[Azure] Entra ID, RBAC, Managed Identity 정리

Azure 권한은 세 가지로 나눠 보면 쉽습니다. Entra ID는 "누구인지"를 관리하는 신원 서비스이고, RBAC은 그 대상이 "어디에서 무엇을 할 수 있는지"를 정하는 권한 체계이며, Managed Identity는 사람이 아닌 Azure 리소스에 붙여 주는 신분증입니다. 권한은 Security Principal, Role, Scope 세 가지를 묶은 Role Assignment로 부여하고, 위 Scope에서 준 권한은 아래로 상속됩니다.

1. 한눈에 보기

회사 건물로 비유하면 Entra ID는 사원증을 발급하는 인사팀, RBAC은 "이 사원증으로 몇 층 어느 방까지 들어갈 수 있는지"를 정하는 출입 권한, Managed Identity는 사람이 아니라 업무용 차량에 붙여 주는 출입증입니다. 사원증이 있어도 출입 권한이 없으면 문이 열리지 않듯, Entra ID에 계정이 있어도 RBAC 권한이 없으면 Azure 리소스를 볼 수 없습니다.

 

구분	역할	비유
Entra ID	사용자, 그룹, 앱의 신원을 만들고 로그인을 처리	사원증 발급
RBAC	신원에 Role을 Scope 단위로 부여	층·방별 출입 권한
Managed Identity	Azure 리소스가 비밀번호 없이 쓰는 신원	업무용 차량 출입증

 

Entra ID의 Security Principal이 Role Assignment를 통해 Scope 안의 Azure 리소스에 접근하는 구조

2. Entra ID

Entra ID는 Azure와 Microsoft 365가 함께 쓰는 ID 서비스로, 예전 이름은 Azure Active Directory입니다. 회사 하나가 디렉터리 하나를 갖는데 이것을 Tenant라고 부르고, Subscription은 반드시 Tenant 하나를 신뢰하도록 연결됩니다. 그래서 Subscription에 로그인한다는 말은 사실 그 Subscription이 연결된 Tenant의 계정으로 로그인한다는 뜻입니다.

 

Azure에서 권한을 받을 수 있는 대상을 Security Principal이라고 하고, 네 종류가 있습니다.

 

타입	대상	예시
User	사람 계정	운영자, 개발자
Group	User를 묶은 단위	인프라팀, 개발팀
Service Principal	앱이나 자동화 도구의 계정	CI/CD 파이프라인, 외부 SaaS
Managed Identity	Azure 리소스의 계정	VM, AKS, App Service

 

앱을 등록할 때 헷갈리는 부분이 App Registration과 Service Principal의 관계입니다. App Registration은 앱의 설계도(Application Object)로, 앱을 등록한 Tenant에 하나만 있습니다. Service Principal은 그 설계도로 각 Tenant 안에 실제로 만들어진 계정이라, 여러 회사가 쓰는 앱은 설계도 하나에 회사마다 Service Principal이 하나씩 생깁니다. 포털의 Enterprise Applications 메뉴에서 보이는 것이 Service Principal이고, 권한은 설계도가 아니라 이 Service Principal에 줍니다.

3. RBAC

3.1 Role Assignment의 세 요소

RBAC(Role-Based Access Control, 역할 기반 접근 제어)은 권한을 사람에게 하나씩 주지 않고 Role이라는 권한 묶음으로 줍니다. 권한 하나를 주는 단위를 Role Assignment라고 하고, 항상 세 가지를 함께 정합니다.

 

요소	의미	예시
Security Principal	누구에게	인프라팀 Group
Role Definition	어떤 권한 묶음을	Contributor
Scope	어디에	rg-prod Resource Group

 

Scope는 Management Group, Subscription, Resource Group, Resource 네 단계이고, 위에서 준 권한은 아래로 그대로 상속됩니다. 건물 출입증으로 치면 "3층 전체" 권한을 받으면 3층의 모든 방에 들어갈 수 있는 것과 같습니다. 그래서 Subscription에 Reader를 주면 그 아래 모든 Resource Group과 Resource를 볼 수 있습니다.

 

