パーサー拡張機能の使用

Chronicle には、元のログのデータを解析して統合データモデル（UDM）レコードに正規化する方法を定義する複数のメソッドが用意されています。

デフォルトのパーサー: 元のログデータを UDM フィールドにマッピングする、Chronicle が管理する事前構築済みのデータマッピング指示。
カスタムパーサー: お客様の特定のデータ解析ニーズを満たすために、お客様が作成および管理するカスタムデータマッピング指示。
パーサー拡張機能: デフォルトパーサーまたはカスタムパーサーを拡張して、元の未加工ログに追加フィールドにマッピングするための追加のデータマッピング指示。この指示は、デフォルトパーサーまたはカスタムパーサーを完全に置き換えるものではありませんが、デフォルトパーサーまたはカスタムパーサー内の既存のマッピング命令は拡張されます。

このドキュメントでは、パーサー拡張機能の使用方法について説明します。

準備

次のドキュメントでは、パーサー拡張機能を操作する際の重要なコンセプトについて説明します。

パーサー拡張機能について

パーサー拡張機能を使用すると、デフォルトまたはカスタムパーサーで定義されているもの以外の追加のマッピング指示を作成し、固有のユースケースに対応できます。この機能は、既存のデフォルトまたはカスタムのパーサーを拡張することを目的としています。パーサー拡張機能は、デフォルトパーサーまたはカスタムパーサーを置き換えるものではありません。パーサー拡張機能を使用して新しいパーサーを作成することはできません。

パーサー拡張機能は、元のログを読み取り、抽出した値を UDM レコードの特定のフィールドに挿入します。UDM レコードには、デフォルトパーサーまたはカスタムパーサーとパーサー拡張機能の両方によって設定されたデータが含まれます。

パーサー拡張機能のデータマッピング指示は、デフォルトパーサーまたはカスタムパーサーのデータマッピング指示よりも優先されます。マッピング指示に競合がある場合、パーサー拡張機能は、デフォルトパーサーまたはカスタムパーサーによって設定された値を上書きします。たとえば、デフォルトのパーサーが未加工のログフィールドを event.metadata.description UDM フィールドにマッピングし、パーサー拡張機能が別の未加工ログフィールドを同じ UDM フィールドにマッピングする場合、パーサー拡張機能は、デフォルトのパーサーによって設定された値を上書きします。繰り返しフィールドは例外です。繰り返しフィールドにデータを書き込むときに値を追加するようにパーサー拡張機能を構成できます。

ログタイプごとに 1 つのパーサー拡張機能を作成します。各ログタイプは一意の取り込みラベルによって識別されます。ログタイプのリストについては、サポートされるデフォルトパーサーをご覧ください。

パーサー拡張機能を作成するには、Chronicle がデフォルトパーサーまたはカスタムパーサーを使用して元のログを取り込み、正規化できる必要があります。パーサー拡張機能は、元のログから追加データを抽出し、UDM レコードにマージします。

パーサー拡張機能は、次のタイプのマッピング指示をサポートします。

コードスニペットのタイプ: デフォルトパーサーとカスタムパーサーに類似したパーサーコードを作成します。元のログは、ログタイプでサポートされているデータ形式のいずれかになります。
データフィールドタイプ: アプリケーションインターフェースで送信元と宛先のフィールドを指定します。元のログは、次のいずれかの形式にする必要があります。
- ネイティブ JSON、ネイティブ XML、CSV のいずれか。
- syslog ヘッダーとネイティブ JSON、ネイティブ XML、CSV のいずれか。サポートされるデフォルトパーサーで、ログタイプのサブセットのデータフィールドタイプのマッピング指示を作成できます。JSON、XML、CSV、SYSLOG + JSON、SYSLOG + XML、SYSLOG + CSV の形式のものを探します。

パーサー拡張機能を作成するときは、次の点に注意してください。

データは、標準データ型と繰り返し値をサポートする任意の UDM フィールドにマッピングできます。
次の UDM フィールドにデータをマッピングすることはできません。
- event.idm.read_only_udm.additional
- event.idm.graph.entity.additional
データマッピング指示を作成する前に、過去 30 日間に Chronicle インスタンスが元のログを取り込んでいること、これらの未加工ログに前提条件で定義しようとしているフィールドが含まれていることを確認してください。これらの元のログは、データマッピング指示の検証に使用されます。
パーサー拡張機能は、公開された後に受信データの解析を開始します。過去に遡って未加工のログデータを解析することはできません。

