NHI Kill Chain 총정리: 크리덴셜이 이미 침해된 8가지 경로, 그리고 전부를 해결하는 하나의 원칙

8가지 방법으로 이미 침해되어 있다

지난 8주간, 우리는 조직 내부에 잠복하는 NHI 크리덴셜 위험을 하나씩 해부했습니다. 각각의 시나리오는 실제 사고를 기반으로 했고, 각각은 보안 팀이 놓치고 있는 사각지대를 정확히 짚었다. 여기서 한 발 물러서서 전체 그림을 보겠습니다.

퇴사한 개발자의 AWS 키가 92일간 살아있었다. 인포스틸러에 감염된 개인 노트북에서 다크웹으로 유출되어 프로덕션이 뚫렸다. Ghost Key.

장애 대응 중 급하게 공유한 DB 비밀번호가 Slack, Confluence, Jira에 퍼졌습니다. 대응이 끝난 뒤에도 아무도 수거하지 않았습니다. Shadow Key.

3년간 아무도 건드리지 못한 Terraform 서비스 계정 키가 있었다. "이거 로테이션하면 프로덕션 멈춥니다"라는 한마디가 3년을 버틴 이유의 전부였고, 공급망 공격의 진입점이 되었다. Aged Key.

Stripe API 키 하나가 14개 서비스에 복사되어 있었다. 로테이션을 시도하면 14곳을 동시에 바꿔야 했고, 결국 아무도 바꾸지 못했습니다. Over-shared Key.

GitHub에서 Secret scanning alert가 떴다. 담당자가 "Resolved"로 마감했습니다. 파일은 삭제됐습니다. 하지만 키 자체는 폐기(revoke)되지 않았습니다. git history에 영원히 남은 키를 공격자가 발굴했습니다. Zombie Key.

하나의 DB 비밀번호가 GitHub, Slack, Confluence, Jenkins, AWS Parameter Store, .env 파일, Jira 티켓까지 7개 플랫폼 유형을 횡단했습니다. 하나의 플랫폼에서 탐지해도 나머지 6곳에는 여전히 살아있었다. Drifted Key.

.env 파일이 GitHub public 리포에 푸시되었다. 4분 만에 공격자 봇이 발견했습니다. 12분 만에 첫 번째 무단 API 호출이 발생했습니다. Public Key.

조직 내 3,400개 시크릿을 감사했습니다. 60%는 소유자가 누구인지 아무도 몰랐다. 누가 만들었는지, 어떤 서비스에 쓰이는지, 로테이션 주기가 언제인지. 소유자가 없는 키는 아무도 관리하지 않고, 아무도 관리하지 않는 키는 결국 침해됩니다. Unattributed Key.

이 중 하나라도 해당되지 않는 조직이 있는가요?

Verizon 2025 Data Breach Investigations Report에 따르면 크리덴셜 악용은 전체 분석 대상 침해 사고의 약 20%에 관여했습니다. IBM 2024 Cost of a Data Breach Report는 데이터 유출의 평균 비용을 488만 달러로 보고했으며, 가장 빈번한 초기 공격 벡터로 도난 또는 침해된 크리덴셜을 꼽았습니다. 이 수치가 NHI 크리덴셜만을 다룬 것은 아니지만, NHI 크리덴셜이 인간 아이덴티티의 평균 17배에 달하고, 그 대다수가 인간 아이덴티티에 적용되는 수명주기 관리를 받지 못한다는 점을 감안하면 공격 표면의 규모는 충격적입니다.

이 글은 아홉 번째 위협을 소개하는 것이 아니다. 8가지 유형을 연결하고, Cyber Kill Chain과 MITRE ATT&CK에 매핑하며, 공통된 근본 원인을 추적하고, 전부를 동시에 해결하는 거버넌스 프레임워크를 제시하는 메타 분석입니다.

CRE 분류 체계, Cremit의 8가지 NHI 위험 유형

