クラウド検出・対応（CDR）：セキュリティアーキテクトのための基本ガイド

クラウド検出・対応（CDR）とは、クラウド環境内で活動中の脅威を検知・阻止するランタイム対策であり、ポスチャー管理とインシデント対応の間に位置する層であり、現代のセキュリティ侵害の多くが実際に発生する場所です。また、これはアナリストやベンダーの間で依然として議論が続いている分野でもあります。2024年5月のフォレスターの分析では、CDRは「市場」ではなく「機能」であると指摘されました。 それから2年後、Forresterの「2026年第1四半期 クラウドネイティブ・アプリケーション保護ソリューションWaveレポート」では、CDR機能を十分に網羅している14社のベンダーが評価されました。その呼称がどうであれ、この機能は現在、規制対象企業がIDの悪用、コントロールプレーンへの攻撃、一時的なワークロードの侵害といった侵害を検知する上で中核的な役割を果たしています。これらは、従来のエンドポイント検知・対応（EDR）やSIEMツールでは検知するよう設計されていなかった侵害です。

本ガイドでは、CDRとは何か、その仕組み、EDR、NDR、XDR、CSPM、CWPP、CNAPP、SIEMとの違い、およびNIS2、NIST SP 800-61 Revision 3、UK GDPRとの対応関係について解説します。 Capital One、Snowflake、UNC6426、欧州委員会といった実際のクラウド侵害事例を用いて、マーケティング上の説明ではなく、実務においてCDRのシグナルがどのように現れるかを示します。

クラウド検知・対応とは何ですか？

クラウド検出・対応（CDR）とは、クラウドの制御プレーン、データプレーン、管理プレーン全体にわたるアクティブな脅威を検知、調査、対応する継続的な監視手法です。CloudTrail、Azure Activity Logs、GCP Audit Logs、ランタイムプロセスイベントといったクラウドネイティブなテレメトリデータを取り込み、行動分析を適用することで、従来のEDR、SIEM、セキュリティ状態監視ツールでは見逃されがちな攻撃を可視化します。

エンドポイントセキュリティの基盤となっていた前提がもはや通用しなくなったため、クラウドには新たなアプローチが必要です。Sysdigの「2025年クラウドネイティブセキュリティおよび利用状況レポート」によると、コンテナの60%は1分未満で消滅します。エージェントを配置できる永続的なホストが存在しないことが多く、フォレンジック証拠は、バッチ処理型のログ集約ツールが保存できる速度よりも早く消えてしまいます。 ネットワークに代わって、IDが主要な初期侵入経路となっています。2026年のクラウド侵害の約83％はIDの侵害から始まっており、業界の脅威インテリジェンス調査によると、2026年のクラウドを意識した侵入は前年比266％の急増が見込まれています。 この状況は、運用面だけでなく財務面でも同様です。ポネモン研究所の「データ侵害コスト」調査シリーズでは、マルチクラウド環境での侵害によるコストがオンプレミス環境のインシデントよりも約100万ドル高いことが一貫して示されており、最新の調査では平均で約505万ドルに達しています。

クラウドセキュリティモニタリング――クラウド上のアクティビティを監視し、リスクやポリシー違反を検知するという広義の取り組み――は、CDRと一部重なる部分はあるものの、同一のものではありません。モニタリングとはテレメトリ収集機能を指すのに対し、CDRは、そのテレメトリを基盤として構築された、能動的な検知・対応の分野です。 ベンダーやアナリストの資料で見かける関連用語には、クラウドネイティブ検出・対応（CNDR）やクラウド脅威検出・対応（CTDR）などがあります。これらは実質的に同じ意味です。

