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

使用動態饋給使用者介面

支援的服務：

Google SecOps SIEM

本文說明如何在動態饋給管理使用者介面中建立、疑難排解及管理動態饋給，包括修改、啟用和刪除動態饋給的操作說明。

事前準備

在 Google Security Operations 設定資料動態饋給前，必須先滿足特定條件。如要查看動態饋給規定，請參閱「依來源類型設定」一節，並搜尋特定資料來源。

支援的壓縮格式和檔案大小

動態饋給擷取支援的壓縮格式包括 .gz、.tar.gz、.tar 和 solr.gz。下表列出 Google SecOps 動態饋給轉換支援的不同檔案大小：

作業	輸入類型	建議大小	預期時間長度	大小上限
資料建模	CSV	< 5 GB	< 7 分鐘	10 GB
資料建模	CSV	< 5 GB	~30 分鐘	10 GB
資料建模	CSV	待定	待定	2 GB
資料建模	XML / JSON	< 1 GB	< 10 分鐘	2 GB
資料建模	XLS / XLSX	< 50 MB	~1 分鐘	50 MB
合併檔案	不限	< 1 GB	視檔案數量而定	100 GB
解壓縮檔案	非郵遞區號	< 5 GB	視檔案數量而定	10 GB (未壓縮)
解壓縮檔案	ZIP	-	視檔案數量而定	4 GB (未壓縮)

記錄行限制和分隔符號

擷取文字記錄 (JSON、CSV 或 Syslog) 時，請確保資料符合下列特定擷取限制：

單行大小上限：單行記錄不得超過 4 MB。如果單行超過此限制，動態饋給會失敗，並顯示錯誤 MaxLogLineSize4MBExceeded。
支援的分隔符號：支援換行 (\n) 和回車字元 + 換行 (\r\n)。

變更連結的雲端專案對資料動態饋給的影響

如果您要更新與 Google SecOps 執行個體相關聯的 Google Cloud 專案，所有使用下列連接器擷取資料的動態饋給都會停止，且必須手動重新建立：

AMAZON_S3_V2
AMAZON_SQS_V2
GOOGLE_CLOUD_STORAGE_V2
AZURE_BLOBSTORE_V2
GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN

所有其他未採用這些連接器的動態饋給，則會繼續擷取資料，不受影響。客戶無須採取任何行動。

在遷移過程中應該注意什麼

受影響的動態饋給會出現下列異動：

動態饋給狀態：遷移前建立的動態饋給會立即停止擷取即時資料，並轉為唯讀狀態。
現有資料：遷移前已轉移至 Google SecOps 的資料會自動擷取，不會遺失。
錯誤訊息：如果嘗試編輯或刪除舊版動態饋給，系統會顯示以下訊息：This feed is read-only because this SecOps has now moved to a new Google Cloud Project (BYOP). To continue ingesting data from this source, please create a new feed。

客戶須採取的行動

為確保資料持續擷取，請務必在新環境中手動重新建立動態饋給。請按照下列步驟操作，盡可能減少干擾：

重新建立動態饋給：您必須建立新的動態饋給，取代遷移前的動態饋給。
設定檔案存在時間上限：設定新動態饋給時，請將檔案存在時間上限設為 BYOP 更新啟動前約 2 小時。這段緩衝時間可確保順利轉換。
管理重複資料：視您選取的「檔案保留期限上限」而定，系統可能會轉移部分重複資料。如要瞭解 Google SecOps 如何篩除這些重複記錄，請參閱「防止簡化」一文。

注意： 如果動態饋給已啟用「轉移後刪除」選項，則不適用這項功能。
記錄並刪除現有動態饋給 (遷移前)：開始 BYOP 遷移前，請先記錄所有使用受影響連接器 (例如 Amazon S3 V2) 的現有動態饋給設定，然後刪除這些動態饋給。如果未刪除遷移前建立的動態饋給，這些動態饋給會變成無法管理，並以孤立設定的形式保留在 Google SecOps 網頁介面中。

設定動態饋給的方式

Google SecOps 客戶可以透過兩種方式在平台中設定動態饋給。請根據您的環境，選擇最合適的方法：

SIEM 設定 > 動態饋給 (標準)
Content Hub > Content Packs (付費)

設定 IP 許可清單

Google SecOps 從 S3、SQS、Azure 和第三方 API 提取資料時，Google 基礎架構會連出至客戶的 bucket 或第三方 API。

如要為儲存空間 bucket 或防火牆設定輸入許可清單，請根據動態饋給類型設定許可清單，如下列清單所述：

V2 動態饋給 (S3_V2、SQS_V2、Azure_Blobstore_V2)：這些動態饋給只會使用 Google Cloud Storage 移轉服務 (STS)，從客戶儲存空間提取資料。必須將 STS IP 範圍加入許可清單：ipranges.json。
第三方 API：需要 goog.json。
舊版動態饋給 (S3、Azure_Blobstore)：需要專屬 IP 範圍。如要瞭解詳情，請與 Google SecOps 支援團隊聯絡。
Azure 事件中樞：需要特定區域的 IP 範圍。詳情請參閱「建立 Azure 事件中心動態饋給」中的「設定網路安全 (選用)」。

由於 Google 服務 IP 範圍會動態變更，Google 建議您按照下列步驟，設定防火牆定期擷取及剖析動態饋給：

V2 動態饋給 (S3_V2、SQS_V2、Azure_Blobstore_V2)：資料移轉作業完全由 Storage 移轉服務 worker 執行。您只需要定期擷取及剖析 ipranges.json 即可。
舊版動態饋給 (S3、SQS、Azure_Blobstore、Azure 事件中樞) 和第三方 API：這些連線源自 Google 基礎架構。您只需要定期擷取及剖析 goog.json 和 cloud.json。

設定動態饋給

本節說明如何一般設定動態饋給，從標準程序流程開始。「動態饋給」頁面列出的資料動態饋給，包含 Google 為您帳戶設定的所有動態饋給，以及您自行設定的動態饋給。

新增動態饋給

如要將動態饋給新增至 Google SecOps 帳戶，請完成下列步驟：

在 Google SecOps 選單中，依序選取「SIEM Settings」(SIEM 設定) >「Feeds」(動態消息)。
按一下「Add New Feed」。
在下一頁，點按「設定單一動態饋給」。注意：如果客戶使用 Google SecOps SIEM 獨立平台，則不適用這個步驟。
新增動態饋給名稱。
在「Source type」(來源類型) 清單中，選取要將資料匯入 Google SecOps 的來源類型。您可以選取下列動態饋給來源類型：
- Amazon Data Firehose
- Amazon S3 (已淘汰)
- Amazon S3 (V2)
- Amazon SQS (已淘汰)
- Amazon SQS (V2)
- Azure Blob 儲存體 (已淘汰)
- Azure Blob 儲存體 (V2)
- 自訂 API
- Google Cloud Pub/Sub
- Cloud Storage (已淘汰)
- Cloud Storage (V2)
- Cloud Storage 事件導向
- 第三方 API
- Webhook
重要事項：
- 使用 Amazon S3 (已淘汰)、Amazon SQS (已淘汰)、Azure Blob 儲存體 (已淘汰) 和 Cloud Storage (已淘汰) 動態饋給時，請務必提供有效的目錄路徑。 Google Cloud
- 使用 Amazon SQS (已淘汰) 或 Amazon SQS (V2) 時，請明確授予 Google SecOps 權限，以便從 Amazon SQS 佇列中刪除訊息。
- 使用 Amazon SQS (已淘汰) 動態饋給時，請確保只有一個動態饋給會使用佇列中的訊息。其他應用程式或動態饋給讀取的訊息不會擷取到目前的動態饋給。
- 只有 Amazon S3 bucket 中的記錄，才能使用 Amazon SQS (已淘汰) 做為動態饋給來源類型。
在「Log type」(記錄類型) 清單中，選取要擷取的記錄類型。可用的記錄會因您先前選取的來源類型而異。

注意： 如果是 AWS CLOUDTRAIL 記錄類型，請確認記錄採用 JSON 格式，且檔案名稱為 JSON 檔案 (未壓縮) 或 JSON GZipped 檔案 (壓縮)。

