はじめのProfessional Security Operations Engineer 認定取得講座⑫Google SecOpsのパーサー拡張機能とCBNマッピングを解説、Google SecOpsのIngestion API移行とudmeventsを解説、Google SecOpsのSilent Source Detectionを解説します！

クラウド

Google SecOpsでは、さまざまなサードパーティ製品から収集したログをUDM（統合データモデル）へ正規化するために、事前構築済みパーサー（Prebuilt Parser）が利用できます。しかし、製品のアップデートなどによってログ形式が変更された場合、標準パーサーだけでは新しいフィールドや形式に対応できないことがあります。

このような場合に活用できるのが、パーサー拡張機能（Parser Extensions）です。標準パーサーそのものを書き換えるのではなく、Snippet BeforeやSnippet Afterを使って必要な処理だけを追加できます。

本記事では、パーサー拡張機能の仕組みとCBN（Code-Based Normalization）によるマッピング方法、Snippet BeforeとSnippet Afterの違いを解説します。さらに、extensionValidationReportsを使った事前検証についても紹介します。

Professional Security Operations Engineer（PSOE）認定試験でも重要となる、「標準パーサーを活用しながら、必要な部分だけを拡張する」という考え方を理解しましょう。

是非、最後までご覧いただけると嬉しいです。

Google SecOpsのパーサー拡張機能とCBNマッピングを解説

セキュリティ運用（SecOps）において、サードパーティ製品のアップデートや仕様変更により、ログフォーマットが突如変更される事態は頻繁に発生します。Google Security Operations（Google SecOps）では、標準で事前構築済みパーサー（Prebuilt Parser）を提供していますが、生ログの形式が変わると正常にパースできず、UDM（統合データモデル）への正規化が失敗する原因となります。

このような変更に対して、標準パーサーを一から書き直すのではなく、最小限の労力で差分のみを修正・拡張できる技術が「パーサー拡張機能（Parser Extensions）」とCBN（Code-Based Normalization）マッピングです。本記事では、Professional Security Operations Engineer（PSOE）試験でも重視される本機能の仕組みと運用設計について解説します。

1. 事前構築済みパーサー（Prebuilt Parser）とCBNの課題

Google SecOpsは、主要なサードパーティ製品（Palo Alto, CrowdStrike, Okta等）向けに標準の事前構築済みパーサーを提供しています。これらはGoogleによって継続的にメンテナンスされていますが、以下の課題が存在します。

  • ベンダー独自のカスタムフィールドへの未対応：標準パーサーは一般的な標準フィールドのみをマッピングするため、組織で独自に追加したカスタムログフィールドが無視されることがあります。
  • 突然のログ仕様変更：サードパーティ製品のバージョンアップによりフィールド名やJSON構造が変わると、標準パーサーが追従するまでの間、ログ解析が停止するリスクがあります。

2. パーサー拡張機能（Parser Extensions）の仕組み

パーサー拡張機能は、事前構築済みパーサーのコード本体を書き換えることなく、前処理（Snippet before）または後処理（Snippet after）としてカスタムのCBN（Code-Based Normalization）構文を追加できる機能です。

拡張機能の2つの挿入ポイント

  1. Snippet Before（前処理）：標準パーサーが実行される前に動作します。標準パーサーが対応していない特殊なログ形式を事前に整形・変換したい場合や、特定ログのドロップ条件を定義したい場合に利用します。
  2. Snippet After（後処理）：標準パーサーが実行された後に動作します。標準パーサーで解析済みのUDMデータ構造を参照し、未解析のフィールドを追加補完・上書きマッピングする際に使用します。

3. CBNマッピングの実践パターン

後処理（Snippet After）での一般的なCBNコード記述例では、標準パーサーによって生成された初期UDMオブジェクトを参照・拡張します。

filter {
  # 生ログからJSONを解析
  json {
    source => "message"
    target => "parsed_json"
  }

  # カスタムフィールドをAdditional Fields用のkey-valueとして作成
  mutate {
    replace => {
      "additional_tenant_id.key" => "custom_tenant_id"
      "additional_tenant_id.value.string_value" => "%{parsed_json.tenant_id}"
    }
  }

  # UDMのAdditional Fieldsへ追加
  mutate {
    merge => {
      "event.idm.read_only_udm.additional.fields" => "additional_tenant_id"
    }
  }
}

