입사·이동·퇴사 자동화: 계정 수명주기를 끊김 없이 관리하는 법
입사·부서 이동·퇴사 때마다 달라지는 SaaS 계정과 권한을 JML 워크플로, SSO, SCIM, MFA, 감사 로그로 일관되게 관리하는 방법을 소개합니다.
사용자 계정의 위험은 로그인 순간에만 생기지 않습니다. 입사자는 업무 첫날 필요한 앱을 받지 못하고, 이동한 직원에게는 이전 부서 권한이 남으며, 퇴사자의 외부 SaaS 계정은 며칠 뒤까지 활성 상태일 수 있습니다. 이 세 전환을 JML(Joiner·Mover·Leaver) 수명주기로 묶어 관리해야 하는 이유입니다.
최근 IAM의 핵심 화두도 인증 기능을 하나 더 추가하는 데서 사람과 앱, 권한의 변화를 지속적으로 통제하는 방향으로 이동하고 있습니다. 자동화의 목표는 단순히 빠른 계정 생성이 아니라, 승인된 상태가 모든 연결 시스템에 같은 기준으로 반영되고 그 결과가 기록되는 것입니다.
JML 단계마다 통제해야 할 것이 다릅니다
Joiner: 첫 로그인 전에 최소 권한을 준비합니다
입사자의 소속, 역할, 시작일을 기준으로 그룹과 앱을 배정하고 MFA 등록을 요구합니다. OIDC·SAML 앱은 SSO 정책으로 연결하되, 첫 로그인만으로 과도한 앱이 자동 생성되지 않도록 기본 권한을 좁게 시작해야 합니다. 계정 생성과 실제 업무 접근 허용도 구분하세요.
Mover: 새 권한 추가보다 이전 권한 회수가 먼저입니다
부서 이동이나 프로젝트 변경 때 새 그룹만 더하면 권한이 계속 누적됩니다. 변경 전후의 그룹과 앱 배정을 비교하고, 이전 역할의 접근을 먼저 제거한 뒤 새 권한을 적용해야 합니다. 그룹 기반 앱 접근 정책을 기준선으로 삼으면 개인별 예외를 줄일 수 있습니다.
Leaver: 중앙 로그인과 외부 계정을 함께 닫습니다
IdP 사용자를 정지해도 SaaS의 로컬 세션, SCIM 계정, SWA 자격증명이 남으면 접근 경로가 완전히 닫힌 것이 아닙니다. 퇴사 이벤트에서 SSO 세션과 앱 배정을 회수하고, 연결된 서비스에는 비활성화를 전달한 뒤 실제 반영 여부를 확인해야 합니다. 상세 절차는 SCIM 오프보딩 자동화에서 확인할 수 있습니다.
안전한 자동화에는 세 가지 안전장치가 필요합니다
승인, 재시도, 감사 기록을 분리하세요
자동화 규칙에는 누가 어떤 조건으로 변경을 승인했는지, 일부 SaaS 연동이 실패하면 어디서 재시도하는지, 최종 결과를 어떻게 확인하는지가 포함돼야 합니다. 한 서비스의 장애가 전체 퇴사 처리를 되돌리게 해서는 안 됩니다. 중앙 접근은 즉시 차단하고 외부 반영 실패는 별도 조치 대상으로 남기는 방식이 안전합니다.
예외에는 소유자와 만료일을 붙이세요
관리자 계정, 공유 계정, SCIM 미지원 앱은 자동화에서 빠지기 쉽습니다. 예외를 허용하더라도 책임자, 사유, 검토일을 기록하고 만료 시 다시 점검해야 합니다. 주기적인 아이덴티티 드리프트 점검을 함께 운영하면 자동화 밖의 차이도 발견할 수 있습니다.
AxiPass로 계정 변화의 시작과 끝을 연결하세요
AxiPass는 고객사별 멀티 테넌트 환경에서 OIDC/SAML SSO, SCIM 프로비저닝, MFA, 그룹 기반 접근, SWA와 감사 로그를 함께 관리하도록 돕습니다. 먼저 퇴사처럼 위험이 큰 전환부터 표준화하고, 이후 입사와 이동까지 같은 사용자·그룹·앱 기준으로 확장하세요. 좋은 JML 자동화의 완료 조건은 작업 실행이 아니라, 필요한 접근만 남았다는 확인입니다.