AI로 만든 프로그램을 깃허브에 올린 뒤 API 키가 함께 공개됐다는 사실을 알아차릴 수 있습니다. 당황해서 파일에서 키만 지우기 쉽지만, 그 작업만으로 노출된 키가 무효가 되지는 않습니다. 가장 먼저 해야 할 일은 해당 키를 발급한 서비스에서 폐기하거나 교체하는 것입니다. GitHub의 민감 정보 노출 대응 안내
[목차]
1. 유출된 키를 먼저 쓸 수 없게 만드세요
API 제공 업체의 공식 관리 화면에서 노출된 키를 확인하고 폐기 또는 회전 절차를 진행합니다. 서비스마다 메뉴와 동작이 다르므로 공식 안내를 따르세요. 새 키를 만들었다는 사실만으로 이전 키가 자동 폐기됐다고 생각하면 안 됩니다.
어느 프로젝트와 프로그램에서 사용하던 키인지도 기록해 두면 좋습니다. 예를 들어 글 생성 작업, 이미지 처리 작업, 배포 서버가 같은 키를 사용하고 있었다면 교체 후 확인할 대상이 여러 개일 수 있습니다. 기록에는 실제 비밀값을 적지 말고 키 이름이나 식별 가능한 끝부분 등 최소한의 정보만 남기세요.
2. 사용 내역과 영향을 확인하세요
노출된 것으로 추정되는 시점부터 요청 기록과 사용량을 살펴봅니다. 평소와 다른 호출이나 비용이 있다면 서비스 제공 업체에 문의할 때 필요한 시간대와 프로젝트 정보를 정리하세요. 이상이 보이지 않는다고 해서 노출이 없었다는 뜻은 아닙니다.
프로그램이 처리하는 데이터의 성격에 따라 점검 범위도 달라집니다. 회사나 고객 자료와 연결된 키였다면 혼자 해결했다고 마무리하지 말고 조직의 보안 담당자에게 알리는 것이 좋습니다. 확인 자료를 전달할 때도 키 전체가 보이는 화면을 다시 공유하지 않도록 주의하세요.
3. 현재 파일과 과거 기록을 구분하세요
GitHub는 저장소의 현재 파일을 수정하더라도 이전 커밋, 복제본, 포크 등에 민감 정보가 남을 수 있다고 설명합니다. 기록을 다시 쓰는 작업은 다른 사람의 작업과 연결된 기록에도 영향을 주므로 협업자와 조율해야 합니다. GitHub의 기록 정리와 영향 설명
이 때문에 인터넷에서 찾은 강제 푸시 명령을 상황 확인 없이 실행하는 것은 피하는 편이 좋습니다. 키를 무효화하는 조치와 저장소 기록을 정리하는 조치는 목적이 다릅니다. 먼저 접근 수단을 차단하고, 기록 정리는 해당 저장소의 협업 상황에 맞게 진행하세요.
4. 새 키는 다시 코드에 넣지 마세요
새 키를 소스코드에 직접 적는 대신 실행 환경의 비밀값 관리 기능을 활용하는 방식으로 구조를 점검합니다. 예제 설정 파일에는 실제 키가 아닌 자리표시자만 넣고, 로그나 오류 화면에도 비밀값이 출력되지 않는지 살펴보세요.
특히 브라우저에 전달되는 코드 안에 서버용 비밀 키를 넣지 않도록 확인해야 합니다. Google Cloud도 클라이언트 코드와 저장소에 API 키를 넣지 않도록 안내합니다. 파일 이름을 바꾸거나 화면에서 가리는 것은 접근 통제가 아닙니다. AI에게 수정 작업을 맡길 때도 실제 키를 붙여 넣기보다 비밀값 없이 설정 구조와 오류 내용을 보여주는 편이 안전합니다. Google Cloud의 API 키 보호 권장사항
마지막으로 교체한 프로그램이 정상 동작하는지 확인하고 오래된 키가 더 이상 유효하지 않은지 점검하세요. 공개된 파일을 지우는 것보다 노출된 키의 권한을 끊는 것이 먼저라는 순서를 기억하면 대응 과정에서 중요한 조치를 놓치지 않을 수 있습니다.