如果選取「Cloud Storage」做為來源類型，請使用「Get service account」(取得服務帳戶) 選項取得專屬服務帳戶。請參閱「Google Cloud Storage 動態饋給設定範例」。
點選「下一步」。
在「Input Parameters」(輸入參數) 分頁中指定所需參數。這裡顯示的選項會因您在「Set Properties」(設定屬性) 分頁中選取的來源和記錄類型而異。將游標懸停在每個欄位的問號圖示上，即可進一步瞭解需要提供的資訊。
選用：您可以在「Set Properties」(設定屬性) 分頁中指定命名空間。如要進一步瞭解命名空間，請參閱「使用資產命名空間」。
點選「下一步」。
在「完成」分頁中，查看新的動態饋給設定。
按一下「提交」。Google SecOps 會完成新動態饋給的驗證檢查。如果動態饋給通過檢查，系統會為動態饋給產生名稱，並提交至 Google SecOps，Google SecOps 則會開始嘗試擷取資料。

為產品系列設定多個動態饋給 (僅限 Google SecOps 客戶)

您可以根據記錄類型，為每個產品系列設定多個動態饋給。

基準記錄類型：標示為「建議」。建議您使用這些記錄類型，以確保核心平台功能正常運作。
補充記錄類型：標示為選用。這些記錄類型可提供額外背景資訊。

為簡化設定程序，平台會提供具體的操作說明，並為每項設定預先定義參數。舉例來說，如果是 CrowdStrike Falcon，您可以在「建議」和「選用」記錄類型下建立多個不重複的動態饋給，確保資料涵蓋範圍夠全面。

設定 CrowdStrike EDR 的動態饋給

請按照下列步驟，設定 CrowdStrike EDR 的記錄檔動態饋給。

依序點選「設定」>「動態饋給」>「新增動態饋給」
1. 按一下「CrowdStrike Falcon」產品：
2. 選取「CrowdStrike EDR」記錄類型。
或者，依序點選「Content Hub」>「Content Packs」，然後點選「CrowdStrike Falcon」產品：
1. 點選「開始使用」。
2. 選取「CrowdStrike EDR」記錄類型。

為下列欄位指定值：

欄位	說明
`Source Type`	Amazon SQS
`Region`	與 URI 相關聯的 AWS S3 區域。
`Queue Name`	要讀取的 SQS 佇列名稱。
`Account Number`	SQS 帳號。
`Source Deletion Option`	指出是否要在移轉後刪除檔案和目錄。
`Queue Access Key ID`	帳戶的 20 個英數字元存取金鑰，例如 `AKIAOSFOODNN7EXAMPLE`。
`Queue Secret Access Key`	帳戶的 40 個英數字元密鑰存取金鑰，例如 `wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY`。

選用步驟：設定下列參數：
- 動態饋給名稱：預先填入的動態饋給專屬名稱。
- 素材資源命名空間：與動態饋給相關聯的命名空間。
- 擷取標籤：套用至這個動態饋給事件的標籤。
按一下「建立動態饋給」。

您可以重複這個程序，為相同記錄類型建立其他動態饋給。您也可以直接在這個頁面，為其他可用的記錄類型設定動態饋給。完成後，請前往「Feed Management」(動態饋給管理) 頁面，查看所有已設定記錄類型的詳細摘要。

刪除來源檔案

來源刪除選項可讓您在移轉成功後，從儲存空間刪除動態饋給來源物件 (檔案和資料夾)。這個選項僅適用於所選動態饋給來源類型，包括 Cloud Storage。這些動態饋給來源類型的「新增」和「編輯動態饋給」工作流程中，包含「來源刪除選項」欄位。

來源刪除選項

如果是支援的動態饋給來源類型 (包括 Cloud Storage)，「SOURCE DELETION OPTION」(來源刪除選項) 欄位會提供下列選項：
- 一律不刪除檔案
- 刪除已轉移的檔案和空目錄
- 刪除轉移的檔案
Microsoft Azure Blob Storage (AZURE_BLOBSTORE) 不支援刪除來源檔案。在「SOURCE DELETION OPTION」(來源刪除選項) 欄位中，請務必選取「Never delete files」(一律不刪除檔案) 選項。
下列動態饋給來源 ("feedSourceType")：GOOGLE_CLOUD_STORAGE_V2、GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN、AMAZON_S3_V2、AMAZON_SQS_V2 和 AZURE_BLOBSTORE_V2，其「SOURCE DELETION OPTION」欄位提供兩個選項：
- NEVER：轉移後一律不刪除任何檔案。
- ON_SUCCESS：轉移後刪除所有檔案和空白目錄。

在 STS 動態饋給中依前置字串篩選物件

「Include prefixes」(包含前置字串) (include_prefixes) 欄位會根據物件金鑰前置字串，篩選 Storage 移轉服務 (STS) 在擷取前移轉的儲存空間物件。您在這個欄位中指定的值會直接傳遞至 STS ObjectConditions.include_prefixes。

支援的 STS 動態饋給來源類型

下列 STS 動態饋給來源類型 (feedSourceType) 支援前置字元篩選：

Cloud Storage (V2) (GOOGLE_CLOUD_STORAGE_V2) 和 Cloud Storage 事件導向 (GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN)
Amazon S3 (V2) (AMAZON_S3_V2) 和 Amazon SQS (V2) (AMAZON_SQS_V2)
Azure Blob 儲存體 (V2) (AZURE_BLOBSTORE_V2) 和事件導向 Azure Blob 儲存體 (AZURE_BLOBSTORE_EVENT_DRIVEN)

前置字串語法和驗證規則

設定「包含前置字元」 (include_prefixes) 時，請遵循下列語法和驗證規則：

開頭不得為斜線：前置字串是相對於 bucket 或容器根目錄，開頭不得為斜線 (/)。例如，請輸入 logs/audit/，而非 /logs/audit/。
結尾斜線與部分比對：結尾斜線可控制前置字串是否僅比對特定資料夾中的物件，或任何以前置字串開頭的物件鍵：
- 結尾斜線：如果前置字串結尾為 / (例如 logs/app/)，則只會比對該資料夾中的物件。在結尾加上斜線，即可指定目錄層級範圍。
- 不含結尾斜線：不含結尾 / 的前置字串 (例如 logs/app) 會比對開頭為該字串的任何物件，包括 logs/app_old/ 和 logs/application/。
區分大小寫：物件金鑰前置字串會嚴格區分大小寫。
不支援萬用字元或規則運算式：不支援模式比對。* 和 ? 等字元會視為常值字元。
不得留空：個別前置字元項目不得留空或只包含空白字元。如要擷取整個 bucket 或容器，請將「Include prefixes」(包含前置字元) 欄位留空。
不重複、不重疊的命名空間：前置字串不得與同一清單中的其他前置字串相同。舉例來說，["logs/", "logs/audit/"] 無效，但同層前置字元 (例如 ["logs/audit/", "logs/vpc/"]) 有效。
限制：動態饋給最多支援 1,000 個前置字串。每個前置字串的長度上限為 1,024 個位元組 (UTF-8 編碼)，且不得包含回車字元 (\r) 或換行字元 (\n)。

來源專屬設定和權限

不同來源類型需要特定的驗證和網路設定，才能與 Google SecOps 通訊。本節說明如何設定權限和服務帳戶。設定重點包括 Cloud Storage 擷取 (提取式)、多雲端擷取 (跨雲端提取) 和推送式擷取 (API 或即時)。

Google Cloud Storage 動態饋給設定範例

在 Google SecOps 選單中，依序選取「設定」和「動態饋給」。
按一下「Add New Feed」。
在下一頁，點按「設定單一動態饋給」。如果您使用的是 Google SecOps SIEM 獨立平台，則不適用這個步驟。
在「來源類型」部分，選取「Cloud Storage v2」。
選取「Log type」(記錄類型)。舉例來說，如要建立 Google Kubernetes Engine 稽核記錄的動態饋給，請選取「Google Kubernetes Engine audit logs」(Google Kubernetes Engine 稽核記錄) 做為「Log Type」(記錄類型)。
按一下「取得服務帳戶」。Google SecOps 會提供專屬服務帳戶，用於擷取資料。或者，您也可以使用 API，透過程式輔助方式取得這個服務帳戶。請參閱「擷取服務帳戶」。
選用：設定服務帳戶。詳情請參閱「授予 Google SecOps 服務帳戶存取權」。
點選「下一步」。
根據您建立的 Cloud Storage 設定，指定下列欄位的值：
- Storage bucket URI
  
  注意： 使用萬用字元可比對整個目錄名稱。例如，gs://cs-myprod/*/more-data 是有效值 (其中 * 會取代單一目錄層級的完整名稱)。
  注意： 如果是 Cloud Storage 事件導向動態饋給類型，請按照「設定 Pub/Sub」一節的說明，為 Cloud Storage 設定 Pub/Sub 訂閱項目。
