身分聯盟的架構模式

本文將比較四種架構模式，以連結外部身分識別提供者 (IdP)。 Google Cloud並提供指引，協助您為自己的用途選擇合適的架構。

這四種架構模式如下：

決策因素

如要選擇適合貴機構的架構模式，請考量多種因素，包括：

  • 服務組合：您的 Google 服務組合，以及是否包含 Google Workspace 和Google Cloud以外的服務，例如 Google Ads、Google 地圖或 Chrome Enterprise。
  • 資料落地：您的資料落地和主權需求。
  • Gemini Enterprise 與 Microsoft 365 整合：您是否使用 Gemini Enterprise 或 NotebookLM Enterprise，以及是否打算將 Gemini Enterprise 與 Microsoft 365 服務整合。

服務組合

Google 服務管理驗證和授權的方式不同。這會影響您設定身分聯盟的方式。這類差異取決於兩個因素：服務模型 (SaaS 與 PaaS 和 IaaS) 和授權模型 (IAM 與服務專屬)。

服務模型

  • 軟體即服務 (SaaS)：Google 會全面管理 Gmail、Google Ads 或 Gemini Enterprise 應用程式等服務。這些服務不需開發，隨時可用。由於 SaaS 服務的目標對象廣泛，因此大多數使用者可能都需要存取這些服務。
  • 平台即服務 (PaaS) 或基礎架構即服務 (IaaS)：大多數Google Cloud 服務都是 PaaS 或 IaaS。技術人員可透過這些服務開發、部署及運作自訂工作負載。由於這些服務的目標對象是技術人員，因此只有部分使用者需要存取權。

授權模式

Google 服務會透過下列其中一種方式實作授權：

  • 身分與存取權管理：大多數 Google Cloud 服務都使用身分與存取權管理，讓管理員精細管理資源存取權。
  • 服務專屬授權：Google Ads、Looker 或 Google Workspace 等服務不會使用 IAM。管理員會改用各項服務專屬的工具管理存取權。

這些因素會產生下列服務群組：

軟體式服務 (SaaS) PaaS 或 IaaS
以 IAM 為基礎的授權 Google Cloud SaaS 服務，例如 Gemini Enterprise 應用程式和 NotebookLM Enterprise Google Cloud PaaS 和 IaaS 服務，例如 BigQuery 或 Compute Engine
服務專屬授權 非雲端 Google 服務，例如 Google Ads、Google Workspace 和 Google 地圖 無

如要選擇適合貴機構的架構模式，請考量哪些服務群組適用於貴機構。

資料落地

為驗證使用者身分和管理工作階段，Cloud Identity、Google Workspace 和員工身分聯盟會處理個人使用者資訊。這類使用者資訊可能包括：

  • 使用者名稱或電子郵件地址
  • 使用者屬性，例如名字和姓氏
  • 群組名稱和成員

Cloud Identity、Google Workspace 和員工身分聯盟會根據服務資料條款處理這類資料，並可能將資料儲存在貴機構或使用者所在位置以外的地方：

  • Cloud Identity 和 Google Workspace 會將服務資料儲存在 Google 資料中心，並可能在所有資料中心複製資料。儲存的資料可能包含驗證時非必要的資訊，例如部門名稱、地址或電話號碼。
  • Workforce Identity Federation 會將服務資料儲存在Google Cloud區域，並可能在所有區域複製資料。

如果您授予使用者資源存取權，IAM 會將他們的主體 ID 儲存在角色繫結中。 Google Cloud 會根據服務資料的條款處理角色繫結，並可能將其儲存在所有 Google Cloud 區域。

本頁面說明的架構模式需要儲存使用者資訊，但儲存時間長度不同：

許多 IdP 都能自動暫停或刪除使用者帳戶，前提是 IdP 中相應的使用者帳戶狀態有所變更。視 IdP 和其設定而定，IdP 可能會延後刪除使用者帳戶，直到特定寬限期結束為止，這可能會延長 Google Cloud儲存使用者資訊的時間。

Gemini Enterprise 能與 Microsoft 365 整合

Gemini Enterprise 提供兩種連接器，可連結至 Microsoft 365 服務：

  • 以資料擷取為基礎的連接器：這類連接器會檢索 Microsoft 365，在 Google Cloud中建立搜尋索引。使用者提交提示時，Gemini Enterprise 會使用這個索引搜尋內容，並評估從 Microsoft 365 取得的存取控制清單 (ACL)，在本地執行存取檢查。
  • 聯合連接器：這些連接器會針對每個提示查詢 Microsoft 365。他們會使用委派授權，讓 Microsoft 365 直接執行存取檢查。

以資料擷取為基礎的連接器對使用者同盟有特定要求：

  • 群組成員意識：Microsoft 365 ACL 可以包含群組和使用者的項目。如要評估使用者是否可以存取內容，連接器必須考量使用者所屬的所有群組。如果連接器只知道部分使用者群組，可能會誤判是否允許存取。
  • 識別碼轉換：如要評估 ACL，連接器必須在 Microsoft 365 使用者和群組識別碼，以及 Google Cloud使用的識別碼之間進行轉換。

