CI/CD를 사용하는 경우 Azure의 엔드 투 엔드 거버넌스

아티클
12/21/2024

조직에 대한 거버넌스 모델을 개발할 때 Azure Resource Manager 리소스를 관리하는 한 가지 방법일 뿐이라는 점을 기억해야 합니다. Azure DevOps 및 CI/CD(지속적인 통합 및 지속적인 업데이트) 자동화는 제대로 보호되지 않는 경우 의도하지 않은 보안 백도어일 수 있습니다. 이러한 리소스는 Resource Manager에 사용되는 RBAC(역할 기반 액세스 제어) 모델을 미러링하여 보호해야 합니다.

엔드 투 엔드 거버넌스의 개념은 공급업체에 구애받지 않습니다. 여기에 설명된 구현에서는 Azure DevOps사용하지만 대안도 간략하게 설명합니다.

잠재적인 사용 사례

이 참조 구현 및 데모는 오픈 소스이며 DevOps를 새로 사용하고 Azure에 배포하기 위한 거버넌스 모델을 만들어야 하는 조직을 위한 교육 도구로 사용됩니다. 이 시나리오를 주의 깊게 읽어 이 샘플 리포지토리에서 사용되는 모델의 의사 결정을 이해하세요.

모든 거버넌스 모델은 액세스 제어의 기술 구현에 반영되는 조직의 비즈니스 규칙에 연결되어야 합니다. 이 예제 모델은 다음과 같은 일반적인 시나리오(비즈니스 요구 사항 사용)를 사용하는 가상의 회사를 사용합니다.

비즈니스 도메인 및 사용 권한 모델과 연계된 Microsoft Entra 그룹
조직에는 크게 독립적으로 운영되는 "과일" 및 "채소"와 같은 많은 수직 비즈니스 도메인이 있습니다. 각 비즈니스 도메인에는 고유한 *-admins 또는 *-devs Microsoft Entra 그룹에 매핑되는 두 가지 수준 또는 권한이 있습니다. 이렇게 하면 클라우드에서 권한을 구성할 때 개발자를 대상으로 지정할 수 있습니다.
배포 환경
모든 팀에는 다음 두 가지 환경이 있습니다.
- 생산. 관리자만 상승된 권한을 갖습니다.
- 비생산. 모든 개발자는 높은 권한을 가집니다(실험 및 혁신을 장려하기 위해).
자동화 목표
모든 애플리케이션은 CI(연속 통합)뿐만 아니라 CD(지속적인 배포)를 위해 Azure DevOps를 구현해야 합니다. 예를 들어 Git 리포지토리를 변경하면 배포가 자동으로 트리거될 수 있습니다.
지금까지 클라우드 경험
조직은 클라우드로의 여정을 가속화하기 위해 격리된 프로젝트 모델로 시작했습니다. 그러나 이제 그들은 "협업"과 "슈퍼마켓"프로젝트를 만들어 사일로를 깨고 협력을 장려하는 옵션을 모색하고 있습니다.

이 간소화된 다이어그램은 Git 리포지토리의 분기가 개발, 스테이징 및 프로덕션 환경에 매핑되는 방법을 보여 줍니다.

다양한 웹 환경에 매핑된 Git 리포지토리 분기의 간소화된 다이어그램
이 다이어그램SVG를 다운로드합니다.

건축학

이 다이어그램은 Resource Manager 및 CI/CD에서 Microsoft Entra ID로 연결하는 것이 엔드 투 엔드 거버넌스 모델을 갖는 열쇠인 방법을 보여줍니다.

이 아키텍처SVG를 다운로드합니다.

메모

개념을 더 쉽게 이해할 수 있도록 다이어그램은 "채소" 도메인만 보여 줍니다. "fruits" 도메인은 비슷하게 보이고 동일한 명명 규칙을 사용합니다.

워크플로

번호 매기기에서는 IT 관리자와 엔터프라이즈 설계자가 클라우드 리소스에 대해 생각하고 구성하는 순서를 반영합니다.

Microsoft Entra ID

