퇴사자 계정이 살아 있는 진짜 이유

한 줄 요약

퇴사자 계정이 살아 있는 이유는 퇴사 처리를 안 해서가 아니라 인사 시스템과 계정 시스템을 잇는 프로비저닝이 없어서다. SSO 는 이 문제를 풀지 않는다.

감사에서 가장 먼저 물어보는 것

정보보호 감사나 ISMS-P 심사에서 계정 관련 질문은 거의 정해져 있다.

1. 퇴사자 계정이 즉시 비활성화됩니까? 근거를 보여 주세요.
2. 관리자 권한을 가진 계정 목록과 부여 사유를 보여 주세요.
3. 최근 N 개월간 미접속 계정을 어떻게 관리합니까?
4. 계정 생성·변경·삭제 이력이 남습니까?
5. 인사 시스템과 계정 시스템의 대사(對査)를 주기적으로 합니까?

5번이 핵심이다. 나머지 넷의 답이 다 이것에서 나온다.
그리고 대부분의 조직이 5번을 사람이 엑셀로 한다.

유령 계정은 왜 생기는가

"퇴사 처리를 안 해서"가 아니다. 구조적인 원인이 있다.

원인 1 — 프로비저닝이 없다

가장 큰 원인이다. SSO 를 붙였다고 계정 수명주기가 해결되는 것이 아니다.

> **"퇴사자가 SaaS 에 여전히 로그인 가능"한 사고의 대부분은
> SSO 가 아니라 프로비저닝 부재 때문이다.**

SSO 는 "로그인할 때 누구인지 확인"할 뿐이다.
그 시스템 안에 사용자 레코드를 만들고 지우는 것은 별개의 일이고,
그걸 자동화하는 표준이 SCIM(RFC 7644) 이다.

SCIM 이 없으면 이렇게 된다. 사람이 나가면 IdP 에서는 로그인이 막힌다.
그런데 개별 시스템에는 계정이 남아 있고, 그 시스템에 **로컬 로그인 경로가
하나라도 있으면** 여전히 들어갈 수 있다. 그리고 대부분의 시스템에는
"IdP 장애 시 비상 로그인"이라는 이름의 로컬 경로가 있다.

원인 2 — 증분 동기화는 삭제를 못 본다

앞 모듈에서 다룬 내용이다. "최근 변경된 사용자"를 가져오는 방식은
사라진 사용자를 볼 수 없다. 전체 동기화를 주기적으로 함께 돌리지 않으면
퇴사자가 계속 남는다.

원인 3 — 사람이 아닌 계정

배치용 계정, 연동용 계정, 벤더 유지보수 계정, 테스트 계정.
이들은 인사 시스템에 없으므로 대사 대상에서 자동으로 빠진다.
그리고 이들이 대개 권한이 세다.

감사에서 지적 순위가 높은 것도 이쪽이다.
"이 계정은 누구 것입니까?" → "예전에 벤더가 쓰던 것 같은데요."

원인 4 — 퇴사가 아닌 이동

휴직, 파견, 협력사 계약 종료, 부서 이동. 이런 상태 변화는
퇴사만큼 명확한 트리거가 없다. 그래서 권한이 그대로 따라다닌다.
부서를 옮겼는데 이전 부서 권한이 남아 있는 것은 감사에서
"권한 누적(privilege creep)"으로 지적된다.

대사(對査)를 기계적으로 하는 법

인사 명부(HR)와 계정 목록(디렉터리)을 양쪽에서 뽑아 집합 연산을 한다.

A = HR 재직자 uid 집합B = 디렉터리 계정 uid 집합B - A  →  유령 계정 (퇴사했는데 계정이 남음)          ★ 1순위A - B  →  미생성 계정 (입사했는데 계정이 없음)         업무 지연A ∩ B  →  정상. 단 부서·직급 불일치는 따로 본다

여기에 세 가지 축을 더한다.

