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

剖析器版本：1.0

支援：

Google SecOps SIEM

本文說明如何使用雲端儲存空間或串流擷取方法，將自訂應用程式存取記錄擷取至 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 bucket

1. 前往 Google Cloud 控制台。
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. 按一下「Get Service Account」。

8. 系統會顯示專屬服務帳戶電子郵件地址，例如：

   [e-mail]
   

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

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

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

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

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

6. 按一下 [儲存]。

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

在 Google SecOps 中設定動態饋給

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

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

   • 儲存空間 bucket 網址：輸入 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. 點選「建立 bucket」。
3. 提供下列設定詳細資料：
   • Bucket 名稱：輸入 bucket 的有意義名稱 (例如 custom-app-access-logs)。
   • 區域：選取應用程式執行的區域 (例如 us-east-1)。
4. 點選「建立」。

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

1. 開啟 IAM console。
2. 依序點選「使用者」>「新增使用者」。
3. 輸入使用者名稱 (例如 chronicle-s3-reader)。
4. 選取「程式輔助存取權」。
5. 點選 [Next: Permissions] (下一步：權限)。
6. 選擇「直接附加現有政策」。
7. 搜尋並選取「AmazonS3FullAccess」AmazonS3FullAccess政策。
8. 按一下「Next: Tags」(下一步：標記)。
9. 按一下 [下一步：檢閱]。
10. 點選「Create user」。
11. 按一下「Download .csv file」，儲存「Access Key」和「Secret Access Key」，以供日後參考。
12. 按一下 [關閉]。

將應用程式設為將記錄寫入 S3

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

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

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

產生並儲存密鑰

1. 在動態饋給詳細資料頁面，按一下「產生 Secret Key」。
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 金鑰」欄位複製 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. 在「Feed name」(動態饋給名稱) 欄位中，輸入動態饋給名稱 (例如 Custom Application Access Logs - Firehose)。
5. 「Source type」(來源類型) 請選取「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. 選取「Custom trust policy」，然後貼上以下內容：

   {
       "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
     • 標頭值：輸入您在先前步驟中儲存的密鑰

   • 備份設定：

     • Source record backup in Amazon S3：選取「Failed data only」 (建議)
     • S3 bucket：選取現有 bucket 或建立新 bucket，用於存放失敗記錄

   • 緩衝區提示：

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

   • 重試時間長度：

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

3. 按一下「Create delivery stream」(建立傳遞串流)。

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

設定應用程式寫入 CloudWatch Logs

設定自訂應用程式，將存取記錄寫入 CloudWatch 記錄群組。接著建立訂閱篩選器，將記錄串流至 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 對應	邏輯
	其他	已與下列項目建立的標籤合併：service、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	設為「自訂應用程式存取權」
timestamp	metadata.event_timestamp	從變更記錄對應
level	additional.fields	從變更記錄對應
service	additional.fields	從變更記錄對應
env	additional.fields	從變更記錄對應

變更記錄

查看這個剖析器的變更記錄

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