🛡

Google SecOps：多様なログソースに対応！SIEM ログの収集方法を徹底解説

2024/09/13に公開

Security

 はじめにこんにちは、クラウドエース株式会社 SRE 部の山﨑です。

本記事では Google Security Operations（以下 Google SecOps）の SIEM を使用した、ログの取り込み方法について解説します。

Linux や Windows など異なる環境からのログ取り込み手順についても紹介いたします。

 Google SecOps と SIEM についてSIEM（Security Information and Event Management）とは、さまざまな接続元からセキュリティログを収集・分析し、脅威の早期発見と迅速な対応を支援するセキュリティソリューションです。

Google SecOps は Google が提供している SIEM/SOAR 製品です。

Google SecOps の概要については以前別記事でご紹介しているので、そちらをご覧ください。

https://zenn.dev/cloud_ace/articles/google-secops-overview

 ログ取り込みプロセス：重要用語と基本フロー

図：ログソース => ログタイプ => パーサー => UDM までの流れ

セキュリティログの取り込み方法を解説する前に、登場する以下の重要なキーワードについて説明します。
パーサー
UDM
ログタイプ

 パーサーパーサーは生のログデータを構造化された統合データモデル形式にマッピングするコンポーネントです。

https://cloud.google.com/chronicle/docs/event-processing/parsing-overview?hl=ja

 UDMUDM（Unified Data Model）とは、統一データモデルの略であり、様々なセキュリティデータソースからのデータを標準化された形式で表現するためのフレームワークです。
Google SecOps では UDM の形式に構造化されたデータを検索する機能（UDM 検索）が搭載されています。

異なる製品のログが UDM 形式に統一されるため、一つのクエリで複数製品のログイベントを高速かつ正確に検索することができます。
UDM 検索が利用することができるスキーマについては以下の公式ドキュメントを参照してください。

https://cloud.google.com/chronicle/docs/reference/udm-field-list

 ログタイプGoogle SecOps で指すログタイプは特定製品のログのレベルで分類したものを指します。

例えば、CrowdStrike などの EDR 製品や、Okta など IdP 製品など、多様な製品のログレベルを取り込むことができます。
サポートされているログは以下の公式ドキュメントを参照してください。

なお、対応しているログタイプの存在するログソースであっても、デフォルトでパーサーがないものもあり、その場合はパーサーを自作する必要がある点にご注意ください。

https://cloud.google.com/chronicle/docs/ingestion/parser-list/supported-default-parsers

 ログの取り込み方法の種類とユースケースGoogle SecOps では、以下のようなログの取り込み方法があります。

それぞれの取り込み方法の概要とユースケースについてご紹介します。
BindPlane Agent を使って取り込む
フォワーダーを使って取り込む
Cloud Logging から直接取り込む
Feed を使って取り込む

 1. BindPlane Agent を使って取り込む

図：BindPlane Agent を使用した構成図
BindPlane Agent とは、OpenTelemetry Collector をベースにしたテレメトリー収集エージェントです。

Windows のイベントログや Linux の Syslog といったさまざまなソースからログを収集し、Google SecOps に転送することができます。

 2. フォワーダーを使って取り込む

図：フォワーダーを使用した構成図
フォワーダーとは、サーバーなどのネットワーク上のマシンまたはデバイスでログの収集と転送を行うソフトウェアです。
基本的には各種サーバなど、前述した BindPlane Agent が利用可能な環境であればそちらを利用すれば良いと考えます。

一方で、フォワーダーは直接 syslog を受け取って転送することが可能（BindPlane Agent では不可）なため、BindPlane Agent をインストールできないネットワーク機器のようなものからログを収集する場合はフォワーダーを利用することになります。

 3. Cloud Logging から直接ログを取り込むGoogle Cloud の各種ログを Google SecOps に取り込むことができます。

別の組織からも Google SecOps に直接ログを取り込むことができます。

直接取り込めるログタイプの種類については以下の公式ドキュメントを参照してください。

