Entra ID 자동화 #2 사용자 수명 주기: 생성, 비활성화, 그리고 수명 주기 워크플로

도구 Microsoft Graph Entra ID
5 분 소요

JML의 세 흐름 중 가장 빈번한 것이 사용자 계정 자체의 수명 주기입니다. 이번 편은 계정의 탄생부터 정리까지를 Graph API로 처리하는 방법과, 이 흐름을 제품 기능으로 제공하는 수명 주기 워크플로를 다룹니다. 코드는 REST 형태로 표기합니다. SDK로 옮기는 방법은 Graph 실무 입문 #3에서 다뤘습니다.

생성: 속성이 자동화의 연료입니다 #

사용자 생성은 POST /users 하나입니다. 중요한 것은 호출 자체가 아니라 무엇을 채우는가입니다.

사용자 생성 요청 
POST https://graph.microsoft.com/v1.0/users
Content-Type: application/json

{
  "accountEnabled": true,
  "displayName": "김입사",
  "userPrincipalName": "ipsa.kim@contoso.com",
  "mailNickname": "ipsa.kim",
  "employeeId": "E12345",
  "department": "Engineering",
  "jobTitle": "Backend Engineer",
  "employeeHireDate": "2026-09-15T00:00:00Z",
  "passwordProfile": {
    "password": "임시-강력-비밀번호",
    "forceChangePasswordNextSignIn": true
  }
}

employeeId, department, employeeHireDate 같은 속성을 “나중에 채우지"라고 생각하면 안 됩니다. 다음 편의 동적 그룹은 department 값으로 멤버십을 계산하고, 뒤에서 볼 수명 주기 워크플로는 employeeHireDate를 트리거로 씁니다. 속성이 부정확하면 그 위의 모든 자동화가 부정확해집니다. 속성의 원천(HR 시스템)과 표기 규칙(부서명 표준 목록)을 정하는 것이 자동화 설계의 절반입니다.

초기 자격 증명 전달은 임시 비밀번호보다 나은 방법이 있습니다. 임시 액세스 패스(TAP, Temporary Access Pass)는 시간 제한이 있는 일회성 코드로, 신규 입사자가 이것으로 첫 로그인을 하고 곧바로 비밀번호 없는 인증(Authenticator, 패스키)을 등록하게 만들 수 있습니다. 비밀번호를 이메일로 보내는 관행을 없앨 수 있는 경로입니다.

퇴사: 삭제가 아니라 차단부터 #

퇴사 처리의 순서는 보안 관점에서 정해져 있습니다.

  1. 즉시 차단: accountEnabled를 false로 바꿉니다(PATCH /users/{id}). 로그인이 막힙니다.
  2. 세션 무효화: POST /users/{id}/revokeSignInSessions로 발급된 리프레시 토큰을 무효화합니다. 비활성화만으로는 이미 로그인된 세션이 토큰 만료까지 살아 있을 수 있습니다.
  3. 접근 회수: 그룹 멤버십 제거, 라이선스 회수, 앱 할당 해제.
  4. 데이터 처리: 메일박스와 OneDrive의 보존·이관 정책 적용.
  5. 삭제는 마지막에: DELETE /users/{id}는 소프트 삭제로, 30일간 복원 가능한 상태로 휴지통에 들어갔다가 영구 삭제됩니다. 급하게 지울 이유가 없습니다. 차단된 계정을 유예 기간 뒤에 지우는 것이 표준입니다.

이 순서를 기억하는 법은 간단합니다. 퇴사 처리의 목표는 계정을 없애는 것이 아니라 접근을 끝내는 것입니다. 접근 종료(1〜3번)는 분 단위로 급하고, 계정 정리(4〜5번)는 프로세스대로 천천히 해도 됩니다.

라이선스: 개인 할당은 마지막 수단입니다 #

