Docker 上の Windows 向け Google Security Operations フォワーダー

このドキュメントでは、Docker 上に Windows 用 Google Security Operations フォワーダーをインストールして構成する方法について説明します。

システム要件

一般的な最適化案は次のとおりです。システムに固有の最適化案については、Google Security Operations のサポートにお問い合わせください。

  • Windows Server のバージョン: Google Security Operations フォワーダーは、Microsoft Windows Server 2022 でサポートされています。
  • RAM: 収集されるログの種類ごとに 1.5 GB。たとえば、エンドポイントの検出とレスポンス（EDR）、DNS、DHCP は別々のデータ型です。3 種類すべてのデータを収集するには、4.5 GB の RAM が必要になります。サポートされているデフォルト パーサーとログの種類の一覧については、サポートされているデフォルト パーサーをご覧ください。
  • CPU: 2 個の CPU は、10,000 EPS（1 秒あたりイベント数）（すべてのデータ型の合計）未満を処理するには十分です。10,000 を超える EPS を送信する予定の場合は、4 ～ 6 個の CPU が必要です。

  • ディスク: Google Security Operations フォワーダーで処理するデータの量に関係なく、100 MB のディスク容量で十分です。構成ファイルに write_to_disk_buffer_enabled パラメータと write_to_disk_dir_path パラメータを追加すると、ディスクをバッファリングできます。

    例:

    - <collector>:
     common:
         ...
         write_to_disk_buffer_enabled: true
         write_to_disk_dir_path: directory_path
         ...

Google IP アドレスの範囲

ファイアウォールの構成を設定するときなどに、Google Security Operations フォワーダーの構成を設定するときに、IP アドレス範囲を開くことが必要な場合があります。Google では、特定の IP アドレスのリストを提供することはできません。 ただし、Google の IP アドレス範囲を取得することはできます。

ファイアウォール構成を確認する

Google Security Operations　フォワーダー コンテナとインターネットの間にファイアウォールまたは認証プロキシがある場合は、次の Google Cloud ホストへのアクセスを許可するルールが必要です。

接続タイプ 宛先 ポート
TCP malachiteingestion-pa.googleapis.com 443
TCP asia-northeast1-malachiteingestion-pa.googleapis.com 443
TCP asia-south1-malachiteingestion-pa.googleapis.com 443
TCP asia-southeast1-malachiteingestion-pa.googleapis.com 443
TCP australia-southeast1-malachiteingestion-pa.googleapis.com 443
TCP europe-malachiteingestion-pa.googleapis.com 443
TCP europe-west2-malachiteingestion-pa.googleapis.com 443
TCP europe-west3-malachiteingestion-pa.googleapis.com 443
TCP europe-west6-malachiteingestion-pa.googleapis.com 443
TCP me-central2-malachiteingestion-pa.googleapis.com 443
TCP me-west1-malachiteingestion-pa.googleapis.com 443
TCP northamerica-northeast2-malachiteingestion-pa.googleapis.com 443
TCP accounts.google.com 443
TCP gcr.io 443
TCP oauth2.googleapis.com 443
TCP storage.googleapis.com 443

Google Cloud へのネットワーク接続は、次の手順で確認できます。

  1. 次のコマンドで Windows PowerShell 管理者権限で（起業、タイプPowerShell、右クリックWindows Powershellをクリックし、管理者として実行）を起動します。

  2. 次のコマンドを実行します。

    C:\> test-netconnection <host> -port <port>

    このコマンドは、TcpTestSucceeded が true であることを返します。

    次に例を示します。

    C:\> test-netconnection malachiteingestion-pa.googleapis.com -port 443
ComputerName     :  malachiteingestion-pa.googleapis.com
RemoteAddress    : 198.51.100.1
RemotePort       : 443
InterfaceAlias   : Ethernet
SourceAddress    : 203.0.113.1
TcpTestSucceeded : True

Microsoft Windows に Docker をインストールする

このセクションでは、コマンドライン インターフェースと PowerShell を使用して、Microsoft Windows に Docker をインストールする方法について説明します。