https://cloud.google.com/chronicle/docs/ingestion/cloud/ingest-gcp-logs?hl=ja#option_1_direct_ingestion
!現時点（2024年9月現在）では、Cloud Loggingからの自動取り込みは組織の階層でのみ設定が可能です。

 4. Feed を使って取り込むFeed は主に、今まで挙げたフォワーダー、BindPlane Agent、Cloud Logging 以外のケースで利用します。

Feed で利用可能な主なログソースには以下のようなものがあります。



表：Feed 主要なログソース一覧


フィードのソースタイプ
説明
ユースケース


サードパーティ API
サードパーティの API からデータを取り込む
 サポートしているログタイプについてはこちらの公式ドキュメントを参照してください
Microsoft 365 管理アクティビティや Microsoft Azure AD ログイン などのセキュリティログを取り込む場合

Google Cloud Storage
GCS バケットからデータを取り込む
ログデータをパブリッククラウド経由で取り込める場合

Amazon S3
Amazon Simple Storage Service バケットからデータを取り込む
ログデータをパブリッククラウド経由で取り込める場合

Azure Blobstore
Azure Blob Storage からデータを取り込む
ログデータをパブリッククラウド経由で取り込める場合

HTTP（S）
HTTP（S）リクエストでアクセス可能なファイルからデータを取り込む
パブリッククラウドを経由しないでログデータを取り込む場合


 ハンズオン：ログを取り込んでみる前述した以下の取り込み方法についての実際の手順についてご紹介します。
BindPlane Agent を利用してログを取り込む（Windows 環境）
フォワーダーを利用してログを取り込む（Linux 環境）
Feed を利用してログを取り込む

 1. BindPlane Agent を利用してログを取り込む（Windows 環境）
 BindPlane Agent のインストールWindows Server で出力されたセキュリティログやイベントログは BindPlane Agent を通じて Google SecOps に取り込むことが可能です。
まず初めに、公式ドキュメントに従い、下記のコマンドでログ収集対象の Windows マシンに BindPlane Agent をインストールします。
powershell
msiexec /i "https://github.com/observIQ/bindplane-agent/releases/latest/download/observiq-otel-collector.msi" /quiet

 BindPlane Agent のセットアップ次に、BindPlane Agent を機能させるために構成ファイルの設定を行います。
Google SecOps にログイン後、左のメニューから 「SIEM Setting」 → 「Collection Agents」 の画面に移動します。

INGESTION AUTHENTICATION FILE（資格情報を含むファイル）と CONFIGURATION（config.yaml のテンプレート）をダウンロードします。



図：Google SecOps での BindPlane Agents の設定
次に、Windows マシン上で config.yaml ファイルを設定します。

特にダウンロード先を指定しなかった場合、以下のディレクトリに config.yaml ファイルが配置してあります。
powershell
C:\Program Files\observIQ OpenTelemetry Collector
配置されている config.yaml ファイルを先ほどダウンロードした CONFIGURATION の内容に置き換えます。

config.yaml の詳細な記法については公式ドキュメントを参照してください。
!Microsoft Windows Sysmon イベントログを取得するのであれば、事前に Sysmon をインストールするなどイベントログを出力するための手順は別途必要です。
本記事では WINDOWS_SYSMON、WINEVTLOG、WINDOWS_AD のログタイプを取り込んでいます。
config.yamlreceivers:
  windowseventlog/sysmon:
    channel: Microsoft-Windows-Sysmon/Operational
    raw: true
    start_at: end
    max_reads: 1000
    poll_interval: 1s
  windowseventlog/dns:
    channel: DNS Server
  windowseventlog/security:
    channel: security
    raw: true
    start_at: end
    max_reads: 1000 
    poll_interval: 1s
  windowseventlog/application:
    channel: application
    raw: true
    start_at: end
    max_reads: 1000
    poll_interval: 1s
  windowseventlog/system:
    channel: system
    raw: true
    start_at: end
    max_reads: 1000
    poll_interval: 1s
  filelog:
    include: [ C://AD.json ]
    start_at: beginning


processors:
  batch:

exporters:
  chronicle/winsysmon:
    endpoint: malachiteingestion-pa.googleapis.com
    creds: '{
    "type": "service_account",
    "project_id": "malachite-project_id",
    "private_key_id": "xxxxx",
    "private_key": "-----BEGIN PRIVATE KEY-----\n<<<認証情報>>>\n-----END PRIVATE KEY-----\n",
    "client_email": "cldc-1234567890@malachite-cldc.iam.gserviceaccount.com",
    "client_id": "1234567890",
    "auth_uri": "https://accounts.google.com/o/oauth2/auth",
    "token_uri": "https://oauth2.googleapis.com/token",
    "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
    "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/cldc-12345678798%40malachite-cldc.iam.gserviceaccount.com",
    "universe_domain": "googleapis.com"
    }'
    log_type: 'WINDOWS_SYSMON'
    override_log_type: false
    raw_log_field: body
    customer_id: <<Google SecOps の Cusotmer ID>>

  chronicle/winevtlog:
    !----------------------------------------!
      chronicle/winsysmon：と同じ中身なので省略
    !----------------------------------------!

    log_type: 'WINEVTLOG'
    override_log_type: false
    raw_log_field: body
    customer_id: <<Google SecOps の Cusotmer ID>>

  chronicle/winad:
    !----------------------------------------!
      chronicle/winsysmon：と同じ中身なので省略
    !----------------------------------------!
    log_type: 'WINDOWS_AD'
    override_log_type: false
    raw_log_field: body
    customer_id: <<Google SecOps の Cusotmer ID>>


