조직의 거버넌스 모델을 개발하는 경우 Azure Resource Manager는 리소스를 관리하는 한 가지 방법일 뿐입니다. Azure DevOps 및 CI/CD(연속 통합 및 지속적인 업데이트) 자동화는 적절하게 보호되지 않으면 의도하지 않은 보안 백 도어가 될 수 있습니다. 이러한 리소스는 Resource Manager에 사용되는 RBAC(역할 기반 액세스 제어) 모델을 미러링하여 보호해야 합니다.
엔드투엔드 거버넌스의 개념은 공급업체에 구애받지 않습니다. 여기서 설명하는 구현은 Azure DevOps를 사용하지만 대안도 간략하게 설명합니다.
잠재적인 사용 사례
이 참조 구현 및 데모는 오픈 소스이며, DevOps를 처음 사용하고 Azure에 배포하기 위한 거버넌스 모델을 만들어야 하는 조직을 위한 학습 도구로 사용하기 위한 것입니다. 이 샘플 리포지토리에 사용된 모델을 지지하는 결정을 이해하려면 이 시나리오를 주의 깊게 참조하세요.
거버넌스 모델은 액세스 제어의 기술적 구현에 반영되는 조직의 비즈니스 규칙과 연결해야 합니다. 이 예제 모델에서는 다음과 같은 일반적인 시나리오(비즈니스 요구 사항 포함)가 있는 가상의 회사를 사용합니다.
비즈니스 도메인 및 권한 모델에 부합하는 Microsoft Entra 그룹
조직에는 "fruits" 및 "vegetables"와 같은 많은 수직적 비즈니스 영역이 있으며 대부분 독립적으로 운영됩니다. 각 비즈니스 도메인에는 고유*-admins또는 Microsoft Entra 그룹에 매핑되는 두 가지 수준 또는*-devs권한이 있습니다. 이렇게 하면 클라우드에서 권한을 구성할 때 개발자를 대상으로 지정할 수 있습니다.배포 환경
모든 팀에는 다음 두 가지 환경이 있습니다.- 프로덕션 관리자만 상승된 권한을 갖습니다.
- 비프로덕션. 모든 개발자가 상승된 권한을 갖습니다(실험과 혁신을 장려하기 위해).
자동화 목표
모든 애플리케이션은 CI(연속 통합)뿐만 아니라 CD(지속적인 배포)를 위해서도 Azure DevOps를 구현해야 합니다. 예를 들어 Git 리포지토리를 변경하여 배포를 자동으로 트리거할 수 있습니다.지금까지의 클라우드 여정
조직은 클라우드로의 여정을 가속화하기 위해 격리된 프로젝트 모델로 시작했습니다. 그러나 이제 "협업" 및 "슈퍼마켓" 프로젝트를 만들어 사일로를 깨고 협업을 장려하는 옵션을 찾고 있습니다.
간소화된 다음 다이어그램에서는 Git 리포지토리의 분기가 개발, 준비 및 프로덕션 환경에 매핑되는 방법을 보여 줍니다.
이 다이어그램의 SVG를 다운로드하세요.
아키텍처
이 다이어그램은 Resource Manager 및 CI/CD에서 Microsoft Entra ID로 연결하는 것이 엔드 투 엔드 거버넌스 모델을 갖는 열쇠인 방법을 보여줍니다.
이 아키텍처의 SVG를 다운로드하세요.
참고
개념을 더 쉽게 이해할 수 있도록 다이어그램에서는 "veggies" 도메인만 보여 줍니다. "fruits" 도메인은 비슷하게 보이고 동일한 명명 규칙을 사용합니다.
워크플로
번호 매기기는 IT 관리자와 엔터프라이즈 설계자가 클라우드 리소스에 대해 생각하고 구성하는 순서를 반영합니다.
Microsoft Entra ID
ID에 대한 단일 평면을 갖기 위해 Azure DevOps를 Microsoft Entra ID와 통합합니다. 즉, 개발자는 Azure DevOps 및 Resource Manager에 대해 동일한 Microsoft Entra 계정을 사용합니다. 사용자는 개별적으로 추가되지 않습니다. 대신 Microsoft Entra 그룹 멤버 자격을 제거하여 개발자가 한 단계에서 리소스에 대한 액세스를 제거할 수 있도록 멤버 자격이 Microsoft Entra 그룹에 의해 할당됩니다. 각 도메인에 대해 다음을 만듭니다.
- Microsoft Entra 그룹. 도메인당 2개의 그룹(이 문서 뒷부분의 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에는 다음과 같은 다른 권한 모델이 있습니다.
이러한 이유로
-admins및-devs그룹에 대한 멤버 자격은 상호 배타적이어야 합니다. 그렇지 않으면 영향을 받는 사용자가 Azure DevOps에서 필요한 것보다 낮은 액세스 권한을 갖게 됩니다.그룹 이름 Resource Manager 역할 Azure DevOps 역할 fruits-all– – fruits-devs참가자 참가자 fruits-admins소유자 Project Administrators veggies-all– – veggies-devs참가자 참가자 veggies-admins소유자 Project Administrators infra-all– – infra-devs참가자 참가자 infra-admins소유자 Project Administrators 제한된 협업 시나리오에서 단일 리포지토리에서 협업하기 위해 fruits 팀에서 veggies 팀을 초대한 다음,
veggies-all그룹을 사용하는 경우입니다.개별 역할 할당을 지지하는 추론을 이해하려면 이 문서의 뒷부분에 나오는 고려 사항 섹션을 참조하세요.
Service connections(서비스 연결)
Azure DevOps에서 서비스 연결은 자격 증명을 둘러싼 일반 래퍼입니다. 서비스 주체 클라이언트 ID와 클라이언트 암호를 포함하는 서비스 연결을 만듭니다. 프로젝트 관리자는 필요한 경우(예: 배포 전에 사람의 승인이 필요한 경우) 이 보호된 리소스에 대한 액세스를 구성할 수 있습니다. 이 참조 아키텍처에는 서비스 연결에 대한 다음 두 가지 최소 보호 기능이 있습니다.
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 워크플로를 보여 줍니다. 빨간색 잠금 아이콘 
은 사용자가 구성해야 하는 보안 권한을 나타냅니다. 권한을 구성하지 않거나 잘못 구성하면 워크로드가 취약해집니다.
이 워크플로의 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를 부트스트랩할 수 있습니다.
소스 코드 및 자세한 지침은 Azure Demo의 거버넌스 - DevOps에서 ARM으로 GitHub 리포지토리를 방문하세요.
가격 책정
Azure DevOps 비용은 필요한 동시 빌드/릴리스 수 및 사용자 수와 같은 기타 요소와 함께 액세스가 필요한 조직의 사용자 수에 따라 달라집니다. Azure Repos 및 Azure Pipelines는 Azure DevOps 서비스의 기능입니다. 자세한 내용은 Azure DevOps 가격 책정을 참조하세요.
Microsoft Entra ID에서 이 시나리오에 필요한 그룹 액세스 관리 유형은 프리미엄 P1 및 프리미엄 P2 버전에서 제공됩니다. 이러한 계층의 가격 책정은 사용자 단위로 계산됩니다. 자세한 내용은 Microsoft Entra 가격 책정을 참조하세요.
참가자
Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.
보안 주체 작성자:
- Julie Ng | 선임 서비스 엔지니어
다음 단계
- Azure Demo의 거버넌스 - DevOps에서 ARM으로에 서 이 시나리오에 대한 코드 리포지토리를 방문합니다.
- 클라우드 채택 프레임워크의 클라우드 거버넌스 가이드를 검토합니다.
- Azure RBAC(Azure 역할 기반 액세스 제어)란?
- 클라우드 채택 프레임워크: Azure에서 리소스 액세스 관리
- Azure Resource Manager 역할
- Azure DevOps 보안 그룹