본문으로 건너뛰기
NEW · Blast Radius: 유출된 API 키 대응 플레이북 (AWS·GCP·Azure)

크리밋 리서치 · 사고 대응 시리즈

Blast Radius

유출된 API 키와 클라우드 크리덴셜을 조사하는 실무 플레이북입니다. AWS, GCP, Azure와 그 배후의 시크릿 저장소를 대상으로 해당 키가 어디까지 접근할 수 있었는지를 증거로 입증하는 절차를 다룹니다.

유출된 키의 영향 범위란?

그 키의 현재 권한으로 접근하거나 수행할 수 있는 리소스와 작업의 범위입니다. 접근 가능성과 실제 사용은 다릅니다. 발급처에서 주체와 권한을 확인한 뒤, 남아 있는 활동 로그로 사용 여부를 조사해야 합니다.

34페이지 · PDF · 한국어판/영문판 · 발행 2026-09-04 · 웹 실습 추가 2026-10-07

01
키 1개
02
주체 1개
03
해당 주체가 수행 가능한 모든 역할
04
해당 역할의 권한이 미치는 전체 범위(영향 범위)

대상사고 대응 담당자, DevSecOps, 플랫폼 및 클라우드 보안팀

팀 실습 · 외부 요청 없이 진행

이 키의 조사를 끝내도 될까요?

아래는 모두 가상의 기록입니다. 실제 키를 입력하거나 발급처에 요청할 필요가 없습니다. 각 기록에서 확인한 사실과 아직 모르는 것을 나눠 적어 보세요.

09:00 UTC · 발견
example-app/config/example.env 12행에서 마스킹된 AWS 키를 발견했습니다. 최초 커밋 시각과 공개 범위는 아직 조사하지 않았습니다.
09:10 UTC · 검증
발급처 인증 검증에 성공했습니다. 작성자는 확인했지만 키 소유 팀과 의존 서비스는 미확인입니다.
09:30 UTC · 담당자
키 소유 팀이 담당자를 지정하고 의존 서비스를 확인했습니다. 현재 권한 목록은 확보했지만 과거 권한 변경 이력은 없습니다.
10:00 UTC · 폐기와 재확인
발급처에서 키를 폐기했고 재검증에서 인증 실패를 확인했습니다. 해당 기간의 데이터 접근 로그는 확보하지 못했습니다.
  1. 발견 시각을 노출 시작 시각으로 써도 될까요?
  2. 검증 성공으로 실제 악용 여부까지 알 수 있나요?
  3. 키가 폐기됐다면 접근 범위와 실제 사용 조사를 끝내도 될까요?
판단 예시 확인
  • 발견은 관측 시각입니다. 커밋·배포·공유 기록으로 노출 시작의 상한과 하한을 좁히고, 모르는 구간을 남겨야 합니다.
  • 검증은 그 시점에 인증할 수 있었다는 증거입니다. 악용 여부는 아닙니다. 작성자, 확정 담당자, 발급처의 주체도 구분해 기록합니다.
  • 폐기와 재검증은 현재 키의 인증 차단을 뒷받침합니다. 과거 사용 여부나 이미 발급된 세션의 종료까지 증명하지는 않습니다. 발급처별 세션·토큰 정책과 남은 로그를 확인합니다.
  • 이 사례의 결론은 “키는 폐기·재확인됨, 과거 데이터 접근은 증거 부족으로 판단 불가”입니다. 현재 권한으로 추정한 접근 가능 범위를 과거의 실제 피해 범위로 보고하지 않습니다.
조사 기록 양식 다운로드 (.md)

원문 키 대신 마스킹된 식별자와 증거 위치를 기록하세요. 양식은 로컬에서 편집할 수 있으며 업로드가 필요하지 않습니다.

플레이북 11–12쪽(검증·노출), 25–26쪽(시크릿과 교체 순서), 28–31쪽(증거 수집·종료 확인)을 바탕으로 작성한 웹 실습입니다. 실습은 PDF 본문에 포함되어 있지 않습니다.

같은 대응 흐름을 제품 화면으로 보기

여기부터 · 2페이지

유출 직후 첫 5분 대응 조치

API 키가 유출됐다면 여기부터 시작하세요. 나머지 내용은 사고 대응 중과 사후에 참조할 자료입니다. 처음 5분에는 다음 세 가지 조치를 시작합니다.

01

노출 기록을 남기고 신속히 차단

노출 위치와 발견 시각(UTC)을 기록합니다. 가능한 로그를 확보하되 키 비활성화나 교체를 조사 완료 때까지 미루지 마세요. 이미 보관된 제공업체 로그는 키를 차단해도 사라지지 않습니다.

02

문자열에서 확인할 수 있는 범위 구분

접두사로 발급처와 유형을 알 수 있는 경우가 있습니다. 일부 구조화된 자격증명은 계정 정보도 담지만, 소유자·유효성·권한은 대개 발급처 기록을 확인해야 합니다.

03

공개 노출은 긴급하게 처리

허니팟 연구에서는 공개된 일부 AWS 키가 수분 안에 사용됐습니다. 모든 키에 같은 시간이 적용되지는 않습니다. 사용 흔적이 보이지 않아도 안전하다는 뜻은 아니므로 관련 로그의 수집 여부를 확인하세요.

인지 시점 기준 신고 기한

대부분의 규제는 인지 시점부터 정해진 시간 내 신고를 의무화합니다. 정보통신망법상 침해사고 신고는 24시간, 개인정보 보호법상 유출 신고는 72시간, EU NIS2 최초 신고는 24시간 이내입니다.

플레이북 6단계

