Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

マルチステージクエリを作成する

以下でサポートされています。

Google SecOps SIEM

このドキュメントでは、YARA-L のマルチステージクエリを使用して、あるクエリステージの出力を次のステージの入力に直接フィードする方法について説明します。このプロセスでは、単一のモノリシッククエリよりもデータ変換を細かく制御できます。

マルチステージクエリを既存の機能と統合する

マルチステージクエリは、Google Security Operations の次の既存の機能と連携して動作します。

複合検出ルール: 複数ステージのクエリは、自動検出とアクティブな調査のギャップを埋めることで、複合検出ルールを補完します。複合ルールは、長期間にわたる複雑なマルチイベントの相関関係を特定するのに優れていますが、マルチステージクエリを使用すると、アナリストはこれらの検出結果からリアルタイムの反復検索にピボットして、展開中の脅威を即座に検証し、範囲を特定できます。
期間とマルチイベントルール: マルチステージクエリを使用して、データ内の異なる期間を比較することで異常を検出できます。たとえば、最初のクエリを使用して長期間にわたるベースラインを確立し、後続のクエリを使用して、そのベースラインに対する最近のアクティビティを評価できます。マルチイベントルールを使用して、同様の比較を作成することもできます。

YARA-L のマルチステージクエリは、ダッシュボードと検索の両方でサポートされています。

結合は、複数のソースのデータを関連付けて、調査のコンテキストをより詳細に把握するのに役立ちます。関連するイベント、エンティティ、その他のデータをリンクすることで、複雑な攻撃シナリオを調査できます。詳細については、検索で結合を使用するをご覧ください。

考慮すべきポイント

マルチステージクエリを構成する際は、次の点に注意してください。

制限ステージ: マルチステージクエリには、ルートステージに加えて、1 ～ 4 個の名前付きステージを含める必要があります。
順序構文: 名前付きステージの構文を定義する前に、必ずルートステージの構文を定義します。

マルチステージクエリを実装する際は、次の既知の問題と推奨される回避策を確認することをおすすめします。

すべてのマルチステージクエリは、統計検索クエリのように動作します（出力は、集計されていないイベントやデータテーブルの行ではなく、集計された統計情報で構成されます）。
一方の側で UDM イベントとエンティティイベントを結合すると、データセットのサイズが原因でパフォーマンスが低下する可能性があります。結合の UDM イベントとエンティティイベントの側をできるだけフィルタすること（イベントタイプでフィルタするなど）を強くおすすめします。

推奨されるプラクティスに関する一般的なガイダンスについては、YARA-L 2.0 のベストプラクティスをご覧ください。結合に固有の情報については、ベストプラクティスをご覧ください。

主な用語

結合のコンテキストでは、ウィンドウ化されたステージは、ウィンドウを含む match セクションがあるステージを指します。一方、テーブルステージはウィンドウを出力しません。

マルチステージ YARA-L クエリを作成する

マルチステージ YARA-L クエリを作成するには、次の操作を行います。

ステージの構造と構文

[調査] > [検索] に移動します。クエリステージを定義するときは、次の構造に従ってください。

構文: 次の構文を使用して、各ステージに名前を付け、他のステージと区別します。

stage <stage name> { }

中括弧: ステージ構文はすべて中括弧 {} の内側に配置します。
順序: ルートステージを定義する前に、名前付きステージの構文をすべて定義します。
参照: 各ステージは、クエリで前に定義されたステージを参照できます。
ルートステージ: クエリにはルートステージが必要です。ルートステージは、すべての名前付きステージの後に処理されます。

次の例のステージ daily_stats は、毎日のネットワーク統計情報を収集します。

stage daily_stats {
  metadata.event_type = "NETWORK_CONNECTION"
  $source = principal.hostname
  $target = target.ip
  $source != ""
  $target != ""
  match:
    $source, $target by day
  outcome:
    $exchanged_bytes = sum(network.sent_bytes + network.received_bytes)
}

ステージの出力にアクセスする

