Leak 을 inevitable 로 취급. 흥미로운 질문은 incident response 가 어떻게 생겼느냐 — 있을지 없을지가 아니라.
응답 트리
| Leak 한 거 | 첫 액션 | 왜 지금 |
|---|---|---|
| API 키 (OpenAI, Anthropic 등) | provider 대시보드에서 즉시 회전 | 비용 0; exploit 되면 청구서 누적 |
| GitHub PAT | GitHub 설정에서 revoke | repo write 접근 = 공급망 침해 |
| DB 비밀번호 | 회전, 그다음 access 로그 체크 | 데이터 유출 윈도우가 leak 한 순간 시작 |
| SSH 키 | 모든 서버 authorized_keys 에서 제거, 새 키 생성 | 제거 전까지 지속 접근 |
| 앱 PIN / session 토큰 (이 퀘스트) | Track 7 에서 Revoke All 클릭 | session 즉시 죽음 |
| OAuth client secret | OAuth provider 에서 회전 | 모든 앱 인스턴스 영향 |
회전 후 세 lookup
- Provider audit 로그. OpenAI/Anthropic/등이 키별 사용량 보여줘. leak 시간과 회전 시간 사이 unusual 한 거?
- 애플리케이션 로그. 이제 죽은 키/토큰으로 예상 못 한 요청?
- Billing. 사용 spike = 다른 사람이 네 키 씀. 청구서 보통 하루 lag; 내일도 체크.
할 수 없는 것
LLM provider 의 로그, 훈련 파이프라인, 제3자 캐시에서 시크릿 scrub 못 함. 시크릿이 원격 서버로 보내진 순간 네가 컨트롤 못 하는 보존 기간 동안 N 카피로 존재. 회전이 작동하는 유일한 응답. 사과는 X.
Post-mortem 질문
"이 leak 이 처음부터 보내지지 않게 뭐가 막았을까?" 거의 항상 답은 "시크릿이 agent 가 읽을 수 있는 파일에 있으면 안 됐어." 그걸 영구 변화로 번역: keychain 마이그레이션, ignore 파일 업데이트, 넓은 거 대신 scoped 토큰.