ハクソク

世界を動かす技術を、日本語で。

バケツスクワットは（ついに）終わった

2026年3月13日原文(onecloudplease.com)

概要

  • AWS S3バケット名の乗っ取り（bucketsquatting）問題 に対する新しい公式対策の登場
  • 新しいネームスペース構文 によるバケット名保護の仕組み
  • 組織全体への適用や既存バケットの移行 に関する注意点
  • 他のクラウドプロバイダー（Google Cloud, Azure）との 比較と現状
  • 今後の推奨事項 と導入の重要性

AWS S3バケット名乗っ取り（Bucketsquatting）問題と新対策

  • Bucketsquatting（バケットスナイピング） は、削除されたS3バケット名が再利用可能になることで発生するセキュリティリスク
  • 予測しやすいバケット名（例：myapp-us-east-1）が攻撃者に悪用されやすい状況
  • AWS内部チームですら影響を受けていた問題
  • 長年にわたり AWS Security Outreachチーム と協力して解決策を模索

新しいネームスペース構文の導入

  • AWSが新たに バケット名ネームスペース 保護機能を提供
  • 新しいバケット名の構文： <prefix>-<accountid>-<region>-an
    • 例：myapp-123456789012-us-west-2-an
  • -an は「アカウントネームスペース（account namespace）」の略
  • この構文により、同じアカウント以外は同名バケットの作成不可
  • 他アカウントが同名で作成しようとすると InvalidBucketNamespaceエラー が発生
  • バケット名のリージョンと実際のリージョンが一致しない場合もエラー

ポリシーによる強制と運用

  • s3:x-amz-bucket-namespace という新しい条件キーで、組織全体にネームスペース利用を強制可能
    • OrganizationのSCPポリシー で一括適用
  • 既存バケットや古いテンプレートには 遡及適用されない 点に注意
  • 既存バケットを保護したい場合は、新構文で新規作成し、 データ移行 が必要

他クラウドプロバイダーとの比較

  • Google Cloud Storage ：バケット名にドメイン名形式（例：myapp.com）を使う場合は ドメイン所有権の検証 が必要
    • 非ドメイン形式ではbucketsquattingのリスクが残る
  • Azure Blob Storage ：ストレージアカウント名＋コンテナ名でスコープされるが、 アカウント名の最大24文字制限 でネームスペースが狭い

推奨事項と今後

  • 新ネームスペース構文の利用がデフォルト推奨
  • セキュリティ管理者は 組織全体での適用ポリシー設定 を検討
  • 既存バケットの移行も視野に入れた運用体制の見直し
  • 他クラウド利用時も、 固有性や所有権検証の仕組み を活用したバケット名管理が重要
  • 詳細や質問は LinkedIn や 𝕏 で連絡推奨

Hackerたちの意見

Azure Blob Storageでは、ストレージアカウントはアカウント名とコンテナ名でスコープが設定されているから、あまり心配する必要はないよね。著者はおそらく、Azure Storageの文脈での「アカウント名」が何かを誤解していると思う。これはS3のバケット名にほぼ相当するもので、確かに大きな問題だよ。全ての顧客に対してユニークなストレージアカウント名のプールがあるのは、特に24文字という短い名前制限があるから、すごくストレスの元になってる。Microsoftも同じように、顧客ごとにユニークなネームスペースを導入してくれるといいな。

└

初めてAzureを使ったとき、リソースがアカウントレベルで名前空間を持ってないことに衝撃を受けたのを覚えてる。これがv1の問題じゃなかったのが不思議だわ。

└

著者です。指摘ありがとう！記事を更新して、クレジットを追加しました。

└

特に、たった24文字の短い名前制限があるからね。そして、意味のある区切り文字もない！ダッシュ、アンダースコア、ドットもなし。数字と小文字のアルファベットだけ。少なくともS3とGCSはダッシュを許可してるから、ちょっとした組織のプレフィックスを付けたりして、完全に意味不明にはならないよね。

└

