本文档介绍将 Active Directory 部署到 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 上的首选网络模型。
如果信任边界中的单个系统遭到侵入，您可以假设该边界中的所有系统都遭到了侵入。这种假设表明信任边界越小越好。信任边界越小，遭到入侵的系统越少，攻击者需要清除的边界越多。
零信任模型的逻辑为：网络中的每台机器都被视为独特的安全区域和信任边界。机器之间的所有通信都必须经过相同的审查和防火墙处理，并且所有网络请求都被视为来自不受信任的来源。
在网络级层，您可以使用防火墙规则来限制流量以及使用 VPC 流日志和防火墙规则日志记录来分析流量，从而实现零信任模型。在应用级层，您必须确保所有应用始终安全地处理身份验证、授权和审核。
Active Directory 中的信任边界
在 Active Directory 域中，机器信任域控制器以代表它们处理身份验证和授权。一旦用户向其中一个网域控制器证明了其身份，用户就可以默认登录到同一网域的所有机器。网域控制器授予用户的任何访问权限（以权限和组成员的形式）适用于网域的多个机器。
通过使用组政策，您可以阻止用户访问某些机器或限制其在某些机器上的权限。但是，一旦机器遭到入侵，攻击者就有可能对登录相同机器的其他域用户窃取密码、密码哈希值或 Kerberos 令牌。然后，攻击者可以利用这些凭据将攻击扩散到林中的其他网域。
鉴于这些因素，我们最好假设林中的所有机器都处于信任安全边界。
与控制为组织的不同部分复制并赋予管理自主权的网域边界相比，林边界可提供更强的隔离。林可以作为信任边界。
将 Active Directory 林与安全区域对齐
将林假设为信任边界会影响安全区域的设计。如果一个林覆盖两个安全区域，攻击者就可以更轻松地清除这些安全区域之间的边界。结果，两个安全区域有效地成为一个并形成单个信任边界。
在零信任模型中，网络中的每台机器都可以被视为一个单独的安全区域。在此类网络中部署 Active Directory 会破坏此概念并拓宽有效的安全边界，使其包括 Active Directory 林的所有机器。
如需将安全区域作为信任边界，您必须确保整个 Active Directory 林都位于安全区域中。
对将 Active Directory 扩展到 Google Cloud 产生的影响
在规划需要 Active Directory 的 Google Cloud 部署时，您必须在两者之间做出调整，以使部署与您现有的安全区域保持一致：
将现有安全区域扩展到 Google Cloud。您可以在 Google Cloud 上预配共享 VPC 并使用 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 上分隔这些工作负载，您可以创建两个共享 VPC 并将其视为新的安全区域。然后向 Google Cloud 部署另外两个 Active Directory 林，每个安全区域部署一个。如有必要，您可以在林之间建立信任关系，以启用跨安全区域的身份验证。
本地和 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 上的 Web 应用进行身份验证。
在适度交互的情况下，操作两个不相交的 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 等工具在环境之间同步用户账号。
如果您的要求符合以下一项或多项描述，请考虑使用同步林模式：
- GCP 的预期用途符合冗余部署模式之一，并且您希望避免本地环境与 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 在本地和 Google Cloud 上管理的资源之间发生适度交互。
- 您有大量用户需要访问部署在 Google Cloud 上的资源，例如使用 IWA 进行身份验证的 Web 应用。
优势：
- 资源林模式使您可以在两个 Active Directory 环境之间维护信任边界。根据信任关系的配置方式，入侵一个环境的攻击者可能对其他环境的访问权限极低，或无法访问。
- 代管式 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 站点，可以确保客户端与最接近它们的域控制器进行通信。
如果您的要求符合以下一项或多项描述，请考虑使用扩展网域模式：
- GCP 的预期用途符合冗余部署模式之一，并且您希望避免本地环境与 Google Cloud 之间的运行时依赖项。
- 您希望 Active Directory 在本地和 Google Cloud 上管理的资源之间发生重度交互。
- 您希望加快依赖 LDAP 进行身份验证的应用的身份验证速度。
优势：
- Google Cloud 托管的 Active Directory 不受本地 Active Directory 中断的影响。该模式非常适合要求业务连续性的用例或需要高可用性的其他场景。
- 您可以限制本地网络与 Google Cloud 之间的通信。这样可以节省带宽并缩短延迟时间。
- 全局目录的所有内容都会复制到 Active Directory，并且可以通过 Google Cloud 托管的资源高效访问。
最佳做法：
- 如果您复制所有网域，则本地网络和 Google Cloud 网络之间的通信受限于网域控制器之间的 Active Directory 复制。如果仅复制林的网域的一部分，则在 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 在本地和 Google Cloud 上管理的资源之间发生适度或重度交互。
- 您有许多用户需要访问部署在 Google Cloud 上的资源，例如使用 IWA 进行身份验证的 Web 应用。
优势：
- 全局目录的所有内容都将复制到 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 进行身份验证的 Web 应用。
优势：
- Google Cloud 托管资源不受本地 Active Directory 中断的影响。该模式非常适合要求业务连续性的用例或需要高可用性的其他场景。
- 该模式使您可以在两个 Active Directory 林之间维护信任边界。根据信任关系的配置方式，入侵一个环境的攻击者可能对其他环境的访问权限极低，或无法访问。
- 您的本地网络与 Google Cloud 网络之间的通信受限于网域控制器之间的 Active Directory 复制。您可以实施防火墙规则来禁止所有其他通信，加强环境之间的隔离。
- 您可以为管理 Google Cloud 托管的 Active Directory 林的团队授予高级别的管理自主权。
- 您可以将托管式 Microsoft AD 用于资源林。
最佳做法：
- 将扩展域的域控制器部署到单独的 Google Cloud 项目和 VPC 中，以便将这些组件与资源林的组件隔离。
- 使用 VPC 对等互连将 VPC 连接到共享 VPC 或资源林使用的 VPC，并配置防火墙来限制与 Kerberos 用户身份验证和林信任创建的通信。
- 使用单向信任连接两个 Active Directory 林，以便 Google Cloud 托管的 Active Directory 可以信任您现有的 Active Directory 林，但反之则不会。
- 使用选择性身份验证来限制资源林中允许其他林用户访问的资源。
- 请注意，跨站点的复制仅在特定间隔执行，因此仅在延迟之后发生在本地网域控制器上的更新才会在 Google Cloud 上执行（反之亦然）。
- 考虑将 RODC 用于扩展网域，但与资源林模式相比，请务必允许缓存密码以保持可用性优势。
后续步骤
- 详细了解代管式 Microsoft AD。
- 查看在 Google Cloud 上部署 Active Directory 资源林的最佳做法。
- 了解如何将容错 Active Directory 环境部署到 Google Cloud。
- 查看我们的 VPC 设计最佳做法。
- 如需查看更多参考架构、图表和最佳做法，请浏览云架构中心。