Zombie Key: 파일 삭제 후에도 활성인 키 조사와 대응

2026년 10월 4일 수정. 이전 글은 가상의 핀테크 침해에 거래 건수와 정확한 시각을 붙여 실제 사건처럼 설명했습니다. GitHub secret scanning이 현재 코드만 검사한다는 주장도 틀렸습니다. 이번 글은 그 내용을 걷어내고, 파일 삭제 상태와 키 유효성 상태에서 실제로 알 수 있는 것을 정리합니다.

파일 삭제와 키 폐기는 다른 기록

파일을 지우거나 하드코딩된 값을 바꾸면 소스가 달라집니다. 키를 발급한 서비스의 상태까지 바뀌지는 않습니다. 키가 여전히 유효하고 누군가 복사본을 갖고 있다면 발급처가 허용하는 범위에서 인증에 쓰일 수 있습니다. 반대로 파일 삭제 기록만으로 유출, 공격자 사용, 다른 시스템의 복사본까지 확정할 수도 없습니다.

어느 발견 위치가 언제 삭제 상태로 바뀌었는지, 키가 처음 어디서 발견됐는지, 활성 상태를 마지막으로 확인한 시각을 기록합니다. 마지막 확인 결과는 그 시점의 관찰이므로 종결 전에 발급처의 현재 상태를 다시 확인하세요. 접근 권한이 있는 연결 소스와 승인된 범위에서 다른 복사본도 찾아봅니다. 관련 브랜치, 산출물, 로그가 조사 대상이 될 수 있습니다.

GitHub secret scanning이 검사하는 범위

GitHub 문서에 따르면 secret scanning은 지원하는 유형에 대해 모든 브랜치의 Git 기록 전체를 검사합니다. 최신 파일에서 값을 지워도 앞선 커밋에서 사라지는 것은 아닙니다. 또한 토큰을 저장소에서 제거해도 해당 경고가 자동으로 닫히지 않습니다. 담당자가 문제를 해결한 뒤 종료 사유를 선택해야 합니다. 유효성 확인 기능을 쓸 수 있는지는 키 종류와 설정에 따라 다릅니다.

닫힌 경고는 업무 처리 상태이지 발급처가 이전 키를 거부한다는 보증이 아닙니다. 종료 사유, 발급처 상태, 관련 보안 로그를 함께 확인하세요. GitHub는 노출된 키를 폐기하거나 교체한 뒤에 기록 재작성 필요성을 판단하라고 권합니다. 기록을 다시 쓰면 협업자에게 영향이 있고 오래된 클론이나 포크도 남을 수 있으므로 키를 무효화한 뒤 범위를 결정해야 합니다.

확인 가능한 대응 순서

발급처, 현재 담당자, 키 권한, 연결된 작업을 확인합니다. 운영 중인 서비스가 예기치 않게 중단되지 않도록 담당자와 교체를 조율하세요. 노출된 키가 아직 작동할 수 있다면 발급처에서 신속히 차단합니다. 이전 값이 더 이상 통하지 않는지 다시 확인하고 교체·폐기 근거를 남깁니다. 관련 기간의 발급처 로그로 사용 흔적을 조사하되 로그가 없는 구간은 빈틈으로 기록해야 합니다.

Amazon RDS의 마스터 비밀번호는 RDS에서 관리하고, 설정에 따라 Secrets Manager와 연동합니다. IAM 콘솔에서 AWS 액세스 키를 끄는 절차와 다릅니다. 정확한 교체 방법은 데이터베이스 자격증명의 관리 방식에 따라 정해야 합니다. 교체 주기도 위험과 운영 요구에 맞춰 정하며, 이 발견 조건 자체가 일률적인 최대 90일 규칙을 뜻하지는 않습니다.

Cremit의 Zombie Key 체크리스트가 뜻하는 것

CRE-005 체크리스트는 자격증명 상태가 활성 또는 수동 활성이고 발견 기록이 하나 이상 있으며, 연결된 모든 스캔 객체가 삭제로 표시된 경우를 보여 줍니다. 관찰된 소스 상태와 마지막 키 상태가 다르다는 조사 단서입니다. 과거 기록이나 외부 복사본이 모두 사라졌는지, 지금도 발급처에서 키가 작동하는지, 공격자가 사용했는지까지 증명하지는 않습니다. Cremit이 키를 자동 폐기하지도 않습니다. 발급처의 최신 상태를 확인하고 담당자의 조치가 끝났는지 검증한 뒤 사건을 종결하세요.