使用員工身分聯盟時，如果設定的屬性對應與 Gemini Enterprise 相容，Gemini Enterprise 就能可靠地轉換 ID 並評估存取控制清單。

使用 Cloud Identity 或 Google Workspace 聯盟時，Microsoft Entra ID 會控管使用者和群組佈建的屬性對應，而非 Google Cloud。Entra 會決定使用者和群組 ID 的轉換規則，這可能涉及複雜的轉換。如要評估 ACL，Gemini Enterprise 連接器必須套用相同的轉換規則，但連接器無法查看 Entra 設定。因此，使用 Cloud Identity 聯盟或 Google Workspace 聯盟時，Gemini Enterprise 無法可靠地轉換使用者和群組 ID，也無法可靠地評估存取控制清單。

如要判斷哪種架構模式適合貴機構，請考量 Gemini Enterprise 的使用情況，以及是否打算使用以資料擷取為基礎的連結器。

架構模式

下圖顯示這些因素如何決定哪種模式符合貴機構的需求：

流程圖：顯示如何選取身分同盟模式。

  1. 貴機構是否大部分都使用 Google Workspace？

  2. 您是否使用 Google Cloud 以外的服務，例如 Google Ads 或 Google 地圖？

    • 如果是「是」，請繼續進行決策 3。
    • 如果否，請繼續進行決策 4。

  3. 您是否打算使用 Gemini Enterprise，並與 Microsoft 365 整合？

  4. 你是否打算使用 Gemini Enterprise？

  5. 您是否需要遵守資料落地規定，盡量減少使用者資訊的儲存量？

Cloud Identity 或 Google Workspace 聯盟

如果貴機構符合下列其中一項條件，請選取這個模式：

  • 貴機構中已有相當比例的使用者採用 Google Workspace。
  • 您使用 Google 服務 (例如 Google Ads 或 Google 地圖)，但不打算使用以資料擷取為基礎的連結器，將 Gemini Enterprise 與 Microsoft 365 整合。 Google Cloud
  • 您只使用 Google Cloud 服務，不打算使用 Gemini Enterprise，且沒有嚴格的資料駐留規定，可盡量減少使用者資料儲存量。

在這個模式中，您不會使用員工身分聯盟。而是將 Cloud Identity 帳戶或 Google Workspace 帳戶與 IdP 聯合，並使用預先使用者佈建和群組佈建。

Cloud Identity 和 Google Workspace 聯盟的架構。

在這個模式中，您必須先佈建使用者和群組，使用者才能登入；否則，登入嘗試會失敗：

  • 使用者帳戶管理：確保使用者能及時加入及退出團隊。
  • 群組佈建：可讓您使用群組管理 Google 服務和資源的存取權。 Google Cloud

如果貴機構只有部分使用者需要 Google Workspace，請在帳戶中同時新增 Google Workspace 訂閱方案和 Cloud Identity 訂閱方案，然後只為需要的使用者指派 Google Workspace 授權。

福利

  • 無論這些服務是否使用 IAM，使用者都可以向 Google 服務驗證身分。在 Cloud Identity 帳戶或 Google Workspace 帳戶中，控管使用者可使用的 Google 服務。
  • 您可以將單一登入 (SSO) 和預先佈建功能限制在部分使用者，並繼續直接在 Cloud Identity 或 Google Workspace 中管理特定使用者，例如緊急存取權使用者。
  • 您可以從外部 IdP 佈建群組、在 Cloud Identity 帳戶或 Google Workspace 帳戶中管理本機群組，或結合這兩種方法。

限制

  • 預先佈建使用者帳戶會增加額外負擔，而且佈建作業可能會拖慢新進人員的訓練程序。

  • 您無法控管或限制 Cloud Identity 或 Google Workspace 用來儲存使用者資料和群組資料的位置。由於 Google 會根據服務資料條款處理及儲存使用者資料和群組資料，資料地區控制選項不適用於這類資料，且 Google 可能會在Google 資料中心位置複製這類資料。

  • 使用 Cloud Identity 聯盟或 Google Workspace 聯盟時，Gemini Enterprise 僅提供有限的支援，可連結至 Microsoft 資料來源。

員工身分聯盟 (無須同步)

如果貴機構符合下列條件，請選取這個模式：

  • 您只使用 Google Cloud 服務。
  • 您使用 Gemini Enterprise，但預期會受到 IdP 施加的群組限制。
  • 您有資料落地規定，因此需要盡量減少儲存個人使用者資訊。

員工身分聯盟架構，無需同步。

在這個模式中，您會使用員工身分聯盟，將Google Cloud 機構與外部 IdP 建立聯盟。

這個模式不需要佈建使用者或群組。每當使用者登入時，IdP 會將使用者相關必要資訊 (包括群組成員資格和自訂屬性) 傳遞至 Google Cloud，並 Google Cloud 僅在使用者工作階段期間保留該資訊。

福利

  • 您不需要在Google Cloud中儲存或管理使用者帳戶或群組。
  • 這個模式可讓您使用以資料擷取為基礎的連接器，將 Gemini Enterprise 與 Microsoft 365 整合。