名前付きステージの出力は、ステージフィールドを使用して後続のステージからアクセスできます。ステージフィールドは、ステージの match 変数と outcome 変数に対応しており、統合データモデル（UDM）フィールドと同様に使用できます。

ステージフィールドにアクセスするには、次の構文を使用します。

$<stage name>.<variable name>

省略可: アクセスウィンドウのタイムスタンプ

名前付きステージでホップウィンドウ、スライディングウィンドウ、タンブリングウィンドウを使用する場合は、次の予約済みフィールドを使用して、各出力行のウィンドウの開始とウィンドウの終了にアクセスします。

$<stage name>.window_start
$<stage name>.window_end

window_start と window_end は、Unix エポックからの経過秒数で表される整数フィールドです。さまざまなステージのウィンドウのサイズは異なる場合があります。

マルチステージクエリの例

このセクションの例は、完全なマルチステージ YARA-L クエリを作成する方法を説明するのに役立ちます。

例: 異常にアクティブなネットワーク接続を検索する（時間）

このマルチステージ YARA-L の例では、ネットワークアクティビティが通常よりも高い IP アドレスのペアを特定し、3 時間以上高いアクティビティを維持しているペアをターゲットにします。クエリには、名前付きステージ hourly_stats と root ステージの 2 つの必須コンポーネントが含まれています。

hourly_stats ステージでは、ネットワークアクティビティのレベルが高い principal.ip と target.ip のペアを検索します。

このステージでは、次のフィールドの 1 時間ごとの値が 1 つ返されます。

送信元 IP の統計情報（文字列）: $hourly_stats.src_ip
宛先 IP の統計情報（文字列）: $hourly_stats.dst_ip
イベント数の統計情報（整数）: $hourly_stats.count
受信バイトの標準偏差（浮動小数点数）: $hourly_stats.std_recd_bytes
平均受信バイト数（浮動小数点数）: $hourly_stats.avg_recd_bytes
Unix エポックからの秒単位の 1 時間バケットの開始時刻（整数）: $hourly_stats.window_start
Unix エポックからの時間バケットの終了時刻（秒単位）（整数）: $hourly_stats.window_end

ルートステージは hourly_stats ステージの出力を処理します。$hourly_stats で指定されたしきい値を超えるアクティビティを含む principal.ip と target.ip のペアの統計情報を計算します。次に、アクティビティの高い時間が 3 時間を超えるペアをフィルタします。


stage hourly_stats {
  metadata.event_type = "NETWORK_CONNECTION"
  $src_ip = principal.ip
  $dst_ip = target.ip
  $src_ip != ""
  $dst_ip != ""

  match:
    $src_ip, $dst_ip by hour

  outcome:
    $count = count(metadata.id)
    $avg_recd_bytes = avg(network.received_bytes)
    $std_recd_bytes = stddev(network.received_bytes)

  condition:
    $avg_recd_bytes > 100 and $std_recd_bytes > 50
}

$src_ip = $hourly_stats.src_ip
$dst_ip = $hourly_stats.dst_ip
$time_bucket_count = strings.concat(timestamp.get_timestamp($hourly_stats.window_start), "|", $hourly_stats.count)

match:
 $src_ip, $dst_ip

outcome:
 $list = array_distinct($time_bucket_count)
 $count = count_distinct($hourly_stats.window_start)

condition:
 $count > 3

ルートステージで一致条件を次のように変更すると、マルチステージクエリに日単位のウィンドウ集計を導入できます。

match:
 $src_ip, $dst_ip by day

例: 異常にアクティブなネットワーク接続を検索する（Z スコアを使用）

このマルチステージクエリは、Z スコア計算（平均からの標準偏差の数を測定）を使用して、1 日あたりの平均ネットワークアクティビティと今日のアクティビティを比較します。このクエリは、内部アセットと外部システム間の異常に高いネットワークアクティビティを効果的に検索します。

前提条件: 計算された Z スコアを有効にするには、クエリの時間枠が 2 日以上で、当日を含んでいる必要があります。

