收集 Workday HCM 記錄

支援的國家/地區：

本文說明如何使用 API 將 Workday 記錄擷取至 Google Security Operations。剖析器會從 JSON 格式的記錄檔中擷取 Workday HCM 使用者資料。這項服務會處理各種資料轉換作業，包括重新命名欄位、合併巢狀物件、剖析日期，以及填入使用者屬性、雇用詳細資料和組織結構的 UDM 欄位。此外，還包含處理格式錯誤的 JSON 和缺少重要欄位的錯誤處理機制。

事前準備

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

  • Google SecOps 執行個體。
  • Workday 的特殊存取權。

設定 Workday API 驗證

在 Workday 中建立整合系統使用者 (ISU)

  1. 以管理員權限登入 Workday。
  2. 在搜尋列中輸入 Create Integration System User，然後從搜尋結果中選取所需工作。
  3. 輸入使用者名稱。
  4. 設定密碼。
  5. 將「Session Timeout Minutes」(工作階段逾時分鐘數) 設為 0，避免 ISU 超時。
  6. 啟用「不允許 UI 工作階段」，限制 UI 登入，提升安全性。
  7. 前往「維護密碼規則」工作。
  8. 將整合系統使用者新增至「System Users exempt from password expiration」(免除密碼到期限制的系統使用者) 欄位。

在 Workday 中建立整合安全性群組

  1. 在搜尋列中輸入 Create Security Group，然後從搜尋結果中選取所需工作。
  2. 找出「Type of Tenanted Security Group」(租戶安全群組類型) 欄位，然後選取「Integration System Security Group (Unconstrained)」(整合系統安全群組 (無限制))。
  3. 提供安全群組的「名稱」。
  4. 按一下 [確定]。
  5. 按一下新建立安全性群組的「編輯」。
  6. 將上一個步驟中的「整合系統使用者」指派給安全群組。
  7. 按一下 [完成]。

在 Workday 中授予安全群組網域存取權

  1. 在搜尋列中輸入「Maintain Permissions for Security Group」(維護安全性群組的權限)，然後從結果中選取這項工作。
  2. 從「來源安全群組」清單中選擇您建立的安全群組，即可修改其權限。
  3. 按一下 [確定]。
  4. 依序前往「Maintain Permissions for Security Group」(維護安全性群組的權限) >「Domain Security Policy Permissions」(網域安全性政策權限)。
  5. 為每個網域指派必要權限，例如 GET 作業。
  6. 按一下 [確定]。
  7. 按一下「完成」儲存變更。

在 Workday 中啟用安全性政策變更

  1. 在搜尋列中輸入 Activate Pending Security Policy Changes，然後從搜尋結果中選取所需工作。
  2. 在註解欄位中輸入稽核原因，然後按一下「確定」，開始執行「Activate Pending Security Policy Changes」(啟用待處理的安全政策變更) 工作。
  3. 在下一個畫面中選取「確認」，然後按一下「確定」，即可完成這項工作。

設定整合的 API 用戶端

  1. 在搜尋列中輸入 Register API Client for Integrations，然後選取該字元。
  2. 點選「建立」。
  3. 提供下列設定詳細資料：
    • 用戶端名稱：輸入 API 用戶端的名稱 (例如 Google SecOps Client)。
    • 系統使用者：選取您在上一步建立的「整合系統使用者」。
    • 範圍：選取 HCM API 或包含員工資料和您要存取其他區域的相關範圍。
  4. 選取「儲存」。
  5. 按一下「確定」建立 API 用戶端。
  6. 建立 API 用戶端後，請儲存「用戶端密鑰」。離開頁面後，系統不會再顯示這個權杖。

產生 OAuth 2.0 更新權杖

  1. 在 Workday 搜尋列中輸入 Manage Refresh Tokens for Integrations，然後選取該字元。
  2. 按一下「產生新的重新整理權杖」。
  3. 在「Workday Account」(Workday 帳戶) 欄位中，搜尋並選取您建立的「Integration System User」(整合系統使用者)。
  4. 選取使用者，然後按一下「確定」。
  5. 複製並儲存顯示的更新權杖。

取得 API 端點網址

  1. 在 Workday 搜尋列中輸入 View API Clients，然後選取該字元。
  2. 在「API Clients for Integrations」下方，找出您建立的 Google SecOps Client。
  3. 複製並儲存下列詳細資料：
    • 權杖端點：您將傳送要求以取得存取權杖的 URL。
    • Workday REST API 端點：用於設定與 Google SecOps 整合的 URL。

產生 OAuth 存取權杖

  1. 使用 curl 或類似的 HTTP 用戶端，將 POST 要求傳送至權杖端點：

    curl -X POST "https://{hostname}/ccx/oauth2/token" \
    -d "grant_type=refresh_token" \
    -d "client_id={your_client_id}" \
    -d "client_secret={your_client_secret}" \
    -d "refresh_token={your_refresh_token}"

  2. 這會傳回存取權杖 (例如 "access_token": "abcd1234")

  3. 複製並儲存存取權杖。

設定動態饋給

在 Google SecOps 平台中，有兩種不同的進入點可設定動態饋給：

  • 「SIEM 設定」>「動態消息」
  • 內容中心 > 內容包

