코드 저장소 비밀정보 노출, 깃에 키·비밀번호를 올리지 않는 5가지

코드 저장소 비밀정보 노출은 설정 파일을 저장소에서 빼고, 이미 올라갔다면 키를 먼저 교체해 막습니다. 이 글에서는 깃 저장소에 비밀번호와 API 키가 올라가는 경로, 미리 막는 5가지 방법, 올라간 뒤의 대응 순서를 정리했습니다.

코드 저장소에 비밀정보가 올라가는 경로

깃(Git) 같은 코드 저장소는 홈페이지 코드의 변경 이력을 모두 기록합니다. 여러 개발자가 함께 작업하고 이전 버전으로 되돌리기 쉽다는 장점이 있지만, 한 번 올라간 내용은 이력에 남습니다. 데이터베이스 비밀번호, 메일 발송 계정, 결제 키가 담긴 설정 파일을 실수로 함께 올리면 그 이력을 볼 수 있는 모든 사람에게 비밀정보가 넘어갑니다.

공개 저장소라면 인터넷 전체에 공개되는 것이고, 비공개 저장소라도 저장소 계정이 털리거나 외주 개발자가 바뀌면 같은 문제가 생깁니다. 저장소를 비공개로 두는 것만으로는 비밀정보를 지킬 수 없습니다.

자주 올라가는 파일

• 데이터베이스 접속 정보가 담긴 환경설정 파일
• 외부 서비스 API 키를 적어 둔 설정 파일이나 코드
• 서버 접속용 개인 키 파일
• 테스트용으로 내려받은 데이터베이스 백업 파일
• 작업 중 남긴 메모 파일에 적은 관리자 비밀번호

비밀정보 노출을 미리 막는 5가지 방법

미리 막는 방법은 비밀정보가 담긴 파일과 코드를 처음부터 분리하는 것입니다. 아래 다섯 가지는 저장소를 처음 만들 때 정해 두면 이후 관리가 쉬워집니다.

1. 설정 파일 분리: 비밀번호와 키는 코드가 아닌 환경설정 파일에 두고, 코드에서는 그 값을 읽어 쓰게 합니다.
2. 무시 목록에 등록: 환경설정 파일, 개인 키, 백업 파일 형식을 저장소의 무시 목록(.gitignore)에 넣어 올라가지 않게 합니다.
3. 예시 파일만 올리기: 실제 값 대신 빈칸이나 가짜 값을 넣은 예시 설정 파일을 올려, 어떤 항목이 필요한지만 알 수 있게 합니다.
4. 자동 검사 켜기: 저장소 서비스가 제공하는 비밀정보 검사 기능을 켜 키 형식의 문자열이 올라오면 알림을 받습니다.
5. 올리기 전 확인 습관: 변경 내용을 올리기 전에 추가된 파일 목록을 보고, 설정 파일이나 백업 파일이 섞이지 않았는지 확인합니다.

그림의 두 번째 방법에는 주의할 점이 있습니다. 깃 공식 설명서의 gitignore 설명에 따르면 무시 목록은 이미 저장소가 추적하고 있는 파일에는 적용되지 않습니다. 이미 올라간 설정 파일은 무시 목록에 넣는 것과 별도로 추적 대상에서 빼야 합니다. 자동 검사 기능의 예로는 GitHub의 비밀정보 검사(secret scanning) 안내가 있습니다.

이미 올라갔을 때 대응 순서

비밀정보가 저장소에 올라간 것을 발견하면 파일을 지우는 것보다 키를 바꾸는 것이 먼저입니다. 아래 표는 흔히 하는 대응과 실제로 필요한 대응을 비교한 것입니다.

상황	흔한 대응	필요한 대응
설정 파일이 올라감	파일만 지우고 다시 올림	비밀번호·키 교체 후 파일을 추적에서 제외
공개 저장소에 키 노출	저장소를 비공개로 전환	키 즉시 교체, 사용 기록 확인
개인 키 파일이 올라감	파일 삭제	서버에서 해당 공개 키 삭제, 새 키 등록
DB 백업이 올라감	파일 삭제	개인정보 포함 여부 확인, 필요하면 신고 검토

표의 공통점은 노출된 값을 쓸 수 없게 만드는 것입니다. GitHub 안내도 비밀정보가 노출되면 그 자격 증명을 즉시 교체하라고 권하며, 이미 폐기한 키라면 이력에서 지우는 작업은 꼭 필요하지 않을 수 있다고 설명합니다. 키를 바꾸는 순서는 API 키 관리 글에 정리했습니다.

개인정보가 담긴 파일이었다면

올라간 파일이 회원 정보가 담긴 데이터베이스 백업이라면 개인정보 유출에 해당할 수 있습니다. 이때는 유출 범위를 확인하고 신고와 통지 기준을 검토해야 하며, 판단이 어렵다면 KISA 상담이나 전문가 확인을 받는 것이 좋습니다. 통지 기준은 개인정보 유출 통지, 이용자에게 알릴 7가지 항목과 72시간 기준을 참고하세요.

저장소 비밀정보 점검 체크리스트

외주 개발이나 리뉴얼이 끝나면 저장소를 넘겨받으면서 아래 항목을 확인합니다.

• 저장소에 실제 값이 든 환경설정 파일이 없다.
• 무시 목록에 환경설정 파일, 개인 키, 백업 파일 형식이 들어 있다.
• 비밀정보 자동 검사 알림이 켜져 있고 남은 경고가 없다.
• 저장소에 접근할 수 있는 사람 목록에 떠난 사람이 없다.
• 과거에 노출된 적 있는 키는 모두 교체했다.

체크리스트의 네 번째 항목은 저장소 서비스의 권한 설정에서 확인할 수 있습니다. 저장소 계정도 관리자 계정처럼 2단계 인증을 켜 두는 것이 좋습니다.

디코랩이 돕는 방식

디코랩은 웹 서비스와 맞춤형 시스템 제작, 운영 중인 사이트의 유지보수와 웹 기술 컨설팅을 맡고 있습니다. 넘겨받은 코드에 비밀정보가 섞여 있는지 확인이 필요하다면 웹사이트 취약점 점검 서비스를 함께 검토할 수 있습니다.

자주 묻는 질문

비공개 저장소라면 괜찮지 않나요?

비공개 저장소도 접근 권한이 있는 사람과 저장소 계정이 털렸을 때의 위험이 남습니다. 비공개 여부와 관계없이 비밀정보는 저장소 밖에 두는 것이 원칙입니다.

이력에서 지우면 키를 안 바꿔도 되나요?

이력을 지우기 전에 이미 누군가 복사했을 수 있으므로 키 교체가 먼저입니다. 이력 정리는 교체한 뒤 필요에 따라 진행합니다.

외주 개발자에게 설정 파일을 어떻게 전달하나요?

저장소가 아닌 별도의 안전한 방법으로 전달하고, 작업이 끝나면 그 비밀번호와 키를 교체합니다. 가능하면 업체용 별도 계정과 키를 발급하는 편이 정리하기 쉽습니다.

넘겨받은 홈페이지 코드와 저장소 점검이 필요하다면 디코랩 프로젝트 문의로 현재 상황을 알려 주세요.