Azure SC-900: 접근 거버넌스 — 조건부 액세스, RBAC, PIM
회사 건물에 들어가는 것과 회사 내 특정 방에 들어가는 것은 다릅니다. 그리고 같은 방이라도 평일과 주말, 정규 직원과 인턴에게 다른 규칙을 적용할 수 있습니다. 현대 클라우드 보안은 이처럼 정교하고 세밀한 접근 제어를 요구합니다. 이 글에서는 Azure의 접근 거버넌스 핵심 도구들을 살펴봅니다.
조건부 액세스: 상황에 따른 스마트 보안
경비원이 건물 입장을 결정할 때 단순히 출입증만 확인하지 않는다고 생각해보세요. "이 사람이 근무 시간에 정문으로 들어오는가? 아니면 새벽 3시에 후문으로 들어오려 하는가? 안면 인식이 맞는가? 등록된 차량으로 왔는가?" 이런 여러 조건을 종합하여 판단합니다.
Microsoft Entra ID의 조건부 액세스(Conditional Access)가 바로 이런 역할을 합니다. 단순히 "비밀번호가 맞는지"만 확인하는 것이 아니라, 여러 신호(Signal)를 종합하여 접근을 허용, 차단, 또는 추가 인증을 요구합니다.
신호 (Signal): 어떤 정보를 수집하나
사용자 관련: 누가 로그인하려는가? (관리자인가, 일반 직원인가) 위치 관련: 어디서 로그인하는가? (한국 사무실인가, 해외인가, 알려진 나쁜 위치인가) 기기 관련: 어떤 기기를 사용하는가? (회사 관리 기기인가, 개인 기기인가) 앱 관련: 어떤 애플리케이션에 접근하려는가? (민감한 재무 시스템인가, 일반 이메일인가) 위험 관련: Microsoft가 AI로 탐지한 로그인 위험도 (비정상적인 패턴인가)
결정 (Decision): 무엇을 할 것인가
수집된 신호를 바탕으로 세 가지 결정을 내릴 수 있습니다:
허용: 정상적인 조건이면 접근을 허용합니다.
차단: 위험하다고 판단되면 접근을 완전히 차단합니다.
조건부 허용: MFA 추가 인증을 요구하거나, 비밀번호 변경을 요청하거나, 준수 상태인 기기에서만 접근 허용 등의 조건을 달아 허용합니다.
실제 활용 예시
시나리오 1: 직원이 한국 사무실에서 평일 업무 시간에 이메일에 접근 → 정상 조건, 바로 허용.
시나리오 2: 같은 직원이 새벽 2시에 나이지리아 IP에서 Azure 관리 포털에 접근 시도 → 위험 신호 감지, 차단 또는 MFA 요구.
시나리오 3: 개인 스마트폰으로 회사 파일에 접근 → 기기가 회사 정책 미준수, MFA + 읽기 전용 접근만 허용.
Entra 역할 vs Azure RBAC: 두 개의 별개 시스템
학교를 생각해보면, 교장은 학교 전체 운영을 관리하지만 서울시 교육 행정을 관리하지는 않습니다. 시청 공무원은 행정을 처리하지만 학교 커리큘럼을 결정하지 않습니다. 역할이 다릅니다.
Azure에도 목적이 다른 두 개의 역할 시스템이 존재합니다.
Microsoft Entra ID 역할
Microsoft Entra ID 자체를 관리하는 역할입니다. 사용자 계정, 그룹, 라이선스, 앱 등록 등 ID 관련 것들을 누가 관리할 수 있는지 결정합니다.
대표 역할: 전역 관리자 (Global Administrator): Entra ID의 모든 것을 관리. 최고 권한. 사용자 관리자 (User Administrator): 사용자와 그룹만 관리. 헬프데스크 관리자 (Helpdesk Administrator): 비밀번호 재설정 등 제한된 작업만 가능.
Azure RBAC (역할 기반 접근 제어)
Azure 리소스(VM, 스토리지, 데이터베이스 등)를 누가 관리할 수 있는지 결정합니다. Entra ID의 역할과는 완전히 별개의 시스템입니다.
대표 역할: 소유자 (Owner): 모든 리소스 접근 및 다른 사람에게 권한 위임 가능. 기여자 (Contributor): 리소스 생성/수정/삭제 가능, 권한 위임 불가. 읽기 권한자 (Reader): 리소스 조회만 가능.
중요한 차이점
Entra ID 전역 관리자가 된다고 해서 자동으로 Azure 구독의 모든 리소스에 접근할 수 있는 것은 아닙니다. 반대로 Azure 구독 소유자가 된다고 Entra ID를 관리할 수 있는 것도 아닙니다. 이 두 시스템은 독립적으로 운영됩니다.
Azure RBAC는 범위(Scope)에 따라 적용됩니다: 관리 그룹 → 구독 → 리소스 그룹 → 개별 리소스. 상위 범위의 역할은 하위 범위에 상속됩니다.
!Entra ID 역할 vs Azure RBAC
PIM: 필요할 때만 높은 권한을
경비 회사에서 열쇠를 관리한다고 상상해보세요. 금고를 열어야 할 때만 금고 열쇠를 빌리고, 작업이 끝나면 반납합니다. 항상 금고 열쇠를 들고 다니는 것은 위험합니다. 잃어버리거나 도둑맞을 수 있으니까요.
PIM(Privileged Identity Management, 권한 있는 ID 관리)은 이 원리를 IT 보안에 적용합니다.
PIM이 해결하는 문제
기존 방식의 문제: 관리자 권한이 필요한 사람에게 관리자 계정을 만들어 24시간 권한을 유지합니다. 이 계정이 탈취되면 공격자는 무한한 권한을 갖게 됩니다.
PIM 방식: 필요할 때만 임시로 권한을 활성화합니다. 평소에는 일반 사용자 권한을 가지다가, 관리 작업이 필요할 때 "권한 활성화" 요청을 합니다.
PIM의 핵심 기능
적시 접근 (Just-in-Time Access): 필요한 시간 동안만 권한을 활성화합니다. 2시간 관리 작업 예정이면 2시간만 권한을 부여합니다.
승인 워크플로: 높은 권한을 활성화하려면 관리자의 승인이 필요하도록 설정할 수 있습니다. "왜 이 권한이 필요한지" 사유를 제출해야 합니다.
시간 제한: 권한이 자동으로 만료됩니다. 사람이 직접 해제하지 않아도 지정된 시간이 지나면 권한이 사라집니다.
알림 및 감사: 누가 언제 어떤 권한을 활성화했는지 모두 기록되고 알림이 전송됩니다.
MFA 요구: 권한 활성화 시 MFA를 요구하여 추가 보안을 확보합니다.
액세스 검토: 권한을 정기적으로 점검
구독 서비스를 생각해보세요. 가끔 "이 서비스 아직 쓰고 있나?" 하고 점검하지 않으면, 쓰지도 않는 서비스에 계속 돈을 내게 됩니다. 조직의 접근 권한도 마찬가지입니다.
직원이 부서를 이동했습니다. 이전 부서의 시스템에 대한 접근 권한은 자동으로 없어지지 않습니다. 퇴사한 직원의 계정이 완전히 비활성화되었는지 확인이 필요합니다.
액세스 검토(Access Reviews)는 이런 "권한 청소"를 체계적으로 수행하는 도구입니다.
어떻게 작동하나
정기 검토 일정을 설정합니다. 예: 매 분기마다 모든 관리자 계정 검토.
검토자(관리자, 리소스 소유자, 또는 사용자 본인)가 각 접근 권한이 여전히 필요한지 승인 또는 거부합니다.
자동화: 검토 결과에 따라 자동으로 권한을 제거하도록 설정할 수 있습니다.
누가 검토하나
관리자가 검토: 팀장이 팀원들의 접근 권한을 검토합니다. 리소스 소유자가 검토: 특정 시스템의 담당자가 그 시스템에 대한 접근을 검토합니다. 사용자 본인이 검토: 사용자에게 "이 접근이 아직 필요한가요?"를 묻습니다.
권한 관리 (Entitlement Management): 접근 패키지로 간편하게
새 직원이 입사하면 어떤 시스템에 접근해야 할까요? IT 팀에 이메일 보내고, 따로 요청하고, 승인 기다리고... 복잡합니다. 특히 조직이 크다면 더욱 그렇습니다.
권한 관리(Entitlement Management)는 이를 간소화합니다. 역할별로 필요한 접근 권한들을 "액세스 패키지"로 묶어 관리합니다.
예: "마케팅팀 신규 직원" 패키지 = SharePoint 마케팅 사이트 + Teams 마케팅 채널 + CRM 시스템 읽기 권한
새 마케팅팀 직원은 이 패키지 하나를 요청하면, 필요한 모든 접근이 한 번에 부여됩니다. 만료 날짜를 설정하여 계약직의 경우 계약 종료일에 자동으로 접근이 제거됩니다.