잘 정의된 프로세스에서 타사 소프트웨어 아티팩트가 검증되고 사용하기 안전한 것으로 표시된 경우에만 공급망에서 타사 소프트웨어 아티팩트 사용 이 패턴은 개발 프로세스에 대한 운영 사이드카입니다. 이 패턴의 소비자는 이 프로세스를 호출하여 잠재적으로 보안 취약성을 발생시킬 수 있는 소프트웨어의 사용을 확인하고 차단합니다.
컨텍스트 및 문제점
클라우드 솔루션은 종종 외부 원본에서 가져온 타사 소프트웨어를 사용합니다. 오픈 소스 이진 파일, 공용 컨테이너 이미지, 공급업체 OS 이미지는 이러한 아티팩트 유형의 몇 가지 예입니다. 이러한 모든 외부 아티팩트는 신뢰할 수 없는 것으로 처리되어야 합니다.
일반적인 워크플로에서는 아티팩트가 솔루션 범위 외부의 저장소에서 검색된 다음 배포 파이프라인에 통합됩니다. 이 방법에는 몇 가지 잠재적인 문제가 있습니다. 원본을 신뢰할 수 없거나, 아티팩트에서 취약성을 포함하거나, 개발자 환경에 적합하지 않을 수 있습니다.
이러한 문제가 해결되지 않으면 솔루션의 데이터 무결성 및 기밀성 보장이 손상되거나 다른 구성 요소와의 비호환성으로 인해 불안정해질 수 있습니다.
이러한 보안 문제 중 일부는 각 아티팩트에서 검사 추가하여 방지할 수 있습니다.
솔루션
워크로드에 소프트웨어를 도입하기 전에 보안에 대한 소프트웨어의 유효성을 검사하는 프로세스가 있어야 합니다. 프로세스 중에 각 아티팩트는 특정 조건에 대해 이를 확인하는 철저한 운영 엄격함을 겪습니다. 아티팩트가 해당 조건을 충족한 후에만 프로세스는 이를 신뢰할 수 있는 것으로 표시합니다.
격리 프로세스는 아티팩트를 소비하기 전에 사용되는 일련의 검사포인트로 구성된 보안 조치입니다. 이러한 보안 검사점은 아티팩트가 신뢰할 수 없는 상태 신뢰할 수 있는 상태 전환되도록 합니다.
격리 프로세스는 아티팩트의 컴퍼지션을 변경하지 않는다는 점에 유의해야 합니다. 이 프로세스는 소프트웨어 개발 주기와 독립적이며 필요에 따라 소비자가 호출합니다. 아티팩트의 소비자는 격리를 통과할 때까지 아티팩트 사용을 차단합니다.
일반적인 격리 워크플로는 다음과 같습니다.
소비자는 의도를 알리고 아티팩트 입력 소스를 지정하며 사용을 차단합니다.
격리 프로세스는 요청의 원본의 유효성을 검사하고 지정된 저장소에서 아티팩트를 가져옵니다.
사용자 지정 확인 프로세스는 격리의 일부로 수행됩니다. 여기에는 입력 제약 조건 확인 및 설정된 표준에 대한 특성, 원본 및 형식 검사 포함됩니다.
이러한 보안 검사 중 일부는 제출된 각 아티팩트에서 취약성 검사, 맬웨어 검색 등이 될 수 있습니다.
실제 검사 아티팩트 유형에 따라 달라집니다. 예를 들어 OS 이미지 평가는 NuGet 패키지를 평가하는 경우와 다릅니다.
확인 프로세스가 성공하면 아티팩트가 명확한 주석이 있는 안전한 저장소에 게시됩니다. 그렇지 않으면 소비자가 사용할 수 기본 없습니다.
게시 프로세스에는 확인 증명 및 각 검사 중요도를 보여 주는 누적 보고서가 포함될 수 있습니다. 보고서가 유효하지 않으며 아티팩트가 안전하지 않은 것으로 간주되는 보고서의 만료를 포함합니다.
이 프로세스는 보고서와 함께 상태 정보를 사용하여 이벤트에 신호를 전송하여 격리의 끝을 표시합니다.
정보에 따라 소비자는 신뢰할 수 있는 아티팩트 사용을 위한 작업을 수행할 수 있습니다. 이러한 작업은 격리 패턴의 범위를 벗어났습니다.
문제 및 고려 사항
타사 아티팩트를 사용하는 팀으로서 신뢰할 수 있는 원본에서 가져오는지 확인합니다. 타사 공급업체에서 조달하는 아티팩트용 조직 승인 표준에 맞게 선택해야 합니다. 공급업체는 워크로드(및 조직)의 보안 요구 사항을 충족할 수 있어야 합니다. 예를 들어 공급업체의 책임 있는 공개 계획이 조직의 보안 요구 사항을 충족하는지 확인합니다.
신뢰할 수 있는 아티팩트와 신뢰할 수 없는 아티팩트가 저장되는 리소스 간에 구분을 만듭니다. ID 및 네트워크 컨트롤을 사용하여 권한 있는 사용자에 대한 액세스를 제한합니다.
격리 프로세스를 호출하는 신뢰할 수 있는 방법을 갖습니다. 아티팩트가 신뢰할 수 있는 것으로 표시될 때까지 실수로 소비되지 않는지 확인합니다. 신호를 자동화해야 합니다. 예를 들어 아티팩트가 개발자 환경에 수집될 때 책임 당사자에게 알리고, GitHub 리포지토리에 변경 내용을 커밋하고, 프라이빗 레지스트리에 이미지를 추가하는 등의 작업과 관련이 있습니다.
격리 패턴을 구현하는 대안은 격리 패턴을 아웃소싱하는 것입니다. 공공 자산 유효성 검사를 비즈니스 모델로 전문으로 하는 격리 실무자가 있습니다. 패턴을 구현하는 데 드는 재무 및 운영 비용과 책임을 아웃소싱하는 비용을 모두 평가합니다. 보안 요구 사항에 더 많은 제어가 필요한 경우 사용자 고유의 프로세스를 구현하는 것이 좋습니다.
아티팩트 수집 프로세스 및 아티팩트 게시 프로세스를 자동화합니다. 유효성 검사 작업에는 시간이 걸릴 수 있으므로 자동화 프로세스는 모든 작업이 완료될 때까지 계속할 수 있어야 합니다.
이 패턴은 첫 번째 기회 순간적인 유효성 검사 역할을 합니다. 격리를 성공적으로 전달해도 아티팩트가 신뢰할 수 있는 기본 보장하지는 않습니다. 아티팩트에서는 릴리스를 승격하기 전에 마지막 기회 유효성 검사 역할을 하는 연속 검사, 파이프라인 유효성 검사 및 기타 일상적인 보안 검사 계속 진행해야 합니다.
이 패턴은 조직의 중앙 팀 또는 개별 워크로드 팀에서 구현할 수 있습니다. 격리 프로세스의 여러 인스턴스 또는 변형이 있는 경우 조직에서 이러한 작업을 표준화하고 중앙 집중화해야 합니다. 이 경우 워크로드 팀은 프로세스를 공유하고 프로세스 관리를 오프로드하는 이점을 누릴 수 있습니다.
이 패턴을 사용해야 하는 경우
다음 경우에 이 패턴을 사용합니다.
워크로드는 워크로드 팀의 범위 외부에서 개발된 아티팩트를 통합합니다. 일반적인 예는 다음과 같습니다.
DockerHub, GitHub Container Registry, Microsoft Container Registry와 같은 공용 레지스트리의 OCI(Open Container Initiative) 아티팩트
NuGet 갤러리, Python 패키지 인덱스, Apache Maven 리포지토리와 같은 공용 원본의 소프트웨어 라이브러리 또는 패키지
Terraform 모듈, Community Chef Cookbooks, Azure 확인된 모듈과 같은 외부 IaC(Infrastructure-as-Code) 패키지
공급업체에서 제공하는 OS 이미지
워크로드 팀은 아티팩트를 완화할 가치가 있는 위험으로 간주합니다. 팀은 손상된 아티팩트를 통합하면 발생하는 부정적인 결과와 신뢰할 수 있는 환경을 보장하는 격리의 가치를 이해합니다.
팀은 아티팩트 유형에 적용해야 하는 유효성 검사 규칙에 대해 명확하고 공유된 이해를 가지고 있습니다. 합의가 없으면 패턴이 효과적이지 않을 수 있습니다.
예를 들어 OS 이미지를 격리로 수집할 때마다 다른 유효성 검사 검사 집합이 적용되면 OS 이미지에 대한 전반적인 확인 프로세스가 일치하지 않습니다.
다음의 경우에는 이 패턴이 유용하지 않습니다.
소프트웨어 아티팩트 워크로드 팀 또는 신뢰할 수 있는 파트너 팀에 의해 만들어집니다.
아티팩트를 확인하지 않을 위험이 격리 프로세스를 빌드하고 기본 비용보다 저렴합니다.
워크로드 디자인
설계자와 워크로드 팀은 격리 패턴을 워크로드의 DevSecOps 사례의 일부로 사용하는 방법을 평가해야 합니다. 기본 원칙은 Azure Well-Architected Framework 핵심 요소에서 다룹니다.
| 핵심 요소 | 이 패턴이 핵심 목표를 지원하는 방법 |
|---|---|
| 보안 디자인 결정은 워크로드의 데이터 및 시스템의 기밀성, 무결성 및 가용성을 보장하는 데 도움이 됩니다. | 보안 유효성 검사의 첫 번째 책임은 격리 패턴에 의해 제공됩니다. 외부 아티팩트의 유효성 검사는 개발 프로세스에서 사용하기 전에 분할된 환경에서 수행됩니다. - SE:02 보안 개발 수명 주기 - SE:11 테스트 및 유효성 검사 |
| 운영 우수성은 표준화된 프로세스와 팀 응집력을 통해 워크로드 품질을 제공하는 데 도움이 됩니다. | 격리 패턴은 손상된 아티팩트가 워크로드에서 소비되지 않도록 하여 SDP(안전한 배포 방법)를 지원하므로 점진적 노출 배포 중에 보안 위반이 발생할 수 있습니다. - OE:03 소프트웨어 개발 사례 - OE:11 테스트 및 유효성 검사 |
디자인 결정과 마찬가지로 이 패턴으로 도입될 수 있는 다른 핵심 요소의 목표에 대한 절충을 고려합니다.
예시
이 예제에서는 워크로드 팀이 공용 레지스트리의 OCI 아티팩트를 워크로드 팀이 소유한 ACR(Azure Container Registry) 인스턴스에 통합하려는 시나리오에 솔루션 워크플로를 적용합니다. 팀은 해당 인스턴스를 신뢰할 수 있는 아티팩트 저장소로 처리합니다.
워크로드 환경에서는 Kubernetes용 Azure Policy를 사용하여 거버넌스를 적용합니다. 신뢰할 수 있는 레지스트리 인스턴스에서만 컨테이너 끌어오기만 제한합니다. 또한 Azure Monitor 경고는 예기치 않은 원본에서 해당 레지스트리로의 가져오기를 검색하도록 설정됩니다.
외부 이미지에 대한 요청은 Azure Web Apps에서 호스트되는 사용자 지정 애플리케이션을 통해 워크로드 팀에 의해 이루어집니다. 애플리케이션은 권한 있는 사용자로부터만 필요한 정보를 수집합니다.
보안 검사point: 요청자의 ID, 대상 컨테이너 레지스트리 및 요청된 이미지 원본이 확인됩니다.
요청은 Azure Cosmos DB에 저장됩니다.
보안 검사point: 감사 내역이 데이터베이스에 기본, 이미지의 계보 및 유효성 검사를 추적합니다. 이 트레일은 기록 보고에도 사용됩니다..
요청은 지속성 있는 Azure Function인 워크플로 오케스트레이터에 의해 처리됩니다. 오케스트레이터는 모든 유효성 검사를 실행하기 위해 분산형 수집 방법을 사용합니다.
보안 검사point: 오케스트레이터에는 유효성 검사 작업을 수행하기에 충분한 액세스 권한이 있는 관리 ID가 있습니다.
오케스트레이터는 신뢰할 수 없는 저장소로 간주되는 격리 ACR(Azure Container Registry)로 이미지를 가져오도록 요청합니다.
격리 레지스트리의 가져오기 프로세스는 신뢰할 수 없는 외부 리포지토리에서 이미지를 가져옵니다. 가져오기에 성공하면 격리 레지스트리에 유효성 검사를 실행할 이미지의 로컬 복사본이 있습니다.
보안 검사포인트: 격리 레지스트리는 유효성 검사 프로세스 중에 변조 및 워크로드 사용으로부터 보호합니다.
오케스트레이터는 이미지의 로컬 복사본에서 모든 유효성 검사 작업을 실행합니다. 작업에는 CVE(Common Vulnerabilities and Exposures) 검색, SBOM(소프트웨어 자료 청구) 평가, 맬웨어 검색, 이미지 서명 등과 같은 검사 포함됩니다.
오케스트레이터는 검사 유형, 실행 순서 및 실행 시간을 결정합니다. 이 예제에서는 작업 실행기로 Azure Container Instance를 사용하고 결과는 Cosmos DB 감사 데이터베이스에 있습니다. 모든 작업은 상당한 시간이 걸릴 수 있습니다.
보안 검사point: 이 단계는 모든 유효성 검사 검사 수행하는 격리 프로세스의 핵심입니다. 검사 유형은 사용자 지정, 오픈 소스 또는 공급업체에서 구매한 솔루션일 수 있습니다.
오케스트레이터가 결정을 내립니다. 이미지가 모든 유효성 검사를 통과하면 이벤트가 감사 데이터베이스에 기록되고, 이미지가 신뢰할 수 있는 레지스트리로 푸시되고, 로컬 복사본이 격리 레지스트리에서 삭제됩니다. 그렇지 않으면 의도치 않은 사용을 방지하기 위해 격리 레지스트리에서 이미지가 삭제됩니다.
보안 검사point: 오케스트레이터는 신뢰할 수 있는 리소스 위치와 신뢰할 수 없는 리소스 위치 간의 구분을 기본.
참고 항목
오케스트레이터가 결정을 내리는 대신 워크로드 팀은 해당 책임을 맡을 수 있습니다. 이 대안에서 오케스트레이터는 API를 통해 유효성 검사 결과를 게시하고 일정 기간 동안 이미지를 격리 레지스트리에 유지합니다.
워크로드 팀은 결과를 검토한 후 결정을 내립니다. 결과가 위험 허용 오차를 충족하는 경우 격리 리포지토리의 이미지를 컨테이너 인스턴스로 끌어옵니다. 이 끌어오기 모델은 보안 위험 허용 범위가 다른 여러 워크로드 팀을 지원하는 데 이 패턴을 사용하는 경우 더 실용적입니다.
모든 컨테이너 레지스트리는 새로 발견된 문제를 지속적으로 검색하는 컨테이너용 Microsoft Defender에서 다룹니다. 이러한 문제는 Microsoft Defender 취약성 관리 표시됩니다.
다음 단계
이 패턴을 구현할 때 다음 지침이 관련이 있을 수 있습니다.
개발 수명 주기를 보호하기 위한 권장 사항 개발 수명 주기의 모든 단계를 통해 신뢰할 수 있는 코드 단위를 사용하는 방법에 대한 지침을 제공합니다.
특히 애플리케이션에 NuGet 종속성이 있는 경우 보안 소프트웨어 공급망 에 대한 모범 사례입니다.
Azure Artifacts 설명서는 Azure Artifacts를 사용하여 소프트웨어 패키지 관리와 관련된 정보의 라이브러리입니다.