本文是探討如何將身分管理解決方案延伸到 Google Cloud，讓員工能在混合運算環境中驗證及使用服務系列的第一單元。
本系列包含以下單元：
- 在混合環境中驗證員工使用者 (即本文)
- 在混合環境中驗證員工使用者的模式
簡介
管理使用者帳戶及控管員工對於應用程式和運算資源的存取權，是企業 IT 部門的重要責任。為了確保一致性與管理效率，大多數企業都會將身分管理視為集中功能，並使用統一的系統來管理身分。最常見的情況下，企業會依賴 Microsoft Active Directory 網域服務 (AD DS) 來達成此目的。
當您以混合策略的一部分將 IT 環境延伸到 Google Cloud 時，您會想要維持只用一個點來管理身分。統一的身分管理系統可將管理帳戶及存取權控管時花費的精力減到最低。此系統也可協助確保使用者與應用程式都能安全地在混合環境中進行驗證。
本文介紹將 Google Cloud 與您的身分管理系統整合在一起的方式，並協助您選擇最適合您要求的方法。
雖然大部分討論內容也適用於 Google Workspace，但本文重點放在 Cloud Identity 上。
評估混合式身分管理的要求
將身分管理系統延伸到 Google Cloud的最佳方法取決於多個因素：
- 您機構中的身分集區
- 用來為您的工作團隊身分提供驗證服務的識別資訊提供者
- 您想要使用者能夠在「 Google Cloud」上存取的資源與應用程式
- 您的企業連續性要求
以下幾節會逐一介紹這些因素。
身分
將 Google Cloud 與您的身分管理系統整合在一起時，要注意的第一個因素是您管理及區別身分類型的方式。大多數機構都使用下列類型的身分：
- 員工身分是您用來管理機構員工的身分。這些身分可用於登入工作站、存取電子郵件，或使用企業應用程式。
- 外部身分是您用來管理非員工的身分，例如需要擁有權限才能存取企業資源的承包商或合作夥伴。
- 訪客身分是由需要存取企業資源的客戶或合作夥伴等各方管理的身分。
- 客戶身分是您用來管理使用者，藉以與網站或客戶專用應用程式互動的身分。
- 工作負載身分是您用來管理的身分，可讓應用程式與其他應用程式或基礎平台互動。
通常，員工身分構成單一身分集區，每一位員工都有單一身分，而所有身分都會以相同方式，使用相同系統管理。但是，做為合併或併購的結果而言，就不一定是這樣。例如，您可能會有多個員工身分集區，每一個集區都使用不同的系統以不同的方式管理。就技術性而言，這表示您可能必須將多個 LDAP 來源、Active Directory 樹系或 Azure AD 用戶群與 Google Cloud整合在一起。
整合多個集區會增加與Google Cloud整合的複雜性，因此，您應評估：
- 是否所有身分集區都需要存取 Google Cloud，或者只有特定子集需要存取？
- 是否所有身分集區都必須存取 Google Cloud中的相同機構，或者每個身分集區都必須存取不同的機構？
- 是否有選項可以減少集區數，例如在 Active Directory 樹系之間建立跨樹系信任？
外部身分的處理方式通常與工作團隊身分的處理方式類似，但有以下例外：
- 外部身分的帳戶有效時間有限。
- 根據預設，外部身分獲得的授權可能較少。
- 外部身分可由個別的 LDAP 目錄、Active Directory 樹系或 Azure AD 用戶群管理。
訪客身分與外部身分不同，訪客身分並非由您管理，而是由其他方管理。在 Google Workspace 之類的軟體即服務 (SaaS) 應用程式中，如果您使用訪客身分，就不需要為客戶或合作夥伴保留外部身分。您很少會在內部部署環境中遇到訪客身分。
本文著重於工作團隊身分和外部身分。
如果您已經使用過 Google Ads 之類的服務，您的某些員工可能已有尚未連線至其工作身分的 Google 帳戶，這表示這些員工有兩個身分。如果是這樣，請考慮合併這些身分。
識別資訊提供者
要考慮的第二個因素是您的識別資訊提供者。「識別資訊提供者」(IdP) 是可為工作負載提供驗證服務，並最終決定是否驗證使用者的系統。
除了提供驗證服務以外，IdP 還通常能夠管理身分生命週期。但是也並非一定如此，因為身分也可以從個別的人力資源系統佈建。
常見的識別資訊提供者包括：
- Active Directory (AD DS)
- Azure Active Directory (Azure AD)
- IDaaS 提供者，例如 ForgeRock、Okta 或 Ping Identity
- 其他 LDAP 目錄，包括 Active Directory Lightweight Directory Services (AD LDS)
您不必只使用一個系統，而是可以使用多個系統來管理不同的使用者集區、處理外部帳戶，或為相同的使用者集區提供不同的驗證服務。用來管理相同集區的多個 IdP 的範例包括以下幾個項目：
- 與 Azure AD 連結的 Active Directory
- 與 ForgeRock、Okta 或 Ping Identity 等 IDaaS 提供者連結的 Active Directory
- 與 AD LDS 備用資源連結的 Active Directory
如要在 Google Cloud上使用 IdP，請依照兩個基本方法操作：
- 將您的識別資訊提供者與 Cloud Identity 連結：連結 Cloud Identity 之後，您會使 Google 成為您的工作場所使用者可以使用，而且在 Google Cloud 上部署的應用程式能夠依賴的另一個 IdP。您不必為每一位使用者保留 Google 身分，而是可以依賴連結關係來自動保留身分。這種關係也有助於確保將您的 IdP 保持為可靠資料來源。
- 將您的識別資訊提供者延伸至 Google Cloud：您可以允許在 Google Cloud 上部署的應用程式重複使用您的 IdP，無論是直接連線，還是在Google Cloud上保留 IdP 的備用資源皆可。
根據其他身分管理因素，您可能需要結合這兩種方法來支援您的混合使用案例。
資源
要考慮的第三個因素是您打算讓員工存取哪些 Google Cloud 資源。這個因素包括 Google Cloud 本身，您必須允許負責團隊使用 Google Cloud Google Cloud 控制台、 gcloud CLI 或 API 管理。
其他資源可能包括以下項目：
- 在 App Engine、Compute Engine 或 Google Kubernetes Engine (GKE) 上部署的應用程式
- 使用 Identity-Aware Proxy (IAP) 保護的應用程式
- 使用 SSH 存取的 Linux VM
- 使用 RDP 存取的 Windows VM
- 其他 Google 工具與服務，例如 Google Workspace、Looker Studio 或 Google Ads
這些資源在必須、可以還是無法使用 Google 做為識別資訊提供者方面各自不同，以下幾節會逐一介紹這三種情況。
必須使用 Google 做為 IdP 的資源
必須使用 Google 做為 IdP 的資源包括 Google Cloud 控制台、gcloud CLI、受 IAP 保護的應用程式，以及其他 Google 工具與服務。如要授予員工使用者存取這些資源的權限，您必須為每位使用者佈建 Google 身分。
保留個別 Google 身分與統一身分管理的想法相悖，因此，讓使用者存取這裡的任何資源就表示您必須將您的 IdP 與 Google Cloud連結。
將您的 IdP 與 Google Cloud連結之後，請考慮使用 Google 做為更多資源的 IdP，包括可能使用其他方法驗證使用者的應用程式。
可以使用 Google 做為 IdP 的資源
可以使用 Google 做為 IdP，但目前沒有這樣做的資源，包括以下項目：
這些應用程式是否能夠使用 Google 做為 IdP，取決於您用於驗證及授權的通訊協定。
網路單一登入通訊協定
Google 支援多種業界標準通訊協定，可處理驗證、授權與單一登入。支援的通訊協定包括以下項目：
- OAuth 2.0，適用於行動用戶端、多功能型用戶端及其他非瀏覽器應用程式。
- OpenID Connect 1.0 (OIDC)，適用於瀏覽器式應用程式。
- SAML 2.0，適用於整合第三方應用程式。
對於您打算開發的應用程式，建議選擇 OAuth 2.0 或 OIDC。這些通訊協定受到廣泛採用，您可以利用許多經過全面測試的程式庫與工具。此外，依賴這些通訊協定也表示您可以選擇使用 Google 做為 IdP，同時保留視需要切換識別資訊提供者的彈性。
如果您的應用程式使用 SAML、OAuth 2.0 或 OIDC，不需要修改程式碼，或者只需要做少量修改，就可以將其更改為使用 Google 做為識別資訊提供者。
LDAP
輕量型目錄存取協定 (LDAP) 屬於功能最多樣化、廣受信賴的驗證及授權通訊協定之一。應用程式可以透過多種方法使用 LDAP 進行驗證與授權，最常見的兩種情境如下：
使用 LDAP 進行驗證及查詢使用者資訊：在這種情境中，應用程式不會使用單一登入，而是對使用者顯示登入表單，要求輸入使用者名稱與密碼，然後使用提供的憑證來嘗試執行 LDAP
bind作業。如果嘗試成功，便會將憑證視為有效。有關使用者的進一步資訊，例如名稱與群組成員資格，可以從目錄中查詢，並用於授權存取權。使用 SAML 進行驗證並使用 LDAP 查詢使用者資訊：在這種情境中，應用程式會使用單一登入通訊協定驗證使用者，應用程式通常會針對這個目的使用 SAML。當使用者通過驗證後，應用程式會使用 LDAP 伺服器查詢有關使用者的其他資訊，例如名稱與群組成員資格。
這兩種情境之間的關鍵差異在於，第一種情境會要求應用程式與 LDAP 伺服器都具有使用者密碼的存取權以驗證憑證。在第二種情境中，應用程式與伺服器不需要存取使用者的密碼；應用程式可以使用專用服務使用者來執行其 LDAP 查詢。
有了安全 LDAP，您可以使用 LDAP 通訊協定存取 Cloud Identity 中的使用者與群組資訊。如果 Google 是您的主要 IdP，安全 LDAP 可讓您支援這兩種情境。不過，如果您將 Cloud Identity 與外部 IdP 整合在一起，Cloud Identity 就不會保有使用者密碼的副本。因此，只有第二種情境可以透過安全 LDAP 啟用。
Kerberos 與 NTLM
如果您打算將 Windows 工作負載遷移至 Google Cloud，這裡的其中一些應用程式可能會依賴整合式 Windows 驗證 (IWA)，而非使用標準通訊協定。IWA 是在 Microsoft IIS 上執行之 ASP.NET 式應用程式的常見選擇。IWA 很受歡迎，因為已使用網域憑證登入 Windows 工作站的使用者會獲得完美的單一登入體驗。
IWA 依賴 NTLM 或 Kerberos。並要求執行應用程式所在的使用者工作站與伺服器加入同一個 Active Directory 網域或信任網域。
依賴 NTLM 與 Kerberos 會產生一個後果，就是使用 IWA 的應用程式無法使用 Google 做為 IdP。不過，您仍然可以重構應用程式來使用 OIDC。OIDC 並不需要使用者工作站或伺服器加入網域。因此，重構可能可以簡化部署，並協助您尋找替代部署選項。
考慮到 IWA 提供的完美單一登入體驗，使用 OIDC 而非 IWA 可能看起來會像是在使用者體驗方面倒退了一步。但是，如果您能夠確保使用者可以完美登入 AD FS 或 Azure AD，那也並不一定就是如此：
- 如果您與 Active Directory 和 AD FS 連結 Google Cloud ，則在 AD FS 中設定的任何驗證方法都適用。如果您設定讓 AD FS 允許 IWA，已透過網域憑證登入 Windows 工作站的使用者可以完美通過任何使用 Google 做為 IdP 的應用程式的驗證。
- 如果您連結 Google Cloud Azure AD，則可使 Azure AD 完美單一登入 (SSO) 達到相同的效果。
下圖顯示如何針對網路應用程式使用 Cloud Identity、AD FS 與 IWA 實作完美單一登入的簡化範例：
- 瀏覽器要求使用網路瀏覽器的受保護頁面。
- 網路應用程式使用 OIDC (OIDC 驗證流程) 啟動登入。 此流程會將瀏覽器重新導向至 Google 登入端點。
- Google 登入端點會將 Google 登入頁面傳回給使用者，提示輸入電子郵件地址。
- 使用者輸入電子郵件地址。
- Google 登入端點會根據電子郵件地址識別 Cloud Identity 帳戶，並確認其是否設定為使用單一登入 (SSO)。然後登入端點會啟動 SAML 登入 AD FS。
- 設定為使用 IWA 的 AD FS 會要求瀏覽器提供 Kerberos 票證，這會觸發瀏覽器要求基礎 Windows 作業系統取得適合的票證。
- 除非已快取適合的票證，否則 Windows 會聯絡 Active Directory 金鑰發佈中心 (KDC)，要求提供根據使用者登入 Windows 時取得的票證授權票證 (TGT) 發出的適合服務票證。
- 瀏覽器將新取得的票證提供給 AD FS。
- AD FS 檢查加密編譯簽名來驗證票證、從票證擷取使用者身分，然後將 SAML 憑證發給 Google 登入端點。
- Google 登入端點會使用 SAML 符記的驗證資訊完成 OIDC 登入，並將 OpenID Connect 符記發給網路應用程式。
- 當使用者通過驗證時，系統便會將受保護的頁面傳回給使用者。
SSH 公開金鑰驗證
當您打算在 Google Cloud上執行 Linux 虛擬機器 (VM) 時，可能需要這些機器的 SSH 存取權。SSH 最常見的驗證方法是公開金鑰驗證。
SSH 公開金鑰驗證與之前討論的單一登入通訊協定不同，SSH 公開金鑰驗證不依賴集中式 IdP 來做出驗證的決定，而是透過分散的方式做出驗證決定，每部機器都根據一組本機授權公開金鑰處理驗證。
您可以透過 OS Login，弭平分散式 SSH 公開金鑰驗證與集中式身分管理之間的鴻溝。OS 登入會將安全殼層金鑰的生命週期與使用者帳戶的生命週期綁定，做法如下：
- 在建立使用者或使用者第一次嘗試使用 SSH 時發布 SSH 公開金鑰。
- 將使用者的公開金鑰佈建至使用者有權存取的機器。
- 在帳戶存取權遭到撤銷、停用或刪除時取消佈建使用者的公開金鑰。
有效使用 OS 登入功能，可讓 Cloud Identity 成為 Linux 執行個體的 IdP。
無法使用 Google 做為 IdP 的資源
有些資源無法直接使用 Google 做為 IdP，但您仍可結合兩種方法來在 Google Cloud 上容納這些資源：
- 將外部 IdP 與 Google Cloud連結，允許企業使用者使用 Google Cloud 控制台、gcloud CLI，以及其他必須或可以使用 Google 做為 IdP 的資源。
- 將 IdP 延伸至 Google Cloud，讓無法使用 Google 做為 IdP 的資源在Google Cloud上執行。
如果資源依賴 Google IdP 不支援的通訊協定，該資源就無法使用 Google 做為 IdP。此類通訊協定包括：
用於驗證的 LDAP：儘管您能夠使用安全 LDAP 來協助透過 LDAP 從 Cloud Identity 查詢使用者資訊，Cloud Identity 也不支援在與外部 IdP 連結時使用 LDAP 進行驗證。
如要允許應用程式使用 LDAP 進行驗證，您可以公開或複製內部部署 LDAP 目錄，也可以將 Active Directory 延伸至 Google Cloud。
WS-Trust、WS-Federation：特別是當您使用 AD FS 時，您可能仍然依賴 WS-Trust 或 WS-Federation 來處理憑證式驗證。除非您可以將受影響的應用程式變更為使用 SAML 或 OpenID Connect，否則建議您將內部部署 AD FS 公開給 Google Cloud，並讓應用程式直接使用 AD FS。
帶有 AD FS 特定憑證附加資訊的 OpenID Connect：AD FS 與 Google 都支援 OpenID Connect。如果您已經使用 AD FS 做為 OpenID Connect 提供者，您可能會依賴某些 Google 不支援的 AD FS 特定憑證附加資訊。如果是這樣，請考慮將內部部署 AD FS 公開給 Google Cloud，並讓受影響的應用程式直接使用 AD FS。
Kerberos、NTLM：如果您的某些應用程式使用 Kerberos 或 NTLM 進行驗證，您可能可以將其修改為改用 OpenID Connect 或 SAML。 如果無法這樣做，您可以將這些應用程式部署到加入網域的 Windows 伺服器，並公開或將內部部署 Active Directory 複製到 Google Cloud。
Windows 虛擬機器：如果您在Google Cloud上執行 Windows 工作負載，則必須能夠透過遠端桌面通訊協定 (RDP)、遠端桌面閘道，或透過其他方式登入這些 VM。如果使用者具有建立 VM 時所在 Google Cloud 專案 Google Cloud 的寫入存取權， Google Cloud Google Cloud 會讓使用者建立使用者與密碼，這樣會在 VM 的本機 Security Account Manager (SAM) 資料庫中建立帳戶。至關重要的一點是，產生的 Windows SAM 帳戶並未連線至使用者的 Google 帳戶，且並未受限於相同的帳戶生命週期。如果您暫停或刪除使用者的 Google 帳戶，Windows SAM 帳戶就不會受到影響，並可以繼續提供 VM 存取權。
如果您擁有中等數量的 Windows VM，以及必須能夠登入這些機器的使用者，讓使用者產生 Windows 使用者帳戶與密碼可能會是一個可行的方法。但是，當管理大量 Windows 伺服器時，最好能將內部部署 Active Directory 延伸至 Google Cloud 與加入網域的各個伺服器。如果您依賴網路層級驗證，則也必須要有加入網域的伺服器。
可用性
最後一個因素是可用性。驗證使用者的能力可能對您的許多工作負載而言都很重要，IdP 服務中斷可能會造成影響深遠的後果。確保適當可用性的正確方法取決於您想要使用 Google Cloud 的方式，以及該方式符合混合策略的程度。
分散式工作負載
如要利用每個運算環境提供的獨特能力，您可以使用混合多雲端方法來跨這些環境分散工作負載。 這些環境可能彼此相依，這對工作負載的可用性很重要。相依性可能包括 VPN 通道或互連網路、彼此互相通訊的應用程式，或跨運算環境存取資料的系統。
將外部 IdP 連結或延伸至 Google Cloud時，請確保驗證所需的外部 IdP 與其他系統的可用性能夠符合或超越其他重要相依性的可用性。這個要求表示您可能需要以備援方式部署外部 IdP 及其相依性，「並」確保備援網路的連線能力。
備援工作負載
如果您使用 Google Cloud 來確保業務持續性，您在 Google Cloud 上的工作負載會針對運算環境中的某些工作負載來啟動鏡像作業。此類設定的目的是要讓一個運算環境在發生故障時接管另一個環境的角色，因此，您需要瞭解這些環境之間的每一個相依性。
讓 Google Cloud 依賴執行內部部署的外部 IdP，就可以建立相依性。這種相依性可能會破壞讓Google Cloud 成為運算環境獨立複本的本意。
請嘗試將您的 IdP 複製到 Google Cloud ，讓 Google Cloud 上的所有工作負載都不會受到內部部署運算環境服務中斷或 Google Cloud 與內部部署網路之間連線中斷的影響。
後續步驟
- 查看在混合環境中驗證員工使用者的常見模式。
- 查看 Google Cloud的身分佈建選項。
- 如需更多參考架構、圖表和最佳做法，請瀏覽 Cloud 架構中心。