このマルチステージクエリには、daily_stats ステージと root ステージが含まれています。これらは連携して、ネットワークアクティビティの Z スコアを計算します。

daily_stats ステージは、最初の日次集計を実行します。各 IP ペア（source と target）について、1 日あたりに交換された合計バイト数を計算し、次のステージフィールド（出力行の列に対応）を返します。
- $daily_stats.source: 単数、文字列
- $daily_stats.target: 単数、文字列
- $daily_stats.exchanged_bytes: 単数、整数
- $daily_stats.window_start: 単数、整数
- $daily_stats.window_end: 単数、整数
ルートステージは、各 IP ペアの daily_stats ステージの出力を集計します。検索範囲全体の 1 日あたりの交換バイト数の平均と標準偏差、および今日の交換バイト数を計算します。これらの 3 つの計算値を使用して Z スコアを決定します。
出力には、今日すべての IP ペアの Z スコアが降順で表示されます。

// Calculate the total bytes exchanged per day by source and target

stage daily_stats {
  metadata.event_type = "NETWORK_CONNECTION"
  $source = principal.hostname
  $target = target.ip
  $source != ""
  $target != ""

  match:
    $source, $target by day

  outcome:
    $exchanged_bytes = sum(network.sent_bytes + network.received_bytes)
}

// Calculate the average per day over the time window and compare with the bytes exchanged today

$source = $daily_stats.source
$target = $daily_stats.target
$date = timestamp.get_date($daily_stats.window_start)

match:
  $source, $target

outcome:
  $today_bytes = sum(if($date = timestamp.get_date(timestamp.current_seconds()), cast.as_int($daily_stats.exchanged_bytes), 0))
  $average_bytes = window.avg($daily_stats.exchanged_bytes)
  $stddev_bytes = window.stddev($daily_stats.exchanged_bytes)
  $zscore = ($today_bytes - $average_bytes) / $stddev_bytes

order:
  $zscore desc

ステージから集計されていない変数をエクスポートする

一般的なマルチステージクエリでは、集計プロセスを通じてステージ間でデータが渡されることがよくあります。これにより、複数のイベントが 1 つの概要にまとめられることがあります。ただし、粒度を失うことなく、一意のプロセス ID や特定のコマンドラインなど、すべてのイベントの特定の詳細を保持する必要があるシナリオもあります。これをサポートするために、グループ化関数なしで変数を直接エクスポートできます。

名前付きステージには、集計されていない outcome セクションを含めることができます。つまり、その outcome セクション内で定義された変数はステージから直接出力され、後続のステージはグループ化された集計を必要とせずに、ステージフィールドとしてアクセスできます。

この詳細情報は、次の点で役立ちます。

データの忠実性を維持する: max() や array_distinct() などの人工的な「プレースホルダ」集計を使用せずに、イベントの正確な属性（特定のファイルパスなど）を次のステージに渡すことができます。
クエリの複雑さを軽減する: ステージ 1 からステージ 2 に値を転送するためだけに match セクションやグループ化ステートメントを必要としないため、YARA-L ロジックが簡素化されます。
パフォーマンスを最適化する: 集計エンジンをバイパスすることで、システムはステージ間でデータをより効率的にストリーミングできるようになり、複雑で大容量の検索の実行時間を短縮できます。

例: 集計されていない変数をエクスポートする

この例では、集計されていない変数をエクスポートする方法を示します。次のロジックに注意してください。

top_5_bytes_sent ステージは、ネットワークアクティビティが最も高い 5 つのイベントを検索します。
top_5_bytes_sent ステージは、出力行の列に対応する次のステージフィールドを出力します。
- $top_5_bytes_sent.bytes_sent: 単数、整数
- $top_5_bytes_sent.timestamp_seconds: 単数、整数
root ステージは、ネットワークアクティビティが最も高い 5 つのイベントの最新のタイムスタンプと最も早いタイムスタンプを計算します。

