セキュリティ研究組織 Unit 42 が、「バケットハイジャック」と名付けたクラウドストレージの攻撃手法を公表した。
本稿が参照する報道は2026年6月27日付である。これは攻撃者が組織の稼働中のデータストリームを、攻撃者の管理下にある外部バケットへ転送する手法である。Google Cloud、Amazon Web Services（AWS）、Microsoft Azure の3社で影響が確認され、責任ある情報開示を通じて各社へ通知された。クラウドのバケット名がグローバルに一意である点を突き、攻撃者は対象のバケットを削除し、同名のバケットを自身のアカウントで再作成する。
Google Cloud では Storage Admin ロールが storage.buckets.delete を付与する。現時点で実際の悪用は確認されていない。Unit 42 は削除権限の限定やデータ境界制御などの防御策を推奨した。
From: New Bucket Hijacking Attack Allows Hackers to Reroute Cloud Data Streams to External Storage
【編集部解説】
「バケットハイジャック」と聞くと派手なゼロデイ攻撃を想像しますが、この手法の本質はむしろ逆です。これはソフトウェアの欠陥（バグ）ではなく、クラウドという仕組みそのものの「設計思想」に根ざした問題だという点を、まず押さえておく必要があります。
そもそもクラウドストレージの「バケット名」は、プロバイダー全体で世界に一つしか存在できません。この一意性は、データの送り先を「名前」だけで簡単に指定できる利便性を生みました。しかし裏を返せば、送り先の正体が「誰のものか（アカウント所有者）」ではなく「名前」だけで決まってしまう。攻撃者は元のバケットを削除し、同じ名前のバケットを自分のアカウントで作り直すだけで、流れ込むデータを丸ごと横取りできてしまうわけです。
この攻撃が真に厄介なのは、その「静けさ」にあります。乗っ取りが完了しても、元の設定画面は正常に見え続け、エラーも警告も出ません。監査ログやテレメトリといった「組織の目」そのものが、気づかれないまま攻撃者の手元へ流れ続ける——検知の難しさこそが、研究者が最も警告している点です。
ここで読者の皆さんに正確にお伝えしたい点があります。この研究を発表したのは、Palo Alto Networks 傘下の脅威研究組織 Unit 42 です。一次情報であるレポートの公開日は2026年6月22日、執筆者はヤハブ・フェスティンガー氏。今回ご依頼の元記事（6月27日付）が引用する内容は概ね正確ですが、いくつか補足が必要な点があります。
まず「現実の悪用は未確認」という点。これは複数の媒体で一致しており、あくまで研究者による概念実証（PoC）の段階です。過度に「今すぐ危険」と煽るのは正確ではありません。一方で、攻撃シナリオは権限昇格だけでなく、バケット削除後に経路設定（ルーター）が残ってしまう「ダングリング（取り残された）リソース」という二つ目の経路も指摘されています。元記事はこの2つ目に触れていませんが、運用ミスから生じうる現実的なリスクとして見逃せません。
影響範囲については、3社が等しく危険というわけではない点も押さえておきたいところです。AWS と Google Cloud では深刻度が高い一方、Azure は名前の即時再利用に制限があるため、攻撃は同一テナント内の「サブスクリプション横断」に限定されます。同じ設計思想を共有しつつも、各社の実装の違いがリスクの大きさを左右しているわけです。
そして最も重要な訂正点です。元記事は「3社すべてに通知した」と現在進行形のニュアンスで報じていますが、一次情報では既に対策が動き始めていることが明記されています。具体的には、Google は調査時点以降、ルーターリソースとストレージの連携方法を調整済み。Microsoft は Azure 利用者に対し、サブドメイン乗っ取りにつながる「取り残されたDNS（ダングリングDNS）」への対処法を解説したドキュメントやツールの確認を推奨しています。つまり「脆弱性が放置されている」のではなく、「設計思想に起因する構造的リスクとして開示され、緩和が進行中」というのが実態に近い理解です。
技術的な核心は「権限の不整合」にあります。Google Cloud の標準的な Storage Admin ロールは storage.buckets.delete を含みますが、ログの送り先を正規に変更する logging.sinks.update は含みません。つまり「設定を変える権限がない人物でも、削除権限さえあればデータの流れを変えられてしまう」という、権限設計のねじれが攻撃を成立させているのです。
長期的な視点で見ると、この研究の真価は個別の攻撃手法そのものより、「クラウド横断的な脆弱性」という概念の提示にあります。Google Cloud、AWS、Azure は別々のエコシステムとして管理されがちですが、設計思想が似ているがゆえに、一つのプラットフォームで見つかった欠陥が他社攻撃の「青写真（設計図）」になりうる。マルチクラウドが当たり前になった今、セキュリティチームは「ベンダーごと」ではなく「クラウド非依存（cloud-agnostic）」の視点を持つべきだ——研究者のこの結論は、業界全体への問題提起と言えるでしょう。
規制やガバナンスへの示唆も小さくありません。監査ログが攻撃者に横取りされうるという事実は、コンプライアンスの根幹を揺るがします。GDPR や各種規制が「ログの完全性」を前提にしている以上、最小権限の徹底とデータ境界制御（AWS の SCP、Google Cloud の VPC Service Controls）は、もはや推奨ではなく前提条件になりつつあります。AWS が提供を始めた「アカウント・リージョン別の名前空間」は、この問題を構造的に解消する一歩であり、クラウドの設計思想そのものが見直されていく兆しと読み取れます。
【用語解説】
バケットハイジャック（Bucket Hijacking）
クラウドストレージの「バケット名」が世界に一つしか存在できない仕組みを悪用した攻撃手法。攻撃者が標的のバケットを削除し、同じ名前のバケットを自分のアカウントで作り直すことで、流れ込むデータを横取りする。ソフトウェアのバグではなく、設計思想に根ざす点が特徴である。
バケット（Bucket）
クラウド上でデータをまとめて格納する「入れ物」のこと。Amazon Web Services（AWS）では S3 バケット、Google Cloud では GCS バケットと呼ばれる。
データストリーム（Data Stream）
サービス間でデータを自動的・継続的に流し込む仕組み。一度設定すれば背後で自律的に動き続け、ログやテレメトリを指定の保存先へ送り続ける。
監査ログ（Audit Log）/ テレメトリ（Telemetry）
監査ログは「誰がいつ何をしたか」を記録した証跡。テレメトリはシステムの稼働状況を示す各種の計測データを指す。いずれも組織のセキュリティ監視の根幹をなす情報である。
ロギングシンク（Logging Sink）
Google Cloud において、ログの送り先を定義するルーター的な仕組み。ログを指定のストレージなどへ振り分ける役割を持つ。
S3 レプリケーションルール（S3 Replication Rule）
AWS の機能で、元のバケットに書き込まれたデータを別の宛先バケットへ自動的に複製する設定のこと。
IAM 権限（storage.buckets.delete / logging.sinks.update）
IAM は「誰がどのリソースに何をできるか」を管理する権限制御の仕組み。storage.buckets.delete はバケットの削除権限、logging.sinks.update はログの送り先を正規に変更する権限を指す。前者で後者を迂回できてしまう点が今回の核心である。
Storage Admin ロール
Google Cloud が用意する標準的なストレージ管理者の役割。広範な権限を持ち、初期状態でバケット削除権限を含むため、攻撃の足がかりになりやすい。
ダングリングリソース（Dangling Resource）
バケットを削除したのに、それを指す経路設定が残ってしまった「取り残された」状態。攻撃者が同名のバケットを作ると、データが流れ込んでしまう。
データ境界制御（Data Perimeter Controls）
信頼された組織の境界の外へデータが流出しないよう制限する仕組みの総称。AWS の SCP（Service Control Policies）や Google Cloud の VPC Service Controls が該当する。
責任ある情報開示（Responsible Disclosure）
発見した脆弱性を、悪用される前にまず該当企業へ通知し、対策の猶予を与えてから公表する慣行。今回も3社へこの手順で通知された。
概念実証（PoC / Proof of Concept）
攻撃や技術が理論上だけでなく実際に成立するかを検証する実証実験。本研究は実際の悪用ではなく、この段階にあたる。
【参考リンク】
Unit 42（Palo Alto Networks）（外部）
パロアルトネットワークス傘下の脅威インテリジェンス研究組織。今回のバケットハイジャック研究の発表元である。
Google Cloud（外部）
今回の攻撃が検証されたクラウド基盤の一つ。Cloud Logging や標準の Storage Admin ロールなどを提供する。
Amazon Web Services（AWS）（外部）
S3 ストレージや S3 レプリケーション機能を提供する世界最大手のクラウド基盤。本研究の検証対象となった。
Microsoft Azure（外部）
Microsoft のクラウド基盤。本研究では診断設定を介したサブスクリプション横断型の攻撃が実証された。
VPC Service Controls（Google Cloud）（外部）
Google Cloud の資源を境界で囲み、データ流出を防ぐ防御機能。今回の緩和策の一つとして挙げられている。
【参考記事】
The Global Namespace Risk: Universal Bucket Hijacking Technique for Cloud Data Exfiltration（外部）
Unit 42 による一次情報の研究レポート。攻撃の仕組みと3社それぞれの検証手順、必要権限、緩和策の進行状況を詳述している。
Breach Roundup: How Hackers Exploited a Cisco SD-WAN Flaw（外部）
本攻撃が設計起因であること、権限昇格とダングリングリソースの2シナリオを整理した週次まとめ記事。
Cloud Bucket Hijacking Lets Attackers Silently Exfiltrate AWS, Google Cloud Data（外部）
Azure のソフト削除ポリシーにより攻撃がサブスクリプション横断に限定される背景を補足した記事。
【編集部後記】
クラウドを使うとき、私たちはつい「どのサービスが安全か」とベンダー単位で考えがちです。けれど今回の研究が突きつけたのは、安全性が個々の製品ではなく、クラウド全体に共通する「設計の思想」に左右されるという事実でした。便利な仕組みほど、その前提が崩れたときの影響は静かに広がります。
みなさんが関わるシステムでは、データはどこを通り、どこへ流れ着いているでしょうか。その経路を一度たどってみることが、これからのクラウドと向き合ううえで小さな手がかりになるかもしれません。
