Google 會運用 AI 技術將內容翻譯成你偏好的語言，但可能會出錯。

在搜尋和資訊主頁中套用 join

支援的國家/地區：

Google SecOps SIEM

Join 可協助關聯多個來源的資料，為調查提供更多脈絡資訊。連結相關事件、實體和其他資料，即可調查複雜的攻擊情境並呈現趨勢。

本文說明如何在 Google SecOps Search 欄位和資訊主頁面板中使用聯結作業。內容涵蓋支援的聯結類型、用途和最佳做法。

聯結的核心概念

您可以透過共用的預留位置變數或明確的等式陳述式 (例如 $e1.hostname = $e2.hostname) 連接資料來源，藉此建立聯結。在統計資料查詢的 match 區段中定義聯結時，必須使用預留位置變數。

以下範例說明如何使用兩個欄位 (以等號 = 和共用預留位置變數表示) 連結資料來源。

範例 1：使用預留位置變數隱含聯結

events:
  // Assign a value from the first event to the placeholder variable $user
  $user = $e1.principal.user.userid

  // The second assignment creates an implicit join, linking $e2 to $e1
  // where the user ID is the same.
  $user = $e2.principal.user.userid

match:
  $user over 1h

condition:
  $e1 and $e2

範例 2：使用等號和預留位置明確聯結

$e1.principal.ip = $ip
$e1.metadata.event_type = "USER_LOGIN"
$e1.principal.hostname = $host

$e2.target.ip = $ip
$e2.principal.hostname = "altostrat"
$e2.target.hostname = $host

match:
  $ip, $host over 5m

搜尋中的聯結

本節的範例會說明 Search 中使用的語法。

搜尋中的查詢預設不區分大小寫。

事件與事件的聯結

事件與事件的聯結會連結兩個不同的通用資料模型 (UDM) 事件。以下查詢範例會將 USER_LOGIN 事件與另一個事件連結，根據共用 IP 位址找出使用者互動的主機名稱 (altostrat)：
```
$e1.principal.ip = $ip
$e1.metadata.event_type = "USER_LOGIN"

$e2.target.ip = $ip
$e2.principal.hostname = "altostrat"

match:
  $ip over 5m
```

Event-ECG join

事件-ECG 聯結會將 UDM 事件與實體內容圖表 (ECG) 中的實體連結。以下範例查詢會找出實體圖中的 NETWORK_CONNECTION 事件和 ASSET，兩者在 1 小時內共用相同的主機名稱：

events:
  $e1.metadata.event_type = "NETWORK_CONNECTION"
  $g1.graph.metadata.entity_type = "ASSET"
  $e1.principal.asset.hostname = $g1.graph.entity.asset.hostname
  $x = $g1.graph.entity.asset.hostname

match:
  $x over 1h

condition:
  $e1 and $g1

資料表事件聯結

資料表事件聯結會將 UDM 事件與自訂資料表中的項目連結。這項功能有助於根據使用者定義的清單 (例如已知的惡意 IP 位址或威脅行為人)，檢查即時事件資料。以下查詢範例會將 NETWORK_CONNECTION 事件與資料表聯結，找出涉及該清單中特定 IP 位址的連線：
```
$ip = %DATATABLE_NAME.COLUMN_NAME
$ip = $e1.principal.ip
$e1.metadata.event_type = "NETWORK_CONNECTION"

match:
  $ip over 1h
```

搭配資料表使用 IN 子句

您也可以使用 in 子句，檢查欄位值是否存在於資料表欄中。所有資料來源 (例如 ioc.type in %abc.type) 都支援這項語法，可根據參照清單篩選事件，不必為聯結定義明確的預留位置變數。

常見用途

本節列出一些常見的聯結使用方式。

偵測憑證遭竊和遭盜用情形

目標：找出使用者成功登入，然後快速刪除重要系統檔案的案例。這可能表示帳戶遭到盜用，或是內部人員從事惡意活動。

加入類型：活動 - 活動加入

說明：這項查詢會連結兩個不同的事件，這些事件本身並不令人起疑，但如果同時發生，就非常可疑。系統會先尋找 USER_LOGIN 事件，然後尋找 FILE_DELETION 事件。這些項目會與常見的 user.userid 結合，並在短時間內顯示。

憑證竊盜偵測查詢

// Event 1: A user successfully logs in
$e1.metadata.event_type = "USER_LOGIN"
$e1.security_result.action = "ALLOW"
$e1.principal.user.userid = $user

// Event 2: The same user deletes a critical file
$e2.metadata.event_type = "FILE_DELETION"
$e2.target.file.full_path = /etc\/passwd|C:\\Windows\\System32\\/
$e2.principal.user.userid = $user

match:
  $user over 10m

condition:
  $e1 and $e2

