---
title: "비밀번호 없이 열린 클라우드 버킷 53만 개, 파일 196억 개가 밖에서 보였다"
published: 2026-05-28T11:05:06.164Z
canonical: https://jeff.news/article/3342
---
# 비밀번호 없이 열린 클라우드 버킷 53만 개, 파일 196억 개가 밖에서 보였다

전 세계 주요 클라우드 저장소에서 비밀번호 없이 접근 가능한 버킷 53만5,480개와 파일 196억 개가 확인됐다. 특히 .env, 개인키, 데이터베이스 백업처럼 공격자가 바로 악용할 수 있는 파일이 대량으로 노출돼, 문제의 본질이 해킹보다 권한 설정 실수에 가깝다는 점이 드러났다.

- 클라우드 저장소 사고가 또 나왔는데, 이번엔 규모가 꽤 세다
  - 미스테리움 VPN이 2026년 3월 기준 주요 클라우드의 공개 버킷 53만5,480개를 조사했더니, 외부에서 접근 가능한 파일이 196억 개로 집계됨
  - 대상은 아마존 S3, 구글 클라우드, 마이크로소프트 애저, 디지털오션, 알리바바 클라우드였음
  - 공격자가 취약점을 뚫은 게 아니라, 인터넷 주소만 알면 파일 목록을 볼 수 있는 공개 설정이 문제였다는 게 포인트임

- 제일 위험한 건 자격증명 파일이 그대로 보였다는 점임
  - .env 파일, 개인키, 비밀번호 저장소 파일 같은 자격증명류가 68만5,047개 발견됨
  - .env에는 데이터베이스 비밀번호, API 키, 인증 토큰이 들어가는 경우가 많아서, 사실상 다음 침투를 위한 열쇠가 될 수 있음
  - 개인키나 비밀번호 저장소 파일은 말 그대로 시스템 접근 권한을 열어주는 물건이라, 공개 버킷에 있으면 답이 없음

> [!WARNING]
> 이건 침입 없는 침해에 가까움. 서버를 뚫지 않아도 공개 버킷에서 .env와 백업을 줍는 순간, 공격자는 내부 시스템으로 갈 수 있는 지도를 얻는 셈임.

- 데이터베이스 백업도 대량으로 노출돼 있었음
  - .sql 파일은 98만5,645개, .bak 파일은 73만3,040개가 공개 상태로 확인됨
  - 운영 데이터베이스는 로그인, 권한, 네트워크 제한이라도 걸려 있지만, 백업 파일이 공개 버킷에 있으면 그런 보호막이 사라짐
  - 공격자는 백업을 내려받은 뒤 오프라인에서 천천히 분석할 수 있어서 방어자 입장에선 더 골치 아픔

- 파일명만 봐도 민감정보 냄새가 진하게 났음
  - secret이 들어간 파일은 76만4,015개, salary는 25만563개, kyc는 19만5,475개, credentials는 12만4,967개였음
  - password, passport, invoice, backup이 들어간 파일은 각각 100만 개 이상으로 집계됨
  - 고객 신원확인 자료, 여권, 급여, 청구서, 백업 파일이 공개 저장소에 섞여 있을 가능성을 보여주는 숫자임

- AWS S3가 가장 많이 보였지만, 이걸 S3만의 취약점으로 보면 오독임
  - 공개 저장소의 3분의 2 이상이 S3에 있었음
  - 다만 S3는 전 세계 사용량이 워낙 크고, 기본적으로 새 버킷과 객체를 비공개로 만드는 구조를 제공함
  - 결국 사용자가 정책이나 권한을 바꾸는 운영 과정에서 예외 설정이 쌓이고, 그게 통제되지 않는 게 문제임

- 구글 클라우드와 애저도 공개 접근 차단 기능은 이미 갖고 있음
  - 구글 클라우드는 공개 접근 방지 설정으로 익명 사용자 권한 부여를 제한할 수 있음
  - 애저 스토리지도 기본적으로 익명 접근을 허용하지 않고, 사용자가 명시적으로 열어야 공개 읽기가 가능함
  - 그러니까 보안 기능 부재가 아니라, 예외 권한과 운영 점검이 무너지는 전형적인 클라우드 보안 문제임

- 실무적으로는 공개 접근을 예외로 다뤄야 함
  - 버킷은 기본 비공개로 두고, 공개가 필요하면 목적과 기간을 정해야 함
  - .env, 개인키, API 토큰, 비밀번호 파일은 객체 저장소에 올리지 않는 게 원칙임
  - 백업 파일은 암호화하고, 접근 권한을 최소화하고, 외부에서 로그인 없이 목록 조회가 되는지 주기적으로 직접 확인해야 함

---

## 기술 맥락

- 이번 문제의 핵심은 클라우드 저장소가 해킹당했다는 게 아니라, 객체 저장소의 공개 권한이 운영 중에 풀렸다는 점이에요. S3, 애저 스토리지, 구글 클라우드 스토리지 모두 비공개 기본값과 차단 기능을 제공하지만, 실제 서비스 운영에서는 임시 공유, 배포 자동화, 백업 스크립트 때문에 예외가 계속 생기거든요.

- .env와 데이터베이스 백업이 특히 위험한 이유는 둘이 연결될 때 공격 난도가 확 내려가기 때문이에요. .env에서 접속 정보를 얻고, 같은 버킷에서 .sql이나 .bak을 찾으면 운영 DB를 직접 때리지 않아도 데이터 구조와 민감정보를 분석할 수 있어요.

- 그래서 대응도 단순히 버킷을 닫자로 끝나면 부족해요. 공개 가능한 버킷을 별도 목록으로 관리하고, IAM 정책, 버킷 정책, 접근제어목록을 정기적으로 비교해야 해요. 여기에 비밀정보 스캔과 백업 암호화를 붙여야 설정 실수 하나가 전체 침해로 번지는 걸 막을 수 있어요.

## 핵심 포인트

- 공개 접근 가능한 클라우드 버킷 53만5,480개에서 파일 196억 개가 확인됨
- 자격증명 파일 68만5,047개, .sql 백업 98만5,645개, .bak 백업 73만3,040개가 공개 상태로 발견됨
- AWS S3 비중이 3분의 2 이상이었지만, 이는 서비스 자체 취약점보다 사용량과 설정 실수 규모의 문제로 봐야 함
- 공개 접근은 기본값이 아니라 목적과 기간이 있는 예외로 관리해야 함

## 인사이트

이번 건은 고급 공격 기술보다 운영 기본기가 더 무섭다는 걸 보여주는 사례다. 버킷 하나 공개로 끝나는 게 아니라, .env와 백업이 같이 노출되면 내부 시스템 접근과 개인정보 유출까지 한 번에 이어질 수 있음.