8가지 시나리오를 체계적으로 분류하기 위해 Cremit은 CRE(Credential Risk Enumeration) 분류 체계를 정의했습니다. 보안 팀이 발견된 크리덴셜의 위험 유형을 즉시 식별하고, 각 유형에 맞는 대응 절차를 적용할 수 있도록 설계된 프레임워큽니다.

CRE | 유형 | 정의 | 탐지 기준 | 위험도

CRE-001 | Ghost Key | 퇴사자의 활성 크리덴셜 | 소유자 비활성 + 키 활성 | Critical

CRE-002 | Shadow Key | 비코드 소스에 노출된 크리덴셜 | Slack/Jira/Confluence 등에서 발견 | High

CRE-003 | Aged Key | 장기 미로테이션 크리덴셜 | 90일 이상 미로테이션 | High

CRE-004 | Over-shared Key | 다중 소스에 복제된 동일 시크릿 | 3곳 이상에서 동일 시크릿 발견 | High

CRE-005 | Zombie Key | 삭제된 파일에 남은 유효 크리덴셜 | 파일 삭제 + 키 유효 | Medium

CRE-006 | Drifted Key | 크로스 플랫폼으로 확산된 크리덴셜 | 2개 이상 플랫폼 유형에 존재 | Medium

CRE-007 | Public Key | 공개 저장소에 노출된 크리덴셜 | 퍼블릭 리포에서 발견 | Critical

CRE-008 | Unattributed Key | 소유자 불명 크리덴셜 | 소유자 매핑 불가 | High

이 분류 체계에서 주목해야 할 점은 하나의 크리덴셜이 동시에 여러 유형에 해당할 수 있다는 것입니다. 퇴사한 개발자가 3년 전에 만든 키는 Ghost Key이면서 동시에 Aged Key다. 그 키가 Slack에도 공유되어 있다면 Shadow Key이기도 합니다. CRE 분류는 배타적 범주가 아니라 중첩 가능한 위험 속성입니다. 이 중첩이 바로 문제를 복잡하게 만드는 핵심 원인이며, 개별 유형에 개별 도구로 대응하는 접근이 실패하는 이유다.

공격자 관점: Cyber Kill Chain x MITRE ATT&CK 매핑

CRE 분류 체계가 "크리덴셜의 상태"에 따른 위험 유형을 정의한다면, 이 섹션은 관점을 완전히 뒤집어 공격자의 눈으로 동일한 8가지 유형을 바라봅니다. 공격자는 각 유형을 Lockheed Martin Cyber Kill Chain의 어느 단계에서 어떻게 활용하는가요? 각 활용은 MITRE ATT&CK 프레임워크의 어떤 전술과 기법에 매핑되는가요?

Kill Chain 7단계 x CRE 오버레이

Kill Chain 단계 | 공격자 행위 | 활용되는 CRE 유형 | MITRE ATT&CK

Reconnaissance | 공개 소스에서 크리덴셜 탐색 | Public Key (GitHub, Pastebin 스캐닝) | T1593 Search Open Websites/Domains

Weaponization | 획득한 크리덴셜의 유효성 검증 및 공격 준비 | Zombie Key (git history 발굴), Aged Key (장기 유효성 보장) | T1588 Obtain Capabilities

Delivery | 크리덴셜 획득 경로 확보 | Ghost Key (다크웹 구매), Shadow Key (비코드 소스 접근) | T1650 Acquire Access

Exploitation | 유효한 크리덴셜로 시스템 인증 | Aged Key, Ghost Key, Public Key | T1078 Valid Accounts

Installation | 추가 크리덴셜 생성, 백도어 확보 | Unattributed Key (소유자 불명 → 탐지 불가) | T1136 Create Account

C2 (Command & Control) | 지속적 접근 채널 유지 | Aged Key (로테이션 부재 → 장기 사용), Unattributed Key | T1078.004 Cloud Accounts

Actions on Objectives | 횡이동, 데이터 탈취, 추가 침해 | Over-shared Key (1키로 N서비스), Drifted Key (크로스 플랫폼 이동) | T1552 Unsecured Credentials, T1550 Use Alternate Auth Material

