本文討論當您將 Active Directory 部署至 GCP 時所要考慮的需求，並協助您選擇正確的架構。 Google Cloud
將 Active Directory 與 Cloud Identity 或 Google Workspace 進行同盟 (請參閱「在混合式環境中驗證員工使用者的模式」)，即可讓現有 Active Directory 網域的使用者驗證並存取 Google Cloud上的資源。如果您打算使用 Active Directory 來管理 Google Cloud 上的 Windows 伺服器，或是依賴 Google Cloud不支援的通訊協定，也可以將 Active Directory 部署到 Google Cloud 。
在您將 Active Directory 部署至 Google Cloud之前，必須先決定要使用哪個網域與樹系架構，以及如何與您現有的 Active Directory 樹系整合。
評估需求
Active Directory 支援各種網域與樹系架構。在混合式環境中，有一個選項是將單一 Active Directory 網域延伸至多個環境。您也可以使用個別的網域或樹系，並使用信任將其連線。哪一種架構最好，取決於您的需求。
如要選擇最佳架構，請考慮以下因素：
- 是否符合現有安全區域
- 內部部署與 Google Cloud 資源之間的互動
- 管理自主權
- 可用性
下列各節將討論這些因素。
是否符合現有安全區域
首先，請檢查內部部署網路的設計。
在內部部署環境中，您可能已使用不同的 VLAN 或子網路 (舉例來說) 將網路劃分為多個安全區域。在已劃分為安全區域的網路中，安全區域內的通訊可能不受限制，或者只受限於輕量級防火牆與稽核政策。相較之下，跨安全區域的任何通訊都受限於嚴格的防火牆、稽核或流量檢查政策。
安全區域的意圖遠大於只是限制及稽核網路通訊，但安全區域應實作信任界線。
信任界線
網路中的每部機器都執行多個程序。這些程序可能會使用程序間通訊的方式來在本機相互通訊，也可能使用 HTTP 等通訊協定來跨機器通訊。在這個通訊網中，對等互連項目一般都不會信任彼此達到相同的程度。例如，程序對於同一部機器上執行的程序，信任度可能超過在其他機器上執行的程序。某些機器可能比其他機器更值得信任。
信任界線會在通訊各方之間強制執行區別，信任某一組通訊對象的程度會超過信任其他一組通訊對象。
信任界線對於遏制攻擊的影響而言至關重要。當單一系統遭到入侵時，攻擊很少會結束，無論該系統是單一程序還是完整機器。攻擊者可能會嘗試將攻擊延伸到其他系統。由於信任界線中的系統不會彼此進行區別，因此在該信任界線內散佈攻擊比跨信任界線攻擊系統更容易。
當信任界線中的系統遭到入侵時，必須假定該信任界線中的其他所有系統也都遭到入侵。這個假設可以協助您找到信任界線，或驗證某一系統界線是否就是信任界線，舉例來說：
假設攻擊者已達到存取目標 A 的最高權限層級 (例如機器或應用程式的管理員或根存取權限)。如果攻擊者能夠利用這些權限取得對於目標 B 的相同存取權限層級，則根據定義，A 與 B 都位於相同的信任界線之內。否則，信任界線就位於 A 與 B 之間。
透過限制網路通訊，安全區域有助於實作信任界線。但是，若要使安全區域成為真正的信任界線，跨越界線兩側的工作負載必須能夠區別源自相同安全區域的要求，以及源自不同安全區域的要求，並更仔細地審查後者。
零信任模型
零信任模型是 Google Cloud的偏好網路模型。
假定遭到入侵的單一系統位於信任界線中，您可以假設該界線中的所有系統都已遭到入侵。這個假設建議採用更小的信任界線。信任界線越小，遭到入侵的系統就越少，攻擊者散佈攻擊時要清除的界線就越多。
零信任模型將這個概念放進了該模型的邏輯結論中：網路中的每部機器都會被視為唯一的安全區域與信任界線。機器之間的所有通訊都要受到相同的審查與防火牆篩查，所有網路要求都會被視為源自不受信任的來源。
在網路層級上，您可以使用防火牆規則限制流量，並使用虛擬私有雲端流程記錄與防火牆規則記錄來分析流量，進而實作零信任模型。在應用程式層級，您必須確保所有應用程式都透過一致及安全的方式處理驗證、授權與稽核作業。
Active Directory 中的信任界線
在 Active Directory 網域中，機器會信任網域控制器來代表機器處理驗證與授權作業。當使用者向其中一個網域控制器證明其身分之後，使用者便可根據預設登入到相同網域的所有機器。 網域控制器授予使用者的的任何存取權限 (以權限與群組成員資格的形式) 都會套用至網域的多部機器。
您可以使用群組政策防止使用者存取某些機器或限制使用者對於某些機器的權限。但是，當機器遭到入侵之後，攻擊者也許可以竊取其他網域使用者登入同一部機器時所使用的密碼、密碼雜湊或 Kerberos 憑證。然後，攻擊者可以利用這些憑證將攻擊散佈到樹系中的其他網域。
鑑於這些因素，最好假設樹系中的所有機器都位於信任安全界線中。
相較於網域界線 (其目的是控制機構不同部分的管理自主權複製及授予能力)，樹系界線可以提供更強的隔離能力。樹系可以擔任信任界線的角色。
符合 Active Directory 樹系與安全區域
假設樹系是影響安全區域設計的信任界線。如果樹系延伸跨越兩個安全區域，攻擊者就更容易清除這些安全區域之間的界線。因此，兩個安全區域實際上可以合成為一個安全區域，形成單一信任界線。
在零信任模型中，您可以將網路中的每部機器想像成個別的安全區域。在此類網路中部署 Active Directory 會破壞這個概念，並擴大有效安全界線，使其納入 Active Directory 樹系的所有機器。
對於擔任信任界線角色的安全區域，您必須確保整個 Active Directory 樹系都在安全區域中。
將 Active Directory 延伸到 Google Cloud的影響
當您規劃需要 Active Directory 的 GCP 部署時，您必須從兩個選項中決定使部署符合現有安全區域的其中一個選項： Google Cloud
將現有安全區域擴展至 Google Cloud。您可以在 Google Cloud 上佈建共用虛擬私有雲端，並使用 Cloud VPN 或 Cloud Interconnect 將其連線至現有區域，藉以將一或多個現有安全區域延伸到 Google Cloud 。
部署在內部部署與 Google Cloud 上且共用區域的資源也可以共用 Active Directory 樹系，這樣就不需要將個別的樹系部署至 Google Cloud。
舉例來說，假設現有網路中有一個開發 邊界網路與實際工作環境邊界網路做為安全區域，並且在每個安全區域中都有個別的 Active Directory 樹系。如果您將安全區域延伸到Google Cloud，則 Google Cloud 上的所有部署也會是這兩個安全區域其中之一的部分，並且可以使用相同的 Active Directory 樹系。
引入新的安全區域。延伸安全區域可能不適用，這是因為您不想要進一步擴展區域，或者現有安全區域的安全需求與 Google Cloud部署的需求不符。您可以將 Google Cloud 視為其他安全區域。
舉例來說，請考慮具有周邊網路，但不會區分開發和實際工作環境工作負載的內部部署環境。如要在 Google Cloud上分隔這些工作負載，您可以建立兩個共用虛擬私人雲端，並將其視為新的安全區域。然後，您可將其他兩個 Active Directory 樹系部署到 Google Cloud，每個安全區域一個。如有必要，您可以在樹系之間建立信任關係，藉以跨安全區域啟用驗證。
內部部署與 Google Cloud 資源之間的互動
將 Active Directory 延伸至Google Cloud 時，要考慮的第二個因素是內部部署與 Google Cloud之間的使用者與資源互動。視用途而定，此互動的程度可能從少量到大量之間的任意程度。
少量互動
如果在 Google Cloud 上使用 Active Directory 的唯一目的是管理一組 Windows 伺服器，並讓管理員能夠登入這些伺服器，環境之間的互動程度便屬於少量：
- 與 Google Cloud 上的資源互動的員工僅限管理人員。
- 部署至 Google Cloud 的應用程式可能根本不會與內部部署應用程式互動，就算會互動也不需要依賴 Kerberos 與 NTLM 等 Windows 驗證方式。
在少量的情境中，請考慮透過以下兩種方法之一來與您的內部部署及Google Cloud 環境互動。
兩個不連續的 Active Directory 樹系：您可以使用不共用信任關係的兩個個別的 Active Directory 樹系隔離兩個環境。如要讓管理員能夠驗證，您可在 Google Cloud樹系中為管理員維持個別一組使用者帳戶。
維持一組重複的使用者帳戶會增加管理工作，並可能在員工離開公司時產生忘記停用帳戶的風險。比較好的方法是自動佈建這些帳戶。
如果內部部署 Active Directory 中的使用者帳戶是由人力資源資訊系統 (HRIS) 佈建，您或許可以使用類似的機制，在Google Cloud 樹系中佈建及管理使用者帳戶。或者，您也可以使用 Microsoft Identity Manager 等工具，在環境之間同步處理使用者帳戶。
具有跨樹系信任的兩個 Active Directory 樹系：使用兩個 Active Directory 樹系並以跨樹系信任連線起來，便可避免維持重複的帳戶。管理員會使用相同的使用者帳戶驗證這兩個環境。儘管環境間的隔離程度可能較弱，使用個別的樹系將可讓您在內部部署與 Google Cloud 環境之間維持信任界線。
中等互動
您的用途可能比較複雜。例如：
- 管理員若要登入在Google Cloud 上部署的 Windows 伺服器，可能需要存取檔案共用區託管的內部部署。
- 應用程式可能會使用 Kerberos 或 NTLM 來跨環境界線驗證及通訊。
- 您可能會想要讓員工使用整合式 Windows 驗證 (IWA) 來向部署在 Google Cloud的網路應用程式驗證。
在中等情境中，操作兩個不連續的 Active Directory 樹系可能限制太多：您無法使用 Kerberos 跨兩個樹系進行驗證，而使用 NTLM 傳遞驗證則需要您保持帳戶與密碼的同步。
在此情況下，建議使用具有跨樹系信任的兩個 Active Directory 樹系。
大量互動
某些工作負載 (包括虛擬桌面基礎架構 (VDI) 部署) 可能需要在內部部署的資源與部署在 Google Cloud的資源之間進行大量互動。如果不同環境的資源緊密耦合，在環境之間維持信任界線可能不切實際，而且使用兩個樹系和跨樹系信任可能會受到太多限制。
在此情況下，建議使用單一 Active Directory 樹系並跨環境共用該樹系。
管理自主權
將 Active Directory 延伸至Google Cloud 時要考慮的第三個因素是管理自主權。
如果您打算跨內部部署與 Google Cloud分散工作負載，您要在 Google Cloud 上執行的工作負載可能會與您保持在內部部署中的工作負載大不相同，您甚至會決定讓不同的團隊管理兩個環境。
為不同的團隊區分責任需要授予每個團隊某些管理自主權。在 Active Directory 中，您可以使用委派管理或個別網域授予團隊管理資源的權限。
委派管理是委派管理職責及授予自主權給團隊的輕量級方法，維持單一網域也可以協助您確保在環境與團隊之間達成一致性。
但是，您無法委派所有管理能力，而且共用單一網域可能會增加在團隊之間進行協調的管理負擔。在此類情況下，建議使用個別網域。
可用性
將 Active Directory 延伸至Google Cloud 時要考慮的最後一個因素是可用性。對於 Active Directory 樹系中的每一個網域，網域控制器都可做為該網域中使用者的識別資訊提供者。
使用 Kerberos 進行驗證時，使用者需要在各個方面與 Active Directory 網域控制器進行互動：
- 初始驗證 (取得票證授權票證)。
- 定期重新驗證 (重新整理票證授權票證)。
- 向資源進行驗證 (取得服務票證)。
執行初始驗證與定期重新驗證只需要與單一網域控制器通訊，這是使用者所屬網域的網域控制器。
向資源進行驗證時，根據資源所在的網域，可能需要與多個網域控制器進行互動：
- 如果資源所在網域與使用者所在網域相同，使用者可以使用相同的網域控制器 (或者相同網域的不同網域控制器) 完成驗證流程。
- 如果資源位於不同的網域，但與使用者的網域之間存在直接信任關係，使用者就需要與至少兩個網域控制器進行互動：一個在資源網域中，另一個在使用者網域中。
- 如果資源與使用者分屬不同網域，而這些網域之間只有間接信任關係，那就需要與信任路徑中的每個網域的網域控制器通訊，才能成功完成驗證。
將使用者與資源放在不同的 Active Directory 網域或樹系中可能會使整體可用性受到限制。由於驗證需要與多個網域互動，一個網域服務中斷可能會對其他網域中的資源可用性造成影響。
考慮到 Active Directory 拓撲可能對可用性造成的影響，建議讓您的 Active Directory 拓撲符合您的混合策略。
分散式工作負載
如要利用每個運算環境的獨特能力，您可以使用混合方法來跨這些環境分散工作負載。在這樣的設定中，您部署至 Google Cloud 的工作負載可能會依賴執行內部部署的其他基礎架構或應用程式，這樣就會使高可用性的混合式連線成為關鍵需求。
如果您將個別的 Active Directory 樹系或網域部署至 Google Cloud，並使用信任來連線至您的內部部署 Active Directory，您就會在 Google Cloud 與內部部署環境之間增加其他相依性。這種相依性對可用性的影響極小。
備援工作負載
如果您使用 Google Cloud 來確保業務持續性，您在 Google Cloud 上的工作負載會在內部部署環境中啟動某些工作負載的鏡像作業。此設定可讓一個環境在發生故障時接管另一個環境的角色，因此，您需要瞭解這些環境之間的每一個相依性。
如果您將個別的 Active Directory 樹系或網域部署至 Google Cloud，並使用信任來連線至內部部署 Active Directory，您所建立的相依性可能會破壞設定的目的。如果內部部署 Active Directory 失去可用性，在Google Cloud 上部署且依賴跨網域或跨樹系驗證的所有工作負載也可能會失去可用性。
如果您的目標是確保業務持續性，可以在未連線到其他環境的每個環境中使用個別的 Active Directory 樹系。您也可以將現有的 Active Directory 網域延伸至Google Cloud。將其他網域控制器部署至Google Cloud ，並在環境之間複製目錄內容，可確保環境獨立運作。
整合模式
評估需求之後，請使用下列決策樹狀圖來協助識別適合的樹系與網域架構。
以下各節說明每種模式。
同步處理的樹系
在「同步處理的樹系」模式中，您會將個別的 Active Directory 樹系部署至 Google Cloud。您可以使用這個樹系來管理部署到 Google Cloud 的任何資源，以及管理這些資源所需的使用者帳戶。
您不必在新樹系與現有的內部部署樹系之間建立信任，而是可以同步處理帳戶。如果您使用 HRIS 做為管理使用者帳戶的領導系統，可以設定讓 HRIS 在 Google Cloud託管的 Active Directory 樹系中佈建使用者帳戶。您也可以使用 Microsoft Identity Manager 等工具，在環境之間同步處理使用者帳戶。
如果符合下列一或多個條件，請考慮使用同步處理的樹系模式：
- 您的 Google Cloud 預定用途符合其中一個備援部署模式，而且您想要避免在內部部署環境與 Google Cloud之間產生執行階段相依性。
- 您想要在內部部署 Active Directory 環境與 Google Cloud託管的 Active Directory 環境之間維持信任界線，這可能是為了做為一種深入防禦機制，或者是因為您對某一個環境的信任程度超過另一個環境。
- 您預期在 Active Directory 代管的資源內部部署與 Google Cloud之間不會產生互動或互動很少。
- 您在 Google Cloud託管的 Active Directory 環境中需要的使用者帳戶數很少。
優點：
- 同步處理的樹系模式可讓您在兩個 Active Directory 環境之間維持強烈的隔離關係。入侵一個環境的攻擊者可能無法順利藉此攻擊第二個環境。
- 您無須在內部部署與 Google Cloud 網路之間設定混合式連線就可以操作 Active Directory。
- Google Cloud託管的 Active Directory 不受內部部署 Active Directory 服務中斷的影響。這個模式非常適合業務持續性用途或其他需要高可用性的情境。
- 您可將大量的管理自主權授予管理 Google Cloud託管之 Active Directory 樹系的團隊。
- Managed Service for Microsoft Active Directory 支援此模式。
最佳做法：
- 不要在兩個 Active Directory 樹系之間同步處理使用者帳戶密碼，這樣做會破壞環境之間的隔離。
- 不要依賴傳遞驗證，因為這需要同步處理使用者帳戶密碼。
- 確定當員工離開公司時，已停用或移除員工在兩個 Active Directory 環境中的帳戶。
資源樹系
在「資源樹系」模式中，您會將個別的 Active Directory 樹系部署至 Google Cloud。您可以使用這個樹系管理部署至Google Cloud 的任何資源，以及管理樹系所需的一組最少的管理使用者帳戶。建立樹系信任到現有的內部部署 Active Directory 樹系，讓現有樹系的使用者驗證及存取Google Cloud託管的 Active Directory 樹系所管理的資源。
如有必要，可以將此模式提升至中心式/軸輻式拓撲，並使現有的 Active Directory 樹系位於中央，然後連線至許多資源樹系。
如果符合以下一或多個條件，請考慮使用資源樹系模式：
- 您的 Google Cloud 預定用途符合其中一個分散式部署模式，且內部部署環境與 Google Cloud之間的相依性是可接受的。
- 您想要在內部部署 Active Directory 環境與 Google Cloud託管的 Active Directory 環境之間維持信任界線，這可能是為了做為一種深入防禦機制，或者是因為您認為某一個環境的信任程度超過另一個環境。
- 您預期在 Active Directory 代管的資源內部部署與 GCP 之間會產生中等程度的互動。 Google Cloud
- 您有大量使用者需要存取部署在 Google Cloud的資源，例如存取使用 IWA 進行驗證的網路應用程式。
優點：
- 資源樹系模式可讓您在兩個 Active Directory 環境之間維持信任界線。根據信任關係的設定，入侵一個環境的攻擊者可能無法順利藉此存取另一個環境，或完全無法存取另一個環境。
- Managed Microsoft AD 完全支援這類模式。
- 您可將大量的管理自主權授予管理 Google Cloud託管之 Active Directory 樹系的團隊。
最佳做法：
- 使用單向信任來連線兩個 Active Directory 樹系，使 Google Cloud託管的 Active Directory 信任現有的 Active Directory，但反之則不然。
- 使用選擇性驗證來限制內部部署 Active Directory 中的使用者允許存取之 Google Cloud託管的 Active Directory 資源。
- 使用備援專屬互連網路、合作夥伴互連網路或 Cloud VPN 連線，確保在內部部署網路與 Google Cloud之間存在高可用性網路連線。
延伸的網域
在延伸的網域模式中，您可以將一或多個現有的 Active Directory 網域延伸至 Google Cloud。您可以在每個網域上部署一或多個網域控制器，以便複製所有網域資料和全域目錄，並在Google Cloud上提供這些資料。 Google Cloud為內部部署和 Google Cloud 子網路使用個別的 Active Directory 網站，可確保用戶端與最接近的網域控制站通訊。
如果符合以下一或多個條件，請考慮使用延伸的網域模式：
- 您的 Google Cloud 預定用途符合其中一個備援部署模式，而且您想要避免在內部部署環境與 Google Cloud之間產生執行階段相依性。
- 您預期在 Active Directory 代管的資源內部部署與Google Cloud之間的互動很多。
- 您想要加快依賴 LDAP 進行驗證的應用程式驗證速度。
優點：
- Google Cloud託管的 Active Directory 不受內部部署 Active Directory 服務中斷的影響。這個模式非常適合業務持續性用途或其他需要高可用性的情境。
- 您可以限制內部部署網路與Google Cloud之間的通訊，這可能可以節省頻寬並改善延遲時間。
- 全域目錄的所有內容都會複製到 Active Directory，並且可以從 Google Cloud託管的資源有效存取。
最佳做法：
- 如果您複製所有網域，內部部署網路與 GCP 網路之間的通訊會限制於在網域控制器之間複製 Active Directory。 Google Cloud 如果您只複製樹系網域的子集，在Google Cloud 上執行的納入網域的伺服器可能仍需要與非複製網域的網域控制器通訊。請確認適用於內部部署與 Google Cloud 之間通訊的防火牆規則考慮到所有相關個案。
- 請注意，跨站台複製只會以特定間隔發生，因此對內部部署網域控制器執行的更新只會在一段延遲時間之後出現在Google Cloud (反之亦然)。
- 請考慮使用唯讀網域控制器 (RODC) 來在 Google Cloud上維持網域資料的唯讀副本，但請注意，在快取使用者密碼方面可能需要進行相關取捨。如果您允許 RODC 快取密碼並預先填入密碼快取，部署在 Google Cloud 的資源可以保持不受內部部署網域控制器服務中斷的影響。但是，使用 RODC 的安全性優點並不會比使用正常網域控制器好多少。如果您停用密碼快取，遭到入侵的 RODC 可能只會對其餘 Active Directory 造成有限風險，但您會失去Google Cloud 保持不受內部部署網域控制器服務中斷影響的好處。
延伸的樹系
在「延伸的樹系」模式中，您會在Google Cloud上部署新的 Active Directory 網域，但將該網域整合到現有樹系中。您會使用新的網域管理在 Google Cloud 上部署的任何資源，並維持管理網域所需的一組最少的管理使用者帳戶。
將隱含信任關係延伸到樹系的其他網域，可讓其他網域的現有使用者驗證及存取 Google Cloud託管之 Active Directory 網域所管理的資源。
如果符合以下一或多個條件，請考慮使用延伸的樹系模式：
- 您的 Google Cloud 預定用途符合其中一個分散式部署模式，且內部部署環境與 Google Cloud 之間的相依性是可接受的。
- 您打算部署至 Google Cloud 的資源所需要的網域設定或結構與現有網域提供的網域設定或結構不同，或者您想要將大量的管理自主權授予管理 Google Cloud託管之網域的團隊。
- 您預期在 Active Directory 代管的資源內部部署與 GCP 之間的互動很多。 Google Cloud
- 您有許多使用者需要存取部署至 Google Cloud的資源，例如存取使用 IWA 進行驗證的網路應用程式。
優點：
- 全域目錄的所有內容都會複製到 Active Directory，並且可以從 Google Cloud託管的資源有效存取。
- 您的內部部署網路與Google Cloud 之間的複製流量受限於全域目錄複製，這可能有助於限制您的整體頻寬耗用。
- 您可將大量的管理自主權授予管理 Google Cloud託管之 Active Directory 網域的團隊。
最佳做法：
- 使用備援「專屬互連網路」、「合作夥伴互連網路」或「Cloud VPN」連線，確保在內部部署網路與 Google Cloud之間存在高可用性網路連線。
具有延伸網域的資源樹系
「具有延伸網域的資源樹系」模式是資源樹系模式的延伸。資源樹系模式可讓您在環境之間維持信任界線，並提供管理自主權。資源樹系的限制是，其完整可用性取決於內部部署網域控制器的可用性及內部部署資料中心的網路連線是否可靠。
您可以結合資源樹系模式與延伸的網域模式來突破這些限制。您的使用者帳戶可以透過複製網域的方式放進 Google Cloud，即使內部部署網域控制器無法使用或網路連線中斷，您也可以確保使用者能夠向 Google Cloud託管的資源驗證。
如果符合以下一或多個條件，請考慮使用具有延伸網域的資源樹系模式：
- 您想要在主 Active Directory 樹系與資源樹系之間維持信任界線。
- 您想要防止因內部部署網域控制器服務中斷或內部部署環境的網路連線中斷而影響到Google Cloud託管的工作負載。
- 您預期在 Active Directory 代管的資源內部部署與 Google Cloud之間會產生中等程度的互動。
- 您有來自單一 Active Directory 網域的許多使用者需要存取部署在 Google Cloud的資源，例如存取使用 IWA 進行驗證的網路應用程式。
優點：
- Google Cloud託管的資源不受內部部署 Active Directory 服務中斷的影響。這個模式非常適合業務持續性用途或其他需要高可用性的情境。
- 這個模式可讓您在兩個 Active Directory 樹系之間維持信任界線。根據信任關係的設定，入侵一個環境的攻擊者可能無法順利藉此存取另一個環境，或完全無法存取另一個環境。
- 內部部署網路與 Google Cloud網路之間的通訊會限制於在網域控制器之間複製 Active Directory。您可以實作防火牆規則來禁止其他所有通訊，進而加強環境之間的隔離。
- 您可將大量的管理自主權授予管理 Google Cloud託管之 Active Directory 樹系的團隊。
- 您可以為資源樹林使用代管的 Microsoft AD。
最佳做法：
- 將延伸的網域的網域控制器部署至個別的Google Cloud 專案和VPC，藉以將這些元件與資源樹系的元件分隔開來。
- 使用虛擬私有雲對等互連將虛擬私有雲連線至共用虛擬私有雲或資源樹系使用的虛擬私有雲，並設定防火牆來限制與 Kerberos 使用者驗證及樹系信任建立之間的通訊。
- 使用單向信任來連線兩個 Active Directory 樹系，使 Google Cloud託管的 Active Directory 信任現有的 Active Directory 樹系，但反之則不然。
- 使用選擇性驗證來限制其他樹系的使用者允許存取的資源樹系資源。
- 請注意，跨站台複製只會以特定間隔發生，因此對內部部署網域控制器執行的更新只會在一段延遲時間之後出現在Google Cloud (反之亦然)。
- 請考慮針對延伸的網域使用 RODC，但請務必允許快取密碼，以保留相較於資源樹系模式的可用性優勢。
後續步驟
- 進一步瞭解Microsoft AD 受控服務。
- 請參閱在 Google Cloud上部署 Active Directory 資源樹系的最佳做法。
- 瞭解如何將容錯 Active Directory 環境部署至 Google Cloud。
- 查看我們關於虛擬私人雲端設計的最佳做法。
- 如需更多參考架構、圖表和最佳做法，請瀏覽 雲端架構中心。