NHI Kill Chain: Unattributed Key — 3,400개의 시크릿, 누가 만들었는지 아무도 모른다

3,400개의 시크릿. 소유자를 아는 건 40%.

2026년 초. 직원 500명 규모의 엔터프라이즈 SaaS 기업. 창립 8년차. 그 사이 세 번의 인수합병, 다섯 번의 조직 개편을 거쳤다. 서비스는 안정적으로 돌아가고 있었고, 매출도 꾸준히 성장하고 있었다. 외형만 보면 건강한 스케일업이었다.

신임 CISO가 부임했습니다. 전임자가 건강 문제로 갑작스럽게 퇴사한 뒤 6개월간 CISO 자리가 공석이었다. 신임 CISO가 첫 번째로 한 일은 보안 실태 전수 조사였습니다.

"우리 조직에 NHI 크리덴셜이 총 몇 개 있는지 파악하세요."

보안팀 4명이 2주간 매달렸다. AWS IAM, GitHub, Slack, CI/CD 파이프라인, 클라우드 서비스, SaaS 인테그레이션. 결과는 보안팀 스스로도 예상하지 못한 규모였습니다.

총 3,400개의 활성 NHI 크리덴셜. API 키, 서비스 계정, 봇 토큰, IAM 액세스 키, 인테그레이션 토큰. 직원 1명당 평균 6.8개의 NHI 크리덴셜이 존재한다는 계산이었다.

이것만으로도 충분히 많았지만, 진짜 문제는 그다음이었다.

소유자가 명확한 크리덴셜은 약 40%(1,360개). 나머지 60%(2,040개)는 누가 만들었는지, 왜 만들었는지, 아직 필요한지 알 수 없었다. 소유자 불명.

2,040개의 프로필을 하나씩 들여다보니 패턴이 보였습니다. 각각 다른 이유지만, 근본적으로는 같은 문제다: 크리덴셜과 사람 사이의 연결이 끊어진 것입니다.

생성자 이메일이 이미 비활성화된 퇴사자 계정. 누구의 것이었는지 추정은 가능하지만 현재 담당자는 없습니다. 보안팀이 추적해 보니 퇴사 시점이 3년에 걸쳐 분포되어 있었다. 첫 번째 인수합병 당시 떠난 엔지니어의 키도 있었고, 정식 오프보딩 없이 계약이 종료된 외주 개발자의 키도 있었다. 크리덴셜은 이들 모두보다 오래 살아남았습니다.

terraform-deploy, ci-bot, monitoring-svc 같은 이름만 달린 공용 서비스 계정. 누군가가, 어느 시점에, 어떤 이유로 만든 것입니다. 하지만 그 "누군가"는 더 이상 식별할 수 없습니다. 서비스 계정을 처음 논의했던 Slack 채널은 아카이브되었고, 인테그레이션을 문서화했던 Confluence 페이지는 워크스페이스 정리 과정에서 삭제되었다. 조직의 기억이 사라졌습니다.

2년 전 두 번째 인수합병으로 가져온 시스템의 크리덴셜. 피인수 기업에서 마이크로서비스 플랫폼 전체가 자체 API 키, 서비스 계정, 인테그레이션 토큰과 함께 넘어왔습니다. 피인수 기업의 기술 리드가 전환 기간 6개월 동안 남아 있다가 퇴사했습니다. 그와 함께 그 크리덴셜들이 왜 존재하는지 이해하는 마지막 사람이 사라졌습니다.

생성 시점이 4년 전이라 담당자가 세 번이나 바뀐 API 키. 현재 팀 리드에게 물어봐도 돌아오는 답은 한결같다: "제가 만든 건 아닌데요. 이전 리드한테 인수인계 받았고, 그 사람도 그 전 사람한테 받은 거예요."

CISO는 보고서를 받아들고 정리를 지시했습니다. 하지만 보안팀은 손을 댈 수가 없었다. 2,040개 중 어떤 것이 프로덕션에 필요하고, 어떤 것이 폐기해도 되는지 판단할 수 있는 사람이 없기 때문입니다. 함부로 폐기하면 프로덕션 장애가 날 수 있습니다. 방치하면 공격 표면이 계속 늘어난다. 하나씩 수동으로 추적 조사를 하면 수개월이 걸린다.

폐기할 수도, 로테이션할 수도, 책임질 사람도 없는 미아 크리덴셜. 이것이 Unattributed Key다.

이 키는 왜 위험한가

