NHI Kill Chain: Shadow Key — 시크릿 스캐너는 코드를 본다. Slack은 보지 않는다.
프로덕션 장애 한 번으로 크리덴셜이 6개 비코드 플랫폼에 퍼졌습니다. 시크릿 스캐너는 하나도 찾지 못했습니다. Shadow Key 킬체인 분석.
새벽 3시, 장애가 터지면 보안은 무너진다
2025년 가을. 직원 350명, 시리즈 C 클로즈, SOC 2 Type II 인증 완료. 보안팀 5명이 상주하고, HashiCorp Vault를 도입했으며, GitHub에 secret scanning을 활성화한 중견 핀테크 SaaS 기업. CISO는 이사회에 "시크릿 관리는 잘 되고 있다"고 보고한 지 한 달이 채 지나지 않은 상태였습니다.
토요일 새벽 3시 12분. 결제 서비스가 멈췄습니다.
PagerDuty가 온콜 SRE 박 엔지니어에게 알림을 보냈습니다. 동시에, 조직이 수년간 꼼꼼하게 구축해온 자동화 파이프라인이 작동하기 시작했습니다. 문제는, 이 자동화가 보안의 적이 될 줄은 아무도 몰랐다는 것입니다.
자동 확산 --- 사람이 아무것도 하지 않아도 이미 시작되었다
Sentry가 결제 서비스의 에러를 캡처했습니다. stack trace의 error context에 Stripe API live key가 포함되어 있었습니다. sk_live_4eC39HqLyjWDarjtT1zdp7dc --- 프로덕션 결제 키 전체가 평문으로 stack trace에 찍혔습니다. Sentry에 설정된 Slack 인테그레이션이 이 stack trace를 그대로 #alerts-payment 채널에 전송했습니다. 키 마스킹? Sentry의 데이터 스크러빙 기능이 있지만, 커스텀 환경변수에 대한 필터링은 따로 설정하지 않으면 작동하지 않습니다. 대부분의 조직이 기본값 그대로 사용합니다.
거의 동시에 Datadog의 APM trace가 request header의 Authorization: Bearer eyJhbGciOiJIUzI1NiIs... 토큰을 평문으로 로깅했습니다. Datadog의 anomaly alert가 #monitoring 채널로 전송되면서 이 trace의 직접 링크가 포함되었습니다. 링크를 클릭하면 누구나 평문 토큰을 볼 수 있는 상태.
PagerDuty는 incident context에 환경 정보와 서비스 메타데이터를 포함하여 #incident-critical 채널에 자동으로 포스팅했습니다. 여기에도 내부 서비스 엔드포인트와 인증 정보 일부가 포함되어 있었습니다.
사람은 아직 아무것도 하지 않았습니다. 자동화된 시스템이 3분 만에 Stripe API 키를 Slack 2개 채널로, Bearer 토큰을 Datadog 로그와 Slack 1개 채널로, 서비스 메타데이터를 또 다른 Slack 채널로 흩뿌린 상태였습니다.
인간 확산 --- 장애 대응은 보안의 적이다
박 엔지니어가 #incident-critical 스레드에서 라이브 디버깅을 시작했습니다. "환경변수 확인한다" --- env | grep STRIPE 결과를 스레드에 바로 붙여넣었습니다. Stripe secret key, PostgreSQL connection string(postgres://admin:Pr0d_P@ss2025@db.internal:5432/payments), 내부 마이크로서비스 API 토큰 3개가 한 번에 노출되었습니다.
백엔드 리드 최 엔지니어가 DM으로 "이 키로 직접 Stripe 대시보드에서 확인해봐"라며 live key를 보냈습니다. Slack DM.
장애는 새벽 5시에 해결되었습니다. 월요일 오전, 박 엔지니어가 Jira에 포스트모템 티켓(SEV-1-20251018)을 작성하면서 Slack 스레드 내용을 거의 그대로 복사/붙여넣기했습니다. 크리덴셜이 포함된 채로. 테크 리드 이 매니저가 Confluence 런북 "결제 서비스 긴급 복구 절차"를 업데이트하면서 "긴급 시 이 키로 직접 DB 접속" 가이드를 추가했습니다. connection string 전체가 문서에 평문으로 기록되었습니다.
결과: 하나의 장애 대응이 Slack 채널 3개(#alerts-payment, #monitoring, #incident-critical) + Slack DM 1건 + Jira 티켓 1건 + Confluence 문서 1건 + Sentry 로그 + Datadog 로그 --- 최소 8곳에 프로덕션 크리덴셜을 남겼습니다. 전부 비코드 소스. GitHub에 secret scanning이 돌아가고 있어도 이 중 단 하나도 탐지되지 않았습니다.
6개월 뒤. 외부 감사인이 SOC 2 갱신 감사를 진행하면서 Confluence 접근 권한을 검토했습니다. 런북에 프로덕션 Stripe API key와 DB connection string이 평문으로 적혀 있는 걸 발견했습니다. 추적해보니 같은 키가 Slack 검색, Jira 검색, Datadog 로그 검색으로 조직 내 누구나 찾을 수 있는 상태였습니다. 최초 노출 시점은 6개월 전 장애 대응. 그 사이 두 명의 계약직 개발자가 프로젝트에 참여했다가 떠났고, 외부 컨설턴트 한 명이 Confluence 접근 권한을 가지고 있었습니다.
이 키는 왜 위험한가
Shadow Key. 비코드 소스에 노출된 크리덴셜을 말합니다. 코드 저장소가 아닌 협업 도구, 모니터링 시스템, 프로젝트 관리 도구, 문서 플랫폼에 평문으로 남아 있는 시크릿입니다. 코드에 하드코딩된 키가 "눈에 보이는 위험"이라면, Shadow Key는 "눈에 보이지 않는 곳에 있는 위험"입니다. Git이 아닌 곳, secret scanner가 비추지 않는 곳, 하지만 조직 내 수십~수백 명이 검색 한 번으로 접근할 수 있는 곳.
Shadow Key가 구조적으로 위험한 이유는 세 가지입니다.
첫째, 확산 속도가 폭발적이다. 코드에 하드코딩된 키는 보통 한 파일, 한 저장소에 존재합니다. Shadow Key는 하나의 이벤트로 여러 플랫폼에 동시 확산됩니다. 장애가 터지면 Sentry가 Slack으로, Datadog이 Slack으로, PagerDuty가 Slack으로 자동 전송합니다. 사람이 아직 아무것도 안 했는데 이미 3~4개 채널에 크리덴셜이 퍼져 있습니다. 엔지니어가 장애 대응을 시작하면 Jira, Confluence까지 추가됩니다. 하나의 장애 → 6개 이상의 플랫폼. 이게 Shadow Key의 확산 메커니즘입니다.
둘째, 검색 가능한 상태로 영구 저장된다. Slack, Jira, Confluence, Datadog 모두 전문 검색(full-text search)을 지원합니다. 한 번 기록된 크리덴셜은 검색어 하나로 누구나 찾을 수 있습니다. sk_live를 Slack에서 검색하면? Stripe 프로덕션 키가 나옵니다. postgres://를 Jira에서 검색하면? DB connection string이 나옵니다. 그리고 이 데이터는 사라지지 않습니다. 메시지를 삭제해도 Slack의 Compliance Export에 남고, Jira의 변경 이력에 남고, Datadog의 로그 보관 기간 동안 유지됩니다.
셋째, "이미 보안 도구를 갖추고 있다"는 착각이 방어를 늦춘다. 이것이 Shadow Key의 가장 교활한 특성입니다. CISO는 secret scanning을 도입하고, Vault를 운영하고, SOC 2를 통과했으므로 시크릿 관리에 자신감을 갖습니다. 하지만 그 자신감은 코드 영역에만 해당합니다.
CISO가 하는 말 | 현실
"Git에 시크릿 없어요" | 맞습니다. Git 밖에 있으니까요.
"Vault 쓰고 있어요" | Vault에서 꺼낸 키가 Slack 스레드에 평문으로 남아 있습니다.
"SOC 2 통과했어요" | SOC 2 감사 범위에 Slack 메시지 내 크리덴셜 검사는 포함되지 않습니다.
"분기마다 접근 권한 리뷰해요" | Jira 티켓과 Confluence 문서에 하드코딩된 키는 접근 권한 리뷰 대상이 아닙니다.
"DLP 솔루션 있어요" | 대부분의 DLP는 파일 유출을 감시하지, Slack 메시지 안의 API 키 패턴은 탐지하지 않습니다.
이 테이블의 한 줄 한 줄이 실제 보안 리더들과의 대화에서 나온 것입니다. "도구가 있다"와 "도구가 이 위협을 커버한다"는 완전히 다른 이야기인데, 그 차이를 인식하지 못하는 조직이 대다수입니다.
Kill Chain --- Shadow Key가 조직 전체를 위협하기까지
Shadow Key의 킬체인은 다른 NHI 위협과 출발점이 근본적으로 다릅니다. Ghost Key는 퇴사자의 개인 장비에서, Public Key는 공개 저장소에서 시작됩니다. Shadow Key는 조직의 일상 업무 --- 특히 장애 대응 --- 에서 시작됩니다. 보안 사고가 아니라 정상적인 운영 프로세스가 위험을 만드는 겁니다.
1단계: 비코드 소스로의 크리덴셜 유출 (Credential Leakage to Non-Code Sources)
시작은 모니터링 도구의 자동 알림입니다. Sentry가 에러를 캡처하면서 stack trace에 포함된 환경변수를 함께 기록합니다. Datadog APM이 request/response를 추적하면서 header의 인증 토큰을 평문으로 로깅합니다. 이 데이터가 Slack 인테그레이션을 통해 채널로 자동 전송됩니다. 사람이 개입하지 않아도 시스템이 크리덴셜을 비코드 소스로 옮기는 겁니다. 이것이 Shadow Key의 독특한 점입니다. 실수가 아닙니다. 의도된 자동화가 의도하지 않은 결과를 만드는 것입니다.
2단계: 인간 증폭 (Human Amplification)
장애 대응 과정에서 엔지니어가 크리덴셜의 확산을 가속시킵니다. env | grep 결과를 Slack에 붙여넣고, "이 키로 직접 테스트해봐"라며 DM으로 전송하고, 장애 해결 후 Jira 포스트모템에 Slack 스레드를 복사/붙여넣기하고, Confluence 런북에 "긴급 시 이 키 사용"이라고 문서화합니다. 자동 알림이 만든 1차 확산을 인간이 2차, 3차로 증폭시킵니다. 하나의 장애 이벤트가 N개 플랫폼에 크리덴셜을 남기는 구조입니다.
3단계: 검색 가능한 시스템에 영구 저장 (Persistence in Searchable Systems)
Slack, Jira, Confluence, Datadog은 모두 전문 검색을 지원합니다. 이 시점에서 크리덴셜은 단순히 "어딘가에 남아 있는" 수준이 아니라 "검색어 하나로 누구나 찾을 수 있는" 상태가 됩니다. 그리고 삭제가 어렵습니다. Slack 메시지를 지워도 Compliance Export나 eDiscovery 로그에 남을 수 있습니다. Jira 티켓의 설명을 편집해도 변경 이력에 원본이 남습니다. Confluence 페이지를 수정해도 이전 버전이 보관됩니다. 한 번 기록되면 완전한 삭제가 사실상 불가능한 플랫폼들입니다.
4단계: 접근 범위 확대 (Access Expansion)
내부 직원 중 해당 Slack 워크스페이스, Jira 프로젝트, Confluence 스페이스에 접근할 수 있는 사람이라면 누구나 검색으로 프로덕션 키를 찾을 수 있습니다. 문제는 "내부 직원"의 범위가 생각보다 넓다는 것입니다. 계약직 개발자, 외부 컨설턴트, 파트너사 직원이 Slack 게스트 계정이나 Jira/Confluence 외부 공유를 통해 접근하는 경우가 흔합니다. 퇴사 예정자, 권한이 과다 부여된 계정도 접근 가능합니다. Confluence가 "Anyone with the link" 설정으로 공유되어 있다면 외부 유출까지 한 걸음입니다.
5단계: 악용 (Exploitation)
Shadow Key의 최종 악용 시나리오는 두 가지입니다. 내부자 위협 --- 불만을 품은 직원이나 퇴사 예정자가 Slack 검색으로 프로덕션 키를 찾아 악용. 또는 계정 탈취 --- Slack 계정이 피싱이나 세션 하이재킹으로 탈취되면, 공격자가 Slack 검색 기능을 이용해 sk_live, AKIA, postgres:// 같은 패턴을 검색하여 수분 내에 프로덕션 크리덴셜을 대량으로 획득합니다. 이 모든 과정에서 Git secret scanning, SIEM, CSPM 어디에도 알림이 발생하지 않습니다. 비코드 소스는 이 도구들의 관찰 범위에 포함되지 않으니까요.
왜 기존 보안 체계로는 잡히지 않는가
Shadow Key가 기존 보안 체계의 사각지대에 존재하는 이유를 구체적으로 분석합니다.
Git Secret Scanning의 커버리지 한계
GitHub Advanced Security, GitLeaks, TruffleHog --- 이 도구들은 효과적입니다. Git 저장소 안에서는요. 문제는 Shadow Key가 Git 바깥에 존재한다는 것입니다. 이 도구들은 Slack 메시지, Jira 티켓 본문, Confluence 페이지, Sentry 로그, Datadog trace를 스캔하지 않습니다. 스캔할 수 없습니다. 연동 자체가 없으니까요. "우리는 secret scanning을 도입했다"는 "코드 안의 시크릿은 잡고 있다"와 같은 뜻이지, "모든 시크릿을 잡고 있다"와 같은 뜻이 아닙니다.
GitGuardian의 2024 State of Secrets Sprawl 보고서는 이 문제를 직접 지적합니다. 시크릿 유출의 상당 부분이 코드가 아닌 협업 도구, 로그 시스템, CI/CD 아티팩트에서 발생한다는 것. Git 중심의 스캐닝만으로는 전체 시크릿 확산(secrets sprawl)의 일부만 커버할 수 있습니다.
DLP의 맹점
전통적인 DLP(Data Loss Prevention) 솔루션은 파일 유출과 이메일 첨부 파일 감시에 최적화되어 있습니다. "직원이 고객 DB를 USB에 복사하려 한다" --- 이건 잡습니다. 하지만 "엔지니어가 Slack 메시지에 AKIA2OGYBAH6QDFGT7LS를 붙여넣었다" --- 이건 대부분의 DLP가 탐지하지 못합니다. Slack 메시지의 텍스트 패턴을 실시간으로 분석하는 DLP는 극히 드뭅니다. API 키, connection string, Bearer 토큰 같은 시크릿 패턴을 DLP 규칙에 정의해놓은 조직은 더 드뭅니다.
SOC 2 / ISO 27001 감사 범위의 사각지대
SOC 2 감사는 접근 통제, 변경 관리, 모니터링 정책을 검토합니다. "시크릿은 Vault에 저장하고 있습니까?" --- 예. "코드 저장소에 secret scanning을 적용하고 있습니까?" --- 예. 감사 통과. 하지만 "Slack 메시지에 프로덕션 크리덴셜이 평문으로 남아 있지 않습니까?"는 대부분의 감사 체크리스트에 포함되지 않습니다. SOC 2를 통과했다는 것은 정의된 통제가 작동한다는 뜻이지, 모든 위협이 커버된다는 뜻이 아닙니다.
모니터링 도구의 기본 설정 문제
Sentry와 Datadog 모두 시크릿 마스킹 기능을 제공합니다. Sentry의 "Data Scrubbing"과 "Security & PII" 필터, Datadog의 "Sensitive Data Scanner." 문제는 이 기능들이 기본적으로 최소한의 패턴만 커버하고, 커스텀 환경변수나 조직 고유의 시크릿 패턴은 수동으로 추가해야 한다는 것입니다. "기본 설정으로 충분하겠지"라고 판단한 조직에서 Stripe key가 stack trace에 평문으로 찍히고, Bearer 토큰이 APM trace에 기록되는 일이 반복됩니다.
실제 침해 사례와 업계 데이터
Shadow Key는 이론적 위험이 아닙니다. 지난 수 년간 발생한 주요 보안 사고들의 공격 체인에 반복적으로 등장하는 패턴입니다.
Uber 2022 --- Slack에서 시작된 전면 침해
2022년 9월, 18세 해커가 Uber 직원의 MFA 인증을 소셜 엔지니어링으로 우회한 뒤 내부 Slack에 접근했습니다. 공격자가 Slack에서 발견한 것은 내부 시스템 크리덴셜이었습니다. PowerShell 스크립트에 포함된 관리자 패스워드가 내부 네트워크 공유와 Slack 메시지에 남아 있었고, 이를 이용해 AWS, Google Workspace, Slack 관리자 콘솔, HackerOne 버그 바운티 플랫폼까지 접근했습니다. Uber는 코드 저장소의 보안은 갖추고 있었습니다. 하지만 Slack에 남아 있는 크리덴셜 --- Shadow Key --- 이 전면 침해의 고리를 이어준 겁니다.
Rockstar Games 2022 --- Slack 워크스페이스 침해
같은 해커 그룹(Lapsus$)이 Rockstar Games의 Slack 워크스페이스에 침투했습니다. Slack을 통해 GTA VI의 개발 빌드 영상과 소스 코드에 접근했습니다. Slack 워크스페이스는 단순한 메신저가 아닙니다. 파일 공유, 코드 스니펫, 인테그레이션 연동, 자동화된 알림이 모이는 곳이고, 그 과정에서 크리덴셜이 평문으로 남는 경우가 빈번합니다. 공격자가 Slack에 들어오면 검색 기능이 무기가 됩니다.
EA 2021 --- Slack 토큰 하나로 내부 침투
2021년 Electronic Arts 침해 사건에서 공격자는 다크웹에서 구매한 Slack 세션 쿠키를 사용해 EA의 내부 Slack에 접근했습니다. Slack 내에서 IT 지원팀에 접근하여 내부 네트워크 접근 권한을 확보했고, 최종적으로 FIFA 21 소스 코드와 Frostbite 엔진 코드를 유출했습니다. $10짜리 Slack 쿠키 하나가 780GB 데이터 유출의 시작점이었습니다.
업계 데이터가 말하는 것
OWASP NHI Top 10은 시크릿 노출(Secret Exposure)을 주요 위험 항목으로 선정하면서, 코드 밖 소스에서의 유출을 명시적으로 경고합니다. CSA의 2026 State of NHI Security 보고서에 따르면, 비코드 소스에서의 시크릿 노출을 체계적으로 모니터링하는 조직은 전체의 15% 미만입니다. 나머지 85%는 Slack, Jira, Confluence에 크리덴셜이 남아 있어도 알 방법이 없습니다.
GitGuardian의 2024 State of Secrets Sprawl 보고서는 시크릿 확산이 코드 저장소를 넘어 협업 도구, CI/CD 아티팩트, 로그 시스템으로 확대되고 있음을 보여줍니다. Git에서 발견되는 시크릿은 전체 시크릿 확산의 일부일 뿐이며, 비코드 소스의 시크릿은 탐지율이 현저히 낮습니다.
이 데이터들이 가리키는 결론은 하나입니다. 코드만 스캔해서는 시크릿 보안이 완성되지 않습니다. Shadow Key가 숨어 있는 비코드 소스를 함께 커버하지 않으면, 보안 도구가 있어도 눈 가리고 아웅입니다.
탐지 및 대응 가이드
Shadow Key 방어는 "도구 도입"이 아니라 "커버리지 확장"의 문제입니다. 이미 도입한 보안 도구들의 관찰 범위를 비코드 소스까지 넓히는 것이 핵심입니다.
비코드 소스 시크릿 스캐닝 도입
Git 저장소만 스캔하는 것으로는 부족합니다. Slack 워크스페이스, Jira 프로젝트, Confluence 스페이스, 로그 시스템(Sentry, Datadog, ELK 등)까지 포함하는 전방위 시크릿 스캐닝이 필요합니다. 스캔 대상은 메시지 본문, 티켓 설명, 문서 내용, 첨부 파일, 로그 엔트리를 모두 포함해야 합니다. 스캔 빈도는 최소 일 단위, 이상적으로는 실시간(API 기반 이벤트 스트리밍)이어야 합니다. 시크릿 탐지 시 자동 알림과 함께 해당 크리덴셜의 즉시 로테이션 프로세스를 트리거해야 합니다.
모니터링 도구의 시크릿 마스킹 강화
Sentry의 Data Scrubbing 설정에서 커스텀 패턴을 추가하세요. sk_live_*, sk_test_*, AKIA*, postgres://, mysql://, mongodb://, Bearer ey* 같은 패턴을 "Additional Sensitive Fields"에 등록합니다. Datadog의 Sensitive Data Scanner에서 조직이 사용하는 모든 시크릿 패턴에 대한 스캐닝 규칙을 생성합니다. PagerDuty의 incident context에 환경변수가 포함되지 않도록 알림 템플릿을 검토합니다. 이 설정들은 한 번 해놓으면 자동으로 작동하지만, "한 번 해놓는" 조직이 드문 게 문제입니다.
Slack/Jira/Confluence 보관 정책 및 접근 통제
Slack Enterprise Grid의 DLP 기능이나 서드파티 Slack DLP 도구를 도입하여 메시지에 시크릿 패턴이 포함되었을 때 자동 경고 또는 메시지 차단을 설정합니다. Jira와 Confluence의 접근 권한을 정기적으로 리뷰하고, 외부 게스트 계정의 접근 범위를 최소화합니다. Confluence의 공개 공유 설정("Anyone with the link")을 감사하고, 민감한 정보가 포함된 스페이스는 비공개로 전환합니다. 시크릿이 포함된 것으로 확인된 메시지/티켓/문서는 즉시 수정하되, 변경 이력에 남은 원본 데이터도 함께 처리해야 합니다.
장애 대응 시크릿 위생 프로토콜
장애 대응 런북에 "시크릿 위생" 섹션을 추가합니다. 구체적으로: (1) 환경변수 덤프(env | grep)를 Slack에 직접 붙여넣지 않는다 --- 대신 시크릿이 마스킹된 형태로 공유하거나, 별도의 보안 채널(예: Vault의 일회성 시크릿 공유 기능)을 사용합니다. (2) 크리덴셜을 DM으로 전송하지 않는다 --- Vault, 1Password, 또는 조직의 시크릿 관리 도구를 통해 공유합니다. (3) 포스트모템 작성 시 크리덴셜을 마스킹합니다 --- sk_live_****, postgres://****:****@**** 형태로. (4) 장애 대응 완료 후 24시간 이내에 보안팀이 해당 인시던트 스레드/티켓을 리뷰하여 노출된 시크릿을 식별하고 로테이션합니다.
Shadow Key 발견 시 대응 절차
Shadow Key가 발견되면 해당 크리덴셜이 이미 노출된 것으로 간주하고 대응합니다. 즉시 로테이션합니다. 해당 키가 다른 플랫폼에도 존재하는지 확인합니다 --- Slack에서 발견되었다면 Jira, Confluence, Sentry, Datadog에도 같은 키가 남아 있을 가능성이 높습니다. 해당 키의 접근 로그를 감사하여 비정상 사용 여부를 확인합니다. 해당 키에 접근할 수 있었던 사람의 범위를 파악합니다 --- 내부 직원뿐만 아니라 외부 게스트, 계약직, 퇴사자도 포함합니다. 시크릿 관리에 대한 더 상세한 구현 가이드는 Git Secret Scanning 완벽 구현 가이드를 참고하세요.
Cremit Argus는 Shadow Key를 어떻게 탐지하는가
Shadow Key가 기존 보안 도구의 사각지대에 존재하는 근본적인 이유는 관찰 범위의 한계입니다. Git secret scanning은 Git만 봅니다. DLP는 파일 유출만 봅니다. 둘 다 Slack 메시지, Jira 티켓, Confluence 문서 안의 크리덴셜은 보지 않습니다. Cremit Argus는 이 사각지대를 정면으로 겨냥합니다.
Argus는 코드 저장소뿐만 아니라 Slack 워크스페이스, Jira 프로젝트, Confluence 스페이스, 로그 시스템까지 포함하는 전방위 시크릿 스캐닝을 수행합니다. 메시지 본문, 티켓 설명, 문서 내용, 스레드 답글, 첨부 파일 안의 시크릿 패턴을 탐지합니다. Git에서 시크릿을 잡는 것과 동일한 정밀도로 비코드 소스의 시크릿을 잡습니다.
Argus는 Shadow Key의 확산 경로를 추적합니다. 하나의 크리덴셜이 여러 플랫폼에 동시에 존재하는 경우 --- Slack 채널 + Jira 티켓 + Confluence 문서 --- 를 자동으로 연결하여 전체 확산 범위를 시각화합니다. 하나를 발견하면 나머지 전부를 찾아주는 것. 수동으로 각 플랫폼을 하나씩 검색하는 것과는 차원이 다른 대응 속도를 제공합니다.
Argus는 실시간 모니터링을 지원합니다. Slack 메시지가 전송되는 순간, Jira 티켓이 생성되는 순간 시크릿 패턴을 탐지하고 즉시 알림을 보냅니다. 장애 대응 중 엔지니어가 env dump를 Slack에 붙여넣으면, 그 메시지가 전송된 직후 보안팀에 알림이 갑니다. "6개월 뒤 감사에서 발견"이 아니라 "6초 뒤 알림"입니다.
Cremit Argus가 비코드 소스의 Shadow Key를 어떻게 탐지하는지 직접 확인하세요.
NHI Kill Chain 시리즈 안내
이 글은 NHI Kill Chain 시리즈의 두 번째 글입니다. 이 시리즈는 조직 내부에 숨어 있는 가장 위험한 NHI 크리덴셜 8가지 유형을 분석하고, 각각의 킬체인과 대응 전략을 제시합니다. 하나의 크리덴셜 관리 실패가 어떻게 다른 위험 유형으로 연쇄되는지 --- 비코드 소스에 노출된 키가 로테이션되지 않으면 Aged Key가 되고, 퇴사자의 키가 폐기되지 않으면 Ghost Key가 되는 --- 를 이해하는 것이 이 시리즈의 핵심입니다.
- CRE-001 Ghost Key --- 퇴사한 개발자의 AWS 키는 아직 출근 중이다 (발행 완료)
- CRE-002 Shadow Key --- 시크릿 스캐너는 코드를 본다. Slack은 보지 않는다. (현재 글)
- CRE-003 Aged Key --- 3년째 프로덕션을 지탱하는 마스터 키 (예정)
- CRE-004 Over-shared Key --- 10명이 하나의 Slack 봇 토큰을 공유하면 생기는 일 (예정)
- CRE-005 Zombie Key --- 코드에서 지웠다고 죽은 게 아니다 (예정)
- CRE-006 Drifted Key --- CI/CD 봇이 DB 비밀번호를 Jira에 자동 첨부할 때 (예정)
- CRE-007 Public Key --- .env가 GitHub에 올라간 뒤 4분간 벌어지는 일 (발행 완료)
- CRE-008 Unattributed Key --- 주인 없는 키, 아무도 책임지지 않는 권한 (예정)
시리즈 종합 요약 --- 8가지 CRE 유형의 상관관계와 통합 방어 전략 (시리즈 완료 후 발행)
이전 글: NHI Kill Chain: Ghost Key --- 퇴사한 개발자의 AWS 키는 아직 출근 중이다
다음 글: NHI Kill Chain: Aged Key --- 3년째 프로덕션을 지탱하는 마스터 키
Cremit은 NHI 보안 전문 기업입니다. cremit.io에서 더 알아보세요.