AWS S3バケットスクワッティングにAmazonが最終対策

10年以上にわたりクラウドセキュリティの懸念材料だった「バケットスクワッティング」が、ついに終わりを迎えた——AWSがS3バケットの名前空間に根本的な保護機能を導入し、この古典的な攻撃手法を無効化しました。

バケットスクワッティングとは、攻撃者がAWS S3のバケット名を先取り（スクワッティング）し、正規ユーザーのデータを傍受したりマルウェアを配布したりする攻撃手法です。2024年にはセキュリティ研究者のIan McKayが、AWSの公式ツール自体がこの脆弱性の影響を受ける可能性があることを実証し、業界に衝撃を与えました。Fortune 500企業の推定30%以上がバケットスクワッティングのリスクにさらされていたとする調査もあり、クラウドセキュリティにおける最大の「設計上の欠陥」の一つとされてきました。

バケットスクワッティングとは何か

バケットスクワッティング（Bucket Squatting）は、ドメインスクワッティング（他人のドメイン名を先取りする行為）のクラウドストレージ版です。AWS S3では、バケット名がグローバルに一意である必要があります。つまり、世界中のAWSユーザーの中で同じバケット名は一つしか存在できません。

この仕様を悪用するのがバケットスクワッティングです。攻撃者は以下のような手口で攻撃を行います。

この図は、バケットスクワッティング攻撃の4ステップのフローと、AWSが導入した3つの対策を示しています。

攻撃の具体的なステップを詳しく見ていきましょう。

ステップ1: バケット名の推測

企業が使用するS3バケット名には予測可能なパターンがあります。たとえば company-name-logs-prod、company-name-backups-us-east-1、company-name-data-pipeline といった命名規則が一般的です。攻撃者はこのパターンを分析し、まだ作成されていないバケット名を推測します。

特に危険だったのは、AWSの公式サービスやツールが予測可能なバケット名を自動生成するケースです。CloudFormation、Elastic Beanstalk、SageMakerなどのサービスが特定のパターンでバケットを作成するため、攻撃者は新しいリージョンやサービスの展開を先回りしてバケット名を確保できました。

ステップ2: 先取りバケットの作成

推測したバケット名で、攻撃者が自分のAWSアカウントにバケットを作成します。S3バケットの作成は数秒で完了し、コストもほぼゼロです。攻撃者は数百〜数千のバケット名を一括で確保することも可能でした。

ステップ3: データの傍受

正規のユーザーやシステムが同じバケット名にデータを送信しようとすると、攻撃者のバケットにデータが届いてしまいます。ログファイル、設定ファイル、バックアップデータ、場合によってはAPIキーや認証情報まで漏洩するリスクがありました。

ステップ4: さらなる攻撃

傍受したデータの中にある認証情報を使ってシステムに侵入したり、正規のバケットに見せかけてマルウェアを配布したりする二次攻撃も行われていました。

過去のインシデントと被害規模

バケットスクワッティングは理論上の脅威にとどまらず、実際に深刻なインシデントを引き起こしてきました。

2024年 AWS公式ツール問題: セキュリティ研究者のIan McKayが、AWSのCloudFormationテンプレートや公式ドキュメントに記載されているサンプルバケット名を先取りすることで、AWSの公式ツールを利用しているユーザーのデータを傍受できることを実証しました。この発見は「AWSの設計そのものに脆弱性がある」として大きな議論を呼びました。

サプライチェーン攻撃への発展: オープンソースのデプロイツールやCI/CDパイプラインが特定のS3バケット名をハードコードしているケースも発見されました。攻撃者がこれらのバケット名を先取りすると、ビルドアーティファクトやデプロイパッケージを改ざんするサプライチェーン攻撃が可能になります。

推定被害規模: セキュリティ企業Aqua Securityの2025年レポートによると、スキャン対象の企業環境の約**35%**で予測可能なバケット名パターンが使用されており、バケットスクワッティングのリスクにさらされていました。

AWSの最終対策 — 何が変わったのか

AWSは2026年初頭にかけて、バケットスクワッティングを根本的に無効化する複数の対策を段階的に導入しました。

対策項目	内容	効果
バケット所有権検証	バケット作成時にAWSアカウントIDとの紐付けを強制	他人のアカウント向けバケット名の先取りを防止
名前空間の保護	組織IDベースの予約済みプレフィックス制度を導入	企業名を含むバケット名の不正取得を排除
削除後の再利用制限	バケット削除後、一定期間は同一名での再作成を制限	削除→先取りの攻撃パターンを封じる
予測可能な名前の廃止	AWSサービスが生成するバケット名にランダム要素を追加	公式ツール経由の攻撃経路を遮断
バケットポリシーの強化	デフォルトでパブリックアクセスを完全ブロック	設定ミスによる情報漏洩リスクを低減

特に重要なのは名前空間の保護です。AWS Organizationsに登録している組織は、自社の組織IDに基づくプレフィックスを予約できるようになりました。たとえば組織ID o-abc123 を持つ企業は、o-abc123- で始まるバケット名を独占的に使用でき、第三者による先取りは不可能になります。

クラウドプロバイダー別のセキュリティ比較

バケットスクワッティングはAWS S3に固有の問題でしたが、クラウドストレージのセキュリティはプロバイダーによって設計思想が異なります。

この図は、AWS S3、Google Cloud Storage、Azure Blob Storageそれぞれのセキュリティ対策チェックリストを比較しています。

各プロバイダーの設計の違いを確認しましょう。

