在混合環境中驗證企業使用者的模式

Last reviewed 2024-06-26 UTC

本文是探討如何將身分管理解決方案延伸到 Google Cloud ，讓員工使用者能在混合運算環境中驗證及使用服務系列的第二單元。

本系列包含以下文件：

簡介

當您將 IT 環境延伸到 Google Cloud 成為混合策略的一部分時，我們建議您採用一致的方法管理不同環境中的身分。雖然您精心設計並打造出符合這些限制與需求的架構，還是可以放心使用一些常用的模式。這些模式分為兩類：

  • 連結外部識別資訊提供者 (IdP) 與Google Cloud 的模式。這個模式的目的是使 Google 成為員工使用者的 IdP，以自動維護 Google 身分，並且繼續使用 IdP 做為可靠資料來源。
  • 將 IdP 延伸到 Google Cloud的模式。這個模式會讓部署在 Google Cloud 的應用程式重複利用 IdP，方法是直接連接 IdP 或在 Google Cloud上維護 IdP 備用資源。

連結外部 IdP 與 Google Cloud的模式

如要存取 Google Cloud 控制台、Google Cloud CLI 或任何使用 Google 做為 IdP 的其他資源，員工使用者必須具有 Google 身分。當所有員工都擁有 IdP 帳戶時，維護每位員工的 Google 身分會有點麻煩。在 IdP 與 Google Cloud之間連結使用者身分後，就可以將 Google 帳戶的維護工作自動化，並將 Google 帳戶生命週期連結至現有帳戶。連結能確保系統實施以下機制：

  • 在身分管理方面，IdP 會繼續保有單一可靠資料來源的地位。
  • 系統會針對 IdP 管理的所有使用者帳戶或其中選取的一部分使用者帳戶，自動建立 Google 帳戶。
  • 如果在 IdP 中停用或刪除帳戶，對應的 Google 帳戶也會遭到停權或刪除。
  • 為防止密碼或其他憑證遭到複製，驗證使用者的動作會委派給 IdP。

使用 Google Cloud Directory Sync 和 AD FS 連結 Active Directory 與 Cloud Identity

如果您使用 Active Directory 做為 IdP，可以使用 Google Cloud Directory Sync (GCDS) 和 Active Directory 同盟服務 (AD FS) 連結 Active Directory 與 Cloud Identity：

  • GCDS 是 Google 免費提供的工具，可實作同步處理程序。GCDS 會透過安全資料傳輸層 (SSL) 與 Identity Platform 通訊，並通常會在現有運算環境中執行。
  • AD FS 由 Microsoft 在 Windows Server 中隨附提供。有了 AD FS，您可以使用 Active Directory 進行連結驗證。AD FS 通常會在現有運算環境中執行。

如要進一步瞭解這種方法，請參閱「與 Active Directory 聯合 Google Cloud 」一文。

模式：使用 GCDS 和 AD FS 連結 Active Directory 與 Cloud Identity。

至於這種模式的變化形式，您也可以將 Active Directory Lightweight Directory Services (AD LDS) 或另外的 LDAP 目錄，與 AD FS 或其他符合 SAML 規範的 IdP 搭配使用。

使用者體驗

  1. 當您要求受保護的資源時，系統會將您重新導向至 Google 登入畫面，並提示您輸入電子郵件地址。
  2. 如果已知電子郵件地址將與從 Active Directory 同步處理的帳戶建立關聯，系統就會將您重新導向至 AD FS。
  3. 根據 AD FS 的設定，登入畫面可能會提示您輸入 Active Directory 使用者名稱和密碼。或是 AD FS 可能會嘗試根據您的 Windows 登入資訊 (IWA) 自動將您登入。
  4. 在您通過 AD FS 驗證後，系統會將您重新導向回受保護的資源。

優點

  • 這種方法可在 Google Cloud上實現跨內部部署應用程式和資源的單一登入體驗。
  • 如果您將 AD FS 設為需要多重驗證，該設定會自動套用到 Google Cloud。
  • 您不需要將密碼或其他憑證同步處理到 Google。
  • Cloud Identity API 可公開存取，因此不需要在內部部署網路與 Google Cloud之間建立混合式連線。

