핵심 요약
API 키·비밀번호를 커밋에 넣어 푸시했다면, 가장 먼저 할 일은 파일을 지우는 게 아니라 그 키를 즉시 폐기(rotate)하는 것이다. 봇들이 GitHub 신규 커밋을 초 단위로 스캔하므로 몇 분 안에 악용될 수 있다. 이미 노출된 키는 "없앨" 수 없고 "무효화"만 가능하다.
1. 대응 순서 (순서가 중요)
- 키를 즉시 폐기·재발급 — 이게 1순위. 노출된 키는 이미 죽은 것으로 간주
- 새 키를 환경변수·시크릿 매니저로 안전하게 교체
- 커밋 히스토리에서 제거(아래)
- 영향 범위 점검 — 로그·청구서에서 오용 흔적 확인
2. 왜 파일만 지우면 안 되나
git rm secret.env
git commit -m "remove secret" # ❌ 소용없음파일을 지운 커밋을 새로 만들어도, 이전 커밋에 키가 그대로 남아 히스토리를 뒤지면 나온다. 그래서 폐기가 최우선이다.
3. 히스토리에서 완전히 제거
# git-filter-repo 권장 (BFG도 가능)
git filter-repo --path secret.env --invert-paths
# 강제 푸시 (협업자와 반드시 사전 조율)
git push origin --force --all히스토리를 다시 쓰므로 팀원은 다시 클론해야 한다. 하지만 이미 노출된 키는 히스토리를 지워도 안전해지지 않는다 — 폐기가 답이다.
4. 재발 방지
| 도구 | 역할 |
|---|---|
.gitignore | .env 등 커밋 대상에서 제외 |
| git-secrets / gitleaks | 커밋 전 시크릿 자동 탐지 |
| pre-commit 훅 | 키 패턴 발견 시 커밋 차단 |
| 시크릿 매니저 | Vault·AWS Secrets Manager로 코드 밖 관리 |
5. 함정
- 프라이빗 저장소라 안전하다고 방심 금지 — 권한 변경·포크·CI 로그로 샐 수 있다
- GitHub Push Protection·Secret Scanning을 켜두면 사전 차단·알림을 받는다
- 키를 코드가 아니라 환경변수로 주입하는 습관이 근본 해결책
자주 묻는 질문
바로 지우고 force push 하면 되지 않나요?
히스토리 제거는 필요하지만 그것만으론 부족합니다. 푸시된 순간 봇·캐시·포크·CI 로그에 이미 복제됐을 수 있어 노출된 키 자체를 반드시 폐기해야 합니다. 순서는 "폐기 먼저, 히스토리 정리 나중"입니다.
프라이빗 저장소인데도 위험한가요?
공개보다는 낮지만 안전하지 않습니다. 협업자 권한 오설정, 저장소 공개 전환, 포크, CI/CD 로그 출력 등으로 유출될 수 있습니다. 프라이빗이라도 시크릿은 코드가 아닌 환경변수·시크릿 매니저로 관리하세요.
어떻게 하면 처음부터 안 올라가나요?
.env를 .gitignore에 넣고, gitleaks·git-secrets 같은 도구를 pre-commit 훅으로 걸어 커밋 전에 자동 차단하세요. GitHub의 Push Protection을 켜면 시크릿이 포함된 푸시를 서버 단에서 막아줍니다.
댓글 0