Azure를 사용하다 보면 헷갈리는 개념 중 하나가 바로 Entra Role과 Azure Role이다. 둘 다 역할(Role)이라는 단어가 들어가 있어서 같은 것처럼 보이기도 하고, 두 개념 모두 RBAC을 사용하지만 적용 대상과 기능이 다르다. 이번 글에서는 이 두 개념의 차이를 쉽게 설명하고, 실제로 어떻게 사용되는지 예시를 들어 보겠다. 쉽게 말해, Entra Role은 '누가 로그인할 수 있는지'를 결정하고, Azure Role은 '로그인한 사람이 무엇을 할 수 있는지'를 결정한다.
RBAC
Role들을 먼저 설명하기 전에, RBAC이라는 개념을 먼저 간단히 살펴보자. RBAC은 아주 간단한 개념인데, Role-Based Access Control, 즉 사용자의 역할(Role)에 따라 시스템이나 리소스에 대한 접근 권한을 부여하는 방식이다. "이 사용자는 어떤 역할을 가지고 있으며, 그 역할이 어떤 권한을 가지는가?"라는 개념에 기반한다.
RBAC의 개념 전에 DAC, MAC의 개념이 있고 다른 방식의 ABAC도 있지만 여기선 설명하진 않는다. 일단 핵심은, Entra Role과 Azure Role에서도 RBAC를 사용하여 사용자가 수행할 수 있는 작업을 제한한다는 것이다.
Entra Role이란?
Entra Role은 Microsoft Entra의 리소스에 대한 접근 권한을 관리하는 역할이다.
이전 글에서 회사에 들어갈 때 사원증이 필요하다고 예시를 들었었다. 출입증을 가진 사람만 건물에 들어갈 수 있다는 전제는 같아도 방문객은 허가받은 공간만, 일반 직원은 사무실까지, IT 관리자는 서버실까지 출입할 수 있는 것처럼 출입증의 종류에 따라 들어갈 수 있는 구역이 다를 수도 있다. 또 누군가는 같은 직원이어도 다른 사람에게 너는 직원, 너는 IT관리자라는 권한을 부여할 수 있고 방문객에게 방문증을 발급하는 사람도 있을 것이다.
이 개념에서도 마찬가지다. Entra Role은 사용자가 Microsoft 365, Azure Portal 등 MS 앱에 로그인할 수 있도록 해 주는 역할을 한다. 즉, "이 사람이 Azure(또는 다른 MS 앱)에 접근할 수 있는가? 접근할 수 있다면, 접근해서 뭘 할 수 있는가?"를 결정하는 것이 Entra Role의 역할이다.
그래서 Entra Role을 검색하면 이런 그림이 나온다.

Entra-specific role, Cross-service role, Service-specific role 등이 보이는데, Entra ID라는 서비스 자체가 AWS IAM과 같이 Azure에 종속된 하위 서비스가 아니라 다른 MS 앱의 사용자 인증을 관리하기 때문에 다른 서비스와의 관계에 따라 정의되는 역할이 있는 것이다.
Entra role 중에서는 대표적으로 아래와 같은 역할이 있다.
- Microsoft Entra 기본 제공 역할
https://learn.microsoft.com/ko-kr/entra/identity/role-based-access-control/permissions-reference
역할 | 설명 |
Global administrator (전역 관리자) | Microsoft Entra ID 및 Entra ID를 사용하는 Microsoft 서비스에 대한 관리 |
User administrator (사용자 관리자) | 사용자 및 그룹 관리, 비밀번호 재설정 등 |
Security administrator (보안 관리자) | 보안 정책 및 MFA 설정 관리 |
Global reader (전역 독자) | Global administrator가 관리하는 것과 같은 범위를 조회 가능, 편집 불가 |
그리고 Entra Role은 RBAC 기반으로 작동한다고 설명했다. 아래 그림은 ① Alex가 ② App Registration Administrator이라는 Custom 역할을 ③ Contoso Widget Builder 앱 등록 범위에서 할당받았을 때를 설명하는데, 이 할당은 Alex에게 특정한 앱 등록에 대해서 App Registration Administrator 역할만 수행할 수 있다는 뜻이다.