- 來源刪除選項
- 選用：加入前置字串。這項功能目前為有限預覽。如要瞭解語法規則和許可清單詳情，請參閱「在 STS 動態饋給中依前置字串篩選物件」。
如要進一步瞭解如何設定 Cloud Storage bucket，請參閱「建立 bucket」。

注意： Cloud Storage bucket 動態饋給不支援空白資料夾名稱。
依序點按「繼續」和「提交」。

將存取權授予 Google SecOps 服務帳戶

前往 Google Cloud 控制台的「Cloud Storage bucket」頁面。
前往「Buckets」(值區) 頁面
將相關 Cloud Storage 物件的存取權授予服務帳戶。
- 如要授予特定檔案的讀取權限，請完成下列步驟：
  1. 選取檔案，然後按一下「編輯權限」。
  2. 按一下「Add principal」(新增主體)。
  3. 在「新增主體」欄位，輸入 Google SecOps 服務帳戶名稱。
  4. 將包含讀取的權限的角色指派給 Google SecOps 服務帳戶。例如 Storage 物件檢視者 (roles/storage.objectViewer)。只有在未啟用統一 bucket 層級存取權時，才能執行這項操作。
  5. 按一下 [儲存]。
- 如要授予多個檔案的讀取權限，請在 bucket 層級授予存取權，如下所示：
  - 針對 "feedSourceType": "GOOGLE_CLOUD_STORAGE"：
    1. 將 Google SecOps 服務帳戶新增為儲存空間 bucket 的主體，並授予 IAM Storage 物件檢視者 (roles/storage.objectViewer) 角色。
    2. 如果將動態饋給設為刪除來源檔案，則必須將 Google SecOps 服務帳戶新增為 bucket 的主體，並授予 IAM Storage 物件管理員 (roles/storage.objectAdmin) 角色。
  - 為 "feedSourceType": "GOOGLE_CLOUD_STORAGE_V2" 授予下列角色：
    1. 授予這個角色：
      - 如果移轉至其他 Cloud Storage bucket，則為 Storage 物件檢視者 (roles/storage.objectViewer)。
    2. 根據您在「Source Deletion Option」(來源刪除選項) 中選取的項目，授予下列其中一個角色。如果選取「成功時」，請授予「Storage 舊版值區寫入者」角色。如果選取「Never」(永不)，請授予「Storage 舊版 bucket 讀取者」角色：
      - 如果需要物件刪除權限，則為 Storage 舊版值區寫入者 (roles/storage.legacyBucketWriter)。
      - 如果不需要物件刪除權限，請使用 Storage 舊版值區讀取者 (roles/storage.legacyBucketReader)。
  - 針對 "feedSourceType": "GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN"：
    1. 授予下列任一角色：
      - 如果移轉至其他 Cloud Storage bucket，則為 Storage 物件檢視者 (roles/storage.objectViewer)。
      - 如果轉移至檔案系統，則為 Storage 物件建立者 (roles/storage.objectCreator)。
    2. 授予下列任一角色：
      - 如果需要物件刪除權限，則為 Storage 舊版值區寫入者 (roles/storage.legacyBucketWriter)。
      - 如果不需要物件刪除權限，請使用 Storage 舊版值區讀取者 (roles/storage.legacyBucketReader)。

啟用 Amazon S3 和 Azure Storage 的 STS 存取權

下列 Google Cloud Storage 動態饋給會使用 STS，將資料從 Amazon S3 和 Azure Storage blobstore 移轉至 Google SecOps：

Amazon S3 (V2)
Amazon SQS (V2)
Azure Blob 儲存體 (V2)

STS 會從一組定義的 STS IP 位址範圍，將資料移轉要求傳送至 Amazon S3 和 Azure 儲存空間服務。這些 STS IP 位址範圍會發布在下列 JSON 檔案中：IP 範圍。

如要使用這些 STS 動態饋給來源類型，您可能需要調整 IP 存取限制，讓 STS 能夠存取 Amazon S3 和 Azure 儲存體服務：

從 JSON 檔案提取最新的 IP 範圍。

建議您至少每週讀取一次這個 JSON 檔案中的資料，確保安全性設定保持最新狀態。檔案中新增範圍後，系統會等待至少 7 天，才會將該範圍用於 STS 的要求。

如需從 JSON 檔案擷取 IP 範圍的 Python 指令碼範例，請參閱「預設網域的 IP 位址」。
比較目前的 IP 範圍 creationTime 與從先前 JSON 檔案讀取的 IP 範圍 creationTime。如果不同，請更新 Amazon S3 和 Azure Storage Blob 儲存庫中的 IP 存取限制。
- Amazon S3
  
  如要更新 Amazon S3 blobstore 的 IP 存取限制，請按照下列步驟操作：
  
  如果 AWS 專案使用 IP 限制來控管儲存空間存取權，您必須將 STS worker 使用的 IP 範圍新增至 IP 許可清單。
  
  注意： 如果您使用代理程式，而非無代理程式移轉作業，請改為將代理程式機器 IP 位址新增至允許的 IP 清單。
  
  如要將這些範圍新增為允許的 IP，請在 bucket policy 中使用 Condition 欄位，詳情請參閱 AWS S3 說明文件：根據特定 IP 位址管理存取權。
- Azure 儲存體
  
  如要更新 Azure Storage blobstore 的 IP 存取限制，請按照下列步驟操作：
  
  如果您使用 Azure 儲存體防火牆限制 Azure 資源的存取權，則必須將 STS worker 使用的 IP 範圍新增至允許的 IP 清單。
  
  如要將這些範圍新增為允許的 IP，請按照這篇文章的操作說明，設定 Azure 儲存體防火牆和虛擬網路。

設定 Pub/Sub 推送動態饋給

如要設定 Pub/Sub 推送動態饋給，請按照下列步驟操作：

建立 Pub/Sub 推送動態饋給。
在 Pub/Sub 訂閱項目中指定端點網址。

建立 Pub/Sub 推送動態饋給

在 Google SecOps 選單中，依序選取「設定」和「動態饋給」。
按一下「新增」。
在「Feed name」(動態饋給名稱) 欄位中，輸入動態饋給名稱。
在「Source type」(來源類型) 清單中，選取「Google Cloud Pub/Sub Push」。
選取「Log type」(記錄類型)。舉例來說，如要建立 Open Cybersecurity Schema Framework 的動態饋給，請選取「Open Cybersecurity Schema Framework (OCSF)」做為「記錄類型」。
點選「下一步」。
選用：指定下列輸入參數的值：
- 分割分隔符號：用於分隔記錄行的分隔符號。只能使用 \n。
- Asset namespace：資產命名空間。
- 擷取標籤：要套用至這個動態饋給事件的標籤。
點選「下一步」。
在「完成」畫面中檢查新的新聞動態消息設定，然後按一下「提交」。
在「詳細資料」分頁中，複製「端點資訊」欄位中的動態饋給端點網址。您需要這個端點網址，才能在 Pub/Sub 建立推送訂閱項目。
選用：按一下「動態饋給已啟用」切換鈕，即可停用動態饋給。動態饋給預設為啟用。
按一下「完成」。

指定端點網址

建立 Pub/Sub 推送動態饋給後，請按照下列步驟指定端點網址：

在 Pub/Sub 中建立推送訂閱項目。如要進一步瞭解如何建立推送訂閱項目，請參閱「建立推送訂閱項目」。
指定端點網址，可在 Google Cloud Pub/Sub 推送動態饋給中找到。
選取「啟用驗證」，然後選取服務帳戶。
停用「推送酬載解除包裝」和「推送酬載解除包裝寫入訊息中繼資料」選項。

設定 Amazon Data Firehose 動態饋給