最佳做法

  • Active Directory 和 Cloud Identity 使用不同的邏輯結構。請務必瞭解兩者的差異之處，並評估哪種對應網域、身分和群組的方式最適合您的情況。如需更多詳細資訊，請參閱我們的連結 Active Directory 指南 Google Cloud 。
  • 除了同步處理使用者之外，也請同步處理群組。您可以透過這種方法來設定 IAM，以在 Active Directory 中使用群組成員資格，控管誰可以存取 Google Cloud資源。
  • 部署並公開 AD FS，讓工作場所使用者可以存取這項服務，但公開程度請勿超過必要之範圍。雖然員工使用者必須能存取 AD FS，但不需要透過 Google 或部署在 Google Cloud上的任何應用程式來連線到 AD FS。
  • 考慮在 AD FS 中啟用整合式 Windows 驗證 (IWA)，以允許使用者依據其 Windows 登入資訊自動登入。
  • 如果 AD FS 無法使用，使用者可能無法使用Google Cloud 控制台或任何其他使用 Google 做為 IdP 的資源。因此，請務必部署 AD FS 和 AD FS 所依賴的網域控制站並調整規模，來滿足您的可用性目標。
  • 如果您使用 Google Cloud 來確保業務持續性，那麼倚賴內部部署 AD FS 可能會破壞使用Google Cloud 做為獨立部署複本的本意。在這種情況下，請考慮在 Google Cloud上部署所有相關系統的備用資源：
    • 將 Active Directory 複製到 Google Cloud 並將 GCDS 部署到 Google Cloud上執行。
    • 在 Google Cloud上執行專用 AD FS 伺服器，這些伺服器使用在 Google Cloud上執行的 Active Directory 網域控制站。
    • 設定 Cloud Identity 使用部署在 Google Cloud 上的 AD FS 伺服器以進行單一登入。

連結 Azure AD 與 Cloud Identity

如果您是 Microsoft Office 365 或 Azure 客戶，可能已將內部部署的 Active Directory 連線至 Azure AD。如果所有可能需要存取 Google Cloud 的使用者帳戶都已同步至 Azure AD，您可以將 Cloud Identity 與 Azure AD 連結，重複使用這項整合功能，如下圖所示。

連結 Cloud Identity 與 Azure AD。

如要進一步瞭解這個方法，請參閱與 Azure Active Directory 聯合 Google Cloud 一文。

使用者體驗

  1. 當您要求受保護的資源時，系統會將您重新導向至 Google 登入畫面，並提示您輸入電子郵件地址。
  2. 如果電子郵件地址已與從 Azure AD 同步處理的帳戶建立關聯，系統就會將您重新導向至 Azure AD。
  3. 根據內部部署 Active Directory 連線到 Azure AD 的方式，Azure AD 可能會提示您輸入使用者名稱和密碼，或者將您重新導向至內部部署 AD FS。
  4. 使用 Azure AD 成功驗證後，系統會將您重新導向回受保護的資源。

優點

  • 您不必安裝任何額外的內部部署軟體。
  • 這個方法可以跨 Office 365、Azure 和 Google Cloud資源實現單一登入體驗。
  • 如果您將 Azure AD 設為需要多重驗證 (MFA)，MFA 會自動套用到 Google Cloud。
  • 如果內部部署 Active Directory 使用多個網域或樹系，而您已設好自訂 Azure AD Connect 設定，將這個結構對應至 Azure AD 用戶群，則可以利用這項整合作業。
  • 您不需要將密碼或其他憑證同步處理到 Google。
  • Cloud Identity API 可公開存取，因此不需要在內部部署網路與 Google Cloud 之間或在 Azure 與Google Cloud之間建立混合式連線。
  • 您可以使用 Google Cloud 控制台做為 Office 365 入口網站的圖塊。

最佳做法

  • Azure AD 和 Cloud Identity 使用不同的邏輯結構，因此請務必瞭解兩者的差異之處。請評估哪種對應網域、身分和群組的方式最適合您的情況。如需更多詳細資訊，請參閱連結 Google Cloud Azure AD。
  • 除了同步處理使用者之外，也請同步處理群組。您可以透過這種方法來設定 IAM，以在 Azure AD 中使用群組成員資格來控制誰可以存取 Google Cloud資源。
  • 如果您使用 Google Cloud 來確保業務持續性，那麼倚賴 Azure AD 進行驗證可能會破壞使用Google Cloud 做為獨立部署複本的本意。

將外部 IdP 延伸到 Google Cloud的模式