Management Group에서 Resource까지 이어지는 Scope 계층과, 위에서 부여한 Role이 아래로 상속되는 방향

 

여러 Role Assignment가 겹치면 권한이 더해집니다. Subscription에서 Reader, 그 아래 rg-prod에서 Contributor를 받았다면 rg-prod에서는 Contributor로 동작합니다. 반대로 위에서 준 권한을 아래에서 빼는 방법은 없어서, 넓은 Scope에 큰 권한을 주는 것은 신중해야 합니다. 예외로 Deny Assignment가 있는데, Role Assignment보다 먼저 검사해서 해당하면 무조건 막습니다. Deny Assignment는 직접 만들 수 없고 Deployment Stacks나 Managed Application 같은 Azure 서비스가 리소스를 보호할 때 만듭니다.

3.2 기본 Role

Built-in Role은 수백 개지만 먼저 알아야 할 것은 다섯 개입니다.

 

Role	리소스 관리	권한 부여	용도
Owner	가능	가능	Subscription 관리자
Contributor	가능	불가	운영자, 배포 파이프라인
Reader	조회만	불가	감사, 모니터링
User Access Administrator	불가	가능(Owner 포함)	권한 관리 담당
Role Based Access Control Administrator	불가	가능(조건 지정)	부여할 수 있는 Role을 제한한 권한 관리

 

Role Based Access Control Administrator는 Condition을 붙여 "Storage Blob Data Reader만 부여할 수 있다"처럼 줄 수 있는 Role을 제한할 수 있습니다. 팀장에게 팀원 권한 관리를 맡기되 Owner를 마음대로 나눠 주지 못하게 할 때 User Access Administrator 대신 씁니다.

3.3 Actions와 DataActions

Role 안의 권한은 두 종류입니다. Actions는 리소스 자체를 관리하는 권한(Control Plane)이고, DataActions는 리소스 안의 데이터를 다루는 권한(Data Plane)입니다. 창고로 비유하면 Actions는 창고를 짓고 자물쇠를 바꾸는 권한, DataActions는 창고 안의 물건을 꺼내는 권한입니다.

 

같은 Storage Account라도 관리 요청은 Actions, Blob 읽기·쓰기 요청은 DataActions로 따로 검사한다

 

실무에서 가장 많이 막히는 부분이 여기입니다. Owner나 Contributor에는 DataActions가 없어서, Storage Account를 만든 사람도 Entra ID 인증으로는 Blob 내용을 읽지 못합니다. 데이터에 접근하려면 데이터용 Role을 따로 줘야 합니다. Contributor가 Blob을 읽을 수 있는 것처럼 보이는 경우는 Contributor에 포함된 "Access Key 조회" 권한으로 키를 가져와 읽는 것이라, Access Key를 끄면 바로 막힙니다.

 

서비스	관리 Role	데이터 Role
Storage Blob	Storage Account Contributor	Storage Blob Data Reader, Storage Blob Data Contributor
Key Vault	Key Vault Contributor	Key Vault Secrets User, Key Vault Secrets Officer
Container Registry	Contributor	AcrPull, AcrPush

4. Entra Role과 Azure Role의 차이

Role이라는 이름이 같아서 헷갈리지만 관리하는 대상이 다릅니다. Entra Role은 사용자, 그룹, 앱 같은 디렉터리를 관리하는 권한이고, Azure Role은 VM, Storage 같은 Azure 리소스를 관리하는 권한입니다. 건물로 치면 Entra Role은 인사팀 권한(사원증 발급, 퇴사 처리), Azure Role은 시설팀 권한(각 층 설비 관리)입니다.

 

항목	Entra Role	Azure Role
관리 대상	User, Group, 앱, 도메인	VM, Storage, VNet 등 Azure 리소스
Scope	Tenant 전체, Administrative Unit	Management Group, Subscription, Resource Group, Resource
대표 Role	Global Administrator, User Administrator	Owner, Contributor, Reader
관리 화면	Entra admin center	Azure Portal의 Access control(IAM)

 

Entra Role은 디렉터리를, Azure Role은 리소스를 관리하며 Global Administrator는 Elevate Access로 Azure 권한을 얻는다

 