Unattributed Key는 NHI 크리덴셜 위험 유형 중 가장 구조적인 문제다. 유출(Public Key)이나 퇴사자 방치(Ghost Key)처럼 특정 사건에 의해 발생하는 것이 아니라, 조직이 성장하는 과정에서 자연스럽게 누적되기 때문입니다. 이것은 사고가 아니라 엔트로피다.

소유자 태깅 체계의 부재가 근본 원인입니다. 대부분의 조직에서 NHI 크리덴셜을 생성할 때 소유자를 명시적으로 태깅하는 정책이 없습니다. AWS IAM 액세스 키를 발급할 때 "이 키의 책임자" 필드가 필수가 아니다. GitHub Personal Access Token을 생성할 때 "이 토큰을 관리할 팀" 메타데이터를 입력하는 워크플로우가 없습니다. Slack 봇 토큰, Datadog API 키, CI/CD 서비스 계정, 전부 마찬가지다. 생성은 쉽고, 태깅은 선택사항이며, 대부분 선택하지 않습니다.

조직 엔트로피가 문제를 가속화합니다. 생성 시점에 소유자가 명확하더라도, 시간이 지나면 모호해진다. 담당자가 팀을 옮긴다. 팀이 해체됩니다. 프로젝트가 종료됩니다. 인수합병으로 새로운 시스템이 유입됩니다. 조직 개편이 일어납니다. 크리덴셜은 이 모든 변화를 무시한 채 활성 상태를 유지합니다. 사람은 바뀌고, 팀은 사라지고, 프로젝트는 종료되지만, 크리덴셜은 폐기되지 않습니다.

인수합병은 Unattributed Key의 가장 강력한 생성기다. 피인수 기업의 인프라와 서비스를 통합할 때, NHI 크리덴셜 전수 조사를 하는 기업은 극소수다. 대부분은 "시스템이 정상적으로 작동하니 건드리지 말자"는 접근을 취합니다. 그 결과, 피인수 기업의 크리덴셜은 생성 맥락 자체를 아는 사람이 없는 상태로 인수 기업의 인프라에 잔존합니다. 한 번의 인수합병이 수백 개의 Unattributed Key를 한꺼번에 만들어냅니다.

이 세 가지가 복합적으로 작용하면 결과는 예측 가능합니다. 조직이 오래될수록, 규모가 클수록, 인수합병을 많이 할수록 Unattributed Key 비율은 올라갑니다. 스타트업 초기에는 10% 미만이던 비율이 5년 후에는 40%, 8년 후에는 60%를 넘긴다. 이것은 보안팀의 실수가 아니라, 소유자 태깅 체계 없이 조직을 성장시킨 구조적 결과다.

Kill Chain, Unattributed Key가 침해로 이어지는 5단계

Unattributed Key 킬체인은 다른 NHI 위험 유형과 구별되는 고유한 특징이 있습니다. 외부 유출이나 단일 사건으로 시작되는 것이 아니라, 거버넌스 부재가 장기간 누적된 결과로 발생합니다. 공격자가 적극적으로 찾아 나서는 것이 아니라, 조직의 구조적 약점이 스스로를 노출시킨다.

1단계: Ownership Gap at Creation, 생성 시점의 소유자 공백

크리덴셜 생성 시 소유자 태깅 체계가 없습니다. 서비스 계정은 "팀 공용"이라는 모호한 소유 구조로 만들어지고, API 키는 프로젝트 시작 시 빠르게 발급되며, 인테그레이션 토큰은 설정 과정에서 자연스럽게 생성됩니다. 이 모든 것이 명시적 소유자 없이 탄생합니다. AWS IAM에서 서비스 계정을 만들 때 "Owner" 태그를 다는 정책이 있는 조직은 소수다. 대부분은 Description 필드조차 비워둔다.

2단계: Organizational Entropy, 조직 변동으로 인한 맥락 소실

시간이 흐른다. 원래 크리덴셜을 만든 사람이 퇴사합니다. 관리하던 팀이 해체됩니다. 인수합병으로 새로운 시스템이 유입됩니다. 프로젝트가 종료되지만 인프라는 남는다. 이 각각의 사건마다 크리덴셜의 맥락, 왜 만들었는지, 어디에 쓰이는지, 누가 관리하는지, 이 한 겹씩 사라집니다. 3년 된 크리덴셜의 맥락을 완전히 아는 사람은 대부분 조직에 남아 있지 않다.

3단계: Governance Paralysis, 거버넌스 마비

