# S3 버킷스쿼팅이 (드디어) 사라졌다 > Clean Markdown view of GeekNews topic #27490. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27490](https://news.hada.io/topic?id=27490) - GeekNews Markdown: [https://news.hada.io/topic/27490.md](https://news.hada.io/topic/27490.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-03-14T14:21:17+09:00 - Updated: 2026-03-14T14:21:17+09:00 - Original source: [onecloudplease.com](https://onecloudplease.com/blog/bucketsquatting-is-finally-dead) - Points: 2 - Comments: 1 ## Topic Body - AWS가 **S3 버킷스쿼팅(bucketsquatting)** 문제를 해결하기 위한 새로운 **계정 기반 네임스페이스 보호 기능**을 도입함 - 새 네임스페이스는 `<prefix>-<accountid>-<region>-an` 형식으로, 동일한 계정만 해당 이름의 버킷을 생성할 수 있음 - 다른 계정이 동일한 이름을 사용하려 하면 **`InvalidBucketNamespace` 오류**가 발생하며, 잘못된 리전 지정 시에도 동일한 오류가 반환됨 - 이 네임스페이스는 **기본적으로 사용이 권장**되며, 조직 정책(SCP)에서 `s3:x-amz-bucket-namespace` 조건 키로 강제 적용 가능 - 기존 버킷에는 소급 적용되지 않지만, 새 버킷에는 강력한 보호를 제공해 **S3 보안 구조의 근본적 개선**을 의미함 --- ### Bucketsquatting 문제 개요 - **Bucketsquatting(또는 Bucketsniping)** 은 AWS S3에서 버킷 이름이 전역적으로 고유하다는 점을 악용하는 공격 형태 - 버킷이 삭제되면 이름이 다시 사용 가능해져, 공격자가 동일한 이름으로 새 버킷을 등록할 수 있음 - 이로 인해 민감한 데이터 접근이나 서비스 중단 위험이 발생할 수 있음 - 조직들이 흔히 `myapp-us-east-1`과 같은 **예측 가능한 네이밍 규칙**을 사용해 공격 노출 가능성이 높았음 - AWS 내부 팀도 이 문제의 영향을 받아, 약 10년간 AWS 보안팀과 협력해 해결 방안을 모색해 왔음 ### 새로운 S3 네임스페이스 도입 - AWS는 문제 해결을 위해 **계정별 네임스페이스(account namespace)** 개념을 도입 - 형식: `<prefix>-<accountid>-<region>-an` - 예시: `myapp-123456789012-us-west-2-an` - 이 네임스페이스는 해당 계정만 해당 이름의 버킷을 생성할 수 있도록 제한 - 다른 계정이 동일 이름을 생성하면 `InvalidBucketNamespace` 오류 발생 - 버킷 이름의 리전이 실제 리전과 불일치할 경우에도 동일 오류 반환 - AWS는 이 네임스페이스를 **모든 새 버킷에 기본적으로 사용할 것을 권장** - 기존 네임스페이스(`.mrap`, `--x-s3`, `-s3alias`)와 달리, 이번에는 **보안 목적의 일반 사용자용 네임스페이스**로 도입됨 ### 정책 적용 및 관리 - 보안 관리자는 `s3:x-amz-bucket-namespace` 조건 키를 사용해 **조직 전체 정책(SCP)** 으로 네임스페이스 사용을 강제할 수 있음 - 기존 버킷이나 네임스페이스 없는 템플릿에는 자동 적용되지 않음 - 기존 버킷을 보호하려면 새 네임스페이스 형식으로 버킷을 만들고 데이터를 마이그레이션해야 함 - 이 조치로 인해 버킷스쿼팅은 사실상 “사라지는 중”이며, 새 버킷에는 완전한 보호 제공 ### 다른 클라우드 제공업체의 접근 방식 - **Google Cloud Storage(GCS)** 는 이미 **도메인 이름 검증 기반 네임스페이스**를 사용 - `myapp.com`과 같은 도메인 형식 버킷은 도메인 소유자만 생성 가능 - 비도메인 형식 버킷에서는 여전히 버킷스쿼팅 가능성 존재 - **Azure Blob Storage**는 **스토리지 계정명 + 컨테이너명** 구조를 사용 - 최대 24자 제한으로 네임스페이스가 좁아, 동일한 문제에 더 취약할 수 있음 ### 결론 (tl;dr) - AWS S3에 **새로운 계정 리전 네임스페이스**가 도입됨 - 이 네임스페이스는 **버킷스쿼팅 공격을 방지**하며, 새 버킷 생성 시 반드시 사용하는 것이 권장됨 - 기존 버킷은 자동 보호되지 않으므로, 필요한 경우 **데이터 마이그레이션**을 통해 보호 강화 필요 ## Comments ### Comment 53004 - Author: neo - Created: 2026-03-14T14:21:17+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47361913) - 최근 AWS 계정 삭제 후에도 **루트 사용자 이메일 주소를 재사용할 수 없다는 사실**을 알게 되었음 우리 조직의 한 사람이 회사 메인 이메일로 폐쇄된 계정의 루트 사용자를 만들었고, 다른 이메일로 새 계정을 만들었는데 이제는 삭제 복구 기간도 지나버림 그 결과, 해당 이메일이 삭제된 루트 계정에 영구적으로 묶여 있어서 외부 IdP를 통한 **SSO 로그인이 불가능**해졌음 AWS 지원팀에 문의했지만 도움을 거의 받지 못했음 - 최근 고객 지원을 돕던 중, 이전 핵심 엔지니어가 퇴사하면서 **루트 계정의 MFA가 그의 휴대폰에 연결된 채로 남은 사례**를 겪었음 비밀번호는 문서화되어 있었지만 MFA를 해제할 방법이 없어 AWS 지원, 계정 담당자 등에게 문의했으나 해결 불가였음 결국 루트 계정 접근이 막혀 있고, 복잡한 환경을 통째로 새 계정으로 옮겨야 할지도 모르는 상황임 - 이메일 제공자가 지원한다면 **플러스 주소(plus addressing)** 를 활용할 수 있음 AWS는 플러스가 붙은 이메일을 별개의 주소로 인식함 - 루트 계정은 사람용으로 쓰지 말고, **비상용 특수 계정**으로 만들어 자격 증명을 안전하게 보관해야 함 정말 심각한 문제가 생겼을 때만 사용하는 것이 좋음 - 보안이란 게 얼마나 허무한지 새삼 느껴짐 결국 어떤 피셔가 고객 지원팀을 속여 **10점짜리 평가**를 받으면 모든 게 무너질 수도 있음 - IdP의 이메일을 역할(role)에 매핑하는 방식이라면 “삭제된 루트 계정에 영구적으로 묶였다”는 게 무슨 의미인지 궁금함 어떤 메커니즘이 실제로 사용을 막는지 알고 싶음 - Azure Blob Storage의 **account name** 개념을 저자가 잘못 이해한 듯함 사실상 S3의 버킷 이름과 동일한 수준이며, 전역적으로 고유해야 해서 여전히 큰 불편이 있음 특히 이름 길이가 24자 제한이라 더 답답함 Microsoft도 AWS처럼 **고객별 네임스페이스**를 도입하길 바람 - 약 10년 전 S3 팀에서도 이 문제를 인식하고 있었음 하지만 초기 설계의 제약 때문에 바꾸지 못했음 개인적으로는 왜 아직도 **S3 v2 API**를 만들지 않았는지 이해가 안 됨 새 API로 점진적 마이그레이션을 유도할 수도 있었을 텐데, 결국 고객과 엔지니어 모두 불필요한 고통을 겪고 있음 - 처음 Azure를 써봤을 때, 리소스들이 계정 단위로 네임스페이스되지 않는 걸 보고 정말 **이상한 설계**라고 느꼈음 - 글쓴이 본인이 직접 등장해, 피드백을 반영해 글을 업데이트했다고 밝힘 - 이름 제한이 24자뿐 아니라, **하이픈·언더스코어·점도 불가**해서 숫자와 소문자만 써야 하는 점이 너무 불편함 S3나 GCS처럼 대시라도 허용했으면 좋겠음 - 스토리지 계정 이름에 하이픈조차 못 쓰는 건 정말 **엉망인 설계**라고 생각함 컨테이너 레지스트리 등 다른 리소스도 마찬가지임 - 패키지명, 버킷명, GitHub 계정명 등은 Discord처럼 **@이름-랜덤4자리** 형식을 쓰면 어떨까 생각함 이렇게 하면 이름 공간을 민주화하고, **스쿼팅이나 재사용 공격**을 막을 수 있음 계정이 삭제되면 전체 이름을 폐기하면 되므로 깔끔함 - 하지만 Discord는 2년 전 이 형식을 **폐지하고 전역 고유 이름 체계로 전환**했음 이유는 [공식 공지](https://support.discord.com/hc/en-us/articles/12620128861463-New-Usernames-Display-Names)에 설명되어 있는데, 4자리 숫자를 기억해야 하고 대소문자 구분까지 해야 하는 불편함 때문이었음 - 개인적으로는 **UUID + petname 시스템**이 더 낫다고 생각함 특히 채팅 앱에서는 내부 ID를 쓰고, 사용자는 별칭만 쓰게 하는 게 깔끔함 버킷의 경우엔 사람이 읽기 쉬운 이름이 핵심이라, 차라리 **자신의 도메인**을 쓰는 게 낫다고 봄 - 버킷에는 괜찮지만, 패키지 하이재킹 방지에는 4자리 코드가 별 도움이 안 됨 오히려 **오타 위험**만 늘어남 - 그냥 **도메인 검증 기반 이름(@example.com)** 을 어디서나 쓸 수 있으면 좋겠음 - 나는 내부 도구를 만들 때 사용자에게 **불투명한 내부 ID**를 부여하고, 이름은 자유롭게 바꾸게 했음 온라인 커뮤니티에서 이름이 겹치는 게 자연스러운 일인데, 왜 굳이 전역 고유 이름을 강제하는지 의문임 - 글쓴이 Ian Mckay에게 감사함 AWS가 공식적으로 **계정·리전 단위 네임스페이스**를 도입한 건 좋은 변화임 Terraform 같은 IaC 도구들이 이 규칙을 기본값으로 채택하면 더 좋겠음 이미 Terraform은 버킷 이름 끝에 **랜덤 해시 접미사**를 붙여 충돌을 방지하고 있음 [AWS 공식 블로그](https://aws.amazon.com/blogs/aws/introducing-account-regional-namespaces-for-amazon-s3-general-purpose-buckets/)에도 관련 내용이 있음 - 클라우드 제공자들이 **예측 가능한 버킷 이름**을 내부 스크래치 공간에 쓸 때 생기는 **버킷 스쿼팅 공격**이 흥미로움 AWS에서는 해시 때문에 실제 공격은 어려웠지만, GCP는 최근에도 이런 문제를 겪었음 관련 발표: [DC32 AWS 버킷 스쿼팅 토크](https://www.youtube.com/watch?v=m9QVfYVJ7R8), GCP 취약점: [CVE-2026-1727](https://www.sentinelone.com/vulnerability-database/cve-2026-1727/) - 그 발표 정말 인상 깊었음 버킷 이름이 예측 가능하다는 걸 보는 순간 위험을 직감했음 **버킷 스쿼팅 + 공개 버킷 + CloudFormation의 TOCTOU 문제** 조합이면 충분히 다른 계정에 리소스를 배포할 수도 있었음 AWS 보안팀이 이걸 더 일찍 발견하지 못한 게 놀라움 - DNS 이름도 비슷한 문제를 가짐 도메인을 갱신하지 않으면 재등록이 가능해지고, 누군가 MX 레코드를 설정해 **비밀번호 재설정 메일** 등을 가로챌 수 있음 - 이런 방식으로 **레거시 IPv4 블록** 같은 자산을 되찾는 경우도 있음 - AWS 버킷은 여전히 **호스트명과 동일한 이름**일 때만 특수 기능을 제공함 관련 문서: [Virtual Hosting in S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/VirtualHosting.html) - 이름은 그것이 지칭하는 대상과 동일해서는 안 됨 이름이 재사용되면 전혀 다른 대상을 가리키게 되고, 그 의미는 문맥에 따라 달라짐 스스로 이름을 재할당할 때만 동일한 것으로 간주할 수 있음 - 계정 ID를 공개하는 게 보안상 위험한지 궁금했음 - AWS는 공식적으로 **계정 ID는 비밀 정보가 아니라고 명시**함 [공식 문서](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-identifiers.html)에 따르면, 신중히 다루되 민감 정보로 간주하지 않음 - 개인적인 의견으로는 이메일 주소처럼 **식별자이지 인증 수단은 아님** 너무 노출시키지만 않으면 괜찮음 - 위생적으로는 좋지 않지만, **계정 ID만으로는 공격 불가**임 IAM 규칙에서 공격자가 *를 쓸 수 있으므로, 결국 방어 측의 정책 설정이 중요함 - S3 서명 URL을 공유하면 그 안에 **Access Key ID**가 포함되어 있음 이를 base32로 디코딩하면 **Account ID를 추출**할 수 있음 참고: [관련 분석 글](https://medium.com/@TalBeerySec/a-short-note-on-aws-key-id-f88cc4317489) - S3가 **버킷 이름만을 접근 키로 사용**한 것은 설계상 가장 짜증나는 결정 중 하나였음