收集自訂應用程式存取記錄

支援的國家/地區：

Google SecOps SIEM

注意： 這項功能受《Google Security Operations 服務專屬條款》的《正式發布前產品條款》規範。正式發布前的功能或許只提供部分支援，而且這類功能的變更可能與其他正式發布前版本不相容。詳情請參閱《Google SecOps 技術支援服務指南》和《Google SecOps 服務專屬條款》。

本文說明如何使用雲端儲存空間或串流擷取方法，將自訂應用程式存取記錄檔擷取至 Google Security Operations。

自訂應用程式存取記錄會擷取專屬或自建應用程式的驗證事件、授權決策和存取模式。這些記錄對於監控使用者活動、偵測未經授權的存取嘗試，以及維持安全政策的法規遵循狀態至關重要。

事前準備

請確認您已完成下列事前準備事項：

• Google SecOps 執行個體
• JSON、CSV 或結構化文字格式的自訂應用程式存取記錄
• 存取下列其中一項：
  • Google Cloud Storage bucket (適用於 GCS 擷取作業)
  • Amazon S3 儲存桶 (適用於 S3 擷取)
  • Microsoft Azure 儲存體帳戶 (用於 Azure Blob 擷取)
  • Webhook 端點功能 (適用於以推送為基礎的擷取作業)
  • Amazon Kinesis Data Firehose (用於串流擷取)

建立自訂記錄類型

Google SecOps 中沒有預建的「CUSTOM_APPLICATION_ACCESS」記錄類型剖析器。您必須先建立自訂記錄類型，才能擷取記錄。

1. 依序前往「SIEM 設定」>「可用記錄類型」。
2. 按一下「要求記錄類型」。
3. 在「自行建立記錄類型」下方，輸入下列詳細資料：
   • 供應商/產品：輸入 Custom Application Access Logs
   • 記錄類型：輸入 CUSTOM_APPLICATION_ACCESS

4. 按一下「建立記錄類型」。

   注意： 系統會自動在記錄類型中加入 _CUSTOM 後置字元，產生 CUSTOM_APPLICATION_ACCESS_CUSTOM。

5. 請等待 10 分鐘，確保所有元件都提供新的記錄類型，再建立動態消息。

選擇擷取方法

選取最適合您基礎架構的擷取方法：

• Google Cloud Storage (GCS)：如果應用程式會將記錄寫入 GCS bucket，或您可以將記錄匯出至 GCS，請使用這項服務
• Amazon S3：如果應用程式會將記錄寫入 S3 儲存空間，或您可以將記錄匯出至 S3，請使用這個選項
• Azure Blob 儲存體：如果應用程式會將記錄寫入 Azure 儲存體，或您可以將記錄匯出至 Azure，請使用這個選項
• Webhook：如果應用程式可以將 HTTP POST 要求傳送至外部端點，請使用這個選項
• Amazon Kinesis Data Firehose：如果應用程式會寫入 CloudWatch Logs，或需要即時串流，請使用這項服務

選項 1：從 Google Cloud Storage 擷取

建立 Google Cloud Storage 值區

1. 前往 Google Cloud Console。
2. 選取專案或建立新專案。
3. 在導覽選單中，依序前往「Cloud Storage」>「Bucket」。
4. 按一下「建立值區」。

5. 請提供下列設定詳細資料：

   設定	值
   為 bucket 命名	輸入全域不重複的名稱 (例如 custom-app-access-logs)
   位置類型	根據需求選擇 (區域、雙區域、多區域)
   位置	選取位置 (例如 us-central1)
   儲存空間級別	標準 (建議用於經常存取的記錄)
   存取控管	統一 (建議)
   保護工具	選用：啟用物件版本管理或保留政策

6. 點選「建立」。

設定應用程式，將記錄檔寫入 GCS

設定自訂應用程式，將存取記錄寫入您建立的 GCS bucket。記錄應採用下列其中一種格式：

• JSON 格式 (建議)：

  {"timestamp": "2025-01-15T10:30:00Z", "user": "[e-mail]", "action": "login", "result": "success", "source_ip": "203.0.113.45", "application": "custom-app", "resource": "/api/users"}
  

