- 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に 新しいアカウント・リージョンネームスペース が導入された
- このネームスペースは バケットスクワッティング攻撃を防止 し、新規バケット作成時には必ず使うことが推奨される
- 既存バケットは自動では保護されないため、必要に応じて データ移行 による保護強化が必要
1件のコメント
Hacker Newsのコメント
最近、AWSアカウントを削除した後でも ルートユーザーのメールアドレスを再利用できない ことを知った
うちの組織のある人物が会社のメインメールで閉鎖済みアカウントのルートユーザーを作成し、別のメールで新しいアカウントを作ったのだが、今では削除復旧期間も過ぎてしまっている
その結果、そのメールアドレスは削除済みのルートアカウントに永久にひも付いたままで、外部IdP経由の SSOログインが不可能 になってしまった
AWSサポートに問い合わせたが、ほとんど助けてもらえなかった
パスワードは文書化されていたが、MFAを解除する方法がなく、AWSサポートやアカウント担当者などに問い合わせても解決できなかった
結局ルートアカウントへのアクセスは塞がれたままで、複雑な環境一式を新しいアカウントへ丸ごと移さなければならないかもしれない状況になっている
AWSはプラス付きのメールを別アドレスとして認識する
本当に重大な問題が起きたときだけ使うのがよい
結局、どこかのフィッシャーがカスタマーサポートをだまして 10点評価 をもらえれば、すべてが崩れるかもしれない
実際に何のメカニズムが利用を妨げているのか知りたい
Azure Blob Storageの account name という概念を著者は誤解しているようだ
実質的にはS3のバケット名と同レベルで、グローバルに一意でなければならず、依然として大きな不便がある
特に名前の長さが24文字に制限されているので、なおさら窮屈だ
MicrosoftもAWSのように 顧客ごとのネームスペース を導入してほしい
しかし初期設計の制約のため変更できなかった
個人的には、なぜいまだに S3 v2 API を作らないのか理解できない
新しいAPIで段階的な移行を促すこともできたはずなのに、結局は顧客もエンジニアも不要な苦痛を味わっている
数字と小文字しか使えないのがとても不便だ
S3やGCSのように、せめてダッシュくらいは許可してほしい
コンテナレジストリなどほかのリソースも同様だ
パッケージ名、バケット名、GitHubアカウント名などは、Discordのように @名前-ランダム4桁 形式を使えばどうだろうと思う
こうすれば名前空間を民主化でき、スクワッティングや再利用攻撃 を防げる
アカウントが削除されたら名前全体を廃棄すればよいので、すっきりしている
理由は 公式告知 に説明されているが、
4桁の数字を覚えなければならず、大文字小文字の区別まで必要で不便だったためだ
特にチャットアプリでは内部IDを使い、ユーザーには別名だけを使わせるのがすっきりしている
バケットの場合は人間が読みやすい名前が重要なので、むしろ 自分のドメイン を使うほうがよいと思う
むしろ タイプミスのリスク だけが増える
オンラインコミュニティで名前が重複するのは自然なことなのに、
なぜわざわざグローバル一意の名前を強制するのか疑問だ
投稿者のIan Mckayに感謝したい
AWSが公式に アカウント・リージョン単位のネームスペース を導入したのはよい変化だ
TerraformのようなIaCツールがこのルールをデフォルトとして採用すると、さらによいだろう
すでにTerraformはバケット名の末尾に ランダムなハッシュ接尾辞 を付けて衝突を防いでいる
AWS公式ブログにも関連内容がある
クラウドプロバイダが 予測可能なバケット名 を内部スクラッチ領域で使うときに生じる バケットスクワッティング攻撃 が興味深い
AWSではハッシュのため実際の攻撃は難しかったが、GCPは最近でもこうした問題を抱えていた
関連発表: DC32 AWSバケットスクワッティング講演,
GCP脆弱性: CVE-2026-1727
バケット名が予測可能だとわかった瞬間に危険を直感した
バケットスクワッティング + 公開バケット + CloudFormationのTOCTOU問題 の組み合わせなら、
十分に別アカウントへリソースをデプロイできたはずだ
AWSセキュリティチームがこれをもっと早く発見できなかったのは驚きだ
DNS名にも似た問題がある
ドメインを更新しなければ再登録可能になり、
誰かがMXレコードを設定して パスワード再設定メール などを横取りできる
AWSバケットは今でも ホスト名と同じ名前 のときにしか特殊機能を提供しない
関連文書: Virtual Hosting in S3
名前は、それが指し示す対象と同一であってはならない
名前が再利用されれば、まったく別の対象を指すことになり、
その意味は文脈によって変わる
自分で名前を再割り当てした場合にだけ、同じものと見なせる
アカウントIDを公開することがセキュリティ上危険なのか気になっていた
公式文書 によれば、
慎重に扱うべきではあるが、機密情報とは見なしていない
あまり露出させすぎなければ問題ない
IAMルールでは攻撃者が * を使えるので、結局は防御側のポリシー設定が重要だ
それをbase32でデコードすると Account IDを抽出 できる
参考: 関連分析記事
S3が バケット名だけをアクセスキーとして使った のは、設計上もっとも腹立たしい判断のひとつだった