Entra ID 자동화 #5 PIM과 감사: 상시 관리자 없애기, 로그와 액세스 리뷰

도구 Microsoft Graph Entra ID
5 분 소요

트랙의 마지막 주제는 권한의 꼭대기와 그 기록입니다. 관리자 권한을 어떻게 최소로 유지하는가, 그리고 누가 무엇을 했는지를 어떻게 자동으로 감시하는가. 여기까지 갖추면 1편에서 그린 JML 수명 주기가 권한과 감사까지 포함한 닫힌 루프가 됩니다.

문제: 상시 관리자 권한은 대기 중인 사고입니다 #

전역 관리자(Global Administrator) 권한을 상시 보유한 계정이 다섯 개 있는 조직을 생각해 봅니다. 그중 하나만 피싱에 뚫려도 테넌트 전체가 넘어갑니다. 권한은 실제로 쓰는 시간보다 보유하고 있는 시간이 압도적으로 길고, 보유한 모든 시간이 공격 표면입니다.

PIM(Privileged Identity Management)의 접근은 권한의 시간 축을 바꾸는 것입니다. Entra ID P2 또는 Governance 라이선스 기능입니다.

  • 자격(eligible) 할당: 사용자는 역할의 “후보"일 뿐 평소에는 권한이 없습니다.
  • 활성화(activation): 필요할 때 본인이 활성화를 요청합니다. 사유 입력, MFA, 필요시 승인자의 승인을 거쳐 시간제한이 있는 활성 권한(최대 8시간, 역할 설정으로 단축 가능)을 받습니다.
  • 만료: 시간이 지나면 권한이 자동 회수됩니다. 회수를 잊는다는 개념 자체가 사라집니다.

결과적으로 상시 전역 관리자는 비상 계정(4편의 break-glass)만 남기고, 사람의 일상 권한은 전부 자격 + 활성화로 바뀝니다. 모든 활성화가 사유와 함께 기록되므로 감사 대응도 “지난 분기에 누가 왜 관리자였나"를 조회 한 번으로 답할 수 있게 됩니다.

PIM을 API로: 할당과 활성화 #

PIM도 Graph로 완전히 자동화됩니다. 역할 관리는 roleManagement/directory 아래의 스케줄 요청 리소스로 이루어집니다.

  • 자격 할당(관리자): roleEligibilityScheduleRequests에 대상 사용자, 역할, 기간을 담아 POST합니다. 온보딩 자동화가 “IT팀 입사자에게 헬프데스크 관리자 자격 부여"를 코드로 처리할 수 있습니다.
  • 셀프 활성화(사용자): roleAssignmentScheduleRequests에 SelfActivate 액션으로 POST합니다. 사유(justification)가 필수이고, 티켓 번호를 함께 남기는 방식이 일반적입니다. 자신이 활성화할 수 있는 자격 목록은 filterByCurrentUser 함수로 조회합니다.
  • 역할 설정: 역할별로 최대 활성화 시간, 승인 필요 여부, MFA 요구를 정책으로 관리할 수 있습니다.

3편에서 만든 역할 할당 가능 그룹과의 조합이 실무 패턴입니다. 그룹에 역할 자격을 부여해 두면, 팀 온보딩은 그룹 멤버 추가로 끝나고 권한 사용은 개인의 활성화로 통제됩니다. 관리 단위(그룹)와 사용 통제(활성화)가 분리되는 구조입니다.

감사 로그와 로그인 로그: 기록을 코드로 소비하기 #

Entra ID는 두 종류의 핵심 로그를 남기고, 둘 다 Graph API로 조회할 수 있습니다.

로그 조회 요청 
GET https://graph.microsoft.com/v1.0/auditLogs/directoryAudits
    ?$filter=activityDateTime ge 2026-09-01T00:00:00Z

GET https://graph.microsoft.com/v1.0/auditLogs/signIns
    ?$filter=status/errorCode ne 0
  • 디렉터리 감사 로그(directoryAudits): 누가 사용자·그룹·정책·역할을 만들고 바꿨는지의 기록입니다.
  • 로그인 로그(signIns): 모든 인증 시도의 기록입니다. 실패 코드, 위치, 클라이언트 앱, 적용된 조건부 액세스 정책까지 담겨 있습니다. 4편의 report-only 영향 분석도 이 로그가 원천입니다.