比較項目	AWS S3	Google Cloud Storage	Azure Blob Storage
名前空間	グローバル一意（対策済み）	プロジェクト紐付け	サブスクリプション紐付け
スクワッティングリスク	対策により解消	設計上低い	設計上低い
デフォルト暗号化	SSE-S3（AES-256）	AES-256	AES-256
アクセス制御	バケットポリシー + IAM	IAM + ACL	RBAC + ACL
ネットワーク制御	VPCエンドポイント	VPC Service Controls	プライベートエンドポイント
監査ログ	CloudTrail	Cloud Audit Logs	Azure Monitor
脅威検出	GuardDuty for S3	Security Command Center	Defender for Storage
料金（1TBストレージ/月）	約$23（約3,450円）	約$20（約3,000円）	約$21（約3,150円）

Google Cloud StorageとAzure Blob Storageは、バケット（コンテナ）がプロジェクトやサブスクリプションに紐付けられるため、バケットスクワッティングのリスクは設計上低くなっています。一方、AWS S3のグローバル一意名前空間は、サービス間の連携やCDN設定のシンプルさというメリットがありましたが、セキュリティ上の弱点でもありました。今回の対策により、AWSはこのトレードオフを解消したと言えます。

クラウドストレージのセキュリティベストプラクティス

バケットスクワッティング対策が完了した今でも、クラウドストレージのセキュリティは多層的に考える必要があります。

1. 最小権限の原則を徹底する: バケットポリシーやIAMロールは「必要最小限のアクセス権限」のみを付与します。s3:* のようなワイルドカード権限は絶対に避け、s3:GetObject、s3:PutObject など具体的なアクションを指定しましょう。

2. パブリックアクセスブロックを有効化する: AWSのS3 Block Public Access機能は、アカウントレベルとバケットレベルの両方で有効化します。2023年以降に作成されたバケットではデフォルトで有効ですが、古いバケットは手動での設定が必要です。

3. 暗号化を必須にする: サーバー側暗号化（SSE-S3またはSSE-KMS）をバケットポリシーで強制します。転送中のデータにはTLS（HTTPS）を必須とし、HTTP経由のアクセスは拒否する設定にしましょう。

4. バージョニングとMFA Deleteを有効化する: オブジェクトのバージョニングを有効にすることで、誤削除や不正な上書きからデータを保護できます。さらにMFA Delete を設定すると、オブジェクトの完全削除にMFA認証が必要になります。

5. 監査ログを分析する: CloudTrailやAccess Loggingを有効にし、不審なアクセスパターンを定期的に分析します。GuardDuty for S3を有効にすると、異常なアクセスパターンを自動的に検出・通知してくれます。

日本企業への影響と対応

バケットスクワッティングの終焉は、日本企業のクラウドセキュリティにとっても重要な節目です。

AWSシェアの高い日本市場: 日本のパブリッククラウド市場においてAWSのシェアは依然として最大で、MM総研の2025年調査では約**30%**を占めています。S3は最も広く利用されているサービスの一つであり、バケットスクワッティング対策の恩恵を受ける企業は多数に上ります。

既存バケットの監査が急務: 新規バケットは自動的に保護されますが、既存のバケットについては設定の見直しが必要です。特に以下の点を確認すべきです。

• バケット名に組織名や推測可能なパターンが含まれていないか
• 古いバケットのパブリックアクセスブロックが有効になっているか
• CloudFormationテンプレート内にハードコードされたバケット名がないか
• CI/CDパイプラインが予測可能なバケット名を使用していないか

金融庁のクラウドガイドラインとの関連: 金融庁が2025年に改訂した「金融機関におけるクラウド利用に関するリスク管理基準」では、クラウドストレージの設定ミスに起因するデータ漏洩が重点的に取り上げられています。バケットスクワッティング対策は、このガイドラインへの準拠においても重要な要素となります。

マルチクラウド戦略の推進材料: 今回の事例は「単一クラウドプロバイダーへの依存リスク」を改めて浮き彫りにしました。AWSとGoogle Cloudを併用するマルチクラウド戦略は、セキュリティリスクの分散という観点からも合理的です。

まとめ — 今日から始めるアクションステップ

バケットスクワッティングの脅威は終わりましたが、クラウドセキュリティの取り組みは継続的に行う必要があります。

1. 既存S3バケットの総点検を行う: AWSマネジメントコンソールまたはAWS CLIを使い、全S3バケットのアクセス設定・暗号化設定・パブリックアクセスブロックの状態を確認します。AWS Config Rulesを使えば、非準拠のバケットを自動検出できます
2. 新しい名前空間保護を適用する: AWS Organizationsの組織IDベースのプレフィックス予約を設定し、自社のバケット名前空間を保護します。新規バケットは予約済みプレフィックスで統一する命名規則を策定しましょう
3. セキュリティ監視を自動化する: GuardDuty for S3、AWS Security Hub、CloudTrailを組み合わせたセキュリティ監視パイプラインを構築します。Slackやメールへの自動通知を設定し、異常を即座に検知できる体制を整えましょう
4. クラウドセキュリティの教育を実施する: 開発チームに対して、S3バケットの安全な設定方法・命名規則・アクセス制御のベストプラクティスについてのトレーニングを実施します。特にIaCテンプレート内でのバケット名のハードコードを禁止するルールを徹底しましょう

バケットスクワッティングという「クラウドの原罪」が解消された今、次に求められるのは各組織における地道なセキュリティ運用の徹底です。攻撃手法は常に進化しますが、基本に忠実な多層防御こそが最も確実な守りになります。