パーサー拡張機能のライフサイクル

パーサー拡張機能のライフサイクルには次のような状態があります。

DRAFT: 新しく作成され、まだ送信されていないパーサー拡張機能。
VALIDATING: Chronicle は、既存の未加工ログに対してマッピング指示を検証し、フィールドが確実にエラーなしで解析されるようにします。
LIVE: パーサー拡張機能が検証に合格し、現在本番環境で稼働中です。受信の未加工ログからデータを抽出して変換し、UDM レコードに変換します。
FAILED: パーサー拡張機能の検証で不合格になりました。

パーサー拡張機能のページを開く

次のいずれかの指示で [now in production] ページにアクセスします。

ナビゲーションバーから開始する

ナビゲーションバーで、[Settings]、[SIEM Settings]、[Parser] の順に選択します。
[Parser] テーブルで、拡張するログタイプを特定します。
その行に移動し、 [メニュー] をクリックします。
[拡張機能を作成] をクリックします。

未加工ログ検索から開始する

未加工ログ検索を使用して、解析されるレコードと同様のレコードを検索します。
[イベント] > [タイムライン] パネルからイベントを選択します。
[イベントデータ] パネルを開きます。
[パーサーの管理] ボタンをクリックします。
[パーサーの管理] ダイアログで、[拡張機能の作成] を選択し、[次へ] をクリックします。[パーサー拡張機能] ページが編集モードで開きます。パーサー拡張機能の定義を開始できます。

新しいパーサー拡張機能を作成する

このセクションでは、[パーサー拡張機能] ページを開いた後にパーサー拡張機能を作成する方法について説明します。[パーサー拡張機能] ページで使用できるフィールドは、未加工のログの構造によって異なります。

[未加工ログ] パネルで未加工のサインの例を確認して、パーサー拡張機能が処理するログを表していることを確かめます。パーサー拡張機能を作成するときは、サンプルの未加工ログの例を参考にしてください。
- 未加工ログ検索から [パーサー拡張機能] に移動すると、パネルには検索結果で選択した元の未加工ログが表示されます。
- ナビゲーションバーの [Parser Extensions] に移動すると、そのログタイプのサンプルの未加工ログが表示されます。
注: [未加工ログ] パネルではデータの編集はできません。[表示方法] メニューと [テキストを折り返す] チェックボックスを使用して、未加工ログ文字列をフォーマットできます。
[拡張方法] を選択します。次のいずれかを選択します。
- データフィールドのマッピング: データフィールドのマッピングを作成します。アプリケーションフィールドを使用して、元のログフィールドと宛先 UDM フィールドを定義します。
- コードスニペットを作成する: サポートされているすべてのログ形式のコードスニペットを作成します。コードスニペットは、デフォルトパーサーとカスタムパーサーと同じパーサー構文を使用します。パーサー構文の詳細については、パーサー構文をご覧ください。
注: コードスニペットマッピングの指示と、データフィールドのマッピング指示を混在させることはできません。

選択した拡張方法に固有の以下のいずれかのサブセクションに進みます。

データフィールドのマッピング指示を作成する
コードスニペットのマッピング指示を作成する

データフィールドのマッピング指示を作成する

受信の未加工のログが JSON、XML、CSV、Syslog ヘッダーと JSON、Syslog ヘッダーと XML、または Syslog ヘッダーと CSV 形式の場合のデータフィールドマッピング指示を作成します。データマッピング指示で、元のフィールド名と宛先 UDM フィールドへのパスを定義します。

[繰り返しフィールド] セレクタで、値の配列をサポートするフィールドにパーサー拡張機能が値を保存する方法を指定します。
- 値の追加: 値は、フィールドに保存されている既存の値のセットに追加されます。
- 値の置換: 値は、以前に保存したすべての値を新しい値に置き換えます。
一部の UDM フィールド（principal.ip や entity.asset.hostname など）には、値の配列が保存されます。これらの繰り返しフィールドは、統合データモデルフィールドリストの repeated ラベルで識別されます。詳細については、繰り返しフィールドセレクタをご覧ください。

