패키지 원본 제어 편집

Amazon에서는 패키지 버전을 직접 게시하거나 CodeCatalyst, 업스트림 리포지토리에서 가져오거나, 게이트웨이를 통해 외부 공개 리포지토리에서 패키지 버전을 수집하여 패키지 리포지토리에 추가할 수 있습니다. 공개 리포지토리에서 직접 게시하고 수집하여 패키지 버전을 추가하도록 허용하면 종속성 대체 공격에 취약합니다. 자세한 내용은 종속성 대체 공격 단원을 참조하십시오. 종속성 대체 공격으로부터 자신을 보호하려면 리포지토리의 패키지에 대한 패키지 오리진 제어를 구성하여 해당 패키지의 버전을 리포지토리에 추가할 수 있는 방법을 제한하십시오.

직접 게시와 같은 내부 소스와 공개 리포지토리와 같은 외부 소스에서 서로 다른 패키지의 새 버전을 가져오도록 패키지 오리진 제어를 구성하는 것을 고려해야 합니다. 기본적으로 패키지 오리진 제어는 패키지의 첫 번째 버전이 저장소에 추가되는 방식을 기반으로 구성됩니다.

패키지 원본 제어 설정

패키지 원본 제어를 사용하여 패키지 버전을 리포지토리에 추가하는 방법을 구성할 수 있습니다. 다음 목록에는 사용 가능한 패키지 원본 제어 설정 및 값이 포함되어 있습니다.

게시

이 설정은 패키지 관리자 또는 이와 유사한 도구를 사용하여 패키지 버전을 리포지토리에 직접 게시할 수 있는지를 구성합니다.

• ALLOW: 패키지 버전을 직접 게시할 수 있습니다.

• BLOCK: 패키지 버전은 직접 게시할 수 없습니다.

업스트림

이 설정은 패키지 관리자가 요청하는 경우 패키지 버전을 외부 또는 퍼블릭 리포지토리에서 수집하거나 업스트림 리포지토리에서 유지할 수 있는지를 구성합니다.

• ALLOW: 모든 패키지 버전은 업스트림 CodeCatalyst 리포지토리로 구성된 다른 리포지토리에서 보존하거나 외부 연결을 통해 퍼블릭 소스에서 수집할 수 있습니다.

• BLOCK: 패키지 버전은 업스트림 CodeCatalyst 리포지토리로 구성된 다른 리포지토리에서 보존하거나 외부 연결을 통해 퍼블릭 소스에서 인제스트할 수 없습니다.

기본 패키지 원본 제어 설정

패키지의 기본 패키지 오리진 제어는 해당 패키지의 첫 번째 버전이 패키지 저장소에 추가되는 방식을 기반으로 합니다.

• 패키지 관리자가 첫 번째 패키지 버전을 직접 게시하는 경우 설정은 Publish: ALLOW 및 Upstream:이 됩니다. BLOCK

• 첫 번째 패키지 버전을 공개 소스에서 인제스트하는 경우 설정은 Publish: BLOCK 및 Upstream:이 됩니다. ALLOW

일반적인 패키지 액세스 제어 시나리오

이 섹션에서는 패키지 버전이 패키지 저장소에 추가되는 몇 가지 일반적인 시나리오를 설명합니다. CodeCatalyst 첫 번째 패키지 버전이 추가되는 방식에 따라 새 패키지에 대한 Package 원본 제어 설정이 설정됩니다.

다음 시나리오에서는 유지 관리하는 패키지와 같은 내부 패키지가 패키지 관리자에서 저장소에 직접 게시됩니다. 외부 패키지는 게이트웨이 리포지토리 업스트림을 통해 리포지토리로 인제스트될 수 있는 공용 리포지토리에 있는 패키지입니다.

외부 패키지 버전은 기존 내부 패키지를 대상으로 게시됩니다.

이 시나리오에서는 내부 패키지인 packageA를 가정합니다. 팀에서 PackageA의 첫 번째 패키지 버전을 패키지 저장소에 게시합니다. CodeCatalyst 이 패키지의 첫 번째 패키지 버전이므로, 패키지 원본 제어 설정은 게시: 허용 및 업스트림: 차단으로 자동 설정됩니다. 패키지가 저장소에 게시되면 패키지 저장소에 연결된 공용 저장소에 같은 이름의 패키지가 게시됩니다. CodeCatalyst 이는 내부 패키지에 대한 종속성 대체 공격 시도일 수도 있고 우연의 일치일 수도 있습니다. 하지만 패키지 원본 제어는 새로운 외부 버전의 수집을 차단하여 잠재적 공격을 방어하도록 구성되어 있습니다.

