Workforce Identity Federation 會將 Google Cloud 機構與外部身分識別資訊提供者 (IdP) 建立聯盟，啟用單一登入 (SSO)。
您可以套用這些最佳做法，有效使用員工身分聯盟，並將安全風險降到最低。
選擇合適的架構
以下各節說明選擇符合需求的聯盟架構時，應考量的主要因素。
選擇聯盟架構模式
以下四種模式說明瞭 Google Cloud 機構與外部 IdP 聯合的常見方式：
聯合前，請先考量每種模式的優點和限制，然後選擇符合您需求的模式。詳情請參閱「身分聯盟的架構模式」。
依服務劃分的分區聯盟用量
一般來說，建議您依服務 (而非使用者) 劃分同盟使用量。整體而言，按服務劃分用量較少缺點。
為降低複雜度，建議使用 Cloud Identity 或員工身分聯盟。不過，視需求而定，您可能需要同時使用這兩者，如混合模式所述。
如果您同時使用 Cloud Identity 聯盟和員工身分聯盟，可以透過下列方式劃分使用情況：
依使用者劃分：將使用者劃分為兩個群組，一個使用員工身分聯盟，另一個使用 Cloud Identity 聯盟。
- 優點：每位使用者在 Google 服務中都只有一個身分，且登入方式相同。
缺點：依使用者劃分區隔有幾個缺點，包括：
管理存取群組可能很複雜，因為 IAM 允許政策必須包含主體類型組合，而且您無法對 Cloud Identity 和員工身分聯盟使用者使用相同群組。
不同群組的使用者無法共用連結，因為 Google Cloud 控制台、Gemini Enterprise 和其他工具會根據使用者的登入方式，使用不同的網址。
不同同類群組的使用者可能可以存取不同的功能組合。
依服務劃分：設定各項服務 (例如Google Cloud 或 Gemini Enterprise)，只授予員工身分聯盟使用者或 Cloud Identity 使用者存取權，但絕不會同時授予兩者。
- 優點：簡化管理作業，確保不同使用者都能享有一致的功能。
- 缺點：部分員工可能需要指派兩個身分，一個使用 Workforce Identity Federation，另一個使用 Cloud Identity。
建議依服務劃分，特別是將 Gemini Enterprise 和 Gemini Notebook Enterprise 與其他服務分開。Gemini Enterprise 和 Google Cloud 控制台是不同的工具，分別用於處理不同工作。登入程序如有任何差異，對整體使用者體驗的影響應微乎其微。
如要強制執行這項分割作業，請使用組織政策限制。
加強群組管理
您應使用群組管理存取權，並建立明確的群組管理程序，有效運用員工身分聯盟。
驗證期間不會決定使用者存取資源的權限，而是根據附加至該特定資源的政策，在使用者嘗試存取資源時評估存取權。這些政策包括：
政策會定義個別主體或主體集的存取權：
主體：透過主體 ID 識別的已驗證使用者。 員工主體 ID 類似於下列 ID：
principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/subject/SUBJECT主體 ID 包含下列項目：
POOL_ID：唯一識別員工身分集區。SUBJECT：用於專屬識別特定使用者。 值和格式取決於 IdP 和屬性對應。
主體集：符合特定條件的使用者。 員工身分聯盟支援三種主體集：以群組為準 (群組成員)、以屬性為準，以及萬用字元 (所有使用者)。
在特定情況下，授予個別主體存取權可能很有用，但由於下列問題，這種做法通常難以擴充：
- 逐一新增主體會導致允許政策不斷增加，管理難度也隨之提高。
- 個別存取權管理需要經常變更允許政策。
- 隨著時間推移，政策可能會越來越不一致。
如要進行可擴充且有效的存取權管理，使用以群組為基礎的主體集可帶來下列優點：
- 您可以透過現有的身分識別工具和程序，在群組中新增或移除成員，藉此管理存取權。
- 縮減允許政策的大小和複雜度。
- 確保具備相同角色的使用者擁有相同的資源存取權。
如要使用群組管理存取權，您必須以特定方式設定外部 IdP，並留意 IdP 對群組施加的任何限制。
以下各節說明有效使用群組的最佳做法，以及如何避免 IdP 限制。
最佳做法：
區分不同類型的群組。使用存取權群組授予資源存取權。
使用強制執行群組限制資源存取權。
請勿使用機構和協作群組管理存取權。
僅將機構群組和協作群組用於 Gemini Enterprise。
區分不同類型的群組
以下列出機構中常見的四種群組：
- 存取權群組：僅用於授予 Google 服務或Google Cloud 資源的存取權。這些群組代表工作職能，可簡化執行這些職能所需角色的指派作業。
- 機構群組：這類群組代表機構結構的子集，通常來自人力資源資料。這些群組可能以部門、匯報結構、地理位置或其他組織分組為依據。
- 協作群組：這類群組代表工作群組、專案成員，或想要協作專案或討論特定主題的使用者，可能用於電子郵件發布。協作群組通常是根據臨時需求，以自助式方式建立。
- 強制執行群組：強制執行群組也稱為政策群組，與用來授予存取權的存取權群組不同，強制執行群組是用來限制存取權。例如主體存取邊界、拒絕政策或強制執行多重驗證。 存取權群組可允許成員自願離開群組。 不過，執法群組成員資格並非自願加入。
您需要同盟的群組取決於您使用的下列服務：
- 如要使用 Google Cloud，您只需要存取群組和強制執行群組。
- 如果是 Gemini Enterprise，則需要存取權群組、強制執行群組，以及 (如果使用以資料擷取為基礎的連結器) 特定機構單位和協作群組。
設定員工身分聯盟時，請排除不相關的群組類型，以免超出 IdP 的權杖限制。這種做法有助於降低超出 IdP 限制的風險，並確保群組的使用方式更加一致。
使用存取權群組授予資源存取權
為有效管理存取權，建議使用對應至存取群組的主體集。存取權群組的唯一用途是提供存取權。這些群組代表工作職能，可簡化指派執行這些職能所需角色的程序。
如要設定存取權群組，請按照下列步驟操作：
- 在 IdP 中，建立代表職務的存取群組。
- 將存取群組對應至主體集，以便在 IAM 中使用。
- 建立政策繫結，授予主體集存取各項工作職能所需資源的權限。
- 在外部 IdP 中，根據使用者的職務功能，在群組中新增或移除使用者。
使用存取群組來管理授予存取權的政策，包括：
- IAM 允許政策
- VPC Service Controls 輸入規則
確保存取群組的精細程度足夠。舉例來說，下列群組代表有效的存取權群組：
widget-sales-dashboard-readers：授予特定 BigQuery 資料集和相關聯資訊主頁的讀取權。dev-ssh-users：授予 OS 登入權限，存取開發環境中的 Compute Engine VM。相較之下，下列類型的群組通常不適合做為存取權群組：
廣泛的管理員群組 (例如
cloud-admins) 通常缺乏特定性，無法判斷適用哪些工作負載或環境。組織群組 (例如
australia-fte) 代表團隊或地點等群組，而非職務。通訊群組 (例如
security-discuss) 是專為電子郵件名單或協作而設計，不適合做為存取權群組。
為確保存取群組的精細程度，請為您加入 Google Cloud的每個工作負載或專案建立一組新的存取群組。這樣一來，您就能根據在 Google Cloud上執行的工作負載數量，調整存取群組數量。
使用強制執行群組限制資源存取權
強制執行群組與存取權群組類似，但通常有以下差異：
- 成員無法自行退出群組。
- 與工作負載無關。
針對會減少存取權的政策，請使用強制執行群組，包括：
- IAM 拒絕政策
- 主體存取權範圍
- 組織政策
違規處置群組的範例包括 users-in-restricted-locations、fedramp-low 和 mfa-users。強制執行群組的數量通常很少，不太可能影響使用者的群組成員總數。
請勿使用機構單位和協作群組管理存取權
如要有效管理存取權，建議使用存取權群組和強制執行群組，而非機構或協作群組。
機構群組代表團隊或機構結構的子集，通常來自人力資源資料。基於下列原因，這些群組不適合用來管理 Google Cloud 資源的存取權：
- 團隊職責和組成可能會隨著時間變動。舉例來說，某個團隊可能會將工作量移交給另一個團隊，或是兩個團隊合併。在這些轉換期間，使用機構群組管理存取權可能需要連串的政策變更。
- 機構群組的成員很少需要相同的資源存取權。授予機構群組存取權時，部分成員通常會獲得超出需求的存取權。
協作群組通常由成員自行管理，成員可經由其他成員核准加入，或無須核准即可加入。您可以使用協作群組授予存取權，但這可能會導致權限過度授予和權限提升。
如要避免機構和協作群組用於存取權管理，請設定 IdP，在用於員工身分聯盟的權杖或聲明中排除這些群組成員。
僅將機構群組和協作群組用於 Gemini Enterprise
雖然組織和協作群組不適合用來 管理資源 Google Cloud 存取權 ，但您可能需要這些群組才能使用 Gemini Enterprise：
- ACL 評估：使用以資料擷取為基礎的連結器整合 Gemini Enterprise 與 Microsoft 365 時，系統可能會遇到存取控管清單 (ACL) 參照機構和協作群組的文件。如果 Gemini Enterprise 無法存取使用者在這些群組中的成員資格，可能就無法正確評估使用者是否有權存取這些文件。
- 共用筆記本：Gemini Notebook Enterprise 支援共用筆記本。允許使用者與協作群組共用筆記本，通常比限制只能與個別使用者共用更方便。
如要確保只有 Gemini Enterprise 能存取機構和協作群組，請按照下列方式設定 IdP：
- 使用 SCIM 佈建機構和協作群組，以及這些群組的成員。
- 在用於員工身分聯盟的權杖或聲明中，排除機構和協作群組成員。
管理員工身分集區
員工身分集區會定義主體 ID 的命名空間，並做為聯盟設定的容器。與使用者目錄不同，共用集區不會儲存使用者或群組的資訊。
每個 IdP 使用單一身分集區
工作團隊身分集區是機構層級的資源，而非專案層級的資源。這項設計反映出員工身分集區管理整個 Google Cloud 機構的驗證，而非個別專案或工作負載。
對大多數機構來說，員工身分集區的數量應與 IdP 數量相符：
- 如果貴機構使用單一 IdP 管理驗證，請使用單一員工身分集區。
- 如果貴機構使用多個 IdP (例如因收購而使用)，請為每個 IdP 使用一個員工身分集區。
限制員工身分集區數量有助於確保下列事項：
- 將新工作負載加入 Google Cloud時，您不必建立或修改員工身分集區。
- 您可以使用 IAM，控管個別使用者可存取哪些專案和資源 Google Cloud 。
選擇有意義的專屬集區名稱
為確保主體 ID 全域不重複，員工身分會將員工身分集區名稱編碼至主體 ID。為員工身分集區選擇名稱時，請注意下列限制：
- 獨特性：選擇在 Google Cloud 中獨一無二的名稱，且未遭其他機構聲明擁有。
- 不可變更性：您無法變更工作團隊身分集區名稱。請選擇長期有意義的名稱，避免使用臨時的計畫名稱。
- 使用者體驗：視登入設定而定，使用者可能需要在登入時輸入集區名稱。選擇簡短好記的名稱。
將集區視為高權限資源
員工身分集區和提供者會決定使用者登入方式，並控管如何從外部 IdP 衍生身分和群組成員資格。由於這些元件會控管驗證邏輯，因此對 Google Cloud 貴機構的安全性至關重要。如果這些元件遭到入侵，不肖人士可能會發動詐騙攻擊。
為發動網路釣魚攻擊，惡意行為人可能會嘗試下列動作：
- 修改屬性對應：修改屬性對應後，惡意行為人就能以他人身分通過驗證，並取得未經授權的特殊權限。
- 新增惡意供應商：新增供應商後，惡意行為人就能略過貴機構的 IdP，並使用他們控制的其他 IdP 進行驗證。
員工身分集區和提供者是安全關鍵資源，因此需要下列保護措施：
- 限制非聯盟使用者的存取權：將管理存取權授予少數 Cloud Identity 或 Google Workspace 使用者，包括至少一位緊急存取使用者。
- 保護管理員使用者：要求所有管理員和緊急存取權使用者啟用兩步驟驗證。
- 即時存取權：使用 Privileged Access Manager (PAM) 即時授予管理員存取權，而非永久存取權。
將聯盟擴展至合作夥伴時，請考量風險
使用員工身分聯盟與外部 IdP 建立聯盟 Google Cloud ，即可建立信任關係。使用同盟時，您會依賴外部 IdP 執行下列動作：
- 執行符合安全規定的多重驗證 (MFA)。
- 準確聲明使用者身分和群組成員資格。
- 遵循身分治理程序，確保使用者能迅速離職，且群組成員資格能準確反映目前角色。
員工身分聯盟提供的機制有限，只能驗證外部 IdP 所做的判斷。具體來說，員工身分聯盟不支援「與 Cloud Identity 相同方式」的 SSO 後 MFA。
使用員工身分聯盟允許外部合作夥伴或承包商存取 Google Cloud 資源前，請先判斷這個信任等級是否合適。除非您信任合作夥伴及其 IdP 能持續符合您的安全標準，否則請勿使用員工身分聯盟功能授予合作夥伴存取權。
管理員工身分集區提供者
員工身分集區提供者會定義與外部 IdP 的聯盟關係，並包含下列設定：
- 用於單一登入的 IdP。
- 用於從 IdP 提供的權杖或判斷結果衍生主體 ID 的屬性對應。
- 選用：用於查詢群組成員資訊的 SCIM 租戶。
最佳做法：
選擇有意義的供應商名稱。使用 IdP 的應用程式入口網站公開個別服務。
每個集區使用單一供應商，避免主體發生衝突。
為 Google Cloud 控制台和 Gemini Enterprise 使用相同的集區和供應商。
使用租戶專屬的發行者 URI。
避免使用 OpenID Connect (OIDC) 隱含流程。
選擇有意義的供應商名稱
建立工作團隊身分集區提供者時，您必須為其指派名稱。
與員工身分集區名稱不同，這個名稱不必是全域不重複，也不會編碼為主體 ID。不過，視登入設定而定，使用者可能需要在登入時輸入提供者名稱。為提升使用者體驗，請選擇有意義且容易記住的名稱，例如 entra 或 staff。
請避免使用 oidc 或 saml 等名稱，因為使用者可能不熟悉這些縮寫。
在 IdP 應用程式入口網站中顯示個別服務
Microsoft Entra ID 和 Okta 等身分識別提供者提供應用程式入口網站，可讓使用者探索及存取已指派的應用程式。使用入口網站執行下列操作，提升使用者體驗：
- 設定入口網站，個別顯示相關的 Google 服務，而不是顯示單一 Google Cloud 連結。
- 設定連結，自動登入使用者。
下表列出支援員工身分聯盟的常見 Google 服務，以及自動登入的網址：
| 應用程式 | 網址 |
|---|---|
| Google Cloud 員工身分聯盟控制台，又稱控制台 (聯盟) | https://auth.cloud.google/signin/locations/global/workforcePools/POOL/providers/PROVIDER?continueUrl=https%3A%2F%2Fconsole.cloud.google |
| Gemini Enterprise | https://auth.cloud.google/signin/locations/global/workforcePools/POOL/providers/PROVIDER?continueUrl=https%3A%2F%2Fvertexaisearch.cloud.google%2Fhome%2Fcid%2FWEBAPP_ID |
| Gemini Notebook Enterprise | https://auth.cloud.google/signin/locations/global/workforcePools/POOL/providers/PROVIDER?continueUrl=https%3A%2F%2Fnotebooklm.cloud.google%2Fglobal%2F%3Fproject%3DPROJECT_NUMBER |
| IAP 網頁應用程式 | 應用程式網址，例如 https://iap.example.com/ |
更改下列內容：
POOL：員工身分集區名稱。PROVIDER：集區供應商名稱。WEBAPP_ID：Gemini Enterprise 網頁應用程式 ID。PROJECT_NUMBER：Gemini Notebook Enterprise 專案編號。
每個集區使用單一提供者，避免主體發生衝突
您可以使用員工身分聯盟，在工作團隊集區中新增多個提供者。在遷移期間，您可暫時允許使用者透過不同的 IdP 進行驗證，因此新增第二個供應商很有用。除了暫時情況外，請避免使用多個供應商，原因如下：
- 主體衝突：使用多個供應商會導致主體衝突的風險。在這種情況下，一個供應商的
google.subject屬性對應會傳回與另一個供應商相同的值。這項衝突會將多個外部身分對應至相同 IAM 主體，導致這些身分在 Cloud 稽核記錄 中無法區分。 - IAP 相容性：IAP 需要員工身分集區具有單一提供者，才能自動將未經驗證的使用者重新導向至 IdP。如果您新增其他供應商，IAP 就無法驗證使用者。
如要與多個供應商聯合，請建立多個員工集區，並為每個集區設定一個供應商。
為 Google Cloud 控制台和 Gemini Enterprise 使用相同的集區和供應商
如果您同時使用員工身分聯盟來存取 Gemini Enterprise 和 Google Cloud，請使用單一供應商，確保使用者能同時存取這兩項服務，不必再次登入。如果您使用不同的供應商，且屬性對應不同，使用者可能會遇到以下情況：他們透過不同供應商登入時，資源存取權會有所不同。
使用租戶專屬的發行者 URI
設定供應商時，您會指定核發者 URI，用來專屬識別 IdP。不過，視 IdP 設定而定，發行者 URI 可能不是貴機構租戶的專屬 URI。舉例來說，如果您使用一般或共用的核發者 URI (例如 Microsoft Entra ID 通用端點 https://login.microsoftonline.com/common/v2.0)，可能會不慎允許其他機構的使用者向貴機構驗證身分。 Google Cloud
為避免發生非預期的跨租戶存取，請使用租戶專屬的核發者 URI。如果 IdP 未提供租戶專屬的核發者 URI，請設定屬性條件，限制特定租戶的存取權。
避免使用 OpenID Connect (OIDC) 隱含流程
設定 OIDC 提供者時，請優先採用授權碼流程，而非隱含流程。OAuth 規格 2.1 版已淘汰隱含流程，因為這類流程容易發生權杖外洩和注入問題。使用授權碼流程有助於降低權杖遭攔截的風險。
管理使用者
您可以使用員工身分聯盟管理使用者。員工身分聯盟會執行下列步驟，從使用者權杖或聲明衍生使用者主體 ID：
- 套用
google.subject的屬性對應，判斷主體 ID。主體 ID 必須在員工身分集區中明確識別使用者，但不需要在 Google Cloud中保持不重複。 將主體 ID 附加至可識別員工身分集區的前置字串，即可衍生主體 ID。產生的主體 ID 在 Google Cloud 中是唯一的，格式如下：
principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/\ subject/SUBJECT
當透過員工身分聯盟驗證的使用者存取資源時，IAM 會使用主體 ID 評估允許政策中的角色繫結，並記錄在 Cloud 稽核記錄中。
使用不可變動的主體 ID
使用者主體 ID 變更時，主體 ID 也會變更。因此，系統 Google Cloud 不再將他們視為同一位使用者：
- 使用者無法存取先前獲准存取的資源，因為新的主體 ID 不再符合允許政策中列出的主體 ID。
- Cloud 稽核記錄項目只會包含新的主體 ID，無法再與使用舊主體 ID 的記錄建立關聯。
如要確保使用者主體 ID 穩定，請使用屬性對應，為 google.subject 產生穩定值。
許多 IdP 會自動為使用者產生專屬的數字或 UUID 格式 ID。這些 ID 具有唯一性且穩定，因此很適合做為 google.subject。不過，使用這些 ID 做為 google.subject 可能會產生冗長且難以辨識的主體 ID，不便於使用。
為協助您選擇 google.subject 的 ID，請依優先順序考量下列需求：
- 專屬性：這個值可專屬識別 IdP 中的使用者。
- 可用性：值有意義，或至少可在 IdP 的使用者目錄中輕鬆搜尋。
- 不可變動性：值不可變動，或至少只能由管理員變更。
請勿重複使用主體 ID
許多 IdP 會對特定使用者 ID 強制執行唯一性限制，但允許重複使用 ID。舉例來說，IdP 可能不允許您建立兩個具有相同使用者名稱 bob 的使用者。不過，一旦刪除使用者帳戶
bob，IdP 可能會允許您建立新使用者帳戶，並再次指派該使用者名稱 bob。
如果供應商的 google.subject 屬性對應是指可重複使用的使用者 ID，您可能會遇到主體衝突：如果舊使用者和新使用者的 google.subject 相同，Workforce Identity Federation 就無法區分兩者。因此，新使用者可能會存取僅供舊使用者使用的資源。
如要避免主體碰撞，請採取下列任一做法：
- 將
google.subject對應至 IdP 不允許重複使用的使用者 ID。 - 在 IdP 中刪除使用者時，請使用
locations.workforcePools.subjects.deleteAPI 刪除 Google Cloud中的使用者資料，並禁止使用相同的使用者 ID 登入，直到所有資料都已清除為止。
Microsoft Entra ID：使用 UPN 做為主體識別碼
只有在您使用 Microsoft Entra ID 做為 IdP 時，才適用這項最佳做法。
如果您使用 Microsoft Entra ID，可做為主體 ID 的 ID 包括：
- 使用者主體名稱 (
upn) - 物件 ID (
oid) - 電子郵件地址 (
proxyAddresses中的主要地址)
在這些選項中，我們建議使用使用者主體名稱做為主體 ID，原因如下：
- 所有使用者都有使用者主體名稱。
- 使用者主體名稱可明確識別使用者。
- 使用者主體名稱通常有意義且容易使用。
- 使用者主體名稱會嵌入網域名稱，用於明確識別使用者所屬的 Microsoft Entra ID 租戶。
- 貴機構可能已制定政策，禁止或控管使用者主體 ID 的重複使用行為。
相較之下，使用者物件 ID 和電子郵件地址較不適合，原因如下：
- 物件 ID (
oid) 格式為 GUID，且無法變更。這種格式難以處理，對人類來說也沒有意義。 - 電子郵件地址並非必要屬性，且可能不會為所有使用者填入。
無論選擇哪種 ID，建議您避免套用轉換，例如強制將 ID 設為小寫。
管理群組
員工身分聯盟可從下列來源判斷使用者的群組成員資格：
- IdP 提供的 SAML 聲明或 ID 權杖。
- 如果您使用 Microsoft Entra ID 做為 IdP，則為 Microsoft Graph API。
- 與工作團隊身分集區提供者相關聯的 SCIM 租戶。
根據預設，員工身分聯盟只會使用 SAML 宣告或 ID 權杖：
| 來源 | Google Cloud | Gemini Enterprise |
|---|---|---|
| SAML 或 ID 權杖 | ||
| Microsoft Graph API | - | - |
| SCIM 租戶 | - | - |
如果您使用 Microsoft Entra ID 做為 IdP，可以啟用額外屬性功能。接著，員工身分聯盟只會使用 Microsoft Graph API 做為群組成員的來源：
| 來源 | Google Cloud | Gemini Enterprise |
|---|---|---|
| SAML 或 ID 權杖 | - | - |
| Microsoft Graph API | ||
| SCIM 租戶 | - | - |
如果您使用 Gemini Enterprise，可以設定員工身分聯盟來使用 SCIM 租戶，這會導致以下行為發生變化：
- Gemini Enterprise 會使用 SCIM 租戶的群組成員資格，並忽略 SAML 判斷或 ID 權杖中的群組成員資格資訊。
- Google Cloud 使用 SAML 聲明或 ID 權杖中的群組成員資格資訊，並忽略 SCIM 租戶中的群組成員資格資訊。
| 來源 | Google Cloud | Gemini Enterprise |
|---|---|---|
| SAML 或 ID 權杖 | - | |
| Microsoft Graph API | - | - |
| SCIM 租戶 | - |
針對每個群組成員資格，員工身分聯盟會執行下列步驟，衍生主體 ID：
- 請採取下列任一行動來判斷群組 ID：
- SAML 判斷或 ID 權杖：套用屬性對應，適用於：
google.groups。 - SCIM 租戶：為
google.group套用權杖附加資訊對應。 - Microsoft Graph API：按照供應商設定中的
extra-attributes-type操作。
- SAML 判斷或 ID 權杖：套用屬性對應，適用於：
將群組 ID 附加至可識別員工身分集區的前置字串，即可衍生主體 ID。產生的主體 ID 在 Google Cloud 中是唯一的，格式如下：
principalSet://iam.googleapis.com/locations/global/workforcePools/\ POOL_ID/group/GROUP_ID
當透過員工身分聯盟驗證的使用者存取資源時，IAM 會使用這些主體 ID 評估允許政策中的角色繫結。
使用不可變更的群組 ID
所有 IAM 政策都會依據主體 ID 參照群組。在 IdP 中重新命名群組，導致群組 ID 變更時， Google Cloud 系統會將其視為不同群組：
- 現有的 IAM 角色繫結會繼續參照舊主體 ID，但會失效。
- 由於群組的新主體 ID 不再與任何 IAM 角色繫結相符，因此重新命名的群組成員會失去存取權。
為避免這類中斷，請設定屬性和聲明對應，使用穩定且不可變更的值，例如 IdP 產生的專屬 ID。請勿使用顯示名稱或電子郵件地址做為群組 ID，因為這些資訊可能會在機構變更時一併變動。
減少聲明或權杖中的群組成員資格
根據預設，IdP 可能會在 SAML 聲明或 ID 權杖中加入更多群組成員，超出管理 Gemini Enterprise 和 Google Cloud 資源存取權的需求。包含不必要的群組成員會造成多項風險：
- 部分存取權遺失：許多 IdP 會限制可在權杖或判斷中加入的群組成員資格數量。如果使用者超過這個上限 (群組超額)，IdP 可能會捨棄部分群組成員資格，導致使用者無法存取特定資源。
- 登入失敗：員工身分聯盟會限制
google.groups屬性對應可產生的群組成員資格大小和數量。如果使用者超過其中一項限制，就無法登入。 - 群組使用方式不一致：如果您將群組公開給 Google Cloud，專案擁有者可能會決定使用這些群組管理資源存取權，即使您從未打算在Google Cloud中使用特定群組。
您可以採取下列方法來降低這些風險，並減少斷言或權杖中的群組成員資格數量：
依群組類型篩選：部分 IdP (包括 Microsoft Entra ID) 可讓您設定篩選器，決定要在判斷或權杖中加入哪些群組。您可以設定篩選器，根據設定和您打算使用的服務，排除不相關的群組類型。
下表說明您可能需要在斷言或權杖中加入哪些類型的群組，具體取決於您打算使用的服務：
群組類型 Google Cloud Gemini (免同步) Gemini (SCIM) 存取群組 - 違規處置群組 - 組織群組 不需要 * - 協作群組 不需要 * - * 只有在使用以資料擷取為基礎的連接器時才須提供。
- 如要管理 Google Cloud的存取權，您必須加入存取權群組和強制執行群組。
- 管理 Gemini Enterprise 存取權所需的篩選條件，取決於您是否使用 SCIM。如果您使用 SCIM，Gemini Enterprise 會忽略斷言或權杖中包含的群組成員資格，因此您不需要納入任何 Gemini Enterprise 專屬群組。如果您未使用 SCIM，則必須加入 Gemini Enterprise 必要的存取群組和強制執行群組。視您是否打算使用以資料擷取為基礎的連結器而定，您可能也需要納入特定機構和協作群組。
指派：部分 IdP (包括 Microsoft Entra ID) 可讓您將權杖和聲明中的群組成員資格限制為已指派的群組，也就是您明確指派給信賴方設定的群組。
額外屬性篩選器：如果您使用 Microsoft Entra ID 並已啟用額外屬性功能，可以使用
--extra-attributes-filter標記指定篩選器。員工身分聯盟會在要求群組成員時，將這個篩選條件傳遞至 Microsoft Graph API。
如要測試或排解篩選器問題，請使用 Google Cloud 控制台中的「Debug IdP token」(偵錯 IdP 權杖) 工具，或啟用詳細稽核記錄。
Microsoft Entra ID：使用物件 ID 做為群組 ID
只有在您使用 Microsoft Entra ID 做為 IdP 時，才適用這項最佳做法。
如果您使用 Microsoft Entra ID，可做為群組 ID 的 ID 包括：
- 物件 ID (
oid) - 電子郵件地址
- 顯示名稱
在這些選項中，我們建議使用物件 ID (oid) 做為群組 ID，原因如下：
- 所有群組都有物件 ID。相較之下，電子郵件地址是選填欄位，可能只會為 Microsoft 365 群組填入。
- 物件 ID 不得重複，且無法變更。相較之下，群組的顯示名稱可以變更，且可能不具唯一性。
無論選擇哪個 ID，建議您避免套用轉換，例如強制將 ID 設為小寫。
管理存取權
存取限制和即時 (JIT) 管理的最佳做法。
最佳做法：
使用 Cloud Identity 使用者進行緊急存取。使用 Cloud Identity 取得高權限存取權。
使用機構政策限制來管理聯盟。
請勿授予集區的所有成員存取權。
限制工作階段時間長度。
配合即時存取權需求調整工作階段時間長度。
使用 Cloud Identity 使用者進行緊急存取
為確保您能持續存取 Google Cloud 環境，請為每個環境建立緊急存取使用者。
當服務設定錯誤、遭入侵或無法正常運作時，緊急存取權使用者可提供 Google Cloud 環境的存取權。緊急存取使用者具有高權限，如果依賴員工身分聯盟驗證緊急存取使用者，會產生下列風險：
- 工作團隊身分集區提供者設定有誤，可能會導致您無法登入。
- 如果外部 IdP 發生服務中斷問題，您可能無法在最需要時使用緊急存取使用者。
- 如果外部 IdP 遭到入侵，惡意行為者就能以緊急存取使用者的身分通過驗證，並取得您 Google Cloud資源的廣泛存取權。
為降低這些風險，請為緊急存取使用者採用 Cloud Identity 或 Google Workspace，即使您為其他使用者採用員工身分聯盟也一樣：
- 在 Cloud Identity 中建立緊急存取使用者。
- 將這些使用者排除在單一登入之外，讓他們使用使用者名稱和密碼驗證。
- 為這些使用者註冊兩步驟驗證，並使用安全金鑰，確保帳戶安全。
如要進一步瞭解緊急存取權使用者，請參閱「持續存取 Google Cloud的最佳做法」。
使用 Cloud Identity 取得高權限存取權
高權限使用者可廣泛存取您的 Google Cloud 環境。這類使用者包括：
- 具備組織管理員角色 (
roles/resourcemanager.organizationAdmin) 的使用者 - 具備「安全管理員」角色 (
roles/iam.securityAdmin) 或類似角色，可修改資源階層重要部分的允許政策 Google Cloud
如果您為高權限使用者啟用員工身分聯盟，外部 IdP 的任何設定錯誤或遭入侵情形，都可能影響 Google Cloud 資源的安全性。具體來說，如果外部 IdP 遭到入侵，惡意行為者就能以高權限使用者身分通過驗證，並取得 Google Cloud 資源的廣泛存取權。
為降低這些風險，請為高權限使用者採用 Cloud Identity：
- 在 Cloud Identity 中建立高權限使用者。
- 為這些使用者註冊兩步驟驗證，並使用安全金鑰，確保帳戶安全。
- 如果您已將 Cloud Identity 與外部 IdP 建立聯盟，請為這些使用者啟用額外的單一登入驗證和兩步驟驗證。
如果 IdP 已強制執行多重驗證，額外的單一登入驗證可能顯得多餘，但這項設定有助於在 IdP 遭到入侵時保護使用者。額外的單一登入驗證是 Cloud Identity 支援的功能，但員工身分聯盟不支援這項功能。
使用機構政策限制管理聯盟
如果您使用 Cloud Identity 的目的不是緊急或高權限存取，請依服務劃分 Cloud Identity 聯盟和員工身分聯盟的使用情況。如要強制執行這項做法，請使用自訂組織政策限制，限制特定專案中允許的主體類型。
舉例來說，您可以執行下列操作，將員工身分聯盟限制為 Gemini Enterprise：
- 對使用
MemberTypeMatches函式的 Gemini Enterprise 專案套用自訂組織政策限制，將允許的主體類型限制為iam.googleapis.com/WorkforcePoolPrincipal和iam.googleapis.com/WorkforcePoolPrincipalSet。這些是員工身分聯盟使用的主要類型。 - 對於所有其他專案，請套用限制，允許
iam.googleapis.com/WorkforcePoolPrincipal和iam.googleapis.com/WorkforcePoolPrincipalSet以外的所有主體類型。
使用自訂機構政策限制，有助於確保一致性，並防止意外使用錯誤的主體類型。
請勿授予集區所有成員存取權
員工身分聯盟支援使用下列格式的萬用字元主體 ID：
principalSet://iam.googleapis.com/locations/global/workforcePools/
POOL_ID/*
這個 ID 會比對 IdP 允許驗證Google Cloud的每位使用者。
請勿使用這個萬用字元 ID 授予權限。隨著 IdP 的使用者群組擴大，使用萬用字元主體 ID 授予存取權會導致權限過度。
請改為在 IdP 中建立存取群組，並使用這些群組管理資源存取權。這種做法可確保存取權是由有意的群組成員資格控管，而非驗證成功與否，進而降低授權過度的風險。
限制工作階段時間長度
使用者登入時，員工身分聯盟會啟動工作階段。使用者可透過工作階段執行下列操作：
- 使用並在控制台 (聯合)、Gemini Enterprise 或其他支援員工身分聯盟的入口網站之間切換。
- 使用受 IAP 保護的網頁應用程式。
- 取得聯合更新權杖和聯合存取權杖，例如執行
gcloud auth login。
在發生下列任一情況前，工作階段都會維持有效：
- 工作階段長度達到員工身分集區定義的上限。
- 工作階段長度達到使用者 SAML 判斷中的
SessionNotOnOrAfter屬性所定義的上限 (如有)。 - 使用者登出。
- 管理員撤銷使用者的工作階段。
如果允許工作階段在較長的時間內保持有效，權杖遭竊的風險就會增加，且群組成員資訊可能會過時：
- 如果從 IdP 撤銷權限，使用者可能會在一段時間內仍保有存取權。
- 使用者可能需要重新驗證並建立新的工作階段，才能使用新授予的存取權。
為降低這些風險，請限制工作階段長度，讓使用者每天至少要重新登入一次。
根據 JIT 存取權需求調整工作階段長度
如要管理具備特殊權限的存取權，您的 IdP 可能支援即時 (JIT) 群組，成員可以暫時啟用這類群組。使用即時群組管理 Google Cloud 或 Gemini Enterprise 的特殊存取權，可能會導致下列風險：
- 延遲啟用：如果使用者在啟用即時群組成員資格時，有有效的工作階段，則必須登出並重新登入，成員資格變更才會生效。或者，如果員工身分集區供應商使用 SCIM，則必須先佈建群組成員變更，成員變更才會生效。
- 延遲撤銷：如果群組成員資格到期，使用者必須登出並重新登入，或是使用 SCIM 佈建群組成員資格變更，才會失去具備權限的存取權。視工作階段長度而定，這項延遲可能會影響會籍到期目的。
為降低這些風險，請將工作團隊身分集區工作階段長度設定為足夠短。
監控活動
每當您發現可疑活動影響Google Cloud中的資源時，Cloud 稽核記錄會提供重要資訊，協助您判斷活動發生時間和涉及的使用者。
啟用資料存取記錄
員工身分聯盟可產生記錄，方便您追蹤登入和權杖交換活動。Security Token Service API 會寫入這些記錄，包括下列方法：
google.identity.sts.SecurityTokenService.WebSignIngoogle.identity.sts.SecurityTokenService.WebSignOutgoogle.identity.sts.v1.SecurityTokenService.ExchangeTokengoogle.identity.sts.v1beta.SecurityTokenService.ExchangeToken
所有與登入和權杖交換活動相關的記錄，都會歸類為資料存取記錄，且預設為停用。如要擷取這些記錄，請為整個Google Cloud 機構的 Security Token Service API 啟用資料存取權記錄。如要進一步提高登入記錄的詳細程度，請啟用詳細稽核記錄。
如要追蹤其他與驗證相關的活動，建議您啟用並使用下列記錄：
後續步驟
- 查看「員工身分聯盟總覽」。
- 瞭解如何管理集區和供應商。
- 瞭解如何撤銷員工身分聯盟使用者工作階段。