AI API 키 유출 후 30분 대응 체크리스트: 삭제보다 먼저 할 일

핵심 요약

• API 키 유출 대응은 “삭제”보다 “권한 차단과 재발급” 순서가 먼저.
• 30분 안에는 노출 위치 확인, 키 폐기, 새 키 발급, 로그 점검, 비용 한도 확인까지 묶어 보기.
• 같은 사고가 반복된다면 GitHub Secret Scanning, push protection, 로그 마스킹, 키 분리 정책을 바로 적용할 상황.

0~5분: 노출된 키를 더 이상 쓰지 못하게 막기

키가 보인 위치를 찾느라 시간을 모두 쓰면 실제 호출은 계속 열려 있을 수 있어요. 첫 5분에는 “어디에 노출됐는지”와 “어떤 키인지”만 빠르게 확인하고, 제공자 콘솔에서 폐기 또는 비활성화부터 처리하는 편이 안전합니다.

아래 표는 사고 티켓에 남길 최소 기록입니다. 키 원문은 적지 말고, 위치와 조치 시각만 남기세요.

5~15분: 새 키를 넣되, 같은 실수를 반복하지 않게 배치하기

새 키를 만들 때 기존과 같은 이름으로 아무 데나 붙여 넣으면 같은 사고가 다시 납니다. 로컬 개발, 서버 배포, 크론, 워커가 모두 같은 키를 쓰고 있었다면 사고 범위도 넓어집니다. 최소한 운영 키와 개발 키를 나누고, 운영 키는 서버 환경변수나 비밀 저장소에서만 읽게 묶어두세요.

• 로컬 .env는 gitignore 상태까지 확인.
• CI/CD에는 repository secret이나 environment secret으로 입력.
• 로그에는 키 원문 대신 앞뒤 일부만 마스킹한 식별자만 남기기.
• 가능하면 프로젝트별, 환경별, 권한별로 키를 분리.

15~30분: 이미 악용됐는지 확인하기

키를 바꿨다고 대응이 끝난 것은 아닙니다. 노출된 시각 이후 호출량, 실패 로그, 비용 증가, 비정상 IP, 평소와 다른 모델·엔드포인트 사용 흔적까지 이어서 봐야 악용 여부가 보입니다.

재발 방지 체크리스트

응급 조치가 끝났다면 같은 경로로 다시 새지 않게 저장소, 로그, 비용 알림을 바로 점검합니다. 아래 항목은 사고 당일에 최소한으로 확인할 재발 방지 목록입니다.

1. GitHub Secret Scanning과 push protection 켜기.
2. 로그 마스킹 규칙에 sk-, api_key, Authorization 패턴 추가.
3. 키 발급·폐기 담당자와 기준 기록.
4. 월 비용 한도와 알림 설정.
5. 사용하지 않는 키 정기 폐기.

실전 예시: GitHub에 키가 올라간 걸 발견했다면

가장 위험한 선택은 커밋만 지우고 끝내는 방식입니다. 공개 저장소에 키가 노출됐다면 누가 복사했는지 알 수 없으므로 키 폐기, 새 키 발급, 사용량 확인, 로그 점검, 재노출 방지 순서로 처리해야 합니다.

• 즉시: 해당 API 키를 비활성화하거나 삭제하고 새 키 발급.
• 10분 안: 결제·사용량 대시보드에서 비정상 호출 여부 확인.
• 30분 안: 저장소 Secret Scanning, 환경변수 분리, 로그 마스킹 규칙까지 점검.

자주 묻는 질문

커밋에서 키를 지우면 안전한가요?

키 원문을 지워도 커밋 기록, 포크, 캐시, 알림에는 흔적이 남았다고 봐야 합니다. 삭제는 필요하지만, 먼저 해당 키를 폐기하고 새 키를 발급한 뒤 기록 정리를 이어가는 순서가 안전합니다.

노출됐지만 호출량이 늘지 않았다면 그냥 써도 되나요?

권장하지 않습니다. 노출 여부를 확인한 순간부터 그 키는 신뢰할 수 없는 키로 보고 교체하는 것이 안전합니다.

API 키 유출 대응 자주 묻는 질문

GitHub Secret Scanning을 켜면 유출 대응이 끝나나요?

끝나지 않습니다. Secret Scanning과 push protection은 노출 가능성을 빨리 발견하고 커밋 단계에서 막는 장치예요. 이미 노출된 키라면 서비스 콘솔에서 폐기·재발급하고, 로그와 비용 한도를 확인한 뒤 저장소 규칙과 환경변수 관리까지 같이 손보는 쪽이 안전합니다.

새 키를 만들 때 가장 먼저 나눌 기준은 무엇인가요?

운영, 개발, 테스트 환경을 먼저 분리하고 필요한 권한만 부여하는 게 좋습니다. 같은 키를 로컬, 서버, 자동 처리 도구에 함께 쓰면 사고 범위가 커집니다. 새 키 적용 뒤에는 예전 키가 실제로 호출되지 않는지 로그로 확인하는 단계까지 남겨두세요.

키를 교체한 뒤에도 저장소 기록을 지워야 하나요?

네, 공개 저장소라면 기록 정리와 접근 범위 점검을 함께 해야 합니다. 다만 기록 삭제만으로는 이미 복사된 키를 회수할 수 없으므로, 먼저 키를 폐기하고 새 키를 배포한 뒤 Secret Scanning 결과, 배포 로그, 비용 한도, 팀 공유 문서를 순서대로 확인하면 됩니다.