マルチクラウドセキュリティの解説：AWS、Azure、GCPを横断した統合脅威検知

現在、多くの企業は単一のクラウド環境のみを運用しているわけではありません。2つ、3つ、あるいはそれ以上のクラウド環境を運用しており、各プロバイダーごとに独自のIDモデル、ポリシー記述言語、監査ログの形式が存在します。Flexeraの「2025年クラウドの現状」レポートによると、約70％の組織がハイブリッドクラウドまたはマルチクラウドを運用しており、1組織あたり平均2.4社のパブリッククラウドプロバイダーを利用しています。こうした分散化こそが、攻撃者が狙うまさにその隙間なのです。Ponemon Instituteの「データ侵害のコスト」調査によると、2024年の報告書では、複数の環境にまたがる侵害が最もコストがかかり、封じ込めに最も長い時間を要したことが明らかになっています。

このページでは、マルチクラウドセキュリティとは何か、ハイブリッドクラウドとの違い、クロスクラウドのIDフェデレーションが最大のリスクとなる理由、そして統合型検知によってクロスクラウド攻撃を一つのストーリーとして可視化する方法について解説します。これこそが、一般的な「機能チェックリスト」では触れられていない深い部分なのです。

マルチクラウドセキュリティとは何ですか？

マルチクラウドセキュリティとは、AWS、Azure、Google Cloudなどの2つ以上のパブリッククラウドプロバイダーにまたがるワークロード、データ、およびIDを単一の攻撃対象領域として保護し、各プロバイダーが別個のコントロールプレーンを運用している場合でも、一貫したポリシー、可視性、および脅威検知を適用する手法です。このアプローチでは、各プロバイダーを個別の環境ではなく、単一の環境として扱います。

企業がマルチクラウドを採用する理由は明確です。各プロバイダーが提供する最高水準のサービス、単一プロバイダーの障害に対する耐性、データ保管場所の柔軟性、そしてベンダーロックインからの解放などが挙げられます。また、マルチクラウドは、単一のクラウドの障害だけでシステム全体がダウンすることはないため、セキュリティの耐障害性を高めることもできます。その代償として複雑さが増しますが、セキュリティ上の課題となるのは、個々のクラウドではなく、プロバイダー間の連携の不備です。

こうした複雑さは、もはや例外ではなく、むしろ当たり前となっています。約3,200人の回答者を対象としたタレス（Thales）の「2025年クラウドセキュリティ調査」によると、1組織あたりのパブリッククラウドプロバイダーの利用数は平均2.1社となっています。 パブリックプロバイダーのみをカウントするか、ハイブリッド環境を含めるかによって導入率は大きく異なる（過去の推計では98％に達した例もある：Oracle/451 Research、2023年）が、2025年の最新データでは、2社以上のプロバイダーを利用することが標準的な運用モデルとして定着しつつある。 結論は単純だ。複数のクラウドを利用している場合、マルチクラウドセキュリティはもはやオプションではなく、相互運用を前提として設計されていないプロバイダー間で、一貫した保護を維持することが課題となる。

これを実現するツール類についてさらに詳しく知りたい方、また、クラウドセキュリティポスチャー管理、ワークロード保護、および利用権限管理がどのように連携しているかについては、当社の「クラウド検出・対応ガイド」をご覧ください。

マルチクラウドとハイブリッドクラウドのセキュリティ

マルチクラウドとハイブリッドクラウドはしばしば混同されますが、これらは異なるアーキテクチャを指し、それぞれ異なるリスクを抱えています。 マルチクラウドとは、2つ以上のパブリッククラウドプロバイダーを並行して運用することを指します。その脅威モデルはプロバイダー間のものであり、一貫性のないアイデンティティおよびアクセス管理（IAM）、断片化されたログ、そして攻撃者があるクラウドから別のクラウドへと侵入できるフェデレーションの信頼関係などが挙げられます。一方、ハイブリッドクラウドとは、オンプレミスインフラとクラウドを組み合わせたものであり、主な懸念事項はイースト-ウエストの可視性と、オンプレミスのディレクトリとクラウドのアイデンティティプロバイダー間のアイデンティティブリッジです。

この区別は、どのような制御が必要かを決定づけるため、重要です。ハイブリッド型プログラムでは、データセンターとクラウドの境界部分の監視に多大なリソースを割きます。一方、マルチクラウド型プログラムでは、異なる形式のデータを出力する各プロバイダー間で、テレメトリデータの標準化やID関連アクティビティの相関分析に注力します。