• CSV 格式：

  timestamp,user,action,result,source_ip,application,resource
  2025-01-15T10:30:00Z,[e-mail],login,success,203.0.113.45,custom-app,/api/users
  

• 以換行符號分隔的 JSON (NDJSON)：

  {"timestamp": "2025-01-15T10:30:00Z", "user": "[e-mail]", "action": "login", "result": "success"}
  {"timestamp": "2025-01-15T10:30:05Z", "user": "[e-mail]", "action": "access", "result": "denied"}
  

擷取 Google SecOps 服務帳戶

Google SecOps 會使用專屬服務帳戶，從 GCS bucket 讀取資料。您必須授予這個服務帳戶值區存取權。

1. 依序前往「SIEM 設定」>「動態饋給」。
2. 按一下「新增動態消息」。
3. 按一下「設定單一動態饋給」。
4. 在「動態饋給名稱」欄位中輸入動態饋給名稱 (例如 Custom Application Access Logs - GCS)。
5. 選取「Google Cloud Storage V2」做為「來源類型」。
6. 選取「CUSTOM_APPLICATION_ACCESS_CUSTOM」做為「記錄類型」。
7. 按一下「取得服務帳戶」。

8. 系統會顯示不重複的服務帳戶電子郵件地址，例如：

   [e-mail]
   

9. 複製這個電子郵件地址，以便在下一步中使用。

   注意： 每個 Google SecOps 執行個體都有專屬的服務帳戶。請勿使用其他說明文件或範例中的服務帳戶。

將 IAM 權限授予 Google SecOps 服務帳戶

Google SecOps 服務帳戶需要 GCS bucket 的「Storage 物件檢視者」角色。

1. 依序前往「Cloud Storage」>「Buckets」。
2. 按一下 bucket 名稱。
3. 前往「權限」分頁標籤。
4. 按一下「授予存取權」。
5. 請提供下列設定詳細資料：
   • 新增主體：貼上 Google SecOps 服務帳戶電子郵件地址
   • 指派角色：選取「Storage 物件檢視者」

6. 按一下 [儲存]。

   注意： 如果您打算使用「刪除已轉移的檔案」或「刪除已轉移的檔案和空白目錄」刪除選項，請授予 Storage 物件管理員角色，而非 Storage 物件檢視者。

在 Google SecOps 中設定動態饋給

1. 返回動態消息建立頁面 (或依序前往「SIEM 設定」>「動態消息」>「新增動態消息」)。
2. 點選「下一步」。