그래서 Global Administrator라도 Azure 리소스 권한이 자동으로 생기지는 않습니다. 퇴사자가 Owner를 갖고 있던 Subscription처럼 아무도 권한을 줄 수 없는 상황에서는, Global Administrator가 Entra ID 속성의 "Access management for Azure resources"를 켜서 루트 Scope(/)의 User Access Administrator를 받은 뒤 권한을 다시 나눠 줍니다. 작업이 끝나면 바로 꺼야 합니다. 예전 Classic 관리자 역할(Account Administrator, Service Administrator, Co-Administrator)은 종료되어 지금은 Azure RBAC만 씁니다.

5. Managed Identity

5.1 동작 방식

VM이나 AKS가 Storage, Key Vault에 접근하려면 원래는 Access Key나 Service Principal의 Secret을 코드나 설정 파일에 넣어야 했습니다. 이 비밀 값은 유출되기 쉽고 만료되면 서비스가 멈춥니다. Managed Identity를 켜면 Azure가 리소스용 Service Principal을 만들고 인증서까지 자동으로 교체해 주므로, 코드에는 비밀 값이 하나도 남지 않습니다. 추가 비용도 없습니다.

 

VM 안의 코드는 VM 안에서만 접근되는 IMDS(Instance Metadata Service, VM 메타데이터 서비스) 주소 169.254.169.254에 토큰을 요청합니다. IMDS가 대신 Entra ID에서 Access Token을 받아 돌려주고, 코드는 이 토큰을 들고 Storage에 요청합니다. Storage는 토큰의 신원에 RBAC Role이 있는지 확인한 뒤 응답합니다. 차량 출입증이 차 안에 붙어 있어서 운전자가 따로 비밀번호를 외울 필요가 없는 것과 같습니다.

 

VM 안의 코드가 IMDS를 통해 Entra ID에서 토큰을 받고, 그 토큰으로 Storage Account에 접근하는 순서

5.2 System-assigned와 User-assigned

Managed Identity는 두 종류입니다. System-assigned는 리소스에 딱 붙은 신원이라 리소스를 지우면 함께 사라지고, User-assigned는 독립된 리소스로 따로 만들어 여러 리소스에 붙일 수 있습니다. System-assigned가 개인 명의 사원증이라면 User-assigned는 팀 공용 출입증입니다.

 

항목	System-assigned	User-assigned
생성	리소스에서 켜면 함께 생성	별도 리소스로 생성
수명	리소스를 지우면 함께 삭제	직접 삭제할 때까지 유지
공유	리소스 1개 전용	여러 리소스가 같이 사용
권한 부여 시점	리소스를 만든 뒤	리소스를 만들기 전에 미리
적합한 대상	VM 1대의 앱	VMSS, AKS, 자주 다시 만드는 리소스

 

System-assigned는 리소스마다 따로 생기고 함께 삭제되며, User-assigned는 하나를 만들어 여러 리소스가 같이 쓴다

 

Microsoft는 User-assigned를 권장합니다. 리소스를 지우고 다시 만들어도 신원이 그대로라 RBAC Role을 다시 줄 필요가 없고, 권한을 미리 준비해 둔 뒤 리소스를 배포할 수 있기 때문입니다. 대표적인 예가 AKS입니다. AKS 노드의 kubelet은 User-assigned Managed Identity로 동작하고, az aks update --attach-acr를 실행하면 이 신원에 Container Registry의 AcrPull Role이 부여되어 이미지를 비밀번호 없이 가져옵니다(AKS 구성은 Azure Kubernetes Service 구성 정리에서 다뤘습니다).

6. 직접 해 보기

6.1 Managed Identity 만들고 권한 주기

VM이 Storage Account의 Blob을 비밀번호 없이 읽도록 User-assigned Managed Identity를 만들고, Storage Account 범위에 Storage Blob Data Reader를 줍니다.

RG=rg-identity
ID_NAME=id-app01
VM_NAME=vm-app01
SA_NAME=stapp01

