사이버보안 기관 CISA 관리자가 GitHub에 AWS GovCloud 키를 노출한 사건

사이버보안 잡으라고 만든 곳에서 사고가 났어요

혹시 CISA라는 기관 들어보셨나요? 미국 국토안보부 산하에 있는 사이버보안 및 인프라보안국(Cybersecurity and Infrastructure Security Agency)이라는 곳이거든요. 쉽게 말하면 미국 정부의 사이버 침해 사고를 막고, 민간 기업들한테도 "이런 취약점 조심하세요" 하고 권고하는 사이버 안전 컨트롤타워라고 보시면 돼요. 그런데 이번에 그 CISA 내부의 관리자급 직원이 자기 개인 GitHub 저장소에 AWS GovCloud 액세스 키를 그대로 푸시해 버린 사실이 보안 기자 Brian Krebs를 통해 공개됐어요. 보안을 가르치는 사람이 보안 사고를 낸 셈이죠.

GovCloud가 뭐길래 더 심각한가요

AWS를 써보신 분이라면 보통 us-east-1, ap-northeast-2 같은 일반 리전을 떠올리실 텐데요. GovCloud는 그런 일반 리전과 물리적으로 완전히 분리된 미국 정부 전용 클라우드 영역이에요. 미국 시민권자만 운영에 접근할 수 있고, FedRAMP High나 DoD IL5 같은 무지막지하게 빡빡한 컴플라이언스 기준을 충족하도록 설계돼 있거든요. 그 안에는 군, 정보기관, 연방기관의 워크로드가 돌아가기 때문에 키 하나가 새는 게 일반 사이드 프로젝트 키가 새는 것과 비교가 안 되는 무게를 가져요.

이번에 노출된 키는 CISA 내부 시스템과 연결된 IAM 사용자에 매여 있었던 것으로 보이고, 권한 범위가 어디까지였는지는 공식적으로 공개되지 않았어요. 다만 깃허브에 올라간 시점부터 발견·회수까지 며칠 단위로 노출돼 있었다는 점, 그리고 같은 저장소에 내부 시스템 명세나 환경 변수까지 함께 들어 있었다는 점이 같이 보도됐어요. 즉 단순히 키 하나만 샌 게 아니라, 그 키를 어디다 어떻게 쓰는지를 알려주는 지도까지 같이 공개된 상황이었던 거예요.

어떻게 새어 나갔을까요

패턴이 너무 익숙해서 오히려 무서운데요. 보통 이런 사고는 "잠깐 테스트하려고 .env 파일 그대로 커밋" → "나중에 정리해야지 하고 잊어버림" → "공개 저장소로 푸시" 이 3단 콤보로 일어나거든요. 이번 사건도 비슷한 흐름으로 추정돼요. AWS는 GitHub 공개 저장소를 지속적으로 스캔해서 자기네 키 패턴(AKIA로 시작하는 액세스 키 ID 등)이 발견되면 자동으로 quarantine 정책을 붙여서 위험한 API 호출을 막아주는데, 이번 건도 그 자동 탐지가 일부 작동했어요. 하지만 자동 탐지 전에 누군가 키를 긁어 갔다면 이미 늦은 거죠.

비슷한 사고가 이렇게 많이 일어나요

사실 이게 일회성 해프닝이 아니에요. GitGuardian이 매년 내는 보고서를 보면, GitHub 공개 커밋에서 발견되는 시크릿이 한 해에 1천만 건이 넘는다고 해요. AWS 키, OpenAI 키, Stripe 키, JWT 시크릿 같은 게 줄줄이 새고 있는 거죠. 토요타도 10년 동안 깃허브에 액세스 키를 올려놨다가 30만 명 분량의 고객 데이터가 노출된 적이 있고, Uber, Slack, Mercedes-Benz도 비슷한 사고를 겪었어요. 이번 CISA 건은 "보안 기관도 똑같이 당한다"는 점에서 충격일 뿐, 메커니즘 자체는 평범한 사고예요.

우리 코드는 안전할까요

한국 개발자 입장에서 "미국 정부 얘기지 뭐" 하고 넘기긴 아쉬워요. 점검 포인트가 몇 개 있거든요. 첫째, 깃 훅 단계에서 미리 막아주세요. gitleaks나 trufflehog 같은 도구를 pre-commit 훅에 걸어두면 키가 들어간 커밋 자체를 만들지 못하게 돼요. 둘째, 키를 코드에 박지 말고 AWS Secrets Manager, HashiCorp Vault, 또는 GitHub Actions의 OIDC 연동을 쓰세요. OIDC를 쓰면 아예 영구 키 없이 워크플로우가 임시 토큰만 받아서 동작하기 때문에 새 나갈 키가 존재하지 않아요. 셋째, IAM 정책에서 최소 권한 원칙을 지키세요. 액세스 키가 어쩌다 새도 그 키로 할 수 있는 일이 "S3 특정 버킷 읽기" 정도면 피해가 제한되거든요. 넷째, CloudTrail과 GuardDuty를 켜두고 비정상적인 API 호출 패턴을 알람으로 받게 하세요.

그리고 진짜 중요한 마지막 한 가지. 혹시 "내 GitHub에 옛날에 뭐 올렸었는데..." 싶으시면 지금 당장 자기 계정 검색해 보세요. AKIA나 secret_key 같은 키워드로 본인 저장소를 grep만 해봐도 의외의 게 나와요. 그리고 한번 푸시된 시크릿은 커밋 히스토리에 영원히 남기 때문에, force push로 덮어도 fork나 캐시에 남아 있을 수 있어요. 발견 즉시 키 폐기(rotate)가 최우선이고, 파일 삭제는 그다음 일이에요.

정리하며

한 줄로 정리하면, 보안의 가장 약한 고리는 늘 사람이고, 그 사람은 사이버보안 기관 직원이라도 예외가 아니다예요. 이번 사고에서 배워야 할 건 "CISA가 한심하다"가 아니라, "내가 만든 시스템도 키를 코드에 박지 않도록 구조적으로 강제하고 있는가"라는 질문이에요.

여러분 팀에서는 시크릿을 어떻게 관리하시나요? 깃 훅에 스캐너를 걸어두는 곳도 있을 거고, 아예 OIDC만 쓰는 곳도 있을 텐데, 실제로 운영해 보시면서 가장 효과적이었던 방법이 있다면 공유해 주세요.