事前に定義された標準パーサーの構造を破棄することなく、差分だけを適用できるため、全体を一から作成する「カスタムパーサー（Custom Parser）」に比べて開発・メンテナンス工数を大幅に削減できます。

4. 構文検証とテスト：extensionValidationReports の活用

パーサー拡張機能を本番環境に適用する前には、構文エラーやマッピング漏れがないかを検証することが不可欠です。

Google SecOpsのパーサー管理UIやAPIでは、テストログを入力して実行結果を確認できる検証機能が備わっています。検証時に生成される extensionValidationReports を確認することで、拡張構文のコンパイルエラーの有無、パース後のUDMオブジェクトの変更差分、ログドロップの挙動などを事前に安全にデバッグできます。

まとめ

Google SecOpsでは、サードパーティ製品のログ仕様変更やカスタムフィールドに対して、パーサー拡張機能を利用して柔軟に対応できます。

Parser Extensionsでは、Snippet BeforeとSnippet Afterを使い分け、標準パーサーの前後に必要なCBNロジックだけを追加できます。

標準パーサーを一から作り直す必要がないため、ログ仕様の変更に対する開発・保守の負担を抑えられる点が大きなメリットです。

また、本番適用前にはextensionValidationReportsを活用して、構文エラーやUDMへのマッピング結果、ログドロップなどを検証することが重要です。

Professional Security Operations Engineer認定試験では、Snippet BeforeとSnippet Afterの違いや、標準パーサーを拡張して効率的にログを正規化する考え方を理解しておきましょう。

Google SecOpsのIngestion API移行とudmeventsを解説

Google Security Operations（Google SecOps）へのデータ取り込み（インジェクション）パイプラインにおいて、API経由でのログ送信アプローチは大きな転換期を迎えています。従来の 旧Ingestion API は非推奨（2027年7月20日に完全廃止予定）となり、Google Cloud標準の Chronicle API への移行が強く推奨されています。

本記事では、Professional Security Operations Engineer（PSOE）認定試験対策および高度なログパイプライン設計の観点から、旧APIからの移行ロードマップと、Chronicle APIの核心機能である udmevents エンドポイントを活用した超低遅延パイプラインの構築技術 について詳しく解説します。

1. 移行の背景：旧Ingestion APIの廃止とChronicle APIへの一本化

これまで多くの組織で利用されてきたレガシーなIngestion APIは、APIキー認証を中心とした独自エンドポイント構造を持っていました。しかし、プラットフォームのGoogle Cloud環境への完全統合に伴い、認証・認可およびAPI管理が Google Cloud IAM（Identity and Access Management） ベースに一本化されることとなりました。

移行を主導する主な要因

  • ガバナンスとセキュリティの強化：APIキーから、より安全なサービスアカウント（OAuth 2.0 / 存続期間の短時限アクセストークン）認証への移行。
  • API標準化：Chronicle API（chronicle.googleapis.com）としてGoogle Cloud APIのエコシステムに統合。
  • EOL（非推奨・廃止）対応：旧Ingestion APIは2027年7月20日にアクセス不能となるため、早期のパイプライン刷新が必要。

2. udmevents による内部CBN（パース処理）のバイパス構造

通常のログ取り込みプロセスでは、送信された生ログ（Raw Log）はGoogle SecOps内部の CBN（Code-Based Normalization）パーサーレイヤ を通過し、そこでUDM（統合データモデル）構造へと変換された後にインデックス化および検出エンジン（YARA-L 2.0）へ引き渡されます。

しかし、送信元（オンプレミスのETLツールやカスタムデータ収集パイプラインなど）の段階で、すでにUDMフォーマットへと正しくマッピング・構造化できている場合、内部CBNでの再パース処理は冗長であり、処理遅延の一因となります。

【通常のログ取り込み】
[ 生ログ ]
     ↓
[ Google SecOps内部のパーサー / CBN ]
     ↓
[ UDMイベント ]
     ↓
[ インデックス・検出エンジン等で利用 ]


【udmeventsによる取り込み】
[ UDM変換済みイベント ]
     ↓
[ Chronicle API / udmevents ]
     ↓
