▲

S3 버킷스쿼팅이 (드디어) 사라졌다

 (onecloudplease.com)
2P by GN⁺ 15시간전 | ★ favorite | 댓글 1개
  • 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에 새로운 계정 리전 네임스페이스가 도입됨
  • 이 네임스페이스는 버킷스쿼팅 공격을 방지하며, 새 버킷 생성 시 반드시 사용하는 것이 권장됨
  • 기존 버킷은 자동 보호되지 않으므로, 필요한 경우 데이터 마이그레이션을 통해 보호 강화 필요
▲
GN⁺ 15시간전  [-]
Hacker News 의견들

  • 최근 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년 전 이 형식을 폐지하고 전역 고유 이름 체계로 전환했음
      이유는 공식 공지에 설명되어 있는데,
      4자리 숫자를 기억해야 하고 대소문자 구분까지 해야 하는 불편함 때문이었음
    • 개인적으로는 UUID + petname 시스템이 더 낫다고 생각함
      특히 채팅 앱에서는 내부 ID를 쓰고, 사용자는 별칭만 쓰게 하는 게 깔끔함
      버킷의 경우엔 사람이 읽기 쉬운 이름이 핵심이라, 차라리 자신의 도메인을 쓰는 게 낫다고 봄
    • 버킷에는 괜찮지만, 패키지 하이재킹 방지에는 4자리 코드가 별 도움이 안 됨
      오히려 오타 위험만 늘어남
    • 그냥 도메인 검증 기반 이름(@example.com) 을 어디서나 쓸 수 있으면 좋겠음
    • 나는 내부 도구를 만들 때 사용자에게 불투명한 내부 ID를 부여하고, 이름은 자유롭게 바꾸게 했음
      온라인 커뮤니티에서 이름이 겹치는 게 자연스러운 일인데,
      왜 굳이 전역 고유 이름을 강제하는지 의문임

  • 글쓴이 Ian Mckay에게 감사함
    AWS가 공식적으로 계정·리전 단위 네임스페이스를 도입한 건 좋은 변화임
    Terraform 같은 IaC 도구들이 이 규칙을 기본값으로 채택하면 더 좋겠음
    이미 Terraform은 버킷 이름 끝에 랜덤 해시 접미사를 붙여 충돌을 방지하고 있음
    AWS 공식 블로그에도 관련 내용이 있음

  • 클라우드 제공자들이 예측 가능한 버킷 이름을 내부 스크래치 공간에 쓸 때 생기는 버킷 스쿼팅 공격이 흥미로움
    AWS에서는 해시 때문에 실제 공격은 어려웠지만, GCP는 최근에도 이런 문제를 겪었음
    관련 발표: DC32 AWS 버킷 스쿼팅 토크,
    GCP 취약점: CVE-2026-1727

    • 그 발표 정말 인상 깊었음
      버킷 이름이 예측 가능하다는 걸 보는 순간 위험을 직감했음
      버킷 스쿼팅 + 공개 버킷 + CloudFormation의 TOCTOU 문제 조합이면
      충분히 다른 계정에 리소스를 배포할 수도 있었음
      AWS 보안팀이 이걸 더 일찍 발견하지 못한 게 놀라움

  • DNS 이름도 비슷한 문제를 가짐
    도메인을 갱신하지 않으면 재등록이 가능해지고,
    누군가 MX 레코드를 설정해 비밀번호 재설정 메일 등을 가로챌 수 있음

    • 이런 방식으로 레거시 IPv4 블록 같은 자산을 되찾는 경우도 있음

  • AWS 버킷은 여전히 호스트명과 동일한 이름일 때만 특수 기능을 제공함
    관련 문서: Virtual Hosting in S3

  • 이름은 그것이 지칭하는 대상과 동일해서는 안 됨
    이름이 재사용되면 전혀 다른 대상을 가리키게 되고,
    그 의미는 문맥에 따라 달라짐
    스스로 이름을 재할당할 때만 동일한 것으로 간주할 수 있음

  • 계정 ID를 공개하는 게 보안상 위험한지 궁금했음

    • AWS는 공식적으로 계정 ID는 비밀 정보가 아니라고 명시함
      공식 문서에 따르면,
      신중히 다루되 민감 정보로 간주하지 않음
    • 개인적인 의견으로는 이메일 주소처럼 식별자이지 인증 수단은 아님
      너무 노출시키지만 않으면 괜찮음
    • 위생적으로는 좋지 않지만, 계정 ID만으로는 공격 불가임
      IAM 규칙에서 공격자가 *를 쓸 수 있으므로, 결국 방어 측의 정책 설정이 중요함
    • S3 서명 URL을 공유하면 그 안에 Access Key ID가 포함되어 있음
      이를 base32로 디코딩하면 Account ID를 추출할 수 있음
      참고: 관련 분석 글

  • S3가 버킷 이름만을 접근 키로 사용한 것은 설계상 가장 짜증나는 결정 중 하나였음

답변달기