stage top_5_bytes_sent {
  metadata.event_type = "NETWORK_CONNECTION"
  network.sent_bytes > 0

  outcome:
    $bytes_sent = network.sent_bytes
    $timestamp_seconds = metadata.event_timestamp.seconds

  order:
    $bytes_sent desc

  limit:
    5
}

outcome:
  $latest_timestamp = timestamp.get_timestamp(max($top_5_bytes_sent.timestamp_seconds))
  $earliest_timestamp = timestamp.get_timestamp(min($top_5_bytes_sent.timestamp_seconds))

マルチステージクエリでウィンドウ処理を実装する

マルチステージ検出では、ウィンドウ処理により、ステージ内のイベントの関連付けに特定の時間境界を定義できます。データを 5 分間のスライディングウィンドウや 1 時間のタンブリングウィンドウなどの個別の時間バケットに分割することで、時間制限付きのシーケンスとして分析した場合にのみ検出できるブルートフォース攻撃やビーコン動作などのパターンを特定できます。

マルチステージクエリは、名前付きステージのすべてのタイプのウィンドウ処理（ホップ、スライディング、タンブリング）をサポートしています。これにより、ステージ間で時間コンテキスト化されたデータを渡すことができます。たとえば、ステージ 1 で高頻度のイベントウィンドウを特定し、ステージ 2 でその特定のウィンドウを後続の管理アクションと関連付けることができます。

名前付きステージにウィンドウが含まれている場合、各出力行のウィンドウの開始と終了には、次の予約済みフィールドを使用してアクセスできます。

$stage_window_start: ウィンドウの開始を示す Unix タイムスタンプ。
$stage_window_end: ウィンドウの終了を示す Unix タイムスタンプ。

ウィンドウ処理の詳細については、YARA-L 2.0 ウィンドウ処理ロジックをご覧ください。

一般的なユースケース

シーケンシャル検出: ログインの失敗が検出されたスパイクの特定の期間を、その直後に成功したログインを探す第 2 段階に渡します。
期間分析: 最初のエクスプロイトステージの $stage_window_start と、後のステージのイベントのタイムスタンプを比較して、「侵害までの時間」を計算します。
履歴ベースライン: ウィンドウを使用して、現在のイベント数を前のウィンドウの出力変数と比較します。

例: ホップウィンドウ

次の例は、マルチステージクエリでホップウィンドウを使用する方法を示しています。

hourly_stats ステージでは、同じ時間内にネットワークアクティビティが高い IP ペアを検索します。
hourly_stats は、出力行の列に対応する次のステージフィールドを出力します。
- $hourly_stats.src_ip: 単数、文字列
- $hourly_stats.dst_ip: 単数、文字列
- $hourly_stats.count: 単数、整数
- $hourly_stats.std_recd_bytes: 単数、浮動小数点数
- $hourly_stats.avg_recd_bytes: 単数、浮動小数点数
- $hourly_stats.window_start: 単数、整数
- $hourly_stats.window_end: 単数、整数
ルートステージでは、アクティビティが 3 時間以上高い IP ペアが除外されます。hourly_stats ステージでホップウィンドウが使用されているため、時間が重複している可能性があります。

stage hourly_stats {
  metadata.event_type = "NETWORK_CONNECTION"
  $src_ip = principal.ip
  $dst_ip = target.ip
  $src_ip != ""
  $dst_ip != ""

  match:
    $src_ip, $dst_ip over 1h

  outcome:
    $count = count(metadata.id)
    $avg_recd_bytes = avg(network.received_bytes)
    $std_recd_bytes = stddev(network.received_bytes)

  condition:
    $avg_recd_bytes > 100 and $std_recd_bytes > 50
}

$src_ip = $hourly_stats.src_ip
$dst_ip = $hourly_stats.dst_ip
$time_bucket_count = strings.concat(timestamp.get_timestamp($hourly_stats.window_start), "|", $hourly_stats.count)

match:
 $src_ip, $dst_ip