如要設定 Amazon Data Firehose 動態饋給，請按照下列步驟操作：

建立 Amazon Data Firehose 動態饋給，然後複製端點網址和密鑰。
建立 API 金鑰，向 Google SecOps 進行驗證。您也可以重複使用現有的 API 金鑰，向 Google SecOps 進行驗證。
在 Amazon Data Firehose 中指定端點網址。

建立 Amazon Data Firehose 動態饋給

在 Google SecOps 選單中，依序選取「設定」和「動態饋給」。
按一下「新增」。
在「Feed name」(動態饋給名稱) 欄位中，輸入動態饋給名稱。
在「Source type」(來源類型) 清單中，選取「Amazon Data Firehose」。
選取「Log type」(記錄類型)。舉例來說，如要建立 Open Cybersecurity Schema Framework 的動態饋給，請選取「Open Cybersecurity Schema Framework (OCSF)」做為「記錄類型」。
點選「下一步」。
選用：指定下列輸入參數的值：
- 分割分隔符號：用於分隔記錄行的分隔符號。只能使用 \n。
- Asset namespace：資產命名空間。
- 擷取標籤：要套用至這個動態饋給事件的標籤。
點選「下一步」。
在「完成」畫面中檢查新的新聞動態消息設定，然後按一下「提交」。
按一下「產生密鑰」，產生用於驗證這個動態饋給的密鑰。
複製並儲存密鑰，因為您無法再次查看。您可以再次產生新的密鑰，但產生密鑰會使先前的密鑰失效。
在「詳細資料」分頁中，複製「端點資訊」欄位中的動態饋給端點網址。在 Amazon Data Firehose 指定傳送串流的目的地設定時，需要這個端點網址。
選用：按一下「動態饋給已啟用」切換鈕，即可停用動態饋給。動態饋給預設為啟用。
按一下「完成」。

為 Amazon Data Firehose 動態饋給建立 API 金鑰

如要為 Amazon Data Firehose 動態饋給建立 API 金鑰，請按照下列步驟操作：

前往 Google Cloud 控制台的「Credentials」(憑證) 頁面。
按一下「建立憑證」並選取「API 金鑰」。
限制 API 金鑰對 Chronicle API 的存取權。

指定端點網址

在 Amazon Data Firehose 中，指定 HTTPS 端點和存取金鑰，如下所示：

將 API 金鑰附加至動態饋給端點網址，並以下列格式將這個網址指定為 HTTP 端點網址：
```
  ENDPOINT_URL?key=API_KEY
```
更改下列內容：
- ENDPOINT_URL：動態饋給端點網址。
- API_KEY：用於向 Google SecOps 驗證身分的 API 金鑰。
存取金鑰：指定建立 Amazon Data Firehose 動態饋給時取得的密鑰。

設定 HTTPS Webhook 動態饋給

事前準備：

請確認您已Google Cloud 設定 Google SecOps 專案，並為該專案啟用 Chronicle API。
將 Google SecOps 執行個體連結至 Google Cloud 服務。

注意： 如果要求大小或 QPS 限制設得太低，透過 Webhook 動態饋給傳送的批次資料可能會發生擷取延遲。HTTPS 推送端點支援的單一要求大小上限為 4 MB，每個 Google SecOps 執行個體的處理量上限為 15,000 QPS。

如要設定 HTTPS Webhook 動態饋給，請按照下列步驟操作：

建立 HTTPS Webhook 動態饋給，並複製端點網址和密鑰。
建立 API 金鑰，並指定端點網址。您也可以重複使用現有的 API 金鑰，向 Google SecOps 進行驗證。
在應用程式中指定端點網址。

在單一 Webhook 要求中傳送多個事件

以下程式碼範例說明如何設定單一要求主體的格式，在 curl --location 項目後方加入多個以換行符號分隔的 JSON 物件：

--header 'Content-Type: application/json' \
--header 'X-goog-api-key: API_KEY' \
--header 'X-Webhook-Access-Key: SECRET' \
--data '{"principal": {"asset_id": "asset 123"}, "metadata": {"event_type": "GENERIC_EVENT", "product_name": "Product Acme"}}
{"principal": {"asset_id": "asset 123"}, "metadata": {"event_type": "GENERIC_EVENT", "product_name": "Product Acme"}}'

建立 HTTPS Webhook 動態饋給

在 Google SecOps 選單中，依序選取「設定」和「動態饋給」。
按一下「新增」。
在「Feed name」(動態饋給名稱) 欄位中，輸入動態饋給名稱。
在「Source type」(來源類型) 清單中，選取「Webhook」。
選取「Log type」(記錄類型)。舉例來說，如要建立 Open Cybersecurity Schema Framework 的動態饋給，請選取「Open Cybersecurity Schema Framework (OCSF)」做為「記錄類型」。
點選「下一步」。
選用：指定下列輸入參數的值：
- 分割分隔符號：用於分隔記錄行的分隔符號。只能使用 \n。
- Asset namespace：資產命名空間。
- 擷取標籤：要套用至這個動態饋給事件的標籤。
點選「下一步」。
在「完成」畫面中檢查新的新聞動態消息設定，然後按一下「提交」。
按一下「產生密鑰」，產生用於驗證這個動態饋給的密鑰。
複製並儲存密鑰，因為您無法再次查看。您可以再次產生新的密鑰，但產生密鑰會使先前的密鑰失效。
在「詳細資料」分頁中，複製「端點資訊」欄位中的動態饋給端點網址。您必須在用戶端應用程式中指定這個端點網址。
選用：按一下「動態饋給已啟用」切換鈕，即可停用動態饋給。動態饋給預設為啟用。
按一下「完成」。

為 Webhook 動態饋給建立 API 金鑰

前往 Google Cloud 控制台的「Credentials」(憑證) 頁面。
按一下 [Create credentials] (建立憑證)，然後選取 [API key] (API 金鑰)。
限制 API 金鑰對 Chronicle API 的存取權。

指定端點網址

在用戶端應用程式中，指定 Webhook 動態饋給提供的 HTTPS 端點。
在自訂標頭中指定 API 金鑰和密鑰，格式如下：

X-goog-api-key = API_KEY

X-Webhook-Access-Key = SECRET

建議您將 API 金鑰指定為標頭，而非在網址中指定。如果 Webhook 用戶端不支援自訂標頭，您可以使用下列格式的查詢參數，指定 API 金鑰和密鑰：
```
  ENDPOINT_URL?key=API_KEY&secret=SECRET
```
更改下列內容：
- ENDPOINT_URL：動態饋給端點網址。
- API_KEY：用於向 Google SecOps 驗證身分的 API 金鑰。
- SECRET：您產生的密鑰，用於驗證動態饋給。

設定自訂 API 動態饋給

Google Security Operations 自訂 API 動態饋給 (又稱無程式碼連接器) 可讓您使用彈性的設定式模型，從第三方 REST API 擷取遙測資料。您可以直接在控制台定義端點、驗證、分頁策略和狀態管理，設定資料提取。

主要優點

加速整合：透過引導式精靈，在幾分鐘內完成新遙測來源的新進人員訓練，不必等待後端更新。
有狀態檢查點：確保輪詢週期內不會重複或遺漏任何記錄。
父項-子項展開：支援兩層探索工作流程，例如列出資源並擷取相關聯的遙測資料。
自動化復原能力和頻率限制：防止供應商節流和配額用盡。為確保擷取作業穩定不中斷，Custom API 動態饋給會自動處理 HTTP 429 回應，並採用指數輪詢機制。此外，這項功能也會透過可設定的頻率限制和工作延遲交錯機制，調整要求速度，並強制執行安全防護措施。詳情請參閱「頻率限制和節流防護措施」。

必要條件

建立自訂 API 動態饋給前，請先確認符合下列必要條件：