자동화 관점의 활용은 두 단계입니다. 첫째, 정기 리포트. 신규 관리자 역할 부여, 비상 계정 로그인, 새 앱 등록 같은 고위험 이벤트를 매일 조회해 채널로 보내는 스크립트는 반나절 작업으로 만들 수 있고 효과가 큽니다. 둘째, SIEM 연계. 로그 볼륨이 크거나 보존 요건이 길면, 진단 설정으로 로그를 Log Analytics나 SIEM으로 흘려보내고 알림 규칙은 그쪽에서 관리하는 것이 맞습니다. Graph 폴링은 소규모와 프로토타입, 스트리밍 연계는 본격 운영이라는 구분입니다.

액세스 리뷰: 권한의 유통기한 만들기 #

JML 자동화가 아무리 잘 돼도 접근 권한은 시간이 지나며 누적됩니다. 프로젝트가 끝나도 그룹에 남아 있고, 역할이 바뀌어도 옛 앱 접근이 살아 있습니다. 액세스 리뷰(access reviews)는 이처럼 누적된 권한을 정기적으로 정리하는 기능입니다(P2 이상, 시나리오에 따라 Governance).

  • 대상(그룹 멤버십, 앱 할당, 관리자 역할)과 주기(분기 등), 검토자(그룹 소유자, 관리자, 또는 본인)를 정해 리뷰를 만듭니다.
  • 검토자가 기한 내 응답하지 않을 때의 기본 동작을 “제거"로 설정하면, 방치가 곧 정리가 됩니다. 이 설정이 액세스 리뷰의 실질을 결정합니다.
  • 리뷰 생성과 결과 수집도 Graph의 identityGovernance/accessReviews API로 자동화됩니다. “모든 관리자 역할은 분기마다 자동으로 리뷰가 생성된다"를 코드로 보장할 수 있습니다.

특히 게스트 계정과 관리자 역할, 이 둘은 액세스 리뷰의 최우선 대상입니다. 3편의 액세스 패키지 만료와 함께 쓰면, “부여된 모든 접근에는 유통기한 또는 재검토가 있다"는 상태를 만들 수 있습니다.

트랙을 마치며: 도입 순서 #

다섯 편을 실제 조직에 적용하는 현실적 순서를 정리합니다.

  1. 속성 표준화와 사용자 수명 주기(2편): 원천 데이터가 깨끗해야 나머지가 성립합니다. 퇴사 처리 자동화가 가장 급한 보안 개선입니다.
  2. 그룹 재설계(3편): 동적 그룹 + 그룹 기반 라이선스로 Mover를 무인화합니다.
  3. 조건부 액세스 정비(4편): 기본 정책 세트를 report-only로 검증해 배포하고, policy-as-code로 옮깁니다.
  4. PIM과 감사(이 편): 상시 관리자를 자격 기반으로 전환하고, 고위험 이벤트 알림과 액세스 리뷰로 루프를 닫습니다.

Graph API 호출의 기초(인증, 스로틀링, 페이지네이션)는 Microsoft Graph 실무 입문 트랙이 전제이므로, 코드가 낯설면 그쪽을 먼저 보시기 바랍니다.

정리 #

  • 상시 관리자 권한은 공격 표면입니다. PIM으로 자격 + 시간제 활성화(최대 8시간) + 사유 기록 구조로 바꾸고, 상시 권한은 비상 계정만 남깁니다.
  • PIM은 roleEligibilityScheduleRequests(자격 할당)와 roleAssignmentScheduleRequests(활성화)로 완전히 API 관리가 가능하며, 역할 할당 가능 그룹과 조합하는 것이 실무 패턴입니다.
  • 감사 로그와 로그인 로그는 Graph로 조회해 고위험 이벤트 알림을 만들고, 규모가 커지면 SIEM 스트리밍으로 승격합니다.
  • 액세스 리뷰는 권한에 유통기한을 부여합니다. 무응답 시 제거를 기본값으로 하고, 게스트와 관리자 역할부터 적용합니다.
  • 도입 순서는 사용자 수명 주기 → 그룹 → 조건부 액세스 → PIM·감사입니다. 원천 데이터 정비가 항상 첫 단계입니다.
X