각 장은 개별 단계에 대응하며 현재 단계는 페이지 상단에 표시됩니다.

  1. 01
    식별
    크리덴셜 유형 및 소유자 파악
  2. 02
    노출 범위
    유출 경로 및 노출 기간 확인
  3. 03
    영향 범위
    크리덴셜 도달 범위 및 수행 가능 역할 전수 분석
  4. 04
    사용 조사
    사용 주체 및 행위 이력 조사
  5. 05
    차단 및 로테이션
    장애 없는 안전한 폐기 절차
  6. 06
    사고 종료
    완전한 종료 상태 객관적 증명

벤더 자료 인용이 아닌 자체 분석

인용이 아니라 직접 계산한 세 페이지

16페이지

AWS 격리 정책의 범위와 한계

AWS는 공개 영역에서 자사 키를 발견하면 AWSCompromisedKeyQuarantineV3을 적용합니다. 명시된 목적은 무단 과금으로 이어지는 사기성 활동의 피해 제한입니다. 2020년 이후 세 버전을 비교한 결과 거부 액션은 28개에서 99개로 늘었고 제거된 액션은 없습니다. S3 읽기를 제외하면 확인된 데이터 접근 액션 21개 중 어느 버전에서도 거부된 항목이 없습니다. sts:AssumeRole과 secretsmanager:GetSecretValue는 여전히 허용됩니다.

4페이지

탐지를 전제해야 하는 이유

탐지가 비율 λ로 무작위 발생한다고 가정하면 구간 W 내 최소 1회 탐지될 확률은 1 − e^(−λW)입니다. 10⁴배 범위에 걸친 4가지 비율은 초기 1시간 동안 격차가 크지만 1개월이 경과하면 완전히 수렴합니다. Toyota 5년, Microsoft AI 3년, Mercedes-Benz 3.5개월, xAI 2개월 노출은 모두 λ와 무관하게 유출이 확정되는 영역에 위치합니다.

17, 25, 33페이지

“시크릿 조회 여부”의 기본 답변, 확인 불가

GCP는 감사 로깅을 기본값이 상반된 두 종류로 구분합니다. Admin Activity는 항상 활성화되어 있으며 무료이고 400일 보관됩니다. Data Access는 비활성화 상태이며 과금 대상이고 30일 보관됩니다. 시크릿 조회는 DATA_READ에 해당합니다. GCP Data Access 로깅 활성화 여부, Key Vault 진단 설정 여부, CloudTrail 데이터 이벤트 기록 여부는 사고 발생 전에 내려야 하는 설정 결정입니다. 어떤 도구도 증거를 소급 생성하지 못합니다.

목차

본문의 모든 사실 기재는 부록 C(32페이지)에 1차 출처와 함께 수록되어 있습니다. 영문판과 한국어판은 내용이 동일하며 국내 규제 항목만 추가되었습니다.

  1. 03시간: 악용 속도와 규제 기한
  2. 04유출 탐지를 전제해야 하는 이유
  3. 05본 플레이북의 근거가 된 침해사고 15건
  4. 06유출 크리덴셜 대응 6대 원칙
  5. 07클라우드 비교: 동일한 질문, 세 가지 답
  6. 08초기 대응 의사결정 트리 전체
  7. 09키 식별표: 크리덴셜 오프라인 분석
  8. 10오프라인 포렌식: 문자열 기반 파악 항목
  9. 11소유 계정, 유효성 검증, 노출 기간
  10. 12노출 포렌식: Git, 이미지, CI
  11. 13–16AWS: 증거 확보, 영향 범위, 위협 헌팅, 차단
  12. 17–19GCP: 로깅 공백, 계정 사칭, 60분 지연 문제
  13. 20–22Azure: 서비스 주체 로그, RBAC와 Graph, SAS 문제
  14. 23실제 침해 체인: GitHub에서 데이터 유출까지
  15. 24시크릿 확산: 정리 작업이 대응보다 커지는 이유
  16. 25–26시크릿 저장소: 2차 영향 범위, 로테이션 순서
  17. 27SaaS 키: 벤더 제공 기능과 한계
  18. 28–29부록 A: 증거 확보 및 수집 런북
  19. 30부록 B: 클라우드별 필드 레퍼런스
  20. 31사고 종료 및 경영진 보고
  21. 32부록 C: 본문 기재 내용의 1차 출처
  22. 33플레이북에서 관리 체계로

월간 NHI 리서치 브리프

보안 엔지니어와 CISO가 읽는 월간 브리프입니다. NHI 공격 사례, 통제 방법, 현장 리서치를 담습니다.

이메일을 판매하거나 외부에 넘기지 않으며, 언제든 수신거부할 수 있습니다.

플레이북에서 관리 체계로

플랫폼이 맡는 것과 조직이 맡는 것

본 문서에 수록된 사고는 거의 전부 인지 부족이 아닌 유지 관리 실패에서 발생했습니다. 앞의 32페이지 중 벤더가 필요한 대목은 없습니다. 도구 도입에 앞서 자산 인벤토리, 담당자 지정, 클라우드별 차단 절차, 로테이션 현황표 관리가 선행되어야 합니다. 크리밋 플랫폼은 그 네 가지 중 자동화할 수 있는 부분을 담당합니다.

33페이지에 단계별로 플랫폼 담당 영역과 조직 잔존 영역을 구분해 정리했습니다.

사내 배포 안내

사내 런북과 교육 자료로 수정 없이 활용할 수 있습니다. 표와 그림을 발췌할 때는 출처를 명기합니다. 수정하여 사용할 계획이면 연락 시 편집 가능한 원본을 제공합니다. ben@cremit.io