您打算部署在 Google Cloud 上的某些應用程式，可能需要使用 Cloud Identity 未提供的驗證通訊協定。如要支援這些工作負載，您必須允許這些應用程式在 Google Cloud中使用您的 IdP。

以下各節說明允許部署在 Google Cloud上的工作負載使用 IdP 的常見模式。

向 Google Cloud公開內部部署 AD FS

如果應用程式需要使用 WS-Trust 或 WS-Federation，或在使用 OpenID Connect 時需要 AD FS 特定功能或憑證附加資訊，您可以允許應用程式直接使用 AD FS 進行驗證。

直接使用 AD FS 進行驗證的應用程式。

使用 AD FS，應用程式即可驗證使用者。不過，由於驗證並非依據 Google 身分，因此應用程式無法使用使用者憑證執行任何 API 呼叫。您必須使用服務帳戶，才能對 Google Cloud API 呼叫進行驗證。

使用者體驗

  1. 當您要求受保護的資源時，系統會將您重新導向至 ADFS 登入畫面，並提示您輸入電子郵件地址。如果 AD FS 尚未透過網際網路公開，那麼您可能需要連線至公司網路或企業 VPN 才能存取 AD FS。
  2. 根據 AD FS 的設定，登入畫面可能會提示您輸入 Active Directory 使用者名稱和密碼。或是 AD FS 可能會嘗試根據您的 Windows 登入資訊自動將您登入。
  3. 在您通過 AD FS 驗證後，系統會將您重新導向回受保護的資源。

優點

  • 您可以使用 Cloud Identity 不支援的驗證通訊協定，包括 WS-Trust 和 WS-Federation。
  • 如果應用程式已針對 AD FS 進行開發及測試，就可以避免將應用程式切換為使用 Cloud Identity 時可能產生的風險。
  • 內部網路與 Google Cloud之間無需設定混合式連線。

最佳做法

  • 部署並公開 AD FS，讓工作場所使用者可以存取這項服務，但公開程度請勿超過必要之範圍。雖然員工使用者必須能存取 AD FS，但不需要透過 Google 或部署在 Google Cloud上的任何應用程式來連線到 AD FS。
  • 如果 AD FS 無法使用，使用者可能無法再使用該應用程式。請務必部署 AD FS 和 AD FS 所依賴的網域控制站並調整規模，來滿足您的可用性目標。
  • 考慮重構需要 WS-Trust 和 WS-Federation 的應用程式，改為使用 SAML 或OpenID Connect。
  • 如果應用程式依賴 AD FS 發出的 IdTokens 中以聲明形式公開的群組資訊，請考慮從其他來源 (例如 Directory API) 擷取群組資訊。查詢 Directory API 是需要權限的作業，必須使用已啟用 Google Workspace 網域範圍授權的服務帳戶。

向 Google Cloud公開內部部署 LDAP 目錄

有些應用程式可能會要求使用者提供使用者名稱和密碼，並使用這些憑證嘗試執行 LDAP 繫結作業。如果您無法修改這些應用程式，以使用其他方式 (例如 SAML) 執行驗證，可將內部部署 LDAP 目錄的存取權授予這些應用程式。

將內部部署 LDAP 目錄的存取權授予使用者。

優點

  • 您無需變更應用程式。

最佳做法

  • 使用 Cloud VPN 或 Cloud Interconnect 在 Google Cloud 與內部部署網路之間建立混合式連線，如此就不需要透過網際網路公開 LDAP 目錄。
  • 確認查詢內部部署 LDAP 目錄所產生的延遲不會對使用者體驗造成負面影響。
  • 確認應用程式與 LDAP 目錄之間的通訊已加密。您可以使用 Cloud VPN 或使用 Cloud Interconnect 搭配 LDAP/S 來達成這項加密。
  • 如果 LDAP 目錄或Google Cloud 與內部部署網路之間的不公開連線無法使用，則使用者可能無法再使用 LDAP 應用程式。因此，請務必部署各個伺服器並調整規模以滿足可用性目標，並考慮使用備援 VPN 通道或互連網路。
  • 如果您使用 Google Cloud 來確保業務持續性，那麼倚賴內部部署 LDAP 目錄可能會破壞使用Google Cloud 做為現有部署獨立複本的本意。在這種情形下，請考慮將 LDAP 目錄複製到 Google Cloud 。
  • 如果您使用 Active Directory，請考慮改為在 Google Cloud 上執行備用資源，特別是在您打算將Google Cloud 上執行的 Windows 機器加入 Active Directory 網域時。