outcome:
 $list = array_distinct($time_bucket_count)
 $count = count_distinct($hourly_stats.window_start)

condition:
 $count > 3

マルチステージクエリの内部結合

内部結合を使用すると、さまざまなステージやソースタイプ間でデータを関連付けることができるため、リアルタイムイベントと事前に計算された統計ベースラインを比較するなど、複雑な分析ワークフローを作成できます。ステージを結合することで、ステートフルデータ（中央値やルックアップテーブルなど）で未加工のテレメトリーを拡充し、単一ステージのイベントフィルタでは見逃される外れ値やマルチベクトル脅威を特定できます。

内部結合は、マルチステージクエリのステージ内およびステージ間でサポートされています。内部結合機能は、次の型をサポートしています。

UDM と UDM: 2 つの異なるセキュリティイベントのセットを関連付けます（たとえば、ログインイベントと後続のファイルアクセスを照合します）。
UDM と ECG: イベントデータを Entity Context Graph 情報と統合して、ID またはアセットを拡充します。
UDM とデータテーブル: ライブイベントを静的またはアップロードされた参照リスト（価値の高いアセットのリストや部門固有の IP 範囲など）と結合します。

次の例は、UDM イベントと計算テーブルステージ間のマッチレス結合（match セクションではなく outcome セクションまたは events セクションで実行される結合）を構成する方法を示しています。このパターンを使用すると、次の平均絶対偏差（MAD）の計算に示すように、統計的異常検出を実行できます。

median ステージ: 各送信元ホストと宛先 IP のペアについて、送信されたバイト数の中央値を計算します。
- $median.host: 単数、文字列
- $median.target: 単数、文字列
- $median.median: 単数、浮動小数点数
absolute_deviations ステージ: 各 UDM イベントを、中央値ステージの対応する行と結合します。これにより、ピアグループに対する個々のイベントの送信バイト数の絶対偏差を計算できます。
- $absolute_deviations.host: 単数、文字列
- $absolute_deviations.target: 単数、文字列
- $absolute_deviations.absolute_deviation: 単数、浮動小数点数
ルートステージ: すべての UDM イベントの絶対偏差の平均を計算して、異常値のしきい値を設定します。

例: マッチしない結合を構成する

stage median {
  metadata.event_type = "NETWORK_CONNECTION"
  $host = principal.hostname
  $target = target.ip

  match:
    $host, $target

  outcome:
    $median = window.median(network.sent_bytes, true)
}

stage absolute_deviations {
  metadata.event_type = "NETWORK_CONNECTION"
  $join_host = principal.hostname
  $join_host = $median.host
  $join_target = target.ip[0]
  $join_target = $median.target

  outcome:
    $host = $join_host
    $target = $join_target
    $absolute_deviation = math.abs(network.sent_bytes - $median.median)
}

$host = $absolute_deviations.host
$target = $absolute_deviations.target

match:
  $host, $target

outcome:
  $mean_absolute_deviation = avg($absolute_deviations.absolute_deviation)

例: ウィンドウステージとテーブルステージ間のマッチレス結合

次の例は、マルチステージクエリでウィンドウステージとテーブルステージ間のマッチレス結合を構成する方法を示しています。

hourly_stats ステージは、送信された合計バイト数を送信元と宛先のホストペアと時間バケットごとに計算します。
hourly_stats ステージは、出力行の列に対応する次のステージフィールドを出力します。
- $hourly_stats.source_host: 単数、文字列
- $hourly_stats.dst_host: 単数、文字列
- $hourly_stats.total_bytes_sent: 単数、浮動小数点数
- $hourly_stats.window_start: 単数、整数
- $hourly_stats.window_end: 単数、整数
agg_stats ステージでは、各ソースホストとターゲットホストのペアについて、1 時間あたりのバイト数の平均と標準偏差が計算されます。
agg_stats は、出力行の列に対応する次のステージフィールドを出力します。
- $agg_stats.source_host: 単数、文字列
- $agg_stats.dst_host: 単数、文字列
- $agg_stats.avg_bytes_sent: 単数、浮動小数点数
- $agg_stats.stddev_bytes_sent: 単数、浮動小数点数
ルートステージは、hourly_stats の各行を、同じ送信元ホストと宛先ホストのペアの agg_stats の行と結合します。ソースホストとターゲットホストのペアごとに、そのホストペアバケットの合計送信バイト数と集計統計情報を使用して z スコアを計算します。

