遷移前驗證指南

支援的國家/地區：

Google SecOps SOAR

本文將逐步說明系統性診斷方法，協助您在 SOAR 遷移前驗證 Google Security Operations 執行個體和驗證設定。本指南著重於用於使用者驗證和授權的 SAML 和 OIDC 標準。

驗證 Chronicle API 設定

如要檢查 Chronicle API 在專案中是否已正確設定，請按照下列步驟操作： Google Cloud

1. 登入 Google Cloud 控制台，然後從頂端導覽列的「專案」清單中選取正確的 Google Cloud 專案。
2. 開啟「導覽選單」 (≡)，然後依序前往「API 和服務」>「已啟用的 API 和服務」。
3. 前往「已啟用的 API 和服務」清單，找出 Chronicle API。

4. 如果列出該 API：表示已啟用。

   如果未列出：按一下頂端的「+ 啟用 API 和服務」，搜尋 Chronicle API，然後按一下「啟用」。

如要確認服務帳戶是否已建立，請按照下列步驟操作：

1. 前往 Google Cloud 控制台的「IAM」頁面。
2. 顯示隱藏帳戶 (重要步驟)：請務必選取篩選列右側的方塊，也就是「包含 Google 提供的角色授予項目」。
3. 搜尋代理程式：在篩選列中輸入 chronicle。您要尋找符合以下特定模式的電子郵件地址： service-[PROJECT_NUMBER]@gcp-sa-chronicle.iam.gserviceaccount.com
4. 確認權限：確認服務帳戶具備「Chronicle 服務代理」角色。 如果缺少角色，請按一下「編輯」，然後重新新增。

Google SecOps 設定驗證

1. 在 Google Cloud 控制台中，從清單選取正確的 Google Cloud 專案。
2. 依序前往「安全性」>「Google SecOps」，然後「單一登入」分頁就會顯示。
3. 如果已啟用 Google SecOps，您應該會看到名為「單一登入」的分頁。如果沒有，表示潛在客戶啟動程序未完成。在產品內通知中的 Google 表單中提供 Google Cloud 專案 ID。確認遷移日期和時間，然後提交表單。如果提交後 72 小時內未收到回覆，請來信至 [e-mail]。
4. 如果該分頁存在，請按一下「前往 SecOps」。成功登入表示驗證設定正確無誤。如果登入失敗，請參閱下一節，對設定進行偵錯。如果登入失敗，請參閱下一節，對設定進行偵錯。

SAML 流程和疑難排解

本節將簡要說明 SAML 驗證程序，並列出診斷及解決常見設定問題的系統性方法。

驗證工作流程架構

瞭解要求流程是找出任何失敗點的關鍵。下圖說明成功登入的循序路徑。

逐步疑難排解程序

如要有效診斷及追蹤 SAML 驗證程序，可以使用下列各節列出的網路公用程式。

Google 不會為任何特定產品背書，但據瞭解，下列工具可協助排解程序問題：

• SAML 驗證： https://www.samltool.io/
  • 用途：用於解碼及驗證原始 SAML 要求和回應。
• JWT 檢查： https://www.jwt.io/
  • 用途：用於檢查 JSON Web Token (JWT) 的聲明和內容。

第 1 階段：準備環境

開始之前，請先完成下列步驟，確保瀏覽器環境已準備好擷取網路流量：

1. 開啟新的瀏覽器分頁，或使用無痕視窗。

2. 使用作業系統的快速鍵開啟開發人員工具：

   • Windows：按下 F12 鍵
   • Linux：按下 Ctrl + Shift + I 鍵
   • macOS：按 Cmd + Option + I

3. 前往「網路」分頁。

4. 選取「保留記錄」方塊，確保重新導向期間不會遺失資料。

   

5. 前往 Google SecOps 環境網址，啟動登入流程。完成將 SOAR 獨立客戶遷移至 GCP 的第 1 階段步驟 5，並在 Google SecOps 中完成設定後，您會收到這組網址的電子郵件。電子郵件主旨為「Your Google SecOps instance is ready」。