このカテゴリーそのものが議論の的となっている。フォレスターは2024年5月時点では、「クラウド検出・対応（CDR）ツールは独立した市場として存在しない」との見解を示していた。それから2年後、フォレスターの「2026年第1四半期 クラウドネイティブ・アプリケーション保護ソリューションWaveレポート」では、実質的なCDR機能を備えた14社のベンダーが評価対象となっている。これは、この分野の捉え方に大きな変化が生じたことを示している。Wiz、Sysdig、Tenableの各ベンダーの主要ページでは、CDRをクラウドセキュリティ分野における新たな分野として位置付けている。我々は、その根底にある機能——3つのクラウドプレーンにわたるランタイム脅威検知——を、購買の境界線がどのように引かれようとも、現実的かつ不可欠なものとして捉えている。

「CDR」という用語の由来

CDRは、2022年から2024年頃にかけてベンダーによって提唱されたカテゴリーとして登場しました。これは、クラウドネイティブ環境におけるセキュリティ侵害が、セキュリティ態勢管理ツール（CSPM）やワークロード強化ツール（CWPP）だけでは対処しきれないレベルに達したためです。ガートナーは、CDRをクラウドネイティブ・アプリケーション保護プラットフォーム（CNAPP）のファミリーに位置付けています。この位置付けは、現在多くの企業ユーザーがクラウドセキュリティスタックを構築している方法と概ね一致しています。

クラウドの検知と対応の仕組み

最もわかりやすい例えはSysdigによるものです。CDRを、クラウド向けの常時稼働する防犯カメラだと考えてみてください。エンドポイントツールは、個々のマシンで何が起きたかを教えてくれます。ポスチャツールは、ある時点での構成状況を把握させてくれます。一方、CDRは、あらゆるレイヤー、プロバイダー、ワークロードにおいて「今まさに何が起きているか」を把握し、それらのシグナルを統合して単一の攻撃ストーリーとして描き出します。運用面では、このアプローチは以下の6つのステップで構成されています：

1. あらゆるレイヤーおよびプロバイダー（AWS、Azure、GCP、Kubernetes、SaaS）からのクラウドネイティブなテレメトリデータを収集します。
2. プロバイダー間でログを正規化する— CloudTrail、アクティビティログ、および監査ログは、それぞれ異なるスキーマを使用しています。
3. 行動分析を活用して分析を行う――まず、IDおよびリソースの行動のベースラインを把握し、その後、異常を検知する。
4. 検知結果に、アイデンティティのコンテキスト、脅威インテリジェンス、および資産のメタデータを付加します。
5. サイバーキルチェーンに沿った単一の攻撃シナリオに、関連するシグナルを統合する。
6. 対応— リスクの低いアクションについては封じ込めを自動化し、リスクの高いアクション（セッションの解除、ワークロードの隔離、IAMプリンシパルの凍結）については、人間の介入による承認を必須とする。

第3段階と第4段階こそが、CDRの本領が発揮される場面です。シグネチャのみに基づく検知では、クラウド攻撃者の攻撃速度に対応しきれず、CloudTrailからの生アラート量だけでも処理しきれないほど膨大です。行動ベースライン（「この主体は通常どのような行動をとるのか？」「このワークロードは通常、どのリソースと通信するのか？」といった情報）を用いることで、その膨大なデータを統合し、精度の高いインシデント対応シグナルへと変換します。

エージェント型とエージェントレス型：導入モデル

「エージェント型対エージェントレス型」という議論は確かに存在しますが、その二分法はますます不適切になりつつあります。スナップショットベースかつAPI駆動型のエージェントレスCDRは、ワークロードへの負荷を一切生じさせることなく、広範な可視性と迅速な導入を実現します。これは、コントロールプレーンおよびマネジメントプレーンの可視化、複数アカウントのカバー範囲、導入スピードの向上に極めて有効です。 一方、エージェントベースのCDR（通常はeBPFやサイドカー）は、実行時の詳細な情報を提供します。これには、プロセスレベルのイベント、システムコールトレース、コンテナ内のネットワーク呼び出し、そして一時的なワークロードによって通常は消去されてしまうようなデータプレーンのフォレンジックデータが含まれます。最近の多くのシステムでは、これら両方を組み合わせています。つまり、広範な可視性を求める場面ではエージェントレスを、実行時のフォレンジックが重要な重要なワークロードやKubernetesセキュリティクラスターなど、詳細な分析が必要な場面ではエージェントベースを活用しているのです。