[ CBNパース処理をバイパス ]
     ↓
[ インデックス・検出エンジン等で利用 ]

udmevents エンドポイントのメリット

  1. 取り込み遅延（Ingestion Latency）の劇的削減: プラットフォーム内部でのパーサー処理負荷を完全にバイパス（スキップ）するため、データが送信された直後に検出エンジンに到達し、リアルタイム（Near Real-time）な脅威検知が可能になります。
  2. パースエラー（Unparsed Logs）リスクの排除: プラットフォーム側でのパース失敗やフィールド落ちが発生せず、送信元で検証された正確なUDMオブジェクトがそのまま格納・検索可能になります。

3. ステップバイステップ移行戦略

既存の旧Ingestion API送信処理を、Chronicle APIの udmevents に切り替える推奨ステップは以下の通りです。

Step 1: 認証・IAMロールの構成

旧APIキー認証を廃止し、Google Cloudプロジェクト側でサービスアカウントを作成します。対象のサービスアカウントには roles/chronicle.editor または roles/chronicle.admin などの適切な権限を付与し、APIリクエスト時にアクセストークンを取得・適用させます。

Step 2: 送信前処理（Pre-UDMマッピング）の実装

ログ送信元のパイプライン（例: Logstash, Fluentd, カスタムPythonスクリプト等）で、ログデータをGoogle SecOpsのUDM JSON構文（metadata.event_type, principal, target 等）へ事前変換・整形するロジックを組み込みます。

Step 3: udmevents APIエンドポイントへのリクエスト構築

以下のような形式で、udmevents エンドポイントに対して構造化済みイベントをPOST送信します。

POST https://chronicle.{region}.rep.googleapis.com/v1alpha/projects/{project_id}/locations/{region}/instances/{instance_id}/events:import
Authorization: Bearer <ACCESS_TOKEN>
Content-Type: application/json

{
  "inlineSource": {
    "events": [
      {
        "udm": {
          "metadata": {
            "eventTimestamp": "2026-09-11T06:00:00Z",
            "eventType": "USER_LOGIN",
            "vendorName": "Example",
            "productName": "Custom SSO Provider"
          },
          "principal": {
            "user": {
              "userid": "user01@example.com"
            }
          },
          "securityResult": [
            {
              "action": "ALLOW"
            }
          ]
        }
      }
    ]
  }
}

Step 4: 並行運用（カナリア検証）と旧APIのデコミッション

新旧両方のエンドポイントに短期間パラレルで送信（または一部ログソースから段階的に切替）を行い、UDM検索およびYARA-L検知ルールへの即時反映状況を確認します。遅延削減とデータ整合性が確認された後、旧Ingestion APIへの送信スクリプトを停止・削除します。

まとめ

旧Ingestion APIは非推奨となっており、今後はChronicle APIへの移行が重要になります。

Chronicle APIのudmeventsを利用すると、事前にUDMへ変換したデータを直接取り込む構成を検討できます。
移行では、IAMによる認証・権限設定、送信前のUDMマッピング、APIリクエストの実装がポイントです。また、新旧APIを並行運用しながら、UDM検索やYARA-L検知への反映を確認する段階的な移行が有効です。

PSOE試験対策として、旧Ingestion APIからChronicle APIへの移行方法とudmeventsの役割を理解しておきましょう。

Google SecOpsのSilent Source Detectionを解説

セキュリティ運用センター（SOC）において、最も恐ろしいリスクの1つは「届くはずのログが届かない状態」が放置されることです。攻撃者が検知を逃れるためにログ生成を停止させたり、ネットワーク障害やエージェントの停止によりテレメトリーの転送が途絶えたりしても、アラートを生成するログそのものが存在しないため、SIEMや検知エンジンは沈黙を守ってしまいます。

このようなセキュリティ上の盲点を排除し、インフラ全体の可観測性（Observability）を担保する技術が「サイレントソース検知（Silent Source Detection）」です。本記事では、Professional Security Operations Engineer（PSOE）認定試験でも重要なテーマとなるログ収集パイプラインの健全性監視と設計手法について解説します。

1. なぜ「ログの沈黙」を見逃してはならないのか？