表：マルチクラウドとハイブリッドクラウドの適用範囲と脅威モデルの違い

このページでは、2つ以上のプロバイダーを組み合わせたモデルについて解説しています。オンプレミスとクラウドの連携に関する部分（東西方向の検知およびディレクトリからクラウドへのIDブリッジ）については、「ハイブリッドクラウドの脅威検知」をご覧ください。

マルチクラウドのセキュリティリスクと課題

マルチクラウドにおける最も一般的なリスクは、決して珍しいものではありません。これらは、ID管理、ポリシー、ログ管理の方法が異なるプロバイダーを組み合わせることで生じる、予測可能な結果に他なりません。繰り返し発生する課題は以下の通りです：

• 可視性の断片化：各プロバイダーの監査ログは異なるスキーマを使用しており、到着するまでの遅延も異なります。
• IAMモデルの不整合：プロバイダーごとにロール、ポリシー、および信頼関係が異なる。
• 設定のずれ：デフォルト設定とポリシー記述が一致しなくなるため、設定が整合性を失う。
• 責任の分散による複雑性：責任の所在は、プロバイダーやサービスごとに異なる。
• 工具の重なり：重複したり、設定が不完全な工具を使用すると、継ぎ目や隙間が生じます。
• 放置アカウント：どのプロバイダーにおいても、忘れ去られたり使われなくなったりしたアカウントは、攻撃の格好の入り口となります。

可視性の断片化には明確な定義が必要だ。なぜなら、これが多くの問題の根源となっているからだ。つまり、各プロバイダーがそれぞれ異なる方法でログを記録・報告するため、全体像を把握できる一元的な場所が失われ、セキュリティ上の死角が生じてしまうのである。忘れ去られたクラウドアカウントがリスクとなるのも、これと関連する理由からだ。誰も監視していない、未使用で権限が過剰に付与されたアカウントは、攻撃者にとって理想的な足掛かりとなり、マルチクラウド環境では、プロバイダーごとにそうしたアカウントが膨れ上がってしまう。

では、マルチクラウド環境はサイバー攻撃に対してより脆弱なのでしょうか？本質的にはそうではありません。マルチクラウドは設計上、セキュリティが低いわけではありませんが、可視性の断片化やIAM（アイデンティティ・アクセス管理）の不統一により、攻撃者が検知されずに活動できる期間が長引いてしまいます。コストに関するデータがこれを裏付けています。ポネモン研究所の「データ侵害コスト調査」2024年版によると、複数の環境にまたがる侵害が最も高額なコスト（505万米ドル）を要し、その特定と封じ込めに283日を要しました。また、侵害の40％が複数の環境にまたがっていました。 2025年版では、世界平均の侵害コストは444万米ドルと、5年ぶりに減少しました。どの版を見ても共通する教訓は、侵害が環境をまたぐ場合、コストが高くなり、解決までに時間がかかるということです。その理由は、全体像を把握できる単一のコンソールが存在しないためです。

「責任分担モデル」の基本や、あらゆるクラウド環境に必要な基本対策については、当社のクラウドセキュリティガイドをご覧ください。

統合型クロスクラウド脅威検知の仕組み

これは、一般的なピラーページでは触れられない部分です。CSPM、CWPP、CIEMを「機能」として列挙しても、AWS CloudTrail、Azure ActivityおよびEntraログ、Google Cloud Audit Logsといった各サービスがスキーマ、レイテンシ、IDモデルにおいて異なる中で、いかにして一貫性のある検知を実現するかについては説明されていません。統合型検知は、各プロバイダーのテレメトリデータを単一のモデルに正規化するため、クロスクラウド攻撃は散在したイベントとしてではなく、相互に関連付けられた単一のストーリーとして可視化されます。

その仕組みは、反復可能なパイプラインに従っています：

1. 各クラウドからプロバイダーごとのテレメトリデータを収集する。
2. データを共通のスキーマに正規化します。
3. すべてのプロバイダーに単一の検出モデルを適用する。
4. 統合型SIEM、XDR、またはNDRに取り込む。
5. クラウド間でアクティビティを関連付ける。
6. 優先順位を付け、一度だけ対応する。

‍