AIと行動分析の役割

行動ベースの検知は、もはや単なる理想ではなく、主流となっています。Sysdigの2026年レポートによると、70%以上のチームが行動ベースの検知を採用しており、その対象となる環境は全体の91%に上ります。 不審なプロセスの自動終了は、前年比で約140%増加しました。管理対象のクラウドIDのうち、人間によるものはわずか約2.8%に過ぎず、残りはサービスプリンシパル、マシンID、一時的なワークロードトークンです。まさにこのため、IDコンテキストの充実化は不可欠なのです。AI専用パッケージの導入は前年比で約25倍に増加し、CDRが監視すべきサプライチェーンの攻撃対象領域を拡大させています。

これに対し、防御側の対応策として提唱されているのが「マシンスピード・パリティ」である。Dark Readingは、5/5/5というベンチマーク（検知に5秒、優先順位付けに5分、対応に5分）を、ブレイクアウト時間が数時間ではなく数分単位で計測される、クラウドを意識した攻撃シナリオにおける運用目標として広めた。

3層アーキテクチャ：制御層、データ層、管理層

クラウド環境を3つの層に分けて考えれば、CDRに関する多くの混乱はすぐに解消されます。これは、すべてのセキュリティアーキテクトが30秒でホワイトボードに描けるべき、アーキテクチャの基盤となる概念です。

• コントロールプレーン — 設定、オーケストレーション、およびIAMイベントが行われるAPIおよび管理インターフェース。テレメトリ：AWS CloudTrail、Azure Activity Logs、GCP Audit Logs。検知対象：異常なIAMロールの引き受け、OIDCトラストポリシーの悪用、予期しないCloudFormationスタックの作成（ CAPABILITY_NAMED_IAM 変更期間外での、S3ポリシーの異常な変更。
• データプレーン— ワークロード（コンテナ、VM、サーバーレス関数）が実際に実行されるランタイム層。テレメトリ：プロセスイベント、システムコール、コンテナランタイム、ネットワークフロー、eBPF由来のシグナル。検知：プロセスの異常な起動、コンテナからの脱出試行、予期しない外部への呼び出し、クリプトマイナーの実行。
• 管理プレーン— アイデンティティ、課金、ガバナンス、およびフェデレーションの領域（管理者の操作、フェデレーテッド・アイデンティティに関するイベント、サービスプリンシパルの動作、課金上の異常）。検出対象：権限昇格の連鎖、サービスプリンシパルの異常な動作、フェデレーショントークンの悪用、アカウント間での異常なロール取得活動。

イメージとして役立つ例えがあります。コントロールプレーンはクラウドの交換機、データプレーンは実際に作業が行われる現場、そしてマネジメントプレーンはアイデンティティやガバナンスに関する決定が行われる管理部門に例えられます。攻撃者が実質的な被害を与えるには、少なくとも2つのプレーンを横断する必要があります。防御側は、攻撃者を検知するためにこれら3つすべてを可視化する必要があります。

テレメトリソースをプレーンにマッピングする

以下の表では、各プレーンについて、その代表的なテレメトリソース、検出例、および MITRE ATT&CK で特定される手法を示しています。このマッピングこそが、アラートのノイズと実用的な検出バックログとの違いです。

表1：クラウドテレメトリソースと3つのCDR検出プレーンとの対応関係

2026年の数値は、なぜこのマップが今重要なのかを説明しています。Google Cloudの「Threat Horizons H1 2026」レポートによると、クラウド攻撃の突破時間は約29分に短縮されています。 ケーススタディで後述するUNC6426クラスターは、単一の侵害されたnpmパッケージから72時間以内にAWSの管理者権限を完全に取得しました。この攻撃チェーン全体は、3つのプレーン（コントロールプレーンのスタック作成、マネジメントプレーンのOIDCトラストの悪用、データプレーンのS3列挙）すべてを横断するものでした。コントロールプレーンの攻撃対象領域に関する詳細は、「クラウドコントロールプレーンの保護」を参照してください。

