AZ-305 솔루션 아키텍트 시험에서 ID와 액세스 관리 도메인은 전체 출제 비중의 약 20~25%를 차지합니다. 단순한 RBAC 역할 암기를 넘어, 누가 어떤 자격으로 어떤 범위에서 무엇에 접근하는가를 설계하는 능력이 요구됩니다. Entra ID 핵심 개념부터 RBAC 상속, Conditional Access, Managed Identity, Privileged Identity Management까지 시험 빈출 주제를 실전 시나리오와 함께 정리합니다. AZ-305를 처음 준비하는 분도, 실무 클라우드 엔지니어도 바로 적용할 수 있는 선택 기준을 제시합니다.
---
Entra ID 핵심 개념
Microsoft Entra ID(구 Azure Active Directory)는 Azure 환경의 출입 관리 시스템입니다. 사원증에 따라 갈 수 있는 구역이 달라지듯, Entra ID는 누가 어떤 클라우드 리소스에 접근할 수 있는지를 결정합니다.
위임된 권한 vs 애플리케이션 권한
위임된 권한(Delegated Permission)은 로그인한 사용자를 대신하여 앱이 동작하는 방식입니다. 사용자가 명시적으로 동의한 범위 내에서만 리소스에 접근하며, Authorization Code Flow를 사용합니다. 예를 들어 웹 앱이 로그인한 사용자의 캘린더를 읽어야 할 때 Calendars.Read(Delegated)로 동작합니다.
애플리케이션 권한(Application Permission)은 사용자 없이 앱 자체의 ID로 동작합니다. Client Credentials Flow를 사용하며, 관리자 동의(Admin Consent)가 필수입니다. 백엔드 API에 정의된 앱 역할(App Role)을 클라이언트 앱의 애플리케이션 권한으로 할당하면 해당 역할이 클레임으로 액세스 토큰에 포함됩니다.
키워드 구분: "사용자를 대신하여" 또는 "사용자 동의"가 나오면 위임된 권한, "사용자 개입 없는 서비스 간 인증"이 나오면 애플리케이션 권한을 선택합니다.
Administrative Unit과 위임 관리
각 부서 IT 관리자가 자기 부서 사용자만 관리하게 하려면 "사용자 관리자(User Administrator)" 역할을 해당 AU 범위로 할당합니다. 헬프데스크 관리자는 신규 사용자 생성 권한이 없으므로, 신규 계정 생성이 필요하다면 반드시 사용자 관리자 역할을 선택하세요.
하이브리드 ID: PHS vs PTA vs AD FS
Password Hash Synchronization(PHS)은 비밀번호 해시를 Entra ID에 동기화합니다. 온프레미스 AD가 중단되어도 클라우드 인증이 계속 가능합니다. Pass-through Authentication(PTA)은 인증 요청을 온프레미스 에이전트로 전달하므로, 온프레미스 연결이 끊기면 인증이 불가합니다.
시험 팁: "온프레미스 장애에도 클라우드 인증 유지"가 조건이면 PHS, "비밀번호를 클라우드에 저장하면 안 됨"이 조건이면 PTA 또는 AD FS를 선택하세요. 또한 Microsoft Entra Connect는 여러 온프레미스 AD 포리스트를 단일 Entra 테넌트에 동기화할 수 있으며, 단일 포리스트 내 자식 도메인은 에이전트 1개로 처리됩니다.
!하이브리드 ID: PHS, PTA, AD FS
RBAC 설계와 권한 위임
RBAC(Role-Based Access Control)는 직책에 따라 열쇠를 다르게 주는 시스템입니다. Azure RBAC 역할 할당은 상위 범위에서 하위 범위로 자동 상속됩니다.
Management Group에서 역할을 부여하면 하위 모든 구독과 리소스에 별도 설정 없이 자동 적용됩니다. 중첩 그룹(nested group)도 지원하므로, 상위 그룹의 역할이 하위 그룹 구성원에게 전달됩니다.
중요한 제한: RBAC 역할 할당은 테넌트 경계를 넘지 않습니다. 두 개의 독립된 Entra 테넌트에 걸쳐 5개 구독에 Reader 권한을 부여하려면, 각 테넌트의 관리 그룹 수준에 1회씩 할당해 총 2회로 해결합니다.
Contributor의 한계: Contributor는 리소스 생성, 수정, 삭제가 가능하지만 권한이 없습니다. 다른 사용자에게 역할을 부여해야 한다면 Owner 또는 User Access Administrator가 필요합니다.
ABAC를 활용하면 기존 역할을 변경하지 않고도 리소스 속성(태그, 컨테이너 이름)에 따라 접근을 세분화할 수 있습니다. 현재 Azure Blob Storage 데이터 작업에서만 공식 지원되며, Files, Queue, Table Storage는 미지원입니다.
---
Conditional Access와 MFA 전략
Conditional Access는 사용자, 디바이스, 위치, 앱, 위험 수준 등 복합 신호를 평가해 접근을 허용, 차단, 또는 추가 인증 요구로 제어하는 Zero Trust 정책 엔진입니다.
MFA 등록 강제와 MFA 수행 강제는 다릅니다. MFA 등록 강제는 조건부 액세스 MFA 등록 정책을 사용하며 사용자가 MFA 방법을 등록하게 합니다. MFA 수행 강제는 정책의 권한 부여(Grant) 컨트롤에서 "MFA 필요" 옵션을 설정해 실제 로그인 시 MFA 인증을 완료해야 접근이 허용됩니다.
BYOD를 차단하고 관리 디바이스에서만 접근을 허용하려면 "준수 디바이스(Compliant Device)" 조건을 설정합니다. Azure Firewall이나 NSG는 디바이스 관리 상태를 인식하지 못하므로 디바이스 기반 제어에는 항상 Conditional Access를 선택합니다.
관리자 계정에 대해 Azure Portal 접근 시 MFA를 강제하는 요구사항은 단일 정책 하나로 해결됩니다. 사용자 그룹, 클라우드 앱(Microsoft Azure Management), 권한 부여 컨트롤(MFA 필요)을 하나의 정책에 결합하면 됩니다.
VM 접근 보안: 공용 IP를 노출하지 않으면서 RDP/SSH가 필요할 때 Azure Bastion을 사용합니다. JIT VM Access는 공용 포트를 일시적으로 개방하는 방식이므로, "공용 IP 노출 제거"가 요구된다면 Bastion + Conditional Access 조합을 선택합니다.
---
Managed Identity와 서비스 인증
코드나 구성 파일에 자격 증명을 저장하지 않고 Azure 서비스 간 인증을 구현할 때 Managed Identity를 사용합니다. Azure 플랫폼이 자동으로 토큰을 발급하고 갱신하므로 만료나 순환 관리가 필요 없습니다.
System-assigned Managed Identity는 특정 Azure 리소스와 생명 주기가 연결됩니다. 리소스가 삭제되면 자동으로 함께 제거됩니다. User-assigned Managed Identity는 여러 리소스에서 동일한 ID를 공유할 수 있습니다.
시험 팁: "각 리소스마다 별도 자격 증명"이면 System-assigned, "여러 리소스가 동일 ID 공유"이면 User-assigned를 선택합니다.
Key Vault 연동 패턴: Managed Identity에 "Key Vault Secrets User" 역할을 부여하면 코드 변경 없이 비밀 값에 접근할 수 있습니다. 인증은 됐는데 읽기가 실패하면 권한 부여(Authorization)가 누락된 것입니다. Managed Identity 인증 성공은 ID 확인 완료를 의미할 뿐이며, 실제 비밀 읽기는 Get/List 권한이 별도로 필요합니다.
SDK 없이 VM 내부에서 REST 호출만으로 Managed Identity 토큰을 얻으려면 Azure Instance Metadata Service(IMDS)를 사용합니다.
---
서비스 비교표
| 서비스 | 주요 용도 | 라이선스 | 핵심 특징 | |--------|-----------|----------|-----------| | Entra ID PIM | JIT 특권 역할 관리 | P2 | Eligible 할당, 승인 워크플로우, 감사 로그 | | Access Reviews | 정기 접근 권한 검토 | P2 | 반복 일정, 자가 확인, 미응답 시 자동 제거 | | Entitlement Management | 외부 사용자 기간 제한 접근 | P2 | 액세스 패키지, 자동 만료, 셀프서비스 요청 | | Conditional Access | 조건부 접근 정책 엔진 | P1 | 사용자/디바이스/위치/앱 복합 신호 평가 | | Application Proxy | VPN 없이 온프레미스 앱 게시 | P1 | 역방향 프록시, KCD 지원, 코드 변경 불필요 | | Entra Domain Services | LDAP/Kerberos 완전관리형 도메인 | 별도 SKU | 온프레미스 연결 불필요, 레거시 앱 호환 |
---
시험에서 자주 헷갈리는 선택 기준
실제 기출 시나리오를 기반으로 선택 기준을 정리합니다.
PIM vs Access Reviews — PIM은 역할을 언제 활성화할지 통제하고, Access Reviews는 누가 역할을 계속 보유해야 하는지 주기적으로 검토합니다. 두 요구사항이 함께 나오면 PIM + Access Reviews 조합을 선택합니다.
Application Proxy vs Azure Bastion — Application Proxy는 HTTP/HTTPS 기반 웹 앱을 VPN 없이 외부에 게시하고, Azure Bastion은 VM의 RDP/SSH 접속 전용입니다. 온프레미스 IWA 앱에 VPN 없이 SSO 접근이 필요하다면 Application Proxy를 선택합니다.
Entra B2B vs B2C — 파트너사 직원이 이미 Entra ID 계정을 보유하고 있으면 B2B 게스트 초대를 사용합니다. 소비자나 소셜 계정 사용자를 대상으로 하면 B2C를 선택합니다.
Entra Domain Services vs Entra Connect — 레거시 앱이 LDAP 인증을 사용하고 온프레미스 연결이 없어야 한다면 Entra Domain Services를 선택합니다. 온프레미스 AD 사용자를 Entra ID에 동기화하는 용도라면 Entra Connect를 사용합니다.
OAuth 2.0 흐름 구분 — 웹 앱이 로그인한 사용자를 대신하여 백엔드 API를 호출할 때는 On-Behalf-Of(OBO) Flow를 사용합니다. 사용자 없이 서비스 간 호출이면 Client Credentials Flow, 사용자가 앱에 직접 로그인하는 경우는 Authorization Code Flow입니다.
---
실무 적용 팁
영구 역할 할당을 가능한 Eligible 할당(PIM)으로 전환합니다. 필요 시에만 활성화하게 하면 권한 남용 위험이 줄어듭니다. 구독당 최대 4,000개 역할 할당 한도를 고려해 그룹 기반으로 할당 수를 최소화합니다.
관리 그룹 계층을 최대한 활용합니다. 구독이 늘어날수록 각 구독에 역할을 개별 할당하는 것은 비효율적입니다. 관리 그룹에 역할을 한 번 할당하면 모든 하위 구독에 자동 상속됩니다.
외부 사용자 라이프사이클 관리는 Entitlement Management의 액세스 패키지로 자동화합니다. 프로젝트 기간 동안만 접근 권한을 부여하고 만료 시 자동 회수하면 운영 오버헤드가 없습니다. Access Reviews를 분기 단위로 설정해 불필요한 권한을 정기적으로 제거합니다.
모든 Azure 리소스 간 인증은 Managed Identity로 전환하는 것이 보안 모범 사례입니다. Azure SDK의 을 사용하면 로컬 개발 환경과 프로덕션 환경 모두에서 자격 증명 변경 없이 동작합니다.
---
정리