従来のセキュリティ監視は、「受信したログに攻撃の兆候（IOC）が含まれているか」を評価する「ポジティブ検知」が中心でした。しかし、以下のシナリオではポジティブ検知は機能しません。

  • 攻撃者による妨害（Anti-Forensics）：侵入に成功した攻撃者が、最初にsyslogサービスやEDRエージェントを停止・無効化する。
  • パイプライン障害：Bindplaneエージェントやフォワーダーの停止、あるいはネットワークの設定ミスによるログ送信エラー。
  • API連携の失効：サードパーティSaaS（OktaやAzure AD等）のAPIトークン切れによるログ取得失敗。

これらはすべて「異常」ですが、ログが届かないためルールエンジンは反応できません。サイレントソース検知は、この「ログの途絶」という「ネガティブな兆候」を能動的に捉えます。

2. Cloud Monitoring を活用したサイレントソース検知のアーキテクチャ

Google Security Operations（Google SecOps）では、Google Cloudのモニタリング基盤である Cloud Monitoring や Cloud Logging と連携して、ログ収集パイプラインのヘルスモニタリングを構築します。

検知メカニズム：指標なし（Metric Absence）ポリシー

ログソースごとの取り込みイベント数（EPS: Events Per Second）やデータ量を指標（Metric）として監視します。ログが正常に送信されていれば指標は絶えず記録されますが、一定時間データが途絶えると「指標の欠落（Metric Absence / Data Absence）」が発生します。

Cloud Monitoringのアラートポリシーにて「一定時間（例：15分〜1時間）データポイントが全く受信されない場合」をトリガー条件として設定することで、サイレントソースを自動検知してSOCチームへ通知します。

3. 実装と閾値設定におけるベストプラクティス

サイレントソース検知を成功させるためには、ログソースの特性に応じた適切なアラート設計が必要です。

  1. ログソースのカテゴリ分け:
    • 高頻度ログ（VPC Flow Logs, DNS等）：常時大量に発生するため、わずか数分間のデータ途絶でも即座にアラート（低レイテンシ検知）を発行します。
    • 低頻度ログ（管理者アクセスログ、特定端末等）：正常時でもログが発生しない時間帯があるため、単純なデータ欠落だけでは誤検知（False Positive）になります。一定時間内の平均発生数や、時間帯ごとのベースラインと比較するロジックを構成します。
  2. 名前空間（Namespace）とログタイプのラベル活用：取り込み指標にログソースのラベルや名前空間を付与しておくことで、「どの環境のどの製品のログが停止したか」を通知時に即座に特定できるようにします。

まとめ

Silent Source Detectionは、「本来届くはずのログが届かない」という異常を検知する仕組みです。攻撃者によるログ停止だけでなく、エージェント停止やネットワーク障害、API連携の失敗なども検知対象になります。

Cloud MonitoringのMetric AbsenceやData Absenceを活用することで、ログ収集パイプラインの停止を監視できます。ログの発生頻度に応じて検知時間や閾値を調整し、誤検知を抑えることが重要です。

PSOE試験対策として、Silent Source Detectionの目的と、ログ収集基盤の可観測性を確保する考え方を理解しておきましょう。

まとめ

今回は、下記３点について説明しました。

  1. Google SecOpsのパーサー拡張機能とCBNマッピングを解説
  2. Google SecOpsのIngestion API移行とudmeventsを解説
  3. Google SecOpsのSilent Source Detectionを解説

Google SecOpsのパーサー拡張機能を利用すると、標準パーサーを一から作り直すことなく、ログ形式の変更やカスタムフィールドに対応できます。Snippet Beforeは標準パーサーの前、Snippet Afterは標準パーサーの後に処理を追加するため、それぞれの用途を理解することが重要です。

CBNマッピングを利用することで、必要なフィールドをUDMへ追加・補完し、ログを適切に正規化できます。本番環境へ適用する前には、extensionValidationReportsを利用して構文エラーやUDMの変更、ログドロップなどを確認します。

PSOE試験対策として、Parser Extensions、Snippet Before/After、CBNマッピング、検証方法の関係を整理して覚えておきましょう。

これからも、Macのシステムエンジニアとして、日々、習得した知識や経験を発信していきますので、是非、ブックマーク登録してくれると嬉しいです！

それでは、次回のブログ！

スポンサーリンク
タイトルとURLをコピーしました