CDR対EDR、NDR、XDR、CSPM、CWPP、CNAPP、およびSIEM

CDRの評価において最もよく聞かれる技術的な質問は、「これは何を置き換えるものなのか？」というものです。率直に言えば、何も置き換えるものではありません。CDRの最大の特徴は、3つのクラウドプレーンにわたるランタイム脅威検知にあるのです。これは、エンドポイント、ネットワーク、セキュリティ態勢、ワークロードの各ツールがそれぞれ部分的にしか捉えられない領域です。これらのカテゴリは互いに補完し合うものであり、最新のプログラムの多くは、これらを組み合わせて導入しています。

• CDR 対 EDR— エンドポイント検出・対応（EDR）は、管理対象のエンドポイントやサーバーを監視します。一方、CDRは、永続的なエンドポイントエージェントを配置できないクラウドのコントロールプレーンや一時的なワークロードを監視します。EDRはノートPCやサーバーの環境に不可欠であり、CDRはAWS、Azure、GCP、およびKubernetesランタイム環境に不可欠です。
• CDR 対 NDR—ネットワーク検知・対応（NDR）は、イースト・ウエストおよびノース・サウス方向のネットワークトラフィックを監視します。一方、CDRはクラウドネイティブなAPIやID関連のイベントを監視します。オンプレミスのネットワークとクラウドのコントロールプレーンの両方が重要なハイブリッドクラウドのセキュリティ環境において、これら2つは互いに補完し合う関係にあります。
• CDR 対 XDR— XDR は、多数のソースにまたがる相関分析レイヤーです。一方、CDR は、XDR が取り込める高精度なシグナルを生成する、ドメイン固有の検知レイヤーです。エンドポイントから始まった相関分析モデルがどのように発展したかについては、「EDR 対 XDR」をご覧ください。
• CDR 対 CSPM— クラウド・セキュリティ・ポスチャー・マネジメント（CSPM）は、保存データにおける設定ミスを検出します。一方、CDRは、進行中の攻撃を検知します。CSPMは「ドアの鍵が開いていた」ことを知らせるのに対し、CDRは「誰かがそのドアから侵入した」ことを知らせるのです。これらは競合するものではなく、互いに補完し合う関係にあります。
• CDR 対 CWPP— クラウドワークロード保護プラットフォーム（CWPP）は、個々のワークロードのセキュリティを強化します（脆弱性スキャン、設定の強制、実行時保護）。一方、CDRは、CWPPでは把握できない制御プレーンや管理プレーンを含め、より広範なクラウド環境全体にわたるアクティブな脅威を検知します。これらは多くの場合、CNAPP内で組み合わせて提供されます。
• CDR 対 CNAPP— CNAPP は、CSPM、CWPP、CDR などを統合したプラットフォーム群です。CDR は CNAPP の「ランタイム検出・対応」機能であり、競合するカテゴリーではありません。
• CDR 対 SIEM— SIEM は企業全体にわたるログを集約し、相関分析を行います。一方、CDR はクラウドテレメトリのセマンティクス（IAM 関係、一時的な識別子、マルチアカウントグラフなど）に特化して設計されています。最近の多くのプログラムでは、CDR と SIEM のどちらか一方を選ぶのではなく、CDR のシグナルをSIEM の最適化ワークフローに取り入れています。TechTarget による CDR と EDR、NDR、XDR を比較した中立的な分析でも、同様の結論が導き出されています。

表2：CDRの範囲と、関連する検知・対応カテゴリーとの比較。

CDRは独立したカテゴリーなのでしょうか、それとも単なる機能セットなのでしょうか？