このパイプラインは、コントロールプレーンの実情から始まります。プロバイダーごとに監査や認証の方法が異なり、あるクラウドで機能する検出モデルを、そのまま別のクラウドに適用することはできません。以下の表は、統合レイヤーが調整しなければならない相違点を示しています。

表：統一された検知モデルが正規化すべき、プロバイダーごとのコントロールプレーンおよびロギングの違い。

テレメトリが正規化されると、次はそれをどこに格納するかという問題になります。従来のSIEMは、成熟した相関分析とレポート機能を提供しますが、マルチクラウド環境でのログ量が増えるとコストがかさむ可能性があります。一方、セキュリティ・データレイクは、より安価な保存と柔軟なクエリ機能を提供しますが、検出エンジニアリングの負担がチームに重くのしかかります。 多くの企業では、両方を併用しています。つまり、広範なデータと長期保存にはデータレイクを、リアルタイムの相関分析には統合された検知レイヤーを活用しています。ネットワーク検知・対応（NDR）および拡張検知・対応（XDR）は、ログのみの視点では見落とされがちな要素を補完します。フローや行動テレメトリに加え、クラウドのコントロールプレーンイベントも活用することで、単一プロバイダーのコンソールでは把握できないクロスクラウドの行動パターンを可視化するのです。

ネットワーク層はこの点において重要な要素であり、個別に詳しく検討する価値があります。プロバイダーをまたぐトラフィックの検査やセグメンテーションについては、「マルチクラウド・ネットワークセキュリティ」を参照してください。しかし、投資だけではこの課題を解決できません。2026年のハイブリッドクラウド・セキュリティ業界調査によると、93％の組織が新たな検知・可視化ツールを導入しているにもかかわらず、41％の組織が「インシデント調査に以前より時間がかかるようになった」と回答しています。統合されていないツールを増やしても、明確さが増すどころか、ノイズが増えるだけなのです。

クラウド間IDフェデレーション：中核となるリスク

アイデンティティはマルチクラウド環境における最大の侵害経路であり、その原因はフェデレーションにあります。Entra IDやサードパーティのシングルサインオン（SSO）サービスといった単一の中央アイデンティティプロバイダーが、AWS、Azure、GCPとフェデレーションされると、その単一のアイデンティティプロバイダーが侵害されただけで、クラウドを横断したアクセスが可能になってしまいます。 あるプロバイダーで盗まれた認証情報やトークンは、別のプロバイダーへのフェデレーションアクセスを可能にし、各プロバイダーのコンソールからは、それらが別個の無関係なイベントのように見えます。そこにギャップがあります。2つのコンソールには2つのログインとして表示されます。プロバイダー間でIDアクティビティを相関させるレイヤーがあって初めて、1つの攻撃として認識されるのです。

タレスの「2025年クラウドセキュリティ調査」によると、クラウド侵害の70%以上でIDの侵害が関与しており、68%の組織が、認証情報やシークレットの盗難を最も急速に増加している攻撃手法として挙げています。 なぜマルチクラウド環境ではID管理がこれほど困難なのでしょうか？それは、各プロバイダーがIDを異なる方法でモデル化しているため、フェデレーションの信頼関係において権限の範囲を過剰に設定しがちであり、さらにIDの拡散（クラウド全体に散在する過剰なアカウント、ロール、権限）によって、そもそも「正常な状態」がどのようなものか把握しにくくなっているからです。

このリスクは単なる仮説ではありません。2024年2月に公開されたCISAとNCSC-UKの共同アドバイザリAA24-057Aでは、ロシアのSVR（対外情報局）の攻撃者（APT29）が、クラウド環境への初期アクセスを得るために戦術を適応させている実態が報告されています。具体的には、休眠アカウントの悪用、トークンの窃取、多要素認証へのプレッシャーをかける手法を用いて、クラウド環境への侵入と持続的な潜伏を図っています。 これらの手法は、クラウド間を横断するフェデレーテッド・ピボットの基盤となるものです。現在の活動もこのパターンを裏付けています。2026年に発生したOAuthデバイスコードphishing 、340以上のMicrosoft 365組織を標的としました。AWSやGCPとフェデレーションされた中央のIDプロバイダーに対して発行されたトークンはクラウド間を横断する有効性を持つため、1つのトークンが盗まれるだけで複数のクラウドへのアクセスが可能になってしまうのです。 決定的なのは、このキャンペーンにおいてMFAが全く防御にならなかった点であり、被害者がパスワードをリセットした後もリフレッシュトークンが残存していたことです（Cloud Security Alliance Labs；FBI IC3 PSA）。