service:
  pipelines:
    logs/winsysmon:
      receivers:
        - windowseventlog/sysmon
      processors: [batch]
      exporters: chronicle/winsysmon
    logs/winevtlog:
      receivers:
        - windowseventlog/security
        - windowseventlog/application
        - windowseventlog/system
      processors: batch
      exporters: chronicle/winevtlog
    logs/windowsad:
      receivers: 
        - filelog
      exporters: chronicle/winad

config.yaml の設定完了後、BindPlane Agent を再起動します。
powershell
Restart-Service observiq-otel-collector

 取り込んだログを Google SecOps で確認するBindPlane Agent で取り込んだログを Google SecOps で確認します。

Google SecOps にログイン後、左のメニューから SIEM Search を選択してクエリを直接打つか、プロンプトを入力して Gemini に生成してもらいます。
Windows ログのクエリは以下のようになります。
UDM クエリ
metadata.vendor_name = "Microsoft" AND metadata.product_name = /Windows/
クエリと合致した取り込まれたログが表示されます。



図：BindPlane Agent で取り込んだログを SIEM で検索した結果
取り込んだログの SIEM での詳細な検索方法と実践的なポイントなどについては別記事で紹介しているので、そちらをご覧ください。

https://zenn.dev/cloud_ace/articles/google-secops-log-search

 2. フォワーダーを利用してログを取り込む（Linux 環境）!Linux 環境でフォワーダーを動かすために Docker が必要です。

Docker のインストール手順については以下のドキュメントを参照してください。
https://docs.docker.com/engine/install/ubuntu/

 Google SecOps 上でフォワーダーの構成ファイルを作成任意の形式でセキュリティログを転送するために、Google SecOps の UI 上でフォワーダーの構成ファイルに必要なパラメータを設定します。

Google SecOps にログイン後、左のメニューから 「SIEM Setting」 → 「Forwarders」 を選択して、フォワーダー作成の画面に移動します。
必須パラメータは FORWARDER NAME のみです。

UPLOAD COMPRESSION を有効化するとログを圧縮し、帯域を節約をすることができます。



図：Google SecOps 上のフォワーダーの作成画面
次に、収集したいログタイプごとにコレクタを設定をします。

コレクタの設定については以下のドキュメントを参照してください。

https://cloud.google.com/chronicle/docs/install/forwarder-management-configurations?hl=ja#asset-namespaces
本記事では Linux Auditing System（AuditD）ログを Google SecOps 転送します。

他の機器やサーバから AuditD のログを転送するプロトコル、ポート、アドレスを設定します。



図：Google SecOps 上のコレクタの作成画面
設定が完了したらフォワーダーの .conf ファイルと_auth.conf ファイルをダウンロードします。