階段 2：驗證傳送至 IDP 的 SAML 要求

這個步驟會驗證 Google Cloud 傳送給您身分識別提供者 (IDP) 的初始訊息。

1. 找出要求：在「網路」分頁的篩選器列中，搜尋 saml。

   

2. 擷取資料：選取要求，然後按一下「Payload」分頁標籤。找出標示為 SAMLRequest 的查詢字串參數。

   

3. 解碼：複製要求值，並貼到 SAML 驗證工具 (samltool.io) 中進行解碼。

   

4. 驗證狀態：

   • 檢查「要求目的地」。
   • 確認這個網址與 IDP 中的設定相符。

階段 3：驗證 IDP 的 SAML 回應

這個步驟會驗證 IDP 在驗證後傳回的屬性。 Google Cloud

1. 找出回應：在「網路」分頁的篩選器列中，搜尋 signin-callback。

   

2. 擷取資料：選取要求，然後按一下「Payload」分頁標籤。找出 SAMLResponse 資料。

   

3. 解碼：複製回應值，並貼到 SAML 驗證工具中。

4. 驗證狀態：

   • 檢查傳回的聲明 (屬性)，例如 groups、first name、last name 和 email。
   • 重要事項：請確認這些屬性與 Google Cloud中「工作團隊集區」設定的屬性相符。

   • 確認嘗試登入的特定使用者值是否正確。

     

下圖顯示屬性對應：

圖片中的對應關係如下：

• google.subject = assertion.subject
• attribute.last_name = assertion.attributes.last_name[0]
• attribute.user_email = assertion.attributes.user_email[0]
• attribute.first_name = assertion.attributes.first_name[0]
• google.groups = assertion.attributes.groups

左側部分一律相同，也就是 Google 語法。右側是根據 SAML 回應中顯示的聲明屬性鍵。

[0] 對於所述特定屬性 (last_name、user_email、first_name) 至關重要，但與 subject 和 groups 無關。

第 4 階段：驗證 Google SecOps 驗證

這個步驟會驗證 Google Cloud 是否正在驗證使用者，以便登入 Google SecOps SOAR。

1. 在使用者瀏覽器中找出權杖：在「網路」分頁的篩選器列中，搜尋端點 auth/siem。

   

2. 擷取資料：選取要求，然後查看「Payload」分頁。找出 jwt 字串。

3. 解碼：複製 JWT 字串，然後貼到 JWT 檢查工具 (jwt.io)。

   

4. 驗證狀態：

   • 比較 given_name、family_name、email 和 idpgroups 的已解碼聲明。
   • 比對確認：這些值必須與第 3 階段 (SAML 回應) 驗證的屬性完全相符。
   • 如果值相符但您仍無法存取，請檢查 IAM 中的角色指派。請務必使用正確的主體格式，為身分識別設定 (Google 受管理帳戶的員工身分聯盟或 Cloud Identity) 指派所有使用者其中一個 Chronicle 預先定義的角色。

第 5 階段：驗證 SOAR 權限存取權

這個步驟可確認系統是否透過平台「群組對應」頁面，在 SOAR 中正確指派權限。

系統管理員會自動取得 SOAR 存取權，因為「群組對應」頁面會啟用預設存取權。

您可以在這個新的 SOAR 執行個體中新增幾個 IDP 群組對應，驗證使用者的群組存取權。根據預設，新執行個體的「群組對應」頁面會是空白。如要驗證其他使用者的群組存取權，請將 IDP 群組對應新增至新的 SOAR 執行個體，然後完成下列步驟：

1. 從現有 SOAR 執行個體的「群組對應」頁面複製群組對應。
2. 請 IDP 群組中的使用者存取新的 Google SecOps 網址。

3. 如果使用者無法存取 SOAR，請按照下列步驟排解問題：

   a. 檢查回應：開啟第 4 階段的 auth/siem 要求，然後選取「預覽」分頁。

   b. 檢查權限：在 JSON 回應中找出 permissions 物件。