この点については、率直な回答が必要でしょう。フォレスターは2024年5月時点で、CDRは独立した市場ではなく、その機能はCNAPP、SIEM、および関連プラットフォーム内に組み込まれており、別途購入する価値はないとの見解を示していました。 この主張は2024年時点では妥当だったが、その後その説得力は弱まっている。フォレスターの2026年第1四半期版「クラウドネイティブ・アプリケーション保護ソリューション・ウェーブ」では、CDR機能を十分に備えた14社のベンダーが評価されており、これは「カテゴリーではなく機能」という厳格な解釈を複雑なものにしている。 ハイパースケーラーによる統合がこの傾向を後押ししている。TechCrunchの報道によると、 Googleは2026年3月11日にWizの320億ドル規模の買収を完了し、 これによりハイパースケーラーのポートフォリオ内に実質的なCDR機能が組み込まれた。

要点は次の通りです。この基盤となる機能は現実的かつ不可欠なものであり、EDR、NDR、CSPM、CWPP、あるいはSIEMのいずれか単独では十分にカバーできません。これを独立した製品として導入するか、CNAPPの一要素として導入するかは、スタックの構成によって異なります。新規導入のプログラムでは、通常CNAPPに統合されます。一方、既存のSIEMやEDRへの投資が充実している成熟したプログラムでは、CDRを独立したレイヤーとして運用し、スタックの他の部分に情報を提供することがよくあります。

クラウド環境における検知と対応の実践

抽象的なカテゴリに関する議論は、具体的な攻撃事例を挙げることでより明確に解決できます。以下の4つの侵害事例は、3つの側面におけるCDRシグナルの実態と、それらが欠如したことで影響を受けた組織が被った損害を明らかにしています。

事例 1 — Capital One（2019年7月、事後分析）。設定ミスのあったAWS WAFとサーバーサイドリクエストフォージェリ（SSRF）の組み合わせにより、攻撃者はEC2インスタンスのメタデータIAMロールを悪用し、S3から米国およびカナダのクレジットカード申込者記録約1億600万件を列挙・流出させた。この攻撃は、発見されるまで数ヶ月にわたり継続していた。CDRシグナル：データプレーンおよびコントロールプレーンにおける異常な動作 — 通常はS3の一括列挙を行わないEC2インスタンスから、単一のIAMプリンシパルが異例のS3読み取り量を発生させていた。これはまさに、CloudTrail上の行動分析とAWS脅威検出を組み合わせることで検出されるよう設計された、クロスプレーンシグナルである。

事例 2 — Snowflake（2024年）。認証情報の再利用（一部は2020年の情報窃取型マルウェアのログから追跡可能）に加え、顧客側での多要素認証（MFA）の適用が不十分だったため、約165の顧客組織が影響を受けた。クラウド・セキュリティ・アライアンス（CSA）による2024年のSnowflake事後分析は、公的に認められた権威ある分析である。CDRのシグナルとしては、地理的に異常なログイン、クエリ量の急増、および高権限のSaaS認証インターフェースにおけるMFAの未適用が挙げられる。これらはすべて、管理プレーンのIDテレメトリを通じて検出可能である。この事例から得られる教訓は、認証情報の盗難による影響は、エンドポイントだけでなくSaaS層におけるCDRの課題でもあるということである。

事例3 — UNC6426（2026年第1四半期）。 これは、公開されている記録の中で最も明確な3つの側面から見た事例研究です。改ざんされたnpmパッケージ（QUIETVAULT）――まさに典型的な サプライチェーン攻撃 — GitHubトークンを盗み出した。GitHubからAWSへのOIDCトラストポリシーが過度に広範であったため、それらのトークンがAWS IAMロールを引き継ぐことが可能となった。CloudFormationを使用して、以下の内容を含むIAMスタックが作成された CAPABILITY_NAMED_IAMこれにより、攻撃者は72時間以内にAWSの管理者権限を取得しました。その後、攻撃者はS3のリソースを列挙し、EC2およびRDSインスタンスを停止させ、アプリケーションキーを復号化しました。この一連の攻撃の流れは、 Hacker NewsによるUNC6426 npmサプライチェーン攻撃に関する報道、その クラウド・セキュリティ・アライアンスによるOIDCトラストチェーンの悪用に関するブリーフィングそして Google Cloudの「Threat Horizons 2026年上半期」レポート. CDR信号： CI以外のプリンシパルによるSTSトークンの発行とCloudFormationの連携 CAPABILITY_NAMED_IAM 変更ウィンドウ外でのスタック作成 — コントロールプレーンとマネジメントプレーンのストーリーラインが組み合わさったものであり、単一のツールカテゴリだけでは対応しきれない。