將內部部署 LDAP 目錄複製到 Google Cloud

將內部部署 LDAP 目錄複製到 Google Cloud ，與向 Google Cloud公開內部部署 LDAP 目錄的模式類似。對於使用 LDAP 驗證使用者名稱和密碼的應用程式，這種做法的目的是為了能在 Google Cloud上執行這些應用程式。您可以選擇在 Google Cloud上維護內部部署目錄的副本，而不允許這類應用程式查詢內部部署 LDAP 目錄。

在 Google Cloud上維護內部部署目錄的備用資源。

優點

  • 您無需變更應用程式。
  • 在 Google Cloud上執行的 LDAP 應用程式的可用性，並不取決於內部部署目錄的可用性或與內部部署網路的連線。此模式非常適合業務持續性混合情境。

最佳做法

  • 使用 Cloud VPN 或 Cloud Interconnect 在 Google Cloud 與內部部署網路之間建立混合式連線，如此就不需要透過網際網路公開 LDAP 目錄。
  • 請確認與內部部署 LDAP 目錄之間的複製作業會透過安全通道進行。
  • 可在多個區域或地區中部署多個 LDAP 目錄備用資源，以滿足您的可用性目標。您可以使用內部負載平衡器，將 LDAP 連線分散在部署於同一地區中的多個備用資源中。
  • 使用獨立的 Google Cloud 專案搭配共用虛擬私有雲來部署 LDAP 備用資源，並運用最低權限原則授予這個專案的存取權。

將內部部署 Active Directory 延伸到 Google Cloud

您打算部署在 Google Cloud 上的某些工作負載可需要使用 Active Directory Domain Services，例如：

  • 需要加入網域的 Windows 機器
  • 使用 Kerberos 或 NTLM 進行驗證的應用程式
  • 使用 Active Directory 做為 LDAP 目錄來驗證使用者名稱和密碼的應用程式

如要支援這類工作負載，您可以將內部部署 Active Directory 樹系延伸到 Google Cloud，例如，將資源樹系部署到Google Cloud ，然後將其連線到內部部署 Active Directory 樹系，如下圖所示。

將資源樹系連線到內部部署 Active Directory 樹系。

如要進一步詳加瞭解這個方法，以及在混合環境中部署 Active Directory 的其他方式，請參閱在混合環境中使用 Active Directory 的模式一文。

在 Google Cloud上部署額外的網域控制站，將內部部署 Active Directory 樹系延伸到 Google Cloud 。

優點

  • 您的工作負載可充分運用 Active Directory，包括能將 Windows 機器加入 Active Directory 網域。
  • 在Google Cloud 上執行的 Active Directory 應用程式的可用性，並不取決於內部部署資源的可用性或與內部部署網路的連線。此模式非常適合業務持續性混合情境。

最佳做法

  • 使用 Cloud VPN 或 Cloud Interconnect 在 Google Cloud 與內部部署網路之間建立混合式連線。
  • 如要盡量減少 Google Cloud 與內部部署網路之間的通訊量，請為 Google Cloud部署作業建立獨立的 Active Directory 站台。每個共用虛擬私有雲端使用一個站台，或每個共用虛擬私有雲端和地區使用一個站台，藉此盡量減少地區間的通訊量。
  • 建立一個專用於Google Cloud 上部署資源的獨立 Active Directory 網域，並將網域新增到現有樹系。使用獨立網域有助於減輕複製作業負擔並減少分區大小。
  • 如要提高可用性，請至少部署兩個網域控制站，並使網域控制站分散在多個區域中1。如果使用多個地區，請考慮在每個地區部署網域控制站。
  • 使用獨立的 Google Cloud 專案搭配共用虛擬私有雲來部署網域控制站，並運用最低權限原則授予這個專案的存取權。惡意專案成員可能會藉由產生密碼或存取網域控制站執行個體的序列控制台來駭入該網域。
  • 建議在 Google Cloud上部署 AD FS 伺服器陣列和 GCDS。這種做法可讓您連結 Active Directory 與 Cloud Identity，而不需要倚賴資源的可用性或與內部部署網路的連線。

後續步驟

  1. 如要進一步瞭解特定地區的注意事項，請參閱「地理位置與區域」一文。↩