選用：如要節省時間，請前往「設定」 >「進階」 >「群組對應」，將這些對應項目複製到現有的 Google SecOps 執行個體。

注意： 完成第 1 階段的遷移作業後，現有 SOAR 執行個體的群組對應會覆寫您新增至新 Google SecOps 執行個體的任何對應。如要查看這些設定，請依序點選「設定」>「進階」>「群組對應」。

OIDC 流程和疑難排解

本節將概述 OIDC 驗證程序，並說明如何有系統地診斷及解決常見的整合問題。

驗證工作流程架構

瞭解要求流程是找出任何失敗點的關鍵。下圖說明成功登入的循序路徑。

OIDC 疑難排解程序

如要有效診斷及追蹤 OIDC 驗證程序，可以使用瀏覽器開發人員工具和線上 JWT 解碼器。

• JWT 檢查： https://www.jwt.io/
  • 用途：用於檢查 JSON Web Token (JWT) 的聲明和內容。

第 1 階段：準備環境

開始之前，請先完成下列步驟，確保瀏覽器環境已準備好擷取網路：

1. 開啟新的空白瀏覽器分頁或無痕視窗。

2. 使用作業系統的快速鍵開啟開發人員工具：

   • Windows：按下 F12 鍵
   • Linux：按下 Ctrl + Shift + I 鍵
   • macOS：按 Cmd + Option + I

3. 前往「網路」分頁。

4. 選取「保留記錄」方塊，確保重新導向期間不會遺失資料。

   

5. 前往 Google SecOps 環境網址，啟動登入流程。完成將 SOAR 獨立客戶遷移至 GCP 的第 1 階段步驟 5，並在 Google SecOps 中完成設定後，您會收到這組網址的電子郵件。電子郵件主旨為「YourGoogle SecOps instance is ready」。

第 2 階段：向 OIDC 供應商驗證授權要求

這個步驟會驗證從 Google Cloud 到 OpenID Connect 提供者 (IdP) 的初始重新導向。

1. 找出要求：在「網路」分頁中，尋找初始重新導向至 OIDC 供應商授權端點的要求。網址通常會包含 client_id、redirect_uri、scope、response_type 和 state 等參數。

   

2. 驗證狀態：

   • 確認 client_id 與 OIDC 供應商設定的相符。
   • 請確認 redirect_uri 與 https://auth.backstory.chronicle.security/signin-callback/locations/global/workforcePools/POOL_ID/provider/PROVIDER_ID 完全相符，並將 POOL_ID 和 PROVIDER_ID 替換為員工身分聯盟的集區和提供者。
   • 確認 response_type 已設為代碼。
   • 請注意範圍參數，其中應包含 openid 和發布必要權杖附加資訊所需的任何其他範圍 (例如 email、profile)。

階段 3：驗證回呼和權杖交換

這個步驟會驗證 IdP 回傳給 Google Cloud的回應。

1. 找出回呼：在「網路」分頁中，找出登入回呼網址的要求 (.../signin-callback/...)。

   

2. 檢查資料：檢查這項要求的網址參數。其中應包含 OIDC IdP 提供的程式碼參數。