다음 이미지에서 RePOA는 저장소에 대한 업스트림 연결이 있는 CodeCatalyst 패키지 저장소입니다. npm-public-registry-gateway 리포지토리에 packageA 버전 1.1 및 2.1이 있지만 버전 3.0은 퍼블릭 리포지토리에 게시됩니다. 일반적으로 RePOA는 패키지 관리자가 패키지를 요청한 후 버전 3.0을 수집합니다. 패키지 통합이 차단으로 설정되어 있기 때문에 버전 3.0은 패키지 저장소에 인제스트되지 않으며 연결된 CodeCatalyst 패키지 관리자가 버전 3.0을 사용할 수 없습니다.

내부 패키지 버전은 기존 외부 패키지를 대상으로 게시됩니다.

이 시나리오에서는 PackageB 패키지가 저장소에 연결된 공용 저장소 외부에 존재합니다. 리포지토리에 연결된 패키지 관리자가 packageB를 요청하면 해당 패키지 버전이 퍼블릭 리포지토리에서 사용자의 리포지토리로 수집됩니다. 이 패키지는 저장소에 추가된 PackageB의 첫 번째 패키지 버전이므로 패키지 오리진 설정은 Publish: 및 Upstream:으로 구성됩니다. BLOCK ALLOW 나중에 패키지 이름이 동일한 버전을 리포지토리에 게시합니다. 공용 패키지를 모르면서 관련 없는 패키지를 같은 이름으로 게시하려고 하거나, 패치가 적용된 버전을 게시하려고 하거나, 이미 외부에 있는 정확한 패키지 버전을 직접 게시하려고 할 수 있습니다. CodeCatalyst 게시하려는 버전을 거부하지만 거부를 명시적으로 무시하고 필요한 경우 버전을 게시할 수 있습니다.

다음 이미지에서 RePOA는 저장소에 대한 업스트림 연결이 있는 CodeCatalyst 패키지 저장소입니다. npm-public-registry-gateway 패키지 저장소에는 공용 저장소에서 수집한 버전 3.0이 포함되어 있습니다. 버전 1.2를 패키지 저장소에 게시하고 싶습니다. 일반적으로 버전 1.2를 RepoA에 게시할 수 있지만 게시가 차단으로 설정되어 있기 때문에 버전 1.2는 게시할 수 없습니다.

기존 외부 패키지의 패치가 적용된 패키지 버전 게시

이 시나리오에서 PackageB 패키지는 패키지 저장소에 연결된 공용 저장소 외부에 존재합니다. 리포지토리에 연결된 패키지 관리자가 packageB를 요청하면 해당 패키지 버전이 퍼블릭 리포지토리에서 사용자의 리포지토리로 수집됩니다. 이 패키지는 저장소에 추가된 PackageB의 첫 번째 패키지 버전이므로 패키지 오리진 설정은 Publish: 및 Upstream:으로 구성됩니다. BLOCK ALLOW 팀에서 이 패키지의 패치가 적용된 패키지 버전을 저장소에 게시하기로 결정합니다. 패키지 버전을 직접 게시할 수 있도록 팀은 패키지 원본 제어 설정을 Publish: ALLOW 및 Upstream:으로 변경합니다. BLOCK 이제 이 패키지의 버전을 리포지토리에 직접 게시하고 퍼블릭 리포지토리에서 수집할 수 있습니다. 팀에서 패치된 패키지 버전을 게시한 후 팀은 패키지 오리진 설정을 Publish: BLOCK 및 Upstream:으로 되돌립니다. ALLOW

패키지 원본 제어 편집

패키지 오리진 제어는 패키지의 첫 번째 패키지 버전이 패키지 저장소에 추가되는 방식에 따라 자동으로 구성됩니다. 자세한 내용은 기본 패키지 원본 제어 설정 단원을 참조하십시오. 패키지 저장소의 패키지에 대한 패키지 오리진 제어를 추가하거나 편집하려면 다음 절차의 단계를 수행하십시오. CodeCatalyst

패키지 오리진 컨트롤 추가 또는 편집하기

1. 탐색 창에서 Packages(패키지)를 선택합니다.

2. 편집하려는 패키지가 들어 있는 패키지 저장소를 선택합니다.

3. 패키지 테이블에서 편집하려는 패키지를 검색하여 선택합니다.

4. 패키지 요약 페이지에서 Origin 제어를 선택합니다.

