파이프라인 및 CI/CD 워크플로 보호

아티클
07/11/2023

이 문서에서는 CI/CD 파이프라인 및 워크플로를 보호하는 방법을 설명합니다.

자동화 및 애자일 방법론을 통해 팀은 더 빠르게 결과를 전달할 수 있지만 워크플로가 개발자 팀 자체로 확장되므로 보안이 복잡해집니다.

다음 다이어그램에서는 기준 CI/CD 워크플로를 보여 줍니다. 빨간색 구성 아이콘 은 고객이 구성해야 하는 보안 권한을 나타냅니다. 이는 Azure 및 기타 공급업체가 거버넌스 모델 및 비즈니스 요구 사항에 따라 고객이 구성해야 하는 권한을 제공하는 공유 책임 모델을 따릅니다.

Git 리포지토리의 코드 변경 내용이 클라우드 리소스에 미치는 영향을 보여 주는 일반적인 CI/CD 워크플로

구성이 서로 의존하는 방식을 이해하는 데 도움이 되도록 이 일반적인 워크플로의 각 단계를 살펴보겠습니다. 워크플로에 더 많은 단계가 있을 수 있습니다. 다음 개념은 CI/CD를 이해하고 보안을 위해 워크플로를 디자인하는 데 도움이 됩니다.

스테이지 1: Git 워크플로

단지 소프트웨어뿐만 아니라 PaC(Pipeline as Code) 및 IaC(Infrastructure as Code)에 대한 코드 변경 내용이 Git에서 저장되고 관리됩니다. Git은 분산 소스 코드 관리 소프트웨어입니다. 로컬 컴퓨터에서 중앙 Git 서버로 코드를 푸시하는 경우 비즈니스 규칙을 수락하기 전에 적용할 수 있습니다.

끌어오기 요청 및 협업

SCM(소프트웨어 구성 관리) SaaS(Software as a Service) 공급업체와 관계없이 업계 표준 워크플로는 소스 코드가 수락되기 전에 자동화된 품질 게이트키퍼 및 수동 승인 단계 역할을 할 수 있는 끌어오기 요청을 사용하는 것입니다.