이 매핑이 보여주는 것은 명확합니다. 8가지 CRE 유형은 Kill Chain의 특정 단계에 국한되지 않습니다. Public Key는 Reconnaissance에서 발견되지만 Exploitation에서도 직접 사용됩니다. Aged Key는 Weaponization에서 유효성을 보장하고, Exploitation에서 인증에 사용되며, C2에서 장기 접근을 유지합니다. 하나의 유형이 여러 단계를 관통하고, 하나의 단계에 여러 유형이 관여합니다.

연쇄 공격 시나리오: 하나의 Public Key에서 전체 인프라까지

이론이 아니라 실제로 일어나는 시나리오를 따라가 보겠습니다. 하나의 공격이 Kill Chain을 따라 진행되면서 여러 CRE 유형을 연쇄적으로 활용하는 과정입니다.

1단계, Reconnaissance. 공격자가 GitHub에서 자동화 스캐닝을 실행합니다. .env 파일이 public 리포에 커밋된 것을 발견합니다. 파일 안에 AWS IAM access key가 포함되어 있습니다. 이것이 Public Key(CRE-007)다. MITRE ATT&CK T1593.

2단계, Exploitation. sts:GetCallerIdentity로 유효성을 확인합니다. 키는 살아있습니다. 해당 키로 AWS에 인증합니다. 이 키는 6개월 전에 생성되었고 한 번도 로테이션되지 않았습니다. Public Key이면서 동시에 Aged Key(CRE-003)다. T1078 Valid Accounts.

3단계, Discovery. 인증 후 내부를 탐색합니다. AWS Systems Manager Parameter Store에서 Slack webhook URL과 Confluence API 토큰을 발견합니다. 이 크리덴셜들은 코드 저장소가 아닌 비코드 소스에도 동일하게 존재합니다. 내부 Slack 채널과 Confluence 페이지에서 추가 크리덴셜을 검색합니다. 장애 대응 시 공유된 DB 비밀번호를 Slack에서 발견합니다. Shadow Key(CRE-002). T1552 Unsecured Credentials.

4단계, Lateral Movement. Slack에서 발견한 DB 비밀번호로 프로덕션 데이터베이스에 접근합니다. 같은 비밀번호가 Jenkins, .env 파일, Jira 티켓에서도 발견됩니다. 하나의 크리덴셜이 7개 플랫폼을 횡단하고 있었다. Drifted Key(CRE-006). T1550 Use Alternate Auth Material.

5단계, Persistence. 탐지를 피하기 위해 기존의 서비스 계정을 활용합니다. 소유자가 매핑되지 않은 서비스 계정을 발견하고, 해당 계정으로 새로운 IAM 사용자와 access key를 생성합니다. 이 키에 대한 알림을 수신할 사람이 아무도 없습니다. Unattributed Key(CRE-008). T1136 Create Account.

6단계, Defense Evasion. 공격자가 사용하는 키들은 3년간 미로테이션 상태다. 모니터링 시스템은 이 키들의 활동을 정상으로 간주합니다. 왜냐하면 이 키들은 원래부터 계속 사용되어 왔고, 사용 패턴에 변화가 없어 보이기 때문입니다. Aged Key(CRE-003). T1078.004 Cloud Accounts.

이 시나리오에서 공격자가 활용한 CRE 유형은 6개다. 필요했던 초기 침입점은 단 1개, GitHub에 노출된 .env 파일 하나. 하나의 Public Key가 전체 Kill Chain의 시작점이 되었고, 각 단계에서 다른 CRE 유형이 방어 부재로 인해 연쇄적으로 다음 단계를 가능하게 했습니다.

방어 관점: 어느 단계에서 끊을 것인가

Kill Chain의 핵심 원리는 간단합니다. 어느 한 단계라도 끊으면 공격 전체가 중단됩니다. CRE 거버넌스는 Kill Chain의 매 단계에 방어 지점을 만듭니다.

Kill Chain 단계 | 방어 행위 | 대응하는 CRE 거버넌스

Reconnaissance 차단 | 공개 소스에서 크리덴셜 제거 | Public Key 스캐닝 + 즉시 로테이션