図：.conf ファイルと _auth.conf ファイルのダウンロード

 Docker コンテナでフォワーダーを起動してログを取り込むフォワーダーを配置するサーバ上でコンテナを起動します。

本記事では「Google SecOps 上でフォワーダーを作成」でダウンロードした .conf ファイルと _auth.conf ファイルを以下に配置しますが、任意のディレクトリに配置して指定することも可能です。
/opt/chronicle/config
Docker Image は Google Cloud 公式の公開イメージが提供されています。

この公開イメージを使用する際は、以下のドキュメントを参照してください。

https://cloud.google.com/chronicle/docs/install/forwarder-linux?hl=ja#verify_the_firewall_configuration
以下のコマンドで公開イメージを取得し、利用することが可能です。
$ docker pull gcr.io/chronicle-container/cf_production_stable
Docker コマンドでフォワーダーコンテナを起動します。

設定ファイルやログファイルから収集する場合、マウントが必要なことに注意してください。
$ docker run --detach --name cfps \
  --restart=always \
  --log-opt max-size=100m \
  --log-opt max-file=10 \
  --net=host \
  -v /opt/chronicle/config:/opt/chronicle/external \
  -v /var/log/audit/audit.log \
  -v /var/log/syslog gcr.io/chronicle-container/cf_production_stable
下記コマンドでコンテナが正常に動いていることを確認することができます。
$ docker ps
CONTAINER ID   IMAGE                                             COMMAND                  CREATED         STATUS         PORTS     NAMES
b36ed7d1df60   gcr.io/chronicle-container/cf_production_stable   "/bin/sh -c '/opt/ch…"   3 seconds ago   Up 3 seconds             cfps
ログを収集をしたいサーバに対し、フォワーダーを配置したサーバの IP アドレスにログを転送する設定が必要です。

詳細については公式ドキュメントを参照してください。

https://cloud.google.com/chronicle/docs/ingestion/ingest-linux-unix-logs?hl=ja
全ての設定が完了したらログが取り込めるようになります。

取り込んだログは BindPlane Agent の時と同様の方法で確認することができます。

 3. Feed を利用してログを取り込む本記事では Feed を利用して Google Workspace のログデータを取り込み手順を紹介します。

手順の概要については以下の公式ドキュメントを参照してください。

https://cloud.google.com/chronicle/docs/reference/feed-management-api?hl=ja#workspace-activity
!Google Workspace 側のライセンスは Business Standard または Business Plus プランを契約している必要があります。

 事前準備初めに、Google SecOps を作成している Google Cloud プロジェクトで 「Admin SDK API」と「Google Workspace Alert Center API」を有効化します。

 Google Workspace 側の設定まず、Google Workspace 側で Google Cloud と連携するユーザアカウントを作成します。



図：Google Workspace のユーザアカウント作成画面
次に、「管理者ロール」の画面でカスタムロールを作成します。



図：Google Workspace でカスタムロールを作成画面



図：Google Workspace のユーザアカウント作成画面
次に、作成したカスタムロールを付与します。



図：作成したカスタムロールを付与
次に、適当なプロジェクトでサービスアカウントとサービスアカウントキーを作成します。

Google Cloud でのサービスアカウントとサービスアカウントキーの作成方法については以下の公式ドキュメントを参照してください。

作成したサービスアカウントのクライアント ID とサービスアカウントキーの秘密鍵ファイルを取得します。

https://cloud.google.com/iam/docs/service-accounts-create?hl=ja

https://cloud.google.com/iam/docs/creating-managing-service-account-keys?hl=ja
次に、Google Workspace 側でドメイン全体の委任を設定します。

「セキュリティ」→「アクセスとデータ管理」→「API の制御」の画面から「ドメイン全体の委任を管理」を選択します。


図：Google Workspace のドメイン全体の委任の画面設定
ドメイン全体を委任するクライアント ID を追加します。

「新しく追加」を選択して必要なパラメータを入力します。

クライアント ID は先ほど作成したサービスアカウントのクライアント ID を入力します。

OAuth スコープについては下記の公式ドキュメントを参考に入力します。

https://developers.google.com/admin-sdk/directory/v1/guides/delegation?hl=ja#delegate_domain-wide_authority_to_your_service_account