重要: データフィールドマッピングの指示には、繰り返しフィールドが階層の最下位レベルにある場合にのみ、繰り返しフィールドを含めることができます。たとえば、ip は階層の最下位レベルにあり、principal は繰り返しフィールドではないため、値は udm.principal.ip 繰り返しフィールドにマッピングできます。intermediary は繰り返しフィールドであり、階層の最下位レベルにないため、値を udm.intermediary.hostname にマッピングすることはできません。
[Syslog] フィールドと [Target] フィールドが表示される場合、Chronicle は未加工のログに Syslog ヘッダーが含まれていることを検出したということです。

サンプルの未加工ログがネイティブ JSON、ネイティブ XML、または CSV ではなく、Syslog ヘッダーがあることを Chronicle が識別すると、Syslog フィールドと Target フィールドが表示されます。次のフィールドを使用して Syslog ヘッダーを前処理し、ログの構造化された部分を抽出する Grok と正規表現パターンを定義します。ログの構造化された部分は、データフィールドを使用してマッピングできます。
- [Syslog] フィールド: Grok と正規表現を使用して、Syslog ヘッダーと未加工のログメッセージを識別する抽出パターンを指定します。
- ターゲット フィールド: ログの構造化部分を格納する抽出パターンに変数名を指定します。
Grok と正規表現を使用して抽出パターンを定義する方法については、Syslog エクストラクタフィールドを定義するをご覧ください。

次の図は、Syslog フィールドと Target フィールドに抽出パターンと変数名をそれぞれ追加する例を示しています。

[Syslog] フィールドと [Target] フィールドの両方が必須であり、ログの構造化部分から Syslog ヘッダーを分離するために連携します。
[Syslog] フィールドと [Target] フィールドに値を入力したら、[検証] ボタンをクリックします。検証プロセスでは、構文エラーと解析エラーの両方がチェックされ、次のいずれかが返されます。
- 成功: データマッピングフィールドが表示されます。パーサー拡張機能の残りの部分を定義します。
- 失敗: エラーメッセージが表示されます。続行する前にエラーを修正してください。
必要に応じて、前提条件の指示を定義します。

前提条件の指示では、静的な値を未加工のログのフィールドと照合することで、パーサー拡張機能が処理する元の未加工のログのサブセットのみを識別します。受信した未加工のログが前提条件の基準を満たしている場合、つまり値と一致する場合、パーサー拡張機能はマッピングの指示を適用します。値が一致しない場合、パーサー拡張機能はマッピングの指示を適用しません。

次のフィールドに値を入力します。
- 前提条件フィールド: ログデータ形式が JSON または XML の場合はフィールドへのフルパスを入力し、データ形式が CSV の場合は列位置を入力します。
- 前提条件の演算子: EQUALS または NOT EQUALS を選択します。
- 前提条件の値: [前提条件フィールド] にデータと一致する必要がある値を入力します。
データマッピング命令を定義します。
- 未加工データフィールド: ログデータ形式が JSON または XML の場合はフィールドへのフルパスを入力し、データ形式が CSV の場合は列位置を入力します。
- 宛先フィールド: 値が保存される完全修飾 UDM フィールド名を入力します（例: udm.metadata.collected_timestamp.seconds）。
重要: 元の未加工ログが JSON 形式の場合、元のログ値のデータ型は宛先 UDM フィールドのデータ型と一致する必要があります。たとえば、元のログに文字列（"packets_sent":"16"）として送信されたパケットが記録されており、これを uint64 データ型の network.sent_bytes UDM フィールドにマッピングしようとすると、この指示は失敗します。この要件は、CSV 形式と XML 形式のログには適用されません。
[Submit] をクリックして、マッピング指示を保存します。

Chronicle がマッピング指示を検証します。

検証プロセスが成功すると、状態は [ライブ] に変化し、マッピング指示は受信ログデータの処理を開始します。
検証プロセスが失敗すると、状態は [失敗] に変わり、エラーが [未加工のログ] フィールドに表示されます。

検証エラーの例を次に示します。

ERROR: generic::unknown: pipeline.ParseLogEntry failed: LOG_PARSING_CBN_ERROR:
"generic::invalid_argument: pipeline failed: filter mutate (7) failed: copy failure:
copy source field \"jsonPayload.dest_instance.region\" must not be empty
(try using replace to provide the value before calling copy)

