Azure RBAC란 무엇인가: Role Assignment와 Scope 이해하기

Azure RBAC는 "누가(Security Principal)", "무엇을(Role Definition)", "어디서(Scope)"라는 세 가지를 묶어 권한을 부여하는 인가(Authorization) 시스템입니다. 이 세 요소의 조합이 Role Assignment이며, RBAC 설계의 출발점입니다.

핵심 요약

• Azure RBAC는 Azure 리소스에 대한 접근을 관리하는 인가(Authorization) 시스템입니다.
• Role Assignment는 Security Principal(누가), Role Definition(무엇을), Scope(어디서) 세 요소로 구성됩니다.
• Scope는 Management Group → Subscription → Resource Group → Resource 4계층으로 구성되며, 상위 Scope의 권한은 하위로 상속됩니다.
• 권한은 모든 Role Assignment를 합산(additive)하고, Deny Assignment가 있으면 우선 차단하는 방식으로 평가됩니다.
• Azure RBAC(리소스 권한)와 Microsoft Entra 역할(디렉터리 권한)은 서로 다른 인가 평면입니다.

1. 왜 RBAC가 필요한가

개발자 5명과 운영자 2명으로 구성된 팀이 Azure 구독 하나를 함께 사용한다고 가정합니다.

권한을 구분하지 않으면 모두가 구독 전체에 대한 소유자(Owner) 권한을 갖게 됩니다. 이 경우 다음 문제가 생깁니다.

• 개발자가 실수로 운영 리소스를 삭제할 수 있습니다.
• 누가 어떤 권한으로 무엇을 변경했는지 추적하기 어렵습니다.
• 외부 협력사에게 특정 리소스 그룹만 열어주고 싶어도 범위를 좁힐 수 없습니다.

Azure RBAC는 이런 문제를 해결하기 위해 "누구에게, 어떤 권한을, 어느 범위까지" 부여할지를 세분화해서 설계할 수 있게 해줍니다. 최소 권한 원칙(Least Privilege)을 Azure에서 구현하는 기본 도구가 RBAC입니다.

2. Azure RBAC란 무엇인가

Azure RBAC(Role-Based Access Control)는 Azure 리소스에 대한 접근을 관리하는 인가 시스템입니다. 여기서 중요한 구분이 있습니다.

단계	담당	질문
인증(Authentication)	Microsoft Entra ID	"당신은 누구인가?"
인가(Authorization)	Azure RBAC	"당신은 무엇을 할 수 있는가?"

사용자가 Microsoft Entra ID로 로그인해 신원을 증명하면(인증), Azure RBAC가 그 사용자가 특정 리소스에 대해 어떤 작업을 할 수 있는지 결정합니다(인가). VM을 만들거나 Storage Blob을 읽는 모든 요청에 대해 RBAC가 권한을 확인합니다.

Tip
AWS 경험자라면 Azure RBAC를 IAM Policy + Role에 대응시켜 이해할 수 있습니다. 다만 AWS는 Policy를 JSON으로 직접 작성해 주체에 연결하는 방식이고, Azure는 미리 정의된 Role을 특정 Scope에 할당하는 방식이라는 점이 다릅니다.

3. Role Assignment의 세 가지 요소

Azure RBAC에서 권한을 부여하는 행위를 Role Assignment(역할 할당)라고 합니다. 모든 Role Assignment는 세 가지 요소로 구성됩니다.

 

azure-rbac-elements

요소	의미	질문
Security Principal	권한을 받는 주체	"누가?"
Role Definition	허용되는 작업의 집합	"무엇을?"
Scope	권한이 적용되는 범위	"어디서?"

이 셋을 묶으면 하나의 문장이 됩니다. 예: "개발팀 그룹(Security Principal)에게 가상 머신 기여자(Role Definition) 권한을 dev 리소스 그룹(Scope)에 부여한다."

3.1 Security Principal (누가)