限制

  • 員工身分聯盟是 IAM 功能，只允許使用者存取使用 IAM 的服務。使用員工身分聯盟驗證身分的使用者，無法存取 Google 服務，例如 Google Ads、Looker 或 Google Marketing Platform。
  • 使用員工身分聯盟驗證的使用者無法存取部分功能。 Google Cloud 詳情請參閱「身分聯盟：產品和限制」。
  • 許多 IdP 會限制可傳遞至員工身分聯盟的群組成員人數 (以 SAML 判斷提示或 ID 權杖的形式)。如要遵守這些限制，您可能需要加強群組管理，並限制在判斷結果或權杖中包含的群組類型。
  • 分享 NotebookLM Enterprise 筆記本等資源時，您無法依名稱搜尋群組，使用者必須手動輸入 ID。

如果您使用 Microsoft Entra ID，可以設定額外屬性，使用這個模式的變體。設定額外屬性時，員工身分聯盟會在使用者驗證期間執行回呼至 Microsoft Graph API，以擷取群組成員資格。這項設定可讓您突破 Entra 對於 SAML 聲明和 ID 權杖的群組成員資格限制，每個使用者最多可有 999 個群組成員資格。

透過 SCIM 使用員工身分聯盟

如果貴機構符合下列條件，請選取這個模式：

  • 您只使用 Google Cloud 服務。也就是說，您並未使用 Google Ads 或 Google 地圖等外部 Google 服務。
  • 您打算使用 Gemini Enterprise 或 NotebookLM Enterprise，且需要支援每位使用者最多 2,000 個群組成員資格，或在共用資源時依名稱查詢群組。

員工身分聯盟搭配 SCIM 的架構。

在這個模式中，您可以使用員工身分聯盟來聯盟Google Cloud 機構。如要增加可供 Gemini Enterprise 使用的群組數量，請預先設定 SCIM 來佈建群組成員資訊。

福利

  • 這個模式可讓您使用以資料擷取為基礎的連接器，將 Gemini Enterprise 與 Microsoft 365 整合。
  • 每位使用者最多可使用 2,000 個群組成員資格，控管 Gemini Enterprise 和 NotebookLM Enterprise 的存取權，並讓 Gemini Enterprise 資料擷取型連接器執行存取權檢查。
  • 分享 NotebookLM Enterprise 筆記本等資源時，您可以依名稱搜尋群組，提升整體使用者體驗。

限制

  • SCIM 佈建群組僅支援 Gemini Enterprise 和 NotebookLM Enterprise。其他服務只能使用 IdP 在 SAML 判斷或 ID 權杖中傳遞的群組成員資格。
  • 員工身分聯盟是 IAM 功能，只允許使用者存取使用 IAM 的服務。使用員工身分聯盟驗證身分的使用者，無法存取 Google 服務，例如 Google Ads、Looker 或 Google Marketing Platform。
  • 使用員工身分聯盟驗證身分的使用者無法存取部分 Google Cloud 功能。詳情請參閱「身分同盟：產品和限制」。

混合雲身分與員工身分聯盟

如果貴機構符合下列條件，請選取這個模式：

  • 您使用的 Google 服務超出 Google Cloud (例如 Google Ads 或 Google 地圖)。
  • 您打算使用 Gemini Enterprise，並與 Microsoft 365 整合。

混合式 Cloud Identity 和員工身分聯盟的架構。

這個模式結合了先前的兩種模式：

  • 您可以使用員工身分聯盟 (免同步或搭配 SCIM)，管理 Gemini Enterprise 和 NotebookLM Enterprise 的存取權。
  • 您可以使用 Cloud Identity 或 Google Workspace 聯盟，管理其他服務的存取權，包括 Google Cloud 和非雲端 Google 服務。

福利

這個模式可結合前兩種模式的優點：

  • 您可以將 Gemini Enterprise 連結至 Microsoft 資料來源，且不受功能限制。
  • 無論這些服務是否使用 IAM，使用者都可以向 Google 服務驗證身分。
  • 使用完整功能集。 Google Cloud

限制

  • 您必須在外部 IdP 中維護兩個不同的信賴方設定：一個用於 Cloud Identity，另一個用於員工身分聯盟。
  • 視您設定使用者使用 Cloud Identity 或員工身分聯盟而定，登入體驗可能會有所不同。
  • 管理 IAM 允許政策時，您必須根據使用者的驗證方式，使用不同的主體 ID。舉例來說，在外部 IdP 中稱為 bob@example.com 的使用者，在 IAM 中可能會有主體 ID bob@example.com 或 principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID//subject/SUBJECT_ID，具體取決於該使用者是透過 Cloud Identity 聯盟還是員工身分聯盟進行驗證。
  • 您無法建立同時包含 Cloud Identity 使用者和員工身分聯盟主體的群組。Cloud Identity 群組只能包含 Cloud Identity 使用者，員工身分群組則只能包含員工身分聯盟主體。
  • 如果將員工身分聯盟的使用範圍擴展到 Gemini Enterprise 以外，使用者可能需要切換身分，或不確定如何驗證。

後續步驟