3. 指定下列輸入參數的值：

   • 儲存空間 bucket URL：輸入 GCS bucket URI，並加上前置路徑：

     gs://custom-app-access-logs/
     

     注意： 請務必在 URI 結尾加上尾端斜線 (/)。如果記錄檔位於子目錄中，請加入路徑 (例如 gs://custom-app-access-logs/access-logs/)。

   • 來源刪除選項：根據偏好設定選取刪除選項：

     • 永不：移轉後一律不刪除任何檔案 (建議用於測試)。
     • 刪除已轉移的檔案：成功轉移檔案後刪除檔案。
     • 刪除已轉移的檔案和空白目錄：成功轉移檔案後，刪除檔案和空白目錄。

   • 檔案存在時間上限：包含在過去天數內修改的檔案 (預設為 180 天)。

   • 資產命名空間：資產命名空間。

   • 擷取標籤：要套用至這個動態饋給事件的標籤 (例如 custom_app_access)。

4. 點選「下一步」。

5. 在「Finalize」(完成) 畫面中檢查新的動態饋給設定，然後按一下「Submit」(提交)。

方法 2：從 Amazon S3 擷取

建立 Amazon S3 儲存貯體

1. 開啟 Amazon S3 控制台。
2. 按一下「建立值區」。
3. 請提供下列設定詳細資料：
   • Bucket Name：輸入 bucket 的名稱 (例如 custom-app-access-logs)。
   • 區域：選取應用程式執行的區域 (例如 us-east-1)。
4. 點選「建立」。

建立具有 S3 存取權的 IAM 使用者

1. 開啟 IAM console。
2. 依序點選「使用者」>「新增使用者」。
3. 輸入使用者名稱 (例如 chronicle-s3-reader)。
4. 選取「程式輔助存取」。
5. 點選 [Next: Permissions] (下一步：權限)。
6. 選擇「Attach existing policies directly」。
7. 搜尋並選取 AmazonS3FullAccess 政策。
8. 按一下「下一步：代碼」。
9. 按一下 [下一步：檢閱]。
10. 按一下「建立使用者」。
11. 按一下「Download .csv file」(下載 .csv 檔案)，儲存「Access Key」(存取金鑰) 和「Secret Access Key」(私密存取金鑰)，以供日後參考。
12. 按一下 [關閉]。

設定應用程式，將記錄寫入 S3

設定自訂應用程式，將存取記錄寫入您建立的 S3 bucket。使用與 GCS 區段所述相同的記錄格式 (JSON、CSV 或 NDJSON)。

在 Google SecOps 中設定動態消息，從 S3 擷取記錄檔

1. 依序前往「SIEM 設定」>「動態饋給」。
2. 按一下「新增動態消息」。
3. 按一下「設定單一動態饋給」。
4. 在「動態饋給名稱」欄位中輸入動態饋給名稱 (例如 Custom Application Access Logs - S3)。
5. 選取「Amazon S3 V2」做為「來源類型」。
6. 選取「CUSTOM_APPLICATION_ACCESS_CUSTOM」做為「記錄類型」。
7. 依序點按「繼續」和「提交」。

8. 指定下列輸入參數的值：

   • S3 URI：輸入 bucket URI，格式如下：

     s3://custom-app-access-logs/
     

     注意： 請在 S3 URI 結尾加上尾端斜線 (/)。

   • 來源刪除選項：根據偏好設定選取刪除選項。

   • 檔案存在時間上限：包含在過去天數內修改的檔案 (預設為 180 天)。

   • 存取金鑰 ID：具有 S3 值區存取權的使用者存取金鑰。

   • 存取密鑰：具有 S3 bucket 存取權的使用者私密金鑰。

   • 資產命名空間：資產命名空間。

   • 擷取標籤：要套用至這個動態饋給事件的標籤 (例如 custom_app_access)。

9. 依序點按「繼續」和「提交」。

選項 3：從 Azure Blob 儲存體擷取資料

建立 Azure 儲存體帳戶

1. 在 Azure 入口網站中，搜尋「儲存體帳戶」。
2. 點選「+ 建立」。

3. 請提供下列設定詳細資料：

   設定	值
   訂閱項目	選取 Azure 訂閱項目
   資源群組	選取現有項目或建立新項目
   儲存體帳戶名稱	輸入不重複的名稱 (例如 customappaccesslogs)
   區域	選取區域 (例如 East US)
   效能	標準 (建議)
   備援功能	LRS (本地備援儲存體)

4. 按一下「Review + create」。

5. 查看帳戶總覽，然後按一下「建立」。

6. 等待部署作業完成。

取得儲存空間帳戶憑證

1. 前往您剛建立的「儲存空間帳戶」。
2. 在左側導覽中，選取「Security + networking」(安全性 + 網路) 下方的「Access keys」(存取金鑰)。
3. 按一下「顯示金鑰」。
4. 複製並儲存下列項目，以供日後使用：
   • 儲存體帳戶名稱：customappaccesslogs
   • 金鑰 1 或金鑰 2：共用存取金鑰

建立 Blob 容器

1. 在同一個儲存空間帳戶中，選取左側導覽列的「容器」。
2. 按一下「+ 容器」。
3. 請提供下列設定詳細資料：
   • 「Name」(名稱)：輸入 access-logs
   • 公開存取層級：選取「私人 (不允許匿名存取)」
4. 點選「建立」。

設定應用程式，將記錄檔寫入 Azure Blob 儲存體

設定自訂應用程式，將存取記錄寫入您建立的 Azure Blob 儲存體容器。使用與 GCS 區段所述相同的記錄格式 (JSON、CSV 或 NDJSON)。

在 Google SecOps 中設定資訊提供，從 Azure 擷取記錄

1. 依序前往「SIEM 設定」>「動態饋給」。
2. 按一下「新增動態消息」。
3. 按一下「設定單一動態饋給」。
4. 在「動態饋給名稱」欄位中輸入動態饋給名稱 (例如 Custom Application Access Logs - Azure)。
5. 選取「Microsoft Azure Blob Storage V2」做為「來源類型」。
6. 選取「CUSTOM_APPLICATION_ACCESS_CUSTOM」做為「記錄類型」。
7. 點選「下一步」。

8. 指定下列輸入參數的值：

   • Azure URI：輸入 Blob 服務端點網址和容器路徑：

     https://customappaccesslogs.blob.core.windows.net/access-logs/
     

     注意： 請在 URI 結尾加上尾端斜線 (/)。

   • 來源刪除選項：根據偏好設定選取刪除選項

   • 檔案存在時間上限：包含在過去天數內修改的檔案 (預設為 180 天)

   • 共用金鑰：輸入從儲存空間帳戶擷取的共用金鑰值 (存取金鑰)

   • 資產命名空間：資產命名空間

   • 擷取標籤：要套用至這個動態饋給中事件的標籤 (例如 custom_app_access)

9. 點選「下一步」。

10. 在「Finalize」(完成) 畫面中檢查新的動態饋給設定，然後按一下「Submit」(提交)。

選項 4：使用 Webhook 擷取

在 Google SecOps 中建立 Webhook 動態饋給

1. 依序前往「SIEM 設定」>「動態饋給」。
2. 按一下「新增動態消息」。
3. 按一下「設定單一動態饋給」。
4. 在「動態饋給名稱」欄位中輸入動態饋給名稱 (例如 Custom Application Access Logs - Webhook)。
5. 選取「Webhook」做為「來源類型」。
6. 選取「CUSTOM_APPLICATION_ACCESS_CUSTOM」做為「記錄類型」。
7. 點選「下一步」。
8. 指定下列輸入參數的值：
   • 分割分隔符：輸入 \n，即可分割以換行符分隔的事件 (如果每個要求傳送多個事件)。
   • 資產命名空間：資產命名空間。
   • 擷取標籤：要套用至這個動態饋給事件的標籤 (例如 custom_app_access)。
9. 點選「下一步」。
10. 在「Finalize」(完成) 畫面中檢查新的動態饋給設定，然後按一下「Submit」(提交)。

產生並儲存密鑰

1. 在動態饋給詳細資料頁面中，按一下「產生密鑰」。
2. 對話方塊會顯示密鑰。

3. 複製並妥善儲存密鑰。

   注意： 密鑰只會顯示一次，之後便無法擷取。如果遺失，就必須產生新的密鑰。

取得動態消息端點網址

1. 前往動態消息的「詳細資料」分頁。
2. 在「端點資訊」部分，複製「動態消息端點網址」。

3. 網址格式為：

   https://malachiteingestion-pa.googleapis.com/v2/unstructuredlogentries:batchCreate
   

4. 請儲存這個網址，以供後續步驟使用。

5. 按一下 [完成]。

建立 Google Cloud API 金鑰

Google SecOps 需要 API 金鑰才能進行驗證。在 Google Cloud 控制台中建立受限制的 API 金鑰。

1. 前往 Google Cloud 控制台的「憑證」頁面。
2. 選取專案 (與 Chronicle 執行個體相關聯的專案)。
3. 依序按一下「建立憑證」>「API 金鑰」。
4. 系統會建立 API 金鑰，並在對話方塊中顯示。
5. 按一下「編輯 API 金鑰」即可限制金鑰。
6. 在「API 金鑰」設定頁面中：
   • 名稱：輸入描述性名稱 (例如 Chronicle Webhook API Key)。
7. 在「API 限制」下方：
   1. 選取「Restrict key」(限制金鑰)。
   2. 在「選取 API」下拉式選單中，搜尋並選取「Google SecOps API」 (或「Chronicle API」)。
8. 按一下 [儲存]。
9. 複製頁面頂端「API key」(API 金鑰) 欄位中的 API 金鑰值。
10. 安全儲存 API 金鑰。

設定應用程式，透過 Webhook 傳送記錄

設定自訂應用程式，將 HTTP POST 要求傳送至 Chronicle Webhook 端點。

• 建構 Webhook 網址：

  1. 在動態消息端點網址中附加 API 金鑰：

     https://malachiteingestion-pa.googleapis.com/v2/unstructuredlogentries:batchCreate?key=<API_KEY>
     

  2. 將 <API_KEY> 替換為您建立的 API 金鑰。

• HTTP POST 要求格式：

  POST https://malachiteingestion-pa.googleapis.com/v2/unstructuredlogentries:batchCreate?key=<API_KEY> HTTP/1.1
  Content-Type: application/json
  x-chronicle-auth: <SECRET_KEY>
  
  {"timestamp": "2025-01-15T10:30:00Z", "user": "[e-mail]", "action": "login", "result": "success", "source_ip": "203.0.113.45"}
  

• 多個事件 (以換行符號分隔)：

  POST https://malachiteingestion-pa.googleapis.com/v2/unstructuredlogentries:batchCreate?key=<API_KEY> HTTP/1.1
  Content-Type: application/json
  x-chronicle-auth: <SECRET_KEY>
  
  {"timestamp": "2025-01-15T10:30:00Z", "user": "[e-mail]", "action": "login", "result": "success"}
  {"timestamp": "2025-01-15T10:30:05Z", "user": "[e-mail]", "action": "access", "result": "denied"}
  

• 使用 curl 的範例：

  curl -X POST \
    "https://malachiteingestion-pa.googleapis.com/v2/unstructuredlogentries:batchCreate?key=YOUR_API_KEY" \
    -H "Content-Type: application/json" \
    -H "x-chronicle-auth: YOUR_SECRET_KEY" \
    -d '{"timestamp": "2025-01-15T10:30:00Z", "user": "[e-mail]", "action": "login", "result": "success", "source_ip": "203.0.113.45"}'
  

方法 5：使用 Amazon Kinesis Data Firehose 擷取資料

在 Google SecOps 中建立動態饋給

1. 依序前往「SIEM 設定」>「動態饋給」。
2. 按一下「新增動態消息」。
3. 按一下「設定單一動態饋給」。
4. 在「動態饋給名稱」欄位中輸入動態饋給名稱 (例如 Custom Application Access Logs - Firehose)。
5. 選取「Amazon Data Firehose」做為「來源類型」。
6. 選取「CUSTOM_APPLICATION_ACCESS_CUSTOM」做為「記錄類型」。
7. 點選「下一步」。
8. 指定下列輸入參數的值：
   • 分割分隔符號：輸入 \n，即可分割以換行符號分隔的記錄。
   • 資產命名空間：資產命名空間。
   • 擷取標籤：要套用至這個動態饋給事件的標籤 (例如 custom_app_access)。
9. 點選「下一步」。
10. 檢查動態饋給設定，然後按一下「提交」。
11. 按一下「產生密鑰」，產生驗證這個動態饋給的密鑰。
12. 複製並儲存密鑰，因為您無法再次查看這組密鑰。
13. 前往「詳細資料」分頁。
14. 從「端點資訊」欄位複製動態消息端點網址。
15. 按一下 [完成]。

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

1. 前往 Google Cloud 控制台的「憑證」頁面：https://console.cloud.google.com/apis/credentials
2. 按一下 [Create credentials] (建立憑證)，然後選取 [API key] (API 金鑰)。
3. 按一下「編輯 API 金鑰」即可限制金鑰。
4. 在「API 限制」下方，選取「限制金鑰」。
5. 搜尋並選取「Google SecOps API」。
6. 按一下 [儲存]。
7. 複製並儲存 API 金鑰。

建構端點網址

1. 以以下格式將 API 金鑰附加至動態饋給端點網址：

   <FEED_ENDPOINT_URL>?key=<API_KEY>
   

2. 更改下列內容：

   • <FEED_ENDPOINT_URL>：上一步中的動態消息端點網址
   • <API_KEY>：上一個步驟中的 API 金鑰

   範例：

   https://malachiteingestion-pa.googleapis.com/v2/unstructuredlogentries:batchCreate?key=AIzaSyD...
   

3. 請儲存這個完整網址，以供下一個步驟使用。

為 Firehose 建立 IAM 政策

1. 在 AWS 控制台中，依序前往「IAM」>「Policies」>「Create policy」>「JSON」分頁。

2. 貼上下列政策 JSON：

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Effect": "Allow",
               "Action": [
                   "firehose:PutRecord",
                   "firehose:PutRecordBatch"
               ],
               "Resource": "arn:aws:firehose:us-east-1:123456789012:deliverystream/CustomAppAccessToChronicle"
           }
       ]
   }
   

