깃허브에서 지운 키는 지워지지 않는다

Privacy실무 가이드

6월 15일 개인정보위가 클라우드·개발 협업도구 사용 시 자격증명 관리를 강화하라는 보도참고자료를 냈다. 새로운 의무를 만든 건 아니고 권고다. 그런데 자료에 붙어 있는 국내 사고 사례가 생각보다 구체적이라, 이건 그냥 넘기기 아깝다.

접근키 하나에 1천만 건

자료에 실린 사례는 네 건이다.

C사는 깃허브에 노출된 AWS 접근키가 확보되면서 개인정보 약 1천만 건이 유출됐다. B사는 깃허브에 평문으로 저장돼 있던 DB 접속정보 때문에 42만 건. A사는 스피어피싱으로 깃허브 계정 접근권한이 먼저 뚫렸고, 거기서 얻은 AWS 접근키로 내부 데이터베이스의 개인정보 240만 건이 열람됐다. D사는 소스코드에 하드코딩된 시크릿 키가 노출된 경우.

네 건 다 시스템 취약점을 뚫은 게 아니다. 공격자는 그냥 정당한 자격증명으로 로그인했다. 이게 실무에서 제일 껄끄러운 지점이다. 접속기록만 놓고 보면 정상 접근처럼 보인다. WAF도, IPS도 안 걸린다. 유출 사실을 몇 달 뒤에 아는 사고들이 대체로 이런 구조다.

지워도 남는다

자료에서 개인적으로 제일 중요하다고 본 문장은 사고 사례가 아니라 마지막에 붙은 사무처장 코멘트다. 실수로 자격증명을 코드저장소에 올렸을 때, 작업 공간에서 지워도 형상관리 이력에는 그대로 남는다는 얘기.

당연한 말 같지만 현장에서 이걸 정확히 아는 개발팀이 생각보다 적다. 키가 들어간 파일을 지우고 커밋하면 최신 코드에서는 사라진다. 근데 이전 커밋에는 그대로 있다. 히스토리를 다시 쓴다고 해도 이미 누가 클론했거나, 포크가 떠 있거나, PR에 diff가 남아 있으면 소용없다. 공개 저장소였다면 봇이 이미 긁어갔다고 보는 게 맞다.

저장소에서 자격증명을 삭제하는 건 대응이 아니다. 노출이 확인된 순간 해야 할 첫 번째 일은 해당 키를 폐기하고 새로 발급하는 것이다. 삭제는 그다음이다.

사고 대응 절차 문서에 이 순서가 안 박혀 있는 곳이 많다. "유출 파일 삭제 후 보고" 같은 식으로 적혀 있으면, 실제 상황에서 개발자는 커밋부터 지우고 있을 확률이 높다. 그 사이 키는 계속 살아 있다.

탐지보다 발급 구조

권고 항목 중에 눈여겨볼 건 임시 자격증명이다. AWS IAM Role처럼 일정 시간 뒤 자동 만료되는 방식을 쓰라는 것. 나머지 권고(IP·네트워크 제한, 주요 시스템 MFA, 최소권한, 미사용 권한 즉시 회수)는 사실 새로운 얘기가 없다.

깃허브 Secret Scanning이나 Push Protection 같은 자동 탐지 도구도 자료에 예시로 들어가 있는데, 이건 어디까지나 사후 안전망이다. 유효기간 없는 장기 키가 계속 발급되는 한, 탐지는 언젠가 뚫린다.

그렇다고 "장기 자격증명 전면 금지"를 컨설팅 리포트에 그대로 쓰는 건 현실적이지 않다. 레거시 배치 스크립트, 벤더 연동 인터페이스, 온프레미스에서 넘어온 잔재에 장기 키가 박혀 있는 경우가 태반이다. 나는 이런 곳에는 순서를 바꿔서 제안한다. 먼저 발급된 키 전수 목록을 만들고, 각 키의 용도·소유자·마지막 사용일을 확인한다. 안 쓰는 키를 회수하는 것만으로도 공격면이 눈에 띄게 준다. 임시 자격증명 전환은 그다음이다. 목록도 없는 상태에서 IAM Role부터 붙이자고 하면 아무 일도 안 일어난다.

심사에서 뭘 물어볼까

컨설팅 입장에서 보면 이 자료는 심사 질문지 예고편에 가깝다. 클라우드 전환을 했거나 하고 있는 조직이라면 다음은 준비해두는 게 좋다.

소스 프로그램 관리(2.8.5) 관점에서 코드 내 하드코딩 자격증명 점검 절차가 있는지. 있다면 코드 리뷰 체크리스트에 명시돼 있는지, 아니면 도구로 자동 점검하는지. 접근권한 검토(2.5.6) 관점에서 클라우드 접근키 발급·회수 대장이 있는지, 검토 주기가 돌고 있는지. 데이터베이스 접근(2.6.4) 관점에서 DB 접속정보가 어디에 어떤 형태로 보관되는지. 관리 콘솔과 DB에 MFA가 걸려 있는지.

이 자료를 낸 부서가 사전실태점검과라는 점도 기억해둘 만하다. 개인정보위가 어디를 들여다보고 있는지에 대한 신호로 읽어도 크게 틀리지 않을 거다.

사고가 난 회사들이 몰라서 그런 건 아닐 거다. 소스코드에 키 넣지 말라는 건 신입 개발자도 안다. 문제는 급할 때 잠깐 넣어둔 키가 3년째 살아 있다는 것, 그리고 그걸 아무도 세고 있지 않다는 것이다.


출처: 개인정보위, 클라우드·개발 협업도구 사용시 자격증명 관리 강화 당부 (2026.6.15)