소유자가 불명이면 폐기 판단이 불가능합니다. "이 키를 삭제해도 되나요?"라는 질문에 답할 수 있는 사람이 없습니다. 프로덕션에서 사용 중일 수도 있고, 아닐 수도 있습니다. 확인하려면 수동으로 사용 로그를 추적하고, 연관 시스템을 파악하고, 테스트 환경에서 비활성화 후 영향을 관찰해야 합니다. 크리덴셜 하나당 수시간에서 수일. 2,040개를 이렇게 처리하는 것은 현실적으로 불가능합니다. 결론은 항상 같다: "일단 두자." 무기한 방치가 시작됩니다.

4단계: Silent Accumulation, 조용한 누적

방치가 기본 대응이 되면, Unattributed Key의 절대 수는 계속 늘어난다. 새로운 크리덴셜은 매일 생성되고, 기존의 Unattributed Key는 정리되지 않습니다. 5년 전에 만들어진 키, 3년 전 해체된 팀의 서비스 계정, 지난번 인수합병에서 가져온 토큰, 모두 활성 상태로 쌓여갑니다. 전체 NHI 크리덴셜 중 Unattributed 비율은 해가 갈수록 올라갑니다. 공격 표면은 아무 사건 없이도 매월 확대됩니다.

5단계: Undetectable Compromise, 감지 불가능한 침해

Unattributed Key가 침해되면 어떻게 되는가요? 일반적인 보안 모니터링은 소유자 기반으로 작동합니다. 비정상 접근이 탐지되면, 해당 크리덴셜의 소유자에게 알림이 갑니다. 소유자가 확인하고, 정상 사용인지 침해인지 판단합니다. 하지만 Unattributed Key에는 소유자가 없습니다. 알림을 받을 사람이 없습니다. SIEM에 이상 패턴이 기록되더라도, 그것을 검토하고 대응할 담당자가 지정되어 있지 않다.

실무적 상황을 생각해 보겠습니다. 공격자가 2,040개의 Unattributed Key 중 하나를 입수합니다. 크리덴셜 덤프를 통해서일 수도, 이미 침해된 다른 시스템에서의 횡이동을 통해서일 수도, 서드파티 인테그레이션의 공급망 침해를 통해서일 수도 있습니다. 공격자가 인증합니다. 크리덴셜은 작동합니다. API 호출이 시작됩니다. 만약 해당 크리덴셜이 프로덕션 수준의 권한을 가지고 있다면, 많은 서비스 계정이 그렇다, 최소 권한 원칙이 정책이 아니라 희망이었던 시절에 만들어졌기 때문에, 공격자는 이제 프로덕션 데이터나 인프라, 혹은 둘 다에 접근할 수 있습니다.

보안팀의 SIEM이 비정상 접근 패턴을 감지할 수 있습니다. 하지만 알림 라우팅 테이블은 "크리덴셜 소유자에게 통보"라고 되어 있습니다. 소유자 필드는 비어 있습니다. 알림은 아무에게도 가지 않거나, 주간 단위로 검토하는 일반 대기열에 들어갑니다. 누군가 알아챌 때쯤이면 공격자는 이미 수일간 내부에 있었다.

공격자 입장에서 이것은 완벽한 사각지대다. 침해되어도 감지되지 않고, 감지되어도 대응되지 않는 크리덴셜. Unattributed Key는 관리되지 않는 것을 넘어, 방어되지 않는 크리덴셜입니다.

왜 기존 보안 체계로는 잡히지 않는가

Unattributed Key 문제가 수년간 방치되는 이유는, 이 문제를 해결하도록 설계된 도구가 기존 보안 스택에 존재하지 않기 때문입니다.

IAM의 소유자 필드는 선택사항입니다. AWS IAM, GCP IAM, Azure AD, 주요 클라우드 프로바이더의 IAM 시스템은 서비스 계정 생성 시 소유자 태그를 필수로 요구하지 않습니다. Description 필드가 있고, 태그를 붙일 수 있지만, 강제하는 정책이 기본으로 활성화되어 있지 않다. 소유자 태깅은 조직이 자체적으로 정책을 수립하고 강제해야 하는 영역입니다. 대부분의 조직은 이 정책을 수립하지 않습니다.

CMDB에 NHI가 포함되어 있지 않다. 전통적인 IT 자산 관리 시스템(CMDB)은 서버, 네트워크 장비, 소프트웨어 라이선스를 추적합니다. NHI 크리덴셜, API 키, 서비스 계정, 봇 토큰, 은 대부분의 CMDB에서 자산으로 분류되지 않습니다. 보안팀이 "자산 인벤토리"를 요청하면, NHI 크리덴셜은 빠져 있습니다. 존재하지 않는 것은 관리할 수도 없습니다.

