AZ-104 문제은행에서 가장 많이 나오는 주제는 Azure RBAC입니다. 그런데 시험은 "Contributor가 무엇인가"를 묻는 데서 멈추지 않습니다. 사용자·그룹·범위가 섞인 역할 할당 표를 보여 주고 "User1은 VM2를 다시 시작할 수 있는가", "누구에게 어떤 역할을 어느 범위에 주어야 최소 권한인가"를 판단하게 합니다. 공식 출제 범위에도 "기본 제공 역할 관리", "여러 범위에서 역할 할당", "액세스 할당 해석"이 따로 적혀 있습니다.
이 글은 역할 할당을 읽고 해석하는 방법에 집중합니다. 역할 할당을 이루는 세 요소, 꼭 구분해야 할 기본 제공 역할, 범위와 상속, 거부 할당과 NotActions의 차이, Entra 역할과 Azure 역할의 경계, 그리고 IAM 화면의 "액세스 확인"으로 실제 권한을 확인하는 방법까지 차례로 다룹니다. RBAC의 기본 개념은 ID와 거버넌스에서 먼저 정리해 두었습니다.
---
역할 할당은 세 요소로 이루어진다
회사 출입증을 떠올려 보세요. 출입증에는 누구의 것인지(사람), 어떤 등급인지(방문객·직원·관리자), 어느 층에 들어갈 수 있는지(구역)가 함께 적혀 있습니다. 셋 중 하나만 바뀌어도 전혀 다른 출입증이 됩니다. Azure의 역할 할당도 똑같이 세 요소의 조합입니다.
| 요소 | 질문 | 들어갈 수 있는 값 | |------|------|------| | 보안 주체 | 누가? | 사용자, 그룹, 서비스 주체, 관리 ID | | 역할 정의 | 무엇을? | 허용할 작업 목록 (Actions, DataActions) | | 범위 | 어디서? | 관리 그룹, 구독, 리소스 그룹, 리소스 |
!역할 할당은 보안 주체, 역할 정의, 범위의 조합이다
권한은 사람에게 직접 주기보다 그룹에 주는 것이 관리하기 쉽습니다. 그룹에 역할을 할당하면 그룹에 들어온 사람은 자동으로 권한을 얻고, 그룹에서 빠지면 자동으로 잃습니다. VM이나 App Service 같은 리소스가 다른 리소스에 접근해야 할 때는 관리 ID를 켜고 그 ID에 역할을 할당합니다. 리소스와 함께 생기고 지워지는 것은 시스템 할당 관리 ID, 독립 리소스로 만들어 여러 리소스가 함께 쓰는 것은 사용자 할당 관리 ID입니다.
시험 팁: "코드나 설정 파일에 자격 증명을 저장하지 않고 VM이 스토리지에 접근"은 VM의 관리 ID에 스토리지 데이터 역할을 할당하는 것이 정답입니다.
---
꼭 구분해야 할 기본 제공 역할
Azure에는 수백 개의 기본 제공 역할이 있지만, AZ-104 문제에서 반복해서 나오는 역할은 정해져 있습니다. 역할 이름 뒤의 "할 수 없는 것"까지 함께 외워야 오답 보기를 걸러낼 수 있습니다.
| 역할 | 할 수 있는 것 | 할 수 없는 것 | |------|------|------| | Owner (소유자) | 모든 리소스 관리 + 역할 할당 | Entra 계정으로 데이터 영역 접근 (데이터 역할 별도) | | Contributor (기여자) | 모든 리소스 관리 | 역할 할당, Blueprints 할당 관리, 이미지 갤러리 공유 | | Reader (읽기 권한자) | 모든 리소스 보기 | 변경 | | User Access Administrator (사용자 액세스 관리자) | 사용자 액세스 관리 (역할 할당) | 리소스 자체를 만들거나 수정 | | Role Based Access Control Administrator | Azure RBAC로 역할 할당, 조건으로 할당 범위 제한 가능 | Azure Policy 등 다른 방식의 액세스 관리 | | Virtual Machine Contributor | VM 생성·관리, 디스크 관리 | VM이 연결된 VNet·스토리지 계정 관리, 역할 할당 | | Network Contributor | 네트워크 관리 | VM 배포·관리 | | Storage Account Contributor | 스토리지 계정 관리 + 계정 키 접근 | 역할 할당 | | Storage Blob Data Contributor | 컨테이너와 Blob 읽기·쓰기·삭제 | 스토리지 계정 설정 관리 | | Tag Contributor | 태그 관리 | 리소스 자체에 접근 |
관리 영역과 데이터 영역
역할의 권한은 두 칸으로 나뉩니다. Actions는 리소스를 만들고 설정을 바꾸는 관리 영역(control plane) 작업이고, DataActions는 Blob 내용을 읽고 쓰는 것 같은 데이터 영역(data plane) 작업입니다. Owner와 Contributor는 Actions에 와일드카드(*)가 있지만 DataActions는 비어 있어서, Microsoft Entra 계정으로 Blob 데이터를 읽는 권한은 따로 받아야 합니다.
함정이 하나 있습니다. Contributor와 Storage Account Contributor에는 계정 키를 조회하는 작업(listkeys)이 들어 있어서, 포털은 이 권한이 있으면 계정 키로 Blob 데이터를 보여 줍니다. 반대로 데이터 역할만 있고 Reader 이상의 관리 영역 역할이 없으면 포털에서 스토리지 계정까지 찾아 들어갈 수 없습니다.
시험 팁: "포털에서 Microsoft Entra 계정으로 Blob을 읽기만 하게"는 스토리지 계정 범위의 Reader + Storage Blob Data Reader 조합입니다. Storage Blob Data Reader 하나만으로는 포털 탐색이 안 됩니다.
---
범위와 상속: 위에서 준 권한은 아래로 흐른다
건물 마스터키를 받은 사람은 모든 층의 모든 방에 들어갈 수 있습니다. Azure도 상위 범위에서 받은 역할이 하위 범위로 그대로 상속됩니다. 범위는 넓은 쪽부터 관리 그룹 → 구독 → 리소스 그룹 → 리소스의 네 단계입니다.
상속과 함께 기억할 원칙은 "Azure RBAC는 더하기 모델"이라는 점입니다. 한 사람에게 여러 역할 할당이 겹치면 실제 권한은 모든 할당의 합입니다. 그래서 아래 범위에 낮은 역할을 주어도 위에서 받은 높은 권한은 줄어들지 않습니다.
| 상황 | 실제 권한 | |------|------| | 구독에 Contributor, RG1에 Reader | RG1에서도 Contributor (합산) | | RG1에 Contributor, VM1에 Reader | VM1에서도 Contributor (상속 + 합산) | | 그룹에 RG1 Contributor, 본인에게 구독 Reader | RG1은 관리, 나머지 리소스 그룹은 보기만 | | RG1에 Owner | RG1 안에서 다른 사람에게 역할 할당 가능, RG2에는 권한 없음 |
시험 팁: "RG2의 VM만 관리하고 다른 곳은 건드리지 못하게"처럼 범위를 좁히라는 요구에는 구독이 아니라 RG2 범위에 Virtual Machine Contributor를 주는 보기를 고르세요. 이미 구독 범위에 높은 역할이 있다면 그 할당을 지우지 않는 한 권한은 줄어들지 않습니다.
---
권한을 빼는 두 가지 방법: NotActions와 거부 할당
이름은 비슷하지만 동작이 완전히 다른 두 가지 "빼기"가 있습니다. 시험은 이 둘을 섞어서 함정을 만듭니다.
| 구분 | NotActions | 거부 할당 (deny assignment) | |------|------|------| | 위치 | 역할 정의 안 | 역할 할당과 같은 수준의 별도 개체 | | 의미 | Actions의 와일드카드에서 일부 작업을 덜어낸 목록 | 지정한 작업을 명시적으로 차단 | | 다른 역할이 같은 작업을 허용하면 | 허용됨 (거부 규칙이 아님) | 그래도 차단됨 | | 만드는 주체 | 사용자 지정 역할을 만드는 관리자 | Azure가 만들고 관리 (직접 생성 불가) | | 예 | Contributor의 역할 할당 작업 제외 | 관리되는 애플리케이션, 배포 스택의 삭제 방지 |
Azure Resource Manager가 요청을 평가하는 순서도 알아 두면 표 문제를 빨리 풀 수 있습니다.
요청한 작업에 적용되는 역할 할당과 거부 할당을 모두 가져옴 거부 할당이 적용되면 즉시 차단 역할 할당의 합에 그 작업이 없으면 차단 역할 할당에 조건이 붙어 있으면 조건을 평가한 뒤 허용 여부 결정
시험 팁: "사용자 지정 역할의 NotActions에 삭제 작업을 넣었는데 사용자가 여전히 삭제할 수 있다"는 다른 역할 할당이 삭제를 허용하고 있기 때문입니다. 특정 리소스의 삭제 자체를 막으려면 리소스 잠금(CanNotDelete)을 고려하세요.
---
Entra 역할과 Azure 역할은 다른 세계
같은 "관리자"라도 관리하는 대상이 다릅니다. 회사 인사팀은 직원 명부를 관리하고, 시설팀은 건물과 장비를 관리합니다. 인사팀장이라고 해서 서버실 열쇠가 자동으로 생기지는 않습니다.
| 구분 | Microsoft Entra 역할 | Azure 역할 (Azure RBAC) | |------|------|------| | 관리 대상 | 사용자, 그룹, 라이선스, 도메인 같은 디렉터리 개체 | VM, 스토리지, VNet 같은 Azure 리소스 | | 대표 역할 | Global Administrator, User Administrator, Billing Administrator | Owner, Contributor, Reader, User Access Administrator | | 할당 범위 | 테넌트 전체 또는 관리 단위 | 관리 그룹, 구독, 리소스 그룹, 리소스 | | 할당 위치 | Entra 관리 센터의 역할 및 관리자 | 각 범위의 액세스 제어(IAM) |
두 세계는 기본적으로 서로의 권한을 넘지 않습니다. 예외는 Global Administrator의 액세스 권한 상승입니다. Entra ID 속성에서 "Azure 리소스에 대한 액세스 관리"를 예로 바꾸면, 그 사람에게 루트 범위(/)의 User Access Administrator가 할당되어 테넌트의 모든 구독과 관리 그룹에 역할을 할당할 수 있게 됩니다. 필요한 작업이 끝나면 다시 아니요로 돌려 놓아야 합니다.
예전 자료에 나오는 Account Administrator, Service Administrator, Co-Administrator 같은 클래식 구독 관리자 역할은 2024년 8월 31일에 사용 중지되었습니다. 지금은 Azure RBAC의 Owner 역할로 같은 일을 합니다.
시험 팁: "새 사용자를 만들고 암호를 재설정할 수 있어야 한다"는 Entra 역할(User Administrator), "구독의 리소스를 관리"는 Azure 역할입니다. "Global Administrator가 구독에 접근하지 못한다"는 문제에는 액세스 권한 상승이 답입니다.
---
IAM 화면에서 실제 권한 확인하기
역할 할당이 여러 범위에 흩어져 있으면 머릿속으로 합산하기 어렵습니다. 이럴 때 쓰는 것이 각 리소스의 액세스 제어(IAM) 화면입니다.
| 기능 | 위치 | 보여 주는 것 | |------|------|------| | 액세스 확인 (Check access) | IAM → 액세스 확인 탭 | 선택한 사용자·그룹·서비스 주체의 역할 할당과 거부 할당 | | 내 액세스 보기 (View my access) | IAM → 액세스 확인 탭 | 내 역할 할당, 자격이 있는(eligible) 할당 | | 역할 할당 탭 | IAM → 역할 할당 | 이 범위의 모든 할당, 범위 열에 "이 리소스" 또는 "(상속됨)" 표시 | | 사용자의 Azure 역할 할당 | Entra ID → 사용자 → Azure 역할 할당 | 한 사용자가 여러 범위에서 받은 역할 목록 |
액세스 확인은 지금 연 범위와 그 위에서 상속된 할당만 보여 주고, 아래 범위의 할당은 보여 주지 않습니다. 구독에서 액세스 확인을 하면 리소스 그룹 하나에만 준 역할은 나오지 않는다는 뜻입니다.
표 문제 풀어 보기
시험에 자주 나오는 형식으로 연습해 보겠습니다. User1은 Group1의 멤버이고, VM1은 RG1에, VM2는 RG2에 있습니다.
| 보안 주체 | 역할 | 범위 | |------|------|------| | Group1 | Virtual Machine Contributor | RG1 | | User1 | Reader | 구독 | | User2 | User Access Administrator | 구독 |
User1은 VM1을 다시 시작할 수 있음 (그룹 할당 + RG1 범위) User1은 VM2를 볼 수만 있음 (구독 Reader 상속) User1은 VM1이 연결된 VNet의 설정을 바꿀 수 없음 (VM Contributor는 VNet 관리 불가) User2는 VM을 시작할 수 없지만, 자신에게 Contributor를 할당한 뒤에는 가능 (역할 할당 권한)
시험 팁: 표 문제는 "누가 어느 그룹에 속하나 → 그 범위는 어디까지 내려가나 → 그 역할에 이 작업이 있나" 순서로 확인하세요. 마지막 단계에서 역할의 "할 수 없는 것"이 결정적인 단서가 됩니다.
---
역할 할당 위임과 사용자 지정 역할
역할을 할당할 수 있는 기본 제공 역할은 Owner, User Access Administrator, Role Based Access Control Administrator입니다. Microsoft는 Owner나 User Access Administrator를 넓게 나눠 주기보다, Role Based Access Control Administrator에 조건을 붙여 "어떤 역할을, 누구에게 할당할 수 있는지"를 제한하는 방식을 더 안전한 방법으로 안내합니다.
기본 제공 역할로 요구 사항이 맞지 않으면 사용자 지정 역할을 만듭니다.
| 속성 | 의미 | |------|------| | Actions | 허용할 관리 영역 작업 | | NotActions | Actions에서 덜어낼 관리 영역 작업 | | DataActions | 허용할 데이터 영역 작업 | | NotDataActions | DataActions에서 덜어낼 데이터 영역 작업 | | AssignableScopes | 이 역할을 할당할 수 있는 범위 |
사용자 지정 역할은 테넌트당 최대 5,000개 같은 테넌트를 신뢰하는 구독끼리 공유 가능 DataActions가 들어 있는 사용자 지정 역할은 관리 그룹 범위에 할당할 수 없음 기존 역할을 복제해서 시작하면 작업 이름을 일일이 찾지 않아도 됨