끌어오기 요청 워크플로는 정상적인 마찰을 발생하도록 설계되었으므로 특정 Git 분기의 보안에만 적용해야 합니다. 특히 클라우드 리소스를 배포 또는 구성하거나 다른 방식으로 영향을 줄 수 있는 자동화된 워크플로를 트리거하는 분기를 보호해야 합니다. 이러한 분기를 보호된 분기라고 하며 일반적으로 이름 지정 규칙(예: production 또는 releases/*)을 따릅니다.

일반적으로 끌어오기 요청에는 다음이 필요합니다.

동료 평가
CI(연속 통합) 빌드 전달
수동 승인

요구 사항이 충족되면 코드 변경 내용이 수락되고 병합될 수 있습니다.

보호된 분기에 대한 액세스 제한

끌어오기 요청 워크플로는 제한된 액세스 제어와 함께 사용됩니다. 그러나 서버가 보호된 분기에 대한 직접 변경을 거부하도록 구성되어 있지 않으면 끌어오기 요청 워크플로를 적용할 수 없습니다.

개발자는 production 분기에 직접 푸시할 수 없으며, 대신 보호된 분기를 대상으로 하는 끌어오기 요청을 만들어야 합니다. 각 SCM 공급업체는 보호된 분기에 대한 제한된 액세스를 달성하기 위한 다른 버전을 가지고 있습니다. 예를 들어 GitHub에서 이 기능은 GitHub 팀 또는 GitHub Enterprise 클라우드를 사용하는 조직에서만 사용할 수 있습니다.

Git 액세스 모델 문서화

협업 모델은 복잡하고 바뀌는 부분이 많기 때문에 다음과 같이 코드 변경이 배포를 트리거할 수 있는 가능한 모든 방법을 문서화하는 테이블을 만드는 것이 유용합니다.

분기 이름	PR 필요 여부	배포 여부	개발자 액세스	관리자 액세스
`feat/*`	아니요	아니요	읽기/쓰기	읽기/쓰기
`main`	예	스테이징	읽기	읽기/쓰기
`production`	예, `main`에서만	생산	읽기	읽기/쓰기

이 Git 액세스 테이블 예제는 용도를 설명하기 위해 상당히 단순화되었습니다. 실제로 더 많은 행위자, 더 많은 배포 대상 및 다양한 사용 사례에 대해 실행되는 여러 파이프라인이 있습니다. 테이블 구조는 조직 및 워크로드의 요구 사항에 따라 다를 수 있습니다.

이 테이블은 다음과 같은 질문에 대답하는 데 도움이 됩니다.

개발자가 코드 변경 내용을 분기 X에 푸시하는 경우 배포되나요? 그렇다면, 어떤 환경으로 배포되나요?
애플리케이션 코드 수명 주기의 어느 시점에서 취약성 검사가 수행되나요?
보안 취약성이 발견되면 프로덕션 환경에 진출하기 전에 필요한 코드 푸시 및 승인은 몇 번이나 필요하나요?

이 테이블은 디버깅 및 정적 설명서뿐만 아니라 팀 협업에도 유용합니다. 코드 품질 및 보안의 우선 순위를 지정하기 위해 워크플로에 건전한 마찰이 도입되었다는 사실은 개발자에게 투명하게 전달됩니다. 더 중요한 것은 코드 변경 내용이 프로덕션 환경에 전달되는 예상 경로가 개발자에게 공개된다는 것입니다.

DevOps는 하나의 여정이므로 Git 액세스 모델은 정적이 아닙니다. 팀이 자체적인 리듬과 완성도를 알아가게 되면서 이러한 모델도 함께 변화하고 진화됩니다. 따라서 이 설명서를 Git 리포지토리에서와 같이 코드와 최대한 가깝게 저장하는 것이 중요합니다.

끌어오기 요청 및 보호된 분기에 대한 자세한 내용은 다음을 참조하세요.

2단계: PaC(Pipelines as code)

PaC(Pipelines as code) 이동은 CI 공급업체에서 개발자로 파이프라인 정의 및 구성을 이동하여 자동화 채택 및 배포를 가속화하여 빌드 및 배포 논리를 해당 애플리케이션 로직과 더 가깝게 만듭니다. 더 큰 유연성이 허락될수록 책임도 커집니다.

UI 기반 파이프라인의 RBAC 컨트롤은 개별 사용자가 파괴적인 변경을 수행하지 못하도록 할 수 있습니다. 그러나 PaC(Pipelines as code)는 권한 있는 ID로 실행되는 경우가 많으며, 그렇게 하도록 지시된 경우 워크로드를 삭제할 수 있습니다.

3단계: 배포 자격 증명 보호

파이프라인 및 코드 리포지토리에는 하드 코딩된 자격 증명 및 비밀이 포함되어서는 안 됩니다. 자격 증명 및 비밀은 다른 위치에 저장해야 하며 보안을 위해 CI 공급업체 기능을 사용해야 합니다. 파이프라인은 헤드리스 에이전트로 실행되므로 개인의 암호를 사용하면 안 됩니다. 파이프라인은 대신 서비스 주체 또는 관리 ID와 같은 헤드리스 보안 주체를 사용하여 실행해야 합니다. 이 보안 주체의 자격 증명, 데이터베이스 연결 문자열 및 타사 API 키에 대한 액세스도 CI 플랫폼에서 안전하게 관리해야 합니다.

자격 증명이 보호되는 방법, 게이트 및 승인은 공급업체별 기능입니다. CI 플랫폼을 선택할 때 필요한 모든 기능을 지원하는지 확인합니다.

Azure Pipelines는 자격 증명이 서비스 연결로 저장되는 엔터프라이즈 스케일 연속 통합 솔루션으로, 이러한 서비스 연결에 대해 승인 및 검사를 구성할 수 있습니다. 이 구성에는 수동 승인과 특정 분기 또는 파이프라인 권한 부여가 포함됩니다.

Azure Key Vault

CI 플랫폼이 지원하는 경우 전용 비밀 저장소(예: Azure Key Vault)에 자격 증명을 저장하는 것이 좋습니다. 자격 증명은 빌드 에이전트가 런타임에 가져오고 공격 표면은 줄어듭니다.

4단계: Azure 리소스 보안 유지

Azure 리소스는 사용 권한과 범위 모두에 적용되는 최소 권한 원칙에 따라 보호해야 합니다.

자세한 내용은 다음을 참조하세요.

빌드 에이전트에 대한 사용자 지정 역할 만들기

CI/CD 자동화는 애플리케이션뿐만 아니라 인프라에도 적용됩니다. IaC(Infrastructure as Code) 템플릿은 일관된 배포를 보장하고 중앙 집중식 클라우드 플랫폼 팀이 스케일링하는 데 도움을 줍니다.

IaC 자동화가 잘못될 수 있음을 이해하는 것이 중요합니다. 잘못 구성될 수 있고 최악의 경우 인프라를 영구적으로 삭제할 수 있습니다. 클라우드 여정을 계획할 때 비즈니스에 중요하고 사용자 개입이 필요한 작업을 미리 파악합니다.

예를 들어 관리 잠금 삭제 불가를 데이터와 같은 중요 비즈니스용 리소스에 적용할 수 있습니다. 이러한 일이 발생하지 않도록 CI 자동화에 사용되는 서비스 주체에서 사용 권한을 제거할 Microsoft.Authorization/*/Delete 수 있습니다. 이 예제 및 사용 사례에서 서비스 주체는 관리 잠금을 만들 수 있지만 삭제할 수는 없습니다.

CI 에이전트에 대한 사용자 지정 역할을 만드는 것이 좋습니다. 빌드 에이전트는 헤드리스로 실행되고 헤드리스 에이전트는 브레인리스입니다. 사용 권한을 신중하게 선택하세요.