인수합병 보안 실사의 사각지대. 인수합병 시 보안 실사(due diligence)는 통상 네트워크 아키텍처, 데이터 분류, 컴플라이언스 상태, 취약점 스캔에 초점을 맞춘다. "피인수 기업에 NHI 크리덴셜이 몇 개 있고, 각각의 소유자가 누구인가요?"라는 질문이 실사 체크리스트에 포함된 경우는 드물다. 인수 완료 후, 피인수 기업의 크리덴셜은 소유자 매핑 없이 인수 기업의 인프라에 합류합니다.

분기별 접근 리뷰는 인간 계정에 집중합니다. SOX, SOC2, ISO 27001 등 컴플라이언스 프레임워크가 요구하는 접근 리뷰는 전통적으로 "사용자 계정"에 초점을 맞춘다. 서비스 계정, API 키, 봇 토큰은 리뷰 범위에서 빠지거나, "시스템 계정"이라는 별도 카테고리로 분류되어 실질적 검토 없이 "유지"로 처리됩니다.

"인벤토리가 있다"는 것은 "관리하고 있다"는 것과 다릅니다. 많은 CISO가 "크리덴셜 인벤토리가 있다"고 말합니다. 하지만 인벤토리에 소유자 필드가 비어 있다면, 그것은 인벤토리가 아니라 목록일 뿐입니다. 목록은 "무엇이 있는지"를 알려주지만, "누가 관리하는지"는 알려주지 않습니다. 거버넌스는 후자 없이는 작동하지 않습니다.

이 모든 갭의 누적 효과는, 서류상으로는 완전해 보이지만 중심부에 구조적 구멍이 있는 보안 체계다. IAM이 있고, CMDB가 있고, 분기별 접근 리뷰가 있고, 컴플라이언스 인증이 있습니다. 그리고 아무도 소유하지 않고, 아무도 모니터링하지 않고, 아무도 안전하게 폐기할 수 없는 2,040개의 활성 크리덴셜이 있습니다. 도구는 전부 갖춰져 있습니다. 문제는 그 사이에 빠져 있습니다.

실제 사례와 업계 데이터

Unattributed Key는 이론적 위험 분류가 아니다. 대규모 침해 사고의 공통 패턴으로 반복되고 있습니다.

CSA의 2026 State of NHI Security 보고서는 NHI 거버넌스의 현실을 수치로 보여줍니다. 조사 대상 조직의 NHI 크리덴셜 중 소유자 매핑이 완료된 비율은 평균 30% 미만이었다. 나머지 70%는 소유자가 불명이거나, 부정확하거나, 아예 매핑을 시도하지 않은 상태였습니다. 이 70%가 모두 Unattributed Key다. 우리 시나리오의 60%는 업계 평균에 가까운 수치일 뿐입니다.

OWASP NHI Top 10은 부적절한 오프보딩(Improper Offboarding)을 NHI 보안의 1순위 위험으로 지정했습니다. Unattributed Key는 오프보딩 문제의 상위 집합입니다. 퇴사자의 키가 방치되는 이유 자체가 소유자 매핑이 안 되어 있기 때문입니다. 소유자를 알면 퇴사 시 폐기할 수 있습니다. 소유자를 모르면 퇴사 여부조차 파악할 수 없습니다.

Verizon 2025 DBIR에 따르면 크리덴셜 기반 공격은 전체 침해 사고의 약 20%를 차지했습니다. 이 비율은 수년간 일관되게 높은 수준을 유지하고 있습니다. 침해에 사용된 크리덴셜 중 상당수가 "누구의 것인지 모르는" 크리덴셜이었다는 점을 고려하면, Unattributed Key는 크리덴셜 기반 공격의 은밀한 기반입니다.

2023년 1월 CircleCI 침해 사고에서는 엔지니어의 디바이스에 설치된 인포스틸러를 통해 세션 토큰이 탈취되었고, 이를 통해 고객의 시크릿이 노출되었다. 사고 후 CircleCI는 모든 고객에게 시크릿 로테이션을 권고했습니다. 하지만 소유자가 불명인 시크릿은 로테이션 권고를 받을 사람이 없습니다. 소유자 불명 크리덴셜은 인시던트 대응의 사각지대이기도 합니다.