事例 4 — 欧州委員会 Europa.eu（2026年3月）。Trivyのサプライチェーン侵害により、攻撃者が5日間にわたりシステム内に潜伏し、その間にEUがホストするAWSインフラから約91.7 GBのデータが流出しました。欧州委員会のクラウド侵害に関するCERT-EUのブログ、BleepingComputerの記事、およびHelp Net Securityの報道が、その経緯を詳述しています。CDRシグナル：5日間にわたって継続したコントロールプレーンAPIの異常。これは、ポスチャーのみを監視するツールでは検知できず、クラウドネイティブなコンテキストがなければ、バッチモードのSIEM相関分析でも通常は見逃されてしまうようなパターンである。

表3：最近のクラウド侵害事件における発生経緯とCDRシグナル

一時的なワークロードのフォレンジック分析

一時的なワークロードは、従来のデジタルフォレンジクスの前提を覆します。コンテナの60%が1分未満しか存続しない場合、事後的な証拠収集は多くの場合不可能です。これに対する運用上の解決策は、リアルタイムでのキャプチャと不変性の確保です：

1. 重要なワークロード上でeBPFベースのエージェントを使用して、プロセスイベントやネットワークテレメトリをリアルタイムでキャプチャします。これは、コンテナが終了する前にシステムコールレベルの証拠を確実に保存できる唯一の方法です。
2. クラウドプロバイダーの監査ログの保存期間を、特にコントロールプレーンやIAMイベントについては、一般的な30～90日というデフォルト設定を超えて延長してください。欧州委員会への不正アクセス事件のような、長期間にわたり継続する侵入攻撃の場合、デフォルトの保存期間では対応しきれない可能性があります。
3. 検出時にクラウドスナップショットの証拠（EBSスナップショット、Azureマネージドディスクのスナップショット、GCPパーシステントディスクのスナップショットなど）を保存し、フォレンジック証拠としてタグ付けすることで、自動削除を防ぐ。
4. クラウドプロバイダーが提供する不変ストレージプリミティブ（コンプライアンスモード対応のS3 Object Lock、Azure Immutable Blob Storage）を活用して、フォレンジックにおける証拠の連鎖（チェーン・オブ・カスターディ）を維持します。書き込み一回限りの保存は、法的に有効なクラウドフォレンジックの基盤となります。

クラウド上の脅威の検知と防止

以下の7つの防御策は、複数のベンダーによる指針を統合したものであり、該当する場合はMITRE ATT&CK と関連付けられています。これらはベンダーごとのチェックリストではなく、防御対策として捉えてください。

1. あらゆる環境（パブリック、プライベート、マルチクラウド、SaaS）を網羅します。単一プロバイダーによる監視は、最も一般的なサイロ化であり、最も一般的な検知の死角でもあります。
2. 継続的なリアルタイム監視— 実行時にCloudTrail、アクティビティログ、および監査ログを取り込みます。バッチモードでのログ集約では、「5/5/5」のベンチマークやNIS2の24時間というタイムラインを満たすことはできません。
3. シグネチャのみに依存する手法ではなく、行動分析を活用し、リソースを横断するイベントを単一のストーリーラインとして関連付ける。現在、環境の91%をカバーする行動ベースの検知を採用しているチームの70%がこれを行っているのは、ルールベースの検知ではクラウド攻撃者のスピードに対応しきれないためである。
4. IDコンテキストは必須です — 実行時のイベントとID関連のアクションを関連付ける（T1078.004, T1552）。83％という身元情報の漏洩率が、まさにその理由そのものです ID脅威の検知と対応 そして IDに基づく攻撃の検知と封じ込め 現在はCDRに隣接しています。
5. 「ヒューマン・イン・ザ・ループ」による安全策を伴う自動応答— セッションを自動的に切断し、本番環境アカウントにおけるIAMロールの停止には人間の承認を必須とする。安全策のない自動化はサービス停止を招く。
6. SIEMおよびSOARとの連携— CDRは既存のプラットフォームを置き換えるのではなく、その機能を強化します。大量の生アラートではなく、高精度に統合された検知情報をSOC運用チームに転送します。
7. 一時的なデータへの対応を計画する――事後ではなく、リアルタイムでフォレンジック証拠を収集する。トリアージが完了する前にデータが消えてしまうと想定しておく。

