このページは Cloud Translation API によって翻訳されました。

データテーブルを使用する

対応しているプロダクト:

Google SecOps SIEM

データテーブルは、ユーザーが独自のデータを Google Security Operations に入力できる、複数列のデータ構造です。データテーブルは、定義済みの列と行にあるデータによってルックアップテーブルとして機能することができます。Google SecOps ウェブインターフェース、データテーブル API、または YARA-L 2.0 の概要クエリを使用して、Google SecOps アカウントにデータテーブルを作成またはインポートできます。

データ RBAC を使用してデータテーブルにスコープを割り当てる

データテーブルを使用するには、データロールベースアクセス制御（データ RBAC）を使用して、データテーブルにスコープを割り当てる必要があります。データテーブルにスコープを割り当てることで、どのユーザーとリソースがデータテーブルにアクセスして利用できるかを制御できます。詳細については、データテーブルのデータ RBAC を構成するをご覧ください。

Google SecOps ウェブインターフェースを使用してデータテーブルを管理する

以降のセクションでは、ウェブインターフェースを使用してデータテーブルにアクセスする方法、新しいデータテーブルを追加して内容を編集する方法、行を追加する方法、アカウントからデータテーブルを削除する方法など、データテーブルを管理する方法について説明します。

データテーブルにアクセスする

[データテーブル] ページにアクセスするには、次の操作を行います。

サイドバーで、[調査] > [データテーブル] を選択します。

特定のデータテーブルを検索するには、[データテーブル] サイドバーの上部にある [検索] フィールドに名前を入力します。

新しいデータテーブルを追加する

新しいデータテーブルを追加する際に、CSV データを手動で入力したり、CSV データを貼り付けたり、CSV ファイルまたは TSV ファイルをデータテーブルにインポートしたりできます。

次の構成は永続的であり、新しいデータテーブルの保存後に変更することはできません。

列ヘッダー
データマッピング
主キー
繰り返しフィールド
列名とエンティティフィールドのマッピング

Google SecOps に新しいデータテーブルを追加する手順は次のとおりです。

サイドバーで、[調査] > [データテーブル] を選択します。
[データテーブル] サイドバーの上部にある [作成] をクリックします。
[新しいデータテーブルを作成] ダイアログで、テーブルに名前を付け、必要に応じて説明を追加します。
次のいずれかを行います。
- CSV データを手動で入力するか、[テキスト]（編集モード）領域に CSV データを貼り付けます。
- CSV ファイルまたは TSV ファイルからデータテーブルにデータをインポートするには、次の操作を行います。
1. [ファイルのインポート] をクリックします。
2. ファイルに移動して [開く] をクリックします。[ファイルをインポート] ダイアログが開きます。
3. 前の手順で TSV ファイルを選択した場合は、次の操作を行います。
  1. [区切り文字の種類] リストから [自動検出] または [タブ] を選択します。
  2. [次の行でインポートを開始] リストで、データのインポート元となるファイルの行を指定します。
4. [データをインポート] をクリックします。
[表] 編集モードを選択し、必要に応じて次のように構成します。
[保存] をクリックします。新しいデータテーブルが [データテーブル] サイドバーに表示され、追加のデータを受け入れる準備が整います。

データ型をデータテーブルの列にマッピングする

新しいデータテーブルを追加するときに、データ型（文字列、正規表現、CIDR、数値）をデータテーブルの列にマッピングできます。

次のとおりウェブインターフェースまたは API を使用して、単一のデータフィールドを 1 つのデータ列にマッピングし、同じデータフィールドを繰り返し 1 つのデータ列にマッピングできます。

ウェブインターフェースと API の両方で、データフィールドの値をパイプ（|）で区切ります。ウェブインターフェースでは、値にパイプ（|）が含まれている場合、デフォルトで繰り返し値として扱われます。
API リクエストの場合は、repeated_values を true に設定します。

詳細については、繰り返しフィールドをご覧ください。

次の例では、データテーブルの列 Field_value に複数のフィールドの値が含まれています。

Field_value	Field_name
altostrat.com	FQDN
192.0.2.135	IP
charlie	userid
example	hostname

上のテーブルは 4 つの列に分割されており、各列をこのドキュメントで説明するデータテーブルのユースケースで使用するには、1 つのフィールドタイプにのみマッピングします。

FQDN	IP	Userid	Hostname
altostrat.com	192.0.2.135	charlie	example
…	…	…	…

キー列を指定する

新しいデータテーブルを追加するときに、特定の列をキー列として指定できます。

列をキー列としてマークすると、その列の値が一意に識別され、データの重複防止や、ルールと検索のためのデータ検出の改善につながります。

繰り返しフィールドに対応する列を指定する

新しいデータテーブルを追加する際に、繰り返しフィールドに対応する特定の列を指定できます。

複数値フィールドまたは繰り返しフィールドを格納する列は、データテーブルの作成時に明示的に repeated として指定する必要があります。

列名をエンティティフィールドにマッピングする（省略可）

新しいデータテーブルを追加するときに、データテーブルの列名をエンティティフィールドにマッピングできます。

次のサンプルデータテーブルでは、Userid 列と Role 列がそれぞれ entity.user.userid と entity.user.attribute.role.name にマッピングされています。

Userid （entity.user.userid にマッピング）	Email	Role （entity.user.attribute.role.name にマッピング）
jack	jack123@gmail.com	administrator
tony	tony123@gmail.com	engineer