防御策は具体的である。パスワードのリセットだけでは盗まれたトークンが有効なまま残ってしまうため、単にパスワードをリセットするだけでなく、リフレッシュトークンも無効化すべきである。デバイスコードのフローを条件付きアクセス制御ポイントとして扱い、その利用を制限または範囲を限定する。トークンの発行と再利用を監視し、異常がないか確認する プロバイダーを問わず、クラウドごとにではなく。MITRE ATT&CK で言えば、クロスクラウドの移動は T1550.001 (アプリケーションアクセストークン) 横方向の動きと T1606.002 (SAMLトークン）による認証情報のアクセス管理。独立した調査でも同様の結論が導き出されている。すなわち、IDの乱立やフェデレーテッド・シングルサインオン（SSO）により、クラウド間での異常な動きが単一コンソールの監視画面では見落とされてしまうという（インフォメーションウィーク).

‍

このギャップを埋めることは、アイデンティティ検知の問題です。アイデンティティベースの攻撃を検知・対応する分野については、「アイデンティティ脅威検知・対応（ITDR）」を参照してください。異常なフェデレーテッドログインを検知する行動ベースラインについては、「アイデンティティ分析」を参照してください。また、技術分類の全容については、 MITRE ATT&CKを参照してください。

プロバイダー横断的な証拠問題としてのマルチクラウド・コンプライアンス

マルチクラウド環境において、コンプライアンスは単なるチェックリストというよりも、証拠の提示に関する課題と言えます。難しいのは、それぞれ異なる形式で独自の証拠を出力する各プロバイダーにわたり、一貫した管理措置の適用範囲を証明することです。マルチクラウド環境の導入は、コンプライアンス監査や報告にどのような影響を与えるのでしょうか？それは作業量を倍増させることになります。証拠を統一しない限り、管理措置ごとにプロバイダーごとに個別に証明を行わなければならないからです。

これは、単なる検知にとどまらない統合ロギングにおいても同様です。 テレメトリが1か所に集約されれば、1回のテストで複数のプロバイダーにまたがる監査証拠を単一のソースから生成できます。つまり、「1回テストすれば、多くのコンプライアンス要件を満たせる」のです。マルチクラウドのセキュリティコンプライアンスにおいて、最も一般的に使用されているフレームワークはどれでしょうか？実際には、多くの組織がNISTサイバーセキュリティフレームワーク とISO/IEC 27001:2022を基準として採用しており、EUの事業者はこれにNIS2を追加しています。

表：マルチクラウド管理手法と主要フレームワークの対応表

EUおよび英国の事業者にとって、今が正念場です。NIS2はすでに完全に施行されており、ENISAのNIS2技術的実施ガイダンスに基づき、初回監査の期限は2026年6月30日に延期されました。この期限に先立ち、統一された証拠を提示できるマルチクラウドプログラムは、プロバイダーごとに手作業でレポートを作成するプログラムよりも、はるかに有利な立場にあります。 プログラム全体の概要については「コンプライアンス」を、データ保護に関する詳細については「GDPRコンプライアンス」をご覧ください。

ツールの乱立とコストの削減

各制御ポイントごとに個別のマネージド検出、SIEM、またはNDRスタックを運用することはコストがかさむだけでなく、攻撃者が悪用する隙を生み出してしまう。統合への道筋は概念的には単純明快だ。現在運用している各ベンダーのツールを洗い出し、重複部分を特定し、冗長なポイントツールを単一の統合された検出レイヤーに統合する。その結果、管理コンソールの数が減り、死角が少なくなり、総コストも削減される。

コスト面での議論とセキュリティ面での議論は、本質的に同じものです。ポネモン研究所の「データ侵害のコストに関する調査」（2024年版）によると、複数の環境にまたがるデータ侵害による損害額は505万米ドルに達し、侵害後の潜伏期間は283日に及んだと報告されています。これは、ツールの乱立によって可視性が断片化されていることが一因となっています。 統合によってこの期間が短縮され、そこからコスト削減効果が生まれます。だからこそ、ツールの重複という問題は、セキュリティ上の課題であると同時に、予算の議論においても重要な位置を占めるのです。

データ保護は、ここで簡単に触れるのではなく、別途詳しく取り上げるべき関連分野です。マルチクラウド環境におけるデータセキュリティの詳細については、専用のリソースをご覧ください。

