ハクソク

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

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

47日前原文(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で名前を使う人は多いってことだね。
AWS内のユニークな名前についてだけど、最近知ったことがあるんだ。AWSアカウントを削除した後、ルートユーザーのメールアドレスは再利用できないんだって（文書化されてるけど、知らなかった）。うちの組織の誰かが、閉じたアカウントのルートユーザーにメインの会社のメールアドレスを使って、現在のアカウントには別の会社のメールアドレスを使ってたんだ。もうAWSがアカウントの削除を元に戻す期間は過ぎちゃった。これで、彼は外部のIdPを通じてSSOを使うことができなくなった。使うメールアドレスが削除されたAWSアカウントのルートユーザーに永遠に結びついてるから！AWSサポートは助けを提供するのがかなりひどかった。
└
彼らには良かったね。フィッシャーからのサポートに10/10の評価を受けるだけで、ほとんどのセキュリティがどれだけ無意味かって、すごいよね。
└
会社とメールアドレスが変わらないのにAWSアカウントを削除する理由がわからないんだけど、動機が見えない。逆に、メールアドレスを再利用できないのは合理的なセキュリティの立場だと思う。メールアドレスは不変だから、1つのアイデンティティに制限するのは理にかなってる。もちろん、このユーザーにはかなりイライラするだろうけど、私にはちょっと馬鹿げてるように思える。
└
メールプロバイダーがサポートしていれば、プラスアドレスを使うことができるよ。AWSはプラスアドレス付きのルートメールをユニークなものと見なしてる。
└
AWSのサポート、ちょっと苦戦してるみたい。前の主要エンジニアとの別れがうまくいかなかった新しい顧客を手伝いに来たんだけど、ルートアカウントのパスワードは記録されてたけど、MFAが彼の電話に行っちゃってるんだ。話せる人にはみんな話して、チケット開いたり、チャットしたり、担当のアカウント代表に連絡しようとしたけど、誰もMFAを解除できない。今のところ他の管理アカウントがあるから助かってるけど、ルートアカウントには全然アクセスできない状態。全環境をリセットして新しいアカウントを作らなきゃいけないかも。複雑でしっかりしたAWSアカウントがあるのに、これはかなりダサいよね。
└
これはGDPR違反になる予感がする。あんな風にメールアドレスを永遠に保存するのは、コンプライアンス的に無理だと思うんだけど。
└
逆だと思ってた。異なるパスワードさえあれば、同じユーザー名で複数のアカウントを持てるんじゃないの？
本当に面白いバケットスコッティング攻撃は、クラウドプロバイダー自身が「スクラッチスペース」バケットに決定論的な名前を使うときだね。DC32でAWSについての良いトークがあったけど、実際のスコッティングは研究者が逆算できないハッシュがあったから難しかった（でも、特定のアカウントに対しては一貫してた）：https://www.youtube.com/watch?v=m9QVfYVJ7R8 ただ、GCPはプロジェクトIDに依存しすぎて、最近の2月にも何度もこれを自分たちでやっちゃったね：https://www.sentinelone.com/vulnerability-database/cve-2026-...
AWSのバケットは、バケット名がホスト名と一致する場合にだけ特別な機能を提供してるよ。 https://docs.aws.amazon.com/AmazonS3/latest/userguide/Virtua...
なんでこれが名前のサフィックスになってるの？サブドメインを使えばいいのに。myapp-123456789012-us-west-2-anとmyapp.123456789012.us-west-2.s3.amazonaws.com。63文字の制限に合わせるためにやらなきゃいけない操作がめっちゃ面倒なんだけど。
ちょっと理解できてないかも。他の誰かがそのバケット名を主張できるのが何が問題なの？もし削除されたら、データも削除されるんじゃないの？それとも何か見落としてることがあるのかな。
└
バケットに悪意のあるデータを入れて、削除されたバケットを「なりすます」ことができると思う。そうすると、古いコードがそのバケットを参照してもエラーを出さずに自分のデータを使うことになるんじゃないかな（？）。
-anサフィックスのアプローチは、名前自体にアイデンティティを埋め込むことで、単に作成を制限するだけじゃないから、なかなか賢いよね。昔の問題は、アイデンティティが結びついていない状態でのグローバルユニークさが足元をすくう原因になってたこと。名前空間は共有されてるけど、責任が伴わないっていう。面白いのは、後方互換性の視点だね。既存のバケット命名規則はそのまま使えるし、新しい規則に従うことで名前空間に参加できるんだ。GCSと比べると、GCSもグローバルユニークだけど、最初から組織レベルのポリシーがしっかり組み込まれてるし、Azureではストレージアカウントがサブドメイン名空間（accountname.blob.core.windows.net）を使っていて、似たような保護を実現してるけど、全く違うアーキテクチャのレイヤーでやってるんだよね。ちょっと気になるのは、世の中にある公開S3バケットの中で、予測可能なパターンで名付けられてるものがどれだけあって、それが削除されたのを見て登録される危険があるかってこと。
まだ一つ名前を変えるのに1時間くらいかかるの？