DataTable リソースの mapped_column_path フィールドを使用して、データテーブルの列をエンティティ proto フィールドにマッピングできます。

この例のテーブルの Email など、エンティティパスが定義されていない列については、データ型を手動で指定する必要があります。参照リストと同様に、データテーブルで対応しているデータ型は number、string、regex、cidr です。

join 条件を指定することで、マッピングされた列とマッピングされていない列の両方をデータテーブルに含めることができます。

マッピングされていない列は、テーブルの結合先であるエンティティの additional フィールドに保存されます。これらは Key-Value ペアとして追加されます。ここで、key は列名、value は対応する行の値です。

データテーブルに新しい行を追加する

新しい行を追加する手順は次のとおりです。

[詳細] タブで、[テーブル] 編集モードを選択します。
既存の行を右クリックして、[Add row above] を選択します。
新しい行のデータを入力します。最初の行はテーブルヘッダーとして扱われます。各データ項目を適切なデータ列とデータ型に一致させてください。
[保存] をクリックします。

データテーブルの行を編集する

行を編集する手順は次のとおりです。

変更するフィールドをクリックします。フィールドが編集可能になります。
ファイルを変更すると、
[保存] をクリックします。

データテーブルの行を検索する

ウェブインターフェースを使用して、データテーブル内の特定の情報を検索できます。[詳細] タブで、検索フィールドに検索文字列を入力し、[検索] をクリックします。検索文字列を含む行が表示されます。

テーブル行の TTL を管理する

テーブル行の有効期間（TTL）値を管理する手順は次のとおりです。

[TTL を列ごとに表示] をクリックします。TTL 列が表示され、各行が期限切れかどうかを示します。有効期限が切れていない場合は、有効期限までの残り時間が表示されます。
[デフォルトの行の有効期限] をクリックして [デフォルトの行の有効期限を更新する] ダイアログを表示し、テーブル行の TTL を調整します。
[時間] または [日] に新しい TTL 値を入力します。最小値は 24 時間です。最大値は 365 日です。
[保存] をクリックします。

テーブルの行を削除する

行を削除するには、行を右クリックして [行を削除] を選択します。

複数の行を削除するには、削除する各行を選択します。次に、選択した行のいずれかを右クリックして、行を削除] を選択します。

データテーブルを削除する

データテーブルを削除する手順は次のとおりです。

サイドバーの [データテーブル] リストからデータ表を選択します。
[削除] をクリックします。

Chronicle API を使用してデータテーブルを管理する

Chronicle API で使用可能な REST リソースを使用して、Google SecOps のデータテーブルを管理することもできます。この API は、ウェブインターフェースで使用できるすべての機能を複製できます。また、データテーブルをより高いパフォーマンスとより大きなスケールで管理できる追加機能も含まれています。

データテーブルの REST リソースは次のとおりです。

例: フィルタ構文

次の Chronicle API の例は、filter 構文を使用してデータテーブルの行で google.com を検索する方法を示しています。

curl -X GET \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  "https://staging-chronicle.sandbox.googleapis.com/v1alpha/projects/{$PROJECT}/locations/${REGION}/instances/${INSTANCE}/dataTables/${DATA_TABLE_NAME}/dataTableRows?filter=google.com"

Google SecOps でデータテーブルを使用する

データテーブルを Google SecOps インスタンスに追加すると、YARA-L クエリを使用してデータテーブルをフィルタリング、強化、拡充できます。このドキュメントには、Google SecOps に組み込むことができる YARA-L 構文の例が多数含まれています。

データテーブルは、検索とルールの両方で YARA-L クエリと組み合わせて使用できます。

データテーブルの使用方法は次のとおりです。

データテーブルを使用して UDM イベントデータまたは UDM エンティティデータをフィルタする

データテーブルのエントリと比較することで、UDM テレメトリーイベントと UDM エンティティをフィルタできます。
データテーブルを複数列の参照リストとして使用する

データテーブルを複数列の参照リストとして使用できます。参照リストは 1 つのディメンションのデータにアクセスできますが、データテーブルでは複数のディメンションのデータにアクセスして、データをフィルタできます。
データテーブルをイベントまたはエンティティと結合する

行ベースの比較に等価（=）演算子を使用すると、UDM イベントをデータテーブルにリンクできます。この比較を使用すると、データをフィルタできます。行ベースの比較は、ステートメント内のすべての条件がデータテーブルの 1 つの行と一致する場合にのみ true と評価されます。

データテーブルを使用して UDM イベントデータと UDM エンティティデータをフィルタする

データテーブルのエントリと比較して、UDM イベントと UDM エンティティをフィルタできます。行ベースまたは列ベースの比較を使用して、データテーブルを UDM イベントまたは UDM エンティティに結合します。

データテーブルの行ベースと列ベースの比較

比較タイプ	キーロジック	一般的な演算子	構文の例	使用する状況
行ベース	すべての条件が同じ行で一致している必要があります	`=`、`!=`、`>`、`>=`、`<`、`<=`	`$e.field = %table.col_a`	同じ行にある複数の列値間の関係が重要である場合。
列ベース	値が列内のどこかに存在している必要がある	`IN`、`IN regex`、`IN cidr`	`$e.field IN %table.col_b`	単一の列の値のセット内に値が存在するかどうかを確認する場合。