找出重要資產的高風險連線

目標：使用資產資訊豐富即時網路資料，找出不應與外部低普及率網域通訊的伺服器 (例如生產資料庫伺服器) 傳出的連線。

加入類型：加入活動心電圖

說明：單一網路連線至罕見網域可能不是高優先順序。不過，這項查詢會將該事件與實體內容圖表 (ECG) 結合，進而提高事件的重要性。具體來說，這項規則會尋找實體圖中標示為「重要資料庫伺服器」的資產所發出的 NETWORK_CONNECTION 事件。

高風險連線查詢

events:
  $e.metadata.event_type = "NETWORK_CONNECTION"
  $e.target.domain.prevalence.day_count <= 5

  $asset.graph.metadata.entity_type = "ASSET"
  $asset.graph.entity.asset.labels.value = "Critical Database Server"

  $e.principal.asset.hostname = $asset.graph.entity.asset.hostname
  $host = $e.principal.asset.hostname

match:
  $host over 1h

condition:
  $e and $asset

搜尋威脅發動者 IOC

目標：主動搜尋入侵指標 (IoC)，方法是根據特定威脅行為者使用的已知網域清單，檢查所有即時 DNS 查詢。

聯結類型：資料表 - 事件聯結

說明：威脅情報團隊維護名為「惡意網域」的資料表ThreatActor_Domains，這項查詢會將所有即時 NETWORK_DNS_QUERY 事件與這個資料表聯結。如果網路中的主機嘗試解析威脅情報清單中的網域，系統會立即顯示相關例項。

威脅發動者 IOC 搜尋查詢

// Datatable: Get the list of malicious domains
$domain = %DATATABLE_NAME.COLUMN_NAME

// Event: A DNS query is made
$e.metadata.event_type = "NETWORK_DNS"
$e.network.dns.questions.name = $domain

match:
  $domain over 5m

condition:
  $e

資訊主頁中的 join

與「搜尋」相比，資訊主頁支援更多資料來源，且關聯性時間範圍更長。與標準 SQL 查詢不同，YARA-L 2.0 不會使用明確的 JOIN 陳述式，而是透過關聯共用預留位置變數或使用多階段查詢，連結資料來源。

區分大小寫

資訊主頁查詢會區分大小寫。如要在資訊主頁中執行不區分大小寫的聯結或搜尋，請使用 nocase 修飾符。

支援的資料來源

在資訊主頁中，您可以從支援的資料來源組合中，合併資料。(並非所有資料來源組合都能在單一查詢中合併)。

多來源資訊主頁查詢中的每個資料參照都必須包含 YARA-L 前置字元限定符 (例如 $u1)，而不只是已聯結的欄位。這樣一來，系統就能正確識別重疊資料來源的欄位擁有權。

支援的彙整組合

您可以在內建資訊主頁中，使用聯結功能關聯 UDM 事件、實體內容和資料表。為維持系統效能，請先查看本節中的支援組合和技術限制，再建構查詢。

UDM 事件到 UDM 事件 (多個事件)
UDM 事件至實體情境
UDM 事件至資料表
案件到案件記錄：這個組合嚴格限制為只能有一個 case 來源和一個 case_history 來源。您無法在這個彙整中加入任何其他資料來源。

注意： 如要將 SOAR 案件資料 (case 或 case_history) 與 SIEM UDM 事件、實體內容或資料表建立關聯，請先將資料集匯出至 BigQuery。資料匯出後，您可以在 BigQuery 中使用標準 SQL 查詢，或在商業智慧工具中建立跨來源的視覺化圖表。如需設定操作說明，請參閱「匯出至自行管理的 BigQuery 專案」。

如要瞭解限制和防護措施，請參閱「技術限制和限制條件」。

範例：聯結案件和 case_history

您可以根據專屬案件 ID 彙整案件中繼資料與歷史活動。

以下範例會聯結 case 和 case_history 資料來源，計算每個高優先順序案件的歷來動作總數。

  // 1. Establish the Join using a shared placeholder variable ($case_id)
  $h.case_history.case_response_platform_info.case_id = $case_id
  $c.case.response_platform_info.response_platform_id = $case_id

  // 2. Apply Filters
  $c.case.priority = "PRIORITY_HIGH"

  // 3. Group the correlated data by the Case ID
  match:
    $case_id

  // 4. Calculate the selected metrics to display on the dashboard
  outcome:
    $case_name = array_distinct($c.case.display_name)
    $total_historical_actions = count($h.case_history.case_activity)

進階用途：計算 MTTR

如要使用平均解決時間 (MTTR) 或平均結案時間 (MTTC) 等較複雜的指標，可以採用多階段查詢。這樣一來，您就能計算第一階段中每個案件的時長，然後在最終結果區塊中，計算這些時長的平均值。