Azure DevOps를 Microsoft Entra ID와 통합하여 ID 관리를 위한 단일 플랫폼을 제공합니다. 즉, 개발자는 Azure DevOps 및 Resource Manager에 대해 동일한 Microsoft Entra 계정을 사용합니다. 사용자는 개별적으로 추가되지 않습니다. 대신 Microsoft Entra 그룹에 의해 멤버십이 할당되어, 한 단계로 개발자의 Microsoft Entra 그룹 멤버십을 제거함으로써 리소스에 대한 액세스를 제거할 수 있습니다. 각 도메인에 대해 을(를) 생성합니다.
- Microsoft Entra 그룹. 도메인당 두 개의 그룹(이 문서의 뒷부분에 있는 4단계 및 5단계에서 자세히 설명됨).
- 서비스 주체. 환경당 하나의 명시적 서비스 주체 .
프로덕션 환경

배포를 간소화하기 위해 이 참조 구현은 리소스 그룹을 사용하여 프로덕션 환경을 나타냅니다. 실제로 다른 구독을 사용해야 합니다.

이 환경에 대한 권한 있는 액세스는 관리자로만 제한됩니다.
개발 환경

배포를 간소화하기 위해 이 참조 구현은 리소스 그룹을 사용하여 개발 환경을 나타냅니다. 실제로는 다른 구독을 사용해야 합니다.

Resource Manager에서의 역할 할당

Microsoft Entra 그룹 이름은 역할을 의미하지만 역할 할당 구성될 때까지 액세스 제어가 적용되지 않습니다. Microsoft Entra 주체에 특정 범위에 대한 역할을 할당합니다. 예를 들어 개발자는 프로덕션 환경에서 기여자 역할을 합니다.

Microsoft Entra 주체	개발 환경(Resource Manager)	프로덕션 환경(Resource Manager)
`veggies-devs-group`	소유자	독자
`veggies-admins-group`	소유자	소유자
`veggies-ci-dev-sp`	사용자 지정 역할 *	–
`veggies-ci-prod-sp`	–	사용자 지정 역할 *

* 배포를 간소화하기 위해 이 참조 구현은 서비스 주체에 Owner 역할을 할당합니다. 그러나 프로덕션 환경에서, 서비스 프린시펄이 리소스에 설정한 관리 잠금을 제거하지 못하도록 하는 사용자 지정 역할을 만들어야 합니다. 이렇게 하면 데이터베이스 삭제와 같은 실수로 인한 손상으로부터 리소스를 보호할 수 있습니다.

개별 역할 할당에 대한 추론을 이해하려면 이 문서의 뒷부분에 고려 사항 섹션을 참조하세요.

Azure DevOps에서의 보안 그룹 할당

보안 그룹은 Resource Manager의 역할처럼 작동합니다. 기본 제공 역할을 활용하고, 개발자는 기본적으로 기여자 역할을 사용하십시오. 관리자는 고급 권한을 받기 위해 프로젝트 관리자 보안 그룹에 할당되어, 보안 권한을 구성할 수 있습니다.

Azure DevOps와 Resource Manager는 서로 다른 권한 모델을 가지고 있습니다.

Azure Resource Manager는 추가 권한 모델을 사용합니다.
Azure DevOps는 최소 사용 권한 모델을 사용합니다.

이러한 이유로 -admins 및 -devs 그룹에 대한 멤버 자격은 상호 배타적이어야 합니다. 그렇지 않으면 영향을 받는 사용자는 Azure DevOps에서 예상보다 적은 액세스 권한을 갖습니다.

그룹 이름	리소스 관리자 역할	Azure DevOps 역할
`fruits-all`	–	–
`fruits-devs`	공헌자	공헌자
`fruits-admins`	소유자	프로젝트 관리자
`veggies-all`	–	–
`veggies-devs`	공헌자	공헌자
`veggies-admins`	소유자	프로젝트 관리자
`infra-all`	–	–
`infra-devs`	공헌자	공헌자
`infra-admins`	소유자	프로젝트 관리자