3. 更改下列內容：

   • us-east-1：您的 AWS 區域
   • 123456789012：您的 AWS 帳戶 ID (12 位數)
   • CustomAppAccessToChronicle：您的 Firehose 傳送串流名稱 (您會在下一個步驟中建立這個名稱)

4. 將政策命名為 CustomAppAccessFirehoseWritePolicy。

5. 點選「建立政策」。

為 CloudWatch Logs 建立 IAM 角色

1. 依序前往「IAM」>「角色」>「建立角色」。

2. 選取「自訂信任政策」並貼上：

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Effect": "Allow",
               "Principal": {
                   "Service": "logs.us-east-1.amazonaws.com"
               },
               "Action": "sts:AssumeRole"
           }
       ]
   }
   

3. 將 us-east-1 替換為您的 AWS 區域。

4. 點選「下一步」。

5. 搜尋並選取您在上一步建立的政策 CustomAppAccessFirehoseWritePolicy。

6. 點選「下一步」。

7. 將角色命名為 CloudWatchLogsToFirehoseRole。

8. 按一下「建立角色」。

建立 Kinesis Data Firehose 傳送串流

1. 在 AWS 控制台中，依序前往「Kinesis」>「Data Firehose」>「Create delivery stream」。

2. 請提供下列設定詳細資料：

   • 來源和目的地：

     • 來源：選取「直接 PUT 或其他來源」
     • 目的地：選取「HTTP 端點」

   • 傳送串流名稱：

     • 傳送串流名稱：輸入 CustomAppAccessToChronicle

   • HTTP 端點目的地：

     • HTTP 端點網址：輸入您先前建構的完整端點網址 (動態饋給端點 + API 金鑰)
     • 內容編碼：選取 GZIP (建議使用，可節省頻寬)

   • 自訂 HTTP 標頭：

     • 按一下「新增自訂 HTTP 標頭」
     • 標頭名稱：輸入 X-Goog-Chronicle-Auth
     • 標頭值：輸入您在上一個步驟中儲存的密鑰

   • 備份設定：

     • Amazon S3 中的來源記錄備份：選取「僅限失敗的資料」(建議)
     • S3 bucket：選取現有 bucket，或為失敗的記錄建立新 bucket

   • 緩衝區提示：

     • 緩衝區大小：輸入 1 MiB (HTTP 端點的最小值)
     • 緩衝間隔：輸入 60 秒

   • 重試時間長度：

     • 重試時間長度：輸入 300 秒 (5 分鐘)