權限：如要建立或修改動態饋給，您必須具備 Chronicle API 管理員 (roles/chronicle.admin) 或 Chronicle API 編輯者 (roles/chronicle.editor) 角色。
第三方 API 規定：
- 有效的 API 基準網址 (必須使用 https://)。
- API 憑證 (API 金鑰、基本驗證憑證，或 OAuth 2.0 用戶端 ID/密鑰)。
- 供應商 API 說明文件，詳細說明端點路徑、要求參數、JSON 回應結構和頻率限制。
Secret Manager 存取權：憑證會在 Secret Manager 中加密及安全管理。執行連接器的服務身分會自動與 Secret Manager (roles/secretmanager.secretAccessor 和 roles/secretmanager.admin) 互動。

設定自訂 API 動態饋給

如要設定自訂 API 動態饋給，請按照下列步驟操作：

依序前往「SIEM 設定」>「動態饋給」。
按一下「新增動態饋給」。
按一下「設定單一動態饋給」。
在「Feed name」(動態饋給名稱) 欄位中，輸入不重複的描述性名稱 (例如 1Password-Audit-Events)。
在「Source type」(來源類型) 清單中，選取「Custom API」(自訂 API)。
在「Log type」(記錄類型) 清單中，選取目標 Google SecOps 記錄類型。
點選「下一步」。
在「一般設定」下方，進行下列設定：
- 基準網址：輸入主要主機 (例如 https://events.1password.com)，開頭必須是 https://。請勿附加子路徑或結尾斜線。
- 輪詢頻率：指定平台檢查 API 是否有新遙測資料的頻率，以分鐘為單位。支援的範圍：5 至 2880 分鐘 (預設：15 分鐘)。標準 API (依序) 動態饋給通常需要 10 到 15 分鐘；清單和詳細資料 (父項-子項) 動態饋給則建議 30 到 60 分鐘，以便完整執行展開工作，避免重疊。
在「Authentication」(驗證) 下方，選取其中一種支援的驗證方式，然後設定必要欄位：
- 基本驗證：輸入使用者名稱 (API 帳戶身分) 和密鑰 (即密鑰密碼或權杖)。
- OAuth 2.0 用戶端憑證：使用 OAuth 2.0 用戶端憑證授權流程進行驗證。Google SecOps 會在每次擷取週期前，自動要求、快取及重新整理不記名存取權杖。輸入 OAuth 權杖端點 (例如 https://auth.vendor.com/oauth/token)、OAuth 用戶端 ID 和 OAuth 用戶端密鑰。
- API 金鑰要求標頭：使用插入要求標頭的自訂 API 金鑰進行驗證 (最常見的企業 REST 模式)。輸入「標頭名稱」 (例如 Authorization 或 X-API-Key) 和「標頭值」 (例如 Bearer <SECRET_TOKEN> 或 <SECRET_KEY>)。
- API 金鑰查詢參數：使用插入網址查詢參數的自訂 API 金鑰進行驗證。輸入「查詢參數名稱」 (例如 api_key) 和「查詢參數值」 (例如 <SECRET_KEY>)。
注意： 您在此輸入的所有憑證都會在輸入時自動遮蓋，並在 Secret Manager 中安全加密，並可選擇支援客戶自行管理的加密金鑰 (CMEK)。
選取自訂 API 使用的連接器模型：
- 標準 API (依序)：線性輪詢流程，每次輪詢都直接以前一次輪詢的狀態為基礎。在這個模式中，下次輪詢會使用從上次輪詢擷取的游標、權杖或時間戳記，只擷取新資料。如果供應商提供的端點會直接傳回遙測事件記錄 (例如 1Password、Okta、SentinelOne、GitHub 或 Slack)，請選取這張資訊卡。
- 清單與詳細資料 (上層/子項)：兩層式探索流程。動態饋給會發出初始呼叫 (父項)，擷取資源或物件清單 (例如使用者 ID 或可用區清單)。接著，動態饋給會自動產生依附的後續呼叫 (子項)，擷取每個已識別資源的詳細遙測資料。如果供應商 API 需要兩層探索模式，請選取這張資訊卡：先呼叫端點來擷取動態實體清單 (例如區域、帳戶、專案、裝置)，然後針對每個實體執行後續詳細資料要求，以擷取遙測資料 (例如 Cloudflare、AWS CloudWatch 或 Tenable)。
注意： 這兩種模型都使用檢查點，這是一種狀態管理程序，會從輪詢中擷取並儲存最高的時間戳記或 ID，以便在下一個週期繼續擷取，不會遺漏記錄或建立重複資料。
如果選取「Standard API (Sequential)」，請按照下列步驟操作：
1. 在「API 端點」下方，設定下列參數，定義要求的技術路徑和頻率調節：
  - 端點路徑：附加至基準網址的特定 API 路徑 (例如 /api/v1/auditevents)，用於定義要查詢的確切遙測資源。
  - HTTP 方法：選取「GET」，即可使用網址查詢參數擷取資料；選取「POST」，則可提交搜尋酬載或篩選主體。
2. 要求主體：如果是 POST 要求，請提供 JSON 資料酬載。您可以嵌入動態查核點變數，例如 {"limit": 100, "start_time": "{{.last_timestamp}}"}。
3. 每分鐘要求數上限：輸入每分鐘可傳送的要求數上限。這是用戶端頻率限制器，用於遵守供應商 API 頻率限制 (預設：5 RPM = 每 12 秒 1 個要求)。這項設定可避免在多頁分頁期間耗盡配額。
4. 選用：在「自訂標頭」下方，設定「標頭名稱」和「值」，然後按一下「新增」，定義目標 API 所需的特殊 HTTP 標頭 (例如 Content-Type: application/json, Accept: application/json)。
5. 選用：在「查詢參數」下方，設定「鍵」和「值」，然後按一下「新增」，指定要附加至網址查詢字串的其他篩選器或選項 (例如 count=1000、status=active)，或繫結動態範本變數 (例如 start={{.last_run_time}})。
6. 在「Pagination strategy:」(分頁策略：) 下方，選取第三方 API 處理多頁結果集所需的分頁機制，然後設定必要欄位：
  - 無：在單一要求中擷取資料，不分頁。
  - 權杖分頁：使用權杖 (自訂索引鍵) 取得下一頁。輸入「下一頁權杖 JSON 路徑」 (例如 meta.next_cursor) 和「權杖分頁查詢參數名稱」 (例如 cursor)。
  - 連結分頁：按照回應中提供的網址取得更多資料。輸入下一頁連結 JSON 路徑 (例如 links.next 或 @odata.nextLink)。
  - 偏移分頁：略過特定數量的記錄，取得下一組記錄。輸入偏移查詢參數名稱 (例如 offset)。
  - 頁碼分頁：前往下一個頁碼。輸入頁碼查詢參數名稱 (例如 page)。
7. 在「Checkpointing」(檢查點) 下方，設定連接器在週期性輪詢週期之間記住上次進度的設定：
  - 策略：選擇下列其中一項策略，並設定必要欄位：
    - 無：擷取所有可用資料，不追蹤各週期的進度。
    - 最新時間戳記：追蹤最新記錄的時間戳記。輸入「Checkpoint value JSON path」(檢查點值 JSON 路徑) (例如 timestamp 或 event_time) 和「Checkpoint variable」(檢查點變數) (例如 last_run_time，在後續輪詢中參照為 {{.last_run_time}})。
    - 最新記錄：追蹤最高記錄 ID，只擷取新記錄。輸入「Checkpoint value JSON path」(檢查點值 JSON 路徑) (例如 id 或 event_id) 和「Checkpoint variable」(檢查點變數) (例如 last_id，參照為 {{.last_id}})。
    - 疊代器權杖：使用 API 提供的永久接續權杖。輸入「Checkpoint value JSON path」(檢查點值 JSON 路徑) 和「Checkpoint variable」(檢查點變數) (例如 iterator_token，參照為 {{.iterator_token}})。
8. 在「Response Mapping」(回應對應) 下方，提供規則，指示平台如何找出及擷取記錄：
  - 目標資料 JSON 路徑：輸入 API 回應酬載中目標記錄項目清單所在的確切路徑。如果是物件包裝的陣列 (例如 {"items": [...]})，請輸入 items。如果 API 直接傳回根 JSON 陣列 (例如 [{...}, {...}])，請將這個欄位留空 ([])。
如果選取「List & Detail (Parent-Child)」(清單與詳細資料 (上層/子項))，請執行下列操作：
1. 上層要求 (探索)：設定要傳回項目清單的端點：
  1. 在「API 端點」下方，設定下列參數，定義要求的技術路徑和頻率調節：
    - 端點路徑：附加至基準網址的特定 API 路徑 (例如 /api/v1/auditevents)，用於定義要查詢的確切遙測資源。
    - HTTP 方法：選取「GET」，即可使用網址查詢參數擷取資料；選取「POST」，則可提交搜尋酬載或篩選主體。
    - 要求主體：如果是 POST 要求，請提供 JSON 資料酬載。您可以嵌入動態查核點變數，例如 {"limit": 100, "start_time": "{{.last_timestamp}}"}。
  2. 每分鐘要求數上限：輸入每分鐘可傳送的要求數上限。這是用戶端頻率限制器，用於遵守供應商 API 頻率限制 (預設：5 RPM = 每 12 秒 1 個要求)。這項設定可避免在多頁分頁期間耗盡配額。
  3. 選用：在「自訂標頭」下方，設定「標頭名稱」和「值」，然後按一下「新增」，定義目標 API 所需的特殊 HTTP 標頭 (例如 Content-Type: application/json, Accept: application/json)。
  4. 選用：在「查詢參數」下方，設定「鍵」和「值」，然後按一下「新增」，指定要附加至網址查詢字串的其他篩選器或選項 (例如 count=1000、status=active)，或繫結動態範本變數 (例如 start={{.last_run_time}})。
  5. 在「Pagination strategy:」(分頁策略：) 下方，選取第三方 API 處理多頁結果集所需的分頁機制，然後設定必要欄位：
    - 無：在單一要求中擷取資料，不分頁。
    - 權杖分頁：使用權杖 (自訂索引鍵) 取得下一頁。輸入「下一頁權杖 JSON 路徑」 (例如 meta.next_cursor) 和「權杖分頁查詢參數名稱」 (例如 cursor)。
    - 連結分頁：按照回應中提供的網址取得更多資料。輸入下一頁連結 JSON 路徑 (例如 links.next 或 @odata.nextLink)。
    - 偏移分頁：略過特定數量的記錄，取得下一組記錄。輸入偏移查詢參數名稱 (例如 offset)。
    - 頁碼分頁：前往下一個頁碼。輸入頁碼查詢參數名稱 (例如 page)。
  6. 在「Checkpointing」(檢查點) 下方，設定連接器在週期性輪詢週期之間記住上次中斷位置的設定：
    - 策略：選擇下列其中一項策略，並設定必要欄位：
      - 無：擷取所有可用資料，不追蹤各週期的進度。
      - 最新時間戳記：追蹤最新記錄的時間戳記。輸入「Checkpoint value JSON path」(檢查點值 JSON 路徑) (例如 timestamp 或 event_time) 和「Checkpoint variable」(檢查點變數) (例如 last_run_time，在後續輪詢中參照為 {{.last_run_time}})。
      - 最新記錄：追蹤最高記錄 ID，只擷取新記錄。輸入「Checkpoint value JSON path」(檢查點值 JSON 路徑) (例如 id 或 event_id) 和「Checkpoint variable」(檢查點變數) (例如 last_id，參照為 {{.last_id}})。
      - 疊代器權杖：使用 API 提供的永久接續權杖。輸入「Checkpoint value JSON path」(檢查點值 JSON 路徑) 和「Checkpoint variable」(檢查點變數) (例如 iterator_token，參照為 {{.iterator_token}})。
2. 資料擷取 (橋梁)：設定下列項目：
  - 項目 ID JSON 路徑：父項回應中可唯一識別個別實體的特定欄位 (例如 id 或 zone_id)。連接器會從父項陣列中的每個項目擷取這個 ID。
  - 範本變數名稱：指定自訂變數名稱，用於保存擷取的 ID (例如 zone_id)。使用者介面會顯示動態徽章：在下方的子請求中使用 {{.zone_id}}。
3. 子項要求 (詳細資料)：設定要傳回各項目詳細記錄的端點：
  1. 在「API 端點」下方，設定下列參數，定義要求的技術路徑和頻率調節：
    - 端點路徑：附加至基準網址的特定 API 路徑 (例如 /client/v4/zones/{{.zone_id}}/logs/received)，用於定義要查詢的確切遙測資源。
    - HTTP 方法：選取「GET」，即可使用網址查詢參數擷取資料；選取「POST」，則可提交搜尋酬載或篩選主體。
    - 要求主體：如果是 POST 要求，請提供 JSON 資料酬載。您可以嵌入動態查核點變數，例如 {"limit": 100, "start_time": "{{.last_timestamp}}"}。
  2. 每分鐘要求數上限：輸入每分鐘可傳送的要求數上限。這是用戶端頻率限制器，用於遵守供應商 API 頻率限制 (預設：5 RPM = 每 12 秒 1 個要求)。這項設定可避免在多頁分頁期間耗盡配額。
  3. 選用：在「自訂標頭」下方，設定「標頭名稱」和「值」，然後按一下「新增」，定義目標 API 所需的特殊 HTTP 標頭 (例如 Content-Type: application/json, Accept: application/json)。
  4. 選用：在「查詢參數」下方，設定「鍵」和「值」，然後按一下「新增」，指定要附加至網址查詢字串的其他篩選器或選項 (例如 count=1000、status=active)，或繫結動態範本變數 (例如 start={{.last_run_time}})。
  5. 在「Pagination strategy:」(分頁策略：) 下方，選取第三方 API 處理多頁結果集所需的分頁機制，然後設定必要欄位：
    - 無：在單一要求中擷取資料，不分頁。
    - 權杖分頁：使用權杖 (自訂索引鍵) 取得下一頁。輸入「下一頁權杖 JSON 路徑」 (例如 meta.next_cursor) 和「權杖分頁查詢參數名稱」 (例如 cursor)。
    - 連結分頁：按照回應中提供的網址取得更多資料。輸入下一頁連結 JSON 路徑 (例如 links.next 或 @odata.nextLink)。
    - 偏移分頁：略過特定數量的記錄，取得下一組記錄。輸入偏移查詢參數名稱 (例如 offset)。
    - 頁碼分頁：前往下一個頁碼。輸入頁碼查詢參數名稱 (例如 page)。
  6. 在「Checkpointing」(檢查點) 下方，設定連接器在週期性輪詢週期之間記住上次中斷位置的設定：
    - 策略：選擇下列其中一項策略，並設定必要欄位：
      - 無：擷取所有可用資料，不追蹤各週期的進度。
      - 最新時間戳記：追蹤最新記錄的時間戳記。輸入「Checkpoint value JSON path」(檢查點值 JSON 路徑) (例如 timestamp 或 event_time) 和「Checkpoint variable」(檢查點變數) (例如 last_run_time，在後續輪詢中參照為 {{.last_run_time}})。
進行下列「Scheduling & Labels」(排程和標籤) 設定：
- 輪詢頻率：選取標準間隔 (例如 5m、1h)。
- 命名空間：選用的機構標記。
- 擷取標籤：資料 RBAC 的鍵/值組合。
按一下「提交」。Google SecOps 會自動檢查憑證和端點驗證。如果驗證成功，動態饋給就會開始輪詢。

設定範例 1：1Password 稽核事件 (標準 API (依序) 模型)

下列宣告式 JSON 設定示範了標準 API (依序) 模型，並使用游標式檢查點功能，為 1Password 建立檢查點：

{
  "base_url": "https://events.1password.com",
  "polling_frequency": 15,
  "header_auth": {
    "header_key_values": [
      {
        "key": "Authorization",
        "value": "Bearer <SECRET_STORED_IN_SECRET_MANAGER>"
      }
    ]
  },
  "primary_request": {
    "request_settings": {
      "endpoint_path": "/api/v1/auditevents",
      "http_method": "POST",
      
      "request_body": "{\"limit\": 1000, \"start_time\": \"{{.last_run_time}}\"}",
      
      "custom_headers": [
        {
          "key": "Content-Type",
          "value": "application/json"
        }
      ],
      "max_requests_per_minute": 5
    },
    "pagination_strategy": {
      "token": {
        "next_page_token_json_path": "additional_items_url",
        "query_param": "cursor"
      }
    },
    "checkpointing": {
      "latest_timestamp_strategy": {
        "checkpoint_value_path": "timestamp",
        "checkpoint_variable": "last_run_time"
      }
    },
    "response_mapping": {
      "target_data_path": ["items"]
    }
  }
}

具體設定範例 2：Cloudflare 區域遙測 (清單與詳細資料 (上層/子項) 模型)

下列宣告式 JSON 設定示範 Cloudflare 的清單和詳細資料 (父項-子項) 展開模型：

{
 "base_url": "https://api.cloudflare.com",
 "polling_frequency": 30,
 "header_auth": {
   "header_key_values": [
     {
       "key": "Authorization",
       "value": "Bearer <SECRET_STORED_IN_SECRET_MANAGER>"
     }
   ]
 },

 "primary_request": {
   "request_settings": {
     "endpoint_path": "/client/v4/zones",
     "http_method": "GET"
   },
   "response_mapping": {
     "target_data_path": ["result"]
   },
   "pagination_strategy": {
     "none": {}
   },
   "checkpointing": {
     "none_strategy": {}
   },
   "dependent_requests_config": {
     "item_id_json_path": "id",
     "item_id_variable": "zone_id",
     "dependent_requests": [
       {
         "request_settings": {
           "endpoint_path": "/client/v4/zones/{{.zone_id}}/logs/received",
           "http_method": "GET",
           "query_parameters": [
             {
               "key": "start",
               "value": "{{.last_run_time}}"
             },
             {
               "key": "count",
               "value": "1000"
             }
           ],
           "max_requests_per_minute": 5
         },

         "pagination_strategy": {
           "none": {}
         },
         "checkpointing": {
           "latest_timestamp_strategy": {
             "checkpoint_value_path": "EdgeStartTimestamp",
             "checkpoint_variable": "last_run_time"
           }
         },
         "response_mapping": {
           "target_data_path": []
         }
       }
     ]
   }
 }
}

自訂 API 最佳做法

輪詢頻率指南：
- 一開始先設定適中的輪詢間隔：針對高流量端點，請先將初始輪詢間隔設為 15 分鐘或 30 分鐘，觀察供應商 API 配額行為，再縮短為 5 分鐘。
- 針對大量展開作業進行最佳化：如果父項與子項 (清單和詳細資料) 動態饋給會探索數十或數百項資源，Google 強烈建議您將輪詢頻率設為 30 到 60 分鐘，讓所有子項工作在下一個探索週期開始前，都能順利完成。
驗證擷取路徑：設定狀態檢查點前，請使用供應商說明文件或 API 測試工具，確認時間戳記的確切 JSON 欄位名稱。
分解多子項 API：如果第三方 API 需要擷取單一使用者清單的快訊和稽核記錄，請建立兩個獨立的單子項動態饋給 (一個用於快訊，另一個用於稽核記錄)，以維持最佳隔離效果。

頻率限制和節流防護機制

為避免客戶動態饋給設定超出第三方供應商配額，或壟斷系統資源，自訂 API 動態饋給類型會實施下列自動防護措施：

可設定要求頻率 (頻率限制)：系統會自動調整傳出 HTTP 要求的頻率，避免超過供應商的頻率限制。預設速率為每分鐘 5 個要求 (每 12 秒 1 個要求)。您可以在端點設定中使用「每分鐘要求數上限」欄位，根據供應商發布的 API 配額調整每個端點。
子項要求上限：如果是父項-子項 (清單和詳細資料) 動態饋給，探索要求在每個輪詢週期最多可調度 500 個子項要求。
單層展開深度：連接器會嚴格執行最多 1 層的展開深度 (父項探索 → 子項詳細資料)。不支援巢狀依附要求 (孫項呼叫)。
回應酬載大小上限：任何單一要求或網頁的 HTTP 回應大小上限為 50 MB。如果未分頁的 API 傳回的回應超過 50 MB，擷取作業就會失敗，並顯示資源耗盡錯誤。為避免這種情況，請務必設定分頁查詢參數 (例如 limit 或 page_size)，以較小的批次擷取記錄。
自動 HTTP 429 退避：如果第三方供應商 API 回應 HTTP 429 (要求過多)，Google SecOps 會自動擷取狀態並啟動指數退避期，暫停執行工作，直到供應商配額視窗重新填滿。

自訂 API 限制

規劃擷取路徑時，請注意自訂 API 動態饋給類型有下列限制：

嚴格 JSON 支援：僅支援 JSON API 回應。不支援 XML、CSV、Parquet 和 Avro 等其他格式。
不支援動態要求簽署：不支援每個要求都需要動態加密編譯簽章的 API (例如 AWS SigV4、Akamai 或 Oracle OCI)。
不支援多步驟驗證：如果 API 需要先透過程式輔助登入呼叫，交換憑證以取得臨時工作階段符記 (例如 Saviynt)，才能進行輪詢，則不支援。
不支援 WebSockets 或推送擷取：自訂 API 動態饋給支援標準 HTTPS 提取輪詢。不支援永久串流連線 (WebSocket) 和傳入 Webhook。
不支援相互傳輸層安全標準 (mTLS)：驗證必須仰賴 API 金鑰、基本驗證或標準 OAuth 2.0 用戶端憑證。不支援用戶端憑證交握。

排解自訂 API 動態饋給問題

如要在 Cloud Logging 記錄檔探索工具中調查自訂 API 動態饋給的錯誤，請使用下列查詢：

resource.type="gce_instance" OR resource.type="generic_task"
jsonPayload.service="gopher"
jsonPayload.feed_id="FEED_ID"

將 FEED_ID 替換為動態饋給 ID。

如要專門篩選失敗的 HTTP 要求，請使用下列查詢：

jsonPayload.service="gopher"
jsonPayload.feed_id="FEED_ID"
jsonPayload.http_status_code >= 400

將 FEED_ID 替換為動態饋給 ID。

常見失敗模式和解決方案

問題 / 錯誤	根本原因	解決方案 / 補救措施
HTTP 401 未經授權 / HTTP 403 禁止存取	API 金鑰、密碼或 OAuth 憑證已過期或無效。	編輯動態饋給，重新輸入有效的憑證，然後按一下「提交」。
HTTP 404 找不到網頁	基準網址或端點路徑範本不正確。	查看供應商 API 說明文件中的端點。請確認基準網址結尾乾淨，且端點路徑開頭為「/」。
HTTP 429 要求過多	超過供應商 API 頻率限制。	請提高輪詢頻率，或減少查詢參數中的 `limit` 參數。
JSON 擷取錯誤 (items_path 為空白)	回應設定路徑不符。	請驗證 API 回應酬載結構，並更新目標資料 JSON 路徑。
重複擷取資料	狀態設定時間戳記或 ID 擷取器路徑無效。	檢查記錄欄位名稱的時間戳記，並更新擷取器路徑。

管理動態饋給

設定資料動態饋給後，請使用管理工具監控擷取健康狀態、修改現有參數，以及管理動態饋給生命週期。本節將說明如何解讀動態饋給狀態，以及執行必要的維護工作，確保資料持續顯示。

「動態饋給」頁面提供多項工具，可協助您瀏覽及整理已設定的動態饋給清單：

搜尋：使用搜尋列，依「動態饋給名稱」、「動態饋給 ID」或「來源類型」尋找動態饋給。
篩選：按一下篩選器圖示，根據特定動態饋給屬性縮小清單範圍。
下載 CSV：按一下「下載為 CSV」，將目前的動態饋給清單匯出為 CSV 檔案。
分頁：使用分頁控制項執行下列操作：
- 變更「每頁列數」。
- 使用頁面分頁和箭頭，瀏覽多個動態饋給頁面。
上次重新整理時間：查看時間戳記，瞭解動態饋給清單上次更新的時間。

查看已設定的動態饋給

「Feeds」(動態饋給) 頁面會顯示您設定的所有動態饋給。

依序前往 「SIEM 設定」 > 「動態饋給」。主頁面會顯示所有已設定的動態饋給。
將游標懸停在各列上，即可顯示「更多」選單圖示 more_vert 。
你可以在選單中查看動態饋給詳細資料，以及編輯、停用或刪除動態饋給。

監控動態饋給狀態

您可以在初始「動態饋給」頁面監控動態饋給狀態，動態饋給可能會有下列狀態：

Active：動態饋給已設定完成，可將資料擷取至 Google SecOps 帳戶。
InProgress：Google SecOps 嘗試從設定的第三方提取資料。
已完成：這則動態饋給已成功擷取資料。
已封存：已停用動態饋給。
失敗：動態饋給無法成功擷取資料。這可能是設定問題所致。按一下問題即可顯示設定錯誤。修正錯誤並重新提交動態饋給後，請返回「動態饋給」頁面，確認動態饋給是否正常運作。

注意： 「動態饋給」頁面的「上次成功時間」欄會顯示該動態饋給上次成功擷取資料的時間。如果是新動態饋給，這個欄位會留空。 Webhook 和 Google Cloud pubsub 等推送動態饋給不會填入這個資料欄。這類推送動態饋給沒有時間表，也就是說，資料會在推送時傳入。如果是 Amazon SQS (V2) 動態饋給，「上次成功時間」欄會顯示有效的擷取活動訊號時間戳記。系統會限制這一欄的更新頻率，最多可能延遲 15 分鐘。

編輯現有動態饋給

在「Feeds」(動態饋給) 頁面中，您可以按照下列步驟編輯現有動態饋給：

將游標懸停在現有動態饋給上，然後按一下右側欄中的 more_vert。
按一下「編輯動態饋給」。您現在可以修改動態饋給的輸入參數，並重新提交至 Google SecOps，系統會嘗試使用更新後的動態饋給。

注意： 現有動態饋給在「動態饋給」頁面中會顯示「[未設定]」做為動態饋給名稱。編輯動態饋給，新增動態饋給名稱。

啟用 (恢復) 和停用 (暫停) 動態饋給

停用動態饋給後，Google SecOps 就會停止從該來源擷取新資料。如要立即停止擷取資料，請刪除動態饋給。現有或受限的移轉作業會繼續執行，直到完成為止。重新啟用動態饋給後，Google SecOps 就能擷取停用期間遺漏的資料。這項功能稱為「回填能力」。

在「狀態」欄中，已啟用的動態饋給會標示為「有效」、「進行中」、「已完成」或「失敗」。停用的欄位會標示為「已封存」。如需說明，請參閱「監控動態饋給狀態」。

在「動態饋給」頁面，您可以啟用 (繼續) 或停用 (暫停) 任何現有的動態饋給：

將游標懸停在現有動態饋給上，然後按一下右側欄中的 more_vert。
選用：按一下「啟用動態饋給」切換鈕，啟用動態饋給。
選用：按一下「停用動態饋給」切換鈕，即可停用動態饋給。動態饋給現在會標示為「已封存」。

重新啟用動態饋給時復原資料 (回填功能)

Google SecOps 能否回填資料，取決於動態饋給是提取式 (支援) 還是推送式 (不支援)。

提取式動態饋給

Google SecOps 會透過這些動態饋給，從外部來源提取資料。提取動態饋給包括：

雲端儲存空間 bucket，例如 Amazon S3、 Google Cloud Storage、Azure Blob Storage
安全檔案傳輸通訊協定伺服器
第三方 API，例如 Microsoft 365、Okta、Proofpoint

重新啟用提取式動態饋給後，Google SecOps 就能擷取動態饋給停用期間產生的資料。

推送式動態饋給

外部系統會透過這些動態饋給，將資料「推送」至 Google SecOps。推送動態饋給包括：

HTTPS Webhook
Google Cloud Pub/Sub
Amazon Kinesis Data Firehose
直接 API/代理程式擷取，例如 Bindplane

Google SecOps 無法自動從推送式動態饋給啟動資料補充作業。如果動態饋給已停用，但系統仍推送資料，Google SecOps 會傳送 HTTP 403 Forbidden 錯誤或一般 4xx 錯誤。

如果系統未儲存資料並重試傳送至 Google SecOps，資料就會遺失。此外，如果系統設為「失敗時捨棄」或清除緩衝區，則該時段的資料會永久遺失。為避免資料遺失，請設定系統，在動態饋給重新啟用後緩衝並重新傳送資料。Google SecOps 就能在動態饋給恢復時，擷取遺漏的資料。

補充資料注意事項

來源系統限制：Google SecOps 可從提取式動態饋給回填的歷來資料量，取決於來源系統保留資料的時間長度，以及 API 允許的範圍。舉例來說，部分 API 只能存取過去七天的資料。
Google SecOps 緩衝區：Google SecOps 的提取式動態饋給內部緩衝區會保留資料最多 90 天，以便自動復原，之後就會捨棄資料。
租戶限制：非付費租戶 (例如概念驗證) 可能無法回填舊資料。
擷取配額：為避免影響即時資料擷取，回填資料的處理優先順序低於即時資料。提取式資料補充作業也設有頻率限制，通常是租戶每種記錄類型 burst 限制的三分之一 (33%)。這可確保重要的推送式動態饋給 (例如 EDR 代理程式) 不會受到負面影響。
動態頻率限制：如果補充作業用盡所有可用的提取配額，系統會暫停擷取資料，直到五分鐘間隔結束，並在間隔重新開始時自動恢復。
雲端儲存空間：你可以使用動態饋給設定控管補充資料，例如篩選新檔案或更新檔案，或篩選日期範圍，例如「檔案存在時間上限」。
大量待處理項目：如果重新啟用後，提取式動態饋給的大量待處理項目造成問題，請與 Google 支援團隊聯絡，要求清除待處理項目。也就是說，動態饋給只會開始擷取新資料，不會回填遺漏的資料。
編輯已停用的動態饋給：在動態饋給停用期間，對其進行的任何設定變更，都會在動態饋給重新啟用後立即生效。

刪除動態

在「動態饋給」頁面中，你也可以刪除現有的動態饋給：

將游標懸停在現有動態饋給上，然後按一下右側欄中的 more_vert。
按一下「刪除動態饋給」。「刪除動態饋給」視窗隨即開啟。如要永久刪除動態饋給，請按一下「是，刪除」。

注意： 刪除動態饋給後，系統就不會擷取新資料。佇列中可能已有資料，系統仍會處理這些資料。

如果是自訂 API 動態饋給，系統會顯示對話方塊視窗，其中包含選用的核取方塊：「刪除待處理的待辦資料」：

取消勾選 (預設)：刪除動態饋給設定和憑證，但允許處理佇列中的待處理資料，直到擷取完成。
勾選：動態饋給設定、憑證和所有待處理的待處理資料都會永久移除。

控管擷取速率

當租戶的資料擷取率達到特定門檻時，Google Security Operations 會限制新資料動態饋給的擷取率，避免擷取率高的來源影響其他資料來源的擷取率。在這種情況下，資料會延遲，但不會遺失。門檻取決於擷取量和租戶的使用記錄。

如要申請提高頻率限制，請與 Cloud Customer Care 聯絡。

排解動態饋給失敗問題

在「Feeds」(動態饋給) 頁面中，您可以查看現有動態饋給的詳細資料，例如來源類型、記錄類型、動態饋給 ID 和狀態，如下所示：
1. 將游標懸停在現有動態饋給上，然後按一下右側欄中的 more_vert。
2. 按一下「查看動態饋給」。系統隨即會顯示對話方塊，其中包含動態饋給詳細資料。如果動態饋給失敗，您可以在「Details」(詳細資料) >「Status」(狀態) 下方找到錯誤詳細資料。
如果動態饋給失敗，詳細資料會包含錯誤原因和修正步驟。
請參閱「來源和擷取錯誤」表格，瞭解使用資料動態饋給時可能遇到的錯誤訊息。
如要詳細分析及排解動態饋給活動問題，請前往 Cloud Logging 查看記錄。請參閱「使用 Cloud Logging 分析動態饋給活動」。
Generic::failed_precondition 錯誤：

錯誤：Generic::failed_precondition: include_prefixes is not enabled for this customer

如果儲存 STS 動態饋給時，「包含前置字元」 (include_prefixes) 欄位有值，但 Google SecOps 租戶不在前置字元篩選許可清單中，就會發生這項錯誤。

如要解決這個錯誤，請執行下列任一操作：
1. 從「包含前置字元」 (include_prefixes) 欄位中移除所有前置字元，然後再次儲存動態饋給，即可擷取整個值區或容器。
2. 請與 Google Cloud 帳戶團隊、客戶技術顧問 (TAM) 或 Cloud Customer Care 聯絡，要求為租戶啟用include_prefixes (enable_feed_include_prefixes) 功能。詳情請參閱「在 STS 動態饋給中依前置字串篩選物件」。

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