Azure Policy 정의 효과 기본 사항
Azure Policy의 각 정책 정의에는 해당 policyRule
에 단일 effect
가 있습니다. 해당 effect
는 정책 규칙이 일치하는 것으로 평가될 때 어떤 일이 발생하는지 결정합니다. 효과는 새 리소스, 업데이트된 리소스 또는 기존 리소스인 경우 서로 다르게 동작합니다.
지원되는 Azure Policy 정의 효과는 다음과 같습니다.
- addToNetworkGroup
- append
- audit
- auditIfNotExists
- deny
- denyAction
- deployIfNotExists
- disabled
- 수동
- modify
- mutate
효과 교환
경우에 따라 지정된 정책 정의에 대해 여러 효과를 사용할 수 있습니다. 매개 변수는 허용되는 효과 값(allowedValues
)을 지정하는 데 자주 사용되므로 할당 중에 단일 정의를 더 다양하게 사용할 수 있습니다. 그러나 모든 효과를 서로 교환하여 사용할 수 있는 것은 아니라는 점에 유의해야 합니다. 정책 규칙의 리소스 속성 및 논리로 특정 효과가 정책 정의에 유효한 것으로 간주되는지 여부를 결정할 수 있습니다. 예를 들어, 효과가 auditIfNotExists
인 정책 정의에는 효과가 audit
인 정책에 필요하지 않은 정책 규칙의 다른 세부 정보가 필요합니다. 효과도 다르게 작동합니다. audit
정책은 자체 속성을 기반으로 리소스의 준수를 평가하는 반면, auditIfNotExists
정책은 자식 또는 확장 리소스의 속성을 기반으로 리소스 준수를 평가합니다.
다음 목록에는 서로 교환 가능한 효과에 대한 몇 가지 일반적인 지침이 나와 있습니다.
audit
,deny
및modify
또는append
는 종종 서로 교환이 가능합니다.auditIfNotExists
와deployIfNotExists
는 종종 서로 교환할 수 있습니다.manual
은 서로 교환할 수 없습니다.disabled
는 어떤 효과와도 서로 교환 가능합니다.
계산 순서
Azure Policy의 첫 번째 평가는 리소스 만들기 또는 업데이트 요청에 대한 것입니다. Azure Policy는 리소스에 적용한 다음, 각 정의에 대해 리소스를 평가하는 모든 할당 목록을 만듭니다. Resource Manager 모드에서 Azure Policy는 적절한 리소스 공급자에 요청을 전달하기 전에 다양한 효과를 처리합니다. 따라서 리소스가 Azure Policy의 설계된 거버넌스 컨트롤을 충족하지 않을 때 리소스 공급자의 불필요한 처리를 방지할 수 있습니다. 리소스 공급자 모드에서 리소스 공급자는 평가 및 결과를 관리하고 그 결과를 다시 Azure Policy에 보고합니다.
- 정책 규칙을 평가해야 하는지 여부를 결정하기 위해 먼저
disabled
를 확인합니다. - 그런 다음
append
및modify
가 평가됩니다. 어느 쪽이든 요청을 변경할 수 있기 때문에 변경하면 audit 또는 deny 효과가 트리거되지 않을 수 있습니다. 이들 효과는 Resource Manager 모드에서만 사용할 수 있습니다. - 그런 다음
deny
가 평가됩니다. 감사 전에 거부를 평가하여 원치 않는 리소스의 이중 로깅이 방지됩니다. audit
가 평가됩니다.manual
가 평가됩니다.auditIfNotExists
가 평가됩니다.denyAction
은 마지막으로 평가됩니다.
Resource Manager 모드 요청에 대해 리소스 공급자가 성공 코드를 반환하면, auditIfNotExists
및 deployIfNotExists
가 추가 규정 준수 로깅 또는 작업이 필요한지 여부를 확인하기 위해 평가를 수행합니다.
tags
관련 필드만 수정하는 PATCH
요청은 tags
관련 필드를 검사하는 조건이 포함된 정책으로 정책 평가를 제한합니다.
정책 정의 계층화
여러 할당이 리소스에 영향을 미칠 수 있습니다. 이러한 할당은 동일한 범위 또는 서로 다른 범위에 있을 수 있습니다. 이러한 각 할당은 정의된 다른 효과를 가질 수 있습니다. 각 정책에 대한 조건 및 효과는 독립적으로 평가됩니다. 예시:
- 정책 1
- 리소스 위치를
westus
로 제한 - 구독 A에 할당됨
- 거부 효과
- 리소스 위치를
- 정책 2
- 리소스 위치를
eastus
로 제한 - 구독 A의 리소스 그룹 B에 할당됨
- 감사 효과
- 리소스 위치를
이 설정은 다음 결과로 나타납니다.
eastus
에 이미 있는 리소스 그룹 B의 모든 리소스는 정책 2를 준수하지만 정책 1은 준수하지 않음eastus
에 있지 않은 리소스 그룹 B의 모든 리소스는 정책 2를 준수하지 않고westus
에 있지 않은 경우 정책 1도 준수하지 않음- 정책 1은
westus
에 없는 구독 A의 모든 새 리소스를 거부함 westus
에 있는 구독 A 및 리소스 그룹 B의 모든 새 리소스는 정책 2에서 생성되고 정책 2를 준수하지 않음
정책 1 및 정책 2 모두에 거부의 효과가 있는 경우 상황은 다음으로 변경됩니다.
eastus
에 있지 않은 리소스 그룹 B의 모든 리소스는 정책 2를 준수하지 않음westus
에 있지 않은 리소스 그룹 B의 모든 리소스는 정책 1을 준수하지 않음- 정책 1은
westus
에 없는 구독 A의 모든 새 리소스를 거부함 - 구독 A의 리소스 그룹 B에 있는 모든 새 리소스는 거부됨
각 할당은 개별적으로 평가됩니다. 따라서 리소스가 범위의 차이로 인한 간격을 통해 떨어질 기회는 없습니다. 계층화 정책 정의의 최종 결과는 가장 제한적인 누적으로 간주됩니다. 예를 들어 정책 1 및 정책 2 모두에 deny
효과가 있으면 겹치고 충돌하는 정책 정의에 의해 리소스가 차단됩니다. 리소스를 여전히 대상 범위에서 만들어야 하는 경우 각 할당에 대한 제외를 검토하여 적절한 정책 할당이 적절한 범위에 적용되고 있는지 유효성을 검사합니다.
다음 단계
- Azure Policy 샘플에서 예제를 검토합니다.
- Azure Policy 정의 구조를 검토합니다.
- 프로그래밍 방식으로 정책을 만드는 방법을 이해합니다.
- 규정 준수 데이터를 가져오는 방법을 알아봅니다.
- 규정 비준수 리소스를 수정하는 방법을 알아봅니다.
- Azure 관리 그룹을 검토합니다.