はじめに
先日、Professional Security Operations Engineer試験を受けてきました！
今回はその振り返りも兼ねて、学習中に整理した各サービスの役割や使い分けをまとめています。
これから受験される方は、試験直前の総チェックや知識の整理にぜひ役立ててください。
Google SecOps・Google Threat Intelligence・Security Command Center の役割と使い分け
Google Cloud 環境におけるセキュリティ運用では、Google Security Operations（Google SecOps）、Google Threat Intelligence、Security Command Center、Cloud Monitoring、Cloud Audit Logs など、複数のサービスが密接に関わってきます。
本稿では、まず各サービスの全体像と守備範囲を整理した上で、「収集」「検出」「調査」「対応」という一連の運用ライフサイクルに沿って、それぞれの役割と使い分けを体系的に解説します。
ログ / テレメトリー
↓
Google SecOps SIEM
↓
検索・検出・リスク分析
↓
GTI / ATI
↓
アラート・ケース
↓
Google SecOps SOAR
↓
自動調査・対応
Google Cloud 環境
↓
Security Command Center
↓
構成ミス・脅威・ポスチャー・コンプライアンス
1. 全体像
1.1 Google SecOps
Google SecOps は、セキュリティ テレメトリーの収集から分析、調査、インシデント対応までをエンドツーエンドで支援するクラウドネイティブなセキュリティ運用プラットフォームです。主に SIEM と SOAR の2つの柱で構成されています。
SIEM
Google SecOps SIEM は、膨大なログやテレメトリーを取り込んで正規化し、高速な検索、脅威検出、脅威ハンティングを実現します。
主な機能は次のとおりです。
- データ取り込み
- パーサーと UDM
- UDM 検索
- YARA-L
- キュレーテッド検出
- IOC の一致
- リスク分析
- Retro hunt
SOAR
Google SecOps SOAR は、検出されたアラートやケースを一元管理し、オーケストレーションと自動化（プレイブック/ハンドブック）によって調査・対応業務を効率化します。
- ケース管理
- ハンドブック
- コネクタ
- インテグレーション
- リモート エージェント
- SOC ロール
- 環境
SIEM で検出
↓
アラート
↓
SOAR のケース
↓
ハンドブック
↓
対応
1.2 Google Threat Intelligence
Google Threat Intelligence（GTI）は、Mandiant のインテリジェンスや VirusTotal、Google の広大な脅威テレメトリーを統合した脅威情報基盤です。IP アドレス、ドメイン、URL、ファイル ハッシュなどの IOC（侵害指標）に加え、マルウェア、脅威アクター、攻撃キャンペーンなどの高度なコンテキストを提供します。
Google SecOps と連携させることで、外部の最新脅威情報を自社環境のテレメトリーとリアルタイムに照合できます。
1.3 Security Command Center
Security Command Center（SCC）は、Google Cloud 環境自体のセキュリティ状態（ポスチャー）を継続的に把握し、構成ミス、脆弱性、脅威、コンプライアンス違反を検出するためのサービスです。
Google SecOps がハイブリッド/マルチクラウドを含む「各種ログ・テレメトリー横断での脅威検出・調査」を担うのに対し、SCC は「Google Cloud 基盤そのものの安全性評価と脅威検知」に特化しています。
2. Google SecOps SIEM
2.1 データの取り込み
ログの取り込み方式は、データソースの種類や所在環境に応じて適切に使い分けます。
| データソース | 主な方式 |
|---|---|
| Google Cloud の標準ログ | 直接取り込み |
| オンプレミス | Bindplane エージェント |
| SaaS / EDR | データフィード |
| 独自アプリケーション | API |
Google Cloud の監査ログ（Cloud Audit Logs）、VPC フローログ、DNS ログ、ファイアウォール ログなどは、設定を行うことで「直接取り込み」が可能です。
一方、オンプレミス環境にある Windows / Linux サーバーやネットワーク機器のログ収集には、Bindplane エージェントを利用します。
オンプレミス
↓
Bindplane エージェント
↓
Google SecOps
エージェントの違い
運用時によく混同されがちな各エージェントの役割は、以下のとおりです。
| 機能 | 用途 |
|---|---|
| Bindplane エージェント | 外部環境のログを収集し、Google SecOps へ送信する |
| Ops エージェント | コンピューティング リソースのログや指標を Cloud Logging / Monitoring へ送信する |
| リモート エージェント | Google SecOps SOAR からのアクションをオンプレミス等の閉域環境で実行する |
「Bindplane エージェント」が外部から SecOps へのデータ入力（インバウンド）を担うのに対し、「リモート エージェント」は SecOps から外部環境への操作実行（アウトバウンド）を担います。
2.2 パーサーと UDM
Google SecOps では、多種多様なベンダー製品のログを取り込む際、共通のデータ構造である「統合データモデル（Unified Data Model: UDM）」へと正規化します。
製品ごとにフォーマットが異なる送信元 IP アドレスの表記（例: src_ip、sourceAddress、client_ip など）も、UDM の共通フィールド（例: principal.ip）へと統一してマッピングされます。
src_ip
sourceAddress ──(正規化)──> principal.ip
client_ip
パーサー
パーサーは、収集した未加工ログ（Raw Log）を構文解析し、UDM レコードへと変換する役割を担います。
未加工ログ
↓
パーサー
↓
UDM
パーサー拡張機能
Google が提供する事前構築済みパーサーをベースにしつつ、独自のログ形式や未対応のフィールドを追加抽出したい場合は、「パーサー拡張機能」を利用してマッピングを補完します。
事前構築済みパーサー
+
パーサー拡張機能
↓
必要な UDM フィールド
単純な JSON 構造からの値抽出であればノーコードで設定でき、正規表現などを用いた複雑な変換処理にはコード（Logstash 構文ベース）を用いて柔軟に対応できます。
2.3 イベントとエンティティ
Google SecOps で扱うデータは、大きく「イベント」と「エンティティ」に分かれます。
- イベント（何が起きたか）: 特定の時点で発生したアクションの記録（例: ログイン、プロセスの起動、ファイルの作成、ネットワーク接続など）
- エンティティ（誰が・何が関係しているか）: 調査や識別の対象となる実体（例: ユーザー、アセット/端末、IP アドレス、ドメイン、ファイル ハッシュなど）
エンティティは人（ユーザー）だけを指すのではなく、調査対象となる端末やインフラ要素全般を含みます。
principal と target
UDM における通信やアクションの方向性は、主に以下の概念で表されます。
-
principal: アクションの主体、通信の起点（送信元） -
target: アクションの対象、通信の宛先（送信先）
内部端末（送信元） 外部 C2（宛先）
principal.ip ──通信──> target.ip
なお、実際のフィールド定義はイベントの種別（ネットワーク通信、認証、ファイル操作など）やパーサーの実装に依存するため、個々の正規化結果を確認しながらルールを設計します。
2.4 エンティティ コンテキスト グラフ
Google SecOps は、単一のイベントログにとどまらず、エンティティ同士のメタデータや関係性（コンテキスト）を紐付け、グラフ構造で把握できます。
ユーザー
↓ 所属・利用
アセット
↓ 割り当て
IP
↓ 名前解決
ドメイン
例えば、人事・ディレクトリ情報からユーザーに対して、
department = finance
restricted = true
といったコンテキストを付与しておくことで、「財務部門かつ制限対象フラグが付いているユーザーによる深夜のログイン」のような、精度の高い検出ルールを作成できます。
First Seen / Last Seen / Prevalence
エンティティの異常性を判断する重要な指標として、以下の概念が組み込まれています。
-
first_seen_time: 環境内でそのエンティティを初めて観測した日時 -
last_seen_time: 環境内でそのエンティティを最後に観測した日時 - Prevalence（普及度/希少性）: そのエンティティが組織内でどれくらい一般的か（または珍しいか）
接続先: new-c2.example
First Seen: 今日（初めて観測）
Prevalence: 非常に低い（社内でこの端末しかアクセスしていない）
上記のような通信は、優先度の高い調査候補として浮かび上がります。「いつ初めて出現したか（新規性）」と「組織内でどれほど珍しいか（希少性）」は、脅威判定における重要な判断軸です。
2.5 検索
UDM 検索
正規化された UDM フィールドを指定してクエリを実行します。異なるベンダー製品のログであっても同一の UDM フィールドにマッピングされているため、製品固有の差分を意識せずに横断検索が可能です。
未加工ログ
収集されたオリジナルの生ログを直接確認したい場合に使用します。
主な用途は以下のとおりです。
- パーサー開発時やトラブルシューティングでの検証
- UDM にマッピングされていない固有フィールドの確認
- 監査やフォレンジック観点でのオリジナル文字列の確認
正規化済みデータを横断調査したい
→ UDM 検索
パース前の元データそのものを確認したい
→ 未加工ログ
2.6 YARA-L 2.0
YARA-L は、Google SecOps における柔軟な検索や脅威検出ルールの記述に用いられるルール言語です。
ルールは主に以下のセクションで構成されます。
| セクション | 役割 |
|---|---|
events |
検出対象とするイベントやエンティティの条件 |
match |
複数イベントを紐付けるキー（ユーザーや IP など）と時間枠（タイムウィンドウ） |
outcome |
リスクスコアや調査用変数などの出力値の定義 |
condition |
アラートを生成するための成立条件（しきい値など） |
YARA-L の最大の強みは、複数のイベントを時間軸で相関分析できる点にあります。例えば、「同一ユーザーが、10分以内に、地理的に離れた複数の国からログインに成功した」といった複雑な攻撃シナリオを簡潔に表現できます。
単一のイベントのみで完結する検知であれば単一イベントルール、前後の文脈や複数の振る舞いを追跡する場合は相関ルールを活用します。
2.7 キュレーテッド検出と Retro hunt
キュレーテッド検出
Google の脅威インテリジェンスチームが作成・管理する、事前構築済みの検出ルールセットです。自社でルールを一から作成することなく、最新の脅威パターンや攻撃手法を即座に検出できます。
一般的な脅威・最新の攻撃手法
→ キュレーテッド検出（Google 管理）
社内システム固有のルール・業務例外への対応
→ カスタム YARA-L ルール（自社管理）
運用の現場では、この両者をバランスよく組み合わせて利用します。
Retro hunt
新しく追加・修正した検出ルールを、過去にさかのぼって取り込み済みのログデータに適用し、再スキャンを実行する機能です。
新たなゼロデイ脆弱性や IOC が公開された際、「過去のログにすでに侵入の痕跡が含まれていないか」を即座に振り返って検証できます。
2.8 データテーブルとウォッチリスト
データテーブル
外部システムや自社定義のカスタムデータを複数列のテーブル構造で保持し、YARA-L ルールや検索から参照できるようにする機能です。
IP 分類 重要度
192.0.2.10 scanner medium
198.51.100.20 blocked high
従来利用されていたリファレンス リストからデータテーブルへの機能移行が進んでいるため、新規で検出環境を設計する際はデータテーブルを優先的に採用します。
ウォッチリスト
リスク分析機能において、退職予定者や高権限管理者、重要資産など、特定のエンティティを重点的・継続的に監視するための機能です。
外部リスト等の静的データを検出ルールで参照したい
→ データテーブル
特定のアカウントや端末の挙動を重点監視したい
→ ウォッチリスト
3. Google Threat Intelligence と ATI
3.1 GTI と IOC
Google Threat Intelligence（GTI）は、包括的な脅威インテリジェンス情報を提供するサービスです。
検出の手がかりとなる代表的な IOC（侵害指標）には、以下のものがあります。
- 悪意のある IP アドレス
- 不審なドメイン
- フィッシング等の URL
- マルウェアのファイル ハッシュ
インテリジェンスを活用する際は、それぞれの概念を正しく区別しておくことが重要です。
脅威アクター : 攻撃を仕掛ける主体・集団
マルウェア : 攻撃に用いられる悪意あるソフトウェア
IOC : 攻撃の実行に伴って残された痕跡・識別情報
キャンペーン : 特定の目的や標的に対して展開される一連の攻撃活動
3.2 Applied Threat Intelligence
Applied Threat Intelligence（ATI）は、GTI が保有する膨大な脅威情報を、Google SecOps 内に取り込まれた自社テレメトリーへと自動的に適用・照合する機能です。
GTI の最新 IOC 情報
+
自社のリアルタイムログ
↓
自動照合
↓
IOC の一致
GTI が「脅威情報のデータベースそのもの」であるのに対し、ATI は「その脅威情報を自社データへ結び付けてリアルタイムに検出へ活かす仕組み」といえます。
3.3 IOC の一致
自社のログやテレメトリーの中に、GTI が把握している既知の悪性 IOC と合致する値が存在した場合、その検知結果は「IOC の一致」として記録されます。
GTI の情報:
悪性 IP = 203.0.113.10
自社のログ:
社内 VM ──通信──> 203.0.113.10
↓
IOC の一致（検知）
つまり、「IOC」は脅威インテリジェンス側が保持する危険な指標そのものを指し、「IOC の一致」は自社環境でその指標に該当する通信やファイルが実際に観測された事実を指します。
3.4 Fusion フィード
Applied Threat Intelligence Fusion フィードを利用すると、単一の IOC だけでなく、関連する脅威アクター、マルウェア ファミリー、キャンペーン情報といったリッチなコンテキストをあわせてルールに組み込むことができます。
IP アドレス
↓ 紐付け
脅威アクター（攻撃グループ）
↓ 利用
マルウェア
↓ 展開
キャンペーン
YARA-L を用いることで、「単に不審な IP と通信した」という条件にとどまらず、「特定の脅威アクターに関連付けられたインフラとの通信が発生した」といった、極めてコンテキストの深い検出ルールを記述できます。
※フィードの名称や構成は統廃合が行われる場合があるため、既存のルールをメンテナンスする際は、旧名称と現行 GTI フィードの対応関係を公式ドキュメント等で確認してください。
3.5 GTI と自社環境の調査
インシデント調査では、「外部視点での脅威評価」と「自社環境内での実態調査」を明確に切り分けて進めます。
「このファイル ハッシュは悪意あるものか？」
→ GTI / VirusTotal で外部評価を確認
「このファイル ハッシュは社内のどこで観測されているか？」
→ Google SecOps の UDM 検索で社内影響範囲を調査
また、SOAR 側で自動化ハンドブックを実行し、ケースに含まれる IP、ドメイン、ファイル ハッシュの評価情報を GTI や VirusTotal から自動取得して、ケースのエンティティ情報を拡充（エンリッチメント）することも可能です。
4. Google SecOps SOAR
4.1 アラート・ケース・エンティティ
アラートは各種検出システムから発報された個々の警告通知であり、ケースは SOAR における調査・対応の管理単位です。
Case（インシデント管理の単位）
├─ Alert（関連する1つ以上のアラート）
├─ Entity（関係するユーザー、IP、端末など）
├─ Timeline（発生したイベントの時系列）
└─ Actions（実行された手動・自動の対応）
関連する複数のアラートを1つのケースに集約（グルーピング）することで、アラート疲れを防ぎ、インシデントの全体像を一元的に把握できます。
4.2 ハンドブック
ハンドブックは、インシデント発生時の調査・トリアージ・封じ込めなどの一連の対応フローを自動化するワークフロー（プレイブック）です。
アラートの受信
↓
エンティティ情報の拡充（GTI / VirusTotal 照会）
↓
リスク判定（条件分岐）
↓
EDR による端末のネットワーク隔離
↓
IT サービス管理ツールでチケット作成
↓
ケースのステータス更新
ハンドブック内では以下の要素を組み合わせて構築します。
- 条件分岐（ロジックの振り分け）
- Expression Builder（データの抽出や加工）
- 手動アクション（アナリストによる作業の組み込み）
- 承認リンク（隔離などの重大なアクション前の管理者承認）
すべての処理を機械的に自動実行するだけでなく、重要な判断ポイントに「人の承認」を挟むワークフローも柔軟に構成可能です。
4.3 ケースのステージ
ケースには、トリアージ、評価、調査、封じ込め、修復といったライフサイクルの進行度（ステージ）を設定できます。
トリアージ ──> 評価 ──> 調査 ──> 封じ込め ──> 修復
ケースのステージ変更を正しく記録・運用することで、インシデント発生から初動対応、解決に至るまでの所要時間（MTTA や MTTR）をフェーズごとに可視化・分析できるようになります。
4.4 コネクタとインテグレーション
SOAR が外部製品と通信する際の役割は、「コネクタ」と「インテグレーション」で明確に分かれています。
コネクタ
外部製品（SIEM、EDR、メールセキュリティなど）を定期的にポーリングし、アラートやイベントを Google SecOps SOAR へ「取り込む」ためのコンポーネントです。
外部製品 ──(コネクタ)──> Google SecOps SOAR
インテグレーション
ハンドブックや手動操作によって、Google SecOps SOAR から外部製品の API を呼び出し、「操作を実行する」ためのコンポーネントです（例: EDR での端末隔離、ファイアウォールでの IP 遮断、チケットの起票など）。
Google SecOps SOAR ──(インテグレーション)──> EDR / ファイアウォール / チケットシステム
整理すると以下のようになります。
外部 ──> SecOps （データの受信） : コネクタ
SecOps ──> 外部 （アクションの実行）: インテグレーション
4.5 リモート エージェント
クラウド上の Google SecOps SOAR から、直接インターネット経由でアクセスできないオンプレミスや閉域ネットワーク内の製品（内部ファイアウォール、内部 Active Directory、DB など）を操作する際に配置する中継コンポーネントです。
Google SecOps SOAR
↓
リモート エージェント（閉域網内に配置）
↓
社内ファイアウォール / EDR / Active Directory / DB
あくまで SOAR からのアクション命令を中継・実行するためのものであり、ログ収集用のエージェントではない点に留意してください。
4.6 SOC ロール・環境・カスタム アラートビュー
マルチテナント運用やチーム内の役割分担を実現するため、以下の機能が用意されています。
SOC ロール
SOC チーム内での役割や職責（例: Tier 1 アナリスト、Tier 2 エンジニア、SOC マネージャーなど）を定義します。同じロールを複数のユーザーに割り当てることが可能です。
環境
テナント、顧客、組織、ネットワーク境界ごとに、データやケースを論理的に完全分離するための枠組みです。MSSP における顧客ごとのマルチテナント運用などに適しています。
顧客 A のデータ ──> 環境 A（Environment A）
顧客 B のデータ ──> 環境 B（Environment B）
カスタム アラートビュー
同一のケースを参照しながらも、担当する SOC ロールや目的に応じて表示する情報やレイアウトをカスタマイズする機能です。
SOC ロール : 「誰が」対応を担当するか
環境 : 「どの」組織・データ境界を扱うか
カスタム アラートビュー: 「何を」画面に表示して見せるか
5. Security Command Center
5.1 主要な検出機能
Security Command Center（SCC）は、Google Cloud リソースに対する脅威や弱点を多角的に検出します。
Security Health Analytics
Google Cloud リソースの設定状況を自動スキャンし、パブリックに公開されたストレージバケットや過剰な権限設定など、構成ミスや脆弱性を検出します。
クラウドアセットの構成上の不備
→ Security Health Analytics
Event Threat Detection
Cloud Logging のストリームログを分析し、不正な IAM 権限の昇格、悪意ある外部 IP との通信、不審な API 呼び出しなど、ログに現れる脅威を準リアルタイムに検出します。
ログから読み取れる攻撃の兆候
→ Event Threat Detection
Virtual Machine Threat Detection
Compute Engine の VM インスタンスに対してエージェントレスでメモリ解析等を行い、内部に潜むマルウェア、ルートキット、暗号資産マイニングなどを検出します。
VM 内部で実行されている脅威
→ Virtual Machine Threat Detection
5.2 検出結果
SCC が特定した構成ミスや脅威は、「検出結果（Finding）」として一元管理されます。
ここで注意すべき点は、「検出結果のステータス変更」と「クラウド環境内の実際のリソース修復」は別物であるということです。例えば、SCC の画面上で検出結果を「非アクティブ」に変更したとしても、元の危険な設定（リソースの公開設定など）そのものが修正されたわけではありません。根本的な解決には、クラウド環境上の実リソース自体を修正する必要があります。
5.3 セキュリティ ポスチャー
セキュリティ ポスチャーサービスは、組織として遵守すべき「理想的なセキュリティ構成（ベースライン）」をポリシーとして定義し、実環境がその基準から外れていないかを継続的に監視・評価する機能です。
望ましい構成ポリシーを定義
↓
ポスチャーを組織やプロジェクトへデプロイ
↓
実環境の状態を継続的に自動評価
↓
ポリシーからの逸脱（ドリフト）を検出
例えば、「本番環境の VM には外部 IP アドレスを付与してはならない」といった基準を定義し、逸脱が発生した際に即座に検知できます。
5.4 Audit Manager とコンプライアンス
Audit Manager は、PCI-DSS、NIST CSF、CIS ベンチマークなどの各種コンプライアンス フレームワークに沿って自社の Google Cloud 環境を自動評価し、監査に必要な証跡（エビデンス）の収集やレポート作成を支援する機能です。
準拠すべきフレームワークの選択
↓
監査の実行
↓
コントロール基準に対する自動評価
↓
エビデンスの収集
↓
監査レポートの自動生成
セキュリティ ポスチャーとの目的の違いは以下のとおりです。
| 目的 | 機能 |
|---|---|
| 組織固有の望ましい構成基準を定義・監視する | セキュリティ ポスチャー |
| 構成の逸脱（ドリフト）を早期に検出する | セキュリティ ポスチャー |
| 業界標準フレームワークに基づいて環境を評価する | Audit Manager |
| 監査用エビデンスを自動収集し、レポートを出力する | Audit Manager |
5.5 SCC と Google SecOps の連携
SCC と Google SecOps は競合するものではなく、相互に補完し合う関係にあります。
SCC
→ Google Cloud 特有の構成ミス・リソース上の脅威・脆弱性を検出
Google SecOps
→ オンプレ、SaaS、マルチクラウドを含む全社テレメトリーを横断して調査・自動対応
SCC で検知された検出結果を Google SecOps へ自動転送することで、クラウド固有のアラートを全社インシデントのコンテキストに統合し、SOAR のハンドブックを用いて自動修復までつなげるといった一気通貫の運用が実現します。
SCC
↓ （検出結果を転送）
Google SecOps
↓ （アラートをケース化）
ハンドブック
↓ （調査・修復の実行）
対応完了
6. 横断的な運用管理
6.1 IAM と Workforce Identity 連携
サービスや機能に対するアクセス権限は、Google Cloud の IAM によって厳密に制御されます。
IAM : 各製品機能や Google Cloud API に対する認可・権限管理
SOC ロール : SOAR 内におけるアナリストの担当業務・職責
環境 : SOAR 内での顧客・組織ごとのデータやケースの論理分離
なお、外部 ID プロバイダ（IdP）の組織内ユーザーを Google Cloud へ連携してログインさせる場合は「Workforce Identity 連携」を、外部クラウドやオンプレミスのアプリケーション・ワークロードに権限を付与してアクセスさせる場合は「Workload Identity 連携」を利用します。
6.2 取り込みの健全性
SIEM はログが正常に届いて初めてその真価を発揮します。ネットワーク障害や設定ミスによるログ取り込みの停止、パース時の異常などを迅速に検知するために、以下のツールを活用して監視を行います。
- Health Hub（SecOps 内部の取り込み・処理ヘルスチェック機能）
- Cloud Monitoring（取り込み指標やアラート通知の設定）
- 取り込み指標（Ingestion Metrics）
「ログの流入が急減・停止していないか？」
「パースエラーが多発していないか？」
→ Health Hub および Cloud Monitoring で常時監視
6.3 Cloud Audit Logs
Google SecOps 自体に対する設定変更やパーサーの更新、検出ルールの改変など、管理者による操作履歴は Cloud Audit Logs に記録されます。
「誰が、いつ、ルールの設定を変更したか？」
→ Cloud Audit Logs で管理操作を監査
「ログの取り込みパイプラインが健全に稼働しているか？」
→ Health Hub / Cloud Monitoring で状態を監視
6.4 ダッシュボードと BigQuery
可視化や分析の目的に応じて、Google SecOps の組み込みダッシュボードと BigQuery を使い分けます。
- Google SecOps ダッシュボード: 日々の SOC 運用状況、リアルタイムのアラート推移、取り込み量の把握など、日常的な可視化に適しています。
- BigQuery: 数年単位に及ぶ膨大なログの長期保存、複雑な集計処理、社内の他システムデータとの JOIN など、高度なアドホック分析に適しています。
日々の SOC 運用・状況モニタリング
→ Google SecOps ダッシュボード
年単位の長期分析・複数データソースとの横断分析
→ BigQuery
6.5 EDR と NDR
EDR
EDR（Endpoint Detection and Response）は、PC やサーバーなどの端末上でプロセス、ファイル作成、PowerShell の実行、マルウェアの挙動などを監視する製品群です。Google SecOps SIEM に EDR ログを取り込んで脅威を検知し、SOAR のハンドブック経由で EDR API を呼び出して感染端末をネットワークから自動隔離するといった連携が行われます。
NDR
NDR（Network Detection and Response）は、ネットワーク通信をパケットやフローレベルで監視・分析して脅威をあぶり出す製品カテゴリ全般を指します（Google SecOps 固有の機能名ではありません）。
Google Cloud 環境においては、VPC フローログがネットワーク分析のテレメトリーデータとなり、マネージドな侵入検知サービスとしては Cloud IDS がその役割を担います。
7. 主要機能の対応表
| 実現したい目的 | 利用する主な機能・サービス |
|---|---|
| Google Cloud の標準ログを取り込む | 直接取り込み |
| オンプレミス環境のログを収集する | Bindplane エージェント |
| 未加工ログを共通形式へ正規化する | パーサー |
| パーサーで不足しているフィールドを補完する | パーサー拡張機能 |
| 正規化された UDM ログを横断検索する | UDM 検索 |
| 複数のイベントを相関付けて脅威を検出する | YARA-L |
| Google 管理の事前構築済みルールで検知する | キュレーテッド検出 |
| 新たなルールで過去のログをさかのぼって再検証する | Retro hunt |
| 最新の脅威インテリジェンスや IOC 情報を調査する | GTI |
| 外部脅威インテリジェンスを自社ログにリアルタイム適用する | ATI |
| 自社環境で IOC と合致した事実を確認する | IOC の一致 / UDM 検索 |
| 独自の参照データをルールからルックアップする | データテーブル |
| 退職者や重要端末などの特定エンティティを重点監視する | ウォッチリスト |
| 外部製品のアラートを SOAR へ取り込む | コネクタ |
| SOAR から外部製品の API を操作・実行する | インテグレーション |
| 閉域網やオンプレミス環境でアクションを実行する | リモート エージェント |
| SOC チーム内の担当レベルや役割を定義する | SOC ロール |
| 顧客や組織ごとにケースやデータを論理分離する | 環境 |
| 担当ロールごとにケースの画面表示内容を切り替える | カスタム アラートビュー |
| Google Cloud のリソース構成ミスを検出する | Security Health Analytics |
| Google Cloud のイベントログから脅威の兆候を検出する | Event Threat Detection |
| VM の内部（メモリ等）に潜む脅威を検出する | Virtual Machine Threat Detection |
| セキュリティ基準からの逸脱（ドリフト）を継続監視する | セキュリティ ポスチャー |
| 業界標準フレームワークに沿った監査とエビデンス収集を行う | Audit Manager |
| ログの取り込み停止やパース異常を監視する | Health Hub / Cloud Monitoring |
| SecOps 自体の設定変更や管理操作を監査する | Cloud Audit Logs |
| ログの長期横断分析や他データとの突合集計を行う | BigQuery |
まとめ
Google Cloud のセキュリティ運用は、各サービスが担当するレイヤーと役割を明確に切り分けて捉えることで、全体像をシンプルに整理できます。
Google SecOps SIEM
→ テレメトリーの収集・正規化・検索・検出
Google Threat Intelligence / ATI
→ 脅威インテリジェンスの提供・IOC の自動照合・脅威コンテキストの付与
Google SecOps SOAR
→ アラートのケース化・トリアージ・ハンドブックによる対応自動化
Security Command Center
→ Google Cloud 環境自体の構成ミス・脅威・ポスチャー・コンプライアンス管理
Cloud Monitoring / Cloud Audit Logs / IAM / BigQuery
→ システム監視・監査証跡・アクセス制御・高度なデータ分析
その上で、SIEM は「取り込み → UDM 正規化 → 検索・検出」、SOAR は「アラート → ケース集約 → ハンドブック自動化 → 封じ込め対応」という業務プロセスに沿って捉えることで、各機能がどのフェーズで活躍するのかを直感的に理解できるようになります。
おわりに
最後まで読んでいただき、ありがとうございました！
Google Cloud のセキュリティ関連サービスは似たような用語が多くて最初は混乱しやすいですが、
それぞれの「役割」と「範囲」を意識して整理してみください。
この記事が皆様のお役に立てば幸いです。