stage hourly_stats {
 $source_host = principal.hostname
 $dst_host = target.hostname
 principal.hostname != ""
 target.hostname != ""
 match:
   $source_host, $dst_host by hour
 outcome:
   $total_bytes_sent = sum(network.sent_bytes)
}

stage agg_stats {
  $source_host = $hourly_stats.source_host
  $dst_host = $hourly_stats.dst_host
  match:
    $source_host, $dst_host
  outcome:
   $avg_bytes_sent = avg($hourly_stats.total_bytes_sent)
   $stddev_bytes_sent = stddev($hourly_stats.total_bytes_sent)
}

$source_host = $agg_stats.source_host
$source_host = $hourly_stats.source_host

$dst_host = $agg_stats.dst_host
$dst_host = $hourly_stats.dst_host

outcome:
  $hour_bucket = timestamp.get_timestamp($hourly_stats.window_start)
  $z_score = ($hourly_stats.total_bytes_sent - $agg_stats.avg_bytes_sent)/$agg_stats.stddev_bytes_sent

マルチステージクエリのクロス結合

Google SecOps 検索またはダッシュボードを使用する場合、マルチステージクエリのクロス結合を使用すると、個々の UDM イベントデータを他の YARA-L ステージで計算された集計統計情報と比較できます。

YARA-L では、cross join キーワードは 1 つの行のみを返すステージで機能します。

制限が 1 のステージと別のデータセット（UDM イベントなど）の間でクロス結合が使用されると、ステージから出力された単一行が他のデータセットの各行に追加されます。これにより、イベントデータが全体的な統計情報で拡充されます。

例: 通常とは異なるログインアクティビティを検出する

次の例では、通常よりも頻繁にログインするユーザーを特定します。この値は、各ユーザーのログイン回数（user_login_counts ステージを使用）と、すべてのユーザーの平均ログイン回数（total_users ステージを使用）を比較して計算されます。ログイン回数が異常に多いユーザーを検索結果で並べ替えることができます。

次に、クロス結合キーワードを使用して、total_users ステージの結果を user_login_counts ステージの結果にリンクします。

stage user_login_counts {
    $user = principal.user.userid
    metadata.event_type = "USER_LOGIN"
    security_result.action = "ALLOW"

    match:
        $user

    outcome:
        $login_count = count(metadata.id)
}

stage total_users {
    outcome:
        $count = count($user_login_counts.user)
    limit:
        1
}

cross join $total_users, $user_login_counts

$login_count = $user_login_counts.login_count
$user = $user_login_counts.user
$tot_users = $total_users.count

// all users who logged in the same number of times are grouped together.
match:
    $login_count
outcome:
    $num_users = count($user)
    $frequency_percent = (count($user) / max($tot_users) ) * 100

制限事項

マルチステージクエリには、次の機能的制約と構造的制約があります。

構造上の要件

クエリを作成する際は、次の構造要件を満たす必要があります。

ルートステージ: クエリごとにルートステージは 1 つのみ使用できます。
名前付きステージ: 最大 4 つの名前付きステージがサポートされています。
ステージ参照: ステージは、同じクエリ内で論理的に前に定義されたステージのみを参照できます。
クロス結合: クロス結合は、単一行を返すステージのみを参照できます。この要件を満たすには、参照されるステージに上限（1）を含める必要があります。この機能は、比較のために、個々のイベント行ごとに 1 つのグローバル統計情報（最大値や平均値など）を追加できるため、便利です。
結合: すべてのステージで、データテーブル以外の結合を最大 4 つ使用できます。
結果の要件: 各名前付きステージ（ルートステージを除く）には、match セクションまたは outcome セクションのいずれかを含める必要があります。outcome セクションでは集計は必要ありません。