以下查詢會計算「Default Environment」中所有案件的平均結案時間 (以分鐘為單位)。

stage stage1 {
  // 1. Establish the Join
  $h.case_history.case_response_platform_info.case_id = $case_id
  $c.case.response_platform_info.response_platform_id = $case_id

  // 2. Filter by specific environment
  $c.case.environment = "Default Environment"

  // 3. Group by Case ID to process per case
  match:
    $case_id

  // 4. Calculate the Time to Close (TTC) for each case individually
  outcome:
    $case_close_time = max(if($h.case_history.case_activity = "CLOSE_CASE", $h.case_history.event_time.seconds, 0))
    $status = array_distinct($h.case_history.case_activity)

    // Subtract the very first event time (creation) from the close time
    $TTC = $case_close_time - min($h.case_history.event_time.seconds)

  // 5. Filter to ensure the case has a complete lifecycle
  condition:
    arrays.contains($status, "CREATE_CASE") and
    arrays.contains($status, "CLOSE_CASE")
}

// 6. Global Aggregation: Calculate the Mean (Average) across all processed cases
outcome:
  $case_count = count($stage1.case_id)
  $MTTC = (math.round(avg($stage1.TTC) / 60))

最佳做法

如要盡可能提升聯結查詢的效能，並確保查詢能有效處理，請按照下列最佳做法篩選事件及管理搜尋範圍。

使用特定篩選器減少事件數量

由於聯結查詢會合併許多結果，因此可能需要大量資源。

廣泛的一般篩選器可能會導致查詢失敗，有時甚至會延遲很久才失敗，例如：
- target.ip != ""
- metadata.event_type = "NETWORK_CONNECTION" (如果環境中很常見這類事件)
建議您將一般篩選條件與更具體的篩選條件合併，減少查詢需要處理的事件總數。廣泛篩選器 (例如 target.ip != "") 應搭配更具體的篩選器，以提升查詢成效，例如：
```
$e1.metadata.log_type = $log
$e1.metadata.event_type = "USER_LOGIN"
$e1.target.ip != ""

$e2.metadata.log_type = $log
$e2.principal.ip = "10.0.0.76"
$e2.target.hostname != "altostrat"

match:
$log over 5m
```

如果查詢速度仍然緩慢，您也可以縮短查詢的整體時間範圍 (例如從 30 天縮短為一週)。

詳情請參閱「YARA-L 最佳做法」。

技術限制

在搜尋和資訊主頁中使用聯結時，請務必遵守下列限制。

比對視窗和查詢限制

比對視窗會定義事件的特定關聯時間範圍。這與您在使用者介面中選取的搜尋時間範圍不同。

搜尋限制

搜尋功能經過最佳化，可在較短的時間範圍內進行即時或快速調查。

查詢限制	用量
最多 48 小時 (部分查詢可能支援更長的時間範圍)。	在快速調查中關聯事件。

資訊主頁的限制

資訊主頁支援長期歷來資料分析。

join 類型	查詢限制	用量
UDM 對 UDM 和 UDM 對實體	31 天	大量遙測查詢。
Case-to-CaseHistory	90 天	生命週期追蹤查詢。
其他支援的設定	最多 365 天	非 UDM 或以指標為準的來源 (例如擷取指標) 的備援。

資料來源和資料表限制

單一查詢中可聯結的資料來源和資料表數量上限，取決於您使用的是搜尋或資訊主頁。

搜尋限制

每項查詢最多可使用兩個 UDM 事件。
每項查詢最多可使用一個心電圖事件。
每項查詢最多可使用兩個 Datatable。
您無法直接將資料表加入實體內容表，必須使用 UDM 事件做為中介橋樑 (例如，同時將 $event.target.hostname 與 $datatable.hostname 和 $asset.graph.entity.asset.hostname 建立關聯)。

資訊主頁限制

join 類型	事件資料表 (UDM 或資料表) 數量上限	實體資料表數量上限
多重事件 (UDM 至 UDM)	2	不適用
UDM 對應實體	2	1
UDM 至資料表	2	不適用
多階段查詢	2	1

效能和防護機制

系統會監控複雜的聯結查詢，避免資源用量過高。為保護整體環境效能，系統可能會自動暫停或隔離超過資源安全門檻的查詢。

如果查詢失敗或傳回錯誤，指出查詢超出資源限制，請嘗試下列最佳化做法：

縮小查詢時間範圍。
在彙整發生前，新增更具體的篩選器來縮減資料集大小。
簡化彙整作業。

API 和查詢類型限制

使用者介面和 EventService.UDMSearch API 支援聯結，但 SearchService.UDMSearch API 不支援。

還有其他問題嗎？向社群成員和 Google SecOps 專業人員尋求解答。