3. 按一下「建立傳送串流」。

4. 等待傳送串流狀態變更為「有效」 (1 到 2 分鐘)。

設定應用程式，將記錄寫入 CloudWatch Logs

設定自訂應用程式，將存取記錄寫入 CloudWatch Log 群組。接著建立訂閱篩選器，將記錄檔串流至 Firehose。

1. 在 AWS 控制台中，依序前往「CloudWatch」>「Logs」>「Log groups」。
2. 建立新的記錄群組，或選取應用程式寫入記錄的現有群組。
3. 按一下「訂閱篩選器」分頁標籤。
4. 依序按一下「建立」> 建立 Amazon Kinesis Data Firehose 訂閱篩選器。

5. 請提供下列設定詳細資料：

   • 目的地：選取放送串流 CustomAppAccessToChronicle。
   • 授予權限：選取角色 CloudWatchLogsToFirehoseRole。
   • 訂閱項目篩選器名稱：輸入 CustomAppAccessToChronicle。
   • 記錄格式：選取「其他」 (Google SecOps 會處理剖析作業)。
   • 訂閱篩選器模式：留空即可傳送所有事件。

6. 按一下「開始串流播放」。

7. 記錄檔會透過 Firehose 即時串流至 Google SecOps。

建立自訂剖析器