# User-assigned Managed Identity 생성
az identity create --resource-group $RG --name $ID_NAME

PRINCIPAL_ID=$(az identity show -g $RG -n $ID_NAME --query principalId -o tsv)
CLIENT_ID=$(az identity show -g $RG -n $ID_NAME --query clientId -o tsv)
ID_RES=$(az identity show -g $RG -n $ID_NAME --query id -o tsv)

# VM에 연결
az vm identity assign --resource-group $RG --name $VM_NAME --identities $ID_RES

# Storage Account 범위로 Blob 읽기 권한 부여
SA_ID=$(az storage account show -g $RG -n $SA_NAME --query id -o tsv)
az role assignment create --assignee-object-id $PRINCIPAL_ID \
  --assignee-principal-type ServicePrincipal \
  --role "Storage Blob Data Reader" --scope $SA_ID

# 받은 권한 확인
az role assignment list --assignee $PRINCIPAL_ID --all -o table

Role Assignment는 반영까지 몇 분 걸릴 수 있습니다. 바로 403이 나오면 잠시 기다린 뒤 다시 시도합니다.

6.2 VM 안에서 토큰 받아 Blob 읽기

VM에 접속해 IMDS에서 Storage용 토큰을 받고, 그 토큰으로 Blob을 읽습니다. User-assigned가 여러 개 붙어 있을 수 있어서 client_id로 어떤 신원을 쓸지 지정합니다.

CLIENT_ID=<위에서 확인한 clientId>

# IMDS에서 Storage용 Access Token 받기
TOKEN=$(curl -s -H Metadata:true \
  "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01\
&resource=https://storage.azure.com/&client_id=$CLIENT_ID" | jq -r .access_token)

# 토큰으로 Blob 읽기 (Bearer 토큰은 x-ms-version 헤더가 필요)
curl -s -H "Authorization: Bearer $TOKEN" -H "x-ms-version: 2020-04-08" \
  "https://stapp01.blob.core.windows.net/data/hello.txt"

토큰 문자열을 jwt.ms 같은 디코더에 넣어 보면 oid 값이 Managed Identity의 principalId와 같은 것을 확인할 수 있습니다. 애플리케이션 코드에서는 이 과정을 직접 구현하지 않고 Azure SDK의 DefaultAzureCredential(또는 ManagedIdentityCredential)을 쓰면 SDK가 IMDS 호출과 토큰 갱신을 대신 처리합니다.

7. 운영 시 주의점

항목	조치
최소 권한	Owner·Contributor 대신 필요한 Role을 가장 좁은 Scope에 줍니다. 데이터 접근은 데이터 Role로 따로 줍니다.
Group 단위 부여	사람마다 Role을 주지 않고 Group에 주면 입사·퇴사 때 Group 멤버만 바꾸면 됩니다.
상시 관리자 권한	Owner 같은 큰 권한은 PIM(Privileged Identity Management, 필요할 때만 권한을 켜는 기능)으로 시간제로 씁니다. Entra ID P2 라이선스가 필요합니다.
비밀 값 제거	Access Key, Service Principal Secret 대신 Managed Identity를 쓰고, Storage의 Shared Key 접근은 꺼 둡니다.
Elevate Access	Global Administrator의 Access management for Azure resources는 복구 작업에만 켜고 끝나면 바로 끕니다.
고아 Role Assignment	지운 신원의 Role Assignment는 "Identity not found"로 남으므로 주기적으로 정리합니다.

8. 정리

• Entra ID는 신원을, RBAC은 그 신원이 어떤 Scope에서 무엇을 할지를, Managed Identity는 Azure 리소스의 신원을 맡습니다.
• 권한은 Security Principal, Role, Scope를 묶은 Role Assignment로 주고, 위에서 준 권한은 아래로 상속되며 여러 권한은 더해집니다.
• 관리 권한과 데이터 권한은 따로이고, 리소스끼리의 인증은 비밀 값 대신 Managed Identity로 합니다.

참고

• Microsoft Learn - Azure RBAC란?
• Microsoft Learn - Azure 리소스용 관리 ID
• 다이어그램 아이콘: Azure Architecture Icons