제한된 협업 시나리오의 경우, 예를 들어 과일 팀이 채소 팀을 단일 리포지토리에서 공동 작업하도록 초대할 때, 그들은 veggies-all 그룹을 사용합니다.

개별 역할 할당에 대한 추론을 이해하려면 이 문서의 뒷부분에 고려 사항 섹션을 참조하세요.

서비스 연결

Azure DevOps에서 서비스 연결은 자격 증명을 감싸는 일반적인 래퍼입니다. 서비스 프린시펄 클라이언트 ID와 클라이언트 암호를 포함하는 서비스 연결을 생성합니다. 프로젝트 관리자는 배포하기 전에 사용자 승인이 필요한 경우와 같이 필요한 경우 이 보호된 리소스 대한 액세스를 구성할 수 있습니다. 이 참조 아키텍처에는 서비스 연결에 대한 두 가지 최소 보호가 있습니다.
- 관리자는 자격 증명에 액세스할 수 있는 파이프라인을 제어하기 위해 파이프라인 권한을 구성해야 합니다.
- 또한 관리자는 production 분기의 컨텍스트에서 실행되는 파이프라인만 prod-connection사용할 수 있도록 분기 제어 확인 구성해야 합니다.
저장소 git

서비스 연결이 분기 컨트롤을 통해 분기에 연결되므로 Git 리포지토리에 대한 권한을 구성하고 분기 정책을 적용하는 것이 중요합니다. CI 빌드를 통과하도록 요구하는 것 외에도 풀 리퀘스트에는 승인자가 두 명 이상 있어야 합니다.

구성 요소

대안

엔드 투 엔드 거버넌스의 개념은 공급업체에 구애받지 않습니다. 이 문서에서는 Azure DevOps에 중점을 두고 있지만 Azure DevOps Server 온-프레미스 대체 항목으로 사용할 수 있습니다. 또는 Jenkins 및 GitLab같은 옵션을 사용하여 오픈 소스 CI/CD 개발 파이프라인을 위한 기술 집합을 활용할 수도 있습니다.

Azure Repos와 GitHub는 모두 오픈 소스 Git 버전 제어 시스템을 사용하도록 빌드된 플랫폼입니다. 기능 집합은 다소 다르지만 둘 다 CI/CD에 대한 글로벌 거버넌스 모델에 통합할 수 있습니다. GitLab은 강력한 CI/CD 기능을 제공하는 또 다른 Git 기반 플랫폼입니다.

이 시나리오에서는 Terraform을 IaC(Infrastructure as Code) 도구로 사용합니다. 대안으로는 Jenkins, Ansible및 Chef등이 있습니다.

고려 사항

Azure에서 엔드 투 엔드 거버넌스를 달성하려면 개발자 컴퓨터에서 프로덕션으로의 경로의 보안 및 권한 프로필을 이해하는 것이 중요합니다. 다음 다이어그램에서는 Azure DevOps를 사용하는 기준 CI/CD 워크플로를 보여 줍니다. 빨간색 잠금 아이콘 사용자가 구성해야 하는 보안 권한을 나타냅니다. 권한을 구성하거나 잘못 구성하지 않으면 워크로드가 취약해질 수 있습니다.

Azure DevOps를 사용하여 기본 CI/CD 워크플로를 나타내는 다이어그램
이 워크플로SVG를 다운로드합니다.

워크로드를 성공적으로 보호하려면 워크플로에서 보안 권한 구성과 사용자 확인의 조합을 사용해야 합니다. RBAC 모델도 파이프라인과 코드 모두로 확장해야 합니다. 이러한 ID는 종종 권한 있는 ID를 사용하여 실행되며, 그렇게 하도록 지시된 경우 워크로드를 삭제합니다. 이러한 일이 발생하지 않도록 하려면 자동화 파이프라인을 트리거하는 변경 내용을 수락하기 전에 사용자 승인을 요구하도록 리포지토리에 분기 정책을 구성해야 합니다.

