Google Security Operations (Chronicle)

解決する課題

セキュリティ侵害は「ログはあったのに気づけなかった」「調査に何時間もかかった」という形で被害が広がります。Google Security Operations（旧称 Chronicle）は、組織中のセキュリティテレメトリを1か所に集め、正規化したうえで高速に検索・検知・対応できるようにしてこの問題に答えます。

• ログが各システムに分散し、攻撃の全体像を追えない → 多様なソースのログを一元集約し、共通スキーマで正規化
• 過去のログを遡って調査したいが、保管も検索も重い → 長期保管されたデータを横断的に高速検索
• 既知の脅威かどうかの判断に時間がかかる → 脅威インテリジェンスと自動で突き合わせて優先度付け
• 検知できても対応が手作業で後手に回る → SOAR によるプレイブックで初動対応を自動化

クラウドをまたいだ大量ログの集約・分析という点では、AWS の Security Lake やログ分析型 SIEM と重なる領域を担います。

主要概念と用語

• SIEM（Security Information and Event Management）: ログを集約・正規化し、相関分析して脅威を検知・調査する仕組み。Google Security Operations の中核
• SOAR（Security Orchestration, Automation and Response）: 検知後の対応を手順化（プレイブック）し、調査・封じ込め・チケット起票などを自動化する領域
• UDM（Unified Data Model）: 取り込んだ多様なログを揃える共通スキーマ。出所が違っても同じフィールドで検索・分析できるようにする正規化の要
• パーサー: 各ソースの生ログを UDM に変換する変換ロジック。標準パーサーのほか、独自フォーマット向けにカスタムも定義できる
• 取り込み（Ingestion）: フォワーダー、API、フィード、各種コネクタ経由でログを Google Security Operations に流し込む経路
• 検知ルール（YARA-L）: イベントの相関や閾値、脅威条件を記述する検知言語。リアルタイム検知と過去データへの遡及検知に使う
• 脅威インテリジェンス: 既知の悪性 IP・ドメイン・ハッシュなどの情報。取り込んだログと突き合わせて該当を浮かび上がらせる
• ケース / アラート: 検知結果をまとめた調査の単位。SOAR 側でプレイブックを回し、対応状況を管理する

仕様・制限・クォータ

• 多様なログソースを取り込む前提で、クラウド・オンプレ・ネットワーク機器・EDR・SaaS などのテレメトリを集約する。取り込んだログは UDM に正規化される
• 長期間の保管と高速検索を特徴とし、過去に遡った調査や遡及検知ができる。具体的な標準保管期間は変動するため公式ドキュメントで確認する
• エディションや組み合わせによって機能範囲が異なる。SIEM 機能を中心とした構成と、SOAR や高度な脅威ハンティングまで含む構成があり、含まれる機能が変わる
• 取り込み・検知・対応が連携する設計で、検知ルール（YARA-L）やプレイブックは利用者側で定義・拡張できる
• 取り込み量の課金単位・上限、リージョン対応、保管期間などの具体的な数値は変動するため、最新は公式の情報で確認する

内部の仕組み

Google Security Operations は「集める・正規化する・検知する・対応する」を大規模データに対して回し続けます。

1. 取り込み（Ingestion）: フォワーダー・API・フィード・コネクタ経由で各ソースのログを取り込む
2. 正規化（Parsing / UDM）: パーサーが生ログを共通スキーマ UDM に変換し、出所の異なるデータを同じフィールドで扱えるようにする
3. 保管と検索: 正規化済みデータを長期保管し、横断的に高速検索できる状態で保持する。過去データへの遡及調査もここで支える
4. 検知（YARA-L）と脅威照合: 検知ルールがイベントを相関・評価し、脅威インテリジェンスとの突き合わせで該当を浮かび上がらせてアラートを生成する
5. 対応（SOAR）: アラートをケースにまとめ、プレイブックで初動対応・エンリッチ・チケット起票などを自動化する

設計パターン / ベストプラクティス

• 取り込みソースを広く揃える: クラウド監査ログ・ネットワーク・EDR・ID 基盤など、調査に効くテレメトリを早期に取り込み、死角を減らす
• パーサーを整える: 主要ソースが UDM に正しく正規化されているかを確認し、独自フォーマットはカスタムパーサーで補う
• 検知ルールを段階的に育てる: まず標準的な検知から始め、自組織の脅威モデルに合わせて YARA-L ルールを追加・調整する
• 脅威インテリジェンスを活用: 既知の悪性インジケータと自動照合し、優先度の高いアラートを先に拾う
• SOAR で初動を自動化: 繰り返しの調査・エンリッチ・封じ込めをプレイブック化し、対応時間を短縮する
• 遡及検知を使う: 新しい脅威情報が出たら、過去ログに遡ってルールを適用し、見逃しを洗い出す

運用・監視

• 取り込みの健全性を監視: 想定ソースのログが途切れていないか、取り込み量や遅延を継続的に確認する
• 検知ルールのチューニング: 誤検知・過検知を見ながらルールを調整し、ノイズと見逃しのバランスを取る
• ケースのトリアージ: アラートを重大度・対象で絞り込み、SOAR のプレイブックで初動から対応完了まで状況を管理する
• 他サービスと突き合わせ: Security Command Center の Finding や Cloud Audit Logs と組み合わせ、態勢情報と監査証跡をあわせて調査する
• 対応の振り返り: クローズしたケースを分析し、検知ルールやプレイブックの改善に反映する

コスト

料金は主に取り込むログの量や採用するエディション・機能範囲に左右されます。一般に、SIEM 中心の構成から SOAR や高度な脅威ハンティングを含む構成になるほど機能が増えます。取り込み量が増えれば保管・処理のコストも増える傾向があるため、調査価値の高いソースを優先して取り込むのが基本です。具体的な金額・課金単位は変動するため、最新は公式の料金情報で確認してください。

セキュリティ

• アクセスを最小権限で絞る: 集約されたログとアラートは機微な情報の塊。閲覧・調査・対応の権限を IAM で分離し、広域ロールを避ける
• 取り込み経路を保護する: フォワーダーや API キーなどの取り込み経路の認証情報を厳重に管理し、不正なログ注入を防ぐ
• 検知と対応をつなぐ: 検知しただけで終わらせず、SOAR のプレイブックで封じ込め・通知・チケット起票まで回して対応漏れを防ぐ
• 監査証跡と併用する: Cloud Audit Logs と突き合わせ、誰が何をしたかを含めて調査の精度を高める

関連サービス・比較

態勢管理と脅威検知を集約する Security Command Center とは役割が異なります。SCC が「設定ミスや態勢の弱点と脅威 Finding を可視化する」のに対し、Google Security Operations は「大量のログを取り込み、正規化して脅威を調査・検知し対応まで回す SIEM/SOAR」です。両者は連携して使うと補完的に機能します。

ハンズオン / CLI例

Google Security Operations の検知ルール作成や調査は主に専用コンソールと API で行います。ここでは関連する gcloud 操作の例として、調査の前提になる組織や監査ログ周りの確認コマンドを示します。

# 組織 ID を確認（セキュリティ運用の対象スコープを把握する）
gcloud organizations list

# 取り込み元になりうる監査ログ設定（IAM ポリシー）を確認
gcloud organizations get-iam-policy ORGANIZATION_ID

# Cloud Audit Logs を一覧し、調査に使う監査証跡の有無を確認
gcloud logging logs list --project=my-project

# 重大度の高い監査ログを抽出（脅威調査の出発点として使う）
gcloud logging read 'severity>=ERROR' \
  --project=my-project \
  --limit=20 \
  --format=json