コンテナを使用する Google Security Operations フォワーダーのメリット:

  • 分離によってセキュリティを強化します:
    • お客様の環境と要件は、Google Security Operations フォワーダーには影響しません。
    • Google Security Operations フォワーダーの環境と要件は、お客様には影響しません。
    • コンテナ配布メカニズムはすでに存在しており、非公開にして、Google Cloud とお客様向けに分けることができます。詳細については、Artifact Registry をご覧ください。

Microsoft Windows Server Core 2022 で次の操作を行います。

  1. Microsoft Windows コンテナ機能を有効にします。

    Install-WindowsFeature containers -Restart

  2. PowerShell 管理者モードで次のコマンドを実行して、Docker CE をインストールします。

    Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/Windows-Containers/Main/helpful_tools/Install-DockerCE/install-docker-ce.ps1" -o install-docker-ce.ps1

.\install-docker-ce.ps1

  3. docker ps コマンドライン コマンドを実行して、Docker コマンドライン インターフェースをテストします。このコマンドは、実行中のコンテナのリストを返します。コマンドにより実行中のコンテナが一覧表示されない場合、インストールは成功しています。Docker が適切にインストールされていない場合、エラーが表示されます。

    詳しくは、スタートガイド: コンテナ用に Windows を準備するをご覧ください。

    エンタープライズ デプロイの場合は、Mirantis Container Runtime（Docker EE）をインストールします。

Google Security Operations フォワーダーを構成する

Docker 上の Windows 用 Google Security Operations フォワーダーを構成するには、Google Security Operations UI でフォワーダー構成を管理するをご覧ください。

Google Security Operations フォワーダーを構成する場合は、フォワーダー内のすべてのパスが `c:` 接頭辞で始まることを確認してください。

構成ファイルに加えられた変更は、Google Security Operations フォワーダーによって 5 分以内に自動的に適用されます。

Docker 上の Windows 用 Google Security Operations フォワーダーを使用してパケットデータを収集するには、パケットデータの収集をご覧ください。

Docker コンテナ内で Google Security Operations フォワーダーを実行する

  1. Google Security Operations フォワーダーをアップグレードする場合は、まず、以前の Docker 実行をクリーンアップします。以下の例では、Docker コンテナの名前は cfps です。

    docker stop cfps

docker rm cfps

  2. この Docker pull コマンドを使用して、Google Cloud から最新の Docker イメージを取得する。

    docker pull gcr.io/chronicle-container/cf_production_stable_windows

  3. Docker コンテナから Google Security Operations フォワーダーを起動します。

    docker run `
--detach `
--name cfps `
--restart=always `
--log-opt max-size=100m `
--log-opt max-file=10 `
-p 10514:10514 `
-v C:\config\:C:/opt/chronicle/external `
gcr.io/chronicle-container/cf_production_stable_windows

    複数のオプションまたは複数の範囲を使用して、複数のポートを追加できます。例: -p 3001:3000 -p 2023:2022、または -p 7000-8000:7000-8000。

フォワーダー ログを表示する

Google Security Operations フォワーダーのログを表示するには、次のコマンドを実行します。

  sudo docker logs cfps

ログが保存されているファイルのパスを表示するには、次のコマンドを実行します。

docker inspect --format='{{.LogPath}}' CONTAINER_NAME

実行中のログを表示するには、次のコマンドを実行します。

  sudo docker logs cfps -f

ログをファイルに保存するには、次のコマンドを実行します。

  sudo docker logs cfps &> logs.txt

Google Security Operations フォワーダーをアンインストールする

次の Docker コマンドを使用すると、Google Security Operations フォワーダーを停止し、アンインストールまたは削除を行うことができます。

このコマンドは、Google Security Operations フォワーダー コンテナを停止します。

  docker stop cfps

このコマンドは、Google Security Operations フォワーダー コンテナを削除します。

  docker rm cfps

Google Security Operations フォワーダーをアップグレードする

Docker on Docker 用の Google Security Operations フォワーダーは、Docker イメージのシェル スクリプトを使用して常に更新されているため、実行可能ファイルを提供する必要はありません。

データの収集

次のセクションは、Google Security Operations インスタンスに転送されるさまざまな種類のデータを取り込むように Google Security Operations フォワーダーを構成するのに役立ちます。

batch_n_bytes には 1 MB を超える値を構成しないでください。1 MB より大きい値を構成すると、値が自動的に 1 MB にリセットされます。

Splunk データを収集する

