本文提供最佳做法和指南，協助您以一致且安全的方式設定同盟。本指南以搭配使用 Cloud Identity 或 Google Workspace 與 Google Cloud 的最佳做法為基礎。
所有 Google 服務 (包括 Google Marketing Platform 和 Google Ads) 都會使用 Google 登入驗證使用者身分。 Google Cloud您不必為每位員工手動建立及維護 使用者帳戶，而是可以將 Cloud Identity 或 Google Workspace 與外部身分識別提供者 (IdP) 聯合，例如 Active Directory 或 Azure Active Directory。設定連結通常需要執行下列操作：
對應身分
由 Cloud Identity 或 Google Workspace 管理的使用者帳戶，會以主要電子郵件地址做為識別身分。主要電子郵件地址會顯示為 Google 帳戶電子郵件地址，位於Google 帳戶頁面。 如要視為有效，主要電子郵件地址必須使用您已新增至 Cloud Identity 或 Google Workspace 帳戶的其中一個網域。
主要電子郵件地址也可用於下列用途：
- 主要電子郵件地址是使用者登入時必須提供的使用者名稱。雖然使用者可以為 Google 使用者帳戶新增備用電子郵件地址或別名，但這些地址不視為身分，無法用於登入。
- 管理員需要傳送通知給使用者時 (例如宣布潛在安全風險)，系統只會將通知傳送至主要電子郵件地址。
如要在 Google 和外部 IdP 之間設定單一登入和自動使用者佈建，您必須將外部 IdP 中的身分對應至 Cloud Identity 或 Google Workspace 中的對應身分。下列各節將說明建立這項對應的最佳做法。
在所有聯合系統中使用相同身分
如要建立對應，您只需確認 IdP 提供給 Google 的 SAML 判斷包含 NameID 聲明，且該聲明的值與現有 Cloud Identity 或 Google Workspace 使用者的主要電子郵件地址相符。IdP 可自由使用任何適用的對應或邏輯，為現有使用者衍生合適的 NameID 聲明。
許多 IdP 依賴電子郵件地址 (或更廣泛地說，符合 RFC 822 的名稱) 來識別使用者。例如：
- Active Directory 中的
userPrincipalName屬性是符合 RFC 822 的名稱，可專門識別使用者，並用於登入 Windows 或 Active Directory Federation Services (AD FS)。 - Azure Active Directory 會使用
UserPrincipalName屬性識別使用者並允許登入。
如果外部 IdP 管理的使用者已將電子郵件地址做為身分，您可以在 Cloud Identity 或 Google Workspace 中，將該身分做為主要電子郵件地址。在聯合系統中使用相同的使用者身分有多項優點：
使用者登入 Google 工具 (例如Google Cloud 控制台) 時，系統會先提示他們提供 Cloud Identity 或 Google Workspace 使用者的主要電子郵件地址，然後將他們重新導向至外部 IdP。視 IdP 而定，使用者可能會看到另一個登入畫面，提示輸入使用者名稱和密碼。
如果這些步驟的電子郵件地址不同，登入畫面的順序可能會讓使用者感到困惑。相反地，如果使用者可以在所有步驟中使用通用身分，就不會感覺到 IdP 之間的技術差異，以儘可能避免引起混淆。
如果不需要對應使用者身分，您就能更輕鬆地將 Google Cloud 的稽核記錄與內部部署系統的記錄相互關聯。
同樣地，如果部署在內部和Google Cloud 的應用程式需要交換含有使用者身分識別的資料，您就不必對應使用者 ID，避免額外的複雜性。
如要進一步瞭解如何將 Active Directory 使用者或 Azure AD 使用者對應至 Cloud Identity 或 Google Workspace，請參閱「Active Directory」或「Azure AD」指南。
確認身分使用可路由傳送的電子郵件地址
Google Cloud 會使用使用者的主要電子郵件地址傳送通知電子郵件。這類通知的例子包括：
預算快訊：如果您已設定預算快訊，當預算超過門檻時，系統會傳送通知給帳單管理員和帳單使用者。Google Cloud
付款通知：系統會將任何付款相關通知或快訊，傳送至受影響帳單帳戶中設定的付款使用者電子郵件地址。
專案邀請：如果您將專案管理員角色指派給使用者，而該使用者所屬的 Cloud Identity 或 Google Workspace 帳戶，與專案所屬機構的帳戶不同，系統會傳送邀請給該使用者。使用者必須點選電子郵件訊息中的連結接受邀請，新授予的角色才會生效。
客服案件的回覆內容，以及支援團隊的其他通知。
如果您使用 Google Workspace，並已正確設定必要的 DNS MX 記錄，系統會將傳送至主要電子郵件地址的所有通知電子郵件，傳送至對應使用者的 Gmail 收件匣。
如果是 Cloud Identity 使用者， Google Cloud 系統也會嘗試傳送通知電子郵件，但電子郵件必須由現有的電子郵件基礎架構處理。為確保 Cloud Identity 使用者不會錯過通知，請確認現有電子郵件系統可接收傳送至 Cloud Identity 使用者主要電子郵件地址的郵件，並將這類郵件轉送至正確的信箱。請執行下列步驟：
確認新增至 Cloud Identity 的所有網域，都有指向現有電子郵件系統的 DNS MX 記錄。
確認 Cloud Identity 使用者的主要電子郵件地址與電子郵件系統中的現有信箱相符。如果 Cloud Identity 使用的主要電子郵件地址與使用者的電子郵件地址不符，請在現有電子郵件系統中設定別名，確保傳送至各個主要電子郵件地址的郵件都會轉送至正確的信箱。
如果這些解決方案不切實際，建議您在現有的 Cloud Identity 帳戶中新增 Google Workspace，並將 Google Workspace 授權指派給負責帳單或與支援團隊互動的主要使用者，因為他們最有可能收到通知。
評估現有個人帳戶的遷移選項
如果貴機構註冊 Cloud Identity 或 Google Workspace 前，員工已使用 Google 服務 (例如 Google Ad Manager、Google AdSense 或 Google Analytics)，他們可能使用消費者帳戶存取這些服務。
讓員工使用個人帳戶從事商業行為可能會有風險。如要進一步瞭解這些風險，以及如何找出現有的消費者帳戶，請參閱「評估現有 Google 帳戶」。
您可以透過下列方式處理現有的個人帳戶：
- 維持現狀，接受潛在風險。
- 發起轉移作業，將帳戶遷移至 Cloud Identity 或 Google Workspace。
- 強制要求非受管使用者帳戶擁有者變更電子郵件地址，改用其他網域。
如要進一步瞭解如何整合現有個人帳戶，請參閱「評估身分整合選項」。
您決定如何處理個人帳戶，會影響您設定聯盟的方式和順序。開始在 Cloud Identity 或 Google Workspace 中建立使用者帳戶或設定單一登入之前，請先評估使用者現有的個人帳戶。
對應身分集
定義外部 IdP 與 Cloud Identity 或 Google Workspace 之間個別身分對應方式後，您必須決定要為哪些身分啟用 Google 服務存取權。
可向 Google 服務驗證身分的有效身分集，是下列兩組的交集：
- 對應至 Cloud Identity 或 Google Workspace 中身分的外部身分。
外部 IdP 允許單一登入 Cloud Identity 或 Google Workspace 的外部身分。
控管單一登入使用權的程序會因您使用的 IdP 而異。舉例來說，Azure AD 依賴指派，而 AD FS 則使用存取控制政策。
限制可向 Google 服務驗證身分的一組身分
視您打算如何使用 Google Cloud、Google Workspace 和其他 Google 工具而定，貴機構的所有員工或只有部分員工必須能夠向 Google 服務進行驗證。
如果您只打算授予部分機構員工 Google 服務存取權，最好將驗證限制為這組使用者。限制可通過驗證的使用者人數，可建立額外的防禦層，萬一您不小心將任何存取權控管規則設定得過於寬鬆，這項措施就能派上用場。
您可以透過下列方式，限制可向 Google 驗證的使用者：
- 盡量減少 Cloud Identity 或 Google Workspace 中的使用者帳戶數量。如果沒有對應的使用者帳戶，即使 IdP 允許使用者透過單一登入登入 Cloud Identity 或 Google Workspace，使用者嘗試驗證身分時仍會失敗。
- 在 IdP 中設定單一登入，盡量減少可登入 Cloud Identity 或 Google Workspace 的使用者人數。
最佳做法取決於您是否需要遷移現有的個人帳戶。
如果仍需遷移消費者帳戶，請限制您佈建的身分識別組合
只有在 Cloud Identity 或 Google Workspace 中，您尚未建立具有相同身分的使用者帳戶時，才能將一般帳戶遷移至 Cloud Identity 或 Google Workspace。
如果您有現有的個人帳戶，且仍打算遷移，請務必小心，以免誤建衝突的使用者帳戶。請遵守下列規範：
- 只為需要帳戶且已知沒有現有消費者帳戶的使用者建立新的 Cloud Identity 或 Google Workspace 使用者帳戶，藉此限制驗證。
- 為避免遷移的帳戶遭到意外鎖定，請允許單一登入，不僅適用於您在 Cloud Identity 或 Google Workspace 中建立使用者帳戶的使用者，也適用於所有尚未遷移的消費者帳戶。
下圖顯示不同類型的身分識別如何重疊及相互關聯。
在圖表中，擁有 Cloud Identity 或 Google Workspace 使用者帳戶的身分位於最小的 (黃色) 橢圓中。該橢圓形包含在第二個 (藍色) 橢圓形中，後者包含可進行驗證的身分。第三個也是最大的橢圓 (灰色) 包含其他橢圓，且由在 IdP 中擁有使用者帳戶的身分組成。如要瞭解如何設定 Active Directory、Azure AD 或 Okta，請參閱這份最佳做法指南。
禁止註冊新的消費者帳戶
在 Cloud Identity 或 Google Workspace 帳戶中新增網域 (例如 example.com) 後，員工仍可使用該網域註冊新的消費者帳戶。這些新消費者帳戶會在 Cloud Identity 或 Google Workspace 帳戶中顯示為非受管使用者，但無法使用單一登入，或您在 Cloud Identity 或 Google Workspace 帳戶中套用的任何其他設定。
如要禁止建立新的個人帳戶，其中一種方法是在 Cloud Identity 或 Google Workspace 中，使用相同的電子郵件地址建立使用者帳戶。舉例來說，如果您在 Cloud Identity 或 Google Workspace 帳戶中建立使用者 alice@example.com，員工嘗試使用相同身分註冊新的個人帳戶時就會失敗。不過，如果 Cloud Identity 或 Google Workspace 中沒有對應的使用者，則註冊新個人帳戶就會成功。
如果沒有其他個人帳戶要遷移至 Cloud Identity，請套用下列設定，防止使用者註冊新的個人帳戶：
限制驗證，只允許相關使用者透過單一登入服務登入 Cloud Identity 或 Google Workspace。
為所有員工佈建 Cloud Identity 或 Google Workspace 使用者。確認使用者帳戶使用員工的公司電子郵件地址做為主要電子郵件地址或別名，這樣一來，就無法使用相同電子郵件地址建立新的個人帳戶。如有可能，請將未啟用單一登入的使用者帳戶設為停權狀態。
下圖說明的就是這項設定。
如果您仍在遷移個人帳戶，可以擷取註冊程序中傳送的驗證電子郵件，暫時監控新個人帳戶的註冊情形。驗證電子郵件使用的郵件寄件者地址與 *@idverification.bounces.google.com 相符。在電子郵件系統中設定篩選器，找出含有這個郵件寄件者地址的電子郵件，並保留這些郵件以供內部審查。
將 Cloud Identity 或 Google Workspace 身分設為外部 IdP 身分的子集
您的 Cloud Identity 或 Google Workspace 帳戶可能包含身分無法對應至外部 IdP 中任何使用者的使用者帳戶。通常有兩種情況會導致出現這類使用者帳戶：
- 您在 Cloud Identity 或 Google Workspace 中建立新的使用者帳戶，並使用未對應至外部 IdP 中任何使用者的主要電子郵件地址。
- 您在 Cloud Identity 或 Google Workspace 中有對應至外部 IdP 身分的使用者帳戶，但隨後刪除了外部 IdP 中的身分。舉例來說，如果員工離職，您可能會刪除該身分。
在 Cloud Identity 或 Google Workspace 中啟用單一登入後，系統會強制所有使用者 (超級管理員除外) 使用單一登入。如果 Cloud Identity 或 Google Workspace 使用者帳戶未對應至外部 IdP 中的身分，任何單一登入嘗試都會失敗。如果使用者帳戶沒有對應的帳戶，就會失效，但仍可能造成風險，例如：
如果單一登入功能暫時或永久停用，使用者帳戶就能再次使用。這可能會導致離職員工登入並存取公司資源。
您或許可以重複使用已刪除使用者帳戶的名稱。舉例來說，新進員工可能與幾個月或幾年前離職的員工同名。如果先前員工的使用者帳戶已遭刪除，您或許可以為新員工指派先前員工使用的使用者名稱。
新員工的使用者帳戶可能與前員工的內部 ID 不同。不過，從同盟的角度來看，如果兩個使用者帳戶都對應至 Cloud Identity 或 Google Workspace 中的同一個主要電子郵件地址，系統就會將這兩個帳戶視為相同。因此，新進員工登入 Google 時，可能會「沿用」前任員工的現有資料、設定和權限。
Cloud Identity 和 Google Workspace 超級管理員使用者可免除使用單一登入的規定，但如果登入作業是由 IdP 啟動，他們仍可使用單一登入。如果超級管理員使用者沒有外部 IdP 中的對應項目，使用 IdP 啟動的單一登入功能可能會導致他們對搶註網域名稱的行為很敏感。
請參考以下範例：Alice 在 Cloud Identity 或 Google Workspace 中擁有超級管理員使用者，但並未使用兩步驟驗證。alice-admin@example.comMallory 不知道 Alice 的密碼，但他找到方法在外部 IdP 中建立對應至 alice-admin@example.com 的新使用者。雖然這個新建立的使用者帳戶可能沒有任何特殊權限，也與 Alice 的使用者帳戶無關，但由於這個帳戶現在與 Alice 的超級管理員帳戶共用身分，Mallory 就能使用 IdP 啟動的單一登入功能，並以 alice-admin@example.com 身分通過驗證。
為降低這種名稱搶註風險，請確保 Cloud Identity 或 Google Workspace 身分是外部 IdP 身分的子集。如要達成這個目標，最好的方法是將外部 IdP 實作的整個使用者帳戶生命週期，對應至 Cloud Identity 或 Google Workspace 中的使用者帳戶生命週期。
使用專用的超級管理員使用者
Google Workspace 和 Cloud Identity 超級管理員帳戶具有強大的權限，不僅適用於 Cloud Identity 或 Google Workspace 帳戶，也適用於相關聯的 Google Cloud 機構。因為只有少數活動需要超級管理員權限，所以請盡可能限制具備超級管理員存取權的管理員人數，並使用權限較低的使用者帳戶管理帳戶或機構的日常事務 Google Cloud 。
找出需要超級管理員存取權的管理員後，請建立專用的超級管理員使用者帳戶，例如：
- 建立身分識別為
alice@example.com的使用者帳戶，並指派一般權限。這個帳戶應做為日常帳戶，用於例行活動。 建立第二個使用者帳戶，身分識別為
alice-admin@example.com，並指派超級使用者權限。最佳做法是讓 Alice 只在需要超級管理員權限時，才使用這個帳戶。為確保傳送至這個電子郵件地址的通知電子郵件能順利送達使用者信箱，請設定 Google Workspace 或現有電子郵件系統，將電子郵件地址
alice-admin@example.com設為別名，或將郵件轉寄至alice@example.com。
請確認外部 IdP 可辨識這兩種身分，這樣 Cloud Identity 或 Google Workspace 中的身分組合才會繼續是外部 IdP 中身分的子集。
建議您為這些專屬超級管理員帳戶採用命名架構，以便在稽核記錄中追蹤帳戶的使用位置和方式。舉例來說，請在使用者名稱中加入 -admin，如上一個範例所示。
限制 Google Workspace 和 Cloud Identity 的服務使用者人數
外部 IdP 可能不僅包含員工的使用者帳戶，也包含供機器使用者 (例如應用程式、工具或背景作業) 使用的帳戶。
相較之下，啟用應用程式以驗證及存取 Google API 的建議做法，是實作下列其中一種方法： Google Cloud
如果網頁應用程式或工具需要代表使用者存取 Google API 或服務，請使用 OAuth 2.0 或 OpenID Connect。應用程式會先透過這些通訊協定徵求使用者同意存取資料，取得同意後，就能代表使用者執行存取作業。
如果 API 或服務的存取權不應代表使用者，而是代表應用程式本身，建議使用Google Cloud 服務帳戶進行驗證，然後使用 IAM授予服務帳戶資源存取權。
如果 Google Cloud 服務帳戶在 IAM 中獲得適當角色，就能用於驗證及使用任何 Cloud API。如要授予服務帳戶存取Google Cloud以外的 API，例如 Directory API 或 Drive API，可以使用 Google Workspace 網域範圍授權。
透過 Google Workspace 網域範圍的委派，您可以讓服務帳戶代表 Cloud Identity 或 Google Workspace 使用者執行動作。由於委派是強大的權限，因此我們建議您只在 OAuth 方法不切實際的情況下，才使用 Google Workspace 網域範圍委派。
為每個已啟用 Google Workspace 網域範圍委派的服務帳戶，使用專屬的 Cloud Identity 或 Google Workspace 使用者。Google Cloud 在外部 IdP 中建立這個使用者，然後將其佈建至 Cloud Identity 或 Google Workspace，確保 Cloud Identity 或 Google Workspace 中的使用者組合仍是外部 IdP 中使用者的子集。
請避免在 Cloud Identity 和 Google Workspace 中建立服務使用者，以免這些使用者用於 Google Workspace 網域範圍授權。
對應使用者帳戶生命週期
外部 IdP 中的使用者帳戶會經歷特定生命週期。通常，這個生命週期會反映員工與公司之間的僱傭關係：
- 為加入機構的員工建立新的使用者帳戶。
- 使用者帳戶可能會暫時停權，之後再重新啟用，例如員工請假時。
- 使用者離職時，系統會刪除使用者帳戶，或將帳戶停權一段保留時間，然後再刪除。
下圖說明這個生命週期。
本節列出最佳做法，確保 Cloud Identity 或 Google Workspace 中的使用者帳戶生命週期，與外部 IdP 中對應的使用者帳戶生命週期一致。
將外部 IdP 指定為可靠資料來源
許多人力資源資訊系統 (HRIS)、IdP 和轉接程式僅支援單向使用者佈建。也就是說，在 HRIS 或 IdP 中進行的變更會傳播至 Cloud Identity 或 Google Workspace，但 Cloud Identity 或 Google Workspace 中進行的變更不會傳播回去。
為避免單向佈建造成不一致，請將外部 IdP 指定為可靠資料來源。完全使用外部 IdP (或 HRIS) 建立、修改或刪除使用者，並透過自動佈建功能將變更傳播至 Google Workspace 和 Cloud Identity。將外部 IdP 指定為可靠資料來源，可降低不一致的風險，並避免手動修改遭到 IdP 覆寫。
自動將使用者帳戶佈建至 Cloud Identity 或 Google Workspace
如要讓員工透過單一登入服務向 Google 驗證身分，您必須先在 Cloud Identity 或 Google Workspace 中為員工建立使用者帳戶。為確保與外部 IdP 的一致性，建議您自動在 Cloud Identity 或 Google Workspace 中佈建這些使用者帳戶：
- 自動佈建可確保 Cloud Identity 或 Google Workspace 身分一律是外部 IdP 中的身分子集。
- 這樣一來，您就能盡量避免 Cloud Identity 或 Google Workspace 中的身分與外部 IdP 中的對應身分不一致。如果電子郵件地址不相符 (例如不小心拼錯)，員工可能會無法登入。
- 大幅減少手動管理作業。
如果您使用 HRIS 管理新進人員的入職程序，可以設定 HRIS，同時將使用者帳戶佈建至外部 IdP 和 Cloud Identity 或 Google Workspace，藉此自動佈建使用者帳戶，如下圖所示。
如要讓這項設定正常運作，請務必確保 HRIS 系統會佈建使用者帳戶，以便正確相互對應。此外，HRIS 必須處理要將哪些使用者帳戶佈建至 Cloud Identity 或 Google Workspace 的決策。
如要自動佈建使用者帳戶，但不想使用人力資源資訊系統，可以改用外部 IdP 做為權威來源，在 Cloud Identity 或 Google Workspace 中佈建使用者帳戶。在這種設定中，對應使用者帳戶和使用者帳戶集的設定會由 IdP 或介面卡管理，如下圖所示。
如果您使用 Active Directory 做為 IdP，可以使用 Google Cloud 目錄同步複製這項設定。其他 IdP (例如 Azure AD 或 Okta) 內建的介面卡可將使用者佈建至 Google Workspace。由於 Google Workspace 和 Cloud Identity 採用相同平台並使用相同 API，這些轉接程式也適用於 Cloud Identity。
將停權事件傳播至 Cloud Identity 或 Google Workspace
當員工暫時或永久離開機構時，建議您撤銷該員工的 Google 服務存取權。在外部 IdP 中暫停員工的使用者帳戶後，系統會撤銷員工透過單一登入驗證 Google 服務的權限，但這可能無法完全撤銷員工對所有 Google 服務的存取權。但仍可能發生下列情況：
- 如果 Cloud Identity 或 Google Workspace 使用者有作用中的瀏覽器工作階段，該工作階段會繼續運作。已取得的 OAuth 權杖仍有效。
- 如果使用者具備超級管理員權限，或是您已設定網路遮罩，員工可能仍可使用密碼登入。
- 使用者帳戶可能仍會收到來自Google Cloud的通知，包括預算快訊。
- 如果使用者已獲派 Google Workspace 授權，系統會繼續將電子郵件傳送至使用者的信箱，地址簿中仍會顯示該使用者，Google 日曆也可能仍會將該使用者列為可邀請對象。
- 如果您允許使用者採用低安全性應用程式，使用者可能仍可使用應用程式密碼存取 Gmail、Google 日曆和其他資料。
如要完全撤銷 Google 服務的存取權，請透過下列方式將停權事件傳播至 Cloud Identity 或 Google Workspace：
請確保外部 IdP 中的使用者帳戶停權時，Cloud Identity 或 Google Workspace 中對應的使用者帳戶也會停權。在 Cloud Identity 或 Google Workspace 中暫停使用者帳戶後，系統會終止有效瀏覽器工作階段、使權杖失效，並撤銷所有其他存取權。
同樣地，在外部 IdP 中重新啟用使用者帳戶時，請務必同時在 Cloud Identity 或 Google Workspace 中重新啟用對應的使用者帳戶。
在 Cloud Identity 或 Google Workspace 中暫停使用者帳戶不會造成任何損害。使用者帳戶停權期間，系統會保留使用者資料、Google Workspace 授權維持不變，且 Google Cloud 中指派的角色也不會變動。
將刪除事件傳播至 Cloud Identity 或 Google Workspace
員工永久離職時，您可能不只會決定在外部 IdP 中停權該員工的使用者帳戶，還會刪除該帳戶。
如果您刪除外部 IdP 中的使用者帳戶，但未刪除對應的 Cloud Identity 或 Google Workspace 使用者，則 Cloud Identity 和 Google Workspace 中的使用者集不再是外部 IdP 中的使用者子集。如果新進員工與離職員工同名，日後可能會造成問題。如果您在 IdP 中為新員工建立使用者帳戶，可能會重複使用舊員工的使用者名稱，導致新使用者帳戶對應至 Cloud Identity 或 Google Workspace 中的舊使用者帳戶。因此，新員工可能會存取舊員工的資料和設定。
如要避免孤立的 Cloud Identity 或 Google Workspace 使用者帳戶造成風險，請在 IdP 中刪除對應的使用者帳戶後，立即刪除 Cloud Identity 或 Google Workspace 使用者。
刪除 Cloud Identity 或 Google Workspace 使用者是破壞性作業，只能在特定時間範圍內復原。 視使用者使用的 Google 服務而定，刪除使用者可能會導致相關資料永久刪除，因此可能無法滿足您的法規遵循要求。
如要在永久刪除使用者前，先保留特定時間的使用者設定和資料，請採取下列其中一種做法：
將使用者帳戶在外部 IdP 中設為停權狀態，並保留一段時間，即可延後刪除帳戶。保留期限過後，請在 IdP 和 Cloud Identity 或 Google Workspace 中刪除使用者。
在外部 IdP 中刪除使用者帳戶時，請停權對應的 Cloud Identity 或 Google Workspace 使用者，並將主要電子郵件地址變更為不太可能造成衝突的名稱。舉例來說，將
alice@example.com重新命名為obsolete-yyyymmdd-alice@example.com，其中yyyymmdd反映外部 IdP 中刪除的日期。將重新命名的使用者帳戶保留在停權狀態一段時間，然後在保留期限過後刪除。
如要保留已停權使用者的 Google Workspace 資料，請保留指派給該使用者的 Google Workspace 授權，或改用封存使用者授權，確保Google Workspace 保管箱保留規則持續套用，並保留使用者資料。
單一登入
所有 Google 產品 (包括 Google Ads 和 YouTube 等服務) 都會使用 Google 登入驗證使用者身分。 Google Cloud服務會將使用者重新導向至 accounts.google.com，藉此啟動驗證程序。使用者會在該處看到 Google 登入畫面，並收到電子郵件地址提示。系統會根據提供的電子郵件地址網域，在 Gmail、消費者帳戶目錄中尋找使用者帳戶，或是在網域與主要、次要或別名網域相符時，在 Cloud Identity 或 Google Workspace 帳戶中尋找。
下圖說明這個驗證程序。
如果設定 Cloud Identity 或 Google Workspace 帳戶使用單一登入，使用者就會重新導向至外部 IdP 進行驗證。外部 IdP 完成驗證後，系統會透過 SAML 聲明將結果轉送回 Google 登入。這項 SAML 聲明可做為驗證成功的證明。聲明會包含使用者的電子郵件地址，並由外部 IdP 的憑證簽署，因此 Google 登入服務可以驗證其真實性。
這個程序稱為「服務供應商啟動的單一登入」，適用於超級管理員以外的所有使用者。系統一律不會將超級管理員重新導向至外部 IdP，而是提示輸入密碼。
部分 IdP 也支援由 IdP 啟動的單一登入。在這個模型中，使用者會在外部 IdP 進行驗證，然後點選指向 Google 服務 (例如 Google Cloud 或 Google Ads) 的連結。如果已為 Cloud Identity 或 Google Workspace 帳戶啟用單一登入，該帳戶的所有使用者 (包括超級管理員) 都可以使用 IdP 啟動的單一登入。
盡量減少 SAML 聲明中傳遞的屬性集
使用者在外部 IdP 完成驗證後，Cloud Identity 或 Google Workspace 會使用外部 IdP 傳遞的 SAML 聲明建立工作階段。除了驗證真偽，這個程序還包括找出與 SAML 聲明中 NameID 值相應的 Cloud Identity 或 Google Workspace 使用者帳戶。
NameID 值應包含要驗證的使用者帳戶主要電子郵件地址。電子郵件地址會區分大小寫，系統不會考量別名和備用電子郵件地址。
為避免拼字或大小寫不符，建議自動佈建使用者帳戶。
SAML 聲明可包含其他屬性，但驗證時不會考量這些屬性。系統會忽略包含使用者名字、姓氏或群組成員資格等資訊的屬性，因為 Cloud Identity 或 Google Workspace 中的使用者帳戶是這類使用者資訊的唯一來源。
為盡量縮減 SAML 聲明的大小，請設定 IdP，不要加入任何Google 登入不需要的屬性。
使用 google.com 做為發行者
Google 登入工作階段不限於單一工具或網域。建立工作階段後，使用者獲准存取的所有 Google 服務都會沿用該工作階段。這份服務清單可能包含 Google Cloud 和 Google Ads 等服務，以及 Google 搜尋和 YouTube 等服務。
SAML 通訊協定交換會反映工作階段的全球性質：根據預設，Google 會在 SAML 要求中使用 google.com 做為發行者 (SAML 要求中的 Issuer 元素)，並預期 SAML 聲明會將 google.com 指定為對象 (SAML 回應中的 Audience 元素)。
如要變更這項預設設定，請在 Cloud Identity 或 Google Workspace 中設定單一登入服務時，啟用「使用網域專屬簽發者」選項。只有在您有多個 Cloud Identity 或 Google Workspace 帳戶 (因此有多個網域)，且 IdP 必須能夠區分由一個 Cloud Identity 或 Google Workspace 帳戶啟動的登入與另一個帳戶啟動的登入時，才啟用網域專屬的簽發者選項。啟用這項選項後，SAML 要求會使用 google.com/a/DOMAIN 做為發行者，並預期 google.com/a/DOMAIN 為對象，其中 DOMAIN 是 Cloud Identity 或 Google Workspace 帳戶的主要網域。
在所有其他情況下，請保留預設設定，將 google.com 做為簽發者，並設定外部 IdP，在 SAML 聲明中將 google.com 指定為對象。視 IdP 而定，這項設定也可能稱為「簽發者」、「信賴方信任識別碼」或「實體 ID」。
讓 Google 工作階段和 IdP 工作階段的時間長度一致
使用者完成單一登入程序並建立工作階段後，Google 登入工作階段會在一段時間內保持有效。如果超過這段時間或使用者登出，系統會要求使用者重複執行單一登入程序，重新進行驗證。
根據預設，Google 服務的工作階段長度為 14 天。如果使用者擁有 Cloud Identity 進階版或 Google Workspace Business 授權，您可以變更預設工作階段長度，例如設為 8 小時。
您可以控制 Google Cloud使用的工作階段長度。 Google Cloud 工作階段適用於 Google Cloud 控制台，以及 Google Cloud CLI 和其他 API 用戶端。您可以在所有 Cloud Identity 和 Google Workspace 帳戶類型中設定工作階段長度。Google Cloud
大多數外部 IdP 也會為通過驗證的使用者維護工作階段。如果 IdP 工作階段長度超過 Google 工作階段長度，系統可能會在使用者不知情的情況下重新驗證。也就是說，使用者會重新導向至 IdP，但可能不必再次輸入憑證。無聲重新驗證可能會破壞縮短 Google 工作階段長度的目的。
如要確保使用者在 Google 工作階段到期後必須重新輸入憑證，請設定 Google 工作階段長度和 IdP 工作階段長度，讓 IdP 工作階段長度短於 Google 工作階段長度。
為超級管理員停用單一登入
對於超級管理員使用者，單一登入為選用功能：他們可以在 IdP 啟動登入作業時使用單一登入，也可以使用使用者名稱和密碼登入。
如果您不打算為超級管理員使用者啟用 IdP 啟動的單一登入功能，可以按照下列程序降低風險：
否則，如果您打算使用 IdP 啟動的單一登入服務，請務必對超級管理員使用者強制執行單一登入後驗證。
多重驗證
在 Cloud Identity 或 Google Workspace 與外部 IdP 之間啟用單一登入，可提升員工的使用者體驗。使用者不必頻繁驗證身分，也不必記住個別憑證就能存取 Google 服務。
但讓使用者在服務和環境中順暢驗證身分，也代表使用者憑證遭盜用的潛在影響會增加。如果使用者遺失或遭竊使用者名稱和密碼，攻擊者可能會使用這些憑證存取現有環境中的資源，以及一或多項 Google 服務。
為降低憑證遭竊的風險，建議為所有使用者帳戶啟用多重驗證。
強制使用者啟用多重驗證
為 Cloud Identity 或 Google Workspace 帳戶設定單一登入後，沒有超級管理員權限的使用者必須使用外部 IdP 進行驗證。
設定 IdP，要求使用者必須使用第二個驗證因素 (例如動態密碼或 USB 金鑰)，強制在單一登入 Google 時套用多重驗證。
如果外部 IdP 不支援多重驗證，請考慮啟用 SSO 後驗證，讓 Google 在使用者透過外部 IdP 驗證後，執行額外驗證。
避免使用網路遮罩，因為這類遮罩可能會遭到濫用，讓使用者規避多重驗證。
強制超級管理員使用者採用 Google 兩步驟驗證
超級管理員嘗試登入 Google Cloud 控制台或其他 Google 網站時，不會重新導向至外部 IdP。系統會提示超級管理員使用者透過使用者名稱和密碼進行驗證。
由於超級管理員使用者可以透過使用者名稱和密碼進行驗證，因此不受 IdP 可能強制執行的任何多重驗證政策限制。為保護超級管理員使用者，請強制所有超級管理員使用者採用 Google 兩步驟驗證。
超級管理員通常屬於下列其中一類：
個人化超級管理員使用者：這些使用者經過個人化設定，適用於單一管理員。建議您為所有個人化超級管理員使用者強制執行兩步驟驗證。
機器超級管理員使用者：雖然最好避免使用這類使用者帳戶，但有時必須啟用這類帳戶，才能讓 Cloud Directory Sync 或 Azure AD 資源庫應用程式等工具管理 Cloud Identity 或 Google Workspace 中的使用者和群組。
限制機器超級管理員人數，並盡可能啟用兩步驟驗證。
如果使用者未採用單一登入，您可以透過機構單位或群組，在任一帳戶中強制執行兩步驟驗證：
如果沒有任何無法使用兩步驟驗證的機器超級管理員使用者，建議為所有使用者啟用強制執行功能。為所有使用者強制執行兩步驟驗證，可避免不小心遺漏使用者。
如果您有部分機器超級管理員使用者無法使用兩步驟驗證，請使用專屬群組控管兩步驟驗證。建立新群組、為該群組啟用強制執行，然後將所有相關超級使用者加入其中。
如要進一步瞭解如何使用兩步驟驗證保護超級管理員使用者，請參閱「適用於管理員帳戶的安全性最佳做法」。
強制超級管理員使用者執行單一登入 (SSO) 後驗證
雖然超級管理員使用者不必使用單一登入，但如果是由 IdP 啟動，他們仍可使用單一登入。為確保超級管理員使用者一律須通過兩步驟驗證 (即使是透過 IdP 啟動的登入程序進行驗證)，請為所有超級管理員使用者啟用額外的單一登入驗證和兩步驟驗證。
如果您的 IdP 已強制執行多重驗證，額外的 SSO 驗證可能顯得多餘，但如果 IdP 遭到入侵，這項設定有助於保護超級管理員使用者。
不要依網路遮罩限制單一登入
在 Cloud Identity 或 Google Workspace 中設定單一登入時，您可以選擇指定網路遮罩。如果您指定遮罩，只有 IP 位址符合遮罩的使用者會受到單一登入限制，其他使用者登入時會收到密碼提示。
如果您使用網路遮罩，可能會破壞外部 IdP 強制執行的多重驗證。舉例來說，使用者可以變更位置或使用 VPN，控管是否套用網路遮罩。如果您在外部 IdP 強制執行多重驗證，使用者或攻擊者可能會利用這項策略，規避在外部 IdP 設定的多重驗證政策。
為確保無論使用者位置或 IP 位址為何，系統一律會套用多重驗證，請避免依網路遮罩限制單一登入。
如要依 IP 位址限制資源存取權，請在外部 IdP 設定適當的 IP 允許清單，或使用 Google Workspace 的 Google Cloud情境感知存取權。
後續步驟
- 瞭解其他最佳做法：
- 比較連結外部 IdP 與 Google Cloud 的模式。