本指南說明在 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 部署個別樹系，並使用單向樹系信任，將該樹系與現有的內部部署 Active Directory 樹系整合。 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 Cloud 主控台、gcloud 指令列工具或其他 Google 和 Google Cloud 工具，您必須使用 Google 身分驗證。因此，在 Google Cloud 上部署 Active Directory 並不能取代將現有 Active Directory 與Google Cloud聯合，如果您打算使用 Active Directory 做為管理使用者的主要系統，就更是如此。
舉例來說，如果您在 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，請將網域控制器部署至共用 VPC 網路。使用共用虛擬私有雲網路有許多優點：
每個可能需要存取 Active Directory 的應用程式，都可以部署到個別專案。使用不同的專案有助於隔離資源，並個別管理存取權。
您可以為 Active Directory 網域控制器使用專屬專案，精細控管哪些使用者可以存取相關資源。 Google Cloud
共用 VPC 網路可讓您集中管理 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 傳入轉送，允許內部部署用戶端查詢 Google Cloud上部署的資源 DNS 記錄。如要使用傳入轉送功能，請建立 DNS 伺服器政策，分配傳入轉寄站 IP 位址，並讓內部部署網路存取這個位址。
如果 Google Cloud 使用的 DNS 網域(例如 cloud.example.com) 是內部部署使用的 DNS 網域 (例如 example.com) 的子網域，請設定 DNS 委派。在內部部署網域中建立指向傳入轉寄站 IP 位址的 NS 記錄。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 轉送。在這種情況下，網域的所有 DNS 記錄都會自動複製到 Google Cloud 和您的地端環境，並可在這兩個環境中進行查詢。
使用 DNS 傳出轉送，從 Google Cloud解析內部部署 DNS 名稱
在 Google Cloud 上執行的用戶端可能需要解析部署在內部部署環境中的資源名稱。如果您擴充樹系或在 上部署 Google Cloud資源樹系，請在 Cloud DNS 中建立私人轉送區域，將地端部署網域的 DNS 查詢轉送至地端部署 DNS 伺服器。
使用輸出 DNS 轉送時，請確保防火牆設定正確無誤。
如果您將現有網域延伸至 Active Directory，則不需要 DNS 外向轉送。在這種情況下，網域的所有 DNS 記錄都會自動複製到 Google Cloud 和您的地端環境，並在這兩個環境中提供查詢。
使用 VPN 通道保護 LDAP 流量
Active Directory 大量使用 LDAP 通訊協定。與 Active Directory 使用的大多數其他通訊協定不同，LDAP 預設不會加密。
Google Cloud 可確保虛擬機器之間的流量經過加密，因此在虛擬私有雲中使用未加密的 LDAP 是可接受的做法。如果將 VPC 連線至內部部署網路，請確保 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 精細控管使用者能夠存取的資源。如果機器是以 Compute Engine 中的 VM 執行個體形式部署，且使用者有權存取基礎專案，您就必須考慮其他可能允許使用者存取機器的路徑： Google Cloud
在 Google Cloud 專案中獲派「Compute 執行個體管理員」角色的專案成員，可以使用密碼重設功能建立本機管理員帳戶。本機管理員帳戶可能會破壞群組政策，或安裝惡意軟體來擷取其他登入使用者的網域憑證，因此會對 Active Directory 網域的安全性造成威脅。
加入開機指令碼後，具備專案權限的成員就能將惡意程式碼插入 VM，並在下次重新啟動機器時以
nt authority\system執行。透過序列埠，具備權限的專案成員也可以存取 Windows Special Administration Console (SAC)。Windows 會將透過 SAC 登入視為本機登入。因此，SAC 可能會遭到濫用，藉此規避拒絕透過 RDP 登入的政策，但卻錯過拒絕本機登入的政策。
具有特殊權限的專案成員可以使用 SAC 發出
crashdump指令，這會導致記憶體傾印寫入磁碟。這類記憶體傾印可能包含私密資訊和憑證。如果將永久磁碟掛接到其他 VM，或使用快照，有權限的專案成員或許就能存取磁碟內容，包括使用者無權登入的電腦記憶體傾印。
使用代管的 Microsoft AD 時，系統預設會提供更完善的保護，防範這些額外的存取路徑。這項服務不允許專案中的具備權限使用者重設網域管理員密碼、執行啟動指令碼，或存取 AD 網域控制站 VM 的序列主控台。
為進一步降低這些風險，請確保以最低權限原則管理含有已加入網域的 VM 執行個體專案的 IAM 權限。您可以透過機構政策、群組政策和受防護的 VM，進一步降低風險：
使用機構政策停用序列埠存取權。
套用群組政策，停用帳戶管理員，防止建立本機管理員帳戶。在群組原則中定義「INI 檔案」偏好設定 (依序前往「電腦設定」>「喜好設定」>「Windows 設定」>「Ini 檔案」)，套用下列設定：
- 動作：更新
- 檔案路徑：
C:\Program Files\Google\Compute Engine\instance_configs.cfg - 專區名稱：
accountManager - 資源名稱：
disable - 屬性值：
true
套用群組原則，從 VM 執行個體中移除所有本機管理員帳戶。使用「本機使用者和群組」功能 (「電腦設定」>「偏好設定」>「控制台設定」>「本機使用者和群組」)，從「Administrators」群組和其他敏感群組中移除群組成員資格。
建議搭配使用受防護的 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 的永久磁碟，進而造成安全風險。為降低未經授權存取的風險，請為管理 VM 使用獨立的Google Cloud 專案，並運用最低權限原則授予這個專案的存取權。
如果您打算使用混合式連線，從內部部署網路存取管理 VM，請將管理 VM 部署到專屬的 VPC 子網路。專供管理 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 的受攻擊面，請使用防火牆禁止任何非必要網路通訊。如要瞭解從 VPC 或內部部署網路存取 Active Directory 時，需要哪些防火牆設定，請參閱這份指南。
將 Active Directory 資源和使用者劃分為管理層級
在 Active Directory 樹系中，部分機器的重要性高於其他機器，對 Active Directory 的整體安全性影響較大。網域控制器和管理 VM 是兩個特別重要的機器範例，因此特別容易受到潛在攻擊。
如要判斷每部機器的重要性，請使用層級分類。合適的層級數量取決於具體設定，但您可以先區分三個層級：
第 0 層 (極度重要)：這個層級包含對 Active Directory 樹系安全至關重要的所有機器。一旦單一第 0 層機器遭到入侵，您就必須假設整個樹系都遭到入侵。
第 1 級 (重大)：這個層級包含您環境中的大多數伺服器，包括應用程式伺服器和資料庫伺服器。第 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 結構：
如果您使用分層管理模式，頂層機構單位必須反映您的管理層級。
為每個層級建立使用者和群組的機構單位。如果您打算管理大量使用者和群組，請視需要建立子機構單位。
為每個層級建立
Projects機構單位，並為每個包含 Active Directory 資源的Google Cloud 專案建立子機構單位。使用專案專屬的子 OU 管理電腦帳戶、服務帳戶或其他 Active Directory 資源，這些資源對應於各專案的資源。 Google Cloud請確認 OU 和專案之間存在 1:1 的對應關係。
下圖顯示遵循這些原則的階層範例：
如果含有 Active Directory 資源的專案數量適中，您可以在 Projects 機構單位下建立扁平的機構單位結構。如果您預計要管理大量專案，且已設計Google Cloud 資源階層，使用多層資料夾，請考慮在 Projects OU 下方反映這個資料夾結構。
將 Active Directory OU 結構與 Google Cloud 資源 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，降低目錄中留下過時資源的風險。
如果您認為機構單位結構需要與專案結構有所不同，這可能表示專案結構過於精細或過於粗略。
使用 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)，藉此還原預設的 Active Directory 行為，與 PDC 模擬器同步處理時間。
整合及監控稽核記錄
在 Google Cloud上部署 Active Directory 時，Active Directory 樹系和 Google Cloud 專案的安全性會相互影響：Active Directory 和 Windows 中的可疑活動可能會危及其他資源的安全性，就像 Google Cloud 中的可疑活動可能會危及 Active Directory 安全一樣。
一致的稽核記錄是重要的工具，可協助您及早找出威脅或錯誤設定，並重建及檢查過去的活動。Cloud 稽核記錄可讓您擷取及分析管理員活動記錄和資料存取記錄。同樣地，您可以使用防火牆規則記錄和 VPC 流程記錄來分析網路流量。不過，這些平台服務不會知道 Active Directory 中發生的任何安全性相關事件。如要建立涵蓋平台相關稽核事件和 Active Directory 相關稽核事件的一致稽核記錄，請在網域控制站和加入網域的電腦上安裝 Cloud Logging 代理程式，將 Windows 安全性事件記錄匯出至 Cloud Logging。
根據預設，Windows 安全性事件記錄檔可能不會擷取稽核所需的所有事件。請參閱 Microsoft 關於設定稽核政策和監控 Active Directory 是否有遭入侵跡象的建議，確保擷取所有相關稽核事件。
處理大量事件時，很容易錯過重要事件。 為避免錯過重要事件，請針對特別重要或可疑的事件建立記錄指標，並考慮設定快訊，在事件發生率變更或超過可接受的閾值時收到通知。
後續步驟
找出最適合您情況的在混合環境中使用 Active Directory 的模式。
歡迎自行試用其他 Google Cloud 功能，請參閱我們的教學課程。