Splunk のデータを Google Security Operations に転送するように Google Security Operations フォワーダーを構成できます。Google Cloud は次の情報を使用して、Splunk からデータを転送するように Google Security Operations フォワーダーを構成します。

  • Splunk REST API の URL（例: https://10.0.113.15:8089）。

  • 必要な各データ型（index=dns など）のデータを生成する Splunk クエリ。

FORWARDER_NAME.conf
output:
collectors:
  - splunk:
      common:
        enabled: true
        data_type: WINDOWS_DNS
        data_hint: "#fields ts      uid     id.orig_h       id.orig_p       id.resp_h         id.resp_p       proto   trans_id        query   qclass  qclass_name"
        batch_n_seconds: 10
        batch_n_bytes: 819200
      url: https://127.0.0.1:8089
      is_ignore_cert: true
      minimum_window_size: 10s
      maximum_window_size: 30s
      query_string: search index=* sourcetype=dns
      query_mode: realtime
  • Splunk アカウントの認証情報を Google Security Operations フォワーダーが使用できるようにします。これはcreds.txtファイルを作成することによって可能になります。

creds.txt ファイルを使用するには:

  1. Splunk の認証情報のローカル ファイルを作成し、creds.txt という名前を付けます。

  2. 最初の行にユーザー名を入力し、2 行目にパスワードを入力します。

    cat creds.txt

myusername
mypassword

  3. Google Security Operations フォワーダーを使用して Splunk インスタンスにアクセスするには、creds.txt ファイルを構成ディレクトリ（構成ファイルが存在するのと同じディレクトリ）にコピーします。次に例を示します。

    cp creds.txt c:/opt/chronicle/config/creds.txt

  4. creds.txt ファイルが正しい場所にあることを確認します。 

    ls c:/opt/chronicle/config

syslog データを収集する

Google Security Operations フォワーダーは、Syslog サーバーとして機能します。TCP または UDP 接続を介した syslog データの送信をサポートするアプライアンスやサーバーを構成して、そのデータを Google Security Operations フォワーダーに転送できます。アプライアンスまたはサーバーが Google Security Operations フォワーダーに送信する正確なデータを制御できます。Google Security Operations フォワーダーは、データを Google Security Operations に転送できます。

FORWARDER_NAME.conf 構成ファイル（Google Cloud が提供）では、転送されるデータの種類ごとにモニタリングするポートを指定します（例: ポート 10514）。Google Security Operations フォワーダーは、デフォルトで TCP 接続と UDP 接続の両方を受け入れます。

rsyslog を構成する

rsyslog を構成するには、各ポートのターゲット（例: 各データ型）を指定する必要があります。正しい構文については、システムのドキュメントをご覧ください。rsyslog のターゲット構成の例を次に示します。

  • TCP ログ トラフィック: dns.* @@192.168.0.12:10514

  • UDP ログ トラフィック: dns.* @192.168.0.12:10514

syslog 構成用の TLS の有効化

Google Security Operations フォワーダーへの syslog 接続用の TLS を有効にできます。Google Security Operations の構成ファイル（FORWARDER_NAME.conf）で、次の例に示すように、自己生成の証明書と証明書鍵の場所を指定します。

証明書 c:/opt/chronicle/external/certs/client_generated_cert.pem
certificate_key c:/opt/chronicle/external/certs/client_generated_cert.key

示している例に基づいて、Google Security Operations フォワーダーの構成ファイル（FORWARDER_NAME.conf）を次のように変更します。

  collectors:
- syslog:
    common:
      enabled: true
      data_type: WINDOWS_DNS
      data_hint:
      batch_n_seconds: 10
      batch_n_bytes: 1048576
    tcp_address: 0.0.0.0:10515
    tcp_buffer_size: 65536
    connection_timeout_sec: 60
    certificate: "c:/opt/chronicle/external/certs/client_generated_cert.pem"
    certificate_key: "c:/opt/chronicle/external/certs/client_generated_cert.key"
    minimum_tls_version: "TLSv1_3"