Delivery 차단 | 비코드 소스 모니터링, 퇴사자 키 폐기 | Ghost Key 오프보딩 자동화, Shadow Key 탐지

Exploitation 차단 | 장기 유효 크리덴셜 제거 | Aged Key 로테이션 정책, Zombie Key 완전 폐기

Lateral Movement 차단 | 키 분리, 최소 권한 원칙 적용 | Over-shared Key 분리, Drifted Key 통합 관리

Persistence 차단 | 모든 키에 소유자 매핑 | Unattributed Key 제로화

가장 효과적인 방어 지점은 Reconnaissance 단계다. Public Key를 실시간으로 탐지하고 즉시 로테이션하면, Kill Chain 자체가 시작되지 않습니다. 하지만 방어는 단일 지점에 의존해서는 안 됩니다. 공격자가 Reconnaissance를 다크웹 크리덴셜 구매(Ghost Key)로 우회하면, Delivery 단계에서 방어해야 합니다. Delivery도 뚫리면 Exploitation에서, Exploitation도 뚫리면 Lateral Movement에서 방어해야 합니다. 이것이 심층 방어(defense in depth)이고, CRE 거버넌스가 Kill Chain 전체에 걸쳐 방어 지점을 만드는 이유다.

연결 관계 맵, 하나가 다른 하나를 만든다

8가지 CRE 유형을 독립적인 문제로 취급하는 것은 근본적인 오류다. 현실에서 이 유형들은 서로를 유발하고, 강화하고, 악화시킨다. 하나의 크리덴셜이 동시에 여러 유형에 해당하는 것은 예외가 아니라 일반적 상태다.

연쇄 패턴 1: 노출에서 확산으로.

Public Key(공개 저장소 노출) → 즉시 로테이션하지 않으면 → Aged Key(장기 미로테이션) → 여러 서비스에서 동일 키를 참조하면 → Over-shared Key(다중 소스 복제). 하나의 노출이 시간이 지나면서 3가지 유형으로 진화합니다.

연쇄 패턴 2: 퇴사에서 통제 상실로.

Ghost Key(퇴사자 크리덴셜) → 소유자 매핑이 없으면 → Unattributed Key(소유자 불명) → 비코드 소스에도 해당 키가 남아있으면 → Shadow Key(비코드 소스 노출). 한 사람의 퇴사가 세 가지 위험을 동시에 활성화합니다.

연쇄 패턴 3: 삭제 착각에서 횡단 확산으로.

Zombie Key(파일 삭제했지만 키는 유효) → git history에 영원히 남은 키를 누군가 다른 플랫폼으로 복사하면 → Drifted Key(크로스 플랫폼 확산) → 해당 키가 3곳 이상에서 발견되면 → Over-shared Key(다중 소스 복제).

연쇄 패턴 4: 역방향, 하나의 거버넌스 실패가 여러 유형을 동시에 만듭니다.

소유자 매핑 부재 → 퇴사자 키를 식별할 수 없다(Ghost Key) + 미로테이션 키를 책임질 사람이 없다(Aged Key) + 키의 존재 자체를 파악할 수 없다(Unattributed Key). 근본 원인 하나가 세 가지 이상의 유형을 동시에 생성합니다.

이 연결 관계의 실무적 함의는 분명합니다. Public Key alert 하나를 처리할 때, 해당 키가 Over-shared Key인지, Aged Key인지, Drifted Key인지를 동시에 확인해야 합니다. Public Key만 처리하고 나머지를 무시하면, 같은 키가 다른 유형으로 재출현합니다. "몰퇴치기(whack-a-mole)" 대응이 실패하는 구조적 이유다.

근본 원인 분석, 왜 이 8가지가 반복되는가

8가지 CRE 유형은 겉보기에 각각 다른 문제처럼 보입니다. Ghost Key는 오프보딩 문제, Aged Key는 로테이션 문제, Shadow Key는 모니터링 문제. 하지만 근본 원인을 추적하면, 6가지 공통된 구조적 결함으로 수렴합니다.

근본 원인 | 관련 유형 | 설명