"LOG: {"insertId":"14suym9fw9f63r","jsonPayload":{"bytes_sent":"492",
"connection":{"dest_ip":"10.12.12.33","dest_port":32768,"protocol":6,
"src_ip":"10.142.0.238","src_port":22},"end_time":"2023-02-13T22:38:30.490546349Z",
"packets_sent":"15","reporter":"SRC","src_instance":{"project_id":"example-labs",
"region":"us-east1","vm_name":"example-us-east1","zone":"us-east1-b"},
"src_vpc":{"project_id":"example-labs","subnetwork_name":"default",
"vpc_name":"default"},"start_time":"2023-02-13T22:38:29.024032655Z"},
"logName":"projects/example-labs/logs/compute.googleapis.com%2Fvpc_flows",
"receiveTimestamp":"2023-02-13T22:38:37.443315735Z","resource":{"labels":
{"location":"us-east1-b","project_id":"example-labs",
  "subnetwork_id":"00000000000000000000","subnetwork_name":"default"},
  "type":"gce_subnetwork"},"timestamp":"2023-02-13T22:38:37.443315735Z"}

パーサー拡張機能で使用可能なすべてのフィールドのリストについては、データマッピング指示のフィールドをご覧ください。

データマッピング指示のフィールド

このセクションでは、パーサー拡張機能で設定できるすべてのフィールドについて説明します。

フィールド名	説明
Syslog	Syslog ヘッダーを前処理して未加工のログの構造化された部分から分離するユーザー定義のパターン。
ターゲット	ログの構造化された部分を保存する Syslog フィールドの変数名。
前提条件フィールド	比較する値を含む未加工のログのフィールド識別子。前提条件の指示で使用されます。
前提条件の演算子	`EQUALS` または `NOT EQUALS` を選択します。前提条件の指示で使用されます。
前提条件の値	未加工ログの Precondition Field と比較される静的な値。前提条件の指示で使用されます。
元データフィールド	マッピング指示で使用されます。データ形式が JSON の場合は、フィールドへのパスを定義します（例: `jsonPayload.connection.dest_ip`）。データ形式が XML の場合、フィールドへの完全なパス（`/Event/Reason-Code` など）を定義します。データ形式が CSV の場合、列のインデックス位置を定義します。インデックスの位置は 1 から始まります。
接続先フィールド	マッピング指示で使用されます。データが保存される UDM フィールドのフルパスを定義します。例: `udm.network.dhcp.opcode` または `graph.entity.asset.hostname`

コードスニペットのマッピング指示を作成する

コードスニペットでは、Logstash に似た構文を使用して、元のログの値を抽出して変換し、UDM レコードに割り当てる方法を定義します。コードスニペットでは、デフォルトパーサーまたはカスタムパーサーと同じ構文と命令のセクションが使用されます。コードスニペットのセクションは次のとおりです。

セクション 1. 元のログからデータを抽出します。
セクション 2. 抽出されたデータを変換します。
セクション 3. UDM フィールドに 1 つ以上の値を割り当てます。
セクション 4. UDM イベントフィールドを @output キーにバインドします。

次の例は、コードスニペットを示しています。

未加工のログの例を次に示します。

{
    "insertId": "00000000",
    "jsonPayload": {
        ...section omitted for brevity...
        "packets_sent": "4",
        ...section omitted for brevity...
    },
    "timestamp": "2022-05-03T01:45:00.150614953Z"
}

次のサンプルコードスニペットは、jsonPayload.packets_sent の値を network.sent_bytes UDM フィールドにマッピングします。

filter {
    # Section 1. extract the data from the original JSON log
    json {
        source => "message"
        array_function => "split_columns"
    }

   # Section 2. transform the extracted data
    mutate {
      convert => {
        "jsonPayload.packets_sent" => "uinteger"
      }
    }

    # Section 3. assign the value to a UDM field
    mutate {
        copy => {
          "event.idm.read_only_udm.network.sent_bytes" => "jsonPayload.packets_sent"
        }
    }

    # Section 4. Bind the UDM fields to the @output key
    mutate {
      merge => {
          "@output" => "event"
      }
    }
}

[Submit] をクリックして、マッピング指示を保存します。
Chronicle がマッピング指示を検証します。
- 検証プロセスが成功すると、状態は [ライブ] に変化し、マッピング指示は受信ログデータの処理を開始します。
- 検証プロセスが失敗すると、状態は [失敗] に変わり、エラーが [未加工のログ] フィールドに表示されます。
注: パーサー拡張機能の検証中は、データマッピング命令を編集できません。

