퇴사자 계정 권한 회수 체크리스트: SaaS 접근을 빠짐없이 끊는 순서

퇴사자 계정 권한 회수는 마지막 근무일에 회사 메일을 정지하는 일로 끝나지 않습니다. 먼저 로그인을 막고 현재 세션을 끊은 뒤, 연결된 SaaS와 공유 비밀번호를 회수하고, 업무 데이터의 새 소유자를 지정해야 합니다. 마지막에는 관리자 기록으로 실제 차단 여부를 확인해야 합니다.

계정 정지와 데이터 삭제를 같은 일로 보지 않습니다

NIST SP 800-53은 퇴사 시 시스템 접근을 정해진 시간 안에 비활성화하고, 인증 수단과 자격 증명을 폐기하며, 퇴사자가 관리하던 조직 정보에는 회사가 계속 접근할 수 있어야 한다고 제시합니다. 계정 관리 절차도 인사 이동·퇴사 절차와 맞물려야 합니다.[1]

그래서 첫 조치는 삭제보다 정지에 가깝습니다. 계정을 바로 삭제하면 로그인은 막히지만 메일, 문서, 캘린더, 자동화 소유권을 넘길 시간을 잃을 수 있습니다. 반대로 계정만 정지하고 세션을 그대로 두면 이미 로그인된 기기나 별도 SaaS 세션이 남을 수 있습니다.

퇴사 확정 전에 계정 지도를 한 장으로 만듭니다

CISA와 NSA의 IAM 권고는 조직 자산을 목록화하고, 각 자산에 존재하는 로컬 계정을 파악하며, 일반 사용자 계정과 관리자·운영 계정을 분리하라고 안내합니다.[2] 회사 메일 목록만 보면 개인 초대로 가입한 디자인 도구, 광고 계정, 코드 저장소, 클라우드 콘솔 같은 바깥 계정을 놓치기 쉽습니다.

퇴사 예정자 이름으로만 검색하지 말고 다음 항목을 함께 모읍니다.

• 회사 이메일과 별칭, 보조 이메일
• Google·Microsoft 같은 중앙 로그인에 연결된 앱
• 이메일과 비밀번호로 따로 가입한 SaaS
• 관리자, 결제 담당자, 소유자 역할
• 개인 액세스 토큰, API 키, SSH 키
• 팀이 함께 쓰는 계정과 비밀번호 보관함
• 퇴사자가 단독 소유한 문서, 캘린더, 대시보드, 자동화

목록에는 서비스명, 계정 형태, 현재 권한, 데이터 인수자, 차단 담당자, 완료 증거를 적습니다. 서비스 수가 많다면 업무 자동화 설계로 인사 상태와 권한 회수 목록을 연결하되, 첫 운영은 사람이 결과를 승인하도록 두는 편이 안전합니다.

마지막 근무일에는 이 순서로 접근을 끊습니다

Microsoft는 퇴사나 계정 침해 상황에서 새 로그인을 차단하고 refresh token을 해지해도, 애플리케이션이 자체 세션 토큰을 쓰거나 별도 로그인을 허용하면 접근 종료까지 시간이 걸릴 수 있다고 설명합니다. 자동 프로비저닝을 지원하지 않는 앱은 수동 해지 절차를 따로 마련해야 합니다.[3]

1. 인사 담당자가 퇴사 효력 시각과 대상자를 확정합니다.
2. 중앙 계정을 비활성화하고 모든 로그인 세션을 해지합니다.
3. 관리자 역할, 그룹, 공유 드라이브, 광고·결제 계정 권한을 제거합니다.
4. 중앙 로그인 밖의 SaaS에서 사용자를 삭제하거나 비활성화합니다.
5. 개인 토큰과 기기 인증서를 폐기하고, 공유 자격 증명은 교체합니다.
6. 회사 관리 기기와 출입 수단을 회수하거나 원격 차단합니다.
7. 메일, 문서, 캘린더, 대시보드, 자동화의 소유자를 바꿉니다.

계정 정지 화면을 봤다는 사실보다, 퇴사자 자격으로 다시 접근할 수 없음을 확인한 기록이 더 중요합니다.

갑작스러운 퇴사라면 접근 차단을 데이터 인계보다 먼저 실행합니다. 예정된 퇴사라면 인계 대상을 미리 정해 두되, 권한 회수 시각은 퇴사 효력과 맞춥니다. 관리자 권한이 있는 사람은 일반 계정보다 먼저 또는 동시에 차단하도록 별도 순서를 정합니다.

공유 계정과 자동화 자격 증명을 따로 점검합니다

공유 계정은 사용자를 목록에서 삭제해도 비밀번호를 아는 사람이 계속 접속할 수 있습니다. NIST도 구성원이 그룹에서 빠질 때 공유·그룹 계정의 인증 정보를 바꾸는 절차를 계정 관리 통제에 포함합니다.[1]

다음 조건 중 하나라도 맞으면 비밀번호나 키를 교체합니다.

• 퇴사자가 공유 비밀번호를 열람할 수 있었음
• 자동화 도구에 퇴사자 개인 토큰이 저장돼 있음
• 클라우드나 저장소에 개인 SSH 키가 등록돼 있음
• 광고·결제 서비스의 복구 수단이 개인 연락처로 연결돼 있음
• 웹훅, 배포, 보고서 발송이 퇴사자 계정 소유임

교체 뒤에는 자동화가 실제로 한 번 정상 실행되는지 확인합니다. 키를 바꿨지만 배포나 결제 알림이 멈춘 상태라면 보안 처리는 끝났어도 업무 인계는 끝나지 않은 것입니다.

완료 표시는 관리자 로그와 재접속 시험 뒤에 합니다

처리표의 상태를 '요청', '차단', '검증'으로 나누면 누락을 찾기 쉽습니다. 담당자가 삭제 버튼을 눌렀다는 기록은 처리 증거이고, 새 로그인 거부·기존 세션 종료·권한 목록 제외를 확인한 결과는 검증 증거입니다. 둘을 한 칸에 섞지 않습니다.

최종 점검에는 아래 항목을 남깁니다.

• 중앙 계정의 비활성 상태와 세션 해지 시각
• 주요 SaaS 사용자 목록에서 계정이 사라졌거나 비활성화된 상태
• 관리자·소유자·결제 담당 역할의 새 담당자
• 교체한 공유 비밀번호와 키의 대상 목록
• 인계한 데이터와 보존 기간을 결정한 책임자
• 실패했거나 접근할 수 없어 후속 조치가 필요한 서비스

작은 팀이라도 분기마다 최근 퇴사자 한 명을 골라 표본 점검해 보세요. 새 SaaS가 계속 늘기 때문에 지난번 체크리스트만 믿으면 사각지대가 생깁니다.

바로 쓸 수 있는 최소 운영 규칙

복잡한 시스템이 없어도 세 가지 규칙은 바로 정할 수 있습니다. 첫째, 새 SaaS를 도입할 때 관리자와 데이터 소유자를 기록합니다. 둘째, 퇴사 통보가 들어오면 인사 담당자 한 명과 IT·운영 담당자 한 명이 같은 회수표를 봅니다. 셋째, 완료는 버튼을 누른 시점이 아니라 차단 결과를 확인한 시점으로 적습니다.

퇴사자 계정 관리는 사람을 의심하는 절차가 아닙니다. 회사 자료의 책임자를 바꾸고, 떠나는 사람에게도 불필요한 접근 책임이 남지 않게 정리하는 운영 절차입니다.