私が10年前にいたとき、S3はその痛みをよく理解してたけど、クラウドのアイデアがほんの数人の目にちらつく前に決定されたことに手を縛られてると考えてた。こんなスケールの運用が現実的だとは思われてなかったからね。名前空間の問題は、S3エンジニアが変えたいと思ってる長いリストの一つで、HTTPステータスコードの動作なども含まれてる。S3がv2 APIを持たない決意を理解したことはない。確かに、V1は長い間残ってなきゃいけないけど、移行を促す方法はいくらでもある。例えば、将来の価値追加をV2に集中させたり、レガシーAPIの維持にかかる開発作業をカバーするためにv1 APIのコストを少しずつ上げたりすることができる。でも、結局彼らは自分たちと顧客が避けられる痛みを抱えることになっちゃった。

Ian Mckayさん、ありがとう！これは、バケット名を考えたり心配したりしなくて済む、良い慣習の一つだね。記事にもあるように、AWSはこれを公式な命名規則の一部にしているみたいだし。[1] IaCのコードライブラリ、特にTerraformがこれをデフォルトの挙動として取り入れるのが楽しみ！Terraformや他のツールのデフォルトの挙動は、エラーを防ぐためにバケット名の末尾にランダムなハッシュサフィックスを追加することだから、これが標準的なやり方になれば、他の人に自動化前にこういう戦略を使うよう説得する手間が省けて、何日も助かってる。[1] https://aws.amazon.com/blogs/aws/introducing-account-regiona...

パッケージ名やバケット名、GitHubアカウント名なんかも、ディスコードみたいな命名規則を使った方がいいんじゃないかと思うことがある。例えば、@sometag-xxxxみたいに、xxxxはランダムな4桁のコード。これはUUIDのアカウント名と完全に人間が生成した名前の中間的なものだよ。このアプローチはネームスペースの民主化に大いに役立つ。誰もそのタグのプレフィックスを「所有」できないからね。（10000人がそれを共有できる）。これを使えば、スコッティングや再利用攻撃を防ぐこともできるし、対応するユーザーアカウントがシャットダウンされたら、フルアカウント名を消しちゃえばいい。早期のユーザーが良い名前を全部取っちゃうのも防げるし。

└

確認済みのドメインをどこでも使えるようにしたいな；@example.comみたいに。

└

バケットにはいいと思うけど、4桁のコードを追加してもパッケージハイジャックの問題には役立たないかも。むしろ、タイプミスやハイジャックの可能性を増やすだけかもしれない。結局、また4文字タイプミスするだけだし。

└

ちなみに、ディスコードは2年前にその形式をやめて、グローバルにユニークなユーザー名に移行したんだ。彼らがそうした理由は、> 「これにより、異なるディスクリミネーターや異なる大文字小文字があれば、他の誰かと同じユーザー名を持つことができるからです。」でも、これって友達とつながるために4桁の番号を覚えなきゃいけないし、大文字小文字の区別も考慮しなきゃいけないってことでもあるよね。[1]: https://support.discord.com/hc/en-us/articles/12620128861463...

└

個人的には、チャットアプリに関してはUUIDとペットネームシステムがいい解決策だと思う。バケットに関しては、使いやすい名前がほとんどの場合の重要な特徴だと思ったけど、じゃあランダムに生成された使い捨ての名前を割り当てればいいじゃん？でも、アカウント名を含む名前空間を追加するって、扱いにくい数字のIDになるのが理解できない。バケットの場合、自分のドメインを使う方がいいんじゃない？

└

.NLのgTLDは、個人登録（つまり、ビジネス登録のない個人）に対してそんな感じで機能してたんだよね。$name.NNN.nlみたいに、好きな番号を選べたんだ。でも、その仕組みは全然普及しなくて、今は廃止されちゃった（今は個人でも利用可能なドメインを登録できるしね）。多分、個人用のTLDを使う人は少ないけど、SNSで名前を使う人は多いってことだね。

Hacker Newsで議論の続きを見る