擷取記錄後，您必須建立自訂剖析器，將資料正規化為 UDM 格式。

1. 依序前往「SIEM 設定」>「剖析器」。
2. 按一下「建立剖析器」。
3. 選取「CUSTOM_APPLICATION_ACCESS_CUSTOM」做為「記錄類型」。

4. 使用剖析器編輯器建立 Grok 模式或剖析器擴充功能，將記錄欄位對應至 UDM 欄位。

   剖析器對應範例：

   自訂記錄欄位	UDM 欄位
   timestamp	metadata.event_timestamp
   user	principal.user.email_addresses
   action	security_result.action
   result	security_result.summary
   source_ip	principal.ip
   application	target.application
   resource	target.resource.name

5. 使用範例記錄測試剖析器。

6. 按一下「儲存」，啟用剖析器。

如需詳細的剖析器建立操作說明，請參閱「自助式剖析器選項」。

驗證擷取作業

設定動態饋給和剖析器後，請確認系統是否正在擷取記錄：

1. 依序前往「搜尋」> UDM 搜尋。

2. 執行以下查詢：

   metadata.log_type = "CUSTOM_APPLICATION_ACCESS_CUSTOM"
   

3. 確認搜尋結果中顯示活動。

4. 根據剖析器設定，檢查 UDM 欄位是否已正確填入資料。