マルチクラウドセキュリティに対する最新のアプローチ

現代のマルチクラウド・セキュリティ戦略において、どのような点に注目すべきでしょうか？重要な機能は、前述の課題と直接的に対応しています：

• クラウド間を横断した統合的な可視性により、すべてのプロバイダーから一元化された情報を提供します。
• フェデレーテッドIDを主な攻撃経路とみなす、ID中心の検知。
• プロバイダーごとのサイロ化ではなく、SIEM、XDR、NDRの統合的なデータ取り込み。
• クラウド間でのシグナルを関連付け、アラートのノイズを低減するAI支援型トリアージ。
• 各プロバイダー間で一貫した方針とコンプライアンスの証拠。

購入者は、セキュリティ態勢管理機能――クラウドセキュリティ態勢管理（CSPM）、クラウドワークロード保護（CWPP）、クラウドインフラストラクチャ利用権管理（CIEM）――も求めるでしょう。これらは必須要件であり、各カテゴリーの定義については、ここで改めて説明するのではなく、当社の「クラウド検知・対応ガイド」に記載されています。

今後12～24ヶ月を形作るいくつかのトレンドがあります。AIは今や攻撃側と防御側の双方に存在しており、より説得力のあるphishing を提供する一方で、防御側の優先順位付けや相関分析を支援しています。ID管理は、数あるリスクの一つから主要な攻撃経路へと変化しており、2025年のインシデント対応調査の約90％でID管理の脆弱性が指摘されています（Unit 42の調査）。 また、プロバイダーごとのコントロールプレーンの脆弱性は絶え間なく報告され続けています。Zero Day 年5月のレビューでは、Azureクラウドサービスに関する重大なCVEが相次いで報告されており、マルチクラウドプログラムでは、すべてのプロバイダーのコントロールプレーンにおけるリスクを同時に追跡する必要があることを改めて示しています。A Zero Trust の姿勢——明示的な検証と最小権限の徹底——こそが、他のすべてを機能させるためのアーキテクチャ上の基盤である。単一プロバイダーにおけるネイティブ検出ツールの例としてはAWSの脅威検知を、ワークロードおよびコンテナ層についてはKubernetesのセキュリティを参照のこと。

Vectra AIがマルチクラウドセキュリティをどう捉えているか

Vectra AIは、現代のネットワークはオンプレミス、マルチクラウド、ID、SaaSにまたがる単一の攻撃対象領域であるというシンプルな前提に基づいています。したがって、レジリエンスは、特定のプロバイダー固有のコンソールではなく、統合された可観測性、AI駆動型の攻撃シグナル、そして情報に基づいた対応によってもたらされるのです。 「侵害を前提とする（Assume Compromise）」という哲学の下、目標は「攻撃者が侵入することは決してない」と主張することではなく、フェデレーテッドなクロスクラウド攻撃が発生した際に、Attack Signal Intelligence それを2つの無関係なコンソールイベントとしてではなく、1つの相関した攻撃ストーリーとしてAttack Signal Intelligence 。これにより、散在し、プロバイダーごとにサイロ化されたアラートを、少人数のチームでも対応可能な単一のシグナルへと変換します。

結論

マルチクラウドのセキュリティとは、各プロバイダーを個別に強化することではありません。重要なのは、プロバイダー間のギャップを埋めることです。つまり、一貫性のないIDモデル、断片化されたログ、そして攻撃者があるクラウドから別のクラウドへと移動できる一方で、各コンソールにはその一部しか表示されないようなフェデレーションの信頼関係といった問題に対処することです。 マルチクラウドセキュリティを適切に運用している組織は、各プロバイダーを単一の攻撃対象領域として扱っています。つまり、テレメトリデータを単一の検知モデルに標準化し、クラウド間のIDアクティビティを相関分析し、プロバイダーごとに個別にではなく、監査担当者を納得させる統一された証拠を一度で作成しているのです。

その背景にある脅威の基盤――クロスクラウドでのID悪用――は急速に拡大しており、ツールへの投資だけではこのギャップを埋めることはできません。今後の道筋は「統合」にあります。つまり、「単一の全体像、単一のシグナル、単一の対応」です。統合されたID認識型検知が、クロスクラウド攻撃を単一の相関性のあるストーリーとして浮き彫りにする仕組みについては、Vectra AIのクラウド検知・対応アプローチをご覧ください。

‍