• 권한 축: 유령 계정 중 관리자 그룹 소속 → 즉시 조치 대상
• 시간 축: 90일 이상 미접속 → 휴면 처리 후보
• 속성 축: HR 부서 ≠ 디렉터리 부서 → 인사이동 미반영

이 다섯 개 목록을 매주 자동으로 생성해 메일로 보내면
감사 대응이 아니라 운영이 된다. 수작업 엑셀 대사는 분기에 한 번 하고,
그 사이에 사고가 난다.

계정 삭제 vs 비활성화

퇴사자 계정을 지우면 안 된다. 이유가 여럿이다.

• 감사 추적: 그 사람이 남긴 데이터의 소유자 정보가 깨진다
• 법적 보존: 금융·의료 등은 접근 이력 보존 기간이 길다
• 재입사: 같은 사람이 돌아오는 경우가 있다
• 참조 무결성: 결재선, 담당자 지정, 문서 작성자에 걸려 있다

그래서 표준적인 처리는 격리다.

1. 비활성화 (로그인 차단)          ← 즉시2. 권한 그룹에서 제거              ← 즉시3. 별도 OU 로 이동 (ou=Disabled)   ← 즉시4. 사유·일자·처리자 기록           ← 즉시5. 보존 기간 경과 후 삭제          ← 정책에 따라 (보통 1~5년)

3번이 실무적으로 유용하다. 격리 OU 로 옮기면
"활성 사용자" 검색 필터에서 자동으로 빠지면서도 데이터는 남는다.
그리고 격리 OU 의 엔트리 수를 세는 것만으로 조치 건수를 보고할 수 있다.

권한 부여의 원칙 — 그룹으로만

개인에게 직접 권한을 주기 시작하면 6개월 뒤 아무도 전체 그림을 모른다.
원칙은 이렇다.

• 권한은 역할 그룹에만 붙인다
• 사람은 역할 그룹의 멤버가 된다
• 개인 예외가 필요하면 기한이 있는 별도 그룹을 만든다

그리고 부서 그룹과 역할 그룹을 섞지 마라.
dev-team 은 조직이고 role-deploy 는 권한이다. 조직 개편은 자주 일어나고,
그때마다 권한이 함께 무너지면 안 된다.

감사 리포트에 들어가야 할 다섯 숫자

리포트는 길 필요가 없다. 이 다섯 개면 대화가 시작된다.

| 항목 | 의미 |
| --- | --- |
| 전체 계정 수 | 기준선 |
| 유령 계정 수 | 퇴사자 잔존 — 0 이어야 한다 |
| 미생성 계정 수 | 입사자 지연 — 업무 지연 지표 |
| 특권 계정 중 유령 | 최우선 조치 |
| 90일 미접속 계정 수 | 휴면 후보 |

숫자가 있으면 추세를 볼 수 있다. "유령 계정이 지난달 12건에서 이번 달 3건"은
개선을 증명한다. 숫자가 없으면 매번 처음부터 설명해야 한다.

현장에서 만나는 모습

감사 질문 다섯 개 중 마지막 하나가 핵심이다 — "인사 시스템과 계정 시스템의 대사를 주기적으로 합니까?" 나머지 넷의 답이 전부 여기서 나오는데, 대부분의 조직이 이걸 사람이 엑셀로 한다.

엑셀 대사의 문제는 정확도가 아니라 주기다. 분기에 한 번 맞춰 보는 대사로는 퇴사 다음 날 계정이 죽지 않는다. 그리고 그 사이의 접근은 기록으로만 남는다 — 막지는 못하고 나중에 발견만 하는 통제다.

증분 동기화만 걸어 둔 경우도 흔한데, 이건 더 위험하다. 변경된 것만 가져오는 방식은 삭제를 못 본다. 인사에서 사라진 사람은 '변경' 이 아니므로 영원히 넘어오지 않고, 계정은 조용히 남는다.

그래서 계정을 지우기 전에 격리하는 절차가 필요하다. 바로 지우면 그 사람이 만든 문서나 결재선이 함께 깨지고, 되돌릴 수도 없다.