마이크로소프트 Credential 유출 사고

"마이크로소프트에서 직원의 실수로 인해 다수의 Secret 그리고 38테라바이트의 주요 데이터 노출 사고가 발생했습니다."

클라우드 보안 스타트업인 Wiz는 30,000개 이상의 내부 Microsoft Teams 메시지를 포함하여 Microsoft의 AI GitHub repository에서 노출 사고를 발견했다고 발표했습니다. Github에 공개된 Secret(SAS token)이 문제였습니다.

해당 리포지토리는 마이크로소프트의 AI 연구 팀에 속해 있으며 이 리포지토리의 목적은 이미지 인식을 위한 오픈소스 코드와 AI 모델을 제공하는 것이었습니다. 리포지토리 내에서 Azure Storage의 URL을 통해 AI 모델을 다운로드하도록 안내하였고 블롭(Blob)스토어 URL에 SAS 토큰을 실수로 잘못 포함시켰고, 이 URL을 공개 GitHub 저장소에 공유했습니다.더욱이 이 토큰은 특정 파일에 대한 접근만 허용되게 하는 것을 잘못 설정하여 전체 스토리지 계정을 공유하게 되었습니다.잘못 설정된 SAS 토큰 때문에, 리포지토리에 액세스 한 사람이라면 추가 Secret, 38TB의데이터, 비밀번호 그리고 마이크로소프트 팀의 내부 채팅 메시지 등을 볼 수 있었습니다.더 큰 문제는 이 토큰은 읽기 전용이 아니라 '전체 제어' 권한까지 부여되어 있었습니다. 이로 인해 공격자가 파일을 삭제하거나 덮어쓸 수 있었습니다.이러한 설정은 공격자가 AI 모델에 악성 코드를 주입할 수 있는 가능성을 열어놓았고, 이로 인해 모델을 사용하는 다른 사용자들에게도 위험이 전파될 수 있었습니다. 이에 마이크로소프트 측은 마이크로소프트 Github, 제휴 조직의 모든 공용 리포지토리에 대한 전체 Secret 탐색을 진행했습니다. 또한 모든 SAS 토큰을 포함하도록 탐지 범위를 확장했습니다.Azure Storage는 SAS URL 작업 시 다음 모범 사례를 권장합니다. (출처 : MSRC 블로그)최소 권한 원칙 적용: SAS URL의 범위를 클라이언트에 필요한 가장 작은 리소스 집합(예: 단일 Blob)으로 지정하고 애플리케이션에 필요한 것만으로 권한을 제한합니다.(예: 읽기 전용, 쓰기 전용)

단기 SAS 사용 : SAS를 생성할 때 항상 임박한 만료 시간을 사용하고 필요할 때 클라이언트가 새 SAS URL을 요청하도록 합니다. Azure Storage에서는 모든 SAS URL에 대해 1시간 이하를 권장합니다.

SAS 토큰을 신중하게 처리 : SAS URL은 데이터에 대한 액세스 권한을 부여하며 애플리케이션 비밀로 처리되어야 합니다. SAS URL은 저장 계정에 접근이 필요한 클라이언트에게만 노출합니다.

해지 계획 수립 : 컨테이너 내에서 SAS 를 세분화하여 해지하려면 SAS 토큰을 저장 액세스 정책과 연결하세요 . SAS 또는 공유 키가 유출되면 저장 액세스 정책을 제거하거나 저장 계정 키를 회전시킬 준비를 하세요.

애플리케이션 모니터링 및 감사 : Azure Monitor 및 Azure Storage 로그를 활성화하여 스토리지 계정에 대한 요청이 인증되는 방식을 추적합니다. SAS 만료 정책을 사용하면 수명이 긴 SAS URL을 사용하는 클라이언트를 감지할 수 있습니다.

마이크로소프트의 사례에서 볼 수 있듯이 Github 소스코드 저장소와 같이 다수에게 공개된 장소에 Secret이 노출되어 있는 경우 내부 정보 유출의 타깃이 되기 쉽습니다. 특히 소스코드 저장소의 경우 노출의 위험이 쉽게 발생하는 장소이기도 합니다.

또한 소스코드 저장소뿐만 아니라 Secret은 내부 시스템, 협업 SaaS 솔루션 어디든지 노출되어 있고 이는 과도한 권한 상승으로 이어질 수 있습니다.Secret Detection : 이것을 막을 수 있는 최고의 방법은 실시간으로 Secret을 탐지하는 강력한 엔진이 필요하고 Secret-Driven Security를 강화해야 합니다. 소스코드 저장소에 토큰 공유, 전체 스토리지 계정을 공유하도록 토큰 설정, 높은 권한의 SAS 토큰 생성, 만료되지 않는 시간 설정 이 모든 것은 결국 사람의 실수에서 발생하고 실수를 줄이는 방법만으로는 한계가 있기 때문입니다.

한국 기업에 주는 시사점

해당 사건은 크레덴셜 노출과 자산 관리 사각지대가 결합되어 발생한 유형이다. 국내 기업은 개인정보보호법 제34조에 따라 유출 인지 시점부터 72시간 이내 개인정보보호위원회에 신고해야 하며, 1천 명 이상 유출 시 과징금 상한이 전체 매출액의 3%로 상향 적용된다. 또한 2027년부터 시행되는 ISMS-P 강화 인증기준은 「인증정보 관리」(2.5.4)를 별도 의무 항목으로 분리하여 크레덴셜 라이프사이클 전 구간의 통제 근거를 요구한다.

즉시 점검해볼 것

• 개인정보 처리 시스템에 하드코딩된 크레덴셜 유무 전수 점검
• 자산 인벤토리에서 누락된 도메인·저장소·서브도메인 존재 여부 확인
• 유출 사고 대응 시 72시간 신고 프로세스 및 책임자 지정 상태 점검
• ISMS-P 2.5.4 인증정보 관리 통제 근거 문서화 수준 재검토

관련 글

• Vercel 환경 변수 베스트 프랙티스: 시크릿 노출 방지 가이드 (실제 사례 포함)
• 바이비트 해킹 사건 분석: 암호화폐 거래소 보안, 어떻게 강화해야 할까요?
• tj-actions/changed-files 침해 사건 - NHI 보안을 중심으로

---

Argus로 NHI 보안 자동화

Cremit의 Argus는 공개·비공개 저장소의 노출된 크레덴셜을 상시 탐지하고, 팀별 소유권을 매핑하며, 회전 워크플로우를 자동화합니다. 14일 무료 체험: argus.cremit.io.