UDM 對應表

記錄欄位	UDM 對應	邏輯
	其他	與從服務、env、msg.attachment.fileName、msg.attachment.digest、msg.attachment.key、msg.attachment.authorizeId、msg.attachment.contentType、dest.type、type、msg.sortID、msg.refID、state.reported.applications_installed、state.reported.applications_status、state.reported.ota_queue、state.reported.VICMB_Deg_Battery_LimpHome、state.reported.VICMB_Inhibit_Propulsion、state.reported.VICMB_FA_LostComm_BPCM、state.reported.VICMB_FA_LostComm_SFAM1、state.reported.VICMB_Inhibit_HV、state.reported.VICMB_FA_LostComm_RIDM、state.reported.VICMB_FA_LostComm_RWAM1、state.reported.uname、meta.reported.battery_charging_rate_kw.timestamp、state.reported.battery_charging_rate_kw、meta.reported.cell.connected.timestamp、meta.reported.cell.packet_loss.timestamp、meta.reported.cell.average_ping_ms.timestamp、meta.reported.cell.bitrate.timestamp、meta.reported.cell.download_speed_bytes_per_sec.timestamp、meta.reported.cell.signal_strength.timestamp、meta.reported.cell.signal.timestamp、state.reported.cell.connected、state.reported.cell.packet_loss、state.reported.cell.average_ping_ms、state.reported.cell.bitrate、state.reported.cell.download_speed_bytes_per_sec、state.reported.cell.signal_strength、state.reported.cell.signal 建立的標籤合併。
request_time	metadata.collected_timestamp	使用 ISO8601 格式從 request_time 剖析
msg_1, msg.body	metadata.description	如果 msg_1 不是空白，則為 msg_1 的值，否則為 msg.body
user_id、src_email、otadata.1687965118.initiator	metadata.event_type	如果存在任何 user_id、src_email、otadata.1687965118.initiator，則設為「USER_UNCATEGORIZED」，否則設為「GENERIC_EVENT」
otadata.1687965118.deployment_id	metadata.product_deployment_id	直接複製值
版本	metadata.product_version	直接複製值
response.status	network.http.response_code	已轉換為整數
request_id	principal.resource.product_object_id	直接複製值
msg.attachment.url, otadata.1687965118.download_url	principal.url	如果 msg.attachment.url 不為空白，則為該值，否則為 otadata.1687965118.download_url
src_email、otadata.1687965118.initiator	principal.user.email_addresses	如果與電子郵件規則運算式相符，則為 src_email 中的值，否則為 otadata.1687965118.initiator 中的值
user_id	principal.user.userid	直接複製值
level	security_result.severity	如果層級為「INFO」，請設為「INFORMATIONAL」
	metadata.product_name	設為「自訂應用程式存取權」
	metadata.vendor_name	設為「自訂應用程式存取權」

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