3. 幕後運作方式：Workforce Identity Federation 會向 OIDC 提供者的權杖端點，將這個授權碼換成權杖 (ID 權杖、存取權杖)。在這個階段發生的錯誤，通常會顯示在 Workforce Identity Federation 的 Cloud Logging 中。

   • 驗證屬性傳播和完整權杖：如要驗證員工身分聯盟中的屬性對應是否產生預期結果，請按照下列步驟操作：
     • 將員工身分聯盟提供者設定中提供的重新導向 URI，新增至提供者的重新導向 URI (例如 https://auth.cloud.google/signin-callback/locations/global/workforcePools/POOL_ID/providers/PROVIDER_ID)。
     • 前往員工身分聯盟提供者，偵錯 IdP 權杖。你也可以查看完整權杖。詳情請參閱「驗證產品設定」。

   

第 4 階段：驗證 Google SecOps 驗證

這個步驟會驗證 Google Cloud 是否正在驗證使用者，以便登入 Google SecOps SOAR。

1. 在使用者瀏覽器中找出權杖：在「網路」分頁的篩選器列中，搜尋端點 auth/siem。

   

2. 擷取資料：選取要求，然後查看「Payload」分頁。找出 jwt 字串。

3. 解碼：複製 JWT 字串，然後貼到 JWT 檢查工具 (jwt.io)。

   

4. 驗證狀態：

   • 比較 sub、given_name、family_name、email 和 idpgroups 的已解碼聲明。
   • 比對確認：這些值必須對應至 OIDC 提供者發布的屬性，以及員工身分聯盟屬性對應中的對應方式。舉例來說，attribute.first_name Google Cloud 應對應至 JWT 中的 given_name。
   • IAM 角色：如果宣告正確，但存取遭拒，並顯示類似 Cannot Authenticate user, because user does not have access to the GCP project..., 的訊息，請檢查 IAM 角色指派。請確認使用正確的 principalSet 格式 (例如 principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/group/IDP_GROUP_NAME)，為使用者的群組 (JWT 中的 idp_groups) 授予必要角色。

第 5 階段：驗證 SOAR 權限存取權

這個步驟可確認系統是否透過平台「群組對應」頁面，在 SOAR 中正確指派權限。

系統管理員會自動取得 SOAR 存取權，因為「群組對應」頁面會啟用預設存取權。

您可以在這個新的 SOAR 執行個體中新增幾個 IDP 群組對應，驗證使用者的群組存取權。根據預設，新執行個體的「群組對應」頁面會是空白。如要驗證其他使用者的群組存取權，請將 IDP 群組對應新增至新的 SOAR 執行個體，然後完成下列步驟：

1. 從現有 SOAR 執行個體的「群組對應」頁面複製群組對應。
2. 請 IDP 群組中的使用者存取新的 Google SecOps 網址。

3. 如果使用者無法存取 SOAR，請按照下列步驟排解問題：

   a. 檢查回應：開啟第 4 階段的 auth/siem 要求，然後選取「預覽」分頁。

   b. 檢查權限：在 JSON 回應中找出 permissions 物件。

選用：如要節省時間，請前往「設定」 >「進階」 >「群組對應」，將這些對應項目複製到現有的 Google SecOps 執行個體。

注意： 完成第 1 階段的遷移作業後，現有 SOAR 執行個體的群組對應會覆寫您新增至新 Google SecOps 執行個體的任何對應。如要查看這些設定，請依序點選「設定」>「進階」>「群組對應」。

常見 OIDC 錯誤：

• invalid_redirect_uri來自 IdP：請確認在 IdP 中設定的重新導向 URI 完全相符：https://auth.backstory.chronicle.security/signin-callback/locations/global/workforcePools/POOL_ID/provider/PROVIDER_ID，並將 POOL_ID 和 PROVIDER_ID 替換為員工身分聯盟中的集區和提供者。 即使是尾端斜線或 http 與 https 不符，也會觸發這項錯誤。

• JWT 中缺少聲明：

  1. IdP 端：確認 OIDC 用戶端已設定為在 ID 權杖中發布必要聲明 (已在 WIF 中對應，例如 sub、groups、email、given_name、family_name)。

  2. WIF 端：請確認這些傳入的聲明已在 WIF 屬性對應部分正確對應 (例如 google.groups=assertion.groups)。如果權杖中含有聲明，但 WIF 中未對應，SOAR 平台可能無法授權使用者。如要確認屬性對應是否產生預期結果，請參閱「驗證提供者設定」。

遷移後的群組對應

遷移完成後，群組對應在 Google SecOps 中仍至關重要

遷移後，遷移的執行個體會保留群組對應。這些角色是判斷使用者 SOAR 存取權的依據。您必須確保每位使用者都已對應至這個頁面，才能存取 Google SecOps。詳情請參閱「存取執行個體」。

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