員工身分聯盟會將 Google Cloud 機構 Google Cloud 與外部識別資訊提供者 (IdP) 聯盟，以啟用單一登入 (SSO)。
您可以套用這些最佳做法，有效使用員工身分聯盟，並將安全風險降到最低。
選擇合適的架構
以下各節說明選擇符合需求的聯盟架構時，應考量的主要因素。
選擇聯盟架構模式
以下四種模式說明將機構與外部 IdP 連結的常見方式： Google Cloud
進行同盟作業前，請先考量每種模式的優點和限制，然後選擇符合您需求的模式。詳情請參閱「身分聯盟的架構模式」。
依服務劃分聯盟用量
一般來說，我們建議您依服務 (而非使用者) 劃分同盟使用量。整體而言，按服務劃分用量較少缺點。
為降低複雜度，建議使用 Cloud Identity 或員工身分聯盟。不過，視需求而定，您可能需要並行使用這兩者，如混合模式所述。
如果您同時使用 Cloud Identity 聯盟和 Workforce Identity Federation，可以透過下列方式劃分使用情況：
依使用者劃分：將使用者劃分為兩組，一組使用員工身分聯盟，另一組使用 Cloud Identity 聯盟。
- 優點：每位使用者在 Google 服務中都只有一個身分，且登入方式相同。
缺點：依使用者劃分區隔有幾個缺點，包括：
管理存取群組可能很複雜，因為 IAM 允許政策必須包含主體類型組合，而且您無法對 Cloud Identity 和員工身分聯盟使用者使用相同群組。
不同群組的使用者無法共用連結，因為 Google Cloud 控制台、Gemini Enterprise 和其他工具會根據使用者的登入方式，使用不同的網址。
不同同類群組的使用者可能可以存取不同的功能組合。
依服務劃分：設定各項服務 (例如Google Cloud 或 Gemini Enterprise)，只允許員工身分聯盟使用者或 Cloud Identity 使用者存取，但絕不允許兩者同時存取。
- 優點：簡化管理作業，確保不同使用者都能獲得一致的功能組合。
- 缺點：部分員工可能需要指派兩個身分，一個使用 Workforce Identity Federation，另一個使用 Cloud Identity。
建議依服務進行分割，特別是將 Gemini Enterprise 和 NotebookLM Enterprise 與其他服務分開。Gemini Enterprise 和 Google Cloud 控制台是不同的工具，適用於不同的工作。登入程序如有任何差異，對整體使用者體驗的影響應微乎其微。
如要強制執行這項分割作業，請使用組織政策限制。
加強群組管理
您應使用群組管理存取權，並建立明確的群組管理程序，以便有效使用員工身分聯盟。
驗證期間不會決定使用者存取資源的權限。而是根據附加至該特定資源的政策，在使用者嘗試存取資源時評估存取權。這些政策包括：
政策會定義個別主體或主體集的存取權：
主體：透過主體 ID 識別的已驗證使用者。 員工主體 ID 類似於以下內容：
principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/subject/SUBJECT主體 ID 包含下列項目：
POOL_ID：員工身分集區的專屬 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：授予開發環境中 Compute Engine VM 的 OS 登入存取權。相較之下，下列類型的群組通常不適合做為存取權群組：
廣泛的管理員群組 (例如
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 無法存取使用者在這些群組中的成員資格，可能無法正確評估使用者是否有權存取這些文件。
- 共用筆記本：使用者可以透過 NotebookLM 共用筆記本。允許使用者與協作群組共用筆記本，通常比限制只能與個別使用者共用更方便。
如要確保機構和協作群組僅供 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 連結。
- 設定連結，讓使用者自動登入。
下表列出支援 Workforce Identity Federation 的常見 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 |
| NotebookLM 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：NotebookLM Enterprise 專案編號。
每個集區使用單一供應商，避免主體衝突
您可以使用員工身分聯盟，在員工集區中新增多個提供者。在遷移期間，您可暫時允許使用者透過不同的 IdP 進行驗證，因此新增第二個供應商很有用。除了暫時情況外，請避免使用多個供應商，原因如下：
- 主體衝突：使用多個供應商會導致主體衝突的風險。發生這類衝突時，其中一個供應商的
google.subject屬性對應會傳回與另一個供應商相同的值。這項衝突會將多個外部身分對應至相同 IAM 主體，導致這些身分在 Cloud 稽核記錄中無法區分。 - IAP 相容性：IAP 要求工作負載身分集區只能有一個提供者，才能自動將未通過驗證的使用者重新導向至 IdP。如果您新增其他供應商，IAP 就無法驗證使用者。
如要與多個供應商同盟，請建立多個員工集區，並為每個集區設定一個供應商。
為 Google Cloud 控制台和 Gemini Enterprise 使用相同的集區和供應商
如果您同時使用員工身分聯盟來存取 Gemini Enterprise 和 Google Cloud，請使用單一供應商，確保使用者能同時存取這兩項服務，不必再次登入。如果您使用不同的屬性對應，使用者可能會遇到以下情況：根據登入時使用的提供者，他們對資源的存取權會有所不同。
使用租戶專屬的核發者 URI
設定供應商時，請指定核發者 URI，以專屬方式識別您的 IdP。不過，視 IdP 設定而定，發行者 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 變更時，主體識別碼也會變更。 因此， 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。舉例來說，身分識別提供者可能不允許您建立兩個具有相同使用者名稱 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，原因如下：
- 所有使用者都有使用者主體名稱。
- 使用者主體名稱可做為使用者的專屬 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 支援額外的 SSO 驗證，但員工身分聯盟不支援。
使用機構政策限制控管聯盟
如果您使用 Cloud Identity 的目的不是緊急或高權限存取，請依服務劃分 Cloud Identity 聯盟和 Workforce Identity Federation 的使用情況。如要強制執行這項做法，請使用自訂機構政策限制，限制特定專案中允許的主體類型。
舉例來說，您可以執行下列操作，將員工身分聯盟限制為僅限 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 的資料存取記錄。如要進一步提高登入記錄的詳細程度，請啟用詳細稽核記錄。
如要追蹤其他驗證相關活動，建議您啟用並使用下列記錄：