계정을 비활성화하면 더는 로그인할 수 없습니다. 그 사람이 만든 접근 수단은 그대로 남고, 무엇을 실행했는지도 알 수 없습니다.
팀의 핵심 SRE가 금요일에 퇴사합니다. IT팀은 아이덴티티 공급자 계정을 비활성화하고 티켓을 닫습니다. 오프보딩 통제 항목도 녹색으로 바뀝니다. 그러나 월요일 아침에도 배포 파이프라인용 개인 API 토큰, 야간 작업용 서비스 계정, 코딩 에이전트의 MCP 연동은 계속 작동합니다. 현재 팀원 누구보다 오래된 로컬 계정도 네 대의 호스트에 남아 있습니다.
사람의 로그인은 차단했지만 그 사람이 만든 접근 수단은 남았습니다. 감사관이 지난 3년간 이 직원이 프로덕션에서 무엇을 실행했는지 물어도 답할 사람이 없습니다.
반복되는 원인은 회수 절차를 잊어서가 아니라 로그인을 차단하면 모두 끝난다고 보기 때문입니다. 에이전트의 공격 표면에서 드러난 같은 공백을 오프보딩 관점에서 살펴보겠습니다. 체크리스트가 다루기 어려운 대상은 두 가지입니다. 퇴사 후 주인을 잃은 비인간 아이덴티티와 접근 권한을 제대로 회수했는지 입증할 실행 기록입니다.
계정 비활성화 후에도 남는 접근 수단
계정을 닫아도 그 사람이 만든 토큰과 서비스 계정, 에이전트 연동은 자체 자격증명으로 계속 인증합니다. OWASP는 부적절한 오프보딩을 비인간 아이덴티티 위험 1위로 꼽았습니다.
OWASP가 Non-Human Identities Top 10에서 1위로 선정한 위험은 유출된 시크릿이나 과도한 권한을 가진 역할이 아니라 부적절한 오프보딩이었습니다. 하위 사례에는 "원래 소유자는 퇴사했지만, 관련된 비인간 아이덴티티는 새로운 지정 소유자 없이 계속 활성 상태로 남는" 상황이 포함됩니다.
2026년의 시니어 엔지니어는 로그인 계정 하나만 남기지 않습니다. CI 자격증명, 클라우드 서비스 계정, 웹훅 시크릿, 에이전트와 MCP 연동은 담당자가 없어도 기존 권한으로 계속 인증합니다. 클라우드 네이티브 환경에서는 머신 아이덴티티가 사람보다 최대 144배 많습니다(Entro Labs). 광범위한 엔터프라이즈 조사에서는 이 비율이 45:1~80:1로 더 낮게 나타납니다.
Cloud Security Alliance의 비인간 아이덴티티 연구에 따르면 엔터프라이즈 아이덴티티의 8%는 생성자가 퇴사한 뒤 HR 시스템과의 소유권 연결이 사라집니다. 이 수치는 The Hacker News가 처음 보도했고 CSA 백서가 인용했습니다. CSA는 조직의 51%가 AI 아이덴티티의 소유권을 명확히 파악하지 못한다고도 보고했습니다. 의도적으로 유지한 자격증명이 아니라, 용도를 아는 유일한 담당자보다 오래 남은 자격증명입니다.
아이덴티티 공급자를 비활성화해도 회수가 끝나지 않는 이유
요약: 페더레이션은 로그인을 관리하지만, 사용자가 다운스트림 도구에서 직접 발급한 자격증명은 관리 범위에 들어오지 않습니다. CSA 조사에서 API 키 오프보딩과 회수를 위한 공식 절차를 갖춘 조직은 20%뿐이었습니다.
싱글 사인온(SSO)을 차단하면 새 세션을 시작할 수 없습니다. 그러나 다운스트림 도구에서 발급한 개인 액세스 토큰에는 영향을 주지 못합니다. 이 토큰은 아이덴티티 공급자를 거치지 않고 도구의 API에 직접 인증하므로, 비활성화된 계정과 연결을 끊을 경로가 없습니다. 자체 자격증명 저장소가 있는 시스템마다 별도의 프로비저닝 해제 경로를 마련해야 합니다. CSA 조사에서 API 키 오프보딩과 회수를 위한 공식 절차를 갖춘 조직은 20%뿐이었습니다.
올해 공개된 Klue 사례가 이 문제를 잘 보여줍니다. TechCrunch는 2026년 6월 보도에서 2022년 제한된 파일럿을 위해 서드파티에 발급한 자격증명이 한 번도 회수되지 않았다고 전했습니다. Klue는 이를 "통합 서비스와 연결된 레거시 자격증명"이라고 설명했지만 정확한 형태는 밝히지 않았습니다.
갈취 조직 Icarus는 약 4년 뒤 이 자격증명으로 Klue 플랫폼에 접근했습니다. 이어 고객이 연결된 서드파티 플랫폼에 부여한 OAuth 토큰을 탈취해 CRM 데이터를 직접 조회했습니다. 공개된 피해자에는 LastPass(TechCrunch 보도 기준)와 자체 사고 보고서를 발표한 Huntress처럼 보안팀을 고객으로 둔 회사가 포함됐습니다. Recorded Future, Tanium, Jamf, Sprout Social, Gong, Insurity도 피해자 명단에 올랐습니다.
Klue에서는 사람 대신 프로젝트의 오프보딩이 실패했습니다. 파일럿이 끝난 뒤에도 자격증명이 남아 있던 생명주기 공백입니다. 보안팀에 서비스를 제공하는 벤더도 이 문제에서 예외가 아니었습니다.
접근 권한 회수를 증명하는 실행 기록
실행 기록이 없으면 접근 권한 회수가 남긴 효과까지 증명할 수 없습니다. SOC 2 CC6.2는 접근이 적시에 종료됐다는 문서화된 증거를 요구하지만, 실행을 기록하지 않았다면 "이 사람이 3년 동안 무엇을 실행했는가"에는 답할 수 없습니다.
오프보딩에서는 두 가지를 확인해야 합니다. 체크리스트는 접근 권한을 회수했는지 답합니다. 감사관은 권한이 유효한 동안 무엇을 실행했는지도 묻지만, 여기에 답할 수 있는 조직은 많지 않습니다. 회수 여부는 현재 상태로 선언할 수 있어도 과거 실행은 당시 기록을 남겨야만 확인할 수 있습니다.
SOC 2 CC6.2는 사용자 접근 종료를 다루며, 감사관은 절차가 문서화됐는지, 적시에 일관되게 적용됐는지를 확인합니다. 퇴사자의 계정이 활성 상태로 남아 있으면 즉시 지적되는 것이 일반적입니다. 그러나 이 인증이 확인하는 대상은 접근 종료 절차입니다. 계정을 15일에 비활성화했다는 티켓만으로는 그 전 3년 동안 해당 권한으로 무엇을 했는지 알 수 없습니다.
이 공백은 수개월 동안 이어질 수 있습니다. 2025년 12월 공개된 쿠팡 침해 사고에서는 2024년에 퇴사한 전 직원이 내부 시스템 접근 권한을 유지했습니다. 침해는 2025년 6월 24일 발생해 11월 18일에야 발견됐고, 고객 3,370만 명의 정보가 노출됐습니다. 접근 권한이 어떤 방식으로 유지됐는지는 공개 보도에 나오지 않습니다.
2024년 퇴사, 2025년 6월 악용, 같은 해 11월 발견이라는 흐름에서는 약 147일의 탐지 공백이 생겼습니다. 업계 평균 침해 식별 기간인 194일(IBM Cost of a Data Breach 2024)보다도 짧습니다. 이 정도의 지연이 이례적이지 않다는 사실이 더 큰 문제입니다.
담당자 퇴사 때 쉽게 놓치는 6가지 체크리스트
여섯 단계 모두 로그인 계정이 아니라 퇴사자가 만들거나 소유한 접근 수단을 기준으로 진행합니다.
- 회수하기 전에 먼저 목록을 만듭니다. 계정을 비활성화하기 전에 그 사람이 만들었거나 마지막으로 소유했던 모든 비인간 아이덴티티를 뽑아 둡니다. API 토큰, 서비스 계정, CI 자격증명, 에이전트와 MCP 연동까지 포함합니다. 계정이 사라지면 대개 소유권 연결 정보도 함께 사라집니다.
- 소유권을 다른 사람에게 넘기고, 그냥 지우지 않습니다. OWASP가 말하는 "주인 없는(orphaned)" 사례는 지정 소유자가 없는 아이덴티티입니다. 살아남는 모든 항목에는 이름이 있는 후임자가 있거나, 명시적으로 기록된 폐기 결정이 있어야 합니다. "아무도 문제 삼지 않았다"는 결정이 아닙니다.
- 아이덴티티 공급자만으로는 부족합니다. 도구마다 따로 회수합니다. 사용자가 직접 자격증명을 발급할 수 있는 시스템은 각자 자기만의 토큰 저장소를 갖고 있습니다. 그만큼 시스템마다 별도의 회수 단계가 필요하고, 이 단계가 가장 자주 빠집니다.
- 손대기 전에 마지막 사용 시점을 확인합니다. 90일 동안 쓰이지 않은 토큰은 폐기 후보입니다. 한 시간 전에 쓰인 토큰은 프로덕션이 의존하고 있는 토큰이며, 금요일 저녁에 이걸 끊으면 야간 작업이 그대로 멈춥니다.
- 직접 만든 계정과 물려받은 계정을 구분합니다. 퇴사자가 묶여 있었다는 이유로
ubuntu나 공유 운영 계정을 지우면 다른 모든 사람의 접근 권한까지 함께 사라집니다. 계정은 남기고, 아이덴티티와의 연결만 끊습니다. - 실행 기록을 남깁니다. 3년치 프로덕션 작업의 유일한 흔적이 이미 재설치된 호스트의 셸 기록 파일뿐이라면, 감사관의 질문에 답할 방법이 없습니다.
실행 제어를 적용한 오프보딩
권한을 선언되고 기록되는 세션 안으로 제한하면 방치할 수 있는 상시 권한이 줄어듭니다. 뒤에서 설명할 두 가지 예외는 남아 있으며, 명령을 통제하는 계층에서 실행 증거도 함께 생성됩니다.
1~5단계는 인벤토리, 6단계는 실행 기록을 다룹니다. 접근 권한이 처음부터 상시 부여되지 않으면 각 단계를 처리하기가 쉬워집니다. Alpacon에서는 사용자와 에이전트의 동작이 선언된 범위를 가진 Work Session에 속합니다. 모든 동작은 범위가 정해지고 기록되는 세션 안에서 이뤄지며, 세션을 연장하지 않으면 정해진 시간이 지난 뒤 자동으로 만료됩니다. 권한이 기본적으로 계속 남지 않는 구조입니다. 다만 퇴사자가 새 세션을 시작하지 못하게 하려면 누군가 Alpacon에서 해당 사용자의 접근 권한을 제거해야 합니다.
인벤토리 절반: 출처와 토큰 위생
계정 출처를 구분하면 상시 권한을 줄일 때 어떤 계정을 정리해야 하는지 판단할 수 있습니다. 오프보딩 런북에서는 5단계에 해당합니다. Alpacon이 발견하거나 프로비저닝한 로컬 계정에는 출처 분류가 붙습니다. 사용자의 마지막 접근 권한을 제거하면 Alpacon이 프로비저닝한 계정은 자동으로 프로비저닝 해제됩니다. Alpacon이 만들지 않은 계정(ubuntu, root, 공유 운영 계정)은 삭제하지 않고 퇴사한 아이덴티티와의 연결만 끊습니다. 담당자의 판단에 맡기지 않고 시스템에서 강제하는 처리입니다.
개인 API 토큰에는 런북 4단계를 판단할 실제 데이터가 있습니다. 마지막 사용 시점, 90일 이상 미사용 토큰 표시, 삭제 후 다시 만들지 않고 교체하는 기능은 이미 출시됐습니다. 토큰이 실행한 명령도 사람이 직접 입력한 명령과 같은 런타임 위험 평가를 받습니다. 모든 명령과 파일 전송은 실행에 사용된 정확한 토큰까지 귀속됩니다. 개인 API 토큰의 특권 실행은 현재도 위험 평가와 귀속 대상입니다. 이를 선언된 Work Session 안에서만 실행하도록 요구하는 기능은 설계와 준비를 마쳤지만 아직 기본값은 아닙니다.
실행 절반: 귀속과 아직 확산 중인 부분
실행 귀속은 런북 6단계에 해당합니다. 세션 기록과 실행 감사를 적용하면 계정을 15일에 비활성화했다는 사실뿐 아니라, 재직 기간에 어떤 명령이 어떤 호스트에서 어떤 아이덴티티와 자격증명으로 실행됐는지 남습니다. CC6.2 인증만으로는 얻을 수 없고, 티켓처럼 나중에 소급해서 만들 수도 없는 기록입니다.
자격증명이 어딘가에 남는 상황을 완전히 피하기는 어렵지만, 그 자격증명이 수행할 수 있는 동작은 제한할 수 있습니다. Alpacon에서는 사람과 에이전트의 특권 동작이 실행 전에 하나의 판단 파이프라인을 통과합니다. sudo 명령과 에이전트 실행도 포함됩니다. 파이프라인은 세션 전체를 차단하는 대신 특정 동작만 사람의 승인 대기 상태로 보낼 수 있습니다.
이 경로의 강제 거부(hard-deny) 기능은 코드 릴리스로 출시됐지만, 아직 모든 배포 환경에서 고위험 명령을 무조건 차단하지는 않습니다. 아이덴티티 계층의 오프보딩은 실행 시점의 판단까지 담당하지 않습니다. 유효한 자격증명이 사용되는 순간 이를 판단하는 통제가 없다면 자격증명의 동작을 제한할 수 없습니다.
여전히 처리되지 않는 부분
요약: Alpacon은 아직 아이덴티티 공급자의 퇴사자 이벤트를 직접 받아 처리하지 않습니다. 트리거는 여전히 사람이 직접 실행하는 동작이고, 일부 자격증명 유형은 세션 모델 밖에 있습니다.
- 아이덴티티 공급자로부터의 자동 프로비저닝 해제는 없습니다. 아이덴티티 공급자로 로그인하면 그 순간 아이덴티티 공급자의 그룹 멤버십이 Alpacon에 반영됩니다. 이는 로그인 시점에만 일어나는 이벤트이므로, 다시는 로그인하지 않을 사람의 권한을 구조적으로 해제할 수 없습니다. 아이덴티티 공급자의 퇴사자 이벤트를 호스트까지 전파하는 기능은 로드맵에 있을 뿐 아직 출시되지 않았습니다. 지금의 트리거는 Alpacon 안에서 그 사람의 마지막 접근 권한을 제거하는 것이고, 이는 여전히 사람이 직접 실행하는 단계입니다.
- 서비스 토큰은 별도의 예외입니다. 개인 API 토큰과 달리 서비스 토큰은 세션이 아니라 정적 ACL로 제한되며, 계속 장기간 유지됩니다.
- 범위를 벗어난
sudo에 대한 상한 거부는 monitor-then-enforce 방식으로 도입되고 있으며, 기본으로 enforce되는 상태는 아닙니다. enforce 모드가 켜진 곳에서는 범위 밖 동작이 거부되고, 꺼진 곳에서는 계측되고 기록만 됩니다. - Alpacon은 자신이 관리하는 인프라만 통제합니다. 퇴사자가 SaaS 콘솔에서 발급한 토큰은 여전히 그 벤더의 프로비저닝 해제 경로에 속합니다.
핵심 정리
프로비저닝을 해제하면 사람의 접근 권한은 사라집니다. 그 사람이 만든 접근 수단은 그대로 남고, 무엇을 실행했는지도 알 수 없습니다. 오프보딩을 인벤토리와 증거의 문제로 다루면 감사관이 묻는 두 가지 질문에 답할 수 있습니다. 퇴사자의 이름으로 아직 무엇이 작동하는지, 재직 중 무엇을 실행했는지입니다.
자주 묻는 질문
오프보딩 접근 권한 회수란 무엇인가요? 퇴사 시점에 그 사람의 접근 권한을 제거하는 작업입니다. 제대로 하려면 사람 계정 하나만이 아니라 그 사람이 만들었거나 소유했던 모든 비인간 아이덴티티, 그리고 회수 전에 무엇을 실행했는지에 대한 증거까지 포함해야 합니다.
아이덴티티 공급자 계정을 비활성화하는 것만으로는 왜 충분하지 않나요? 싱글 사인온이 관리하는 대상은 로그인이고, 다운스트림 도구 안에서 직접 발급된 자격증명은 그 관리 범위 밖에 있습니다. 비활성화 신호를 되돌려 보낼 경로 자체가 없기 때문입니다. API 키 오프보딩을 위한 공식 절차를 갖춘 조직은 20%뿐입니다(CSA).
직원이 퇴사할 때 SOC 2 CC6.2는 무엇을 요구하나요? 접근 권한을 문서화하고 시의성 있게 제거하는 것입니다. 퇴사자의 계정이 활성 상태로 남아 있으면 표준적인 지적 사항이 됩니다. 그 권한을 가진 동안 무엇을 실행했는지에 대한 기록까지는 요구하지 않습니다. 그 기록을 남기려면 세션 기록과 실행 감사가 별도로 필요합니다.
퇴사 후 주인 없는 서비스 계정은 어떻게 찾나요? 사람이 아니라 출처에서부터 시작합니다. 모든 계정과 자격증명을 출처, 소유자, 마지막 사용 시점 기준으로 목록화하고, 소유자가 HR에서 사라진 항목을 표시합니다. Alpacon에서는 관리 대상 서버에서 발견하거나 프로비저닝한 로컬 계정에 출처 분류와 관리 여부 플래그가 붙고, 개인 API 토큰은 마지막 사용 시점과 오래된 토큰 표시를 직접 보여줍니다.