Graph에는 사용자에게 직접 라이선스를 붙이는 assignLicense API가 있지만, 개인별 할당을 자동화 루프에 넣는 순간 “누가 어떤 라이선스를 왜 갖는가"가 코드 속에 흩어집니다. 기본 전략은 그룹 기반 라이선스입니다. 라이선스를 그룹에 붙여 두면, 그룹에 들어온 사용자에게 자동으로 할당되고 나가면 자동으로 회수됩니다. 그러면 사용자 자동화가 할 일은 “올바른 그룹에 넣는 것"으로 줄어들고, 라이선스는 그룹 구조가 관리합니다. 자세한 구성은 다음 편(그룹)에서 다룹니다.

수명 주기 워크플로: JML을 제품 기능으로 #

여기까지의 흐름을 직접 스크립트로 짤 수도 있지만, Entra에는 이것을 제품화한 기능이 있습니다. 수명 주기 워크플로(Lifecycle Workflows)입니다. Entra ID Governance(또는 Entra Suite) 라이선스가 필요합니다.

구조는 단순합니다. 트리거(언제) + 범위(누구에게) + 태스크(무엇을).

  • Joiner 예시: employeeHireDate 7일 전에 → 영업부 신규 입사자에게 → 그룹 배정, 관리자에게 TAP 발송, 환영 메일.
  • Leaver 예시: employeeLeaveDateTime 당일에 → 전 직원 대상 → 계정 비활성화, 그룹·라이선스 제거, 며칠 후 계정 삭제.
  • 비활성 계정 정리: 일정 기간 로그인이 없는 사용자를 자동으로 비활성화·삭제하는 트리거도 지원됩니다. 방치 계정 감사를 상시 프로세스로 바꿔 줍니다.

내장 태스크로 부족한 부분은 커스텀 확장으로 Logic Apps를 호출해 외부 시스템(사내 포털, 티켓 시스템, Slack 알림)과 연결할 수 있습니다. 워크플로 자체도 Graph API(identityGovernance 네임스페이스)로 생성·관리되므로, 워크플로 정의를 코드로 두고 배포하는 구성이 가능합니다.

직접 구현과의 선택 기준은 이렇습니다. 표준 JML 흐름은 워크플로(라이선스가 있다면)가 운영 부담이 적고, 조직 고유의 복잡한 로직이나 라이선스 제약이 있으면 Graph 직접 구현이 답입니다. 둘을 섞어서, 뼈대는 워크플로에 맡기고 특수 단계만 커스텀 확장으로 붙이는 구성이 실무에서 흔합니다.

원천과의 연결: HR 주도 프로비저닝 #

마지막 조각은 “누가 이 자동화를 촉발하는가"입니다. 이상적인 답은 사람이 아니라 HR 시스템입니다. Entra의 HR 주도 프로비저닝은 Workday, SuccessFactors 같은 HR 제품과 연동해, 입사·이동·퇴사 이벤트가 HR에 기록되는 순간 Entra ID의 계정과 속성이 따라 움직이게 합니다. HR 연동이 없는 조직이라도 원칙은 같습니다. 사람 정보의 단일 원천을 정하고, 디렉터리는 그 원천을 따라가게 만드는 것. 원천이 스프레드시트라면 그 스프레드시트를 읽는 스크립트가 프로비저닝 엔진이 되는 것이고, 시작점으로는 그것도 충분합니다.

정리 #

  • 사용자 생성의 핵심은 속성 표준화입니다. department, employeeId, 입사·퇴사일이 동적 그룹과 워크플로의 입력값이 됩니다.
  • 초기 자격 증명은 임시 비밀번호 대신 임시 액세스 패스(TAP)로 전달하는 경로를 검토합니다.
  • 퇴사 처리는 차단(accountEnabled) → 세션 무효화 → 접근 회수 → 데이터 처리 → 삭제 순입니다. 삭제는 30일 소프트 삭제라 서두를 이유가 없습니다.
  • 라이선스는 그룹 기반이 기본 전략이고, 개인 할당 API는 예외 처리용입니다.
  • 표준 JML은 수명 주기 워크플로(Governance 라이선스)로, 고유 로직은 Graph 직접 구현으로. 그리고 가능하다면 트리거는 사람이 아니라 HR 시스템이어야 합니다.
X