行ベースまたは列ベースの比較方法を使用して、UDM イベントをデータテーブルにリンクします。

UDM イベントをデータテーブルにリンクする行ベースの比較

行ベースの比較を使用して UDM イベントをデータテーブルにリンクするには、等価演算子（=、!=、>、>=、<、<=）を使用します。

例: $<udm_variable>.<field_path> = %<data_table_name>.<column_name>
- 複数の比較ステートメントを使用している場合、すべてのフィールドまたは条件が同じデータテーブルの行と一致する必要があります。
- クエリで演算子（not、!=、>、>=、<、<= など）を使用するには、UDM フィールドとデータテーブルの行との間に条件 join を 1 つ以上含める必要があります。
- Google SecOps は、データテーブル join を含むルールをマルチイベントルールとして扱います。そのため、ルール定義に match セクションが必要です。
UDM イベントの値とデータテーブルの行を照合してデータをフィルタするには、次の結合構文を検討してください。
- 正しい結合構文:
  
  行ベースの「組み合わせ除外」では、たとえば、left outer 結合と nulls をチェックする where 句が必要です。
- 結合構文が正しくありません:
  
  複数の行ベースの等価条件を NOT でラップしないでください。この構文では、「この組み合わせが見つかった場合は除外する」という効果は得られません。
  
  たとえば、NOT (field1 = %table.col1 AND field2 = %table.col2) のような構文は使用しないでください。
  
  これは、一致が引き続き行ごとに適用されるためです。いずれかの行が内部の複合条件を満たさない場合、NOT によってその行の評価が true になり、イベントが除外されずに含まれる可能性があります。

行ベースの比較に CIDR 型または regex 型のデータテーブル列を使用するには、次の構文を使用します。

net.ip_in_range_cidr($e.principal.ip, %<data_table_name>.<column_name>)

  re.regex($e.principal.hostname, %<data_table_name>.<column_name>)

UDM イベントをデータテーブルにリンクする列ベースの比較

列ベースの比較を使用して UDM イベントをデータテーブルにリンクするには、in キーワードを使用します。

例: $<udm_variable>.<field_path> in %<data_table_name>.<column_name>
フィールド値が指定された列（ブロックリストや許可リストなど）に存在するイベントをフィルタで除外するには、NOT (... IN %table.column) 構文を使用します。

例: not ($evt_username in %my_data_table.username)
列ベースの比較に CIDR 型または regex 型のデータテーブル列を使用するには、次の構文を使用します。
```
$e.principal.ip in cidr %cidr_data_table.column_name

$e.principal.hostname in regex %regex_data_table.column_name
```
データ型が CIDR または正規表現であるデータテーブルの列を比較する場合、キーワード cidr とキーワード regex は省略可能です。
演算子 not はデータテーブルでも使用できます。

次のクエリの例では、IP アドレス（$e.principal.ip）が cidr_data_table の benign_ip 列にリストされている CIDR 範囲のいずれにも一致しないエントリを除外します。
```
not $e.principal.ip in %data_table.benign_ip
```

データテーブルを複数列の参照リストとして使用する

データテーブルを複数列の参照リストとして使用できます。参照リストは 1 つのディメンション（1 つの列）のデータにアクセスできますが、データテーブルは複数の列に対応しているため、複数のディメンションにわたってデータをフィルタしてアクセスできます。

列ベースの比較にキーワード in を使用して UDM イベントをデータテーブルにリンクすると、特定の UDM フィールドの値をデータテーブルの単一の列の値と照合できます。

次の例では、badApps データテーブルに hostname と ip の 2 つの列が含まれています。クエリは、両方の値（UDM フィールドに基づく値とデータテーブルに基づく値。どちらも文字列データ型）を個別に照合します。

ルールの例:

rule udm_in_data_table {
meta:
  description = "Use data table as multicolumn reference list"
events:
  $e.metadata.event_type = "NETWORK_CONNECTION"
  $e.security_result.action = "ALLOW"
  $e.target.asset.asset_id = $assetid

  // Event hostname matches at least one value in table column hostname.
  $e.target.hostname in %badApps.hostname

  // Event IP matches at least one value in table column ip.
  $e.target.ip in %badApps.ip

match:
  $assetid over 1h

condition:
  $e
}

検索の例:

events:
  $e.metadata.event_type = "NETWORK_CONNECTION"
  $e.security_result.action = "ALLOW"
  $e.target.asset.asset_id = $assetid

  // Event hostname matches at least one value in table column hostname.
  $e.target.hostname in %badApps.hostname

  // Event IP matches at least one value in table column ip.
  $e.target.ip in %badApps.ip

データテーブルと UDM イベントまたは UDM エンティティ間の行ベースの結合

等価演算子と比較演算子（=, !=, >, >=, <, <=）を使用して UDM イベントをデータテーブルにリンクし、行ベースの比較を行うことができます。このアプローチでは、UDM イベントの値とデータテーブルの行を照合して、データをフィルタできます。複数の比較ステートメントを使用している場合、すべてのフィールドまたは条件が同じデータテーブルの行と一致する必要があります。

クエリで演算子（not, !=, >, >=, <, <= など）を使用するには、UDM フィールドとデータテーブルの行との間に条件 join を 1 つ以上含める必要があります。Google SecOps は、データテーブル join を含むルールをマルチイベントルールとして扱います。そのため、対応する match セクションをルール定義に含める必要があります。

