처음에는 맞았던 권한이 왜 위험해질까: 아이덴티티 드리프트 점검 가이드
입사·이동·퇴사와 앱 설정 변경이 누적되며 계정과 권한이 기준에서 벗어나는 아이덴티티 드리프트를 발견하고 줄이는 방법을 소개합니다.
SSO와 MFA를 도입한 날에는 사용자, 그룹, 앱 권한이 모두 정책과 일치할 수 있습니다. 그러나 조직 개편, 프로젝트 종료, 예외 승인, 수동 계정 생성이 반복되면 실제 상태는 처음 정한 기준에서 조금씩 벗어납니다. 이를 아이덴티티 드리프트(identity drift)라고 합니다.
최근 IAM에서는 분기마다 목록을 확인하는 것만으로는 부족하다는 문제의식이 커지고 있습니다. 중요한 것은 도구를 더 추가하는 일이 아니라, 계정과 권한의 변화를 계속 비교하고 발견된 차이를 회수까지 연결하는 운영입니다.
아이덴티티 드리프트는 어디에서 생길까요?
사용자 상태와 외부 계정이 어긋납니다
AxiPass에서 사용자를 정지했지만 대상 SaaS의 계정은 활성 상태로 남거나, 퇴사 처리 뒤에도 로컬 로그인 경로가 유지될 수 있습니다. SCIM 연결 오류나 수동 처리 누락처럼 작은 실패가 쌓이면 중앙 로그인만 보고는 실제 접근 가능 여부를 알기 어렵습니다. SCIM 오프보딩 자동화는 처리 속도를 높이지만, 대상 서비스에서 반영됐는지 확인하는 절차까지 있어야 합니다.
직무가 바뀌어도 이전 권한이 남습니다
부서 이동이나 프로젝트 종료 뒤 기존 그룹을 제거하지 않으면 새 권한 위에 과거 권한이 누적됩니다. 개별 사용자에게 직접 부여한 권한은 그룹 정책보다 발견하기도 어렵습니다. 그룹 기반 앱 접근 정책을 기준선으로 삼고, 실제 그룹 소속과 앱 할당의 차이를 정기적으로 비교해야 합니다.
SSO 밖의 접근 경로가 늘어납니다
OIDC·SAML 앱만 점검하면 로컬 관리자, 공유 계정, SWA로 연결한 앱이 빠질 수 있습니다. 비상 계정이나 임시 예외에는 소유자, 사유, 만료일이 있어야 하며, 기한이 지나면 자동으로 검토 대상으로 올라와야 합니다.
분기별 검토에서 지속 점검으로 바꾸세요
1. 기대 상태를 먼저 정의합니다
테넌트별 활성 사용자, 소속 그룹, 허용 앱, MFA 적용 대상, 외부 계정 상태를 기준선으로 정합니다. 같은 이메일이라도 고객사 테넌트가 다르면 별도의 아이덴티티로 취급해야 합니다.
2. 차이를 위험도 순으로 분류합니다
퇴사자의 활성 계정, 관리자 권한, MFA 예외는 즉시 확인하고, 장기 미사용 계정이나 종료일이 가까운 협력사 권한은 후속 검토로 나눕니다. 단순 개수보다 방치 기간과 접근 가능한 데이터의 중요도를 함께 보세요.
3. 발견에서 조치 완료까지 기록합니다
경고를 만드는 것만으로는 드리프트가 줄지 않습니다. 발견 시각, 담당자, 유지·변경·회수 결정, 실제 반영 결과를 감사 기록으로 남겨야 합니다. 개선 효과는 SSO 도입 후 보안 지표의 계정 회수 시간과 예외 만료율처럼 반복 가능한 수치로 확인할 수 있습니다.
AxiPass로 고객사별 기준과 실제 상태를 연결하세요
AxiPass는 멀티 테넌트 환경에서 OIDC/SAML SSO, SCIM 프로비저닝, MFA, 그룹 기반 접근, SWA와 감사 로그를 함께 운영하도록 돕습니다. 모든 외부 SaaS의 상태를 자동으로 보장할 수는 없으므로, 연결 가능한 계정은 자동화하고 나머지 예외는 책임자와 검토 기한을 명시하는 방식이 현실적입니다. 한 번 완성된 권한표보다 계속 차이를 발견하고 닫는 운영 체계를 만드세요.