유출된 API 키: 노출·사용·거래 증거 구분법

API 키가 공개됐다는 사실만으로 누군가 그 키를 샀거나 사용했다고 말할 수는 없습니다. 이 글의 이전 버전은 서로 다른 수준의 주장을 섞었고, 직접 만든 제목 카드에 거래 화면이라는 설명을 붙였습니다. 해당 이미지를 빼고 2026년 10월 4일에 본문을 다시 썼습니다.

증거를 네 단계로 나눠 보기

노출: 공개 저장소, 배포된 JavaScript, 로그 등에서 키가 보였다면 위치와 최초 확인 시각, 담당자, 키 종류를 기록합니다. 조사에 필요한 최소한의 정보만 남기고 키 원문을 티켓이나 화면 캡처에 옮기지 않습니다.

유효성: 발급 기관이 지원하는 방법으로 키의 현재 상태를 확인할 수 있습니다. GitHub의 secret scanning도 키 종류에 따라 유효성 검사를 지원하며, 일반 패턴은 지원하지 않습니다. 유효하다는 결과가 제3자의 열람이나 사용을 증명하지는 않습니다.

권한과 사용: 발급 기관에서 키의 권한을 확인하고 감사 로그와 사용량을 살핍니다. AWS CloudTrail은 최근 관리 이벤트를 액세스 키 ID로 검색할 수 있습니다. 기본 이벤트 기록에는 데이터 이벤트가 들어 있지 않습니다. 조회 결과가 없더라도 기록 범위, 보존 기간, 리전, 서비스별 로그를 먼저 확인해야 합니다.

거래: 판매 게시물이나 거래 기록이 있다면 출처를 검증하고 해당 키와 연결되는 근거를 따로 확보해야 합니다. 공개 노출, 유효한 키, 수상한 API 호출만으로 판매 사실은 입증되지 않습니다. 이전 글에 등장한 키가 실제 거래됐다는 증거는 현재 제시할 수 없습니다.

키가 노출됐을 때의 순서

1. 발급 기관과 담당자를 찾고 조사 기록의 접근을 제한합니다. 조사 범위를 확인하는 동안 사용 가능한 키는 침해 가능성을 전제로 다룹니다.

2. 발급 기관에서 키를 폐기하거나 교체하고, 연결된 서비스의 설정과 오류를 확인합니다. 저장소 커밋에서 문자열을 지우는 것만으로 노출이 사라지지 않습니다. GitHub도 폐기 또는 교체를 먼저 권합니다.

3. 저장소, 빌드 결과물, 배포 파일, 로그 등 승인된 범위에서 복사본을 찾습니다. 노출 기간의 권한과 활동을 검토하고, 확인한 사실과 추정, 미확인 사항을 사건 기록에 구분해 적습니다.

4. 새 키에는 필요한 애플리케이션과 API에 맞는 제한을 둡니다. Google Cloud API 키는 지원되는 경우 애플리케이션·API 제한을 설정하고 정기적으로 관리합니다.

Cremit으로 확인할 수 있는 범위

Cremit은 지원하는 소스와 승인된 외부 자산에서 노출된 자격증명을 찾고, 지원되는 종류의 상태를 확인하며, 담당자에게 조사를 연결합니다. AWS 액세스 키와 Google Cloud API 키의 접근 분석은 우선순위를 정하는 데 도움이 됩니다. 다크웹 거래를 감시하거나 판매를 입증하거나 키를 자동으로 교체하지는 않습니다. 실제 사용 여부는 발급 기관의 기록과 사건 증거로 확인해야 합니다.