AZ-104 시험에서 ID/거버넌스 도메인은 전체의 20~25%를 차지합니다. 처음 들으면 딱딱하게 느껴질 수 있지만, 실제로는 "누가 무엇에 접근할 수 있는가"와 "규칙대로 운영되고 있는가"를 관리하는 이야기입니다. Entra ID 관리, RBAC, Azure Policy가 핵심입니다.
---
Entra ID 사용자 및 그룹
Entra ID(이전 명칭: Azure Active Directory)는 회사 건물의 출입 관리 시스템과 같습니다. 건물에 들어오려면 사원증이 필요하고, 사원증에 따라 갈 수 있는 층이 다르듯이, Entra ID는 "누가 Azure에 로그인할 수 있는가"와 "어떤 리소스에 접근할 수 있는가"를 결정합니다.
사용자 관리
사용자를 만드는 방법은 여러 가지입니다. 소규모 팀이라면 Azure Portal에서 한 명씩 추가하면 되지만, 수백 명의 직원을 한꺼번에 등록해야 한다면 CSV 파일로 대량 생성하는 방법이 훨씬 편리합니다. PowerShell이나 Azure CLI를 사용하면 스크립트로 자동화할 수도 있습니다.
사용자 생성: Portal(웹 화면), PowerShell, CLI(명령줄), 대량 생성(CSV 파일 업로드) 중 상황에 맞게 선택합니다. 게스트 사용자 (B2B 협업): 외부 파트너나 협력업체 직원이 내 Azure 리소스에 접근해야 할 때 사용합니다. 예를 들어 외주 개발사가 테스트 환경에 접근해야 한다면, 그 회사 직원을 "게스트"로 초대할 수 있습니다. 게스트는 자신의 회사 계정(또는 개인 이메일)으로 로그인하므로 별도의 계정을 새로 만들어줄 필요가 없습니다. SSPR (셀프서비스 암호 재설정): 직원이 비밀번호를 잊어버렸을 때 IT 헬프데스크에 전화하지 않고 스스로 재설정할 수 있는 기능입니다. 직원 입장에서는 빠르고 편하고, IT 팀 입장에서는 반복적인 비밀번호 재설정 요청에서 해방됩니다. 관리 단위 (Administrative Units): 대형 조직에서 지역별·부서별로 관리 권한을 나눌 때 사용합니다. 예를 들어 "서울 지사 관리자"는 서울 지사 사용자만 관리하도록 권한을 제한할 수 있습니다.
그룹 유형
사용자를 그룹으로 묶으면 권한 관리가 훨씬 쉬워집니다. 100명에게 하나씩 권한을 주는 대신 "마케팅 팀" 그룹에 권한을 주면 그룹 멤버 전원이 자동으로 해당 권한을 갖게 됩니다.
| 유형 | 멤버십 방식 | 주요 용도 | |------|------------|----------| | 보안 그룹 | 직접 할당 또는 동적 | Azure 리소스 접근 권한 관리 | | Microsoft 365 그룹 | 직접 할당 또는 동적 | Teams, 공유 사서함, SharePoint 등 협업 도구 |
보안 그룹은 "이 팀이 이 리소스에 접근할 수 있다"는 권한을 묶을 때 씁니다. Microsoft 365 그룹은 단순 권한을 넘어서 공유 이메일함, 팀즈 채널, SharePoint 사이트까지 자동으로 연결되는 협업 중심의 그룹입니다.
멤버십 방식도 두 가지입니다. 직접 할당은 관리자가 한 명씩 수동으로 추가하는 방법이고, 동적 멤버십은 "부서가 마케팅인 사람은 자동으로 포함"처럼 규칙을 설정하면 조건에 맞는 사용자가 자동으로 추가되거나 제거됩니다. 입사·퇴사·부서 이동이 잦은 조직에서는 동적 그룹이 매우 유용합니다.
---
Azure RBAC
RBAC(Role-Based Access Control, 역할 기반 접근 제어)는 직책에 따라 열쇠를 다르게 주는 시스템입니다. 회사에서 신입사원은 자신의 책상 서랍만 열 수 있고, 팀장은 회의실도 열 수 있고, 시설 관리자는 건물 전체를 관리할 수 있는 것과 같습니다. Azure에서는 "역할"을 부여함으로써 각 사용자가 할 수 있는 일을 정확하게 통제합니다.
기본 제공 역할
Azure는 자주 쓰이는 역할을 미리 만들어 제공합니다. 처음에는 이 네 가지만 이해해도 충분합니다.
| 역할 | 할 수 있는 일 | 할 수 없는 일 | |------|-------------|-------------| | Owner (소유자) | 모든 것 + 다른 사람에게 역할 부여 | 없음 | | Contributor (기여자) | 리소스 생성·수정·삭제 | 다른 사람에게 역할 부여 | | Reader (읽기 권한자) | 리소스 조회·확인 | 생성·수정·삭제 | | User Access Administrator | 역할 할당 관리 | 리소스 자체 변경 |
실제 업무 예시로 생각해 보면 이렇습니다. 개발자에게는 Contributor를 줘서 인프라를 배포하고 관리하게 하되, 다른 사람의 권한까지 건드리지는 못하게 합니다. 감사팀에게는 Reader를 줘서 현황은 볼 수 있지만 아무것도 바꾸지 못하게 합니다.
역할 할당 범위
RBAC의 강력한 점 중 하나는 어느 수준에서 역할을 줄지 선택할 수 있다는 것입니다. Azure는 아래 네 단계의 계층 구조를 갖습니다.
상위 계층에서 부여한 역할은 하위 계층에 자동으로 상속됩니다. 예를 들어 "구독" 수준에서 누군가에게 Reader를 주면, 그 구독 안에 있는 모든 리소스 그룹과 리소스에 대해서도 자동으로 읽기 권한이 생깁니다. 반대로 특정 리소스 하나에만 권한을 주고 싶다면 "리소스" 수준에서만 역할을 할당하면 됩니다.
!RBAC 역할 할당 범위 계층 구조
사용자 지정 역할
기본 제공 역할이 조직의 요구사항과 정확히 맞지 않을 때는 직접 역할을 만들 수 있습니다. 예를 들어 "특정 스토리지 계정의 Blob은 읽을 수 있지만 Queue는 접근 불가"처럼 세밀하게 조정해야 할 때 JSON 파일로 사용자 지정 역할을 정의합니다. 조금 고급 기능이지만, 시험에서도 "기본 역할로는 요구사항을 충족할 수 없을 때 어떻게 하나요?"라는 형태로 출제됩니다.
---
거버넌스
거버넌스는 간단히 말하면 "규칙대로 운영되고 있는가"를 보장하는 체계입니다. 아무리 좋은 시스템도 규칙 없이 운영하면 비용이 폭발하거나, 보안 허점이 생기거나, 규정 위반이 발생할 수 있습니다. Azure의 거버넌스 도구들은 이런 문제를 미리 막아줍니다.
Azure Policy
Azure Policy는 조직의 규칙을 자동으로 집행하는 시스템입니다. 예를 들어 "모든 리소스는 반드시 대한민국(Korea Central) 지역에만 만들어야 한다"는 규칙을 Policy로 설정하면, 누군가 미국 지역에 서버를 만들려고 할 때 자동으로 차단됩니다.
Policy를 통해 할 수 있는 일은 크게 네 가지입니다.
Deny (차단): 규칙을 어기는 리소스 생성 자체를 막습니다. 가장 강력한 효과입니다. Audit (감사): 규칙에 어긋나더라도 차단하지는 않고, 위반 사실만 기록합니다. 규칙을 처음 도입할 때 영향 범위를 파악하기 위해 먼저 Audit 모드로 운영하는 경우가 많습니다. DeployIfNotExists (자동 배포): 리소스가 생성될 때 특정 조건이 없으면 자동으로 추가 배포를 합니다. 예를 들어 가상 머신이 생성되면 자동으로 모니터링 에이전트를 설치하도록 설정할 수 있습니다. Modify (자동 수정): 규칙에 어긋난 설정을 자동으로 올바른 값으로 수정합니다.
이니셔티브(Initiative)는 여러 Policy를 하나의 묶음으로 관리하는 기능입니다. 예를 들어 "보안 강화" 이니셔티브 안에 암호화 정책, 네트워크 정책, 태그 정책을 모두 묶어두면, 이니셔티브 하나만 구독에 할당해도 모든 정책이 한꺼번에 적용됩니다.
규정 준수 대시보드를 통해 현재 어떤 리소스가 어떤 정책을 위반하고 있는지 한눈에 확인할 수 있습니다. 위반 비율(%)도 볼 수 있어 조직의 전체 준수 상태를 파악하기 좋습니다.
리소스 잠금
중요한 리소스를 실수로 삭제하거나 변경하지 않도록 잠글 수 있습니다. 프로덕션(실제 운영) 환경의 데이터베이스나 핵심 네트워크 설정은 잠금을 걸어두는 것이 좋은 관행입니다.
잠금에는 두 가지 종류가 있습니다.
Delete 잠금: 리소스를 삭제하는 것만 막습니다. 설정을 수정하거나 데이터를 추가하는 것은 여전히 가능합니다. "지워지면 안 되는" 리소스에 적합합니다. ReadOnly 잠금: 말 그대로 읽기만 가능합니다. 수정도 삭제도 모두 불가능합니다. 변경이 전혀 일어나면 안 되는 안정적인 환경에 적합하지만, 너무 제한적이어서 일부 작업이 예상치 못하게 막힐 수 있습니다.
잠금은 RBAC와 별개로 동작합니다. Owner 권한을 가진 사람도 잠금이 걸린 리소스는 삭제할 수 없습니다. 잠금을 해제하려면 먼저 잠금 자체를 제거해야 합니다.
태그
태그는 리소스에 메모 스티커를 붙이는 것과 같습니다. 예를 들어 , , 처럼 키-값 쌍으로 원하는 정보를 리소스에 붙일 수 있습니다.
태그가 왜 중요할까요? Azure에서 수백 개의 리소스를 운영하다 보면 "마케팅 팀이 이번 달에 얼마를 썼지?"라는 질문에 바로 답하기 어렵습니다. 하지만 모든 리소스에 태그가 붙어 있다면 태그 기준으로 비용을 필터링해서 확인할 수 있습니다.
한 가지 중요한 특성이 있습니다. 태그는 상속되지 않습니다. 리소스 그룹에 태그를 붙여도 그 안의 리소스에는 자동으로 붙지 않습니다. 모든 리소스에 태그를 강제로 붙이고 싶다면 Azure Policy의 Modify 효과를 활용하면 됩니다.
---
시험 핵심 정리
시험에서는 시나리오를 주고 가장 적합한 Azure 기능을 고르는 문제가 많이 출제됩니다. 아래 핵심 내용을 시나리오와 연결해서 기억해 두면 도움이 됩니다.
사용자와 그룹 관련 "부서, 직위 같은 속성을 기반으로 그룹 멤버를 자동 관리하고 싶다" → 동적 그룹을 사용합니다. 사람이 일일이 추가·제거하지 않아도 됩니다. "외부 파트너나 협력업체 직원을 내 Azure 환경에 초대하고 싶다" → 게스트 사용자 (B2B 협업)을 사용합니다. 상대방이 자신의 계정으로 로그인합니다. "직원이 비밀번호를 잊어버렸을 때 IT팀 도움 없이 스스로 재설정하게 하고 싶다" → SSPR(셀프서비스 암호 재설정)을 활성화합니다.
RBAC 역할 관련 "모든 권한이 필요하고, 다른 사람에게도 역할을 줄 수 있어야 한다" → Owner입니다. "리소스를 만들고 관리할 수 있지만, 권한 관리는 할 수 없어야 한다" → Contributor입니다. "RBAC 역할은 어떻게 전파되나요?" → 상위에서 하위로 상속됩니다. 관리 그룹 → 구독 → 리소스 그룹 → 리소스 순서로 자동 적용됩니다.
거버넌스 관련 "특정 리소스 유형이나 지역만 허용하도록 규칙을 강제하고 싶다" → Azure Policy를 사용합니다. "실수로 중요한 리소스가 삭제될까 봐 걱정된다" → Delete 잠금을 겁니다. 수정은 여전히 가능합니다. "아무것도 변경하면 안 되는 환경을 만들고 싶다" → ReadOnly 잠금을 사용합니다. 수정과 삭제 모두 차단됩니다. "리소스에 비용 추적을 위한 레이블을 붙이고 싶다" → 태그(Tag)를 사용합니다. 단, 태그는 하위 리소스에 자동으로 상속되지 않으므로, 일괄 적용이 필요하다면 Policy와 함께 사용하세요.
이 도메인은 외우는 것보다 "이 상황이라면 어떤 기능을 쓸까?"라는 사고방식으로 접근하는 것이 효과적입니다. 각 기능의 존재 이유를 이해하면 시험장에서 처음 보는 시나리오도 논리적으로 풀어낼 수 있습니다.