依序前往「SIEM 設定」>「動態饋給」，設定動態饋給

如要設定動態消息，請按照下列步驟操作：

  1. 依序前往「SIEM 設定」>「動態消息」。
  2. 按一下「新增動態消息」。
  3. 在下一個頁面中，按一下「設定單一動態饋給」。
  4. 在「動態饋給名稱」欄位中輸入動態饋給名稱 (例如 Workday Logs)。
  5. 選取「第三方 API」做為「來源類型」。
  6. 選取「Workday」Workday記錄類型。
  7. 點選「下一步」。
  8. 指定下列輸入參數的值：
    • API 主機名稱：Workday REST API 端點的網址。
    • 租戶：Workday API 端點的最後一個路徑元素，用於識別執行個體。
    • 存取權杖：OAuth 存取權杖。
  9. 點選「下一步」。
  10. 在「Finalize」畫面中檢查動態饋給設定，然後按一下「Submit」。

從內容中心設定動態饋給

為下列欄位指定值：

  • API 主機名稱：Workday REST API 端點的 FQDN。
  • 租戶：Workday API 端點的最後一個路徑元素，用於識別執行個體。
  • 存取權杖：OAuth 存取權杖。

進階選項

  • 動態饋給名稱：系統預先填入的值，用於識別動態饋給。
  • 來源類型：將記錄收集到 Google SecOps 的方法。
  • 資產命名空間：與動態饋給相關聯的命名空間。
  • 擷取標籤：套用至這個動態饋給所有事件的標籤。

UDM 對應表

記錄欄位 UDM 對應 邏輯
@timestamp read_only_udm.metadata.event_timestamp.seconds 原始記錄的 @timestamp 欄位會重新命名為 timestamp，並剖析為時間戳記 (以秒為單位，自 Epoch 起算)。
businessTitle read_only_udm.entity.entity.user.title 直接從原始記錄中的 businessTitle 欄位對應。
descriptor read_only_udm.entity.entity.user.user_display_name 直接從原始記錄中的 descriptor 欄位對應。
Employee_ID read_only_udm.entity.entity.user.employee_id 直接從原始記錄中的 Employee_ID 欄位對應。
Employee_ID read_only_udm.entity.metadata.product_entity_id 如果沒有 id，則直接從原始記錄中的 Employee_ID 欄位對應。
gopher-supervisor.descriptor read_only_udm.entity.entity.user.managers.user_display_name 直接從原始記錄中的 gopher-supervisor.descriptor 欄位對應，重新命名為 empmanager.user_display_name，然後合併至 managers。
gopher-supervisor.id read_only_udm.entity.entity.user.managers.product_object_id 直接從原始記錄中的 gopher-supervisor.id 欄位對應，重新命名為 empmanager.product_object_id，然後合併至 managers。
gopher-supervisor.primaryWorkEmail read_only_udm.entity.entity.user.managers.email_addresses 直接從原始記錄中的 gopher-supervisor.primaryWorkEmail 欄位對應，然後合併到 managers。
gopher-time-off.date read_only_udm.entity.entity.user.time_off.interval.start_time 從原始記錄的 gopher-time-off 陣列中，剖析為 gopher-time-off.date 欄位中的日期。
gopher-time-off.descriptor read_only_udm.entity.entity.user.time_off.description 直接從原始記錄的 gopher-time-off 陣列中的 gopher-time-off.descriptor 欄位對應。
Hire_Date read_only_udm.entity.entity.user.hire_date 從原始記錄的 Hire_Date 欄位剖析為日期。
id read_only_udm.entity.metadata.product_entity_id 如果原始記錄中存在 id 欄位，系統會直接對應。
Job_Profile read_only_udm.entity.entity.user.title 如果沒有 businessTitle，則直接從原始記錄中的 Job_Profile 欄位對應。
Legal_Name_First_Name read_only_udm.entity.entity.user.first_name 直接從原始記錄中的 Legal_Name_First_Name 欄位對應。
Legal_Name_Last_Name read_only_udm.entity.entity.user.last_name 直接從原始記錄中的 Legal_Name_Last_Name 欄位對應。
location.descriptor read_only_udm.entity.entity.location.city 直接從原始記錄中的 location.descriptor 欄位對應，重新命名為 _location.city，然後再重新命名為 entity.entity.location.city。
primarySupervisoryOrganization.descriptor read_only_udm.entity.entity.user.department 直接從原始記錄中的 primarySupervisoryOrganization.descriptor 欄位對應。
primaryWorkEmail read_only_udm.entity.entity.user.email_addresses 直接從原始記錄中的 primaryWorkEmail 欄位對應。
primaryWorkPhone read_only_udm.entity.entity.user.phone_numbers 直接從原始記錄中的 primaryWorkPhone 欄位對應。
Termination_Date read_only_udm.entity.entity.user.termination_date 從原始記錄的 Termination_Date 欄位剖析為日期。
Work_Email read_only_udm.entity.entity.user.email_addresses 如果沒有 primaryWorkEmail，則直接從原始記錄中的 Work_Email 欄位對應。
collection_time read_only_udm.metadata.event_timestamp.collected_timestamp 記錄的 collection_time 會對應至 collected_timestamp。

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