過去2年間で最も重大な影響を与えたクラウドセキュリティ侵害は、malware始まったものではありません。その発端はログインでした。攻撃者は有効な認証情報や承認済みのOAuthトークンを手にし、正規のアプリケーションプログラミングインターフェース（API）に対して形式の正しい呼び出しを行い、シグネチャと照合できるような不正な形式のデータは一切残しませんでした。この現実こそが、クラウドセキュリティ分析が解決すべき課題なのです。 本ガイドでは、この用語を正確に定義し、分析パイプラインの仕組みを解説するとともに、2つの典型的な侵害事例を詳細に検証してシグネチャが機能しなくなる理由を明らかにし、Amazon Web Services（AWS）、Azure、Google Cloudにおける実践手法を解説します。これには、多くの解説で省略されがちなテレメトリの経済性やフレームワークの整合性についても含まれています。
クラウドセキュリティ分析とは、クラウドネイティブなテレメトリ（コントロールプレーンの監査ログ、IDおよびトークン関連のイベント、API呼び出しパターン、ワークロードおよびフローデータなど）に検知分析を適用し、攻撃者の行動を明らかにする手法です。これは、クラウドビジネスインテリジェンスや、個々のセキュリティ情報イベント管理（SIEM）製品、さらにはクラウドセキュリティポスチャー管理（CSPM）における「静的状態」のチェックとは区別されます。
隣接する各用語は、それぞれ異なる問いに対する答えとなっています。AWSが「セキュリティ分析」と定義する広義の取り組み――脅威を検知するためにセキュリティデータを収集・分析すること――は、テレメトリ自体がクラウドネイティブであり、分析対象となる動作がエンドポイントではなくアイデンティティやAPIに属する場合、「クラウドセキュリティ分析」となります。この分野は、予防やセキュリティ態勢の管理と並んで、クラウドセキュリティの検知層として機能します。両者はデータパイプラインを共有していますが、これは決してビジネス分析ではありません。
2026年の調査結果は、この分野が今や独立した分野として確立された理由を明らかにしています。2025年下半期におけるマンディアントのインシデント対応およびマネージド脅威検知業務――主要なクラウドおよびSaaS（Software-as-a-Service）への侵入事例をプラットフォームに依存しない視点で分析した結果――では、83％の事例でIDの不正利用が根本原因となっており、73％の事例で攻撃者がデータを標的としており、脆弱性の悪用が占める割合はわずか2％にとどまりました （『Threat Horizons H1 2026』）。これらの範囲に関する注記に留意してほしい。これらの数値は調査対象となった侵入事例を示しており、すべてのテナントにおけるすべてのアラートを網羅しているわけではない。
データ漏洩の全体像は様相を呈しており、その分類の仕方も重要である。ベライゾンの『2026年データ漏洩調査報告書（DBIR）』によると、データ漏洩の31％で脆弱性の悪用が確認され、これは19年ぶりに認証情報の盗難を上回った。また、サードパーティの関与は48％に達し、前年比で60％増加した（ベライゾン DBIR 2026）。 同様に全環境を網羅するデータセットである『M-Trends 2026』によると、2025年の世界的な平均潜伏期間は11日から14日に延び、攻撃ベクトルの首位は6年連続でエクスプロイトが占め、その割合は32％であった（M-Trends 2026）。 これらを総合すると、一つの明確な事実が浮かび上がります。すなわち、すべての侵害事例においてエクスプロイトが首位を占める一方で、主要なクラウドおよびSaaSへの侵入においては、IDの悪用が支配的であるということです。IDの悪用こそが、まさにサーフェスシグネチャでは検知できない部分なのです。
これは、多くの解説で見落とされがちな重要な点であり、購入や構築すべきものを左右するものです。クラウド分析は、ビジネスインテリジェンスのパイプラインを通じて、利用状況、収益、製品の挙動といったビジネス上の疑問に答えを出します。SIEMは製品でありアーキテクチャでもあり、検知コンテンツを実行できる場です。CSPMは、攻撃者が現れる前に、保存されている設定（パブリックバケットや権限が過剰に付与されたロールなど）を評価します。 クラウドセキュリティ分析は、クラウドのテレメトリにおいて、進行中の攻撃者の行動をリアルタイムで検知します。以下の表では、これら4つの概念を区別しています。
よく混同されがちな4つの用語――クラウドセキュリティ分析は行動を検知し、クラウドBIはビジネス上の意思決定を支援し、SIEMはログを集約し、CSPMは保存中のデータのセキュリティ態勢を点検する。
クラウドセキュリティ分析は、大量のクラウドテレメトリデータを、優先順位付けされた行動ベースの検知結果に変換します。このパイプラインは、ログ名が異なる場合でもプロバイダー間で一貫性があり、以下の5つの段階に集約されます：
その基盤となるのは、クラウドネイティブなテレメトリです。コントロールプレーンの監査ログ（AWS CloudTrail、Google Cloud Audit Logs、Entra IDのサインインおよび監査ログなど）は、環境内で行われるすべての管理操作やAPI呼び出しを記録します。 IDおよびトークンイベントは、認証、権限付与、同意を捕捉します。API呼び出しパターンからは各IDが実際に何を行っているかが分かり、ワークロードおよびネットワークフローデータからはデータがどのように移動しているかが分かります。Googleのリファレンスアーキテクチャでは、セキュリティログ分析ガイダンスの中で、これを適切に実施するための運用手順――適切なログを有効化し、分析先へルーティングし、そこで分析を行う――について説明しています。
クラウドプロバイダー間でスキーマの統一が図られていないため、正規化は特に重視すべき点です。同じ概念上のイベント――つまり、特権を付与されたIDによる操作――であっても、CloudTrail、Entra IDの監査ログ、Google Cloud Audit Logsでは、その表示がまったく異なって見えます。そこで、エンリッチメントによって、アセットの重要度、IDの所有者、脅威インテリジェンスのコンテキストなど、生のイベント情報には欠けている情報が補完されます。
この分野がクラウド特有である理由は、リソースの性質にあります。 クラウドインフラストラクチャは一時的であり、API駆動型で、アイデンティティ中心です。ワークロードの存続時間は数分単位であり、あらゆるアクションはAPI呼び出しであり、アイデンティティが事実上の境界となります。したがって、検知のシグナルとなるのは、不正なペイロードではなく、学習されたベースラインからの行動の逸脱です。そのため、ユーザーおよびエンティティ行動分析（UEBA）がこの分野の中心に位置し、ネットワーク異常検知では、ワークロード間でやり取りされるトラフィックに対しても、同様のベースライン設定ロジックが適用されるのです。
最後の2つの段階こそが、アナリティクスが運用面で真価を発揮する場面です。相関分析により、個別のイベント（新しいログイン、権限の変更、データ読み取りの急増など）が1つの攻撃シナリオとして結びつけられ、優先順位付けによって、そのシナリオが注目を競う他のすべての事象と比較してランク付けされます。 これが適切に行われれば、アラート疲労の特効薬となります。また、アナリストが生のイベントストリームではなく、短く優先順位付けされたリストから分析を開始するため、ほとんどのセキュリティオペレーションセンター（SOC）の評価指標となる「平均検知時間（MTTD）」と「平均対応時間（MTTR）」という2つの数値を最も大きく改善する要因でもあります。
攻撃者が盗んだ有効な認証情報や承認済みのトークンを使用して認証を行う場合、行動分析が唯一の検知手段となることがよくあります。シグネチャは、malware 、エクスプロイトのペイロード、悪意のあるドメインなど、既知の悪意ある要素と照合されます。しかし、承認済みのAPIを介してログインが成功した場合、こうした要素は一切生成されません。認証の失敗もなければ、バイナリファイルのドロップもなく、検査すべきエクスプロイトトラフィックも存在しないのです。これが、シグネチャのみに依存するツールや、ルールのみに基づくSIEMの導入において共通して見られる盲点です。
UNC5537として追跡されている、2024年のSnowflake顧客環境を標的とした攻撃キャンペーンは、典型的な事例である（Google Threat IntelligenceによるUNC5537の分析）。 攻撃者は、 malwareによって盗まれた認証情報（その79.7％は過去に流出したものであり、一部は4年間も更新されていなかった）を、多要素認証（MFA）やネットワークの許可リストが設定されていないアカウントに対して使用した。約165の組織に通知が行われた。脆弱性が悪用された事実はなく、malware プラットフォームにmalware なかった。攻撃者のすべての行動は、認証済みで形式の整ったクエリであった。
その結果、防御側には3種類のシグナルが残されました。いずれも行動に基づくもので、ログイン間の不自然な移動、見慣れないクライアントアプリケーションやフィンガープリント、そしてアカウントの基準値を大幅に超えるクエリ量です。これらの基準値に基づいて構築された行動分析と、各アカウントの通常の認証方法を評価するID分析を組み合わせたものが、被害者が欠いていた基本的な予防策と並んで、検知エンジニアリングにおける解決策となります。
UNC6395として追跡された2025年のSalesloft Driftインシデントは、パスワードからトークンへと教訓の範囲を広げた（Google Threat IntelligenceのUNC6395分析）。攻撃者はDrift連携からOAuthトークンを不正取得し、それを利用して多数のSalesforce顧客インスタンスに対して適切に構成されたSOQL（Salesforce Object Query Language）クエリを実行した――一次報告書では単に「多数」としか記載されていない。 個々のリクエストに不正な形式のものはありませんでした。手がかりとなったのは、API呼び出し量、クエリの形状、およびユーザーエージェントなど、統合機能の確立されたベースラインからの逸脱といった、集計データや行動パターンでした。これが、ID脅威検知・対応（ITDR）プログラムにおいて、非人間の統合機能を第一級のIDとして扱う理由です。
この傾向は2026年に入っても、2つの異なる経路で続いている。2026年7月の報告によると、ShinyHuntersの恐喝エコシステムに関連する、1年にわたるOAuth悪用攻撃の波が確認された（The Hacker News）。また、別のphishing 、被害者にEntra IDへの攻撃者管理下のパスキーの登録を誘導し、phishing制御機能を、持続的な足掛かりへと変貌させていた（Help Net Security）。 異なる手口ながら、検出上の課題は共通している。すなわち、有効な認証情報（トークン、セッションクッキー、パスキー）が、正規のAPIを呼び出しているという点だ。
クラウド環境においても、重要なスコープラベルを伴うエクスプロイトは依然として発生しています。マンディアントの調査データとは異なるGoogle Cloud独自のプラットフォームテレメトリによると、侵入経路としてのリモートコード実行（RCE）の割合は、2025年上半期の2.9％から下半期には13.6％へと増加しました（『Threat Horizons H1 2026』）。
実際に悪用が発生した場合、シグネチャの配布よりも武器化の方が先行します。React2Shell（CVE-2025-55182）は、React Server Components に存在する認証前のリモートコード実行（RCE）脆弱性であり、共通脆弱性評価システム（CVSS）で最高値の10.0と評価されています（Reactセキュリティアドバイザリ）。 この脆弱性は、公開から約48時間以内に実際に悪用され始めました。サイバーセキュリティ・インフラセキュリティ庁（CISA）は、アドバイザリ発表の2日後の2025年12月5日、悪用が確認されているという証拠を根拠に、この脆弱性を「既知の悪用済み脆弱性」カタログに追加しました（CISAアラート）。行動分析も、そのギャップの一部を埋める役割を果たします。例えば、突然クリプトマイナーを起動するワークロードは、シグネチャが配信される前にそのベースラインから逸脱してしまうからです。
この単一の分析コアが、一連のユースケースを支えています。各ユースケースは、シグネチャだけでは回答できない行動に関する問いを投げかけています。SOCアナリストはこれらの検知結果をトリアージに活用し、脅威ハンターは仮説検証に、コンプライアンスチームは監視範囲の証拠として活用しています。その結果、早期検知、誤検知の低減、調査期間の短縮が実現します。これらはすべて、パイプラインのベースライン設定段階に基づいています。
このうち2つは、調査の基盤となるため特に強調すべきです。クラウドにおけるデータ流出の検知は、主にクエリとデータ流出の問題です。Snowflakeを標的としたキャンペーンでは、アカウントのベースラインを大幅に上回るクエリ量やパターンが、持続的なシグナルとして機能していました。また、エンリッチメントは異常を判断材料へと変換します。つまり、その発生源となるインフラストラクチャがすでにクレデンシャルスタッフィング攻撃と関連付けられている場合、同じログインでも異なるスコアが付けられることになります。
現在、ほとんどのクラウド環境において、サービスアカウント、APIキー、OAuthトークンの数は、人間の数をはるかに上回っています。 クラウドセキュリティアライアンス（CSA）が公開した、Tenableが作成した2026年の分析によると、マシンIDと人間IDの比率はおよそ100対1となっています。また、Tenableの『2026年クラウドおよびAIセキュリティリスクレポート』では、組織の65％が、所有者も、更新も、監視もされていない「ゴースト」と呼ばれる忘れ去られたクラウド認証情報を抱えていることが別途明らかになりました。
それらの「幽霊」は単なる仮説上の存在ではありません。UNC5537キャンペーンの背景にある、何年も前から更新されていない認証情報は、まさにそのカテゴリーに属していました。 また、非人間的なIDは人間の行動とは全く異なる——勤務時間もなく、移動もなく、アクセスパターンも極めて規則的である——ため、人間のUEBAとは別の独自の基準が必要となる。サービスアカウントが突然対話型で認証を行ったり、アクセス範囲を拡大したり、新しいデータセットを照会したりする行為は、クラウドセキュリティ分析が生み出す検出信号の中でも最も強いものの一つである。
SIEMは分析を実行できるプラットフォームであり、クラウドセキュリティ分析とは、そこで実行される行動検知機能のことです。これらは競合するものではなく、互いに補完し合う関係にあります。この点を混同すると、不要な製品を二重に購入したり、ログ集約機能だけでクラウド攻撃を検知できると誤解したりするなど、大きな損失につながります。以下の表では、購入者が直面する関連するプラットフォームのカテゴリーも含め、その境界線を明確に示しています。
クラウドセキュリティ分析は機能の一種であり、SIEM、CDR、CNAPPは、その機能が動作する、あるいは組み込まれている製品やプラットフォームです。
SIEMプラットフォームは、依然として多くのチームにとって、データの集約、相関分析、コンプライアンス対応の基盤となっています。そして、まさにそこが重要な点なのです。つまり、製品に関する問題と機能に関する問題は別物なのです。クラウド検出・対応（CDR）プラットフォームは、機能面の問題に直接答えるものであり、検出コンテンツの管理を外部に委ねたいチーム向けに、クラウドネイティブな行動分析と対応アクションをパッケージ化しています。実務上の関係は、多くの場合、コストを通じて成り立っています。チームはクラウド分析を活用して、どのテレメトリデータをSIEMに取り込むべきか、どのデータをより安価なストレージに振り分けるべきかを判断しており、このトレードオフについては次のセクションで定量的に説明します。
ここに挙げた頭字語は、競合関係ではなく、その適用範囲を表しています。クラウドネイティブ・アプリケーション保護プラットフォーム（CNAPP）は、アプリケーションのライフサイクル全体にわたるセキュリティ態勢とワークロード保護を統合したものです。CSPMは保存中の設定を評価し、クラウド・ワークロード保護プラットフォーム（CWPP）はコンピューティング層を保護し、クラウド・インフラストラクチャ権限管理（CIEM）は、誰が何を行えるかを管理します。 これらはいずれも行動検知に取って代わるものではなく、攻撃対象領域を縮小・可視化し、分析ツールがそれを監視できるようにするものです。2026年の「ID主導型の侵入証拠」では、マンディアントの調査案件において、主要なクラウドおよびSaaS関連のインシデントの83％がIDに起因していることが示されており（『Threat Horizons H1 2026』）、これらすべてのカテゴリーがIDの行動に収束し続けている理由を説明しています。
市場はすでに、「機能か製品か」という問いに対して答えを出しています。スタンドアロンのクラウドセキュリティ分析製品は、繰り返し販売終了となるか、より広範な検知・セキュリティ態勢管理プラットフォームに統合されてきました。この用語を、アーキテクチャ図上の単なる「ボックス」としてではなく、SIEM、セキュリティデータレイク、あるいはCDRプラットフォームなどにおいて、自らが求める機能の一つとして捉えるべきです。
クラウドセキュリティ分析の有効性は、維持できるテレメトリの量に左右されます。データ取り込みコストは、テレメトリを大量に必要とするあらゆるアーキテクチャに対して実務者が抱く主な懸念事項であり、これがセキュリティデータレイクが存在する率直な理由でもあります。つまり、安価なストレージと選択的な検知を分離するためです。
データ量は予算の伸びを上回るペースで増加しており、すべてのログが費用に見合う価値があるわけではありません。データアクセス監査ログは典型的な例です。Googleの実装ガイダンスでは、データをルーティングする前にデータアクセス監査ログの量を適切に管理することに特に重点が置かれています（セキュリティログ分析ガイダンス）。 ここで重要なのが、テレメトリの選別です。コントロールプレーンおよびID関連のログは、1ギガバイトあたりの検知価値が最も高い一方で、詳細なデータプレーンのログは、資産の価値に見合う場合にのみ取り込みが行われます。この選別作業こそが、環境が拡大する中でもクラウドセキュリティの監視を持続可能なものにする鍵なのです。
リテンション・ティアリングにより、データ取り込みと検知のトレードオフが解消されます。ライブ検知テレメトリは「ホット」に、調査用テレメトリは「ウォーム」に、ハンティング用テレメトリは「コールド」に保持します。コールド状態でも検索は可能ですが、価格はアーカイブストレージと同等となります。
階層型保存により、すべてのデータに対してホットストレージの料金を支払うことなく、価値の高いテレメトリデータをインシデントハンティング用に検索可能な状態に保つことができます。
データ保持期間は、単なるコンプライアンス上のチェック項目ではありません。調査でどのような情報を確認できるかを決定づけるものです。UNC5537キャンペーンの際、Snowflakeのデフォルトのデータ保持期間により、調査担当者は365日分のアカウント活動履歴を調査対象とすることができました（UNC5537調査）。データ保持期間が短い組織では、復元できる履歴が単純に少なくなります。
ベンチマークは、その重要性を浮き彫りにしています。ポネモン研究所の「データ侵害のコスト」調査によると、2025年の世界平均は444万ドル、侵害の特定と封じ込めに要する日数は241日とされています。これはあらゆる環境を対象とした数値であり、2026年版も間もなく発表される予定です（Help Net Security）。クラウドの是正措置にかかる期間も、同様の緊急性を示しています。 Push Securityによる2026年版DBIRのクラウド調査結果の分析によると、サードパーティ組織のうち、クラウドにおける多要素認証（MFA）の脆弱性を完全に是正していたのはわずか23％にとどまり、組織の中央値では、パスワードおよび権限設定の誤りの発見事項の50％を解決するのに8か月を要していた（Push Security）。
テレメトリの名称はプロバイダーごとに異なりますが、確認すべき事項は変わりません。Googleのリファレンスアーキテクチャでは、すべての環境が対応すべき質問群が定義されています。具体的には、ログインおよびアクセスの異常、権限の変更、プロビジョニング活動、データアクセス、ネットワークパターンなどです（セキュリティログ分析のガイダンス）。以下の表では、これらの質問を各プロバイダーの主要な情報源に対応付けています。
コントロールプレーンおよびIDテレメトリのデータ送信が開始されれば、すべてのプロバイダーに対して、一連の行動に関する質問が同様に適用されます。
多くの企業では、こうした質問に対して複数の場所で同時に回答しています。マルチクラウドセキュリティプログラムでは、プロバイダーごとのログスキーマを単一の分析レイヤーに統一するため、単一のベースラインロジックがあらゆる場所に適用されます。とはいえ、プロバイダー固有の詳細な分析も依然として有効です。例えば、AWSの脅威検知では、CloudTrailのデータイベントやフローログを管理プレーン上に重ね合わせることで、アカウントレベルのログでは捕捉できない情報を検出しています。
コンテナは、クラウドをまたぐワークロードの攻撃対象領域を生み出します。Kubernetesの監査ログやランタイムイベントは、クラスターがどこで実行されていても同じ形式であるため、Kubernetesのセキュリティテレメトリは自然な統合要素となります。また、ワークロードがデータセンターやクラウドにまたがるハイブリッドクラウドのセキュリティアーキテクチャにおいても、同じベースラインを適用することが可能になります。
その背後にあるワークロードだけでなく、IDプロバイダー（IdP）自体も監視してください。 Entra IDにおける2026年のなりすまし脆弱性「CVE-2026-40379」は、CVE番号付与機関（CNA）から9.3、米国国立標準技術研究所（NIST）から7.5の評価を受けています（NVDレコード）。IdPが標的となった場合、IdP自身のサインインおよび監査テレメトリが検知対象となります。
2026年4月28日にMITRE ATT&CK 、回避のモデル化方法が再構築されました。従来の「Defense Evasion」戦術は廃止され、「Stealth」（0005) および 防御機能の障害（0112) — 後者は、防御側が何が起きているのかを確認したり信頼したりできないように、セキュリティメカニズムやパイプライン、ツールを破る攻撃者を指す。その ATT&CKクラウドマトリックス 「Office Suite」、「Identity Provider」、「SaaS」、および「IaaS（Infrastructure as a Service）」という4つのプラットフォームにわたる12の戦術を網羅しており、検出エンジニアに対し、本ガイドで説明する行動に関する共通の用語体系を提供します。
ATT&CK v19のクラウド戦術から、クラウドセキュリティ分析によって実現可能な行動ベースの検知へと至る道筋を示すマップです。
コンプライアンス・マッピングは、その自然な延長線上にある。2024年に公表されたNISTサイバーセキュリティ・フレームワーク（CSF）2.0において、この実践は、フレームワークの6つの機能のうちの1つである「検出（Detect）」機能内の、DE.CMおよびDE.AE（NIST）のカテゴリーに分類される。 17のドメインにわたり197のコントロールからなるCSAクラウド・コントロール・マトリックスv4では、「ロギングおよびモニタリング（LOG）」ドメインにおいて、これと同等の要件が定められています（CSA CCM）。
NIS2（指令（EU）2022/2555）の第23条では、重大なインシデントを認識してから24時間以内に早期警告を行い、72時間以内にインシデント通知を行い、1か月以内に最終報告書を提出することが義務付けられています。DORA（規則（EU）2022/2554）は、2025年1月17日よりEUの金融機関に適用されており、これほど厳しい報告期限は、検知の迅速さを極めて重視していることを如実に示している。
この分野では、3つの動きに収束しつつあります。検知は「アイデンティティファースト」へと移行しています。これは、検証済みの証拠がそれを示唆しているためです。マンディアント社の2025年下半期の調査データ（『Threat Horizons』2026年上半期版）によると、主要なクラウドおよびSaaSへの侵入の83％は、アイデンティティが根本原因でした。 スタンドアロンの分析ツールは、SIEMがホストするコンテンツパックからクラウド型検知・対応プラットフォームに至るまで、プラットフォームへの統合が進んでいる。また、AIを活用したトリアージやハンティングが標準化しつつある。これは、人員の限られたチームでは、クラウドのスピードに合わせて複数の領域にまたがる挙動を手作業で結びつけることができないためである。
購入者にとって、堅牢なプラットフォームと単なるダッシュボードを区別する基準は3つあります。クラウド、ID、SaaS環境全体にわたる統合的な可視性を備えたものを選びましょう。認証情報が盗まれた後も機能し続ける行動ベースの検知機能――つまり、ID脅威の検知・対応テスト――を徹底して求めましょう。そして、アラートの数よりもシグナルの質を重視し、少人数のチームが実際に調査できる範囲を基準に判断してください。
Vectra AIは、「侵害済みと仮定する」というスタンスからクラウドセキュリティ分析に取り組んでいます。攻撃者が有効なIDを悪用して侵入してくるケースが増加しているため、この手法では、ネットワーク、ID、クラウド、SaaSにわたる攻撃シグナルの明確さを最優先し、有効な認証情報の悪用では決してトリガーされないシグネチャではなく、アクティブな攻撃者の存在を明らかにする行動を浮き彫りにします。 実際には、これは人間およびマシンを問わずすべてのIDのベースラインを確立し、各領域における逸脱を1つの攻撃シナリオとして統合し、膨大なアラート量の中から、実際の攻撃の進行を示す少数のシグナルを優先的に抽出することを意味します。
クラウドセキュリティ分析が独自の名称を持つのは、クラウドによって検知すべき対象が変化したためです。有効な認証情報やトークンを用いて侵入してくる攻撃者は、シグネチャによる検知を完全に回避します。2024年および2025年に発生した代表的なセキュリティ侵害事例では、malwareエクスプロイトもログイン失敗も確認されず、ベースラインから逸脱した行動のみが確認されました。その解決策は、単一の製品ではなく、一連の取り組みにあります。重要なコントロールプレーン、ID、API、およびワークロードのテレメトリデータを収集してください。 人間・機械を問わず、すべてのアイデンティティのベースラインを確立しましょう。コストを抑えつつ脅威ハンティングを継続できるよう、データ保持期間を段階的に設定します。検知結果を、ATT&CK v19のクラウドマトリックスや監査担当者が認識するフレームワークにマッピングします。クラウドセキュリティ分析を、実行環境を問わず「能力」として捉えるチームこそが、従来のシグネチャでは検知できない攻撃者を今後も見つけ出し続けるでしょう。
いいえ。クラウド分析といえば、ほとんどの場合、ビジネスインテリジェンスを指します。つまり、クラウドデータを抽出・変換・可視化し、収益や利用動向といったビジネス上の課題に対する答えを見出すことです。一方、クラウドセキュリティ分析では、検出分析をクラウドのテレメトリ（監査ログ、ID関連イベント、APIパターンなど）に適用し、攻撃者の行動を特定します。この2つはデータインフラストラクチャを共有している以外には共通点がほとんどなく、これらを混同することが、この用語に関する最も一般的な誤解となっています。
SIEMとは、あらゆるソースからのログを集約、保存、相関分析するための製品およびアーキテクチャです。クラウドセキュリティ分析とは、クラウドネイティブなテレメトリに適用される検知機能のことです。この機能は、SIEM内、セキュリティデータレイク上、あるいはクラウド検知・対応（CDR）プラットフォーム内で実行できるため、両者は競合するものではなく、互いに補完し合う関係にあると言えます。
これは、すべてのIDについて正常な行動パターンを基準として設定し、そこから逸脱した行為（不可能な移動、見慣れないクライアントのフィンガープリント、異常なAPI呼び出し量、あるいはそのアカウントがこれまで生成したことのないクエリのパターンなど）を検知します。有効な認証情報や有効なトークンを悪用する攻撃では、malware生成やエクスプロイトの実行、認証失敗イベントは発生しないため、シグネチャやルールによる検知は機能しません。学習された行動基準からの逸脱こそが、防御側にとって利用可能な唯一のシグナルとなる場合が少なくありません。
4つの主要なデータソース。コントロールプレーンの監査ログ（AWS CloudTrail、Google Cloud Audit Logs、Entra IDのサインインおよび監査ログ）に加え、IDおよびトークン関連のイベント、API呼び出しパターン、ワークロードおよびネットワークフローデータが含まれます。Kubernetesの監査イベントおよびランタイムイベントにより、コンテナへの対応範囲が拡大されます。まずは、取り込まれた1ギガバイトあたりの検出価値が最も高いコントロールプレーンおよびID関連のログから始めましょう。
クラウドセキュリティポスチャー管理（CSPM）は、保存状態の構成を評価します。たとえば、「このストレージバケットは公開されているか」「あのロールには過剰な権限が与えられていないか」といった点です。一方、クラウドセキュリティ分析は、時間の経過に伴うアクティブな挙動を検知します。例えば、「このIDが現在、データを不正に流出させていないか」といった点です。ポスチャー管理ツールは侵入前に攻撃対象領域を縮小し、分析ツールはそれでも侵入した攻撃者を特定します。成熟したクラウドプログラムでは、同じテレメトリデータに基づいて、この両方が機能することが求められます。
いいえ、むしろそれを補完するものです。アナリティクスは、ルールのみによる導入では見落とされがちなクラウドネイティブな行動検知機能を追加する一方で、SIEMは依然として堅実な集約、相関分析、コンプライアンスのレイヤーとしての役割を果たします。適切に活用すれば、アナリティクスと保存階層化を組み合わせることで、SIEMのデータ取り込みコストを削減することさえ可能です。なぜなら、チームは、どのテレメトリデータをホットストレージに保存すべきか、また、ハンティングのカバー範囲を損なうことなく、どのデータをより安価な階層に移行できるかを把握できるからです。
3つの課題が支配的です。テレメトリのデータ量と取り込みコストにより、厳しい選別と保持の判断が迫られます。複数のクラウドにまたがる一貫性のないシグナルを正規化するには、継続的なエンジニアリング作業が必要です。また、サービスアカウント、APIキー、OAuthトークンといった非人間アイデンティティについては、人間ユーザーとは別にベースラインを設定する必要があります。マシンアイデンティティの数は人間をはるかに上回り、忘れられた認証情報は長年にわたって残存するため、所有者が不明なアイデンティティは依然として最も一般的な死角となっています。
