本指南將說明在 Google Cloud上執行 Active Directory 的最佳做法。本指南著重於在 Google Cloud上部署 Active Directory 時，專屬於 Google Cloud 或特別重要的做法。您可以將本指南視為 Microsoft 發布的Active Directory 安全性最佳做法的補充資料。
架構
下列章節將詳細說明架構相關的最佳做法。
使用最符合需求的架構模式
如要在 Google Cloud上部署 Active Directory，您必須先決定要使用哪個網域和樹系架構。如果您已使用 Active Directory，也必須決定是否要整合這兩個環境，以及如何整合。
最適合您情況的設計取決於多項因素，包括內部部署網路的設計、內部部署和Google Cloud 資源的互動方式，以及您對可用性和管理自主權的要求。請參閱在混合環境中使用 Active Directory 的模式，瞭解這些因素如何決定您的設計。
如果您想在Google Cloud 與內部部署環境之間維持信任界線，請考慮實作資源樹系模式。在這個模式中，您會在 Google Cloud 上部署個別樹系，並使用單向樹系信任來整合 Google Cloud 樹系與現有的內部部署 Active Directory 樹系。
將測試和實際工作環境分開
視您使用 Active Directory 的方式而定，您可能需要在應用程式開發和測試期間，經常變更 Active Directory 中的設定。開發人員可能需要能夠建立及修改有效的目錄帳戶、變更群組成員資格 (如果應用程式使用群組來處理授權)，或加入及移除電腦。
為避免開發和測試工作影響實際工作負載或妨礙部署作業的安全性，建議您為開發和測試作業部署個別的 Active Directory 網域或樹系。
您也可以建立不同的開發和測試網域或樹狀結構，在將管理變更套用至實際工作環境前先驗證。這類變更的例子包括實驗群組政策、測試自動化指令碼，或提高森林功能層級等可能有風險的動作。
除了在 Google Cloud上部署 Active Directory，還要設定 Cloud Identity 聯盟
在 Google Cloud 上部署 Active Directory，可讓您管理 Google Cloud上的 Windows VM，讓使用者可以使用現有的使用者帳戶登入 Windows VM，並支援依賴 Kerberos、NTLM 或 LDAP 進行驗證的應用程式。
不過，您必須使用 Google 身分驗證，才能使用 Google Cloud 主控台、gcloud 指令列工具或其他 Google 和 Google Cloud 工具。因此，如果您打算將 Active Directory 做為管理使用者的首要系統，在 Google Cloud 上部署 Active Directory 並不會取代將現有 Active Directory 與Google Cloud進行整合。
舉例來說，如果您在 Google Cloud上部署個別的樹系，就可以設定與內部部署 Active Directory 的跨網域服務，如以下圖表所示。在這種情況下，在內部部署的 Active Directory 中擁有帳戶的使用者就能使用需要 Google 身分識別資訊的工具，以及需要 Active Directory 驗證的應用程式。
如果您決定擴充現有的樹狀結構或網域至 Google Cloud，也可以選擇使用部署在 Google Cloud 上的網域控制站和 AD FS 伺服器來設定聯合服務。
連結後，您也可以為 Google 帳戶和 Active Directory 帳戶強制執行通用生命週期，這樣一來，當您在內部部署的 Active Directory 中停用使用者帳戶時，對應的 Google 使用者也會遭到停權。
網路
以下章節將詳細說明網路相關的最佳做法。
將 Active Directory 部署至共用虛擬私有雲網路
如要讓多個專案都能使用 Active Directory，請將網域控制器部署至共用虛擬私有雲網路。使用共用虛擬私有雲網路有許多優點：
每個可能需要 Active Directory 存取權的應用程式，都可能會部署至個別專案。使用不同的專案有助於隔離資源，並可個別管理存取權。
您可以為 Active Directory 網域控制器使用專屬專案，藉此精細控管哪些使用者可以存取相關 Google Cloud 資源。
共用虛擬私有雲網路可讓您集中管理 IP 位址和防火牆設定，有助於確保多個專案的一致性。
由於 VPC 是全域資源，您可以在多個區域中使用相同的共用 VPC 網路。
不要將網域控制站公開給外部
為縮小 Active Directory 的攻擊面，請避免將外部 IP 位址指派給網域控制器。
由於沒有外部 IP 位址的 VM 執行個體預設無法存取網際網路，因此您需要採取額外步驟，確保 Windows 啟用和 Windows 更新不會在網域控制器上受損。
如要支援 Windows 啟用功能，請在您打算部署網域控制器的子網路上啟用 私人 Google 存取權，並確保 VM 執行個體可以存取 kms.windows.googlecloud.com。這樣一來，即使沒有直接網際網路存取權，也能啟用 Windows。
您可以透過多種方式支援 Windows 更新：
您可以部署 Cloud NAT，透過 NAT 閘道存取網際網路。
如果您已設定混合式連線，也可以透過內部 NAT 閘道或 Proxy 伺服器轉送傳出流量。
提前為網域控制器預留靜態 IP 位址
由於網域控制站可做為 DNS 伺服器使用，因此需要指派不會變更的 IP 位址。為達到這項目標，請為網域控制器 VM 設定靜態內部 IP 位址。
預留 IP 位址時，系統會自動選擇未使用的位址。為確保網域控制器的 IP 位址容易記憶，請預留內部靜態 IP 位址。
在網域控制器上，將網路介面的 IP 位址設為相同的位址。雖然這個步驟並非必要，但可防止 Active Directory 發出警告訊息，指出機器的 IP 位址可能仍會動態指派。
在多個區域部署網域控制站
如要提高可用性，請至少部署兩個網域控制站，並將這些控制站分散在多個區域中。由於子網路和 IP 位址不會與區域綁定，因此您可以將所有網域控制器部署至單一子網路。
如果您打算在多個地區部署工作負載，請考慮在每個相關區域部署網域控制站。由於子網路屬於地區性資源，因此如果要部署至其他區域，就必須額外建立子網路。
為每個區域建立一個網站
當用戶端嘗試尋找網域控制器時，會先在與用戶端 IP 位址相對應的 Active Directory 網站中尋找網域控制器。如果這個網站沒有可用的網域控制器，用戶端會繼續嘗試在其他網站中找出網域控制器。
您可以為部署網域控制站或網域用戶端的每個區域建立個別網站，充分利用這項行為。接著，用戶端會自動優先使用位於相同區域的網域控制器，這有助於減少延遲時間和區域間的資料傳輸成本。
如果您的客戶位於沒有網域控制器的區域，您可以調整網站連結費用，反映區域的地理位置相近程度，並啟用「嘗試下一個最近的網站」設定，藉此影響這些客戶選擇的網域控制器。
使用多個網站會影響網域控制器之間的複寫行為。使用多個網站的一個缺點，是網站之間的複製作業頻率不如網站內部複製作業頻繁。
不過，您無法在 Managed Microsoft AD 中建立 Active Directory 網站，因為 Managed Microsoft AD 不支援 Active Directory 網站和服務功能。
使用 Cloud DNS 私人轉送區域
在 Compute Engine 中建立新的 VM 執行個體時，作業系統會預先設定為使用預設 DNS 伺服器，以便存取 內部 DNS 和公用 DNS。
將機器加入 Active Directory 網域前，您必須確保機器能夠解析由 Active Directory 管理的 DNS 記錄。Compute Engine 為 VM 執行個體設定的預設 DNS 伺服器可提供 內部 DNS 和公開 DNS 的存取權，但無法解析由 Active Directory 管理的 DNS 名稱。
在 Cloud DNS 中建立私人 DNS 轉送區域，讓用戶端解析由 Active Directory 管理的 DNS 記錄。設定該區域，將符合 Active Directory 網域的查詢轉送至網域控制器。
與設定用戶端直接使用 Active Directory 網域控制器做為 DNS 伺服器相比，使用私人 DNS 轉送區域有許多優點：
您不需要調整 VM 執行個體的網路設定。這可簡化建立新 VM 的程序。
升級或降級網域控制器時，您只需更新私人 DNS 轉送區域的設定，無須修改任何用戶端設定。
VM 執行個體仍可存取內部 DNS。
任何不符合 Active Directory 網域的 DNS 記錄都會由 Cloud DNS 處理，藉此減少網域控制器的負載。
如果您使用多個網域，請為每個 Active Directory 網域建立個別的私人 DNS 轉送區域。
Cloud DNS 私人轉送區域的範圍僅限於單一 VPC。如果您使用對等互連連線多個 VPC，則可透過設定DNS 對等互連，將私人轉送區域公開給其他 VPC。
您仍必須在網域控制站上手動設定 DNS 設定。使用 127.0.0.1 做為主要 DNS 伺服器，並視需要使用其他網域控制器的 IP 位址做為次要 DNS 伺服器。詳情請參閱「建議的 DNS 設定和其他選項」。
混合式連線
下一個章節將詳細說明混合式連線的最佳做法。
使用 DNS 傳入轉送功能，從內部部署環境解析 DNS 名稱 Google Cloud
內部部署網路中的用戶端可能需要解析部署在 Google Cloud上的資源 DNS 名稱。如果您擴充作業空間或在Google Cloud上部署資源作業空間，請使用 DNS Inbound Forwarding，讓內部部署用戶端能夠查詢在 Google Cloud上部署的資源 DNS 記錄。如要使用傳入轉送，請建立 DNS 伺服器政策，以便分配傳入轉寄站 IP 位址，並讓內部部署網路存取這個位址。
如果 Google Cloud 使用的 DNS 網域(例如 cloud.example.com) 是內部部署 DNS 網域 (例如 example.com) 的子網域，請設定 DNS 委派。在內部部署的網域中建立 NS 記錄，指向傳入轉寄站 IP 位址。NS 記錄會導致用戶端嘗試在 Google Cloud代管的網域中查詢 DNS 名稱，並將其重新導向至入站轉送器 IP 位址。
如果 Google Cloud 和內部部署的 Active Directory 使用的 DNS 網域不同 (例如 cloud.example.com 和 corp.example.com)，請在內部部署的網域中設定條件式 DNS 轉送，並使用內送轉寄站 IP 位址做為目標。當系統要求解析 Google Cloud代管網域中的 DNS 名稱時，內部部署的網域控制器會將要求轉送至入站轉送器 IP 位址。
使用內送 DNS 轉送時，請確認防火牆已正確設定。
如果您將現有網域延伸至 Active Directory，就不需要 DNS Inbound Forwarding。在這種情況下，網域的所有 DNS 記錄會自動複製到 Google Cloud 和貴機構的內部環境，並可在兩個環境中查詢。
使用 DNS 傳出轉送功能，從 Google Cloud解析內部部署 DNS 名稱
在 Google Cloud 上執行的用戶端可能需要能夠解析在內部部署的資源名稱。如果您擴充作業森林或在 Google Cloud上部署資源作業森林，請在 Cloud DNS 中建立私人轉送區域，將內部部署網域的 DNS 查詢轉送至內部部署 DNS 伺服器。
使用外送 DNS 轉送功能時，請確認防火牆已正確設定。
如果您將現有網域擴充至 Active Directory，就不需要 DNS 出站轉送。在這種情況下，系統會自動在 Google Cloud 和內部環境中複製網域的所有 DNS 記錄，並在兩個環境中提供查詢。
使用 VPN 通道保護 LDAP 流量
Active Directory 大量使用 LDAP 通訊協定。與 Active Directory 使用的大多數其他通訊協定不同，LDAP 預設不會加密。
Google Cloud 可確保虛擬機器之間的流量經過加密，因此您可以在虛擬私有雲端中使用未加密的 LDAP。如果您將虛擬私有雲連線至內部部署網路，請確保 LDAP 流量只透過可信任的管道交換。
如果您使用 Cloud VPN 連線至 Google Cloud 和內部部署網路，Google Cloud 和內部部署 VPN 端點之間的流量就會自動使用 IPSec 加密。
Cloud Interconnect 和合作夥伴互連 不提供加密功能。為確保通訊安全，請使用 Google Cloud Marketplace 提供的 VPN 裝置，透過 Interconnect 連線建立 VPN 通道。
為樹狀結構信任關係使用選擇性驗證和 AES
在 Active Directory 樹系之間建立信任關係時，請優先使用樹系信任關係，而非外部信任關係，並善用下列功能來提升安全性：
在資源樹系中啟用傳出信任的選擇性驗證。選擇性驗證可確保機構樹系中的使用者無法存取資源樹系中的資源，除非明確授予權限。
針對組織樹林中的傳入信任關係，啟用 Kerberos 完整委派的強制執行森林邊界。這項功能可防止權限提升攻擊，方法是禁止資源區塊中的資源向組織區塊中的使用者要求票證授予票證 (TGT)。
建立信任關係時，請啟用「其他網域支援 Kerberos AES 加密」選項。這個選項可確保用於跨林驗證的票證會使用 AES 加密，而非安全性較低的 RC4 演算法。
安全性
下一個章節將詳細說明安全性相關的最佳做法。
避免 Google Cloud 安全性干擾 Active Directory 安全性
Active Directory 可讓您精細控管哪些使用者可以存取哪些資源。當機器以 VM 執行個體的形式部署在 Compute Engine 中，且使用者可存取基礎 Google Cloud專案時，您必須考慮其他可能允許使用者存取機器的路徑：
在 Google Cloud 專案中獲派 Compute 執行個體管理員角色的專案成員，可以使用重設密碼功能建立本機管理員帳戶。本機管理員帳戶可能會危害 Active Directory 網域的安全，因為這些帳戶可用於破壞群組政策，或安裝可能擷取其他登入使用者網域憑證的惡意軟體。
只要新增啟動指令碼，具有權限的專案成員就能在下次重新啟動機器時，將惡意程式碼注入以
nt authority\system執行的 VM。透過序列主控台，具有權限的專案成員也可以存取 Windows Special Administrative Console (SAC)。Windows 會將透過 SAC 的登入作業視為本機登入作業。因此，SAC 可能會遭到濫用，用來規避拒絕透過 RDP 登入的政策，但卻會錯過拒絕本機登入的政策。
具有特殊權限的專案成員可以使用 SAC 發出
crashdump指令，這可能會導致記憶體傾印寫入磁碟。這類記憶體傾印可能包含機密資訊和憑證。將永久磁碟掛載至其他 VM 或使用快照時，具有特權的專案成員可能會從使用者無法登入的電腦存取磁碟內容 (可能包括記憶體傾印)。
使用代管的 Microsoft AD 時，預設會提供更完善的保護措施，以防範這些額外的存取路徑。這項服務不允許專案中的特權使用者重設網域管理員密碼、執行啟動腳本，或存取 AD 網域控制器 VM 上的序列主控台。
為進一步降低這些風險，請確保包含已加入網域的 VM 執行個體的專案，是以最小權限管理身分與存取權管理權限。您可以透過使用者採用機構政策、群組政策和受防護的 VM，進一步降低風險：
使用機構政策停用序列埠存取權。
套用群組政策，藉由停用帳戶管理員來防止建立本機系統管理員帳戶。在群組原則中定義 INI 檔案偏好設定 (依序前往「Computer Configuration」>「Preferences」>「Windows Settings」>「Ini Files」)，以套用下列設定：
- 動作：更新
- 檔案路徑：
C:\Program Files\Google\Compute Engine\instance_configs.cfg - 區段名稱：
accountManager - 資源名稱：
disable - 屬性值：
true
套用群組原則，從 VM 執行個體中移除任何本機管理員帳戶。使用「本機使用者和群組」功能 (「電腦設定」>「偏好設定」>「控制台設定」>「本機使用者和群組」)，從「管理員」群組和其他敏感群組中移除群組成員。
建議您使用受防護的 VM 搭配 BitLocker 磁碟加密功能，避免未經授權的使用者讀取永久磁碟或快照。
避免 Active Directory 安全性干擾 Google Cloud 安全性
在 Active Directory 網域中，機器會信任網域控制器來代表機器處理驗證與授權作業。除非受到群組政策、機器的本機安全性政策或選擇性驗證的限制，否則只要使用者已向其中一個網域控制器證明其身分，便可登入網域中的任何機器。
Active Directory 使用者可登入任何電腦，這可能會讓攻擊者在網域中執行橫向移動。如果某些 VM 執行個體不受防火牆限制，或使用 Google Cloud 服務帳戶，這類橫向移動可能會導致權限提升：VM 執行個體上的所有程序和使用者都可以存取服務帳戶的憑證。因此，任何可使用 Active Directory 登入機器的使用者，都能存取這些服務帳戶憑證，取得服務帳戶授予存取權的任何 Google Cloud資源。
設定 Managed Microsoft AD 時，服務會建立群組，讓特定使用者輕鬆透過 RDP 存取已加入網域的 VM。
為降低橫向移動的風險，請將使用者分類為不同的管理層級，並使用「從網路拒絕存取這部電腦」和「拒絕透過遠端桌面服務登入」群組政策，根據層級限制對 VM 的存取權。
在資源樹系拓樸中，請進一步利用選擇性驗證，進一步限制其他樹系中允許登入 VM 的使用者組合。您可以透過對齊 Google Cloud 和 Active Directory 資源結構，簡化選擇性驗證權限的管理作業：如果 Active Directory 機構單位對應至 Google Cloud 專案，您就可以授予使用者驗證權限，以便在與 Google Cloud 專案相符的層級進行驗證。
如果無法套用選擇性驗證或群組政策，請建立個別的服務帳戶，匯出服務帳戶金鑰，將金鑰儲存至 VM 執行個體的本機磁碟或檔案共用，並使用 NTFS ACL 保護金鑰，這樣只有經過授權的 Active Directory 使用者才能讀取及使用金鑰。
使用專屬專案來管理網域控制器
網域控制器在 Active Directory 網域的安全性中扮演重要角色，如果單一網域控制器遭到入侵，整個 Active Directory 樹系都可能受到影響。
為降低未經授權存取的風險，請使用獨立的 Google Cloud 專案部署網域控制站，並運用最低權限原則授予這個專案的存取權。建立專案時，請注意部分權限可能會從上層資料夾繼承。為避免不慎透過繼承授予存取權，建議您在一般資料夾階層以外的位置建立專案。
為專案設定 IAM 政策時，請特別注意限制存取 VM 執行個體、含有 ntds.dit 資料庫的永久磁碟，以及可能含有備份的任何儲存位置。
除了使用 IAM 政策限制專案存取權外，也防止專案遭到意外刪除。
使用不同的 VM 和專案管理 Active Directory
如要管理 Active Directory，您必須能夠使用 Active Directory 使用者和電腦或 Active Directory 管理中心等工具。這些工具需要您使用特殊權限網域帳戶登入，因此在您執行這些工具的電腦上，會成為盜用憑證或鍵盤記錄的目標。
為盡可能降低攻擊者取得特權網域憑證的風險，請使用專屬的 VM 執行個體來管理網域，並處理特權存取工作站等管理 VM：
使用群組政策，確保只有特定的使用者才能登入管理 VM。如果您已實施分層管理，這群使用者就會對應至第 0 層。
與網域控制站類似，專案成員建立本機系統管理員帳戶、透過序列控制台登入，或竄改其永久磁碟，都可能讓管理 VM 面臨風險。為降低未經授權存取的風險，請使用獨立的 Google Cloud 專案來管理 VM，並根據最低權限原則授予此專案的存取權。
如果您打算使用混合式連線功能，從內部部署網路存取管理 VM，請將管理 VM 部署至專屬的虛擬私有雲子網路。您可以使用專用於管理 VM 的子網路，在設定內部部署防火牆時，更清楚區分管理 VM 和其他 VM。如果您使用共用虛擬私有雲，請使用子網路層級權限，確保只有具備權限的管理員才能將 VM 執行個體部署至管理子網路。這項做法有助於確保，如果內部部署防火牆為管理 VM 套用不同規則，使用者就無法將非管理 VM 放入管理子網路，藉此規避防火牆規則。
此外，請考慮將管理 VM 的登入限制管理群組政策限制在管理子網路中。這項做法會強制將登入限制 (根據群組政策) 與防火牆規則 (根據子網路/IP 位址) 對齊。
除了使用 IAM 政策限制專案存取權外，也防止專案遭到意外刪除。
使用防火牆規則保護網域控制站和伺服器
網域控制器會公開多項服務，包括 LDAP、DNS、Kerberos 和 RPC。視用途而定，在 Google Cloud上部署的 VM 和在內部部署的機器，可能需要存取這些服務的不同子集，才能充分運用 Active Directory。
使用 Managed Microsoft AD 時，AD 網域控制器會部署在專屬租用戶專案中。代管 AD 網域控制站的網路會自動受到強化的 AD 專屬防火牆規則保護。
為減少網域控制器和 VM 的攻擊面，請使用防火牆禁止任何非必要的網路通訊。如要進一步瞭解如何在防火牆中使用 Active Directory，請參閱這篇文章，瞭解如何從 VPC 或內部部署網路存取 Active Directory。
將 Active Directory 資源和使用者分類為管理層級
在 Active Directory 樹系中，有些機器對 Active Directory 的整體安全性至關重要。網域控制器和管理 VM 是兩個特別重要的機器，因此特別容易受到潛在攻擊。
如要判斷每部機器的重要性，請使用等級分類法。雖然正確的層級數量取決於您的具體設定，但您可以先區分三個層級：
層級 0 (極為重要)：這個層級包含對 Active Directory 樹系安全性至關重要的所有機器。一旦單一第 0 層機器遭到入侵，您就必須假設整個樹系都遭到入侵。
第 1 級 (重要)：這個層級包含環境中的大部分伺服器，包括應用程式伺服器和資料庫伺服器。遭到入侵的 Tier 1 伺服器可能會對業務造成重大影響，但不會對整個林區造成立即威脅。
第 2 級 (一般)：這個等級包括工作站或其他通用機器。等級 2 機器遭到入侵，對業務和整體安全性影響有限。
雖然遭到入侵的 2 級機器可能會造成的立即影響似乎有限，但仍有連鎖效應的風險：當有權存取 0 級或 1 級機器的使用者被誘騙登入遭到入侵的 2 級機器時，可能會成為按鍵記錄程或其他形式的憑證竊取工具的受害者。擷取的憑證可能會用於攻擊更高層級的機器，導致整體影響擴大。
為避免這種連鎖效應，請務必不僅將機器分類，也將使用者帳戶分類，並限制這些使用者可存取哪些機器：
第 0 級 (極為重要)：可存取第 0 級機器的使用者。
第 1 級 (重要)：可存取第 1 級機器的使用者。
第 2 級 (一般)：可存取第 2 級機器的使用者。
請參考下表，瞭解哪些使用者應具備哪些資源的存取權：
| 群組 | 級別 | 網域存取權 | 第 0 級電腦存取權 | 級別 1 電腦存取權 | 第 2 級電腦存取權 |
|---|---|---|---|---|---|
| Active Directory 管理員 | 0 | 管理員 | 受限使用者 | 已封鎖 | 已封鎖 |
| 管理伺服器管理員 | 0 | 受限使用者 | 管理員 | 已封鎖 | 已封鎖 |
| 伺服器管理員 | 1 | 受限使用者 | 已封鎖 | 管理員 | 已封鎖 |
| VDI 工作站管理員 | 2 | 受限使用者 | 已封鎖 | 已封鎖 | 管理員 |
| VDI 工作站使用者 | 2 | 受限使用者 | 已封鎖 | 已封鎖 | 受限使用者 |
如要進一步瞭解如何在 Active Directory 中導入管理層級模型，以及相關最佳做法，請參閱 Microsoft 說明文件。
在 Active Directory 樹系中使用管理層級模型時，請確保其完整性不會因樹系信任關係而受損。如果信任的樹系也套用分層管理模式，請使用選擇性驗證，確保信任樹系的使用者只能存取同層中的資源：
如果信任的樹系未實施分層管理，請將信任的樹系對應至特定層級，並使用選擇性驗證，確保信任樹系的使用者只能存取該特定層級的資源。
針對內部部署主機使用 VPC Service Controls 和私人 Google 存取權
Managed Microsoft AD API 可讓您重設管理員密碼，並執行其他機密作業。對於重要的實際部署作業，建議您啟用 VPC Service Controls，並針對內部部署主機使用私人 Google 存取權，以提升安全性。
管理
下一個章節將詳細說明 Active Directory 管理的最佳做法。
對齊 Google Cloud 和 Active Directory 資源結構
在Google Cloud上部署新的 Active Directory 網域或樹系時，您必須定義機構單位 (OU) 結構，以便透過 Active Directory 網域整理資源。請建立與Google Cloud 資源階層相符的 OU 結構，而非設計全新結構或套用在內部部署環境中使用的結構：
如果您使用分層管理模式，則頂層 OU 必須反映您的管理層級。
針對每個層級，為使用者和群組建立 OU。如果您打算管理大量使用者和群組，請視需要建立子 OU。
針對每個層級，建立
ProjectsOU，並為每個包含 Active Directory 資源的 Google Cloud 專案建立子 OU。使用專屬的專案子 OU 管理電腦帳戶、服務帳戶或其他 Active Directory 資源，這些資源與 Google Cloud相關專案的資源相對應。請確認 OU 和專案之間的對應關係為 1:1。
下圖為遵循這些原則的階層範例：
如果含有 Active Directory 資源的專案數量適中，您可以在 Projects 機構單位下建立平面機構單位結構。如果您要管理大量專案，且已設計Google Cloud 資源階層來使用多個層級的資料夾，建議您在 Projects OU 下方反映這個資料夾結構。
將 Active Directory OU 結構和 Google Cloud 資源階層對齊有幾項優點：
使用 IAM 政策將管理權限委派給 Google Cloud 專案時，您可能還需要在 Active Directory 中授予專案使用者特定權限。舉例來說，Compute Engine 管理員可能需要能夠將機器加入特定 OU 下的網域。對齊 OU 和 Google Cloud 專案後，您就能在 Active Directory 中授予與 Google Cloud相同精細度的權限。
如果您打算使用群組政策物件 (GPO) 來管理電腦，則反映 Google Cloud 資源階層的 OU 結構有助於確保 GPO 能一致地套用至特定專案或資料夾的所有 VM。
如果您使用跨林區信任關係搭配條件式驗證，則可以使用與 Google Cloud 專案相對應的 OU，針對每個專案授予「允許驗證」權限。
在 Google Cloud中刪除專案時，您可以直接刪除相關聯的 OU，降低在目錄中留下過時資源的風險。
如果您認為 OU 結構需要與專案結構有所出入，這可能表示您的專案結構過於精細或過於粗略。
使用 Google 時間伺服器
Kerberos 驗證會在通訊協定中使用時間戳記。如要成功驗證，用戶端和伺服器機器的時鐘必須在特定範圍內同步。根據預設，Active Directory 允許的差異時間不得超過 5 分鐘。
在內部部署的 Active Directory 環境中，以下是同步時間的預設設定：
- 加入網域的機器會與網域控制站同步時間。
- 網域控制站會將時間與網域的 PDC 模擬器同步。
- 所有網域的 PDC 模擬器都會將時間與林根網域的 PDC 模擬器同步。
在這種設定中，樹狀結構根網域的 PDC 模擬器是 Active Directory 的最終時間來源，通常會將這部電腦設定為使用外部 NTP 伺服器做為時間來源。
在 Compute Engine 上，Windows VM 的預設設定是使用中繼資料伺服器 (metadata.google.internal) 做為 NTP 伺服器，而後者會依賴 Google 的 NTP 伺服器來取得正確時間。將 VM 加入 Active Directory 網域不會變更這項預設設定。
除非您的樹狀結構根網域的 PDC 模擬器是部署在 Google Cloud外，否則請保留 Compute Engine 的預設設定。
如果 PDC 模擬器部署在 Google Cloud以外的位置，請將其設定為使用 time.google.com 做為 NTP 來源。或者，您也可以將 Compute Engine VM 重新設定為使用 DOMHIER NTP 來源，並設定防火牆規則，允許網域控制站的 NTP 流量 (UDP/123) 傳入，藉此還原與 PDC 模擬器同步時間的預設 Active Directory 行為。
整合及監控稽核記錄
在 Google Cloud上部署 Active Directory 時，Active Directory 樹系和 Google Cloud 專案的安全性會相互連結：Active Directory 和 Windows 中的可疑活動可能會危及其他資源的安全性，就像 Google Cloud 中的可疑活動可能會讓您的 Active Directory 處於危險狀態一樣。
一致的稽核記錄是及早找出威脅或設定錯誤的重要工具，可讓您重建及檢查過去的活動。Cloud 稽核記錄可讓您擷取及分析管理員活動記錄和資料存取記錄。同樣地，您也可以使用防火牆規則記錄和虛擬私有雲流程記錄來分析網路流量。不過，這些平台服務不會察覺在 Active Directory 中發生的任何安全性相關事件。如要建立涵蓋平台相關稽核事件和 Active Directory 相關稽核事件的一致稽核記錄，請在網域控制器和加入網域的電腦上安裝 Cloud Logging 代理程式，將 Windows 安全性記錄檔匯出至 Cloud Logging。
根據預設，Windows 安全性事件記錄可能不會擷取您用於稽核作業所需的所有事件。請參閱 Microsoft 針對設定稽核政策和監控 Active Directory 是否有遭到入侵的跡象的建議，確保您能擷取所有相關稽核事件。
處理大量事件時，很容易遺漏重要事件。為避免遺漏重要事件，請為可能特別嚴重或可疑的事件建立記錄指標，並考慮設定快訊，在事件發生率變更或超過可接受的閾值時通知您。
後續步驟
找出最適合您情況的在混合環境中使用 Active Directory 的模式。
歡迎自行試用其他 Google Cloud 功能。請參閱教學課程。