배포 단계	책임	설명
끌어오기 요청	사용자	엔지니어는 파이프라인 코드 자체를 포함하여 작업을 동료 검토해야 합니다.
분기 보호	공유	특정 표준, 예를 들어 CI 검사 및 피어 리뷰(풀 리퀘스트를 통해)를 충족하지 않는 변경 사항을 거부하도록 Azure DevOps를 설정합니다.
파이프라인을 코드	사용자	빌드 서버는 파이프라인 코드가 이를 지시하는 경우 전체 프로덕션 환경을 삭제합니다. 끌어오기 요청 및 분기 보호 규칙(예: 사용자 승인)을 조합하여 이를 방지할 수 있습니다.
서비스 연결	공유	이러한 자격 증명에 대한 액세스를 제한하도록 Azure DevOps를 구성합니다.
Azure 리소스	공유	Resource Manager에서 RBAC를 구성합니다.

거버넌스 모델을 디자인할 때 고려해야 할 개념과 질문은 다음과 같습니다. 예제 조직의 잠재적인 사용 사례에 유의하세요.

1. 브랜치 정책을 사용하여 환경 보호

소스 코드가 배포를 정의하고 트리거하기 때문에 첫 번째 방어선은 SCM(소스 코드 관리) 리포지토리를 보호하는 것입니다. 실제로 이 작업은 끌어오기 요청 워크플로와 분기 정책을 함께 사용하여 수행됩니다. 이 정책들은 코드가 수락되기 전에 검사와 요구 사항을 정의합니다.

엔드 투 엔드 거버넌스 모델을 계획할 때 권한 있는 사용자(veggies-admins)는 분기 보호 구성을 담당합니다. 배포를 보호하는 데 사용되는 일반적인 분기 보호 검사는 다음과 같습니다.

통과하려면 CI 빌드가 필요합니다. 코드 린팅, 단위 테스트, 그리고 바이러스 및 자격 증명 검사 같은 보안 검사 등 기준 코드 품질을 설정하는 데 유용합니다.
피어 검토 코드가 의도한 대로 작동하는지 다른 사람이 다시 확인해야 합니다. 파이프라인 코드를 변경할 때는 주의해야 합니다. CI 빌드를 활용하여 피어 검토를 더 효율적으로 만듭니다.

개발자가 프로덕션 환경에 직접 푸시하려고 하면 어떻게 되나요?

Git은 분산 SCM 시스템입니다. 개발자는 로컬 production 분기에 직접 커밋할 수 있습니다. 그러나 Git이 제대로 구성되면 Git 서버에서 이러한 푸시를 자동으로 거부합니다. 예를 들어:

remote: Resolving deltas: 100% (3/3), completed with 3 local objects.
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Required status check "continuous-integration" is expected.
To https://github.com/Azure/devops-governance
 ! [remote rejected] main -> main (protected branch hook declined)
error: failed to push some refs to 'https://github.com/Azure/devops-governance'

예제의 워크플로는 공급업체에 구애받지 않습니다. 끌어오기 요청 및 분기 보호 기능은 Azure Repos, GitHub및 GitLab포함하여 여러 SCM 공급자에서 사용할 수 있습니다.

코드가 보호된 브랜치에 수용되면 빌드 서버(예: Azure Pipelines)에서 다음 액세스 제어 계층이 적용됩니다.

2. 보안 주체에 필요한 액세스 권한은 무엇인가요?

Azure에서 보안 주체는 사용자 보안 주체 또는 헤드리스 보안 주체로, 서비스 주체 또는 관리 ID와 같은 것일 수 있습니다. 모든 환경에서 보안 주체는 최소 권한원칙을 따라야 합니다. 보안 주체가 사전 프로덕션 환경에서 액세스를 확장했을 수 있지만 프로덕션 Azure 환경은 JIT(Just-In-Time) 액세스 및 Microsoft Entra 조건부 액세스를 선호하여 대기 권한을 최소화해야 합니다. 사용자 보안 주체의 Azure RBAC 역할 할당을 최소 권한 원칙에 맞추어 만드세요.

Azure DevOps RBAC와 별도로 Azure RBAC를 모델링하는 것도 중요합니다. 파이프라인의 목적은 Azure에 대한 직접 액세스를 최소화하는 것입니다. 혁신, 학습 및 문제 해결과 같은 특별한 경우를 제외하고 Azure와의 대부분의 상호 작용은 특별히 빌드되고 제어된 파이프라인을 통해 수행되어야 합니다.