Uber의 2022년 9월 침해 사고에서는 내부 시스템의 PowerShell 스크립트와 네트워크 공유에서 발견된 크리덴셜이 AWS, Google Workspace, Slack, HackerOne으로의 횡이동에 사용되었다. 내부 시스템에 산재한 소유자 불명 크리덴셜이 공격 체인의 일부였습니다. 조직 규모가 클수록, 인수합병 이력이 많을수록, 이런 "아무도 모르는 크리덴셜"의 수는 기하급수적으로 늘어난다.

GitGuardian의 2025 State of Secrets Sprawl 보고서는 GitHub 리포지토리에 노출된 시크릿의 90% 이상이 탐지 후 5일이 지나도 여전히 유효했다고 밝혔다. Unattributed Key는 이보다 훨씬 긴 유효 기간을 갖는다. 로테이션할 사람이 없으니 무기한 유효합니다. 3년, 5년, 8년. 만료 정책이 없으면 키는 영원히 살아 있습니다.

탐지 및 대응 가이드

Unattributed Key를 해결하는 것은 크리덴셜 하나를 폐기하는 문제가 아니라, NHI 거버넌스 체계를 구축하는 문제다. 단기 대응과 장기 체계 수립을 병행해야 합니다.

1단계: 전수 인벤토리와 소유자 매핑

모든 NHI 크리덴셜을 열거하고, 각각에 소유자를 매핑합니다. 소유자 매핑의 데이터 소스는 복수여야 합니다. IAM 생성 로그(CloudTrail, Audit Log), 코드 리포지토리의 커밋 히스토리, CI/CD 파이프라인 설정 파일, Terraform/IaC 코드의 변경 이력, Slack 채널의 인테그레이션 설정. 단일 소스로는 매핑률이 낮다. 복수 소스를 교차 검증해야 60% 이상의 매핑률을 달성할 수 있습니다. 매핑이 불가능한 크리덴셜은 "Unattributed" 태그를 부여하고, 별도 관리 대상으로 분류합니다.

2단계: 위험도 기반 우선순위 결정

2,040개의 Unattributed Key를 동시에 처리하는 것은 불가능합니다. 위험도 기반으로 우선순위를 정해야 합니다. 우선 처리 대상은 다음과 같다: 프로덕션 환경에 대한 쓰기 권한을 가진 크리덴셜, 90일 이상 사용 이력이 없는 크리덴셜(높은 확률로 불필요), 인수합병으로 유입되었으나 통합되지 않은 시스템의 크리덴셜, admin/root 수준의 권한을 가진 서비스 계정. 이 기준에 따라 상위 10%를 먼저 처리하는 것이 현실적 접근입니다.

3단계: 안전한 폐기 프로세스

소유자를 알 수 없는 크리덴셜을 폐기할 때는 점진적 접근이 필요합니다. 즉시 삭제가 아니라, 먼저 권한을 축소합니다. 읽기 전용으로 전환하거나, 특정 리소스 접근만 차단합니다. 2주간 모니터링합니다. 장애가 발생하지 않으면 완전 비활성화합니다. 비활성화 후 추가로 2주 모니터링. 이상 없으면 삭제합니다. 각 단계에서 롤백이 가능해야 합니다. 이 프로세스가 번거롭지만, "함부로 삭제해서 프로덕션이 터졌다"는 상황보다는 낫다.

4단계: 생성 시 소유자 태깅 의무화

더 이상 Unattributed Key가 만들어지지 않도록, 크리덴셜 생성 시 소유자 태깅을 의무화하는 정책을 수립합니다. IaC(Infrastructure as Code)에서 서비스 계정 생성 시 owner 태그가 없으면 배포를 차단하는 정책. API 키 발급 포탈에서 소유자 필드를 필수로 설정. 정기적으로 소유자 태그 누락 크리덴셜을 감사하는 자동화. 문화보다 시스템이 효과적입니다. 사람에게 "태깅하세요"라고 교육하는 것보다, 태깅 없이는 생성 자체가 안 되게 만드는 것이 훨씬 확실합니다.

5단계: 정기적 소유자 검증