結合が行われると、リンクされたデータテーブルの行が検索に表示されます。詳細については、検索でデータテーブルの行を表示するをご覧ください。

クエリの event セクションのデータテーブルではプレースホルダに対応していますが、プレースホルダは UDM イベントまたは UDM エンティティに接続する必要があります。

次の例では、string 型のデータテーブル列を使用しています。
- この YARA-L クエリの例では、ユーザーログインイベントが example_table の行と一致するかどうかをチェックします。
- 1 つの条件は、user ID が example_table に存在することです。
- ルールをトリガーするには、両方の条件が example_table の同じ行で一致する必要があります。

// Check if a user exists in a data table and that the user is active for all user login events.

ルールの例:

// Check if user exists in a data table and is active in all user login events.
rule udm_join_data_table {

meta:
  description = "Join data table with UDM event"

events:
  $e.metadata.event_type = "USER_LOGIN"
  $e.security_result.action = "ALLOW"
  $e.principal.user.userid = $userid

// Event must match at least 1 row in the data table 
// where the uid in the data table row is the userid on the event 
// and the active date in the same data table row is before the event timestamp.
%example_table.uid = $userid
$e.principal.hostname = %example_table.hostname

match:
  $userid over 1h

condition:
  $e
}

検索の例:

events:
$e.metadata.event_type = "USER_LOGIN"
$e.security_result.action = "ALLOW"
$e.principal.user.userid = $userid

// Event must match at least 1 row in the data table 
// where the uid in the data table row is the userid on the event 
// and the active date in the same data table row is before the event timestamp

%example_table.uid = $userid
$e.principal.hostname = %example_table.hostname

次の例は、データテーブルと UDM イベントデータがどのように連携するかを示しています。

上記の YARA-L クエリのロジックに基づき、user ID 32452 を持つユーザーは、システムからのユーザーの hostname として検出に表示され、データテーブル内の hostname と一致します。

データテーブル
uid	title	hostname
32452	HR	host1
64452	ファイナンス	host2
46364	IT	host3

UDM イベントテーブル
principal	metadata	security_result	principal
32452	USER_LOGIN	許可	host1
64589	USER_LOGIN	許可	host9
87352	USER_LOGIN	許可	host4

YARA-L クエリの結果をデータテーブルに書き込む

YARA-L クエリの結果をデータテーブルに書き込むことができます。この機能を使用すると、Google SecOps データからデータテーブルを作成し、そのテーブルを使用して他のデータをフィルタリングして強化できます。

YARA-L クエリの書き込み構文は、次の目的で使用できます。

データテーブルにクエリ結果を書き込むための YARA-L 構文を定義する。
脅威インテリジェンス、インシデント対応、その他のセキュリティユースケースにデータテーブルを使用する。
データは YARA-L の構文と規則に準拠している必要がある。

YARA-L を使用して検出結果とアラートをデータテーブルに書き込む

YARA-L クエリを使用して、検出結果とアラートをデータテーブルに送信できます。

write_row 関数を使用すると、ルールから取得した結果を使用して、データテーブルの行をデータテーブル内の対応するキーで上書きできます。キーがテーブルに見つからない場合は、代わりに新しい行を追加します。

YARA-L クエリの export セクションで write_row 関数を指定します。データテーブルへのデータの書き込みは、クエリの最終アクションである必要があります。これにより、結果変数がデータテーブルに書き込まれます。

export:
  %<data_table_name>.write_row(
  data_table_column_x_name: <value>,
  data_table_column_y_name: <value>,
  ...,
  ...,
  data_table_column_z_name: <value>
)
// depending on the key column(s), the rows will be updated for existing keys 
and appended for new keys

YARA-L を使用してデータテーブルを変更する

次の例は、YARA-L を使用してデータテーブルを変更する方法を示しています。

TableName: ip_user_domain_table（主キーのキー列は作成時に定義されます）

IP アドレス	employee_id*	domain
192.0.2.10	Dana	altostrat.com
192.0.2.20	Quinn	altostrat.com
192.0.2.30	Lee	cymbalgroup.com

* は主キーを示します。

次のクエリは、principal.ip、principal.user.employee_id、target.domain の一意の組み合わせを取得します。target.domain の普及率に基づいて結果をフィルタします。

events:
  $e.principal.ip = $principal_ip
  $e.principal.user.employee_id = $principal_user_employee_id
  $e.target.domain.name = $target_domain
  $e.target.domain.prevalence.day_count < 5

// To run this query as a rule, add Condition Section here 
// condition:$e

クエリ結果:

ip	empid	domain
192.0.2.10	Dana	altostrat.com
192.0.2.30	Lee	examplepetstore.com
192.0.2.20	Quinn	altostrat.com

例: write_row を使用してクエリ出力をデータテーブルに書き込む

ルールの例:

  rule udm_write_data_table {
  meta:
      description = "Writeto data table"
  events:
    $e.principal.user.employee_id = $principal_user_employee_id
    $e.target.domain.name = $target_domain
    $e.target.domain.prevalence.day_count < 5

  outcome:
    $hostname = $target_domain
    $principal_emp_id = $principal_user_employee_id
  
  condition:
    $e

  export:
    %ips_with_hostnames.write_row(
        employeeid:$principal_emp_id,
        hostname:$hostname
    )
  }

検索の例:

