사이버보안 사령탑의 민낯: CISA 관리자가 GitHub에 AWS 정부 클라우드 키를 흘렸다

“의사가 가장 아프다"는 말이 있죠. 이번엔 사이버보안의 의사라 할 수 있는 미국 CISA(사이버보안·인프라보안국) 차례입니다. 다른 기관의 보안을 지도하던 CISA의 한 관리자가 정작 자신은 AWS GovCloud 접근 키를 공개 GitHub 저장소에 그대로 올려놨다는 사실이 드러났습니다. 보안 업계가 한바탕 술렁이는 이유, 같이 살펴보시죠.

무슨 일이 벌어진 건가요

사건의 골자는 단순합니다. CISA에서 관리자 권한을 가진 한 직원이 공개 GitHub 저장소에 코드를 푸시했는데, 그 안에 AWS GovCloud 접근 자격증명이 평문으로 포함돼 있었다는 겁니다.

GovCloud는 일반 AWS와 다릅니다. 미국 연방정부와 국방부, 그리고 정부 계약자들이 민감한 워크로드를 돌리기 위해 쓰는 격리된 클라우드 환경입니다. 한마디로 정부 전용 금고인데, 그 금고 열쇠를 누구나 볼 수 있는 게시판에 붙여놓은 셈이죠.

키가 노출된 시간은 짧지 않았다고 합니다. 자동화된 봇들이 GitHub를 24시간 스캔하며 자격증명을 줍는 시대에, 노출 시간이 분 단위만 넘어도 사실상 “공개된 것으로 간주"하는 게 업계의 상식입니다.

왜 이게 특별히 충격적인가

CISA가 누구입니까. 미국 정부 기관들에게 “절대 코드에 시크릿 하드코딩하지 마라”, “git-secrets, TruffleHog 같은 도구로 사전 차단하라"고 지침을 내려보내는 곳입니다. 본인들이 발행한 Secure by Design 캠페인의 핵심 메시지도 “비밀은 비밀답게 관리하라"였습니다.

설교하던 사람이 가장 기초적인 실수를 한 거죠. 게다가 일반 직원도 아닌 관리자(admin) 권한 계정의 자격증명이라는 점이 문제를 키웁니다. 관리자 키는 그 자체로 시스템 전체를 좌우할 수 있는 마스터키에 가깝거든요.

GovCloud 키가 노출되면 어떤 일이 가능한가

기술적으로 따져보면 영향 범위는 노출된 키의 권한 범위에 달려 있습니다. 최악의 시나리오를 가정해보면 이런 그림이 그려집니다.

첫째, 정부 시스템 내부 데이터 열람입니다. S3 버킷, RDS 데이터베이스, 로그 스토리지에 저장된 정보가 위험에 노출됩니다.

둘째, 측면 이동(lateral movement)입니다. 한번 발판을 잡으면 IAM 권한을 활용해 다른 리소스로 옮겨가며 권한을 확장할 수 있습니다.

셋째, 흔적 지우기입니다. CloudTrail 로그를 조작하거나 비활성화해 침입 자체를 은폐할 수도 있죠.

물론 CISA가 이중 인증이나 IP 화이트리스트, 키 자동 회전 같은 보강 장치를 걸어뒀다면 실제 피해는 제한적일 수 있습니다. 다만 “그런 장치가 있었기를 바란다"는 게 외부 보안 전문가들의 솔직한 반응입니다.

사람의 실수 vs 시스템의 실패

이 사건을 단순히 “한 직원의 부주의"로 정리하면 본질을 놓칩니다. 보안 업계에는 오래된 격언이 있습니다. “한 사람의 실수로 뚫리는 시스템은, 그 시스템이 잘못 설계된 것이다.”

GitHub에 시크릿이 올라가지 않게 막는 기술적 장치들은 이미 존재합니다. pre-commit hook, GitHub의 시크릿 스캐닝, AWS의 IAM Access Analyzer, 자격증명 자동 회전 정책까지 도구는 차고 넘칩니다. 그런데도 사고가 났다는 건, CISA 내부의 개발 파이프라인 어딘가에서 이런 안전망이 빠져 있었다는 뜻입니다.

특히 GovCloud 같은 민감 환경의 키라면 애초에 장기 자격증명(long-lived credentials)을 발급하지 않고 IAM Roles나 STS 임시 토큰을 쓰는 게 정석입니다. 키가 코드에 들어갈 일 자체가 없도록 만드는 거죠.

우리가 가져갈 교훈

남의 사고를 보며 우리 조직을 돌아보지 않으면 그저 가십일 뿐입니다. 이번 사건이 던지는 질문은 명확합니다.

당신의 회사 GitHub에는 지금 이 순간에도 시크릿이 잠들어 있을 가능성이 얼마나 됩니까. git history 깊은 곳, 누군가 5년 전 테스트 코드에 박아둔 키가 아직 살아있지는 않은가요. 그 키들은 정기적으로 회전되고 있나요.

CISA마저 당했다는 사실은 역설적으로 위안이 됩니다. 보안은 의지의 문제가 아니라 시스템의 문제라는 걸 입증하니까요. 그리고 시스템은 만들면 됩니다. 오늘 당장.

여러분 조직의 시크릿 관리, 마지막으로 점검한 게 언제입니까. 이 글을 다 읽고 나서 한 번쯤 사내 보안팀에 슬쩍 물어보시는 것도 나쁘지 않을 것 같습니다.