- API 키가 GitHub에 노출됐을 때 30분 대응 순서
- 0~5분: 노출된 키를 즉시 폐기하기
- 서비스 관리 화면에 접근할 수 없다면
조회 1 · 전체 글
대표 이미지: Grigent Guide가 이 글의 주제에 맞춰 AI로 제작한 편집 일러스트입니다. 실제 상품·행사·기관의 촬영 사진은 아닙니다.
API 키가 GitHub에 노출됐을 때 30분 대응 순서
API 키, 클라우드 자격 증명, 데이터베이스 비밀번호가 GitHub 저장소에 올라갔다면 커밋을 지우는 것부터 시작하면 안 됩니다. 이미 복제되었을 가능성을 전제로 키를 먼저 폐기하고, 피해 여부를 확인한 뒤, 이력과 배포물을 정리해야 합니다. 공개 저장소가 아니더라도 같은 원칙을 적용하는 편이 안전합니다. 협업자 계정이나 자동화 도구가 침해되면 비공개 저장소의 비밀정보도 노출될 수 있기 때문입니다.
GitHub는 노출된 비밀정보가 예기치 않은 클라우드 비용, 데이터 접근, 공급망 공격으로 이어질 수 있다고 설명하며, 노출 사실을 발견하면 자격 증명을 가능한 빨리 폐기하거나 교체하라고 안내합니다. 다음 순서는 당황한 상황에서도 중요한 일을 먼저 처리하도록 만든 30분 대응표입니다.
0~5분: 노출된 키를 즉시 폐기하기
가장 먼저 해당 서비스의 관리 화면에 접속해 키를 비활성화하거나 삭제합니다. 새 키를 발급하는 것만으로는 이전 키가 막히지 않을 수 있습니다. 반드시 기존 키가 더 이상 인증에 사용되지 않는 상태인지 확인합니다.
다음 정보를 간단히 기록합니다.
- 노출된 키의 종류와 소유 서비스
- 발견한 시간과 발견한 사람
- 키가 포함된 저장소, 브랜치, 파일, 커밋
- 저장소가 공개였는지 비공개였는지
- 키에 부여된 권한과 접근 가능한 자원
- 키가 사용된 서버, 배포 환경, 자동화 작업
키를 채팅이나 이슈에 그대로 복사해 공유하지 않습니다. 식별이 필요하면 앞뒤 몇 글자만 남긴 마스킹된 값이나 서비스에서 제공하는 키 ID를 사용합니다.
서비스 관리 화면에 접근할 수 없다면
조직 관리자나 보안 담당자에게 즉시 연락합니다. 비용 발생 가능성이 있는 클라우드 키라면 공급자 지원 채널과 결제 담당자도 함께 알립니다. 접근 권한을 얻기까지 기다리면서 Git 이력만 수정하는 것은 우선순위가 아닙니다. 공격자가 이미 본 키를 이력에서 가리는 것보다 실제 사용을 막는 일이 먼저입니다.
5~10분: 새 키를 최소 권한으로 발급하고 교체하기
업무가 계속되어야 한다면 새 키를 발급합니다. 이전 키와 똑같은 광범위한 권한을 복사하기보다 실제 기능에 필요한 범위만 부여합니다. 가능하면 사용 기간, 허용 IP, 접근 대상 프로젝트, 호출 한도를 제한합니다.
새 키는 코드에 직접 넣지 않습니다. 서버의 환경 변수, 배포 플랫폼의 비밀정보 저장소, 클라우드 비밀 관리 서비스처럼 접근이 통제되고 기록이 남는 위치에 저장합니다. 브라우저에서 실행되는 JavaScript, 모바일 앱 패키지, 공개 저장소의 설정 파일에는 장기 비밀키를 넣지 않습니다. OpenAI도 API 키를 비밀로 유지하고 클라이언트 측 코드에 노출하지 말며, 서버의 환경 변수나 키 관리 서비스를 통해 불러오라고 안내합니다.
키를 바꾼 뒤에는 실제 서비스가 새 키로 정상 동작하는지 확인합니다. 단, 확인용 요청도 최소 범위로 실행하고 로그에 키 전체가 찍히지 않는지 살펴봅니다.
10~20분: 사용 로그와 피해 범위 확인하기
키가 유효했던 시간 동안의 활동을 확인합니다. “노출된 지 몇 분밖에 안 됐다”는 이유만으로 안전하다고 단정하지 않습니다. 공개 저장소와 커밋은 자동 수집 도구가 빠르게 감지할 수 있습니다.
서비스별로 다음 항목을 봅니다.
- 평소와 다른 지역, IP, 사용자 에이전트에서의 요청
- 갑자기 늘어난 호출 수와 비용
- 새로 생성되거나 삭제된 자원
- 권한 변경, 새 사용자, 새 토큰 발급
- 데이터 다운로드 또는 대량 조회
- 오류율 급증과 호출 패턴 변화
이상 활동이 있으면 관련 계정의 세션과 다른 키도 함께 폐기하고, 접근한 자원의 로그를 보존합니다. 데이터 유출이나 고객 영향 가능성이 있으면 조직의 사고 대응 절차에 따라 보안·법무·개인정보 담당자에게 알립니다. 조용히 수정하고 끝내면 뒤늦게 피해가 발견됐을 때 시간 순서를 재구성하기 어렵습니다.
비용이 발생한 경우 공급자에게 노출 시점, 폐기 시점, 이상 요청 내역을 제공할 수 있도록 기록합니다. 지원팀이 반드시 환불해 준다는 보장은 없지만, 빠른 폐기와 명확한 증거는 상황을 설명하는 데 도움이 됩니다.
20~30분: 저장소와 배포 산출물 정리하기
키를 폐기한 뒤 코드에서 비밀정보를 제거합니다. 최신 파일에서만 지워도 과거 커밋, 태그, 풀 리퀘스트, 포크, 작업 로그, 빌드 산출물에 값이 남을 수 있습니다.
점검 범위는 다음과 같습니다.
- 기본 브랜치와 작업 브랜치의 현재 파일
- 과거 커밋과 태그
- 열려 있거나 병합된 풀 리퀘스트의 변경 내역
- 이슈, 댓글, 위키, 릴리스 첨부 파일
- CI 작업 로그와 캐시, 빌드 결과물
- 배포된 정적 파일과 소스맵
- 컨테이너 이미지와 패키지 레지스트리
- 저장소 포크와 로컬 복제본
Git 이력을 다시 쓰는 작업은 협업자에게 영향을 줍니다. 저장소 관리자와 범위를 정하고 공식 절차를 따릅니다. 이력 정리는 폐기된 키가 검색되거나 다시 복사되는 일을 줄이지만, 노출 자체를 없던 일로 만들지는 못합니다. 그래서 키 폐기가 항상 먼저입니다.
비밀이 아니라 식별자였는지도 확인하기
모든 문자열이 같은 위험을 갖는 것은 아닙니다. 공개용 프로젝트 ID나 클라이언트 식별자는 원래 공개될 수 있지만, 비밀키·개인 액세스 토큰·서명키·서비스 계정 파일은 인증 수단입니다. 구분이 어렵다면 해당 서비스의 공식 문서에서 키 종류를 확인합니다.
“이 키는 읽기 전용”이라는 이유로 방치하지 않습니다. 읽기 권한만 있어도 비공개 데이터와 구조가 노출될 수 있고, 다른 취약점과 결합될 수 있습니다. 사용하지 않는 키라면 폐기하는 것이 가장 명확합니다.
사고 기록에 남길 내용
짧은 문서 하나를 만들어 다음을 시간순으로 적습니다.
- 무엇이, 어디에, 언제 노출되었는가?
- 누가 발견했고 누구에게 알렸는가?
- 기존 키를 언제 폐기했는가?
- 로그에서 어떤 활동을 확인했는가?
- 새 키는 어디에 저장했고 권한은 어떻게 줄였는가?
- 저장소와 배포물에서 어떤 흔적을 제거했는가?
- 다시 발생하지 않도록 어떤 장치를 추가했는가?
이 문서는 비난을 위한 것이 아니라 다음 사고의 대응 속도를 높이는 자료입니다. 키 원문은 기록에 넣지 않습니다.
재발 방지: 커밋 전과 푸시 시점에 막기
사고가 끝난 뒤 개인의 주의만 강조하면 비슷한 문제가 반복됩니다. 비밀정보가 저장소에 들어오는 경로 자체를 줄입니다.
예시 설정 파일을 분리하기
실제 값이 든 .env 같은 파일은 버전 관리에서 제외하고, 필요한 변수 이름만 담은 .env.example을 공유합니다. 예시 값은 실제 키처럼 보이지 않는 명확한 가짜 값으로 씁니다. 저장소를 새로 복제한 사람이 설정 방법을 알 수 있도록 README에 발급과 저장 위치를 설명합니다.
비밀정보 탐지 사용하기
GitHub의 비밀정보 검사와 푸시 보호는 알려진 형식의 비밀이 포함된 푸시를 감지하거나 차단하는 데 도움을 줍니다. 조직과 저장소에서 사용할 수 있는 기능을 확인해 켭니다. 다만 모든 사내 토큰이나 임의 형식을 자동으로 알아보는 것은 아니므로, 자체 패턴과 추가 검사 도구도 검토합니다.
권한과 수명을 줄이기
하나의 만능 키를 여러 서비스가 함께 쓰지 않습니다. 환경과 애플리케이션별로 키를 나누면 한 번의 노출이 전체 시스템으로 번지는 것을 줄일 수 있습니다. 짧은 수명, 자동 교체, 호출 한도, 사용처 제한을 지원한다면 적극적으로 설정합니다.
로그에 비밀을 남기지 않기
오류 메시지, 요청 헤더, 디버그 출력에 인증값이 찍히지 않도록 마스킹합니다. CI가 환경 변수를 출력하는 명령을 사용하지 않는지 확인하고, 실패한 작업의 로그도 접근 권한과 보관 기간을 관리합니다.
바로 쓸 수 있는 30분 체크리스트
- [ ] 기존 키를 비활성화 또는 삭제했다.
- [ ] 키의 권한과 접근 가능한 자원을 확인했다.
- [ ] 새 키를 최소 권한으로 발급했다.
- [ ] 새 키를 서버 측 비밀 저장소로 옮겼다.
- [ ] 서비스 동작을 확인했다.
- [ ] 노출 기간의 호출·접근·과금 로그를 확인했다.
- [ ] 이상 활동이 있으면 담당자에게 보고하고 로그를 보존했다.
- [ ] 현재 파일, 과거 이력, CI 로그, 배포물을 점검했다.
- [ ] 사고 기록을 남겼다.
- [ ] 비밀정보 검사와 푸시 보호를 켰다.
마무리
API 키 노출 대응의 핵심 순서는 폐기 → 교체 → 로그 확인 → 흔적 정리 → 재발 방지입니다. 커밋 삭제부터 하면 대응하는 동안에도 키가 계속 악용될 수 있습니다. 공개 여부와 상관없이 노출된 인증 정보는 더 이상 비밀이 아니라고 가정하고 빠르게 교체하세요.
공식 참고 자료
조직의 사고 대응 규정과 각 서비스 공급자의 최신 보안 안내가 있다면 그 절차를 우선 적용하세요.
확인한 공식 자료
본문은 아래 공개 자료를 바탕으로 정리했습니다. 적용 전 최신 원문과 날짜를 다시 확인하세요.