events:
  $e.principal.user.employee_id = $principal_user_employee_id
  $e.target.domain.name = $target_domain
  $e.target.domain.prevalence.day_count < 5

outcome:
  $hostname = $target_domain
  $principal_emp_id = $principal_user_employee_id

export:
  %ips_with_hostnames.write_row(
    employeeid:$principal_emp_id,
    hostname:$hostname
  )

例: write_row の理解

次の例では、user と ip が主キーとして使用されています。検出テーブルに保持される各検出結果により、クエリの export セクションで関数呼び出しが 1 回評価されます。

ルールの例:

  rule udm_write_data_table {
  meta:
    description = "Write data table"
  events:
    $e.metadata.event_type = "USER_LOGIN"
    all $e.security_result.action != "BLOCK"
    all $e.security_result.action != "UNKNOWN_ACTION"

    $user = $e.principal.user.userid
    $ip = $e.target.ip
    $ts = $e.metadata.event_timestamp.seconds

  match:
    $user, $ip over 1h

  outcome:
    $first_seen = min($ts)

  condition:
    $e

  export:
    %successful_logins.write_row(user:$user, ip:$ip)
  }

検索の例:

events:
  $e.metadata.event_type = "USER_LOGIN"
  all $e.security_result.action != "BLOCK"
  all $e.security_result.action != "UNKNOWN_ACTION"

  $ts = $e.metadata.event_timestamp.seconds

outcome:
  $user = $e.principal.user.userid
  $ip = $e.target.ip[0]

export:
  %successful_logins.write_row(user:$user, ip:$ip)

イベントデータは次のとおりです。

metadata: {
  event_type: USER_LOGIN
  event_timestamp: { seconds: 1283299200 }
}
principal: {
  user: {
    userid: "charlie"
  }
}
target: {
  ip: ["192.0.2.135", "192.0.2.136"]
}
security_result: {
  action: ALLOW
}

このクエリをルールとして実行すると、次の検出結果が返されます。

検出 ID $user に一致 $ip に一致

0 charlie 192.0.2.135

1 charlie 192.0.2.136

データテーブルには次の情報が含まれています。

ユーザー ip

charlie 192.0.2.135

charlie 192.0.2.136

次の検索クエリは、検索で提供されるデータテーブルへのスカラー値の書き込みへの対応を示しています。

注: ルールではこのような書き込みに対応していません。
```
events:
  $e.metadata.event_type = "NETWORK_CONNECTION"

export:
  %summary_table.write_row(col_name: $e.metadata.product_name, Vendor_name: $e.metadata.vendor_name)
```

データテーブルを使用してエンティティグラフを拡充する

データテーブルを使用すると、エンティティグラフに表示されるエンティティを追加、置換できるほか、ルールから削除できます。ルール setup セクションの関数を使用して、データテーブルを events セクションで参照されるエンティティイベントとどのように統合するか、そのようなエンティティイベントにどのように追加するか、またはそのようなエンティティイベントからエンティティを削除するのにどのように使用するかを指定します。

次のルールテンプレートを使用して、エンティティグラフを変更できます。

rule entity_graph_template {

  meta:
    ...

  setup:
    // import the data table into entity graph
    <enrichment_keyword> <join_condition>

  events:
    ...

  match:
    ...

  condition:
    ...
}

次の YARA-L 2.0 関数を使用して、データテーブルでエンティティグラフを強化できます。

graph_override: 結合条件に一致するエンティティグラフ内の行をデータテーブルのデータで上書きします。