表4：クラウドの検知と対応を運用面で効果的にする7つの防御策。

検出の基礎となる手法についてさらに詳しく知りたい場合は、「脅威検出」および「MITRE ATT&CK Matrix」を参照してください。補足的なユースケースの枠組みについては、TechTargetによるCDRユースケース分析が、中立的な参考資料として有用です。また、OWASPの「Cloud-Native Application Security Top 10」やENISAの「Cloud Security Guide」など、自社の取り組みを照らし合わせる価値のある業界フレームワークも存在します。

クラウドの検知・対応およびコンプライアンス

CDRは現在、セキュリティ機能であると同時にコンプライアンス機能でもあります。現行のEUおよび英国の規制で定められている24時間および72時間の要件は、バッチ処理によるログの確認や手動による選別では満たすことができません。

• NIST SP 800-61 リビジョン3（2025年4月）— 2012年以来となる米国政府のインシデント対応ガイドの初の改訂版。本ガイドでは、クラウド環境やログ保存期間の制約について明確に言及するとともに、インシデント対応をNIST CSF 2.0の「検知（Detect）」「対応（Respond）」「復旧（Recover）」の各機能に位置づけています。 全文はNISTから入手可能です。本ガイドはNIST SP 800-207「 Zero Trust 」と連動しています。詳細は zero trust を参照）と相まって、クラウド検知プログラムのための連邦政府の基礎的な指針となっています。
• NIS2（EU）— 第23条のインシデント報告義務では、24時間以内の早期警告および、初期評価を伴う72時間以内のインシデント通知が求められています。必須事業体に対する罰金の上限は、1,000万ユーロ、または全世界の売上高の2％に達します。欧州委員会のNIS2指令に関するページが主な情報源です。リアルタイムのCDR検知こそが、この24時間のタイムラインを運用上実現可能にするものです。
• 英国GDPR— 第33条では、情報コミッショナー事務局（ICO）へのデータ侵害通知を72時間以内に行うことが義務付けられています。これと同様の運用上の要件として、対象となるインシデントを迅速に検知し、確実に通知期限のカウントダウンを開始できる体制が求められます。より広範な規制の背景については、英国ICOのNISおよび英国GDPRに関するデータ侵害対応ガイダンス、 ならびにGDPRコンプライアンスに関する 資料をご参照ください。
• 英国サイバーセキュリティ・レジリエンス法案— 本稿執筆時点では起草中であり、2026年半ばから後半にかけて成立が見込まれる。英国の重要インフラ事業者およびデジタルサービス事業者に対し、報告義務およびレジリエンス確保に関する義務をさらに追加するものである。
• MITRE ATT&CK Matrix— 監査対応における防御策の有効性を裏付ける確固たる根拠。CDRによる検知結果をATT&CKの手法にマッピングすることで、コンプライアンス担当チームは具体的な形で防御範囲を証明することができます。
• CISAクラウドセキュリティ参照アーキテクチャ— 米国連邦政府およびCSP関連の環境に適用されます。CISA SCuBAプロジェクトページが公式の入り口となります。

表5：CDR機能と主要なクラウドインシデント対応規制との対応関係

現代的なアプローチと、この分野の今後の展望