既存のパーサー拡張機能を表示する

ナビゲーションバーで、[Settings]、[SIEM Settings]、[Parser] の順に選択します。
パーサーのリストで、パーサー拡張機能を使用してログタイプを特定します。これは、名前の横の EXTENSION というテキストで識別されます。
その行に移動し、 [メニュー] をクリックします。
[拡張機能を表示] をクリックします。
[カスタム / 事前構築済みパーサーの表示] > [拡張機能] タブにパーサー拡張機能の詳細が表示されます。概要パネルには、デフォルトで LIVE パーサー拡張機能が表示されます。

パーサー拡張機能を編集する

[カスタム / 事前構築済みパーサーの表示] > [拡張機能] タブを開きます。このページを開く方法については、既存のパーサー拡張機能を表示するをご覧ください。
[拡張機能を編集] ボタンをクリックします。[パーサー拡張機能] ページが表示されます。
パーサー拡張機能を編集します。
- 編集をキャンセルして変更を破棄するには、[下書きを破棄] をクリックします。
パーサー拡張機能の編集が終了したら、[Submit] をクリックします。
変更を送信すると、検証プロセスが実行されて新しい構成が検証されます。

注: パーサー拡張機能の検証中は、データマッピングの指示を編集することはできません。

パーサー拡張機能を削除する

[カスタム / 事前構築済みパーサーの表示] > [拡張機能] タブを開きます。このページを開く方法については、既存のパーサー拡張機能を表示するをご覧ください。
[拡張機能を編集] ボタンをクリックします。[パーサー拡張機能] ページが表示されます。
[拡張機能を削除] ボタンをクリックします。

パーサー拡張機能の編集中は、いつでもそれを削除できます。次のいずれかをクリックします。

下書きを破棄
失敗した拡張機能を削除する

繰り返しフィールドセレクタの詳細

一部の UDM フィールドには、principal.ip や Entity.asset.hostname など、値の配列が保存されます。繰り返しフィールドにデータを格納するパーサー拡張を作成する場合、このオプションを使用すると、値を配列に追加するか、デフォルトのパーサーによって設定された既存の値をすべて置き換えるかを制御できます。繰り返しフィールドは、統合データモデルフィールドリストで繰り返し付けられるラベルによって識別されます。

[値を追加] を選択した場合、パーサー拡張機能は、抽出された値を UDM フィールドの既存の値の配列に追加します。[値を置き換える] が選択されている場合、パーサー拡張機能は UDM フィールドの既存の値の配列を抽出された値に置き換えます。繰り返しフィールド セレクタは、繰り返されていないフィールドへのデータの保存方法には影響しません。

パーサー拡張機能は、繰り返しフィールドが階層の最下位レベルにある場合にのみ、繰り返しフィールドにマッピングできます。たとえば、値の udm.principal.ip へのマッピングはサポートされています。これは、繰り返される ip フィールドは階層の最下位レベルにあり、principal は繰り返しフィールドではないためです。udm.intermediary.hostname への値のマッピングはサポートされていません。これは、intermediary は繰り返しフィールドであり、階層の最下位レベルにないためです。

次の表は、繰り返しフィールド構成が生成された UDM レコードに与える影響の例を示します。