권한을 부여받는 객체입니다. Azure RBAC에서는 네 가지 유형을 지원합니다.

유형	설명
User	Microsoft Entra ID에 등록된 개별 사용자
Group	사용자 묶음. 그룹에 할당하면 멤버 전체에 적용
Service Principal	애플리케이션이나 서비스의 보안 신원
Managed Identity	Azure가 관리하는 서비스용 자격 증명 (자격 증명 관리 불필요)

Security Note
애플리케이션이 다른 Azure 리소스에 접근해야 할 때는 Service Principal의 비밀(secret)을 직접 관리하기보다 Managed Identity를 우선 검토하는 것이 좋습니다. Managed Identity는 자격 증명을 코드나 설정에 저장하지 않으므로 키 유출 위험을 줄일 수 있습니다.

3.2 Role Definition (무엇을)

Role Definition(역할 정의)은 허용되는 작업의 집합입니다. 흔히 "Role"이라고 부릅니다. Owner, Contributor, Reader 같은 이름이 모두 Role Definition입니다.

Role Definition은 네 가지 권한 목록으로 구성됩니다.

속성	설명
Actions	허용되는 관리 작업 (control plane)
NotActions	Actions에서 제외할 작업
DataActions	허용되는 데이터 작업 (data plane)
NotDataActions	DataActions에서 제외할 작업

여기서 control plane과 data plane의 구분이 중요합니다.

• Control plane(관리 작업): 리소스 자체를 생성/삭제/구성. 예) Storage Account 생성, VM 삭제
• Data plane(데이터 작업): 리소스 안의 데이터에 접근. 예) Blob 읽기, Queue 메시지 쓰기