5. Origin 컨트롤에서 이 패키지에 설정하려는 패키지 오리진 제어를 선택합니다. 패키지 오리진 컨트롤 설정인 퍼블리시와 업스트림을 동시에 설정해야 합니다.

   • 패키지 버전을 직접 게시할 수 있도록 허용하려면 게시에서 허용을 선택합니다. 패키지 버전 게시를 차단하려면 차단을 선택합니다.

   • 외부 리포지토리에서 패키지를 수집하고 업스트림 리포지토리에서 패키지를 가져오도록 허용하려면 업스트림 소스에서 허용을 선택합니다. 외부 및 업스트림 리포지토리에서의 패키지 버전 수집과 가져오기를 모두 차단하려면 차단을 선택합니다.

6. 저장(Save)을 선택합니다.

리포지토리 게시 및 업스트림

CodeCatalyst에서는 연결 가능한 업스트림 리포지토리 또는 퍼블릭 리포지토리에 있는 패키지 버전을 게시할 수 없습니다. 예를 들어 npm 패키지를 리포지토리에 게시하려고 하는데 npmjs.com에 대한 외부 연결이 있는 lodash@1.0 업스트림 리포지토리가 있다고 가정해 myrepo 보겠습니다. myrepo 다음 시나리오를 고려해 보세요.

1. 패키지 오리진 제어 설정은 게시: 및 업스트림:입니다. lodash ALLOW ALLOW 업스트림 리포지토리 또는 npmjs.com에 있는 경우 lodash@1.0 409 충돌 오류가 발생하여 게시 시도를 CodeCatalyst 거부합니다. myrepo lodash@1.1 같은 다른 버전은 게시할 수 있습니다.

2. 패키지 오리진 제어 설정은 Publish: 및 Upstream: 입니다. lodash ALLOW BLOCK 패키지 버전에 연결할 수 없으므로 아직 존재하지 않는 모든 버전을 저장소에 게시할 수 있습니다. lodash

3. 의 패키지 원본 제어 lodash 설정은 게시: BLOCK 및 업스트림:입니다. ALLOW 패키지 버전은 리포지토리에 직접 게시할 수 없습니다.

종속성 대체 공격

패키지 관리자는 재사용 가능한 코드를 패키징하고 공유하는 프로세스를 단순화합니다. 이러한 패키지는 애플리케이션에서 사용하기 위해 조직에서 개발한 프라이빗 패키지일 수도 있고, 조직 외부에서 개발되어 퍼블릭 패키지 리포지토리에서 배포하는 퍼블릭(대부분의 경우 오픈 소스) 패키지일 수도 있습니다. 패키지를 요청할 때 개발자는 패키지 관리자를 이용해 종속 항목의 새 버전을 가져옵니다. 종속성 혼동 공격이라고도 하는 종속성 대체 공격은 대부분의 패키지 관리자가 패키지의 합법적인 버전과 악성 버전을 구분할 방법이 없다는 사실을 악용합니다.

종속성 대체 공격은 소프트웨어 공급망 공격으로 알려진 공격의 일부에 속합니다. 소프트웨어 공급망 공격은 소프트웨어 공급망에 존재하는 취약성을 악용하는 공격입니다.

종속성 대체 공격은 내부적으로 개발된 패키지와 퍼블릭 리포지토리에서 가져온 패키지를 모두 사용하는 사용자라면 누구나 노릴 수 있습니다. 공격자는 내부 패키지 이름을 식별한 다음 같은 이름의 악성 코드를 전략적으로 퍼블릭 패키지 리포지토리에 배치합니다. 일반적으로 악성 코드는 버전 번호가 높은 패키지에 게시됩니다. 패키지 관리자는 악성 패키지가 패키지 최신 버전이라고 생각하기 때문에 이러한 퍼블릭 피드에서 악성 코드를 가져옵니다. 이로 인해 원하는 패키지와 악성 패키지 간에 “혼동” 또는 “대체”가 발생하여 코드가 손상될 수 있습니다.

종속성 대체 공격을 방지하기 위해 CodeCatalyst Amazon은 패키지 오리진 제어를 제공합니다. 패키지 원본 제어는 패키지를 리포지토리에 추가하는 방법을 제어하는 설정입니다. 컨트롤은 새 패키지의 첫 번째 패키지 버전을 리포지토리에 추가할 때 자동으로 구성됩니다. 제어를 통해 패키지 버전을 CodeCatalyst 리포지토리에 직접 게시하거나 퍼블릭 소스에서 수집할 수 없도록 보장하여 종속성 대체 공격으로부터 보호할 수 있습니다. 패키지 원본 제어 및 이를 변경하는 방법에 대한 자세한 내용은 패키지 원본 제어 편집 섹션을 참조하세요.