퇴사자의 NHI 크리덴셜(AWS IAM 키, 서비스 계정 토큰, Slack 봇 토큰 등)은 HR 오프보딩 과정에서 거의 다뤄지지 않으며, 퇴사 후 수개월간 활성 상태로 방치된다
OWASP NHI Top 10은 부적절한 오프보딩(Improper Offboarding)을 1순위 리스크로 선정했으며, CSA 보고서에 따르면 API 키 오프보딩 프로세스를 갖춘 조직은 19%에 불과하다
퇴사자의 개인 장비에 캐시된 크리덴셜은 조직이 내부 시스템에서 키를 삭제해도 회수가 불가능하며, 인포스틸러 감염 시 다크웹으로 직접 유출된다
Ghost Key는 로테이션 되지 않으므로 다크웹 크리덴셜 마켓에서 유효율이 극도로 높고, DevOps/SRE 퇴사자의 키는 프로덕션 인프라 전체 접근 권한을 포함하는 경우가 많다
직원 1명당 평균 31개 SaaS 계정을 사용하며 그 뒤에 숨은 서비스 계정과 토큰의 수는 훨씬 많다, 퇴사 시 이 전부를 수동으로 추적하는 건 현실적으로 불가능하다
NHI 크리덴셜을 인간 소유자에 매핑하고, 퇴사 이벤트와 자동 연동되는 오프보딩 체계가 방어의 핵심이다
휴면 크리덴셜의 재활성화를 실시간으로 감지하는 모니터링 없이는 Ghost Key 공격을 초기에 차단할 수 없다
새벽 3시 17분, 죽었어야 할 키가 깨어났다
2025년 초, 서울 강남의 한 중견 SaaS 기업. 직원 수 100명 남짓, 시리즈 C를 앞두고 성장 중인 회사였습니다. DevOps 엔지니어 K는 이 회사에서 3년을 일했습니다. Terraform으로 인프라를 관리하고, CI/CD 파이프라인을 구축했으며, 모니터링 시스템을 설계한 핵심 인력이었습니다. K가 직접 생성하거나 관리하던 크리덴셜은 한두 개가 아니었습니다. Terraform 배포용 AWS IAM Access Key, Slack 장애 알림 봇 토큰, Datadog 모니터링 API 키, GitHub Actions 서비스 계정, Jenkins 파이프라인 토큰. 3년간 인프라를 세팅하면서 만들어진 비인간 아이덴티티(NHI) 크리덴셜이 최소 15개 이상 K의 이름과 연결되어 있었습니다.
2024년 11월, K가 퇴사했습니다. HR팀의 오프보딩은 교과서적이었습니다. 노트북 회수, Google Workspace 계정 비활성화, 출입증 반납, VPN 접근 차단. 체크리스트의 모든 항목에 체크가 들어갔습니다. 다만, 그 체크리스트에 "해당 직원이 생성/관리한 NHI 크리덴셜 전수 조사 및 폐기"라는 항목은 없었습니다. 애초에 그런 항목이 있는 기업이 드뭅니다.
K는 재직 중 개인 맥북에서도 종종 작업했습니다. 야근할 때, 주말에 장애가 터졌을 때. 개인 노트북의 ~/.aws/credentials 파일에는 Terraform 배포용 IAM 키가 들어 있었고, 브라우저에는 GitHub과 Slack 세션 토큰이 캐시되어 있었습니다. .env 파일 몇 개도 로컬에 남아 있었습니다. 퇴사할 때 회사 노트북은 반납했지만, 개인 장비의 크리덴셜은 누구도 신경 쓰지 않았습니다. K 본인도요.
퇴사 2개월 후인 2025년 1월, K는 개인 노트북에 크랙 소프트웨어를 설치했습니다. 유료 디자인 도구의 무료 버전을 찾다가 내려받은 파일에 Lumma Stealer가 심어져 있었습니다. Lumma Stealer는 2024년 가장 많이 유포된 인포스틸러로, 전년 대비 배포량이 약 2배 성장한 악성코드입니다. 이 인포스틸러가 K의 개인 노트북에서 수집한 것은 브라우저에 저장된 비밀번호와 쿠키, ~/.aws/credentials, 로컬 .env 파일, SSH 키, 그리고 각종 세션 토큰이었습니다. 수집된 데이터는 자동으로 다크웹 크리덴셜 마켓에 업로드되었습니다.
2025년 2월 15일 토요일 새벽 3시 17분. us-west-2 리전에서 비정상 API 호출이 발생했습니다. K의 IAM 키로 sts:GetCallerIdentity가 호출되었고, 이어서 s3:ListBuckets, s3:GetObject가 연이어 실행되었습니다. K가 재직 중 이 키를 사용한 리전은 ap-northeast-2(서울)뿐이었습니다. 미국 서부에서 날아온 호출. 토요일 새벽. 이미 2개월 전에 퇴사한 사람의 키로.
다크웹에서 K의 크리덴셜 덤프를 구매한 공격자는 주말을 택했습니다. 보안팀이 쉬는 시간. 토요일 새벽부터 일요일 밤까지 약 44시간 동안 공격자는 S3 버킷에 저장된 고객 데이터에 접근했고, K가 만든 Slack 봇 토큰을 이용해 내부 #general 채널에 "긴급 보안 업데이트"를 가장한 피싱 링크를 전송했습니다. 3명의 직원이 일요일 저녁에 이 링크를 클릭했습니다.
월요일 아침, 출근한 보안 엔지니어가 주간 CloudTrail 리뷰를 시작했을 때 비로소 이상을 감지했습니다. us-west-2에서의 API 호출. 퇴사자 K의 IAM 키. Slack 봇의 비정상 메시지. 3일 전 토요일 새벽에 시작된 침해를 월요일에야 발견한 겁니다.
이 시리즈의 Public Key 글에서 다룬 공개 저장소에 노출된 크리덴셜은 "외부에서 4분 만에 발견"되는 위협이었습니다. Ghost Key는 다릅니다. 아무도 보고 있지 않았기 때문에 3개월간 방치되었고, 공격자가 먼저 발견했습니다. 4분이 아니라 3개월. 그게 Ghost Key의 본질입니다.
Ghost Key 타임라인 — Day 0 퇴사부터 Day 92 공격 개시, Day 95 탐지까지
이 키는 왜 위험한가
Ghost Key. 직역하면 유령 열쇠입니다. 소유자가 조직을 떠났지만 아직 활성 상태인 NHI 크리덴셜을 말합니다. 사람은 떠났는데 그 사람이 만든 API 키, 서비스 계정 토큰, 봇 크리덴셜은 여전히 살아서 작동하는 상태. 주인 없는 열쇠가 아직 자물쇠를 열 수 있는 상황입니다.
왜 이런 일이 생길까요? 근본적인 원인은 HR 오프보딩 프로세스의 구조적 한계에 있습니다. 현재 대부분의 기업 오프보딩은 인간 아이덴티티만 커버합니다. Active Directory 계정 비활성화, 이메일 차단, 노트북 회수, VPN 접근 제거. 이건 잘 됩니다. 문제는 비인간 아이덴티티(NHI)입니다. 퇴사하는 직원이 생성했거나 관리하던 AWS IAM 키, GitHub Personal Access Token, Slack 봇 토큰, CI/CD 서비스 계정, 모니터링 API 키, 이것들은 HR 오프보딩 체크리스트에 아예 항목 자체가 없는 경우가 대부분입니다.
숫자로 보면 문제의 규모가 실감납니다. CSA(Cloud Security Alliance)의 2026년 NHI 보안 보고서에 따르면 API 키에 대한 오프보딩 프로세스를 갖춘 조직은 전체의 19%에 불과합니다. 나머지 81%는 직원이 퇴사해도 해당 직원의 API 키와 서비스 계정을 체계적으로 추적하고 폐기하는 절차가 없다는 뜻입니다. 같은 보고서에서 NHI를 통한 공격 방어에 높은 자신감을 가진 조직은 12%뿐이었습니다.
규모의 문제도 심각합니다. 평균적으로 직원 1명당 31개의 SaaS 계정을 사용합니다. 하지만 이건 직접 사용하는 계정만 센 것입니다. 그 뒤에 숨어 있는 서비스 계정, API 토큰, 봇 크리덴셜의 수는 훨씬 많습니다. OWASP NHI Top 10에 따르면 기업 환경에서 NHI 크리덴셜은 인간 계정 대비 약 100:1 비율로 존재합니다. 직원 100명인 조직이라면 NHI 크리덴셜은 수천에서 수만 개에 달할 수 있습니다. 한 명이 퇴사할 때 그 사람과 연결된 NHI 크리덴셜을 수동으로 전부 찾아내는 건 현실적으로 불가능에 가깝습니다.
Ghost Key에는 Public Key와 근본적으로 다른 차원의 위험이 하나 더 있습니다. 인포스틸러 문제입니다. 회사가 내부 시스템에서 퇴사자의 키를 완벽하게 삭제했다고 가정해봅시다. IAM 키도 로테이션하고, 서비스 계정도 비활성화하고, 토큰도 폐기했습니다. 하지만 그건 회사가 통제할 수 있는 범위 안에서의 이야기입니다. 퇴사자의 개인 노트북에 캐시된 ~/.aws/credentials, 브라우저에 저장된 세션 토큰, 로컬 .env 파일, 이것들은 회사가 손댈 수 없습니다. 퇴사자가 자발적으로 삭제하지 않는 한, 그리고 그 개인 장비가 인포스틸러에 감염되지 않는 한 안전하겠지만, K의 사례에서 봤듯이 그 가정은 언제든 무너질 수 있습니다.
정리하면, Public Key는 "노출된 키"입니다. 공개 공간에 드러나 있어서 누구든 찾으면 악용할 수 있는 키. Ghost Key는 "잊혀진 키"입니다. 어디에 있는지, 아직 활성 상태인지, 누구의 것이었는지조차 추적되지 않는 키. 잊혀졌다는 건 아무도 감시하지 않는다는 뜻이고, 감시하지 않으면 악용되고 있어도 모른다는 뜻입니다.
Kill Chain, Ghost Key 공격 체인
Ghost Key의 공격 체인은 Public Key와 출발점부터 다릅니다. Public Key가 공개 저장소라는 밝은 무대에서 시작된다면, Ghost Key는 퇴사자의 개인 장비라는 어두운 곳에서 시작됩니다. 그리고 그 어두움이 공격자에게 시간이라는 결정적 이점을 줍니다.
1단계: 크리덴셜 수확(Credential Harvesting)
시작은 퇴사자의 개인 장비입니다. 인포스틸러, Lumma Stealer, RedLine, Raccoon 같은 악성코드, 가 감염된 장비에서 브라우저에 저장된 비밀번호와 쿠키, ~/.aws/credentials, ~/.ssh/ 디렉토리, 로컬 .env 파일, 각종 설정 파일 속 토큰을 자동으로 수집합니다. 수집된 데이터는 "로그(logs)"라 불리는 패키지로 묶여 다크웹 크리덴셜 마켓에 자동 업로드됩니다. Russian Market, Genesis Market 같은 플랫폼에서 건당 수 달러에서 수십 달러에 거래됩니다. 여기서 핵심은, 이 과정에서 피해 기업은 아무것도 감지할 수 없다는 점입니다. 감염된 건 퇴사자의 개인 장비이고, 유출된 크리덴셜은 이미 회사의 관리 범위 밖에 있으니까요.
2단계: 검증(Validation)
다크웹에서 크리덴셜 덤프를 구매한 공격자는 먼저 키가 아직 살아 있는지 확인합니다. AWS 키라면 sts:GetCallerIdentity, GitHub 토큰이라면 /user API, Slack 봇 토큰이라면 auth.test 메서드를 호출합니다. 여기서 Ghost Key의 치명적인 특성이 드러납니다. Ghost Key는 로테이션이 안 됩니다. 소유자가 떠났고, 남은 사람 중 이 키의 존재를 아는 사람이 없으므로, 로테이션 주기가 돌아와도 대상에 포함되지 않습니다. 결과적으로 다크웹에서 거래되는 일반 크리덴셜의 유효율이 시간이 지나면서 떨어지는 것과 달리, Ghost Key의 유효율은 비정상적으로 높게 유지됩니다. 공격자에게 이건 프리미엄 상품입니다.
3단계: 초기 접근(Initial Access)
검증된 키로 조직의 인프라에 접근합니다. 여기서 피해 규모를 결정하는 건 퇴사자가 누구였느냐입니다. 일반 개발자의 키라면 특정 서비스나 리소스에 한정된 접근일 수 있습니다. 하지만 DevOps 엔지니어, SRE, 인프라 관리자의 키는 이야기가 다릅니다. Terraform 배포용 IAM 키는 인프라 전체를 만들고 삭제할 수 있는 권한을 가진 경우가 많고, CI/CD 파이프라인 서비스 계정은 프로덕션 환경 배포 권한을 포함합니다. 3년간 인프라를 관리한 K의 키가 위험했던 이유가 바로 이겁니다. 그건 K라는 사람의 접근 권한이 아니라, K가 관리한 시스템 전체의 접근 권한이었습니다.
4단계: 지속성 확보 및 측면 이동(Persistence & Lateral Movement)
Ghost Key 공격에서 공격자가 누리는 가장 큰 이점은 모니터링 사각지대입니다. 현직 직원의 키에서 비정상 활동이 발생하면 그나마 누군가 들여다볼 가능성이 있습니다. 하지만 퇴사자의 키? 로그를 보는 사람이 없습니다. 해당 키가 아직 활성 상태인지조차 모르니까요. 공격자는 이 사각지대 안에서 느긋하게 작업합니다. 새로운 IAM 사용자를 생성하고, 추가 액세스 키를 발급하고, 백도어를 심습니다. 원래 Ghost Key가 나중에 발견되어 폐기되더라도, 이미 만들어둔 백도어 키로 접근을 유지할 수 있습니다. K의 사례에서 공격자가 주말 44시간 동안 자유롭게 움직인 것도 이 사각지대 덕분이었습니다. 평일에도 마찬가지였을 겁니다. 퇴사자의 키에서 발생하는 API 호출을 실시간으로 감시하는 조직이 얼마나 될까요?
5단계: 영향(Impact)
Ghost Key를 통한 최종 피해는 다층적입니다. 가장 직접적인 건 데이터 유출입니다. S3 버킷, 데이터베이스, 내부 문서에 접근해 고객 데이터와 지적 재산을 빼돌립니다. 하지만 Ghost Key 공격은 여기서 끝나지 않는 경우가 많습니다. K의 사례에서 봤듯이, Slack 봇 토큰이 있으면 내부 채널에 피싱 메시지를 보낼 수 있습니다. 조직 내부에서 발송된 메시지이므로 의심 없이 클릭할 확률이 높습니다. CI/CD 파이프라인 토큰이 있다면 공급망 공격까지 가능합니다. 빌드 프로세스에 악성 코드를 삽입하면 그 소프트웨어를 사용하는 모든 고객이 피해를 봅니다. 하나의 Ghost Key가 데이터 유출, 내부 피싱, 공급망 오염이라는 세 가지 공격 벡터를 동시에 열어주는 겁니다.
Ghost Key가 위험한 건 키 자체의 속성 때문이기도 하지만, 기존 보안 체계가 이걸 잡을 수 있도록 설계되어 있지 않기 때문이기도 합니다. 각 방어선을 하나씩 살펴보겠습니다.
HR 시스템은 NHI를 모른다
Workday, BambooHR 같은 HR 시스템은 직원의 인사 정보를 관리합니다. 입사일, 부서, 직급, 퇴사일. 하지만 "이 직원이 어떤 AWS IAM 키를 생성했는가", "어떤 Slack 봇 토큰을 관리하는가", "어떤 서비스 계정의 소유자인가", 이런 정보는 HR 시스템의 관리 대상이 아닙니다. 직원이 퇴사 처리되면 HR 시스템은 AD 계정 비활성화, 이메일 차단 같은 워크플로우를 트리거합니다. NHI 크리덴셜 폐기를 트리거하는 연동은 존재하지 않습니다. "직원 퇴사"라는 이벤트와 "해당 직원의 NHI 크리덴셜 전부 폐기"라는 액션 사이에 자동화된 연결고리가 없는 겁니다.
IAM 도구의 구조적 한계
AWS IAM, GCP IAM, Azure AD 같은 아이덴티티 관리 도구에도 근본적인 한계가 있습니다. IAM 사용자나 서비스 계정을 만들 때 "소유자" 필드가 필수가 아닙니다. 태그를 달 수는 있지만 강제되지 않습니다. 3년간 수십 개의 서비스 계정과 IAM 키를 만들면서 매번 "Owner: K"라고 태깅한 조직이 얼마나 될까요? 태깅이 안 되어 있으면, K가 퇴사해도 K와 연결된 NHI 크리덴셜을 한 번에 조회하는 게 불가능합니다. 하나씩 뒤져야 합니다.
SCIM/SAML 디프로비저닝의 범위
IdP(Identity Provider)와 SaaS 서비스 간 SCIM 프로토콜을 통한 자동 프로비저닝/디프로비저닝을 구축한 조직도 있습니다. 직원이 퇴사하면 IdP에서 계정이 비활성화되고, SCIM을 통해 연동된 SaaS 서비스에서도 해당 사용자 계정이 자동으로 비활성화됩니다. 잘 작동합니다. 문제는 SCIM이 처리하는 건 "직접 사용자 계정"뿐이라는 점입니다. 그 사용자가 생성한 API 키, Personal Access Token, 봇 토큰, 서비스 계정은 SCIM 디프로비저닝의 대상이 아닙니다. 사람 계정은 깨끗하게 정리되지만, 그 사람이 뿌려놓은 NHI 크리덴셜은 그대로 남습니다.
감사 주기의 허점
연간 또는 분기별로 크리덴셜 감사를 실시하는 조직이 있습니다. 좋은 관행입니다. 하지만 감사와 감사 사이에 수개월의 간격이 있습니다. 지난 감사 직후에 퇴사한 직원의 NHI 크리덴셜은 다음 감사까지 최대 3개월(분기별) 혹은 12개월(연간) 동안 방치됩니다. K의 사례에서 퇴사 후 3개월 만에 침해가 발생한 건 이 주기의 사각지대에 정확히 들어맞습니다.
인포스틸러라는 통제 불가 변수
위에서 말한 모든 한계를 극복했다고 가정해봅시다. HR 시스템이 NHI를 추적하고, IAM 키에 소유자가 태깅되어 있고, 퇴사 시 SCIM 디프로비저닝과 함께 NHI 크리덴셜도 전부 폐기됩니다. 완벽한 오프보딩. 하지만 그래도 Ghost Key 위협을 100% 제거할 수 없습니다. 퇴사자의 개인 장비에 캐시된 크리덴셜은 조직의 통제 범위 밖이기 때문입니다. 조직이 내부에서 키를 로테이션하거나 폐기하면 캐시된 크리덴셜은 무효화됩니다. 이건 맞습니다. 하지만 로테이션이 즉시 이루어지지 않는 경우, 또는 로테이션 대상에서 빠진 키가 있는 경우, 그 창(window) 안에서 인포스틸러가 유효한 크리덴셜을 수집해갈 수 있습니다. 그리고 현실에서 "모든 NHI 크리덴셜을 퇴사 즉시 완벽하게 로테이션"하는 조직은, 솔직히 거의 없습니다.
오프보딩 갭 — HR 비활성화 항목 vs 여전히 활성 상태인 NHI 크리덴셜 비교
실제 침해 사례와 업계 데이터
Ghost Key는 이론적인 시나리오가 아닙니다. 실제로 반복해서 터지고 있고, 업계 데이터가 그 규모를 보여줍니다.
OWASP NHI Top 10: 오프보딩이 1순위
OWASP NHI Top 10에서 부적절한 오프보딩(Improper Offboarding)이 최상위 리스크 항목으로 선정된 건 우연이 아닙니다. 비인간 아이덴티티 보안의 가장 근본적인 실패 지점이 바로 여기이기 때문입니다. 사람이 떠나도 그 사람이 만든 비인간 크리덴셜이 정리되지 않는 구조적 문제. OWASP가 이걸 1순위에 놓은 건, 이 문제가 가장 흔하면서도 가장 간과되고 있다는 의미입니다.
CSA 2026년 보고서: 준비된 조직은 소수
CSA의 2026 State of Non-Human Identity Security 보고서는 현실의 냉정한 단면을 보여줍니다. API 키 오프보딩 프로세스를 갖춘 조직은 19%. NHI 공격 방어에 높은 자신감을 가진 조직은 12%. 크리덴셜 노출 후 24시간 이내에 로테이션하는 조직은 76%로, 뒤집으면 24%는 24시간이 지나도 노출된 키를 교체하지 못한다는 뜻입니다. Ghost Key 시나리오에서는 "노출" 자체를 인지하지 못하므로 로테이션 타이머 자체가 시작되지 않습니다.
Verizon DBIR 2025: 크리덴셜이 여전히 1순위 공격 벡터
Verizon의 2025 Data Breach Investigations Report에 따르면 전체 침해의 약 22%가 크리덴셜 악용으로 시작됩니다. 이건 피싱, 취약점 악용을 제치고 꾸준히 1위를 유지하는 공격 벡터입니다. 탈취된 크리덴셜 중 상당수가 인포스틸러를 통해 수집된 것이며, Ghost Key처럼 오프보딩 실패로 방치된 크리덴셜이 여기에 상당 부분 기여하고 있습니다.
CircleCI 2023: 교과서적인 Ghost Key 시나리오
2023년 1월 CircleCI 침해 사건은 Ghost Key 공격의 메커니즘을 가장 잘 보여줍니다. 엔지니어의 노트북이 악성코드에 감염되었고, 2FA가 적용된 SSO 세션 쿠키가 탈취되었습니다. 이 세션 토큰으로 공격자는 CircleCI 내부 프로덕션 시스템에 접근했고, 고객 환경 변수와 시크릿에 접근할 수 있었습니다. CircleCI는 모든 고객에게 시크릿 로테이션을 권고해야 했습니다. 감염된 건 한 명의 노트북이었지만, 그 안에 캐시된 세션 토큰 하나가 수천 개 고객 조직의 크리덴셜에 영향을 미쳤습니다.
SolarWinds와 Uber 2022: 크리덴셜 체이닝의 결말
SolarWinds 공격에서 공격자는 내부 빌드 시스템의 서비스 계정 크리덴셜을 장악해 Orion 소프트웨어 업데이트에 악성 코드를 삽입했습니다. 피해는 SolarWinds를 넘어 미국 정부 기관을 포함한 수만 개 고객에게 확산되었습니다. 2022년 Uber 침해에서는 탈취된 크리덴셜로 내부 네트워크에 진입한 후, 네트워크 공유 폴더에 하드코딩된 관리자 크리덴셜을 발견해 AWS, GCP, Google Workspace, Slack, HackerOne까지 접근했습니다. 두 사건 모두 최초 진입점은 단일 크리덴셜이었고, 크리덴셜 체이닝을 통해 조직 전체가 장악되었습니다.
인포스틸러 시장의 폭발적 성장
Ghost Key 위협의 배경에는 인포스틸러 시장의 급성장이 있습니다. Lumma Stealer는 2024년 가장 많이 유포된 인포스틸러로, 전년 대비 약 2배 성장했습니다. 서비스형 악성코드(MaaS) 모델로 운영되어 기술이 부족한 공격자도 쉽게 구매하고 배포할 수 있습니다. 수집된 크리덴셜은 자동으로 마켓에 올라가고, 구매자는 키워드로 특정 기업이나 서비스의 크리덴셜을 검색해 구매합니다. 퇴사자의 개인 장비가 감염될 확률은 재직 중보다 오히려 높을 수 있습니다. 회사 보안 정책(EDR, 웹 필터링, 패치 관리)의 보호를 더 이상 받지 못하니까요.
GitGuardian 2024: 노출된 시크릿은 살아 있다
GitGuardian의 2024 State of Secrets Sprawl 보고서에 따르면, 공개 GitHub에 노출된 시크릿의 90% 이상이 5일이 지나도 여전히 유효한 상태입니다. Ghost Key의 맥락에서 이 데이터를 해석하면, 퇴사자의 키는 공개 저장소에 노출된 키보다 더 오래 살아남을 가능성이 높습니다. 공개 노출은 그나마 발견될 여지라도 있지만, Ghost Key는 발견의 계기 자체가 없기 때문입니다.
탐지 및 대응 가이드
Ghost Key 위협에 대응하려면 "퇴사 시 AD 계정만 비활성화하면 끝"이라는 기존 사고방식을 근본적으로 바꿔야 합니다. 단계별로 정리합니다.
인벤토리: NHI 크리덴셜을 인간 소유자에 매핑
가장 먼저 해야 할 일은 조직 내 모든 NHI 크리덴셜의 목록을 만들고, 각각을 인간 소유자에 연결하는 것입니다. AWS IAM 키는 어떤 직원이 생성했는가. 이 Slack 봇 토큰은 누가 관리하는가. 이 CI/CD 서비스 계정은 누가 만들었는가. 소유자가 불명확한 크리덴셜이 있다면 그것부터가 이미 Ghost Key 후보입니다. IAM 도구에서 서비스 계정과 키에 Owner 태그를 필수 필드로 설정하는 것이 시작입니다.
오프보딩 연동: 퇴사 이벤트가 NHI 폐기를 자동 트리거
직원 퇴사가 확정되면 HR 시스템에서 해당 직원의 인사 처리가 이루어지고, 동시에 그 직원에 매핑된 모든 NHI 크리덴셜의 목록이 자동으로 생성되어야 합니다. 각 크리덴셜에 대해 즉시 폐기할 것, 다른 소유자에게 이전할 것, 모니터링 강화 대상으로 분류할 것을 구분합니다. "이 직원의 AD만 잠그면 끝"이 아니라 "이 직원과 연결된 NHI 크리덴셜 15개를 각각 이렇게 처리한다"가 되어야 합니다.
휴면 탐지: 30/60/90일 미사용 크리덴셜 플래그
활성 크리덴셜 중 장기간 사용되지 않는 것은 Ghost Key 후보입니다. 30일 미사용이면 경고, 60일이면 소유자에게 필요 여부 확인, 90일이면 자동 비활성화. 이 정책을 적용하면 소유자가 퇴사해서 아무도 쓰지 않는 크리덴셜이 90일 이상 방치되는 걸 구조적으로 방지할 수 있습니다.
로테이션 정책: 의무적 로테이션 주기
모든 NHI 크리덴셜에 의무적 로테이션 주기를 설정합니다. 90일마다, 또는 60일마다. 로테이션 주기가 되면 자동으로 새 키가 발급되고 기존 키가 폐기됩니다. 소유자가 퇴사해서 로테이션을 처리할 사람이 없는 키가 있다면, 그건 자동으로 Ghost Key로 분류되어 즉시 조치 대상이 됩니다.
Ghost Key 발견 시 대응: 이미 악용되었을 가능성을 전제
Ghost Key가 발견되면, 아직 악용되지 않았다고 가정하면 안 됩니다. 이미 악용되었을 가능성을 전제하고 대응해야 합니다.
즉시 폐기, 해당 크리덴셜을 무효화합니다. 비활성화가 아니라 삭제입니다.
접근 로그 감사, CloudTrail, 서비스별 감사 로그를 뒤져서 해당 키로 수행된 모든 활동을 확인합니다. 비정상적인 시간대, 비정상적인 리전, 비정상적인 API 호출 패턴에 주목합니다.
폭발 반경(blast radius) 평가, 해당 키로 접근 가능했던 모든 리소스를 식별하고, 각 리소스의 침해 여부를 확인합니다.
크리덴셜 체이닝 확인, 해당 키로 다른 키가 생성되었는지, 새로운 IAM 사용자가 만들어졌는지, 백도어가 설치되었는지 확인합니다. K의 사례에서 공격자가 백도어 키를 만들었다면, 원래 Ghost Key를 폐기해도 접근이 유지될 수 있습니다.
대응 플로우 — Ghost Key 대응 4단계: 고아 키 식별, 해지 및 교체, 접근 로그 감사, 수명주기 정책 수립
Cremit Argus는 이걸 어떻게 탐지하는가
Ghost Key의 핵심 문제는 "누구의 것인지 모르고, 아직 살아 있는지 모르고, 악용되고 있는지 모르는" 상태, 세 겹의 무지입니다. Argus는 이 세 가지를 각각 해결하도록 설계되었습니다.
첫째, Argus는 조직 내 모든 NHI 크리덴셜을 인간 소유자에 자동으로 매핑합니다. AWS IAM 키, GitHub Personal Access Token, Slack 봇 토큰, CI/CD 서비스 계정, 흩어져 있는 NHI 크리덴셜을 통합 인벤토리로 구성하고, 각각을 생성자 또는 관리자인 인간 아이덴티티에 연결합니다. "이 키는 누구의 것인가"에 대한 답이 항상 존재하는 상태를 만드는 겁니다.
둘째, 직원 퇴사 이벤트가 발생하면 Argus가 해당 직원에 연결된 모든 NHI 크리덴셜을 즉시 식별합니다. K가 퇴사했을 때, Argus가 있었다면 "K에게 매핑된 NHI 크리덴셜 15개: IAM 키 3개, Slack 봇 토큰 2개, GitHub PAT 4개, CI/CD 서비스 계정 3개, Datadog API 키 2개, SSH 키 1개"라는 목록이 자동으로 생성되었을 겁니다. 이 목록 없이는 수동으로 수십 개 서비스를 뒤져야 하고, 그 과정에서 빠뜨리는 키가 곧 Ghost Key가 됩니다.
셋째, 휴면 크리덴셜의 재활성화를 실시간으로 감지합니다. 3개월간 한 번도 사용되지 않던 IAM 키가 새벽 3시 17분에 us-west-2에서 API를 호출했다면, Argus는 이걸 즉시 이상 행위로 플래그합니다. "이 키는 90일간 미사용이었고, 마지막 사용 리전은 ap-northeast-2였으며, 소유자는 2개월 전 퇴사한 K입니다", 이 맥락이 결합된 실시간 알림이 K 시나리오에서 토요일 새벽에 울렸다면, 44시간의 자유 활동 시간은 몇 분으로 줄었을 겁니다.
Argus의 모니터링 범위는 GitHub에 국한되지 않습니다. Slack, Confluence, CI/CD 파이프라인, AWS/GCP/Azure 등 클라우드 인프라까지, NHI 크리덴셜이 존재하는 모든 플랫폼을 크로스 플랫폼으로 통합 관리합니다. K의 사례에서 Slack 봇 토큰을 통한 내부 피싱이 가능했던 건, Slack 속 NHI 크리덴셜을 아무도 관리하지 않았기 때문입니다. Argus는 이 사각지대를 제거합니다.