소유자가 매핑된 크리덴셜도 시간이 지나면 Unattributed가 될 수 있습니다. 소유자가 퇴사하거나, 팀이 변경되거나, 역할이 바뀔 수 있기 때문입니다. 분기마다 소유자 유효성을 검증하는 프로세스가 필요합니다. 소유자가 여전히 조직에 있는지, 해당 크리덴셜을 관리할 역할에 있는지 확인합니다. 소유자가 변경되었으면 새로운 소유자를 지정합니다. 소유자를 지정할 수 없으면 Unattributed로 재분류하고 폐기 프로세스를 시작합니다. 시크릿 탐지 및 관리에 대한 상세 구현 방법은 Git Secret Scanning 완벽 구현 가이드를 참고하세요.

Cremit Argus가 Unattributed Key를 해결하는 방법

Unattributed Key의 핵심 난관은 소유자 매핑입니다. 수천 개의 크리덴셜을 일일이 수동으로 추적하는 것은 비현실적입니다. Cremit Argus는 이 과정을 자동화합니다.

Argus는 다중 소스 기반 소유자 자동 추론을 수행합니다. IAM 생성 로그, 코드 리포지토리의 커밋 히스토리, CI/CD 파이프라인 설정, IaC 코드의 변경 이력을 교차 분석하여 각 크리덴셜의 생성자와 현재 관리자를 자동으로 추론합니다. 단일 데이터 소스로는 30%에 불과하던 매핑률을 복수 소스 교차 검증으로 80% 이상까지 끌어올린다.

Argus의 NHI 거버넌스 대시보드는 전체 크리덴셜 현황을 소유자 매핑 상태별로 시각화합니다. 전체 크리덴셜 수, 소유자 매핑 완료 수, Unattributed 수, 위험도별 분류를 실시간으로 보여줍니다. CISO는 "우리 조직의 Unattributed Key가 몇 개인지"를 대시보드 한 번 열어 확인할 수 있습니다. 2주간 전수 조사를 할 필요가 없습니다.

Argus는 크로스 플랫폼 가시성을 제공합니다. AWS, GCP, Azure, GitHub, Slack, CI/CD 시스템, SaaS 인테그레이션, NHI 크리덴셜이 존재하는 모든 플랫폼을 단일 뷰에서 관리합니다. 하나의 크리덴셜이 여러 시스템에 걸쳐 사용되고 있는 경우도 추적합니다. 인수합병으로 유입된 시스템의 크리덴셜도 동일한 거버넌스 범위 안에서 관리할 수 있습니다.

소유자 변경이 감지되면, 예를 들어 매핑된 소유자가 퇴사하거나 팀이 변경되면, Argus는 자동으로 해당 크리덴셜을 "재지정 필요" 상태로 전환하고, 관련 팀에 알림을 보냅니다. Unattributed Key가 되기 전에 선제적으로 소유자를 재지정합니다.

Cremit Argus로 NHI 거버넌스를 시작하세요. cremit.io

NHI Kill Chain 시리즈 안내

이 글은 NHI Kill Chain 시리즈의 여덟 번째 글입니다. 이 시리즈는 조직 내부에 숨어 있는 가장 위험한 9가지 NHI 크리덴셜 유형을 분석합니다. 각 유형은 독립적이면서도 서로 연결되어 있습니다.

공개 리포지토리에 노출된 키(Public Key)가 로테이션되지 않으면 Aged Key가 됩니다. 퇴사자의 키(Ghost Key)가 소유자 매핑 없이 방치되면 Unattributed Key가 됩니다. 하나의 크리덴셜 관리 실패가 어떻게 다른 위험 유형으로 전이되는지 이해하는 것이 이 시리즈의 핵심입니다.

1. Public Key: .env 파일이 GitHub에 올라간 후 4분 동안 벌어지는 일
2. Ghost Key: 퇴사한 개발자의 AWS 키는 아직 출근 중이다
3. Aged Key: 3년간 프로덕션을 지탱한 마스터 키
4. Zombie Key: 코드에서 삭제했다고 죽은 게 아니다
5. Over-shared Key: 10명이 하나의 Slack 봇 토큰을 공유하면 벌어지는 일
6. Shadow Key: 시크릿 매니저 바로 옆에 하드코딩된 키
7. Drifted Key: CI/CD 봇이 DB 비밀번호를 Jira에 자동 첨부할 때
8. Unattributed Key: 3,400개의 시크릿, 누가 만들었는지 아무도 모른다 (현재 글)
9. 시리즈 총정리: NHI Kill Chain 전체 분석과 통합 대응 전략 (예정)

이전 글: NHI Kill Chain: Drifted Key, CI/CD 봇이 DB 비밀번호를 Jira에 자동 첨부할 때

다음 글: NHI Kill Chain: 시리즈 총정리, 전체 분석과 통합 대응 전략

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