Microsoft Entra ID (사용자, 서비스 주체, 관리 ID)

Entra ID 와 Azure 의 관계

Microsoft Entra ID 는 예전 이름이 Azure Active Directory(Azure AD)였던 클라우드 ID 서비스입니다. 2023년에 이름이 바뀌었고, 지금 문서와 포털에는 모두 Entra 로 나옵니다. 오래된 스크립트나 블로그에서 "AAD", "Azure AD" 라고 쓰면 같은 것을 가리킵니다.

Azure 구독은 정확히 하나의 Entra 테넌트를 믿습니다. 포털 로그인, Azure CLI, SDK, 파이프라인 모두 Entra 에서 토큰을 받아 Azure Resource Manager(ARM)에 보냅니다. 그래서 Azure 권한 문제의 절반은 사실 "어떤 ID 로 토큰을 받았나" 문제입니다.

관리 ID: 비밀 없는 인증

Azure 리소스에서 다른 Azure 리소스를 부를 때는 관리 ID 가 첫 번째 선택입니다. 비밀 회전도, 유출도 걱정할 필요가 없습니다.

• 시스템 할당: 리소스와 수명을 같이합니다. VM 을 지우면 ID 도 사라집니다.
• 사용자 할당: 독립 리소스입니다. 여러 리소스가 같이 쓰거나, 리소스를 다시 만들어도 권한을 유지하고 싶을 때 씁니다.

# App Service 에 시스템 할당 관리 ID 켜고, 스토리지 Blob 읽기 권한 주기
az webapp identity assign -g rg-shop-prod -n app-shop-prod
PRINCIPAL=$(az webapp identity show -g rg-shop-prod -n app-shop-prod --query principalId -o tsv)
az role assignment create --assignee-object-id $PRINCIPAL --assignee-principal-type ServicePrincipal \
  --role "Storage Blob Data Reader" \
  --scope $(az storage account show -n stshopprod --query id -o tsv)

코드에서는 DefaultAzureCredential 을 쓰면 로컬에서는 개발자 로그인, Azure 에서는 관리 ID 로 같은 코드가 동작합니다.

from azure.identity import DefaultAzureCredential
from azure.storage.blob import BlobServiceClient

cred = DefaultAzureCredential()
svc = BlobServiceClient("https://stshopprod.blob.core.windows.net", credential=cred)

주의 역할을 할당한 직후에는 권한이 바로 반영되지 않을 수 있습니다. 보통 몇 분 안에 반영되지만, 토큰 캐시 때문에 앱을 다시 시작해야 할 때도 있습니다. 403 이 계속되면 AuthorizationFailed 트러블슈팅을 봅니다.

CI/CD 는 워크로드 ID 페더레이션으로

GitHub Actions 나 Azure DevOps 에서 Azure 에 배포할 때 클라이언트 비밀을 저장소 비밀에 넣는 방식은 이제 권장하지 않습니다. 앱 등록이나 사용자 할당 관리 ID 에 페더레이션 자격 증명을 추가하면, GitHub 가 발급한 OIDC 토큰을 Entra 토큰으로 바꿔 줍니다.

permissions:
  id-token: write
  contents: read
steps:
  - uses: azure/login@v2
    with:
      client-id: ${{ vars.AZURE_CLIENT_ID }}
      tenant-id: ${{ vars.AZURE_TENANT_ID }}
      subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}

페더레이션 자격 증명의 subject 는 repo:org/repo:environment:prod 처럼 환경 단위로 좁혀서, 아무 브랜치나 운영에 배포하지 못하게 합니다. AKS 에서는 같은 원리의 Microsoft Entra Workload ID 로 파드에 ID 를 줍니다.

Azure 관리 작업의 필수 MFA

Microsoft 는 Azure 관리 작업에 다단계 인증(MFA)을 단계적으로 강제했습니다.

2단계는 Global Administrator 가 2026-07-01 까지 미룰 수 있었으므로, 2026-10 기준으로는 대부분 테넌트에 적용된 상태입니다. 관리 ID 와 서비스 주체 같은 워크로드 ID 는 대상이 아닙니다. 반대로 사람 계정을 서비스 계정처럼 써서 돌리던 자동화는 MFA 때문에 깨지므로, 관리 ID 나 서비스 주체로 옮겨야 합니다.

라이선스별 주요 기능

조직 규모가 커지면 보안 기본값 대신 조건부 액세스 정책으로 MFA, 장치 준수, 위치 조건을 세밀하게 정합니다. 특권 역할은 PIM 으로 "필요할 때만, 승인 받고, 시간 제한" 활성화하는 것이 기본입니다. 자세한 내용은 RBAC 와 Policy 문서의 PIM 부분을 봅니다.

자주 하는 실수

• 앱 등록과 서비스 주체를 혼동: 역할 할당 화면에서 앱 이름으로 검색하면 서비스 주체가 나옵니다. 다른 테넌트의 앱이면 그 테넌트에 서비스 주체가 먼저 만들어져야 합니다.
• 클라이언트 비밀 만료: 비밀은 기본 만료가 있고, 만료되면 배포가 갑자기 실패합니다. 가능하면 페더레이션이나 관리 ID 로 바꿉니다.
• 게스트 계정에 Owner: 외부 협력사 게스트에 구독 Owner 를 주면 회수가 어렵습니다. 리소스 그룹 범위, 시간 제한 할당을 씁니다.
• 테넌트 착각: 여러 테넌트에 속한 계정은 CLI 가 엉뚱한 테넌트로 로그인할 수 있습니다. az login --tenant <id> 와 az account show 로 확인합니다.

공식 문서

• Plan for mandatory Microsoft Entra multifactor authentication
• What are managed identities for Azure resources?
• Workload identity federation