重要な留意点:

  • TCP バッファサイズを構成できます。TCP バッファのデフォルトのサイズは 64 KB です。

  • connection_timeout のデフォルト値と推奨値は 60 秒です。 指定した時間で接続が非アクティブの場合、TCP 接続は終了します。

  • TLS の最小バージョンは、入力リクエストの TLS バージョンに対してチェックされます。入力リクエストの TLS バージョンは、最小 TLS バージョンよりも大きくする必要があります。TLS の最小バージョンは、TLSv1_0、TLSv1_1、TLSv1_2、TLSv1_3 のいずれかの値にする必要があります。

構成ディレクトリの下に証明書ディレクトリを作成し、証明書ファイルを保存できます。

ファイルデータを収集する

ファイル コレクタはファイルからログを取得するように設計されています。このファイルは Docker コンテナにバインドする必要があります。

1 つのログファイルから手動でログをアップロードする場合にこれを使用します。これは、特定のログファイルのログをバックフィルするために使用できます。

Docker コンテナから Google Security Operations フォワーダーを起動します。

  docker run `
    --name cfps `
    --log-opt max-size=100m `
    --log-opt max-file=10 `
    -p 10514:10514 `
    -v c:/opt/chronicle/config:c:/opt/chronicle/external `
    -v c:/var/log/crowdstrike/falconhoseclient:c:/opt/chronicle/edr `
     gcr.io/chronicle-container/cf_production_stable

複数のオプションまたは複数の範囲を使用して、複数のポートを追加できます。例: -p 3001:3000 -p 2023:2022、または -p 7000-8000:7000-8000。

負荷ボリュームをコンテナにマッピングするには、この docker run コマンドが重要です。

この例に基づいて、Google Security Operations フォワーダーの構成（FORWARDER_NAME.conf ファイル）を次のように変更します。sample.txt ファイルは、/var/log/crowdstrike/falconhostclient フォルダに存在する必要があります。

 collectors:
  - file:
       common:
         enabled: true
         data_type: CS_EDR
         data_hint:
         batch_n_seconds: 10
         batch_n_bytes: 1048576
       file_path: c:/opt/chronicle/edr/output/sample.txt
       filter:

フラグ構成

skip_seek_to_end（bool）: このフラグはデフォルトで false に設定され、ファイル入力では新しいログ行のみが入力として送信されます。これを true に設定すると、フォワーダーの再起動中に、以前のすべてのログ行が再送信されます。これにより、ログが重複します。このフラグを true に設定すると、特定の状況（停止時など）で役立ちます。フォワーダーを再起動すると、欠落したログ行が再度送信されるからです。

poll（bool）: ファイル コレクタは Tail ライブラリを使用して、ファイル システムの変更を確認します。このフラグを true に設定すると、Tail ライブラリはデフォルトの通知メソッドではなく、ポーリング メソッドを使用します。

パケットデータを収集する

Google Security Operations フォワーダーでは、Windows システムの Npcap を使用してネットワーク インターフェースから直接パケットをキャプチャできます。

パケットはキャプチャされ、ログエントリではなく Google Cloud に送信されます。キャプチャはローカル インターフェースからのみ行われます。

Google Security Operations　のサポートにお問い合わせのうえ、パケット キャプチャをサポートするよう Google Security Operations　のフォワーダー構成ファイルを更新してください。

パケット キャプチャ（PCAP）フォワーダーを実行するには、次の要件を満たすことが必要です。

  • Microsoft Windows ホストに Npcap をインストールします。

  • Google Security Operations フォワーダーに root または管理者権限を付与して、ネットワーク インターフェースをモニタリングします。

  • コマンドライン オプションは必要ありません。

  • Npcap のインストールで、WinPcap 互換モードを有効にします。

PCAP フォワーダーを構成するには、パケットのキャプチャに使用するインターフェースに GUID が必要です。 Google Security Operations フォワーダーをインストールするマシン（サーバーまたはスパンポートをリッスンするマシン）で getmac.exe を実行し、出力を Google Security Operations に送信します。

別の方法では、構成ファイルを変更することでも可能です。PCAP セクションを見つけ、インターフェースの横にある GUID の値を、getmac.exe の実行で表示される GUID に置き換えます。

たとえば、次のような元の PCAP セクションがあるとします。

- pcap:
      common:
        enabled: true
        data_type: PCAP_DNS
        batch_n_seconds: 10
        batch_n_bytes: 1048576
      interface: \Device\NPF_{1A7E7C8B-DD7B-4E13-9637-0437AB1A12FE}
      bpf: udp port 53

getmac.exe を実行した結果は次のとおりです。

C:\>getmac.exe
  Physical Address    Transport Name
  ===========================================================================
  A4-73-9F-ED-E1-82   \Device\Tcpip_{2E0E9440-ABFF-4E5B-B43C-E188FCAD1234}

最後に、新しい GUID で修正した PCAP セクションを次に示します。

- pcap:
      common:
        enabled: true
        data_type: PCAP_DNS
        batch_n_seconds: 10
        batch_n_bytes: 1048576
      interface: \Device\NPF_{2E0E9440-ABFF-4E5B-B43C-E188FCAD9734}
      bpf: udp port 53

Kafka トピックからデータを収集する

syslog と同じように、Kafka トピックからデータを取り込むことができます。コンシューマ グループを使用すると、最大 3 つの Google Security Operations フォワーダーをデプロイし、同じ Kafka トピックからデータを pull できます。詳細については、Kafka をご覧ください。

Kafka コンシューマー グループの詳細については、Kafka コンシューマー グループをご覧ください。

構成例: Kafka の入力

次の Google Security Operations フォワーダーの構成は、Kafka トピックからデータを取り込むように Google Security Operations フォワーダーを設定する方法を示しています。

FORWARDER_NAME.conf ファイル

collectors:
- kafka:
      common:
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: NIX_SYSTEM
        enabled: true
      topic: example-topic
      group_id: chronicle-forwarder
      timeout: 60s
      brokers: ["broker-1:9092", "broker-2:9093"]
      tls:
        insecureSkipVerify: true
        certificate: "c:/path/to/cert.pem"
        certificate_key: "c:/path/to/cert.key"
- syslog:
      common:
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: WINEVTLOG
        enabled: true
      tcp_address: 0.0.0.0:30001
      connection_timeout_sec: 60

FORWARDER_NAME_auth.conf ファイル

collectors:
- kafka:
      username: user
      password: password
- syslog:

WebProxy データを収集する

Google Security Operations フォワーダーは、Npcap を使用してネットワーク インターフェースから直接 WebProxy データをキャプチャし、Google Cloud に送信できます。

システムの WebProxy データ キャプチャを有効にするには、Google Security Operations　のサポートにお問い合わせください。

WebProxy フォワーダーを実行する前に、次の操作を行います。

  1. Microsoft Windows ホストに Npcap をインストールします。インストール中に WinPcap 互換モードを有効にします。

  2. Google Security Operations フォワーダーに root または管理者権限を付与して、ネットワーク インターフェースをモニタリングします。

  3. WebProxy フォワーダーを構成するには、Google Cloud では WebProxy パケットをキャプチャするインターフェースに GUID が必要です。

    Google Security Operations フォワーダーをインストールするマシンで getmac.exe を実行し、出力を Google Security Operations に送信します。別の方法では、構成ファイルを変更することでも可能です。[WebProxy] セクションを見つけ、インターフェースの横にある GUID を、getmac.exe の実行後に表示される GUID に置き換えます。

    Google Security Operations フォワーダーの構成（FORWARDER_NAME.conf）ファイルを次のように変更します。

      - webproxy:
    common:
        enabled : true
        data_type: <Your LogType>
        batch_n_seconds: 10
        batch_n_bytes: 1048576
      interface: \Device\NPF_{2E0E9440-ABFF-4E5B-B43C-E188FCAD9734}
      bpf: tcp and dst port 80

構成をカスタマイズする

次の表に、フォワーダー構成ファイルで使用される重要なパラメータを示します。

パラメータ 説明
data_type コレクタが収集、処理できるログデータのタイプ。
メタデータ メタデータ。グローバル メタデータをオーバーライドします。
max_file_buffer_bytes ディスクまたはファイル バッファに蓄積できる最大バイト数。デフォルト値は 1073741824 で、1 GB です。
max_memory_buffer_bytes メモリバッファに蓄積できる最大バイト数。デフォルト値は 1073741824 で、1 GB です。
write_to_disk_dir_path ファイルまたはディスク バッファに使用されるパス。
write_to_disk_buffer_enabled true の場合、メモリ バッファの代わりにディスク バッファが使用されます。デフォルト値は false です。
batch_n_bytes コレクタが累積できる最大バイト数。これを超えると、データがバッチ処理されます。デフォルト値は 1048576 で、1 MB です。
batch_n_seconds コレクタが収集したデータがバッチ処理されるまでの秒数。デフォルト値は 11 秒です。
data_hint コレクタが受信できるデータ形式（通常は、形式を記述したログファイルのヘッダー）。

構成ファイルで使用されるパラメータの広範なリストについては、フォワーダーの構成フィールドとコレクタの構成フィールドをご覧ください。

データ圧縮を切り替える

ログ圧縮により、ログを Google Security Operations に転送する際のネットワーク帯域幅の使用量が削減されます。ただし、圧縮によって CPU 使用率が増加する場合があります。 CPU 使用率と帯域幅のトレードオフは、ログデータのタイプ、データの圧縮率、 Google Security Operations フォワーダーを実行しているホスト上の CPU サイクルの可用性、ネットワーク帯域幅の使用量の削減の必要性など、さまざまな要因によって決まります。

たとえば、テキストベースのログは圧縮率が高く、低い CPU 使用率によって帯域幅を大幅に削減できます。一方、未加工のパケットの暗号化されたペイロードは圧縮率が低く、CPU 使用率が高くなります。

デフォルトでは、ログ圧縮は無効になっています。ログ圧縮を有効にすると、帯域幅の使用量が減少する可能性があります。ただし、ログ圧縮を有効にすると CPU 使用率も増加する可能性があります。ただし、このトレードオフに注意します。

ログ圧縮を有効にするには、次の例に示すように、Google Security Operations フォワーダー構成ファイルの compression フィールドを true に設定します。

FORWARDER_NAME.conf ファイル

output:
  compression: true
    url: malachiteingestion-pa.googleapis.com:443
    identity:
      identity:
      collector_id: 10479925-878c-11e7-9421-10604b7cb5c1
      customer_id: ebdc4bb9-878b-11e7-8455-10604b7cb5c1
...

FORWARDER_NAME_auth.conf ファイル

output:
  identity:
    secret_key: |
    {
     "type": "service_account",
...
    }

ディスク バッファリングを構成する

ディスク バッファリングを使用すると、バックログにあるメッセージをメモリではなくディスクにバッファリングできます。バックログにあるメッセージは、Google Security Operations フォワーダーがクラッシュした場合や、基盤となるホストがクラッシュした場合に備えて保存できます。ディスク バッファリングを有効にするとパフォーマンスに影響する可能性があるので注意してください。

ディスク バッファリングが無効になっている場合、Google Security Operations フォワーダーは、ログタイプ（たとえば、各コネクタなど）ごとに 1 GB のメモリ（RAM）を使用します。max_memory_buffer_bytes 構成パラメータを指定します。最大許容サイズは 4 GB です。

自動ディスク バッファリングを構成すると、コレクタ間で動的に共有されるバッファを使用できます。これにより、トラフィックの急増に対応できます。動的に共有されるバッファを有効にするには、フォワーダー構成に次の行を追加します。

auto_buffer:
  enabled: true
  target_memory_utilization: 80

自動ディスク バッファリングが有効になっていても、target_memory_utilization が定義されていない場合は、デフォルト値の 70 が使用されます。

Docker を使用して Google Security Operations フォワーダーを実行している場合は、分離の目的のため、構成ボリュームとは別のボリュームをマウントすることをおすすめします。また、競合を避けるために、各入力を独自のディレクトリまたはボリュームで分離するべきです。

構成例: ディスク バッファリング

次の構成には、ディスク バッファリングを有効にする構文が含まれています。

collectors:
- syslog:
    common:
      write_to_disk_buffer_enabled: true
      # c:/buffers/NIX_SYSTEM is part of the external mounted volume for the
forwarder
      write_to_disk_dir_path: c:/buffers/NIX_SYSTEM
      max_file_buffer_bytes: 1073741824
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60

正規表現フィルタを設定する

正規表現フィルタを使用すると、正規表現と未加工のログの照合に基づいてログをフィルタできます。

フィルタでは RE2 構文を使用します。

フィルタには正規表現を含める必要があります。また、必要に応じて、一致した場合の動作を定義します。一致のデフォルトの動作は「ブロック」です（ブロックとして明示的に構成できます）。

また、allow の動作でフィルタを指定することもできます。allow フィルタを指定すると、Google Security Operations フォワーダーによって、少なくとも 1 つの allow フィルタに一致しないログがブロックされます。

任意の数のフィルタを定義できます。ブロック フィルタは、allow フィルタよりも優先されます。

フィルタを定義する場合は、名前を割り当てる必要があります。アクティブなフィルタの名前は、フォワーダーのヘルス指標を介して Google Security Operations に報告されます。構成のルートで定義されたフィルタは、コレクタレベルで定義されたフィルタと結合されます。名前が競合する場合、コレクタレベルのフィルタが優先されます。ルートレベルまたはコレクタレベルでフィルタが定義されていない場合、動作はすべてを許可します。

構成例: 正規表現フィルタ

次の Google Security Operations フォワーダー構成では、ルートフィルタ（allow_filter）に一致しない WINEVTLOG ログがブロックされます。正規表現では、フィルタでは 0 から 99 の間の優先度を持つログのみが許可されます。 ただし、「foo」または「bar」を含む NIX_SYSTEM ログは、allow_filter にかかわらずブロックされます。これは、フィルタが論理 OR を使用するためです。フィルタがトリガーされるまで、すべてのログが処理されます。

regex_filters:
  allow_filter:
    regexp: ^<[1-9][0-9]?$>.*$
    behavior_on_match: allow
collectors:
- syslog:
    common:
      regex_filters:
        block_filter_1:
          regexp: ^.*foo.*$
          behavior_on_match: block
        block_filter_2:
          regexp: ^.*bar.*$
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60

任意のラベルを構成する

ラベルは、キーと値のペアを使用してログに任意のメタデータを追加するために使用されます。ラベルは、Google Security Operations フォワーダー全体に対して、または Google Security Operations フォワーダーの特定のコレクタ内で構成できます。両方が指定されている場合、ラベルには、chronicle のフォワーダー キーが重複する場合にコレクタのキーが優先してマージされます。

構成例: 任意のラベル

次の Google Security Operations フォワーダー構成では、foo=bar と meow=mix の Key-Value ペアの両方が WINEVTLOG ログと、foo=baz と meow=mix に関連付けられます。キーと値のペアが NIX_SYSTEM ログにアタッチされます。

metadata:
  labels:
    foo: bar
    meow: mix
collectors:
syslog:
    common:
      metadata:
        labels:
          foo: baz
          meow: mix
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60

名前空間を構成する

名前空間ラベルを使用して、異なるネットワーク セグメントのログを識別し、重複する IP アドレスの競合を解決します。名前空間ラベルは、Google Security Operations フォワーダー全体に対して、または Google Security Operations フォワーダーの特定のコレクタ内で構成できます。両方が含まれている場合、特定のコレクタの名前空間が優先されます。

Google Security Operations フォワーダーに構成された名前空間は、関連するアセットとともに Google Security Operations のユーザー インターフェースに表示されます。Google Security Operations の検索機能を使用して名前空間を検索することもできます。

Google Security Operations のユーザー インターフェースで名前空間を表示する方法については、こちらをご覧ください。

構成例: 名前空間

次の Google Security Operations フォワーダー構成では、WINEVTLOG ログが FORWARDER 名前空間にアタッチされ、NIX_SYSTEM ログが CORPORATE 名前空間にアタッチされます。

metadata:
  namespace: FORWARDER
collectors:
- syslog:
      common:
        metadata:
          namespace: CORPORATE
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: NIX_SYSTEM
        enabled: true
      tcp_address: 0.0.0.0:30000
      connection_timeout_sec: 60
- syslog:
      common:
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: WINEVTLOG
        enabled: true
      tcp_address: 0.0.0.0:30001
      connection_timeout_sec: 60

ロード バランシングと高可用性のオプションを構成する

Windows on Docker 用の Google Security Operations フォワーダーは、データソースと Google Security Operations フォワーダー インスタンスの間にレイヤ 4 ロードバランサがインストールされている環境にデプロイできます。これにより、ログ収集を複数の Google Security Operations フォワーダーに分散できます。また、1 つの Google Security Operations フォワーダーに障害が発生した場合は、別の Google Security Operations フォワーダーにログを送信できます。この機能は、syslog 収集タイプでのみサポートされています。

Windows on Docker 用の Google Security Operations フォワーダーには、ロードバランサからの HTTP ヘルスチェックに応答する組み込みの HTTP サーバーが含まれています。HTTP サーバーはまた、Google Security Operations フォワーダーの起動時またはシャットダウン中にログが失われないようにします。

Google Security Operations フォワーダー構成ファイルの server セクションで、HTTP サーバー、ロード バランシング、高可用性オプションを構成します。これらのオプションは、コンテナ スケジューラやオーケストレーション ベースのデプロイで受信されるヘルスチェックや、従来のロードバランサで受信されるヘルスチェックに応じて返されるタイムアウト期間とステータス コードの設定をサポートします。

次の URL パスを使用して、ヘルス、readiness、liveness のチェックを行います。 <host:port> 値は、Google セキュリティ オペレーション フォワーダー構成で定義されます。

  • http://<host:port>/meta/available: Kubernetes などのコンテナ スケジューラ / オーケストレーターの liveness チェック。
  • http://<host:port>/meta/ready: readiness チェックと従来のロードバランサのヘルスチェック。

次の Google Security Operations フォワーダー構成は、ロード バランシングと高可用性の例です。

collectors:
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60
server:
  graceful_timeout: 15s
  drain_timeout: 10s
  http:
    port: 8080
    host: 0.0.0.0
    read_timeout: 3s
    read_header_timeout: 3s
    write_timeout: 3s
    idle_timeout: 3s
    routes:
    - meta:
        available_status: 204
        ready_status: 204
        unready_status: 503
設定パス 説明
server : graceful_timeout Google Security Operations フォワーダーが不適切な readiness やヘルスチェックを返していながら新しい接続を引き続き受け入れている時間。これは、停止する信号を受信してから実際にサーバー自体のシャットダウンが開始されるまで、待機する時間でもあります。これにより、ロードバランサがプールから Google Security Operations フォワーダーを削除する時間を確保できます。
server : drain_timeout アクティブな接続がサーバーによって閉じられる前に、独自に正常に終了するまで Google Security Operations フォワーダーが待機する時間。
server : http : port HTTP サーバーがロードバランサからのヘルスチェックをリッスンするポート番号。1024 ～ 65535 にする必要があります。
server : http : host IP アドレス、または、サーバーがリッスンする IP アドレスに解決できるホスト名。空の場合、デフォルト値はローカル システム（0.0.0.0）です。
server : http : read_timeout HTTP サーバーの調整に使用されます。通常、デフォルト設定から変更する必要はありません。ヘッダーと本文の両方のリクエスト全体の読み取りが許可される最大時間。read_timeout と read_header_timeout の両方を設定できます。
server : http : read_header_timeout HTTP サーバーの調整に使用されます。通常、デフォルト設定から変更する必要はありません。リクエスト ヘッダーを読み取ることができる最大時間。接続の読み取り期限は、ヘッダーの読み取り後にリセットされます。
server : http : write_timeout HTTP サーバーの調整に使用されます。通常、デフォルト設定から変更する必要はありません。レスポンスの送信に許可される最大時間。 新しいリクエスト ヘッダーが読み取られるとリセットされます。
server : http : idle_timeout HTTP サーバーの調整に使用されます。通常、デフォルト設定から変更する必要はありません。アイドル状態の接続が有効な場合に、次のリクエストを待機する最大時間。idle_timeout が 0 の場合は、read_timeout の値が使用されます。両方がゼロの場合、read_header_timeout が使用されます。
routes : meta : ready_status 次のいずれかの状況でトラフィックを受け入れる準備ができた場合に、Google Security Operations フォワーダーが返すステータス コード。
  • 準備チェックは、Kubernetes などのコンテナ スケジューラまたはオーケストレーターから受信されます。
  • ヘルスチェックは、従来のロードバランサから受信されます。
routes : meta : unready_status トラフィックを受け入れる準備ができていない場合に、Google Security Operations フォワーダーが返すステータス コード。
routes : meta : available_status 実行チェックが受信され、Google Security Operations フォワーダーが利用可能な場合に、Google Security Operations フォワーダーが返すステータス コード。Kubernetes などのコンテナのスケジューラ / オーケストレーターは、多くの場合、liveness チェックを行います。