[繰り返しフィールド] の選択	サンプルログ	パーサー拡張機能の構成	生成された結果
値を追加	`{"protoPayload":{"@type":"type.AuditLog","authenticationInfo":{"principalEmail":"admin@cmmar.co"},"requestMetadata":{"callerIp":"1.1.1.1, 2.2.2.2"}}}`	前提条件のフィールド: `protoPayload.requestMetadata.callerIp` 前提条件の値: `" "` 前提条件の演算子: `NOT_EQUALS` 元データフィールド: `protoPayload.requestMetadata.callerIp` 宛先フィールド: `event.idm.read_only_udm.principal.ip`	`metadata:{event_timestamp:{}.....}principal:{Ip:"1.1.1.1, 2.2.2.2"} } }`
値を追加	`{"protoPayload":{"@type":"type.AuditLog","authenticationInfo":{"principalEmail":"admin@cmmar.co"},"requestMetadata":{"callerIp":"2.2.2.2, 3.3.3.3", "name":"Akamai Ltd"}}}`	前提条件 1: 前提条件フィールド:`protoPayload.requestMetadata.callerIp` 前提条件値: `" "` 前提条件演算子: `NOT_EQUALS` 元データフィールド: `protoPayload.requestMetadata.callerIp` 宛先フィールド: `event.idm.read_only_udm.principal.ip` 前提条件 2: 元データフィールド: `protoPayload.requestMetadata.name` 宛先フィールド: `event.idm.read_only_udm.metadata.product_name`	拡張機能を適用する前に事前構築済みパーサーによって生成されたイベント。 `metadata:{event_timestamp:{} ... principal:{ip:"1.1.1.1"}}}` 拡張機能を適用した後の出力。 `timestamp:{} idm:{read_only_udm:{metadata:{event_timestamp:{} .... product_name: "Akamai Ltd"}principal:{ip:"1.1.1.1, 2.2.2.2, 3.3.3.3"}}}`
値を置換する	`{"protoPayload":{"@type":"type..AuditLog","authenticationInfo":{"principalEmail":"admin@cmmar.co"},"requestMetadata":{"callerIp":"2.2.2.2"}}}`	前提条件フィールド: `protoPayload.authenticationInfo.principalEmail` 前提条件の値: `" "` 前提条件演算子: `NOT_EQUALS` 元データフィールド: `protoPayload.authenticationInfo.principalEmail` 宛先フィールド: `event.idm.read_only_udm.principal.ip`	拡張機能を適用する前に事前構築済みパーサーによって生成された UDM イベント。 `timestamp:{} idm:{read_only_udm:{metadata:{event_timestamp:{} ... principal:{ip:"1.1.1.1"}}}` 拡張機能適用後の UDM 出力 `timestamp:{} idm:{read_only_udm:{metadata:{event_timestamp:{} ....} principal:{ip:"2.2.2.2"}}}`

Syslog エクストラクタフィールドの詳細

Syslog エクストラクタフィールドを使用すると、出力を保存するための Grok、正規表現、正規表現パターン内の名前付きトークンを定義することにより、構造化ログから Syslog ヘッダーを分離できます。

Syslog エクストラクタフィールドを定義する

[Syslog] フィールドと [Target] フィールドの値は連携して、パーサー拡張機能で Syslog ヘッダーを未加工ログの構造化部分から分離する方法を定義します。Syslog フィールドでは、Grok と正規表現の組み合わせを使用して式を定義します。この式には、未加工ログの構造部分を識別する変数名が含まれます。[ターゲット] フィールドで、変数名を指定します。

次の例は、これらのフィールドがどのように連携するかを示しています。

未加工ログの例を次に示します。

<13>1 2022-09-14T15:03:04+00:00 fieldname fieldname - - - {"timestamp": "2021-03-14T14:54:40.842152+0000","flow_id": 1885148860701096, "src_ip": "10.11.22.1","src_port": 51972,"dest_ip": "1.2.3.4","dest_port": 55291,"proto": "TCP"}

未加工のログには次のセクションが含まれています。

syslog ヘッダー: <13> 2022-09-14T15:03:04+00:00 fieldname fieldname - - -
JSON 形式のイベント: {"timestamp": "2021-03-14T14:54:40.842152+0000","flow_id": 1885148860701096, "src_ip": "10.11.22.1","src_port": 51972,"dest_ip": "1.2.3.4","dest_port": 55291,"proto": "TCP"}

Syslog ヘッダーを未加工ログの JSON 部分から分離するには、[Syslog] フィールドに次の式の例を使用します: %{TIMESTAMP_ISO8601} %{WORD} %{WORD} ([- ]+)?%{GREEDYDATA:msg}

式の次の部分は、Syslog ヘッダーを識別します: %{TIMESTAMP\_ISO8601} %{WORD} %{WORD} ([- ]+)?
式のこの部分は、未加工ログの JSON セグメントをキャプチャします: %{GREEDYDATA:msg}

この例には、変数名 msg が含まれています。変数名を選択してください。パーサー拡張機能は、未加工のログの JSON セグメントを抽出して、変数 msg に割り当てます。

[ターゲット] フィールドに、変数名 msg を入力します。msg 変数に格納された値は、パーサー拡張機能で作成したデータフィールドマッピング指示に入力されます。

未加工ログの例を使用すると、データマッピング指示に次のセグメントが入力されます。

