퇴사자 계정과 권한은 무엇부터 어떤 순서로 정리해야 합니까

계정이 아니라 접근 수단을 셉니다

퇴사 처리에서 빠지는 것은 대개 계정이 아니라 계정 밖의 접근 수단입니다. 메일과 사내 포털은 인사 시스템과 연결돼 자동으로 막히지만, 그 사람이 만든 클라우드 액세스 키, 협업 도구의 API 토큰, 여러 명이 같이 쓰던 관리자 계정의 비밀번호, 개인 휴대전화에 등록된 MFA 앱은 어느 시스템도 대신 회수해 주지 않습니다.

그래서 첫 작업은 차단이 아니라 목록 만들기입니다. 사람 기준으로 「이 사람이 접근할 수 있었던 모든 것」을 적어야 빠짐이 보입니다. 시스템 기준으로 계정 목록을 훑으면 개인 계정은 찾지만 공유 계정과 키는 놓칩니다.

순서: 차단, 교체, 회수, 기록

1. SSO 차단
2. 개인 키·토큰 교체
3. 공유 계정 비밀번호·MFA 회수
4. 권한 변경 내역 보관
5. 30일 뒤 잔존 접근 재확인

통합 로그인 차단이 가장 먼저인 이유는 효과 범위가 가장 넓기 때문입니다. SSO에 연결된 시스템은 한 번에 막히고, 연결되지 않은 시스템이 무엇인지도 그 순간 드러납니다. 다음으로 그 사람 이름으로 발급된 장기 자격 증명을 교체하고, 공유 계정의 비밀번호와 MFA 기기를 회수합니다. 마지막으로 무엇을 언제 바꿨는지 기록하고, 한 달쯤 뒤 로그인 기록과 키 사용 기록을 다시 확인해 남은 접근이 없는지 봅니다.

순서만큼 중요한 것이 시작 신호입니다. 인사 담당자가 퇴사일을 알게 된 시점과 IT 담당자가 그 사실을 아는 시점이 다르면, 계정은 마지막 근무일이 한참 지난 뒤에야 막힙니다. 퇴사 확정 정보가 IT 쪽으로 자동 전달되도록 인사 절차에 연결해 두고, 갑작스러운 퇴사처럼 즉시 차단이 필요한 경우의 연락 경로도 따로 정해 둡니다.

AWS는 장기 자격 증명이 꼭 필요한 경우 직원이 퇴사할 때처럼 필요한 시점에 액세스 키를 교체하고, 키를 안전하게 교체·삭제하려면 마지막 사용 정보(last used)를 활용하라고 권합니다. 사람이 쓰는 계정은 애초에 IAM Identity Center 같은 통합 로그인으로 들어와 임시 자격 증명을 받도록 바꿔 두면, 다음 퇴사 때 정리할 키 자체가 줄어듭니다.

지우기 전에 사용처를 확인해야 하는 것

퇴사자 이름의 액세스 키를 바로 삭제하면 그 키로 돌던 배포나 야간 작업이 멈추는 일이 생깁니다. 개인 계정으로 만든 키를 서버 설정이나 배포 파이프라인에 넣어 둔 경우가 적지 않기 때문입니다. 순서는 다음과 같습니다.

1. 사용 기록 확인키의 마지막 사용 시각과 서비스, 호출 위치를 봅니다.
2. 대체 자격 증명 준비사람이 아닌 작업용 역할이나 서비스 계정을 만들어 같은 일을 하게 합니다.
3. 비활성화삭제하지 않고 먼저 끕니다. 문제가 생기면 즉시 되돌릴 수 있습니다.
4. 관찰 후 삭제정해 둔 관찰 기간 동안 오류가 없으면 삭제합니다.

공유 계정도 같습니다. 도메인 등록 업체, DNS, 결제 대행, 광고 플랫폼처럼 한 사람이 오래 관리해 온 계정은 복구 이메일과 전화번호가 그 사람 개인 정보로 남아 있는 경우가 있습니다. 비밀번호만 바꾸면 복구 절차로 다시 들어올 수 있으므로 복구 수단까지 회사 소유로 바꿔야 정리가 끝납니다.

메일 계정에는 하나 더 볼 것이 있습니다. 자동 전달 규칙입니다. 퇴사 전에 업무 메일을 개인 메일로 자동 전달하도록 설정해 두면, 계정을 막기 전까지 들어온 업무 메일이 그대로 회사 밖으로 나갑니다. 메일을 다른 담당자에게 넘기려고 계정을 바로 막지 않고 유지하는 경우라면 더 그렇습니다. 퇴사 처리 때 전달 규칙과 외부 앱 연결 권한(다른 서비스에 메일·드라이브 접근을 허용한 기록)을 함께 확인하고 지웁니다.

같은 절차는 외주 개발사·유지보수 업체·파견 인력에게도 적용해야 합니다. 계약이 끝나도 인사 시스템에는 기록이 없어 퇴사 처리 대상에서 빠지기 쉽고, 외부 인력에게 준 원격 접속 계정이나 클라우드 권한은 계약 종료 뒤에도 그대로 남는 경우가 있습니다. 외부 인력 계정에는 처음부터 만료일을 붙여 발급하고, 계약 종료일을 퇴사일과 같은 신호로 다루는 것이 안전합니다.

개인정보처리시스템이라면 법이 정한 기준이 있습니다

개인정보의 안전성 확보조치 기준 제5조는 개인정보처리시스템의 접근 권한에 대해 세 가지를 요구합니다. 개인정보취급자가 바뀌거나 업무가 바뀌면 지체 없이 권한을 변경 또는 말소하고, 권한 부여·변경·말소 내역을 기록해 최소 3년간 보관하며, 계정은 취급자별로 발급해 공유하지 않도록 하는 것입니다.

마지막 항목은 퇴사 처리와 직접 연결됩니다. 여러 명이 같은 관리자 계정을 쓰면 한 사람이 나갈 때 남은 사람 모두의 비밀번호를 바꿔야 하고, 누가 무엇을 했는지도 가려낼 수 없습니다. 퇴사 처리가 번거롭다면 공유 계정을 개인 계정으로 쪼개는 것이 근본적인 해결입니다.

퇴사일 기준 체크리스트

• 퇴사 예정 통보 시점에 접근 수단 목록 작성
• 퇴사 시각에 SSO·메일·원격 접속 차단
• 개인 이름의 클라우드 키·API 토큰 사용처 확인 후 교체
• 공유 계정 비밀번호, MFA 기기, 복구 이메일·전화번호 변경
• 업무 파일·SaaS 소유권 이전
• 권한 말소 내역 기록과 보관
• 약 30일 뒤 로그인·키 사용 기록 재확인

빌드업웍스가 IAM 권한을 정비할 때도 어떤 계정으로 누가 접근하는지, 그중 애플리케이션·배포 도구처럼 사람이 아닌 주체가 무엇인지를 먼저 구분합니다. 개인 이름의 키가 배포나 예약 작업에 쓰이고 있다면 퇴사 처리 때가 아니라 평소에 작업용 역할로 옮겨 두어야 정리가 쉬워집니다.

참고 자료

• 개인정보의 안전성 확보조치 기준 제5조(접근 권한의 관리) — 국가법령정보센터
• Security best practices in IAM — AWS 문서
• Manage access keys for IAM users — AWS 문서