Azure Role이란?
Entra Role은 조직의 ID, MS 앱 수준의 권한 등을 관리하는 역할이다. 하지만, 사용자가 VM이나 Storage 같은 Azure 리소스에 접근할 수 있는지는 따로 관리해야 한다. 그것이 바로 Azure Role이다.
똑같이 회사의 예시를 들어보자. 신입사원이라 사원증을 새로 발급받고 사옥에 들어왔다고 해서 사옥 내에 있는 모든 자원에 내가 손을 댈 수 있는 건 아니다. 3층의 개발자는 VM을 만들고 사용할 수 있고, 4층의 네트워크 관리자는 방화벽 정책을 변경할 수 있다. 그리고 10층의 재무 담당자는 비용 관리 시스템에 접근할 수 있을 것이다. 하지만 개발자가 방화벽 정책을 변경하거나, 재무 담당자가 VM을 삭제할 순 없을 것이다.
바로 Azure Role에 뭐가 있는지 알아보자..,,
- Microsoft Entra 기본 제공 역할
https://learn.microsoft.com/ko-kr/azure/role-based-access-control/built-in-roles
역할 | 설명 |
Owner (소유자) | 모든 리소스를 관리할 수 있는 모든 권한 O Azure RBAC에서 역할 할당 권한 O |
Contributor (기여자) | 모든 리소스를 관리할 수 있는 모든 권한 O Azure RBAC에서 역할 할당 권한 X |
Reader (독자) | 리소스 조회 O 리소스 편집 X |
RBAC administrator (RBAC 관리자) | Azure RBAC의 역할 정의/설정 편집 O 사용자에 대한 권한을 직접 할당/제거 X |
User Access Administrator (사용자 액세스 관리자) | 사용자에게 특정 역할을 부여/철회 O |
그리고 똑같이 RBAC 기반이다. Scope를 보면 Entra Role과 다른 점이 보일 것이다.
추가로, 이젠 지원되지 않는 클래식 구독 관리자라는 역할이 3개 있는데, 링크로 대신한다: https://learn.microsoft.com/ko-kr/azure/role-based-access-control/rbac-and-directory-admin-roles#classic-subscription-administrator-roles
Azure 역할, Microsoft Entra 역할 및 클래식 구독 관리자 역할
Azure의 다양한 역할(Azure 역할, Microsoft Entra 역할, 클래식 구독 관리자 역할)을 설명합니다.
learn.microsoft.com
Entra Role vs. Azure Role
둘 다 RBAC의 개념을 따르지만, 적용되는 대상이 다르다.
비교 항목 | Entra Role | Azure Role |
적용 대상 | MS Entra Resource, Microsoft 365 등 | Azure 리소스 (VM, 스토리지, 네트워크 등) |
역할 종류 | Global Admin, User Admin 등 | Owner, Contributor, Reader 등 |
권한 유형 | 로그인 및 ID 관리 관련 | Azure 리소스 관리 관련 |
예시 | "이 사용자가 Azure Portal에 로그인할 수 있는가?" | "이 사용자가 가상 머신을 만들고 삭제할 수 있는가?" |
Azure Role (범위): Scope과 상속
Entra Role과 Azure Role의 개념을 알아봤다. 여기서부터는 Azure Role의 특징을 설명하려 한다. 먼저 권한의 상속이라는 개념이다. 위에서 RBAC을 정의하려면 주체, 역할과 범위가 설정되어야 한다고 했다. 주제도, 역할도 대충알겠는데, 범위는 뭘까?
Azure의 범위(Scope)는 크게 4개로 분류된다. Azure RBAC의 그림에서 볼 수 있는 Scope과 같은 그림이다. Azure 에서는 관리 그룹(Management group), 구독(Subscription), 리소스 그룹(Resource group), 리소스(Resource)의 4개 수준에서 범위를 지정할 수 있고, 보다시피 계층구조로 되어 있다.
그림에 대한 추가 설명을 조금 덧붙이자면, 리소스는 리소스 그룹으로 묶이고, 리소스 그룹은 구독 아래에 존재한다. 또 구독은 관리 그룹에 속한다. 그리고 관리그룹은 또 다른 관리그룹을 포함할 수 있다. 아래 구조처럼 말이다.
아무튼, 다시 본론으로 돌아가서 Azure는 4개 범위가 계층적으로 구성된다는 점까지 알았다. 이는 즉, 권한이 상속된다는 개념으로 이어진다. 구독의 범위는 곧 해당 구독과 그 구독에 속한 리소스 그룹, 리소스까지 포함된다는 뜻이다.
Azure Portal 웹이 아니라 CLI로 사용자 권한을 관리해야 한다고 가정했을 때, RBAC 정의 중 '범위'를 적을 때 이런 문법을 쓴다. 특정할 구독의 ID, 리소스 그룹의 이름, 리소스명을 계층적으로 명시해야 한다.
# 구독 포함 하위 수준
/subscriptions
/{subscriptionId}
/resourcegroups
/{resourceGroupName}
/providers
/{providerName}
/{resourceType}
/{resourceSubType1}
/{resourceSubType2}
/{resourceName}
# 구독 상위 수준
/providers
/Microsoft.Management
/managementGroups
/{managementGroupName}
범위 | 예시 |
관리 그룹 | /providers/Microsoft.Management/managementGroups/marketing-group |
구독 | /subscriptions/00000000-0000-0000-0000-000000000000 |
리소스 그룹 | /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/Example-Storage-rg |
/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/pharma-sales | |
리소스 | /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/Example-Storage-rg/providers/Microsoft.Storage/storageAccounts/azurestorage12345/blobServices/default/containers/blob-container-01 |
/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/MyVirtualNetworkResourceGroup/providers/Microsoft.Network/virtualNetworks/MyVirtualNetwork12345 |
폴더 경로를 삭제하면 해당 폴더 안에 있는 파일도 다 삭제된다는 느낌을 주려고 이렇게 표현해봤다. 그림으로 보면 이렇다.
pharma-sales 리소스 그룹에 속한 Marketing group에 Contributor 역할을 할당하면, 해당 그룹에 속한 사용자도 Contributor 역할을 할당받는다.
이전에 Reader는 리소스 조회, Contributor는 편집까지 가능한 Azure Role이라고 소개했다. 즉, Contributor가 더 큰 권한을 가진다. 사용자에게 구독 단위의 Contributor 권한을 할당하고 그 구독에 속한 리소스 그룹에 Reader 역할을 할당했을 때, 리소스 그룹은 구독에 속했으므로 Contributor 권한이 상속되고, Reader보다 더 큰 권한이기에 결국 Reader는 하나마나 한 할당인 것이다.
+ Entra Role은 권한 상속의 개념이 없나? 없다! Entra Role은 테넌트 수준에서 관리되기 때문에 하위 리소스의 개념이 존재하지 않는다. 반면 Azure Role은 관리 그룹 > 구독 > 리소스 그룹 > 리소스와 같이 계층 구조를 가지기 때문에 상위 계층에서 부여한 권한이 하위 리소스로 상속되는 개념이 있는 것이다.
Azure Role (역할): 데이터 권한의 분리
Azure RBAC의 중요한 특징 중 하나는 리소스에 대한 관리 권한과 리소스 내부 데이터에 대한 접근 권한이 분리되어 있다는 점이다. 왜 굳이 분리할까? 리소스를 관리할 수 있다고 해서 내부 데이터를 조작할 필요는 없기 때문이다.
예를 들어 가상 머신을 관리하는 사람이 반드시 그 VM 내부 데이터를 읽을 필요가 없고, 스토리지를 운영하는 사람이 모든 데이터에 접근할 필요는 없는 것과 같다.
위 그림에서 Alice는 구독 단위의 소유자다. 즉 구독을 포함해 하위 레벨의 읽기는 물론 편집이 가능하다. Bob은 Storage Blob Data Contributor라는 권한을 가졌다. 대충 어떤 데이터들이 저장되어 있는 저장소의 기여자라고 이해하면 된다. 이 내용을 CLI에서의 표현법처럼 나타내면 다음과 같다.
Alice:
actions
*
Bob:
actions
Microsoft.Storage/storageAccounts/blobServices/containers/delete
Microsoft.Storage/storageAccounts/blobServices/containers/read
Microsoft.Storage/storageAccounts/blobServices/containers/write
Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey/action
DataActions
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/move/action
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action
Alice한테는 구독 단위의 와일드카드(*) actions가 있기 때문에 구독 내에서 모든 작업을 수행할 수 있다. Alice는 컨테이너를 읽고 쓰며 삭제할 수 있지만, 데이터를 삭제할 수는 없다. 즉, Alice는 기본적으로 스토리지 내부의 데이터에 대한 권한은 없다. 데이터를 읽으려면 actions가 아닌 DataActions가 필요하다.
Bob의 권한은 Blob Data Contributor 역할에 지정된 Actions 및 DataActions로만 제한된다. Bob은 역할에 따라 지정된 스토리지 내 데이터를 읽고, 쓰고, 삭제할 수 있다.
이 actions, DataActions 말고도 정의할 수 있는 역할이 몇 가지 더 있는데, 기본적으로 actions에서 NotActions를 제외한 것이 설정된다고 생각하면 된다: https://learn.microsoft.com/ko-kr/azure/role-based-access-control/role-definitions
Azure 역할 정의 이해 - Azure RBAC
Azure 리소스의 세분화된 액세스 관리에 사용되는 Azure RBAC(Azure 역할 기반 액세스 제어)의 Azure 역할 정의에 대해 알아봅니다.
learn.microsoft.com
Entra ID와 Entra Role, Azure Role를 설명했고 Azure Role을 정의할 때 있어서 범위와 역할을 설정할 때의 특징도 소개했다. 다음 글에서는 주체를 설정할 때 알면 좋은 개념으로 Service Principal과 Managed Identity를 알아보자.
REF.
https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/custom-overview
https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference
https://learn.microsoft.com/en-us/azure/role-based-access-control/overview
https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles
'Azure Security' 카테고리의 다른 글
Azure Computing (1) AKS와 ACR (0) | 2025.04.04 |
---|---|
Azure Networking (1) VNet, NSG와 Default Outbound Access (0) | 2025.04.04 |
Azure IAM (3) Service Principal와 Managed Identity (0) | 2025.04.04 |
Azure IAM (1) Microsoft Entra ID (0) | 2025.04.04 |
☁🎈 Azure Cloud 개념 정리 (0) | 2025.04.03 |