{"timestamp": "2021-03-14T14:54:40.842152+0000","flow_id": 1885148860701096, "src_ip": "10.11.22.1","src_port": 51972,"dest_ip": "1.2.3.4","dest_port": 55291,"proto": "TCP"}

次の図は、入力済みの [Syslog] フィールドと [ターゲット] フィールドを示しています。

Syslog エクストラクタのフィールド

次の表に、サンプルログ、Syslog 抽出パターン、ターゲット変数名、結果を含むその他の例を示します。

未加工ログのサンプル	Syslog フィールド	ターゲットフィールド	結果
`<13>1 2022-07-14T15:03:04+00:00 suricata suricata - - - {\"timestamp\": \"2021-03-14T14:54:40.842152+0000\",\"flow_id\": 1885148860701096,\"in_iface\": \"enp94s0\",\"event_type\": \"alert\",\"vlan\": 522,\"src_ip\": \"1.1.2.1\",\"src_port\": 51972,\"dest_ip\": \"1.2.3.4\",\"dest_port\": 55291,\"proto\": \"TCP\"}"`	`%{TIMESTAMP_ISO8601} %{WORD} %{WORD} ([- ]+)?%{GREEDYDATA:msg}`	msg	`field_mappings { field: "msg" value: "{\"timestamp\": \"2021-03-14T14:54:40.842152+0000\",\"flow_id\": 1885148860701096,\"in_iface\": \"enp94s0\",\"event_type\": \"alert\",\"vlan\": 522,\"src_ip\": \"1.1.2.1\",\"src_port\": 51972,\"dest_ip\": \"1.2.3.4\",\"dest_port\": 55291,\"proto\": \"TCP\"}" }`
`<13>1 2022-07-14T15:03:04+00:00 suricata suricata - - - {\"timestamp\": \"2021-03-14T14:54:40.842152+0000\"} - - - {\"timestamp\": \"2021-03-14T14:54:40.842152+0000\",\"flow_id\": 1885148860701096,\"in_iface\": \"enp94s0\",\"event_type\": \"alert\",\"vlan\": 522,\"src_ip\": \"1.1.2.1\",\"src_port\": 51972,\"dest_ip\": \"1.2.3.4\",\"dest_port\": 55291,\"proto\": \"TCP\"}`	`%{TIMESTAMP_ISO8601} %{WORD} %{WORD} ([- ]+)?%{GREEDYDATA:msg1} ([- ]+)?%{GREEDYDATA:msg2}`	msg2	`field_mappings { field: "msg2" value: "{\"timestamp\": \"2021-03-14T14:54:40.842152+0000\",\"flow_id\": 1885148860701096,\"in_iface\": \"enp94s0\",\"event_type\": \"alert\",\"vlan\": 522,\"src_ip\": \"1.1.2.1\",\"src_port\": 51972,\"dest_ip\": \"1.2.3.4\",\"dest_port\": 55291,\"proto\": \"TCP\"}" }`
`"<13>1 2022-07-14T15:03:04+00:00 suricata suricata - - - {\"timestamp\": \"2021-03-14T14:54:40.842152+0000\"} - - - {\"timestamp\": \"2021-03-14T14:54:40.842152+0000\",\"flow_id\": 1885148860701096,\"in_iface\": \"enp94s0\",\"event_type\": \"alert\",\"vlan\": 522,\"src_ip\": \"1.1.2.1\",\"src_port\": 51972,\"dest_ip\": \"1.2.3.4\",\"dest_port\": 55291,\"proto\": \"TCP\"}"`	`%{TIMESTAMP_ISO8601} %{WORD} %{WORD} ([- ]+)?%{GREEDYDATA:message} ([- ]+)?%{GREEDYDATA:msg2}`	msg2	`Error - message already exists in state and not overwritable.`

パーサー拡張機能へのアクセスを制御する

パーサー拡張機能を表示、管理できるユーザーを制御する新しい権限が利用可能です。デフォルトでは、管理者ロールを持つユーザーはパーサー拡張機能にアクセスできます。ユーザーとグループの管理、またはロールの割り当ての詳細については、ロールベースのアクセス制御をご覧ください。

次の表に、Chronicle の新しいロールをまとめます。

機能	アクション	Description
パーサー	削除	パーサー拡張機能を削除します。
パーサー	編集	パーサー拡張機能を作成して編集します。
パーサー	表示	パーサー拡張機能を表示します。