ウィンドウと互換性の制限

ウィンドウの使用方法とクエリの実行場所には、次の制限が適用されます。

機能のサポート: マルチステージクエリは検索とダッシュボードで機能しますが、ルールではサポートされていません。
ウィンドウタイプ: 1 つのクエリ内で異なるウィンドウタイプを混在させないでください。
ウィンドウの依存関係: ホップウィンドウまたはスライディングウィンドウを使用するステージは、ホップウィンドウまたはスライディングウィンドウを使用する別のステージに依存できません。
タンブリングウィンドウサイズ: さまざまなステージのタンブリングウィンドウのサイズは異なる場合がありますが、サイズの差は 720 倍未満でなければなりません。

例: ステージの集計の差（無効）

次の構成は、1 か月には 44,640 分が含まれているため無効です（44,640 / 1 > 720）。

Stage: monthly_stats { ... match: by month }

ルート: match: by minute

例: ステージの集計の差（有効）

この問題を解決するには、ステージ間の比率を小さくします。たとえば、1 時間ごとのデータを集計して日次レポートを作成します。

Stage: daily_stats { ... match: by day }

ルート: match: by hour

24（1 日の時間数）は 720 より小さいため、システムはステージデータをルートステージに効率的にマッピングできます。

ステージとクエリの制限事項

マルチステージクエリ内の各ステージには、特定の制約があります。単一ステージクエリに適用される制限のほとんどは、個々のステージにも適用されます。

出力要件: 各ステージで、少なくとも 1 つの一致変数または結果変数（ステージフィールド）を出力する必要があります。
クエリの時間範囲:
- 標準クエリ: 最大 30 日。
- 一致しない結合を含むマルチステージクエリ: 最大 14 日間に制限されます。
ウィンドウサイズの上限: 最大ウィンドウサイズ（ホップ、スライディング、タンブリング）は、クエリに結合が含まれているかどうかによって異なります。
- 結合あり: 任意のタイプ（ホップ、スライディング、タンブリング）の最大ウィンドウサイズは 2 日間です。詳細については、検索結合の制限事項をご覧ください。
- 結合なし（単一イベント）:
- ホップウィンドウとスライディングウィンドウ: 最大 2 日。
- タンブリングウィンドウ: 最大値が 30 日に増加します。
結果変数の最大数:
- デフォルトは 20
- 上限の引き上げを有効にしているお客様の場合は 50
- 配列の制限: 配列値の結果変数には最大 10,000 個の要素を指定できます。
クエリあたりのイベント制約:
- 最大 2 つの UDM イベント
- 心電図イベントは最大 1 件
- 最大 2 つのデータテーブル

サービスとパフォーマンスの上限

マルチステージクエリには、統計情報クエリと同じ制限が適用されます。

統計情報クエリ: 120 QPH（API と UI）。
検索ビュー: 1 分あたり 100 回のビュー。
API のサポート: Google SecOps システムと EventService.UDMSearch API はマルチステージ結合をサポートしていますが、SearchService.UDMSearch API はサポートしていません。また、このシステムでは、結合なしでマルチステージクエリを実行することもできます。

イベントとグローバルの制限事項

イベントとプラットフォーム全体の境界内にとどまる必要があります。

最大イベント数

マルチステージクエリでは、同時に処理できるイベントの数が厳密に制限されます。

UDM イベント: 最大 2 つの UDM イベントを指定できます。
エンティティコンテキストグラフ（ECG）イベント: ECG イベントは 1 つまで許可されます。

グローバルクエリの制限事項

これらのプラットフォーム全体の制約により、マルチステージクエリが返すデータの範囲と量が制御されます。

クエリの期間: 標準クエリの最大期間は 30 日です。
結果セットの合計: 結果セットの合計サイズの上限は 10,000 件です。

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