---
title: "미국 사이버 안보기관 협력업체가 정부 클라우드 키를 깃허브에 올렸다"
published: 2026-05-20T07:05:04.886Z
canonical: https://jeff.news/article/2897
---
# 미국 사이버 안보기관 협력업체가 정부 클라우드 키를 깃허브에 올렸다

미국 CISA 협력업체 직원이 정부용 AWS GovCloud 관리자 자격증명과 내부 시스템 비밀번호를 공개 깃허브 저장소에 노출했다. 저장소는 약 26시간 만에 비공개 처리됐지만 핵심 AWS 키는 이후에도 약 48시간 유효했다.

- 미국 사이버 안보를 맡는 CISA 쪽 협력업체에서 꽤 심각한 자격증명 유출 사고가 터짐
  - 외부 용역 업체 나이트윙(Nightwing) 소속 관리자가 민감한 정부 클라우드 자격증명을 공개 깃허브 저장소에 올린 것으로 확인됨
  - 저장소 이름은 ‘Private-CISA’였지만 실제로는 전 세계 누구나 접근 가능한 공개 상태였음. 이름만 private이면 뭐하냐 싶은 상황임
  - 저장소는 지난해 11월부터 올해 5월 중순까지 노출돼 있었던 것으로 알려짐

- 노출된 내용이 그냥 테스트 계정 수준이 아니었음
  - 미국 정부의 민감 업무용으로 설계된 AWS GovCloud 환경의 최고 관리자급 자격증명 3개가 포함돼 있었음
  - ‘AWS-Workspace-Firefox-Passwords.csv’ 파일에는 CISA 내부 시스템 수십 개에 로그인할 수 있는 사용자 이름과 비밀번호가 평문으로 들어 있었음
  - 데브섹옵스(DevSecOps) 환경 자격증명도 포함돼 있어서, 단순 정보 조회를 넘어 개발·배포 흐름까지 건드릴 수 있는 위험이 있었음

> [!WARNING]
> 특히 내부 아티팩토리(Artifactory) 자격증명 노출이 치명적임. 공격자가 여기를 장악하면 악성 백도어를 정상 업데이트처럼 배포하는 공급망 공격으로 이어질 수 있음.

- 더 황당한 대목은 깃허브의 보호장치가 꺼져 있었다는 점임
  - 조사 결과 해당 관리자는 깃허브가 제공하는 비밀번호·암호화 키 외부 노출 자동 차단 기능을 고의로 비활성화한 뒤 파일을 올린 것으로 파악됨
  - 업로드 패턴을 보면 안전한 개발 프로젝트가 아니라, 직장 노트북과 재택근무용 개인 컴퓨터 사이에서 파일을 동기화하거나 백업하려는 사적 용도였던 것으로 분석됨
  - 보안 사고의 출발점이 “편해서 잠깐”인 경우가 많은데, 이번 건은 그 대가가 너무 큼

- 대응도 깔끔하지 않았음. 저장소를 막은 뒤에도 키가 살아 있었음
  - CISA는 유출 사실을 통보받고 약 26시간 만에 저장소를 비공개 처리함
  - 하지만 핵심 AWS 자격증명 키는 이후에도 약 48시간 동안 유효한 상태였음
  - 실제 악용 정황은 아직 확인되지 않았다고 하지만, 공격자 입장에서는 48시간이면 꽤 많은 일을 할 수 있는 시간임

> [!IMPORTANT]
> 공개 저장소 차단은 사고 대응의 시작일 뿐임. 노출된 키 폐기, 권한 회수, 로그 조사, 배포 파이프라인 검증이 같이 움직이지 않으면 위험이 계속 남음.

- 이 사건은 한국 조직에도 그대로 적용되는 교훈이 있음
  - 공공, 금융, 클라우드 운영 조직은 협력업체 계정과 개발자 개인 워크플로까지 보안 경계에 넣어야 함
  - 시크릿 탐지 도구를 켜두는 것만으로는 부족하고, 누가 끌 수 있는지와 껐을 때 어떤 경보가 나는지도 봐야 함
  - 관리자급 키는 장기 키보다 짧은 수명의 임시 자격증명으로 줄이고, 노출 탐지 시 자동 폐기까지 이어지는 흐름이 필요함

---

## 기술 맥락

- 이번 사고의 핵심은 “깃허브에 비밀번호가 올라갔다”가 아니라, 정부용 클라우드의 높은 권한 키가 공개 저장소에 오래 남아 있었다는 점이에요. AWS GovCloud 같은 환경은 민감 업무를 다루기 위해 분리된 곳이라, 관리자급 키가 새면 일반 서비스 계정 유출보다 훨씬 크게 번져요.

- Secret Scanning 같은 자동 탐지 기능은 보안팀 입장에서는 기본 안전망이에요. 그런데 이 기능을 관리자가 끌 수 있고, 꺼진 사실이 강하게 통제되지 않으면 도구가 있어도 운영 리스크는 그대로 남거든요.

- Artifactory 자격증명이 같이 노출된 것도 중요한 이유가 있어요. 이 시스템은 배포되는 소프트웨어 구성 요소를 관리하는 곳이라, 공격자가 접근하면 내부 사용자가 신뢰하는 업데이트 경로에 악성 코드를 섞을 수 있어요.

- 그래서 이런 환경에서는 저장소 차단보다 키 회전과 권한 회수가 먼저 떠올라야 해요. 저장소를 비공개로 바꿔도 이미 복제된 키는 계속 쓸 수 있으니, 노출 감지와 동시에 자격증명을 폐기하는 자동화가 필요해요.

## 핵심 포인트

- 공개 저장소에는 AWS GovCloud 최고 관리자급 자격증명 3개와 내부 시스템 비밀번호가 포함됨
- 깃허브의 비밀번호·키 외부 노출 자동 차단 기능이 고의로 비활성화된 정황이 나옴
- 유출된 키가 저장소 차단 뒤에도 약 48시간 살아 있어 사고 대응 절차의 허점이 드러남

## 인사이트

이건 단순한 ‘깃허브에 비밀번호 올리지 말자’ 수준의 교훈이 아니다. 자동 차단 비활성화, 개인 백업 용도 저장소, 키 폐기 지연까지 겹치면 보안 성숙도가 높은 조직도 공급망 공격 표적이 될 수 있다는 사례다.