직원 오프보딩의 진짜 어려움은 머신 자격증명에 있다
직원 한 명이 퇴사할 때 인사 시스템에서 계정을 비활성화하는 건 5분이면 끝납니다. Slack, GSuite, GitHub 사람 계정도 SCIM이 깔려 있으면 자동입니다. 진짜 어려움은 그 사람이 만들어 두고 사용해 온 머신 자격증명입니다 — CI에 박혀 있는 deploy 토큰, 본인 이름으로 발급한 AWS access key, Lambda 함수에 들어 있는 service account, 한 번 만들고 잊어버린 GitHub Personal Access Token.
이 머신 자격증명들은 사람 계정이 비활성화된 후에도 멀쩡히 동작합니다. 인포스틸러 악성코드에 감염된 퇴사자 노트북에서 다크웹으로 흘러가거나, 누군가의 1Password vault에 남아 있다가 새 직원이 그걸 그대로 다시 사용하기도 합니다. Cremit 분석상 전형적인 조직의 활성 NHI 중 약 60%가 소유자가 명확하지 않은 상태이며, 그 비율의 상당수는 이전 직원이 만든 키들입니다.
Cremit의 오프보딩 자동화는 사람 계정이 아니라 머신 자격증명을 표적으로 삼습니다. HR 이벤트가 트리거되면 그 사람과 연결된 모든 NHI를 enumerate해서, 회수 가능한 것은 즉시 회수하고 공유되어 있는 것은 회전합니다.
제로 리스크 직원 오프보딩
직원 퇴사 시 모든 접근 권한을 즉시 폐기하여 보안 공백 제거
즉시 접근 권한 폐기
퇴사하는 직원이 소유한 모든 API 키, 서비스 계정, 인증 정보를 원클릭으로 폐기합니다.
크로스 플랫폼 오프보딩
AWS, GitHub, Azure, GCP, 데이터베이스, 서드파티 서비스 전반의 접근 권한을 자동으로 제거합니다.
완전한 감사 추적
컴플라이언스 및 보안 감사를 위해 모든 접근 폐기 내역의 상세 로그를 유지합니다.
예약 오프보딩
계약직 및 임시 직원의 종료 날짜 기반으로 접근 폐기를 미리 예약합니다.
다운타임 없는 전환
폐기 후 공유 인증 정보를 자동으로 로테이션하여 서비스 연속성을 유지합니다.
HRMS 통합
Workday, BambooHR 및 기타 HR 시스템과 통합하여 자동 오프보딩 워크플로우를 트리거합니다.
작동 방식
3단계 자동 오프보딩
퇴사 감지
HR 시스템과의 통합으로 직원이 퇴사로 표시되면 자동으로 오프보딩 워크플로우를 트리거합니다.
모든 접근 권한 식별
Cremit이 직원이 소유하거나 접근한 모든 API 키, 인증 정보, 서비스 계정을 자동으로 발견합니다.
폐기 및 로테이션
모든 접근 권한이 즉시 폐기되고, 공유 인증 정보가 로테이션되며, 완전한 감사 로그가 자동으로 생성됩니다.
오프보딩이 실패하는 다섯 가지 패턴
실제 침해 사례를 분석해 보면 오프보딩 실패는 거의 항상 다음 다섯 가지 형태 중 하나입니다.
1. Ghost Key — 비활성화 누락
HR이 사람 계정은 disable했지만 그 사람이 발급한 AWS access key, GitHub PAT, Datadog API 토큰은 그대로 남아 있습니다. 가장 흔한 패턴이며, 약 92일 평균 잔존 기간이 측정됩니다.
2. Shared Key — 회전 못 하는 키
한 명의 명의로 발급됐지만 팀 7명이 같이 쓰던 키. 그 사람이 떠나면 회수해야 하지만, 회수하면 7명의 워크플로우가 멈춥니다. 회수 대신 회전 후 재배포가 정답이지만 자동화 없이는 누가 한 번 시도하다 멈춥니다.
3. Personal Cloud — 개인 계정에 박힌 키
엔지니어가 자기 개인 GitHub/AWS 계정으로 회사 인프라에 토큰을 등록한 경우. 회사가 그 토큰의 존재 자체를 모릅니다. 인포스틸러로 노트북이 털리면 그 통로로 회사 자산까지 넘어갑니다.
4. Hardcoded — 코드/CI에 박혀 있는 키
키가 git history나 CI 파이프라인 환경변수에 박혀 있어 사람 계정 비활성화로는 도달할 수 없습니다. 자격증명 인벤토리가 git 트리·.github/workflows·CI 설정까지 커버해야 잡힙니다.
5. Unattributed — 소유자 매핑 자체가 없음
회수 대상으로 식별하려면 자격증명이 그 사람과 매핑돼 있어야 하는데, 만들 때 owner를 적지 않았습니다. 퇴사하는 직원이 만든 키인지 아닌지 알아낼 방법이 없습니다. Cremit 분석상 활성 NHI의 약 60%가 이 상태이며, 자동 오프보딩의 가장 큰 차단 요인입니다.
컴플라이언스가 요구하는 것 vs 실제로 일어나는 일
SOC 2, ISO 27001, PCI DSS, HIPAA — 어떤 프레임워크를 적용하든 access termination 통제는 있습니다. 보통 "직원 퇴사 시 24시간 내 모든 access 회수, 감사 로그 보관" 같은 형태입니다. 사람 계정에는 비교적 잘 지켜집니다. 머신 자격증명에는 거의 지켜지지 않습니다.
감사 시즌이 되면 인사 시스템 로그와 IAM 비활성화 기록을 비교한 보고서가 만들어지지만, 그 보고서는 NHI를 거의 보지 않습니다. CI에 박힌 토큰, Lambda 안의 service account, Slack workflow에 등록된 webhook 같은 것들은 감사 범위 밖에서 살아남습니다.
Cremit 오프보딩 자동화는 이 격차를 닫습니다. 사람 계정 비활성화 이벤트를 트리거로 삼아 NHI 인벤토리에서 그 사람과 매핑된 모든 자격증명을 enumerate하고, 어떤 것을 회수했고 어떤 것을 회전했는지 감사 로그에 기록합니다. 다음 감사 때 보여줄 evidence가 자동으로 쌓입니다.
자주 묻는 질문
SCIM이 이미 있는데도 별도 오프보딩 자동화가 필요합니까?
SCIM은 사람 계정을 deprovision합니다 (Slack, Okta, GSuite 등). 머신 자격증명 — API 키, service account, CI 토큰, 인증서 — 은 SCIM 범위 밖이라 그대로 살아남습니다. Cremit은 SCIM과 충돌하지 않고 그 위에서 NHI 레이어를 처리합니다.
얼마나 빨리 회수됩니까?
HR 이벤트가 들어온 시점부터 평균 90초 이내에 첫 회수가 시작됩니다. 회전이 필요한 공유 자격증명은 안전한 deployment 윈도우(기본 5분)를 둔 후 자동 진행됩니다. 모든 단계가 감사 로그에 기록됩니다.
어떤 HR 시스템과 통합됩니까?
Workday, BambooHR, Rippling, Personio, Sapling, HiBob과 직접 통합됩니다. 그 외에는 SCIM 또는 webhook(POST에 employee_id 전달)으로 누구든 trigger를 붙일 수 있습니다.
계약직·외주 직원도 처리됩니까?
계약 종료일을 미리 등록해 두면 그 시점에 자동으로 회수 워크플로우가 발화합니다. 계약직은 사람 계정 deprovision이 누락되는 경우가 더 많기 때문에 자동화의 효과가 가장 큽니다.
소유자가 명확하지 않은 키는 어떻게 됩니까?
오프보딩 시점에 자동 회수는 안 됩니다 — 누가 만들었는지 모르는 키를 회수하면 무엇이 끊길지 모르기 때문입니다. Cremit은 그런 키를 별도 큐로 분리해서 보안 팀에 owner 매핑 요청을 보냅니다. 시간이 갈수록 unattributed 비율이 줄어드는 구조입니다.
온프레미스 / 에어갭 환경도 지원합니까?
온프레미스 IAM, AD, 자체 호스팅 GitLab/Jenkins/Vault에 대한 connector를 지원합니다. 에어갭 환경은 self-hosted runner 모드로 배포하면 외부 인터넷 없이 동작합니다.