NHI 소유자 매핑 부재 | Ghost, Unattributed, Aged | 누가 이 키를 만들었는지 모르면, 퇴사 시 폐기할 수 없고(Ghost), 소유자가 불명이 되고(Unattributed), 로테이션 책임자가 없다(Aged)

비코드 소스 모니터링 부재 | Shadow, Drifted | GitHub만 스캔하면 Slack, Jira, Confluence에 퍼진 크리덴셜은 보이지 않는다

크리덴셜 수명주기 관리 부재 | Aged, Zombie | 키를 생성하는 프로세스는 있지만, 로테이션하거나 폐기하는 프로세스가 없다

크로스 플랫폼 가시성 부재 | Over-shared, Drifted, Shadow | 동일 시크릿이 몇 곳에 존재하는지, 어떤 플랫폼 유형을 횡단하는지 파악할 수 없다

"삭제 = 폐기" 착각 | Zombie, Public | 파일을 삭제하거나 커밋을 되돌려도, 키 자체를 revoke하지 않으면 여전히 유효하다

HR-IAM 연동 부재 | Ghost | HR 시스템은 직원이 퇴사한 것을 안다. IAM 시스템은 서비스 계정이 존재한다는 것을 안다. 이 두 시스템이 연동되지 않으면 Ghost Key는 필연이다

이 표에서 가장 많은 유형에 관여하는 근본 원인은 "NHI 소유자 매핑 부재"와 "크로스 플랫폼 가시성 부재"다. 각각 3가지 유형에 직접 관여합니다. 이 두 가지를 해결하면, 8가지 유형 중 5가지의 발생 조건이 제거되거나 탐지 가능해진다.

여기서 결론이 나옵니다. 개별 유형에 개별 도구로 대응하면 끝이 없습니다. Ghost Key 전용 도구, Aged Key 전용 정책, Shadow Key 전용 스캐너를 각각 도입하면 8개의 도구와 8개의 정책과 8개의 프로세스가 필요합니다. 근본 원인을 해결하면, 하나의 프레임워크로 8가지 유형을 동시에 다룰 수 있습니다.

이 패턴은 보안의 다른 영역에서 이미 관찰된 진화와 같습니다. 취약점 관리는 개별 CVE 패치에서 리스크 기반 우선순위화로 진화했습니다. 위협 탐지는 시그니처 기반 규칙에서 행위 기반 분석으로 진화했습니다. NHI 크리덴셜 보안도 동일한 진화가 필요하다, 개별 alert 대응에서 근본 원인 기반 거버넌스로의 전환. 위 6가지 근본 원인이 그 전환의 출발점입니다.

NHI 거버넌스 프레임워크, 내일부터 시작하는 4단계

근본 원인을 알았으니 실행으로 옮겨야 합니다. 아래는 CISO와 보안 프로그램 매니저가 내일 당장 시작할 수 있는 단계적 접근입니다. 한꺼번에 모든 것을 하려고 하면 실패합니다. 단계별로 가시성을 확보하고, 급한 위험부터 제거하며, 프로세스를 구축하고, 지속적 거버넌스로 전환하는 것이 현실적인 경로다.

Phase 1: 가시성 확보 (1-2주)

모든 것은 "현재 상태를 아는 것"에서 시작합니다. NHI 크리덴셜이 몇 개인지, 어디에 있는지, 누가 만들었는지를 파악하지 못하면 그 이후의 모든 조치는 추측에 불과합니다.

전체 NHI 크리덴셜 인벤토리를 구축합니다. GitHub 리포지토리, CI/CD 파이프라인, 클라우드 프로바이더(AWS, GCP, Azure), SaaS 연동, 내부 도구, 크리덴셜이 존재할 수 있는 모든 곳을 스캔합니다. 각 크리덴셜에 소유자 매핑을 시도합니다. CloudTrail, Audit Log, 커밋 히스토리에서 생성자 정보를 추출합니다. 매핑이 불가능한 키의 비율을 파악합니다. 이것이 Unattributed Key 비율이고, NHI 보안 성숙도의 가장 직관적인 지표다.

