收集 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. 將「工作階段逾時分鐘」設為 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. 按一下新建安全性群組的「Edit」。
  6. 將先前步驟中的整合系統使用者指派給安全性群組。
  7. 按一下 [完成]。

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

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

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

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

為整合設定 API 用戶端

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

產生 OAuth 2.0 更新權杖

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

取得 API 端點網址

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

產生 OAuth 存取權杖

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

    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 中設定動態饋給，以便擷取 Workday 記錄

  1. 依序前往「SIEM 設定」>「動態饋給」。
  2. 按一下「新增」。
  3. 在「動態饋給名稱」欄位中輸入動態饋給的名稱 (例如 Workday Logs)。
  4. 將「來源類型」設為「第三方 API」。
  5. 選取「Workday」記錄類型。
  6. 點按「Next」。
  7. 指定下列輸入參數的值：
    • API 主機名稱：Workday REST API 端點的網址。
    • Tenant：Workday API 端點的最後一個路徑元素，用於識別您的執行個體。
    • 存取權杖：OAuth 存取權杖。
    • 資產命名空間：資產命名空間。
    • 擷取標籤：套用至這個動態饋給事件的標籤。
  8. 點按「Next」。
  9. 在「Finalize」畫面中查看動態饋給設定，然後按一下「Submit」。

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。

異動

2024-06-25

改善項目：

  • 新增對 UDM 事件的支援
  • 在 href" 上新增 Grok 模式，以便擷取欄位 entity_host_name
  • 已將 entity_host_name 對應至 entity.entity.asset.hostname
  • 已將 href 對應至 entity.entity.url

2024-06-24

改善項目：

  • 新增 CSV 記錄支援功能

2022-09-15

  • 已遷移至預設剖析器

2022-05-11

  • 已遷移至預設剖析器

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