例: [graph_override](?tab=t.0#heading=h.v0fps7eke1if)
graph_append: データテーブルの行をエンティティグラフの行に追加します。graph_append オペレーションでは、結合条件ではなく、データテーブル変数とエンティティイベント変数を含む配列が必要です。

次の例では、$g1 はエンティティグラフ変数、example_table はデータテーブルです。graph_append [$g1, %example_table]

append 関数では、エンティティを検証するために、データテーブルに次の列を含める必要があります。
- start_time（metadata.interval.start_time.seconds にマッピング）
- end_time（metadata.interval.end_time.seconds にマッピング）
ウェブインターフェースを使用して、データテーブルの列をメタデータフィールドにマッピングすることはできません。append のユースケースでは、Chronicle API（https://cloud.google.com/chronicle/docs/reference/rest/v1alpha/projects.locations.instances.dataTables/create）を使用してデータテーブルを作成する必要があります。
graph_exclude: join 条件に一致するエンティティグラフ内の行を削除します。

例: [graph_exclude](?tab=t.0#heading=h.o0qbb5paki6g)

結合条件は、データテーブルの列とエンティティグラフのフィールドとの間の等式表現である必要があります。graph_override 関数と graph_exclude 関数でデータテーブルにアクセスする構文は次のとおりです。

<data_table_name>.<column_name>

イベントセクションの <entity_variable> に指定されたフィルタはいずれも、データテーブルで拡張された後に適用されます。

エンティティグラフのエンティティがデータテーブルのエンティティで拡充されたら、エンティティグラフのエンティティ変数を UDM エンティティに結合する必要があります。

データテーブルのデータでエンティティグラフをオーバーライドする

graph_override 関数を使用すると、エンティティグラフとデータテーブルの両方に存在するフィールドが、データテーブルのフィールドに置き換えられます。エンティティグラフに存在し、データテーブルに存在しないフィールドは変更されません。エンティティグラフには存在しないが、データテーブルには存在するフィールドが含まれます。

マッピングされたデータテーブルの列のみが、エンティティグラフの列をオーバーライドします。マッピングされていない列は、データテーブルが結合されているエンティティグラフの additional フィールドに追加されます。

例: 単一結合で一致する

次の例では、データテーブルの列とエンティティグラフのフィールド（$g1.graph.entity.ip = %example_table.my_ip）の間の結合条件に一致するエンティティグラフの行が、データテーブルによってオーバーライドされます。

rule rule_override {
  meta:
    description = "Override entity context with data table before joining with UDM event"

  setup:
    //Rows in the entity graph that match the join condition are overridden by the data table
    graph_override ($g1.graph.entity.ip = %example_table.my_ip)

  events:
    $e.metadata.event_type = "NETWORK_CONNECTION"
    $e.security_result.action = "ALLOW"

    // Filter will be applied after graph is overridden by data table
    $g1.graph.entity.hostname = "ftp01"

    // Accessing unmapped columns
    $g1.graph.additional.fields["Owner"] = "alice"

    // Joining the UDM event with the enriched entity graph
    $e.target.ip = $iocip
    $g1.graph.entity.ip = $iocip

  match:
    $iocip over 1h

  condition:
    $e and $g1
}

データテーブルの未マッピングの列（「Owner」など）を使用するには、$g1.graph.entity.owner = "alice" is $g1.graph.additional.fields["Owner"] = "alice" の同等のステートメントを使用します。これは、データテーブルのマッピングされていないすべての列が、エンティティグラフ ($g1) の additional フィールドに格納されるためです。

次のテーブルは、データテーブルの IP フィールドがエンティティグラフの IP フィールドと一致する場合に、エンティティグラフの行が拡充されるオーバーライドオペレーションを示しています。

既存のエンティティグラフ
Hostname	IP	MAC
ftp01	10.1.1.4	…:01
www01	10.1.1.5	…:02

データテーブル
Hostname	IP	MAC	Owner
ftp01	10.1.1.4	…:bb	alice
h1	10.1.1.6	…:cc	bob
h2	10.1.1.7	…:dd	chris
h3	10.1.1.4	…:ee	doug

拡充されたエンティティグラフ
Hostname	IP	MAC	Owner
ftp01	10.1.1.4	…:bb	alice
www01	10.1.1.5	…:02
h3	10.1.1.4	…:ee	doug

例: 複数の結合で一致する

次の例では、複数の結合条件（$g1.graph.entity.ip = %example_table.my_ip と $g1.graph.entity.hostname = %example_table.my_hostname）に一致するエンティティグラフの行がデータテーブルによってオーバーライドされます。

rule rule_override {
meta:
    description = "Override Entity context with Data Table before joining with UDM event"
setup:
  // example with more than one condition
  graph_override ($g1.graph.entity.ip = %example_table.my_ip and
  $g1.graph.entity.hostname = %example_table.my_hostname) 
events:
  $e.metadata.event_type = "NETWORK_CONNECTION"
  $e.security_result.action = "ALLOW"

  // Filter will be applied after graph is overridden by data table
  $g1.graph.entity.hostname = "ftp01"

  // joining the UDM event with the enriched entity graph
  $e.target.ip = $iocip
  $g1.graph.entity.ip = $iocip

match:
  $iocip over 1h

condition:
  $e and $g1
}

次のテーブルは、データテーブルの IP フィールドと Hostname フィールドの両方がエンティティグラフの IP フィールドと Hostname フィールドに一致する場合に、エンティティグラフの行が拡充されるオーバーライドオペレーションを示しています。

既存のエンティティグラフ
Hostname	IP	MAC
ftp01	10.1.1.4	…:01
www01	10.1.1.5	…:02

データテーブル
Hostname	IP	MAC	Owner
ftp01	10.1.1.4	…:bb	alice
h1	10.1.1.5	…:cc	bob
h2	10.1.1.6	…:dd	chris
h3	10.1.1.4	…:ee	doug

拡充されたエンティティグラフ
Hostname	IP	MAC	Owner
ftp01	10.1.1.4	…:bb	alice
www01	10.1.1.5	…:02

データテーブルのデータをエンティティグラフに追加する

graph_append 関数では、結合条件は必要ありません。

次の例では、データテーブルのすべての行がエンティティグラフの行に追加されます。

rule rule_append {
meta:
  description = "Data table append entity"
   
setup:
  graph_append [$g1, %example_table]

events:
    // filter UDM events
  $e.metadata.event_type = "NETWORK_CONNECTION"
  $e.security_result.action = "ALLOW"

  // Join the filtered UDM events with the enriched graph
  $e.target.ip = $iocip
  $g1.graph.entity.ip = $iocip

match:
  $iocip over 1h

condition:
  $e and $g1
}

次の例のテーブルは、データテーブルの行がエンティティグラフの行に追加される追加オペレーションを示しています。

既存のエンティティグラフ
Hostname	IP	MAC
ftp01	10.1.1.4	…:01
www01	10.1.1.5	…:02

データテーブル
IP	MAC	Owner
10.1.1.4	…:01	alice
10.1.1.6	…:cc	bob
10.1.1.7	…:dd	chris
10.1.1.4	…:ee	doug

拡充されたエンティティグラフ
Hostname	IP	MAC	Owner
ftp01	10.1.1.4	…:01
www01	10.1.1.5	…:02
	10.1.1.4	…:bb	alice
	10.1.1.6	…:cc	bob
	10.1.1.7	…:dd	chris
	10.1.1.4	…:ee	doug

graph_exclude を使用してエンティティグラフから行を削除する

graph_exclude 関数を使用すると、結合条件に一致するエンティティグラフ内の行がエンティティグラフから削除されます。

次の例では、指定された結合条件（データテーブルの列とエンティティグラフのフィールドとの間）に一致するエンティティグラフ内のすべての行が削除されます。データテーブルの行はエンティティグラフに追加されません。

rule rule_exclude {

    meta:
    setup:
      graph_exclude ($g1.graph.entity.ip = %example_table.ip)

    events:
        $e.metadata.event_type = "NETWORK_CONNECTION"
        $e.security_result.action = "ALLOW"
        $e.target.ip = $iocip
        $g1.graph.entity.ip = $iocip

    match:
        $iocip over 1h

    condition:
        $e and $g1
}

次のテーブルは、データテーブルの IP フィールドと一致するエンティティグラフの行が削除される除外オペレーションを示しています。

既存のエンティティグラフ
Hostname	IP	MAC
ftp01	10.1.1.4	…:01
www01	10.1.1.5	…:02

データテーブル
IP	MAC	Owner
10.1.1.4	…:bb	alice
10.1.1.6	…:cc	bob
10.1.1.7	…:dd	chris

拡充されたエンティティグラフ
Hostname	IP	MAC
www01	10.1.1.5	…:02

制限事項

Google SecOps アカウントのデータテーブルの最大数: 1,000。
データテーブルでサポートされているのは CSV データのみです。データテーブルでタブ区切り値がサポートされるのは、新しいデータテーブルを追加するときと、タブ区切り値（TSV）ファイルをインポートするときのみです。
データテーブルのフィールドは、カンマ（,）に対応していません。
クエリで参照リストを参照する場合の in ステートメントの数に関する上限は、データテーブルの in ステートメントにも適用されます。
String データ型と Number データ型の列のクエリ内の in ステートメントの最大数: 7。
正規表現演算子を含む in ステートメントの最大数: 4。
CIDR 演算子を含む in ステートメントの最大数: 2。
データテーブルあたりの最大列数: 1,000。
データテーブルあたりの最大行数: 1,000 万。
アカウント内のデータテーブル全体のデータ容量の最大合計制限: 1 TB。
テキストエディタビューとテーブルエディタビューでデータテーブルの行をウェブページに表示する際の最大行数: 10,000 行。
データテーブルの作成時の最大ファイルアップロードサイズの上限: 10 GB。
設定セクションではプレースホルダを使用できません。
データ型が string に設定されているデータテーブルの未マッピングの列は、UDM イベントまたは UDM エンティティの文字列フィールドとのみ結合できます。
データ型が CIDR または正規表現の cidr または regex に設定されているデータテーブルで、マッピングされていない列のみを使用します。
データテーブルのルックアップ: 正規表現のワイルドカードには対応していません。検索語句は 100 文字までに制限されています。

ルール内のデータテーブル結合の制限事項

ルール内のデータテーブル結合には、次の制限が適用されます。

イベントでデータテーブル結合を使用している場合、検出結果のすべてのイベントサンプルを取得することはできません。
エンティティや UDM とは異なり、データテーブルはプレースホルダに対応していません。これにより、次の制限が生じます。
- 1 つのフィルタセットをデータテーブルに適用し、UDM エンティティと結合することはできません。
- 同じデータテーブルに別のフィルタセットを適用しながら、別の UDM プレースホルダと結合することはできません。
たとえば、my_hostname、org、my_email の 3 つの列を持つ dt という名前のデータテーブルと、次のルールがあるとします。
```
events:
  $e1.principal.hostname =  %dt.my_hostname
  %dt.org ="hr"

  $e2.principal.email =  %dt.my_email
  %dt.org !="hr"
```

データテーブルのすべてのフィルタが最初に適用され、次にデータテーブルのフィルタされた行が UDM と結合されます。この場合、dt テーブルの矛盾するフィルタ（%dt.org ="hr" and %dt.org !="hr"）により、空のデータテーブルが生成され、そのテーブルが e1 と e2 の両方に結合されます。

ルールでデータテーブルを使用する場合の制限事項

ルールで使用する場合、データテーブルには次の制限事項が適用されます。

実行頻度に関する制限事項

データテーブルを含むルールでは、リアルタイム実行の頻度に対応していません。

データテーブルへの出力に関する制限事項

データテーブルの繰り返しフィールド列では、any 修飾子と all 修飾子に対応していません。
データテーブルの繰り返しフィールド列では、配列インデックス作成に対応していません。
結果変数はデータテーブルにのみエクスポートできます。イベントパスやデータテーブルの列を直接エクスポートすることはできません。
列リストには、データテーブルの主キー列を含める必要があります。
結果は最大 20 個まで設定できます。
データテーブルが存在しない場合は、指定された順序に従って、すべての列にデフォルトの string データ型を使用して新しいテーブルが作成されます。
一度にデータテーブルに書き込むことができるルールは 1 つだけです。別のルールがすでに書き込んでいるデータテーブルにルールが書き込もうとすると、ルールのコンパイルが失敗します。
プロデューサールールが、データテーブルのコンシューマールールが開始する前にそのデータテーブルに行を追加できる保証はありません。
単一のルールには、結果の行数に上限があります。結果と永続データ、データテーブルには最大 10,000 行の制限が適用されます。
行を更新すると、キー以外のすべての列の新しい値が古い値を置き換えます。新しい行の追加などの更新は、クエリで使用できるようになるまでに約 5 分かかります。

データテーブルからのエンティティ拡充に関する制限事項

1 つのエンティティグラフ変数に適用できる拡充オペレーションは 1 つだけです（override、append、exclude のいずれか）。
各拡充オペレーションで使用できるデータテーブルは 1 つのみです。
YARA-L ルールの setup セクションでは、任意のタイプの拡充オペレーションを最大 2 つ定義できます。

次の例では、override オペレーションがエンティティグラフ変数 $g1 に適用され、append オペレーションがエンティティグラフ変数 $g2 に適用されます。

    setup:
    graph_override($g1.graph.entity.user.userid = %table1.myids)
    graph_append [$g2, %table1]

上記の例では、同じデータテーブル（table1）を使用して、異なるエンティティグラフを強化しています。次のように、異なるデータテーブルを使用して、さまざまなエンティティグラフを強化することもできます。

    setup:
    graph_override($g1.graph.entity.user.userid = %table1.myids)
    graph_append [$g2, %table2]

検索でデータテーブルを使用する場合の制限事項

検索で使用されるデータテーブルには、次の制限事項が適用されます。

Chronicle API を使用してデータテーブルで検索クエリを実行することはできません。クエリにはウェブインターフェースのみが対応しています。
1 回のクエリ実行でデータテーブルに出力できる行数は最大 100 万行、または 1 GB のいずれか先に達した方です。
検索結果をデータテーブルに出力する際、イベント行が 5 MB を超えるとスキップされます。
検索ではエンティティの拡充に対応していません。
顧客管理の暗号鍵（CMEK）のユーザーはデータテーブルに対応していません。
書き込みは、お客様 1 人につき 1 分あたり 6 回に制限されます。
検索関連のデータテーブルオペレーションでは API サポートを利用できません。
データテーブル結合では統計クエリに対応していません。
エンティティではなく UDM イベントでのみデータテーブルとデータテーブル結合に対応しています。

サポート対象: %datatable1.column1 = %datatable2.column1

サポート対象外: graph.entity.hostname = %sample.test
統計情報クエリの export セクションに match 変数を含めることはできません。

たとえば、以下はサポートされていません。
```
  match:
      principal.hostname
  export:
      %sample.write_row(
      row: principal.hostname
    )
```

さらにサポートが必要な場合 コミュニティメンバーや Google SecOps のプロフェッショナルから回答を得ることができます。

検出 ID	$user に一致	$ip に一致
0	charlie	192.0.2.135
1	charlie	192.0.2.136

データテーブルを使用する

データ RBAC を使用してデータテーブルにスコープを割り当てる

Google SecOps ウェブ インターフェースを使用してデータテーブルを管理する

データテーブルにアクセスする

新しいデータテーブルを追加する

データ型をデータテーブルの列にマッピングする

キー列を指定する

繰り返しフィールドに対応する列を指定する

列名をエンティティ フィールドにマッピングする（省略可）

データテーブルに新しい行を追加する

データテーブルの行を編集する

データテーブルの行を検索する

テーブル行の TTL を管理する

テーブルの行を削除する

データテーブルを削除する

Chronicle API を使用してデータテーブルを管理する

例: フィルタ構文

Google SecOps でデータテーブルを使用する

データテーブルを使用して UDM イベントデータと UDM エンティティ データをフィルタする

データテーブルの行ベースと列ベースの比較

UDM イベントをデータテーブルにリンクする行ベースの比較

UDM イベントをデータテーブルにリンクする列ベースの比較

データテーブルを複数列の参照リストとして使用する

データテーブルと UDM イベントまたは UDM エンティティ間の行ベースの結合

YARA-L クエリの結果をデータテーブルに書き込む

YARA-L を使用して検出結果とアラートをデータテーブルに書き込む

YARA-L を使用してデータテーブルを変更する

例: write_row を使用してクエリ出力をデータテーブルに書き込む

例: write_row の理解

データテーブルを使用してエンティティ グラフを拡充する

データテーブルのデータでエンティティ グラフをオーバーライドする

例: 単一結合で一致する

例: 複数の結合で一致する

データテーブルのデータをエンティティ グラフに追加する

graph_exclude を使用してエンティティ グラフから行を削除する

制限事項

ルール内のデータテーブル結合の制限事項

ルールでデータテーブルを使用する場合の制限事項

実行頻度に関する制限事項

データテーブルへの出力に関する制限事項

データテーブルからのエンティティ拡充に関する制限事項

検索でデータテーブルを使用する場合の制限事項

Google SecOps ウェブインターフェースを使用してデータテーブルを管理する

列名をエンティティフィールドにマッピングする（省略可）

データテーブルを使用して UDM イベントデータと UDM エンティティデータをフィルタする

データテーブルを使用してエンティティグラフを拡充する

データテーブルのデータでエンティティグラフをオーバーライドする

データテーブルのデータをエンティティグラフに追加する

graph_exclude を使用してエンティティグラフから行を削除する