CSA의 2026 State of NHI Security 보고서에 따르면, NHI 크리덴셜의 수는 인간 아이덴티티의 평균 17배다. 100명 규모 조직에 1,700개 이상의 NHI 크리덴셜이 존재할 수 있다는 의미다. 이 숫자를 모르는 상태에서 보안 정책을 수립하는 것은 적의 규모를 모르고 전쟁 계획을 세우는 것과 같습니다.

Phase 2: 즉각 위험 제거 (2-4주)

가시성이 확보되면, 가장 위험한 유형부터 처리합니다. 우선순위는 위험도와 악용 용이성으로 결정합니다.

첫째, Ghost Key 전수 조사다. HR 시스템의 퇴사자 목록과 NHI 크리덴셜 인벤토리를 대조합니다. 퇴사한 직원이 생성하거나 관리하던 키가 아직 활성 상태인지 확인하고, 발견 즉시 폐기합니다. OWASP NHI Top 10이 Improper Offboarding을 1위 위험으로 선정한 이유가 여기에 있습니다.

둘째, Public Key 스캐닝입니다. 조직의 모든 public 리포지토리를 스캔하여 노출된 크리덴셜을 식별하고, 발견 즉시 로테이션합니다. GitGuardian의 2025 State of Secrets Sprawl 보고서에 따르면, GitHub에 노출된 시크릿의 90% 이상이 5일 후에도 여전히 유효했습니다.

셋째, Aged Key 식별입니다. 90일 이상 로테이션되지 않은 크리덴셜을 목록화하고, 위험도가 높은 것부터 로테이션을 시작합니다. 프로덕션 의존성이 높은 키는 Phase 3에서 별도 프로세스로 처리합니다.

Phase 3: 프로세스 구축 (1-3개월)

Phase 1-2가 현재 상태를 정리하는 것이라면, Phase 3는 새로운 문제가 발생하지 않도록 프로세스를 만듭니다.

크리덴셜 생성 시 소유자 태깅을 의무화합니다. 모든 새로운 NHI 크리덴셜은 생성 시점에 소유자가 지정되어야 합니다. 소유자 없는 키 생성을 기술적으로 차단하거나, 최소한 정책적으로 금지합니다. 이것만으로 새로운 Unattributed Key의 유입이 차단됩니다.

퇴사 오프보딩에 NHI 크리덴셜 폐기를 포함합니다. HR 이벤트(퇴사 처리)가 트리거되면, 해당 직원에게 매핑된 모든 NHI 크리덴셜이 열거되고, 폐기 또는 재할당 프로세스가 시작됩니다. 수동 체크리스트가 아니라 자동화된 워크플로여야 합니다.

비코드 소스 모니터링을 도입합니다. Slack, Jira, Confluence, Notion, 개발자들이 크리덴셜을 공유하는 곳은 GitHub만이 아니다. 비코드 소스 스캐닝을 도입하면 Shadow Key와 Drifted Key의 탐지 범위가 획기적으로 넓어진다.

로테이션 정책을 수립하고 자동화합니다. 크리덴셜 유형별 최대 수명을 정의하고, 자동 로테이션을 구현합니다. 자동화가 불가능한 키에 대해서는 알림 및 수동 로테이션 프로세스를 만듭니다.

Phase 4: 지속적 거버넌스 (상시)

Phase 1-3을 완료하면, 상시 운영 모드로 전환합니다.

크로스 플랫폼 드리프트 모니터링을 상시 운영합니다. 동일 크리덴셜이 새로운 플랫폼에서 발견될 때 즉시 알림을 받는다. Drifted Key와 Over-shared Key를 실시간으로 탐지합니다.

크리덴셜 sprawl 대시보드를 운영합니다. 전체 NHI 크리덴셜 수, 유형별 분포, Unattributed Key 비율, 평균 수명, 로테이션 준수율 등 핵심 지표를 실시간으로 추적합니다.

분기별 NHI 감사를 실시합니다. 전체 인벤토리를 재검증하고, CRE 분류를 업데이트하며, 새로운 위험 패턴을 식별합니다. 감사 결과를 거버넌스 프레임워크에 피드백합니다.