今後12～24カ月の間に、3つの要因がCDRのあり方を一新しようとしています。第一に、「AIファーストのクラウド防御」が概念から製品へと移行しつつあります。異常を検知し、人間の介入なしに封じ込める「エージェント型修復」機能は、2026年第1四半期のForrester Waveにおいて、主要なCNAPPベンダー各社で導入が進んでいます。 第二に、2026年3月11日にGoogleによる320億ドル規模のWiz買収が完了したことで、ハイパースケーラーによる市場統合が著しく加速しました。独立系CDRベンダーは、シグナルの品質とマルチクラウド環境における統合の中立性において差別化を図る必要があります。 第三に、防御側はAIを活用した攻撃者との「マシンスピード」の対等性を追求する方向へシフトしている。Sysdigの2026年のレポートによると、行動ベースの検知と自動遮断は差別化要因ではなく、標準的な実践となっている。

5名未満のセキュリティチームにとって、これはクラウド環境において何らかの形のマネージド・ディテクション・アンド・レスポンス（MDR）がますます適切な解決策となりつつあることを意味します。5/5/5や24時間体制のNIS2要件を満たすために必要な運用ペースは、小規模なチームでは社内で維持することが困難だからです。 この分野の展望は統合に向かう。成熟したCNAPPスタックを持つ組織では、CDRを独立した購入ラインとして継続するだろうが、ゼロから構築する組織では、プラットフォーム型CNAPPへと統合されていく。いずれにせよ、ランタイム検出機能は必須である。MediumによるガートナーのCDRポジショニングの概要や、SkyhawkのCDRベストプラクティスフレームワークなどのベンダーフレームワークの参照資料を含む業界のポジショニング概要は、さらなる背景情報を提供している。

Vectra AIがクラウドの検知と対応をどのように捉えているか

Vectra AIのクラウド検知・対応アプローチは、クラウド環境に適用された「侵害を前提とする」という哲学を反映しています。具体的には、3つのプレーンにわたる継続的な可観測性、ノイズを排除して攻撃の連鎖を明らかにするAI駆動型のAttack Signal Intelligence™、そして横方向の移動が定着する前にアクティブな脅威を封じ込める、情報に基づいた対応です。その目的は、アラートの数を増やすことではなく、機械の速度で適切なシグナルを提供することにあります。Vectra AIプラットフォームに対するIDCの独立分析によると、MITRE ATT&CK 90%以上をカバーし、ROIは391%、投資回収期間は6ヶ月であることが判明しました。AWS固有のランタイムカバレッジについては、Vectra AI CDR for AWSをご覧ください。

結論

クラウド検知・対応（Cloud Detection and Response）とは、クラウドのテレメトリを統合された攻撃の経緯へと変換するランタイム層のことです。これは、EDR、NDR、SIEMと競合する新たな製品カテゴリーではなく、これら3つのクラウド領域をセキュリティ運用チームにとって理解可能な形にするための手法です。セキュリティ態勢やエンドポイントのみを重視する考え方からの転換は、もはや選択の余地のない課題となっています。アイデンティティは、主要な初期侵入経路です。ワークロードは一時的なものです。 侵入から拡散までの時間は数分単位で計測されます。規制当局は24時間体制を義務付けています。こうした状況下で持ちこたえられる組織とは、その実装形態にかかわらず、ランタイム・クラウド検知を最優先の機能として位置づけている組織です。

クラウド検知プログラムを構築または刷新する場合は、まず「3つのプレーン」という概念モデルから始め、既存のテレメトリデータをそれに照らし合わせて分析し、単なるロギングにとどまらず、実際に検知が行われているプレーンを特定してください。CDR（イベントデータ記録）と行動分析を組み合わせ、既存のSIEMや拡張された検知・対応（EDR）ワークフローに組み込み、検知範囲MITRE ATT&CK Matrixに整合させることで、監査時の議論において具体的な根拠を示すことができるようになります。 関連分野についてさらに詳しく知りたい場合は、以下の関連トピックにある「ID脅威の検知と対応」、「AWS脅威検知」、「Kubernetesセキュリティ」をご覧ください。方法論の観点については、上記のリンク先にあるVectra AIプラットフォームのページで、Attack Signal Intelligence™が同様の課題にどのようにアプローチしているかが説明されています。