図：クライアント ID の追加画面
入力が完了したら「承認」を選択して、Google Workspace 側の設定は完了です。

 Google SecOps 上で Feed を作成Feed の設定については以下の公式ドキュメントの手順に沿って行います。

https://cloud.google.com/chronicle/docs/administration/feed-management?hl=ja#storage-example
Google SecOps にログイン後、左のメニューから 「SIEM Setting」 → 「Feeds」 を選択して、Feed の作成画面に移動します。
SOURCE TYPE は Third party API を選択します。

LOG TYPE には収集したいログをタイプを選択します。

今回は Workspace Activities を選択します。



図：Google SecOps 上で Feed の作成画面
次に、以下の公式ドキュメントを参考に Feed のパラメータを設定します。

https://cloud.google.com/chronicle/docs/reference/feed-management-api?hl=ja#applications
JWT CLAIMS ISSUER にはクライアント ID （今回はプロジェクトで作成したサービスアカウントのクライアント ID）を入力します。

JWT CLAIMS SUBJECT には Google Workspace で作成したユーザアカウントのメールアドレスを入力します。

RSA PRIVATE KEY には事前に取得したサービスアカウントキーの秘密鍵ファイルの情報を入力します。

CUSTOMER ID には Google Workspace の Customer ID を入力します。



図：Google SecOps 上で Feed の作成画面（パラメータ部分）
すべての入力が完了したら、「SUBMIT」を選択して Feed の設定が完了です。



図：Feed の設定完了画面

ログの取り込みが完了すると、作成した Feed の STATUS が Completed の状態になります。

取り込んだログは BindPlane Agent の時と同様の方法で確認することができます。
!Google Workspace は複数のログタイプがありますが、ログタイプごとに別々の Feed を設定する必要があります。

 まとめ本記事では、Google SecOps の SIEM におけるログの取り込み方法について解説しました。
Google SecOps では Google Cloud に限らず、CrowdStrike や Okta などの多様な製品からセキュリティログを取り込むことができます。

取り込むログソースや環境によって、BindPlane Agent / フォワーダー / Cloud Logging / Feed などを使い分けることで、多様な環境からセキュリティログを取り込むことができます。
本記事の内容を参考に、Google SecOps を活用することで、組織のセキュリティ運用を効率化し、セキュリティ態勢を強化することにつなげていただけば幸いです。

フィードのソースタイプ	説明	ユースケース
サードパーティ API	サードパーティの API からデータを取り込むサポートしているログタイプについてはこちらの公式ドキュメントを参照してください	Microsoft 365 管理アクティビティや Microsoft Azure AD ログインなどのセキュリティログを取り込む場合
Google Cloud Storage	GCS バケットからデータを取り込む	ログデータをパブリッククラウド経由で取り込める場合
Amazon S3	Amazon Simple Storage Service バケットからデータを取り込む	ログデータをパブリッククラウド経由で取り込める場合
Azure Blobstore	Azure Blob Storage からデータを取り込む	ログデータをパブリッククラウド経由で取り込める場合
HTTP（S）	HTTP（S）リクエストでアクセス可能なファイルからデータを取り込む	パブリッククラウドを経由しないでログデータを取り込む場合

はじめに

Google SecOps と SIEM について

ログ取り込みプロセス：重要用語と基本フロー

パーサー

UDM

ログタイプ

ログの取り込み方法の種類とユースケース

1. BindPlane Agent を使って取り込む

2. フォワーダーを使って取り込む

3. Cloud Logging から直接ログを取り込む

4. Feed を使って取り込む

ハンズオン：ログを取り込んでみる

1. BindPlane Agent を利用してログを取り込む（Windows 環境）

BindPlane Agent のインストール

BindPlane Agent のセットアップ

取り込んだログを Google SecOps で確認する

2. フォワーダーを利用してログを取り込む（Linux 環境）

Google SecOps 上でフォワーダーの構成ファイルを作成

Docker コンテナでフォワーダーを起動してログを取り込む

3. Feed を利用してログを取り込む

事前準備

Google Workspace 側の設定

Google SecOps 上で Feed を作成

まとめ

Discussion