타임라인이 중요합니다. Phase 1은 2주 안에 가치를 제공한다, 이전에 몰랐던 숫자를 알게 되고, 그 지식만으로도 의사결정이 달라집니다. Phase 2는 향후 90일 내에 침해로 이어질 가능성이 가장 높은 위험을 제거합니다. Phase 3는 새로운 위험을 만들어내는 구조적 결함을 차단합니다. Phase 4는 조직이 이전 상태로 퇴보하지 않도록 보장합니다. 각 단계는 이전 단계 위에 구축되지만, 각 단계는 후속 단계가 지연되더라도 독립적으로 가치를 제공합니다.

자가진단 체크리스트, 당신의 조직은 몇 개를 통과하는가

이 시리즈를 읽으면서 "우리 조직은 해당 안 된다"고 생각했는가요? 아래 8개 항목으로 확인해 보겠습니다. 각 항목은 8가지 CRE 유형 중 하나에 직접 대응합니다.

[ ] 전체 NHI 크리덴셜 수를 알고 있는가요?
[ ] 모든 크리덴셜에 소유자가 매핑되어 있는가요? (Unattributed Key)
[ ] 퇴사 시 NHI 크리덴셜 폐기 프로세스가 있는가요? (Ghost Key)
[ ] 90일 이상 미로테이션 크리덴셜을 식별하고 있는가요? (Aged Key)
[ ] Git 외 소스(Slack, Jira, Confluence)의 시크릿을 모니터링하는가요? (Shadow Key)
[ ] 동일 시크릿이 몇 곳에 존재하는지 파악하고 있는가요? (Over-shared Key)
[ ] 크리덴셜 삭제 시 실제 폐기(revoke)까지 확인하는가요? (Zombie Key)
[ ] 크로스 플랫폼 크리덴셜 드리프트를 탐지하는가요? (Drifted Key)

8개 중 3개 이하로 체크했다면, 이 시리즈의 시나리오 중 최소 하나는 당신의 조직에서 지금 이 순간 일어나고 있습니다.

4-5개를 체크했다면, 기본적인 가시성은 있지만 연쇄 패턴에 취약합니다. 하나의 유형을 탐지해도 연결된 다른 유형을 놓칠 가능성이 높다.

6-7개를 체크했다면, 강력한 NHI 보안 프로그램을 운영하고 있습니다. 하지만 8번째 빈칸이 공격자의 진입점이 될 수 있습니다.

8개 전부 체크했다면, 이 시리즈의 모든 시나리오에 대한 방어 체계를 갖추고 있습니다. 다음 단계는 이 상태를 유지하는 것이다, 거버넌스는 일회성 프로젝트가 아니라 상시 운영입니다.

Cremit Argus, 전체 그림을 보는 유일한 방법

8가지 CRE 유형을 개별 도구로 각각 대응하면 어떻게 될까? Ghost Key 탐지 도구, Public Key 스캐너, Aged Key 모니터링 도구, Shadow Key 탐지기를 각각 도입하고, 각각의 대시보드를 관리하고, 각각의 알림을 처리해야 합니다. 도구 8개, 대시보드 8개, 프로세스 8개. 그리고 여전히 유형 간 연결 관계는 보이지 않습니다. Over-shared Key로 처리한 것이 사실은 Drifted Key이기도 했다는 것을 뒤늦게 발견합니다.

Cremit Argus는 이 문제를 근본적으로 다른 방식으로 접근합니다. 하나의 플랫폼에서 8가지 CRE 유형 전체를 탐지하고, 분류하고, 연결 관계를 추적합니다.

CRE 분류 체계 기반 자동 탐지 및 분류. 발견된 크리덴셜이 8가지 유형 중 어디에 해당하는지 자동으로 분류합니다. 하나의 크리덴셜이 여러 유형에 해당하면 중첩 분류를 제공합니다.

