Microsoft AZ-500: ID 및 액세스 관리 — 학습 가이드
다음의 일부입니다: Microsoft Azure Security Engineer Associate AZ-500 — 학습 가이드. 검증된 답안으로 연습하기: Microsoft 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.
개요
Microsoft Azure의 ID 및 액세스 관리(IAM)는 Microsoft Entra ID(이전 Azure AD)를 중심으로 이루어집니다. 이는 누가 어떤 리소스에 어떤 조건과 권한으로 액세스할 수 있는지를 제어합니다. 효과적인 IAM 아키텍처는 상시 권한(standing privilege)을 최소화하고, 조건부 및 위험 기반 액세스를 강제하며, 하이브리드 및 외부 협업 시나리오를 지원하면서 사람과 워크로드 모두에 최신 인증을 채택합니다.
Microsoft Entra ID 구성 요소 및 범위
- 테넌트, 사용자, 그룹
- 테넌트는 조직의 ID 경계와 신뢰 구조(trust fabric)를 나타냅니다. 사용자는 구성원 또는 게스트(B2B) 계정이 될 수 있습니다. 권한 부여에는 보안 그룹을, 협업 기능에는 Microsoft 365 그룹을 사용하세요. 수동 멤버십 관리를 줄이기 위해 동적 그룹을 사용하는 것이 좋습니다.
- AU(관리 단위)
- AU를 사용하면 사용자/디바이스의 하위 집합에 대해 디렉터리 역할을 위임할 수 있습니다(예: 지역 헬프데스크는 유럽 사용자만 관리 가능). 이는 디렉터리 작업에 대한 최소 권한 원칙을 지원합니다.
- 디렉터리 역할 및 역할 할당 범위
- 디렉터리 역할(예: Global Administrator, User Administrator)은 Microsoft Entra 리소스에 적용됩니다. 가능한 경우 AU 수준에서 디렉터리 역할의 범위를 지정하여 영향 반경(blast radius)을 제한하세요. Privileged Identity Management(PIM)를 처음 구성하려면 Global Administrator 역할이 필요합니다.
- Azure RBAC(역할 기반 액세스 제어) 범위
- Azure RBAC는 Azure 리소스에 대한 액세스를 제어합니다. 관리 그룹, 구독, 리소스 그룹 또는 리소스 범위에서 역할을 할당하세요. 상속은 하향식으로 적용됩니다. 과도한 권한 부여를 줄이기 위해 항상 실용적으로 가장 좁은 범위를 선택하세요.
- 운영상의 고려 사항
- 디렉터리 역할(Entra)과 Azure RBAC(리소스 권한 부여)를 분리하세요. AU와 엄격한 RBAC 범위를 사용하여 관리 범위를 제한하고, 측면 이동(lateral movement) 기회를 줄이며, 액세스 검토를 단순화하세요.
Azure RBAC 및 최소 권한 원칙을 사용한 액세스 제어
- 기본 제공 역할 및 최소 권한
- 작업에 맞는 가장 구체적인 기본 제공 역할을 사용하는 것이 좋습니다. 예: 광범위한 Contributor 역할 대신, AcrPull 역할로 컨테이너 이미지 풀(pull) 전용 액세스 권한을, AcrPush 역할로 업로드/푸시(push) 액세스 권한을 부여하세요. Key Vault의 경우, RBAC를 통한 관리 제어는 볼트 관리자에게만 부여하고, 인증서 관리와 같은 특정 객체 작업에는 세분화된 액세스 정책을 사용하세요.
- 역할 할당 상속
- 가능한 가장 낮은 범위에서 할당하세요. 관리 그룹 또는 구독 할당은 하위로 계단식으로 적용됩니다. 의도적인 경우가 아니라면 광범위하게 상속되는 권한은 피하세요. 여러 구독에 걸쳐 일관된 RBAC가 필요한 경우, 수동 PIM 할당 대신 Azure Blueprints(또는 최신 IaC 대안)를 통해 일관된 역할 할당을 적용하세요.
- 거부 할당
- 거부 할당(Deny assignments)은 허용 할당과 관계없이 작업을 명시적으로 차단하며, 일반적으로 Azure Policy나 Blueprints와 같은 Azure 서비스에 의해 생성됩니다. 협상 불가능한 가드레일을 강제하는 데 사용하세요(예: 민감한 리소스에 대한 공용 네트워크 규칙 방지).
- 사용자 지정 역할
- 기본 제공 역할이 너무 광범위할 경우, 필요한 작업만 포함된 사용자 지정 역할을 정의하세요. 최소 권한 테스트와 액세스 검토를 통해 유효성을 검사하세요.
{
"Name": "Storage Blob Reader (TagsBlocked)",
"IsCustom": true,
"Description": "Read blobs; no tag write",
"Actions": [
"Microsoft.Storage/storageAccounts/blobServices/containers/read",
"Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read"
],
"NotActions": [
"Microsoft.Resources/tags/write"
],
"AssignableScopes": ["/subscriptions/00000000-0000-0000-0000-000000000000"]
}
- 운영상의 고려 사항
- RBAC 범위 지정과 사용자 지정 역할은 과도한 자격 부여와 감사 대상 영역(audit surface)을 줄여줍니다. 거부 할당은 실수로 부여된 광범위한 ‘허용’ 권한으로도 우회할 수 없는 ‘강력한’ 규정 준수 제약 조건을 설정하여 보안 태세의 복원력을 향상시킵니다.
권한 있는 액세스, 조건부 액세스 및 ID 보호
PIM(Privileged Identity Management)
- 적격(Eligible) vs 활성(active): 적격 할당은 상시 권한을 부여하지 않으며, 사용자는 활성 상태가 되기 위해 JIT(Just-In-Time)으로 활성화해야 합니다. 활성화 시 승인, 사유, MFA를 강제하고, 제한된 기간을 설정하며, 추적성을 위해 티켓 참조를 요구하세요. 먼저 권한 있는 역할을 검색하여 현재 노출 상태를 파악하는 것부터 시작하세요. 주기적인 액세스 검토를 사용하여 지속적인 필요성을 검증하고, 이상적으로는 리소스 또는 그룹 소유자를 검토자로 지정하세요.
CA(조건부 액세스)
- 할당 대상은 사용자/그룹, 워크로드 ID, 클라우드 앱 및 작업입니다. 조건에는 로그인 위험, 디바이스 플랫폼/상태, 위치, 클라이언트 앱, 디바이스 및 앱용 필터가 포함됩니다. 권한 부여 제어(Grant controls)는 MFA, 규격 또는 하이브리드 Azure AD 조인 디바이스, 앱 보호 정책 또는 사용 약관을 요구할 수 있습니다. 세션 제어는 로그인 빈도, 영구 세션, 앱 강제 제한(예: SharePoint의 경우 웹 전용)을 제한합니다. 보고서 전용 모드를 사용하여 정책 적용 전에 안전하게 정책 영향을 검증하세요. 계정 잠김(lockout)을 방지하기 위해 비상 액세스(break-glass) 계정에 대한 제외를 유지하고 단계적 롤아웃을 수행하세요.
Identity Protection
- 사용자 위험은 계정이 손상되었을 가능성을, 로그인 위험은 특정 세션이 위험할 가능성을 나타냅니다. 보안 수정 조치를 요구하도록 정책을 구성하세요:
- 유출된 자격 증명을 가진 사용자: 높은 사용자 위험으로 처리하고, 암호 재설정을 강제하며, 수정될 때까지 차단합니다.
- 의심스러운 활동이 있는 IP에서의 로그인: 최소 중간 로그인 위험으로 처리하고, MFA로 확인하거나 민감한 앱에 대해서는 차단합니다.
- CA와 통합하여 실시간으로 신뢰도를 조정하세요. 위험 기록과 수정 조치를 추적하여 효율성을 측정하세요.
- 사용자 위험은 계정이 손상되었을 가능성을, 로그인 위험은 특정 세션이 위험할 가능성을 나타냅니다. 보안 수정 조치를 요구하도록 정책을 구성하세요:
운영상의 고려 사항
- PIM은 상시 권한을 제거하고 강력하며 감사 가능한 활성화를 강제합니다. CA와 Identity Protection은 제로 트러스트를 적용하여 사용자, 디바이스, 세션, 위험을 기반으로 각 액세스 시도를 검증함으로써 자격 증명 도용 및 토큰 재사용 공격의 성공률을 줄입니다.
하이브리드 및 워크로드 ID
- 하이브리드 ID 옵션
- 암호 해시 동기화(PHS): 암호 해시를 Entra ID에 동기화합니다. 간단하고 복원력이 높지만, 인증 시 온프레미스 로그인 정책을 강제하지 않습니다.
- 통과 인증(PTA): 경량 커넥터를 통해 온프레미스 DC에 대해 암호를 검증합니다. AD FS 없이 온프레미스 암호 정책 및 계정 제한을 실시간으로 강제합니다.
- 페더레이션(예: AD FS): 인증을 온프레미스 STS로 전환합니다. 복잡한 클레임이나 레거시 시나리오에 필요한 경우에만 사용하며, 더 많은 서버와 운영 오버헤드를 유발합니다.
- Seamless Single Sign-On(Seamless SSO): 회사 네트워크 내의 도메인 가입 디바이스에서 사용자가 최소한의 프롬프트로 로그인할 수 있도록 합니다.
- 운영상의 선택: 서버를 최소화하면서 온프레미스 암호 정책 및 계정 제한을 강제하려면 PTA와 Seamless SSO를 배포하고, PTA에 의존하지 않는 시나리오의 복원력/장애 조치를 위해 PHS도 활성화합니다. 페더레이션만으로는 복잡성이 증가하고 “서버 최소화” 목표를 충족하지 못합니다.
- 하이브리드 조인된 Windows 디바이스에서 Azure SQL로의 앱 인증
- Active Directory 통합 인증을 사용하여 프롬프트를 최소화하고 해당되는 경우 Kerberos/SSO를 활용합니다.
- 관리 ID 및 서비스 주체
- **관리 ID(시스템 할당 또는 사용자 할당)**는 시크릿을 제거하고 자격 증명을 자동으로 회전시키므로 Azure 호스팅 워크로드에 대한 첫 번째 선택입니다. 리소스 범위에서 ID에 최소 권한 RBAC를 할당합니다.
- 서비스 주체는 앱 등록의 기반이 됩니다. 클라이언트 시크릿 대신 인증서 자격 증명을 사용하고 실행 가능한 가장 짧은 수명을 설정합니다.
- 워크로드 ID 페더레이션
- OIDC 페더레이션을 사용하여 외부 워크로드 ID(예: GitHub Actions, Kubernetes)가 시크릿을 저장하지 않고 Entra 앱용 토큰을 얻을 수 있도록 합니다. 발급자(issuer), 주체(subject), 대상(audience) 클레임을 정확하게 정의하여 토큰을 교환할 수 있는 대상을 제한합니다.
az ad app federated-credential create \
--id <app-object-id> \
--parameters '{
"name":"gh-actions-main",
"issuer":"https://token.actions.githubusercontent.com",
"subject":"repo:contoso/api:environment:prod",
"audiences":["api://AzureADTokenExchange"]
}'
- AKS에서 ACR로의 액세스
attach-acr흐름을 사용하여 대상 레지스트리에 대한 AKS 클러스터의 관리 ID에AcrPull권한을 부여합니다. 이 방식은 올바른 범위 지정을 자동화하고 잘못된 할당을 방지합니다.
az aks update -n aks-prod -g rg-aks --attach-acr myRegistry
- 운영상의 고려사항
- PTA+PHS+Seamless SSO는 클라우드 복원력을 유지하면서 실시간 온프레미스 제어를 강제합니다. 관리 ID와 페더레이션은 파이프라인과 런타임에서 정적 시크릿을 제거하여 빈번하게 발생하는 자격 증명 도용 경로를 차단합니다.
외부 협업, 인증 방법 및 앱 액세스
- 외부 ID 및 B2B 협업
- 테넌트 간 액세스 설정, 사용 약관, 게스트 대상 CA(조건부 액세스)와 함께 B2B 게스트 계정을 사용합니다. 초대할 수 있는 사람을 제한하고, 권한 관리를 통해 Just-In-Time 액세스를 선호합니다.
- 권한 관리 및 액세스 패키지
- 그룹, 앱, SharePoint 사이트를 액세스 패키지로 묶고, 요청할 수 있는 사람(외부 사용자 포함), 승인 워크플로, 할당 기간, 액세스 검토를 정의하는 정책을 설정합니다. 검토자 선택 시에는 그룹 소유자(Group Owners)를 사용하여 리소스 담당자가 비즈니스 책임을 지도록 합니다.
- 인증 방법 및 암호 없는 방식
- 강력한 방법으로 표준화합니다: FIDO2 보안 키, 비즈니스용 Windows Hello, Microsoft Authenticator 전화 로그인. 결합된 보안 정보 등록(SSPR + MFA)을 사용하고 모든 사용자에 대해 MFA 등록 정책을 강제합니다. 필요한 경우 온프레미스 쓰기 저장(writeback) 기능이 있는 SSPR을 활성화하고, 보안 방법을 요구하며 가능한 경우 회사 관리 요소로 제한합니다. 레거시/기본 인증 프로토콜을 비활성화하고, 위험이 있는 경우 취약한 SMS 전용 MFA를 차단합니다.
- Microsoft Entra application proxy
- 인바운드 방화벽 포트를 열지 않고 온프레미스 웹 앱을 게시합니다. 고가용성(HA)을 위해 커넥터 그룹을 사용하고, Entra ID로 사전 인증하며, 레거시 앱에 제로 트러스트를 적용하기 위해 CA, 디바이스 준수, Identity Protection을 계층화합니다.
- 애플리케이션 등록 보안
- 관리자 동의 워크플로를 요구하고, 앱을 만들 수 있는 사람을 제한하며, 권한을 분류합니다. 사용자 컨텍스트가 필요하지 않은 경우에만 애플리케이션 권한을 선호하고 API 범위를 최소한으로 지정합니다. 가능한 경우 암시적 허용(implicit grant)을 비활성화하고, 엔터프라이즈 앱에 할당을 요구하며, 비밀(secret) 대신 자동 순환되는 인증서를 선호합니다.
az ad app update --id <app-id> --required-resource-access @permissions.json
az ad sp update --id <sp-id> --set appRoleAssignmentRequired=true
- 운영상의 근거
- 액세스 패키지와 앱 프록시는 관리되고 감사 가능한 외부 액세스를 제공합니다. 강력한 암호 없는 방식은 피싱 저항성을 높입니다. 엄격한 앱 등록 제어는 과도한 동의를 방지하고 앱 가장 가능성을 줄입니다.
실용적인 문제 시나리오
Adobe Inc.는 타사 공급업체에 Azure 리소스의 일부에 대한 임시 관리 액세스 권한을 부여하고, 내부 레거시 웹 앱을 해당 공급업체에 게시해야 합니다. 이때 강력한 인증과 상시 권한 없음(zero standing privilege) 원칙을 적용해야 합니다.
- 액세스 범위 지정 및 모델링
rg-vendor-ops리소스 그룹을 만들고 필요한 리소스만 이 그룹으로 이동합니다. 최소한의 Azure RBAC 역할을 할당합니다(예:rg-vendor-ops에 대한 Contributor, 진단 리소스 그룹에 대한 Reader).- 근거: 범위를 좁히면 수평 이동(lateral movement)을 방지할 수 있습니다. 역할 상속이
rg-vendor-ops로 제한되어 영향 반경(blast radius)을 줄입니다.
- PIM을 사용한 ID 및 활성화 거버넌스
- 공급업체 관리자가 필요한 역할에 대해 영구적이 아닌 자격(eligible)을 갖도록 설정합니다. 활성화 시 승인, 티켓 ID, MFA를 요구하고 활성화 시간을 4시간으로 제한합니다. 먼저 PIM의 ‘권한 있는 역할 검색(Discover privileged roles)‘을 실행하여 기존 할당의 기준선을 설정합니다.
- 근거: 자격 할당은 상시 권한을 제거합니다. 승인 및 MFA는 지원 기간에 맞춰 JIT 액세스를 강제하고 감사 가능한 제어를 제공합니다.
- 조건부 액세스 및 위험 정책 강제
- 공급업체 그룹, Azure 포털 및 ARM API를 대상으로 하는 CA 정책을 만듭니다. 이 정책은 MFA, 규격/하이브리드 조인 디바이스를 요구하고 위험한 위치에서의 액세스를 차단합니다. 먼저 보고서 전용(report-only) 모드로 활성화한 후 강제 적용합니다. Identity Protection을 구성합니다: 암호 재설정 전까지 높은 사용자 위험(자격 증명 유출)을 차단하고, 중간 로그인 위험(의심스러운 IP)에 대해 MFA를 요구합니다.
- 근거: CA는 액세스를 디바이스 신뢰 및 위험과 실시간으로 연결합니다. 보고서 전용 모드는 롤아웃 중 서비스 중단을 방지합니다. 위험 정책은 손상된 세션과 계정을 자동으로 수정합니다.
- Microsoft Entra application proxy로 레거시 앱 게시
- 고가용성(HA)을 위해 공급업체에 노출된 별도의 서브넷에 두 개의 커넥터를 배포합니다. Entra ID로 사전 인증을 구성하고, 엔터프라이즈 앱에 할당을 요구하며, 동일한 CA 정책을 적용합니다. 액세스 패키지를 사용하여 공급업체 사용자에게 엔터프라이즈 앱과 RG 역할 모두에 대한 시간 제한적 액세스 권한을 부여하고, 그룹 소유자(Group Owners)를 검토자로 설정합니다.
- 근거: 앱 프록시는 인바운드 노출을 제거하고 인증을 중앙 집중화합니다. 권한 관리는 온보딩/오프보딩을 표준화하고 리소스 소유자에 의한 정기적인 검토를 보장합니다.
- 워크로드 및 앱 자격 증명 보안
- 서비스 주체의 모든 클라이언트 비밀(client secret)을 인증서 자격 증명으로 교체합니다. CI/CD의 경우 비밀을 저장하는 대신 워크로드 ID 페더레이션을 사용합니다. 이미지가 필요한 AKS 워크로드의 경우, ACR을 클러스터에 연결하여 관리 ID에
AcrPull권한을 부여합니다. - 근거: 정적 비밀을 제거하면 일반적인 침해 경로가 차단됩니다. 페더레이션 및 관리 ID는 최소 권한의 자동 순환 액세스를 제공합니다.
- 비상 계정(break-glass) 보호 및 모니터링
- 두 개의 비상 계정을 CA에서 제외하되, 오프라인에 저장된 긴 임의 암호로 보호합니다. 분기별로 액세스 검토를 활성화하고, PIM 및 CA 로그를 Log Analytics 작업 영역으로 내보내 비정상적인 활성화에 대한 경고를 설정합니다.
- 근거: 비상 계정은 운영상 안전을 유지하면서 테넌트 잠금을 방지합니다. 지속적인 모니터링은 오용을 신속하게 감지하여 규정 준수 및 인시던트 대응 준비 상태를 유지합니다.
모든 도메인 · 네트워크 보안 아키텍처 →
이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
시험 합격하기 →