Azure Pipeline 서비스 주체의 경우, 리소스 잠금을 제거하거나 그 목적 범위를 벗어난 파괴적인 작업을 수행하지 않도록 방지하는 사용자 지정 역할을 고려해 보십시오.

3. 프로덕션에 액세스하는 데 사용되는 서비스 주체에 대한 사용자 지정 역할 만들기

CI/CD 빌드 에이전트 소유자 역할 및 권한을 부여하는 것은 일반적인 실수입니다. 파이프라인이 ID 역할 할당 또는 Key Vault 정책 관리와 같은 기타 권한 있는 작업을 수행해야 하는 경우 기여자 권한으로는 충분하지 않습니다.

그러나 CI/CD 빌드 에이전트는 그렇게 하라는 명령을 받을 경우 전체 프로덕션 환경을 삭제할 것입니다. 되돌릴 수 없는 파괴적인 변경방지하기 위해 다음과 같은 사용자 지정 역할을 만듭니다.

Key Vault 액세스 정책을 제거합니다.
의도적으로 리소스가 삭제되지 않도록 해야 하는 관리 잠금을 제거합니다(규제 산업의 일반적인 요구 사항).

이렇게 하려면 사용자 지정 역할을 만들고 Microsoft.Authorization/*/Delete 작업을 제거합니다.

{
  "Name": "Headless Owner",
  "Description": "Can manage infrastructure.",
  "actions": [
    "*"
  ],
  "notActions": [
    "Microsoft.Authorization/*/Delete"
  ],
  "AssignableScopes": [
    "/subscriptions/{subscriptionId1}",
    "/subscriptions/{subscriptionId2}",
    "/providers/Microsoft.Management/managementGroups/{groupId1}"
  ]
}

이렇게 하면 사용자의 목적에 맞게 너무 많은 권한이 제거되는 경우 Azure 리소스 공급자 작업에 대한 공식 설명서의 전체 목록을 참조하고 필요에 따라 역할 정의를 조정합니다.

이 시나리오를 배포하십시오

이 시나리오는 Resource Manager를 넘어 확장됩니다. 이 때문에 Terraform사용하여 Microsoft Entra ID에서 보안 주체를 만들고 단일 인프라를 코드 도구로 사용하여 Azure DevOps를 부트스트랩할 수 있습니다.

소스 코드 및 자세한 지침은 DevOps에서 ARM이르기까지 Azure 데모의 GitHub 리포지토리 거버넌스를 방문하세요.

가격

Azure DevOps 비용은 필요한 동시 빌드/릴리스 수 및 사용자 수와 같은 다른 요인과 함께 액세스가 필요한 조직의 사용자 수에 따라 달라집니다. Azure Repos 및 Azure Pipelines는 Azure DevOps 서비스의 기능입니다. 자세한 내용은 Azure DevOps 가격을 참조하십시오.

Microsoft Entra ID에서 이 시나리오에 필요한 그룹 액세스 관리 유형은 프리미엄 P1 및 프리미엄 P2 버전에서 제공됩니다. 이러한 계층에 대한 가격은 사용자 단위로 계산됩니다. 자세한 내용은 Microsoft Entra 가격 책정을 참조하세요.

참여자

이 문서는 Microsoft에서 유지 관리합니다. 그것은 원래 다음 기여자에 의해 작성되었습니다.

주 작성자:

Julie Ng | 선임 서비스 엔지니어

다음 단계

DevOps에서 ARM이르기까지 Azure 데모의 거버넌스에서 이 시나리오에 대한 코드 리포지토리를 방문하세요.
클라우드 채택 프레임워크의 클라우드 거버넌스 가이드검토합니다.
Azure RBAC(Azure 역할 기반 액세스 제어)란?
클라우드 채택 프레임워크: Azure 리소스 액세스 관리
Azure Resource Manager 역할
Azure DevOps 보안 그룹

다음을 통해 공유