실제 권한은 Actions - NotActions로 계산됩니다. 예를 들어 어떤 Role이 Microsoft.Storage/*를 Actions로 갖고 Microsoft.Storage/storageAccounts/delete를 NotActions로 가지면, Storage 관련 모든 작업은 허용하되 삭제만 제외하는 역할이 됩니다.

대표적인 기본 제공(built-in) 역할은 다음과 같습니다.

역할	권한 범위
Owner	모든 리소스 관리 + 다른 사용자에게 권한 부여 가능
Contributor	모든 리소스 관리 가능, 단 권한 부여(Role Assignment)는 불가
Reader	모든 리소스 조회만 가능
User Access Administrator	리소스 관리는 불가, 권한 부여만 가능

주의
Owner와 Contributor의 가장 큰 차이는 "다른 사람에게 권한을 줄 수 있는가"입니다. Contributor는 리소스를 자유롭게 관리하지만 Role Assignment 권한이 없으므로, 권한 위임 자체를 통제하고 싶을 때 적합합니다. 권한 부여만 따로 위임하려면 User Access Administrator를 사용합니다.

3.3 Scope (어디서)

Scope는 권한이 적용되는 리소스의 범위입니다. 같은 역할이라도 Scope가 다르면 영향 범위가 완전히 달라집니다. Scope는 다음 절에서 자세히 다룹니다.

4. Scope: 권한의 적용 범위

4.1 4계층 구조

Azure의 Scope는 넓은 범위부터 좁은 범위까지 네 단계로 구성됩니다. 이 계층은 부모-자식 관계를 가집니다.

azure-rbac-scope-hierarchy

계층	범위	예시
Management Group	여러 구독을 묶는 최상위 단위	회사 전체 구독 그룹
Subscription	청구와 리소스 관리의 기본 단위	prod 구독, dev 구독
Resource Group	리소스를 논리적으로 묶는 단위	rg-web-prod
Resource	개별 리소스	특정 VM, Storage Account

4.2 상속 (Inheritance)

Scope의 핵심 동작은 상속입니다. 상위 Scope에 부여한 권한은 하위 Scope로 자동 상속됩니다.

예를 들어 어떤 사용자에게 Subscription Scope로 Reader 역할을 부여하면, 그 구독 안의 모든 Resource Group과 Resource에 대해 자동으로 Reader 권한을 갖게 됩니다.

이 동작은 두 가지 의미를 가집니다.

1. 편의성: 구독 전체에 적용할 권한은 상위에서 한 번만 할당하면 됩니다.
2. 위험성: 상위 Scope에 과도한 권한을 부여하면 의도보다 훨씬 넓은 범위에 영향을 줍니다.

Security Note
Management Group이나 Subscription Scope에 Owner를 부여하면 하위 모든 리소스에 대한 전체 권한이 상속됩니다. 권한은 가능한 한 가장 좁은 Scope(Resource Group 또는 Resource)에 부여하는 것이 최소 권한 원칙에 부합합니다. 넓은 Scope의 강력한 역할은 꼭 필요한 소수에게만 제한합니다.

5. 권한은 어떻게 평가되는가

여러 Role Assignment가 겹칠 때 Azure가 권한을 결정하는 방식은 다음과 같습니다.

azure-rbac-evaluation-flow

5.1 합산(Additive) 방식

Azure RBAC는 적용되는 모든 Role Assignment의 권한을 합산합니다. 즉, 어느 한 곳에서라도 작업이 허용되면 그 작업은 허용됩니다.

예를 들어 한 사용자가 다음 두 할당을 동시에 가진다면:

• Resource Group A에 Reader
• Resource Group A에 Contributor

두 권한이 합쳐져 Contributor로 동작합니다. RBAC의 Role Assignment에는 "Deny" 효과가 없습니다. 모두 "Allow"의 합집합입니다.

5.2 Deny Assignment

다만 Role Assignment와 별개로 Deny Assignment(거부 할당)라는 개념이 있습니다. Deny Assignment는 특정 작업을 명시적으로 차단하며, Role Assignment보다 우선합니다.

구분	Role Assignment	Deny Assignment
효과	Allow (합산)	Deny (차단)
우선순위	낮음	높음 (먼저 평가)
생성 방식	사용자가 직접 할당	주로 Azure Blueprints 등이 자동 생성

권한 평가 순서를 정리하면 다음과 같습니다.

1. 요청에 적용되는 Deny Assignment가 있는지 확인한다. 있으면 즉시 거부한다.
2. Deny Assignment가 없으면, 적용되는 모든 Role Assignment를 합산한다.
3. 합산된 권한에 요청한 작업이 포함되면 허용, 아니면 거부한다.

Tip
"분명히 Contributor를 줬는데 작업이 안 된다"는 상황은 대부분 Deny Assignment 때문이거나, 권한을 부여한 Scope가 실제 작업 대상 Scope와 다르기 때문입니다. 권한 문제 디버깅 시 이 두 가지를 먼저 확인하면 빠르게 원인을 좁힐 수 있습니다.

6. 실무 사용 사례

사례 1: 환경별 권한 분리 (가장 기본)

개발/운영 환경을 구독 또는 리소스 그룹으로 분리하고, 권한을 다르게 부여하는 구조입니다.

# 개발팀 그룹에 dev 리소스 그룹 Contributor 부여
az role assignment create \
  --assignee "<dev-team-group-object-id>" \
  --role "Contributor" \
  --scope "/subscriptions/<sub-id>/resourceGroups/rg-dev"

# 운영팀 그룹에 prod 구독 Reader만 부여 (변경은 별도 승인 프로세스)
az role assignment create \
  --assignee "<ops-team-group-object-id>" \
  --role "Reader" \
  --scope "/subscriptions/<prod-sub-id>"

이 구조를 선택한 이유:

• 개발자는 dev 환경에서 자유롭게 작업하되, prod에는 직접 변경 권한이 없습니다.
• 권한을 개별 사용자가 아닌 그룹에 부여하므로, 인원이 바뀌어도 그룹 멤버십만 조정하면 됩니다.
• prod 변경이 필요할 때는 PIM(Privileged Identity Management) 같은 승인 기반 임시 권한을 별도로 검토할 수 있습니다.

사례 2: 애플리케이션의 Storage 접근

웹 애플리케이션이 Blob Storage에서 파일을 읽어야 하는 상황입니다.

# App Service의 Managed Identity에 특정 Storage Account의 Blob 읽기 권한 부여
az role assignment create \
  --assignee "<managed-identity-object-id>" \
  --role "Storage Blob Data Reader" \
  --scope "/subscriptions/<sub-id>/resourceGroups/rg-web/providers/Microsoft.Storage/storageAccounts/mystorageacct"

여기서 Storage Blob Data Reader는 data plane 역할입니다. 이 역할은 Blob 데이터를 읽을 수 있지만 Storage Account 자체를 삭제하거나 구성을 변경하는 control plane 권한은 없습니다. 접근 키(access key)를 코드에 저장하지 않고 Managed Identity로 인증하므로 키 유출 위험이 줄어듭니다.

사례 3: 외부 협력사에 제한된 접근 부여

외부 협력사에게 특정 리소스 그룹의 모니터링 데이터만 보여주고 싶은 상황입니다. 이 경우 가장 좁은 Scope(해당 리소스 그룹)에 Reader 또는 Monitoring Reader 역할만 부여합니다. 구독이나 Management Group Scope에는 절대 부여하지 않습니다. 이렇게 하면 협력사는 위임된 리소스 그룹 외의 어떤 것도 볼 수 없습니다.

7. Azure RBAC vs Microsoft Entra 역할

Azure를 처음 다룰 때 가장 혼동하기 쉬운 부분입니다. 두 가지는 이름은 비슷하지만 서로 다른 인가 평면(authorization plane)입니다.

기준	Azure RBAC 역할	Microsoft Entra 역할
관리 대상	Azure 리소스 (VM, Storage, Network 등)	Entra ID 리소스 (사용자, 그룹, 앱 등록 등)
적용 범위	Management Group ~ Resource	Entra 테넌트 전체 또는 관리 단위
예시 역할	Owner, Contributor, Reader	Global Administrator, User Administrator
저장 위치	Azure Resource Manager	Microsoft Entra ID

두 시스템의 권한은 서로 호환되지 않습니다. Entra 역할의 권한을 Azure 커스텀 역할에 넣을 수 없고, 그 반대도 마찬가지입니다.

주의
예외적으로 Global Administrator는 "Azure 구독 및 관리 그룹에 대한 액세스 관리" 설정을 켜면 모든 구독의 User Access Administrator 권한을 얻을 수 있습니다. 이는 긴급 복구용이며, 평상시에는 이 두 평면을 분리해서 관리하는 것이 원칙입니다.

8. 커스텀 역할 (Custom Role)

기본 제공 역할이 요구사항에 맞지 않을 때 커스텀 역할을 정의할 수 있습니다. Actions/NotActions/DataActions/NotDataActions를 직접 지정해 필요한 권한만 담은 역할을 만듭니다.

{
  "Name": "VM Operator (No Delete)",
  "Description": "VM 시작/중지/재시작은 가능하지만 삭제는 불가",
  "Actions": [
    "Microsoft.Compute/virtualMachines/start/action",
    "Microsoft.Compute/virtualMachines/restart/action",
    "Microsoft.Compute/virtualMachines/deallocate/action",
    "Microsoft.Compute/virtualMachines/read"
  ],
  "NotActions": [],
  "AssignableScopes": [
    "/subscriptions/<sub-id>"
  ]
}

커스텀 역할은 Microsoft Entra 디렉터리에 저장되며 여러 구독에서 공유할 수 있습니다. AssignableScopes로 이 역할을 어느 범위에서 할당할 수 있는지 제한합니다.

Tip
커스텀 역할을 만들기 전에 기본 제공 역할로 충분한지 먼저 검토하는 것이 좋습니다. Azure에는 수백 개의 세분화된 기본 역할(예: Storage Blob Data Reader, Network Contributor)이 있어, 대부분의 요구사항은 기본 역할 조합으로 해결됩니다. 커스텀 역할은 관리 부담이 따르므로 꼭 필요할 때만 만듭니다.

9. 비용/운영 고려사항

주의
Azure RBAC 자체는 무료이지만, 운영 시 알아둬야 할 제한(limit)이 있습니다. 대규모 환경에서는 이 한도가 설계 제약이 됩니다.

항목	한도/비용
Azure RBAC 사용 비용	무료
구독당 Role Assignment	최대 4,000개 (Management Group Scope 할당은 미포함)
테넌트당 커스텀 역할	최대 5,000개 (21Vianet 운영 Azure는 2,000개)
PIM(Privileged Identity Management)	Microsoft Entra ID P2 라이선스 필요 (별도 비용)

운영 관점:

• 그룹 기반 할당: 개별 사용자보다 그룹에 할당하면 Role Assignment 수를 줄여 4,000개 한도에 여유를 둘 수 있습니다.
• 할당 정리: 사용하지 않는 Role Assignment는 주기적으로 검토하고 제거합니다. Access reviews 기능을 활용할 수 있습니다.
• 조건부 할당(ABAC): 할당 수가 많아지면 속성 기반 조건(Azure ABAC)으로 하나의 할당이 더 세밀하게 동작하도록 설계할 수 있습니다.

10. 자주 하는 실수

1. 넓은 Scope에 강력한 역할을 부여하는 것: 편의를 위해 구독 Scope에 Owner를 주면 모든 하위 리소스로 권한이 상속됩니다. 권한은 가장 좁은 Scope에 부여합니다.
2. 개별 사용자에게 직접 할당하는 것: 인원 변동이 잦으면 관리가 어렵고 할당 수도 빠르게 늘어납니다. 그룹에 할당하고 멤버십으로 관리합니다.
3. control plane과 data plane을 혼동하는 것: Contributor를 줬는데 Blob 데이터를 못 읽는 경우가 있습니다. 데이터 접근에는 Storage Blob Data Reader 같은 data plane 역할이 별도로 필요합니다.
4. Azure RBAC와 Entra 역할을 같은 것으로 보는 것: 사용자에게 Entra의 User Administrator를 줘도 Azure 리소스(VM 등)는 다룰 수 없습니다. 두 평면은 분리되어 있습니다.
5. 권한이 안 될 때 Scope를 확인하지 않는 것: 할당한 Scope와 실제 작업 대상 Scope가 다르면 권한이 적용되지 않습니다. Deny Assignment 여부도 함께 확인합니다.

11. 정리

• Azure RBAC는 Azure 리소스에 대한 인가를 담당하며, 인증은 Microsoft Entra ID가 담당합니다.
• Role Assignment는 Security Principal(누가) + Role Definition(무엇을) + Scope(어디서)의 조합입니다.
• Scope는 Management Group → Subscription → Resource Group → Resource 4계층이며, 상위 권한은 하위로 상속됩니다.
• 권한은 모든 할당을 합산하되, Deny Assignment가 있으면 우선 차단됩니다.
• 최소 권한 원칙은 "가장 좁은 Scope에, 그룹 단위로, 필요한 역할만" 부여하는 것으로 구현합니다.

참고 문서

• Azure 공식 문서: Azure RBAC란 무엇인가
• Azure 공식 문서: Role Assignment 이해하기
• Azure 공식 문서: Scope 이해하기
• Azure 공식 문서: Role Definition 이해하기
• Azure 공식 문서: Azure 역할, Entra 역할, 클래식 관리자 역할
• Azure 공식 문서: 커스텀 역할
• Azure 공식 문서: RBAC 한도 문제 해결