收集 Cloud Identity 裝置使用者記錄
本文說明如何使用第三方 API 方法 (建議做法),將 Cloud Identity 裝置使用者記錄檔收集到 Google Security Operations。剖析器會先從 JSON 格式的 Cloud Identity Device Users 記錄中擷取資料,然後將時間戳記轉換為標準化格式。然後,系統會將原始記錄資料中的特定欄位,對應至使用者實體、與資產的關係,以及管理和密碼狀態等其他使用者屬性的統一資料模型 (UDM) 欄位。
事前準備
請確認您已完成下列事前準備事項:
- Google SecOps 執行個體
- 服務帳戶的全網域委派設定。服務帳戶必須獲得下列範圍的授權:
https://www.googleapis.com/auth/cloud-identity.devices.readonly
- 您的 Google Cloud 專案已啟用下列 API:
- Cloud Identity API
- Google Workspace Admin SDK
- Alert Center API
建議:設定第三方 API 動態饋給
在 Google SecOps 平台中,有兩種不同的進入點可設定動態饋給:
- 依序點選「SIEM Settings」>「Feeds」>「Add New Feed」
- 依序點選「內容中心」「內容包」「開始使用」
如何設定 Google Cloud 身分識別裝置使用者動態饋給
- 按一下「Google Cloud Compute platform」套件。
- 找到「Google Cloud 身分識別裝置使用者」記錄類型,然後按一下「新增動態饋給」。
- 為下列欄位指定值:
- 來源類型:選取「第三方 API」。
- OAuth JWT 端點:輸入 OAuth 權杖端點:
https://oauth2.googleapis.com/token - JWT 權杖簽發者:輸入服務帳戶的電子郵件地址 (位於服務帳戶的 JSON 金鑰檔案中)。
- JWT 聲明主體:輸入在 Workspace 控制台中獲派「服務管理員」或「超級管理員」角色的使用者電子郵件地址 (透過全網域委派功能模擬的使用者)。
- JWT 聲明目標對象:再次輸入端點:
https://oauth2.googleapis.com/token - RSA 私密金鑰:從服務帳戶的 JSON 金鑰檔案中,貼上私密金鑰的完整內容 (包括
-----BEGIN PRIVATE KEY-----和-----END PRIVATE KEY-----行)。
進階選項
- 動態饋給名稱:系統預先填入的值,用於識別動態饋給。
- 資產命名空間:與動態饋給相關聯的命名空間。
- 擷取標籤:套用至這個動態饋給所有事件的標籤。
- 點選「建立動態饋給」。
如要進一步瞭解如何為這個產品系列中的不同記錄類型設定多個動態饋給,請參閱「依產品設定動態饋給」。
替代方法:透過 Cloud Storage 擷取
- 登入Google Cloud 控制台。
前往「Cloud Storage Buckets」(Cloud Storage bucket) 頁面。
點選「建立」。
在「建立 bucket」頁面中,輸入 bucket 資訊。完成下列每個步驟後,請按一下「繼續」前往下一個步驟:
在「開始使用」部分,執行下列操作:
- 輸入符合值區名稱規定的不重複名稱,例如 gcp-cloudidentity-users-logs。
如要啟用階層命名空間,請按一下展開箭頭,展開「為檔案導向和資料密集型工作負載提供最理想的儲存空間」部分,然後選取「為這個值區啟用階層結構式命名空間」。
如要新增值區標籤,請按一下展開箭頭,展開「標籤」部分。
按一下「新增標籤」,然後指定標籤的鍵和值。
在「Choose where to store your data」(選擇資料的儲存位置) 部分,執行下列操作:
- 選取「位置類型」。
使用位置類型選單選取位置,永久儲存 bucket 中的物件資料。
如要設定跨 bucket 複製作業,請展開「設定跨 bucket 複製作業」部分。
在「為資料選擇儲存空間級別」部分,選取 bucket 的預設儲存空間級別,或選取「Autoclass」,讓系統自動管理 bucket 資料的儲存空間級別。
在「選取如何控制物件的存取權」部分,取消選取「強制禁止公開存取」,然後為 bucket 物件選取「存取權控管」模型。
在「選擇保護物件資料的方式」部分,執行下列操作:
- 選取「資料保護」下方的任何選項,為 bucket 設定資料保護措施。
- 如要選擇物件資料的加密方式,請按一下標示為「資料加密」的展開箭頭,然後選取資料加密方法。
點選「建立」。
設定匯出 Cloud Identity 裝置使用者記錄
- 登入Google Cloud 控制台。
- 依序前往「Logging」>「Log Router」。
- 按一下「建立接收器」。
提供下列設定參數:
- 接收器名稱:輸入有意義的名稱,例如
Cloudidentity-Users-Sink。 - 接收器目的地:選取「Cloud Storage Storage」,然後輸入值區的 URI,例如
gs://gcp-cloudidentity-users-logs/。 記錄檔篩選器:
logName="projects/<your-project-id>/logs/cloudaudit.googleapis.com%2Factivity" resource.type="cloud_identity_user"設定匯出選項:包含所有記錄項目。
- 接收器名稱:輸入有意義的名稱,例如
點選「建立」。
設定 Cloud Storage 的權限
- 依序前往「IAM 與管理」>「IAM」。
- 找到 Cloud Logging 服務帳戶。
- 授予值區的 roles/storage.admin。
UDM 對應表
| 記錄欄位 | UDM 對應 | 邏輯 |
|---|---|---|
| collection_time.nanos | timestamp.nanos | 直接從記錄檔欄位對應。代表事件時間戳記 (以奈秒為單位)。 |
| collection_time.seconds | timestamp.seconds | 直接從記錄檔欄位對應。代表事件時間戳記 (以秒為單位)。 |
| createTime | entity.metadata.creation_timestamp | 由 date 篩選器剖析後,直接從記錄欄位對應。代表使用者的建立時間戳記。 |
| managementState | entity.additional.fields.value.string_value | 直接從記錄檔欄位對應。代表使用者的管理狀態。 |
| 名稱 | entity.entity.resource.name | 直接從記錄檔欄位對應。代表裝置使用者的完整資源名稱。 |
| passwordState | entity.additional.fields.value.string_value | 直接從記錄檔欄位對應。代表使用者的密碼狀態。只有在原始記錄中存在 passwordState 欄位時,才會對應這個欄位。 |
| userEmail | entity.entity.user.email_addresses | 直接從記錄檔欄位對應。代表使用者的電子郵件地址。 |
| entity.additional.fields.key | 在剖析器中設為常數值 Management State。這個欄位用於提供 managementState 值的背景資訊。 |
|
| entity.additional.fields.key | 在剖析器中設為常數值 Password State。這個欄位用於提供 passwordState 值的背景資訊,只有在原始記錄中存在 passwordState 時才會顯示。 |
|
| entity.entity.user.product_object_id | 使用 grok 篩選器從 name 欄位擷取,擷取 deviceuser_id 部分。代表裝置使用者的專屬 ID。 |
|
| entity.metadata.collected_timestamp.nanos | 從「collection_time.nanos」複製的項目。代表收集記錄的時間戳記。 |
|
| entity.metadata.collected_timestamp.seconds | 從「collection_time.seconds」複製的項目。代表收集記錄的時間戳記。 |
|
| entity.metadata.entity_type | 在剖析器中設為常數值 USER。 |
|
| entity.metadata.product_name | 在剖析器中設為常數值 GCP Cloud Identity Device Users。 |
|
| entity.metadata.vendor_name | 在剖析器中設為常數值 Google Cloud Platform。 |
|
| relations.entity.asset.product_object_id | 使用 grok 篩選器從 name 欄位擷取,擷取 device_id 部分。代表裝置的專屬 ID。 |
|
| relations.entity_type | 在剖析器中設為常數值 ASSET。 |
|
| relations.relationship | 在剖析器中設為常數值 MEMBER。 |
還有其他問題嗎?向社群成員和 Google SecOps 專業人員尋求答案。