크로스 플랫폼 통합 스캐닝. 코드 저장소만 스캔하는 것이 아니다. Slack, Jira, Confluence, CI/CD 파이프라인, 클라우드 프로바이더, NHI 크리덴셜이 존재할 수 있는 모든 곳을 통합 스캔합니다. Shadow Key와 Drifted Key를 코드 소스와 동일한 수준의 가시성으로 탐지합니다.

소유자 자동 추론 및 매핑. CloudTrail, Audit Log, 커밋 히스토리, 조직도를 교차 분석하여 각 크리덴셜의 소유자를 자동으로 추론합니다. Unattributed Key를 Zero에 가까운 비율로 줄이는 것이 목표다.

NHI 거버넌스 대시보드. 전체 크리덴셜 인벤토리, CRE 유형별 분포, 연결 관계 맵, Unattributed Key 비율, 로테이션 준수율, Kill Chain 매핑, CISO가 NHI 보안 상태를 하나의 화면에서 파악할 수 있습니다.

Cremit Argus로 NHI 크리덴셜 전체 그림을 확인하세요.

시리즈 마무리, 8가지 경로, 하나의 원칙

8주에 걸쳐 8가지 NHI 크리덴셜 위험 유형을 분석했습니다. 각각의 글은 독립적인 시나리오였지만, 이 총정리에서 보았듯이 8가지 유형은 근본 원인을 공유하고, 서로를 유발하며, 공격자의 Kill Chain 위에서 연쇄적으로 작동합니다.

Ghost Key: 퇴사한 개발자의 AWS 키는 아직 출근 중이다. 퇴사 후 92일간 방치된 AWS 키가 인포스틸러를 통해 다크웹으로 유출된 시나리오.
Shadow Key: 시크릿 매니저 바로 옆에 하드코딩된 비밀번호. 장애 대응 중 Slack과 Confluence에 공유된 크리덴셜이 수거되지 않은 시나리오.
Aged Key: 3년간 프로덕션을 지탱한 해골 열쇠. "건드리면 안 된다"는 관성으로 3년간 미로테이션된 키가 공급망 공격에 활용된 시나리오.
Over-shared Key: Slack 봇 토큰 하나를 10명이 공유하면 생기는 일. 하나의 키가 14곳에 복제되어 로테이션이 사실상 불가능해진 시나리오.
Zombie Key: 코드에서 지워도 죽지 않는 키. 파일을 삭제하고 alert를 마감했지만, 키 자체는 여전히 유효했던 시나리오.
Drifted Key: CI/CD 봇이 DB 비밀번호를 Jira에 자동 첨부한 날. 하나의 크리덴셜이 7개 플랫폼 유형을 횡단한 시나리오.
Public Key: .env 파일이 GitHub에 올라간 뒤 4분간 벌어진 일. 공개 저장소 노출 후 4분 만에 공격자 봇이 발견한 시나리오.
Unattributed Key: 3,400개 시크릿의 60%는 소유자를 모른다. 소유자 매핑 없이 운영되는 크리덴셜의 구조적 위험 시나리오.

이 시리즈의 결론은 단순합니다. NHI 크리덴셜 보안의 출발점은 "모든 NHI 크리덴셜에 소유자를 매핑하는 것"입니다. 소유자가 매핑되면 퇴사 시 폐기할 수 있고(Ghost Key 해결), 로테이션 책임자가 생기고(Aged Key 해결), 알림 수신자가 존재하고(Unattributed Key 해결), 키의 존재를 파악할 수 있다(Shadow Key, Drifted Key 탐지 가능). 하나의 원칙이 여러 유형을 동시에 해결합니다.

NHI 크리덴셜은 눈에 보이지 않습니다. 보이지 않는 것은 관리할 수 없습니다. 관리할 수 없는 것은 결국 침해됩니다. 가시성이 첫 번째이고, 소유자 매핑이 두 번째이며, 지속적 거버넌스가 세 번째다. 이 세 가지가 갖춰지면, 8가지 경로 모두를 차단할 수 있습니다.

시리즈를 읽어주셔서 감사합니다.

Cremit은 NHI 보안 회사입니다. [cremit.io에서 더 알아보세요](https://cremit.io)