使用 IPsec 与组策略隔离服务器和域－第 4 章：设计和规划隔离组

本章提供了定义隔离组的完整指南，这些隔离组可满足第 2 章“了解服务器和域隔离”中所讨论的安全要求。该解决方案使用 Active Directory® 目录服务域中的计算机身份组合、IPsec 策略来验证此身份，使用 Microsoft® Windows® 的安全策略来定义和实施隔离组。 信息技术 (IT) 管理员可使用隔离组的概念，在内部网络中以一种对于应用程序是透明的安全方式来管理网络通信量。 该功能可显著降低以网络为载体的感染和攻击所带来的损害的威胁。

通过 Woodgrove Bank 的方案，该指南显示了组织如何将其安全要求转化为已部署隔离组的主要细节。 此外，该指南还显示了 IPsec 如何与其他安全设置组合，以构建详细的、可管理的、可伸缩的服务器和域隔离解决方案。

每项业务对解决方案都有独特的要求，该指南中的模型不能毫无疑问或原封不动地照搬。 使用该指南的组织需要确定自身环境需要什么、可实现什么，对隔离组模型设计进行适当更改，以确保对自己的业务要求最适合。

本页内容

	本章先决条件
	创建服务器和域隔离设计
	组实施方法
	Woodgrove Bank 的组实施
	总结

本章先决条件

此部分包含的信息，可帮助确定组织的服务器和域隔离解决方案的方法。 组织中成功实现这样一个解决方案，取决于此部分所确定的先决条件。

预备知识

应当熟悉 IPsec 的概念和术语。 还需要熟悉 Microsoft Windows Server™ 2003 的以下方面：

•	IPsec 策略、IPsec 筛选器、筛选器操作和筛选器列表。
•	Active Directory 概念（包括 Active Directory 结构和工具；操纵用户、组和其他 Active Directory 对象；名称解析服务；以及组策略的使用）。
•	身份验证的概念，包括 Windows 登录过程和 Kerberos V5 协议。
•	Windows 系统安全（包括安全的概念，如用户、组和审核、访问控制表 [ACL]；使用安全模板；使用组策略或命令行工具应用安全模板）。

在继续本章之前，也应当读过本指南的前几章。

组织先决条件

应咨询组织中的其他成员的意见，他们可能需要参与实施本解决方案，包括以下人员：

•	行政负责人
•	安全和审核人员
•	Active Directory 工程、管理和操作人员
•	域名系统 (DNS)、Web 服务器、网络工程管理和操作人员 注：根据 IT 组织的结构，这些角色可由许多人员担任，也可由较少的人员可同时担任几个角色。 但是，在项目的各个阶段，确定单点联系以帮助协调跨组织小组的工作很重要。

本章还假定读者已满足第 2 章“了解服务器和域隔离”和第 3 章“确定 IT 基础结构的当前状态”的要求。这些要求包括从主机、网络和 Active Directory 收集信息。 还讨论了收集业务要求和获取业务身份。

最后，必须准备好计划，就该解决方案的新概念、术语和技术，对各种服务台和支持人员进行培训。 由于该解决方案会影响组织的许多领域，应当培训支持人员处理部署过程中出现的任何问题。

IT 基础结构的先决条件

本章假定存在以下 IT 基础结构：

•

以混合或纯模式运行的 Windows Server 2003 Active Directory 域。 对于组策略对象应用，该项解决方案使用通用组。 如果组织不是以混合或纯模式运行，仍然可以通过使用标准全局和本地组配置来应用组策略对象 (GPO)。 但是，由于这种方法管理起来很复杂，本解决方案未予采用。 注：Windows Server 2003 引入了许多影响 IPsec 策略的改进。 本解决方案没有任何特别之处会妨碍它与 Windows 2000 一起工作。 但是，只使用 Windows Server 2003 Active Directory 对本解决方案进行了测试。 有关 Windows Server 2003 中对 IPsec 所做的增强的详细信息，请参阅 Microsoft 网站上的“New features for IPsec”页面，网址为 www.microsoft.com/resources/documentation/ WindowsServ/2003/standard/proddocs/en-us/ipsec_whatsnew.asp。

返回页首

创建服务器和域隔离设计

解决方案的设计在很大程度上取决于前几章所收集的业务需求和信息。 第 2 章，“了解服务器和域隔离”与附录 D：“IT 威胁类别”解释了解决方案的组件，并确定能够和不能解决的威胁。 第 3 章，“确定 IT 基础结构的当前状态”提供了如何收集规划数据（如网络中的当前网络体系结构和主机资产）的信息。 本章使用为 Woodgrove Bank 收集的信息和需求，详细记录在 Business_Requirements.xls 中（在“工具和模板”文件夹中）。 在设计过程中，应当参考本章中对该文件的详细描述，以更好地理解解决方案设计背后的原因。 解决方案设计过程包括以下主要任务：

•	基础组建模
•	规划计算机和网络访问组 (NAG)
•	创建附加隔离组
•	网络通信需求建模
•	分配计算机组和 NAG 成员身份

下节对每个任务进行了解释。

基础组建模

对于大多数实施，建议为初始隔离组设定通用的起始点。 下面的图显示了应当加以考虑的两个初始隔离组。

图 4.1 基础隔离组

基础隔离组提供了逻辑容器，对于隔离组设计是出色的起始点。

不受信任的系统

从概念上来说，最佳的开始位置是那些未被组织的 IT 部门拥有、托管，或甚至未知其存在的计算机。 这些计算机通常指不受信任或非托管的主机，是设计中要确定的首要系统。 由于这些计算机不能使用域指派的 IPsec 策略，因此不会成为解决方案的一部分。

属于该组的计算机包括：

•	非基于 Windows 的计算机和设备。 Macintosh 和 UNIX 工作站和个人数字助理 (PDA) 可能不具备 IPsec 功能。
•	较早版本的 Windows 操作系统。 运行 Microsoft Windows NT® 4.0 和 Windows 9x 的计算机不能使用基于组策略的 IPsec。
•	未加入受信任域的基于 Windows 的计算机。 独立计算机不能在 Internet 密钥交换 (IKE) 中使用 Kerberos 域信任进行验证。 计算机被加入不受林信任的域，而此林被用作 IKE 验证的信任边界，则该计算机不能参与域或服务器隔离解决方案。
•	其他非 Microsoft 远程访问或 VPN 客户端。 如果非 Microsoft IPsec 虚拟专用网络 (VPN) 客户端正用于组织的远程访问解决方案，则安装可能已禁用本机 Windows IPsec 服务。 如果不能使用本机 Windows IPsec 服务，则主机不能参与该解决方案。 即使本机 Windows IPsec 服务正在运行，VPN 客户端也应当允许通过 VPN 隧道连接进行 IKE 和 IPsec 端对端通讯。 如果端对端 IPsec 无法通过 VPN 连接工作，则可为所有用于远程访问的 IP 子网创建免除。 当该远程客户端重新连接到内部网络时，能够再次参与隔离解决方案。

隔离域

隔离域为受信任主机提供第一个逻辑容器。 该组中的主机使用 IPsec 策略来控制允许进出自身的通讯。 此处术语“域”用来说明信任边界，而不是表示 Windows 域。 在该解决方案中，两个构造非常相似，因为从受信任主机接收入站连接要求 Windows 域验证 (Kerberos)。 但是，Windows 域（或林）可与信任关系链接，以提供单个逻辑隔离域。 因此不能将它们视为完全一样。

隔离域的通讯特性的目标，是为组织的大多数计算机提供“正常”或标准规则。 通过这种方式，对于大多数实施，隔离域会包含最大数量的计算机。 如果其他隔离组的通讯要求与隔离域不同，则可为解决方案创建这些隔离组。 从概念上来说，隔离域只是隔离组的一种类型。

边界组

几乎在所有的组织中，都会有许多不能使用 IPsec 通信的工作站或服务器。 例如，Mac 或 UNIX 工作站之类的计算机，不可能使用 IPsec 通信。 常常是那些与隔离域中受信任主机通信的计算机有业务需求。 在理想的情况下，可能内部网络中的所有主机都能够处于相同的信任级别并使用 IPsec，而且设计会更简单。 但是，实际情况是并非所有的操作系统都为 IPsec 提供了相同程度的支持。

处理这一状况，建议创建隔离组（本指南中称为边界组），该组包含会被允许与不受信任的系统进行通信的主机。 由于这些主机能够直接从不受信任的计算机接收入站通信，因此风险级别较高。

边界组中的计算机为受信任的主机，能够与其他受信任的主机和不受信任的主机进行通信。 边界主机会通过向源计算机启动 IKE 协商，尝试使用 IPsec 通信。 如果在三秒中之内没有收到 IKE 响应，主机会回退到使用明文通信方式，并开始尝试不使用 IPsec 以明文建立通信。 由于边界组中的主机象任何其他隔离域中的受信任主机一样使用 IPsec 策略，因此可以有动态 IP 地址。 由于这些边界组中的主机会被允许与受信任的主机（使用受 IPsec 保护的网络通信）、以及不受信任的主机（使用回退到使用明文的通信方式）进行通信，必须以其他方式高度保证它们的安全。 在决定是否在边界组中配备计算机的过程中，了解和减轻这一额外风险应当是个重要部分。 例如，在同意每台计算机配备于该组之前，设置正式的业务调整过程，有助于确保所有有关各方都了解为什么需要这一额外风险。 以下图示过程，可帮助进行决策。

图 4.2 边界组成员身份过程示例的决策流程图
查看大图

该过程的目标是确定向边界组添加一台主机的风险是否能够减轻到组织可以接受的级别。 如果最终不能减轻风险，则应当拒绝成员身份。

创建免除列表

服务器和域隔离安全模型在实际环境中实施时，都面临一些限制。 通常，主基础结构服务器如域控制器、DNS 服务器，以及动态主机配置协议 (DHCP) 服务器可供内部网络中的所有系统使用。 显然，必须以最大可能的程度保护这些服务器免受攻击。 但是，由于这些服务器可供网络上的所有系统使用，不只归域成员使用，这些服务器的服务不能为入站访问要求 IPsec，也不能为它们所有的通信流利用 IPsec 传输模式保护。 由于三秒钟回退到使用明文对这些服务进行访问，尤其是 DNS，会严重影响所有内部网络访问的性能，因此不作为边界组的选择。 同样，在计算机启动过程中，或网线/网卡插入移动计算机时，受信任主机要求访问 DHCP 服务器以获得 IP（Internet 协议） 地址。 受信任主机也要求 DNS 查找域控制器，以便能够登录到域，并接收 Kerberos 凭据。 因此，会要求不使用 IPsec 的服务器和服务（协议）列表，以便 IPsec 正常工作，并允许所有内部主机共享通用的内部网络基础结构。 无法使用 IPsec 进行安全保护的计算机列表称为“免除列表”，在每个设计的 IPsec 策略中实施。 网络上也可能有其他受信任主机不能使用 IPsec 进行访问的服务器，这些服务器会被添加到免除列表。 通常，以下条件可能会导致主机出现在免除列表中：

•	如果该主机是一台受信任主机要求访问的计算机，但没有兼容的 IPsec 实现。
•	如果该主机为受信任和不受信任主机提供服务，但未满足边界隔离组成员身份的标准。
•	如果该主机用于应用程序，而此应用程序受到三秒钟回退到使用明文延迟或应用程序通信流的 IPsec 封装的不利影响。
•	如果该主机同时支持数千客户端，且由于性能的影响 IPsec 不能使用。
•	如果该主机支持来自不同隔离域的受信任主机，而这些域彼此互不信任。
•	如果该主机为域控制器，因为目前不支持域控制器和域成员之间的 IPsec。 但是，域控制器满足此列表中的其他标准，并且也向域成员和隔离概念所基于的 Kerberos 验证提供 IPsec 策略。
•	如果该主机支持受信任和不受信任主机，但从不使用 IPsec 来保护到受信任主机的通信。

Windows 中的 IPsec 实施只支持静态筛选，不支持动态（或状态）筛选。 因此，出站通信流的静态免除也是入站通信流的静态免除。 因此，被免除的主机可不需要身份验证对每台主机进行入站访问，无论受信任或不受信任的主机。 因此，被免除的主机必须保持最小数量，必须对这些主机加以密切管理，并尽可能加强对于攻击和感染的防护。 要帮助减轻免除列表中主机的入站攻击风险，可使用基于主机的状态筛选防火墙，如 Windows 防火墙。 Windows XP Service Pack (SP) 2 提供了基于域的组策略控制，用于配置防火墙。 被 IPsec 保护时，使用策略设置“Windows 防火墙：允许通过验证的 IPSec 旁路”，Windows 防火墙 可支持只授权特定计算机通过防火墙的功能。Woodgrove Bank 选择不实现 Windows 防火墙功能。 但是，在其他环境中，这一功能在隔离的域或组中实现高级别的安全可能很有必要。 有关详细信息，请参阅 Microsoft 下载中心的白皮书“Deploying Windows Firewall Settings for Microsoft Windows XP with Service Pack 2”，网址为 http://go.microsoft.com/fwlink/?LinkId=23277。

对于大型组织，如果由一个 IPsec 策略为整个域或所有受信任的林实施所有的免除，免除列表可能会变得相当大。 对于每台接收策略的计算机，大型列表有许多不利影响，包括以下方面：

•	降低了隔离的总体效果
•	造成了更大的管理负担（由于频繁的更新）
•	增加了策略的规模，意味着会消耗更多内存和 CPU 资源，降低了网络吞吐量，增加了下载和应用策略所需时间

要保持免除数量尽可能小，有以下选项：

•	如果通信可以承受三秒钟回退到使用明文延迟，则不使用免除。 该选项不适用于域控制器。
•	仔细考虑每个隔离组的通信需求，特别是只包含服务器的组。 可能不会要求它们和客户端域级别策略中的每个免除进行通信。
•	合并服务器功能。 如果几个免除服务能够在一个 IP 地址托管，则可以减少筛选器的数量。
•	合并相同子网中被免除的主机。 网络通信量会允许这么做，服务器可位于被免除的子网上，而不是每个 IP 地址都使用免除。

对于定义边界组，应当有个正式过程，批准主机添加到免除列表中。 将前一幅图中的决策流程作为处理免除请求的模型。

规划计算机和网络访问组

隔离域和每个隔离组必须有清晰、完整的网络安全要求规格。 “工具和模板”文件夹中的电子表格 Business_Requirements.xls，提供了如何将需要编成文档的模型。 入站和出站需求被编成文档之后，可设计实现访问控制的机制。

此时，应当启动新的 Active Directory 组记录，用于支持隔离组需求。 对于每个隔离组，最多需要创建三个专用的 Active Directory 组。 下节解释每个组的角色。

计算机组

每个隔离组会要求创建一个计算机组，用来包含隔离组的成员。 这样做是因为隔离组的安全要求是通过 GPO 中的几种类型的安全设置来实现，这些 GPO 在域中指派。 例如，该解决方案对 GPO 使用安全组筛选，以向特定隔离组中的计算机提供 IPsec 策略。 在处理 GPO 时，会为属于该计算机组成员的计算机帐户指派相关的 IPsec 策略。 这是为了避免不得不 更改或创建基于隔离组成员身份的新组织单位 (OU) 结构，以应用正确的 GPO。 如果可更改 OU 结构以反映隔离组成员身份，则不需要这些计算机安全组来控制组策略的应用。

表 4.1：Woodgrove Bank 计算机组

计算机组名称	描述
CG_IsolationDomain_Computers	通用组包含的所有计算机，是隔离域的一部分。
CG_BoundaryIG_Computers	该组包含所有被允许从不受信任的系统接收通信的计算机。

网络访问组

单独使用 IPsec 和 Kerberos 提供受信任和不受信任的验证边界。 为帮助将该组与任何其他组区分开来，本指南称这些组为“网络访问组 (NAG)”。

可创建两种类型的 NAG：允许和拒绝。 正是这些组控制了其他受信任系统明确允许或拒绝访问的能力。 通过使用组策略中的用户权限“拒绝从网络访问这台计算机”（“拒绝”）或“从网络访问此计算机”（“允许”）实现此控制。

从技术上来说，此用户权限访问控制只适用于接收登录凭据来验证网络登录帐户的网络服务。 “帐户”可以是一台计算机、用户或服务帐户。 当 IPsec 策略配置为保护所有通信流时，IKE 会确认远程计算机具有网络登录权限。 因此，此时网络登录权限控制了远程计算机建立任何受 IPsec 保护的连接的能力。 在选中 IP 级别的访问控制之后，常规的上层协议（例如，文件共享）通常会对用户进行验证，再次对用户身份的网络登录权限进行评估。 最后，使用用户身份对特定于服务的权限（如文件共享访问控制表）进行评估。 有关详细信息，请参阅第 2 章“了解服务器和域隔离”中的网络控制层图。

默认情况下，“允许”用户权限包含了 Everyone 组，允许所有经过身份验证的用户和计算机访问该计算机。 在实施此解决方案的过程中，会通过组策略用户权限分配将 Everyone 组替换为包含特定计算机、或用户和组的 NAG，具体取决于组织需求。 同样，“拒绝”用户权限所包括的计算机，不具有受 IPsec 保护的入站访问。 尽管可以使用一个组来包含用户和计算机帐户，Microsoft 建议使用单独的组，用户和计算机各一个。 此方法可不断提高管理和支持这些策略和组的能力。 用户权限分配配置为“允许”和“拒绝”，对早期的 Windows 平台安全指南作了补充，因为那些指南没有特别提供 IPsec 所需要的计算机身份验证。

NAG 可实现的需求包括以下方面：

•	阻止从位于公共区域的边界主机或受信任主机对敏感服务器进行网络访问。
•	限制高级执行人员专用的服务器只接受那些成员所使用的客户端计算机的访问。
•	将研究和开发项目中的受信任主机与域中所有其他的受信任主机隔离开来。

在 Woodgrove Bank 方案中，一项业务需求对当年度要购买的新计算机硬件的数量进行了限制。 需要一台打印服务器，允许受信任主机和不受信任主机都可用于打印。 尽管 Woodgrove 应当购买一台新的服务器，只供不受信任主机用于打印，但 Woodgrove 确定一台服务器就可以满足两种类型的主机的需要。 因此，创建了一台边界服务器作为打印服务器。 由于打印服务器遭受来自不受信任的计算机感染和攻击的风险更高，因此，其余受信任的计算机需要阻止来自打印服务器的入站访问。 需要时，受信任主机仍然能够建立到打印服务器的出站连接。 因此，Woodgrove 确定需要“拒绝 NAG”来实现这一需求。

在设计过程的这个阶段，不要求分配 NAG 成员身份。 所需要的是确定和记录设计所要求的 NAG。 Woodgrove Bank 的设计人员确定了以下 NAG 的要求：

表 4.2：Woodgrove Bank 网络访问组

NAG 名称	描述
DNAG_IsolationDomain_Computers	该组包括如下域计算机帐户：这些帐户被拒绝建立到隔离域中所有受信任主机的受 IPsec 保护的入站连接。

创建附加隔离组

在设计过程的这个阶段，有两个隔离组：隔离域和边界组。

如果该设计能够满足组织的业务需求，可继续本章的下一节，为这两个隔离组定义通信流模型。 但是，如果组织要求某些受信任主机具有不同的入站或出站的网络访问控制或通信流保护，则每组不同的需求都要有隔离组。

本节的目的是帮助了解何时会要求附加组。 首先要做的是确定哪台计算机具有特别的隔离或通信流保护需求，隔离域的设置不能满足这些需求。 目标应当是将主机的数量保持最低，因为每个新组都会增加总体设计的复杂性，从而使支持和管理的难度更大。

可能导致创建新组需求的典型示例如下：

•	加密需求
•	要求网络层的受限主机或用户的访问
•	与隔离域不同的传出或传入网络通信流或保护需求

很多情况下，包含高价值数据的服务器入站访问需求只允许域中受信任主机的子网进行连接。 其他情况下，可能不允许受信任主机建立到不受信任主机的出站连接，以降低信息泄露的风险或强制遵循网络通信保护法规。 例如，在 Woodgrove Bank 的方案中，设计人员确定只能通过创建以下两个附加隔离组来满足需求：

•	加密组包含了一小组带高价值数据的应用程序服务器，这些服务器要求最高级别的保护。 只允许受信任客户端特定的子网建立到这些服务器的入站连接。 与这些服务器的所有网络通信都要求 128 位级别的加密，符合美国 金融数据隐私的联邦法规。 最后，不允许这些服务器建立到不受信任主机的出站连接，或从边界主机接收入站连接。
•	许多隔离域中受信任的主机要求无回退组，需要限制这些域到不受信任系统的网络通信。

尽管第二组有无回退的需求，但没有应用程序服务器所具有的整套需求。 因此，这两组不同的需求表示需要两个附加隔离组。 这两个附加组使 Woodgrove Bank 的总组数为四。 下图显示了最终 Woodgrove Bank 隔离组设计中这些组的情况：

图 4.3 最终 Woodgrove Bank 组设计

以下四个组要求策略实现设计需求的策略：

•	隔离域。 是所有受信任计算机的默认组。
•	边界隔离组。 该组分配给要求不受信任的主机对其进行访问的计算机。
•	加密隔离组。 该组只允许通过受信任、加密的通信路径的通信。
•	无回退隔离组。 该组包含的计算机具有更高的安全要求，此要求表示不允许直接启动到不受信任主机的通信。

由于 Woodgrove Bank 确定了要求 IPsec 策略的两个附加组，因此定义了附加计算机组来控制这些新制定策略的应用。

表 4.3：其他 Woodgrove Bank 计算机组

计算机组名称	描述
CG_NoFallbackIG_Computers	该组包含了所有不允许回退到使用明文的计算机。
CG_EncryptionIG_Computers	该组包含了所有要求使用加密的计算机。

因此，Woodgrove 确定由 NAG 为受信任主机的子网对入站访问进行授权。 Woodgrove Bank 的设计人员创建了以下 NAG：

表 4.4：Woodgrove Bank 网络访问组

NAG 名称	描述
ANAG_EncryptedResourceAccess_Users	该组包括所有被授权可对加密隔离组服务器进行访问的用户。
ANAG_EncryptedResourceAccess_Computers	该组包括所有被授权可对加密隔离组服务器进行入站网络访问的计算机。
DNAG_EncryptionIG_Computers	该组包括将要被拒绝对加密隔离组中的主机进行访问的计算机帐户组。

收集网络通信需求

在设计过程的这个阶段，应当将允许在组之间通过的通信流需求与通信方式一起记录。 记录组的通信流需求有许多方式。 但是，Microsoft IT 支持小组根据他们的经验发现，绘制图形是交流准确需求的最佳方法。

下图描绘了通常允许用于基础组、不受信任的主机，以及免除列表之间的通信路径。 要简化此模型，免除列表以单个组显示。 基础结构服务（如域控制器或 DNS 服务器）通常就是这种情况。 但是，隔离组可能有免除特定计算机的业务需求，只用于该组中的计算机。 在这些情况下，隔离组会包含附加计算机免除列表，这些计算机是除了通用免除之外另外要免除的。 Microsoft 建议保持免除列表条目最小，因为它们明确免除了系统参与 IPsec 基础结构。 图中，所有的实心黑线箭头使用 IPsec 通信，点线表示允许不使用 IPsec 的通信。 以粗虚线描绘的组具有指派给该组中计算机的 IPsec 策略。

图 4.4 允许用于基础隔离组的典型通信路径
查看大图

下表记录了允许用于基础组、不安全系统和免除列表之间通信流的通信路径：

表 4.5：允许用于基础隔离组的通信选项

路径	开始	到达	双向	尝试 IKE/IPsec	回退	加密
1	ID	EX	是	否	否	否
2	ID	BO	是	是	否	否
3	ID	UN	否	是	是	否
4	BO	EX	是	否	否	否
5	BO	UN	否	是	是	否
6	UN	BO	否	否	否	否
7	UN	EX	是	否	否	否

前一个表记录了初始隔离组设计中每条允许的通信路径的通信需求。 下表对每列进行了解释：

•	路径。 组图中显示了分配给通信路径的数量。
•	开始。 包含通信流启动方的组。
•	到达。 包含响应方的组，响应方会通过所允许的通信路径联系到。
•	双向。 表示路径是否允许启动方和响应方的角色转换，以便通信流既能以开始组为起点，也能以到达组为起点。
•	尝试 IKE/IPsec。 表示路径是否尝试使用 IPsec 来保护通信。
•	回退。 表示如果 IKE 协商未能完成，通信是否能恢复不使用 IPsec。
•	加密。 表示路径是否要求使用 IPsec 策略中设置的加密算法对通信进行加密。

组名的简易格式用于使表中的信息尽可能简洁。 通过使用这种格式的文档，可以非常简洁地表示解决方案的通信。 通过假定所有的网络通信流被禁止（除非在此表中特别指定），指定通信流的过程变得更清晰，此过程会作为解决方案的一部分加以保护。 在上图显示的示例中，解释了以下每一条允许的路径：

•	通信流路径 1、4 和 7 显示了免除列表在其 IPsec 策略中列出的所有主机被特别允许的网络通信。 隔离组的特定免除可能不同。
•	通信流路径 2 显示了隔离域和边界组之间的通信。 该路径尝试使用 IPsec 来保护通信流。 通信流可能需要加密，具体取决于安全要求。 如果 IKE 协商失败，通信也会失败，因为当 IKE 协商失败时，没有“回退到使用明文”选项。
•	路径 3 显示隔离域中的主机可以启动与不受信任主机的通信。 可做到这一点，是因为如果初始 IKE 协商请求没有收到回复，则该组的策略允许隔离域主机“回退到使用明文”。 试图启动与受信任主机的非 IPsec 连接的不受信任的系统，被 IPsec 入站筛选器阻止。
•	通信流路径 5 和 6 记录了边界组和不受信任的系统之间所允许的通信。 路径 4 显示了边界组被允许与不受信任的主机以明文通信。 如果 IKE 协商协商没有收到响应，主机会“回退到使用明文”通信方式。 路径 5 包括从不受信任的主机启动到达边界组的通信流。 尽管此箭头看上去与路径 4 相似，表中的细节显示不受信任的主机没有对边界组尝试 IKE 协商。 它们使用明文 TCP/IP 进行连接。

基础通信制成文档之后，附加组可添加到总体规划中，其通信需求以相同的方式记录。 例如，Woodgrove Bank 方案要求两个附加组，导致了更复杂的通信图，如下图所示。

图 4.5 Woodgrove Bank 允许的隔离组通信路径
查看大图

下表记录了 Woodgrove Bank 方案允许附加组中的通信流使用的通信路径。

表 4.6：允许用于附加隔离组的通信选项

路径	开始	到达	双向	尝试 IKE/IPsec	回退	加密
8	EN	EX	是	否	否	否
9	EN	ID	是	是	否	是
10	EN	NC	是	是	否	是
11	EN	BO	否	是	否	是
12	NF	ID	是	是	否	否
13	NF	EX	是	否	否	否
14	NF	BO	是	是	否	否

上图显示的示例和前一张表的描述，解释了以下每一条允许的附加路径：

•	路径 8 和 13 为明文通信，用于所有被免除的通信流。
•	路径 9 和 10 显示了“加密”、“无回退”和隔离域组之间要求的“IPsec 封装式安全措施负载 (ESP)”加密的通信。 如果 IKE 协商使用加密对通信进行保护失败，则通信尝试失败。
•	路径 11 的通信流略有不同，只允许从加密组启动通信到边界组，而不是相反的方向。 这是因为 Woodgrove Bank 将高价值数据放置在加密组中，避免数据暴露给直接被不受信任的资源访问的计算机。
•	12 和 14 的通信流路径可通过 IPsec AH 传输模式或 IPsec ESP 传输模式实现，这些模式已验证身份但没有加密 (ESP-Null)。

如此例所示，添加组会对解决方案的复杂性产生指数级的影响。 因此，建议保持最小的组数量，特别是在部署的早期阶段，此时所做的更改最多。

分配计算机组和网络访问组成员身份

在设计中对通信流需求进行细化和记录之后，下一个任务是确定主机是哪一个计算机组或 NAG 的成员。

如前所述，该解决方案中使用的计算机组应用包含相关 IPsec 策略的 GPO。 确定计算机必须属于某个特定隔离组之后，将该计算机的帐户添加到代表此隔离组的计算机组。 对于隔离域不要求此步骤，因为所有的域计算机都隐含地属于隔离域计算机组。

NAG 中的成员身份基于该 NAG 实施的入站身份验证。 例如，如果一个 NAG 要限制特定服务器到一组已知客户端的通信，则客户端计算机帐户需要放置在合适的 NAG 中。 NAG 只在需要时才创建，因此没有默认配置。

计算机组成员身份

一台主机不应该属于多个计算机组，这一点很重要，因为应用哪一个 GPO 由计算机组控制。 修改策略以使一台主机属于多个计算机组，尽管在理论上是可能的，但这种方法的复杂性会很快使解决方案无法承受。

通常，确定计算机组成员身份的任务并不复杂，但很费时间。 应当使用由审核生成的信息，如本指南的第 3 章“确定 IT 基础结构的当前状态”，根据主机的隔离组成员身份，将每台主机放置到计算机组中。 可通过添加“组”列，记录最终设计的计算机组的成员身份来确定放置操作，如下表所示：

表 4.7：主机收集数据示例

主机名称	满足了硬件要求吗？	满足了软件要求吗？	所需的配置	详细资料	预计成本	组
HOST-NYC-001	否	否	同时升级硬件和软件	当前操作系统为 Windows NT 4.0。 老硬件与 Windows XP 不兼容。	$XXX。	ID
SERVER-LON-001	是	否	加入受信任的域，从 NT 4 升级到 Windows 2000 或更高版本	没有防病毒软件。	$XXX。	EN

网络访问组成员身份

设计过程最后的步骤是填充本章此前确定的 NAG 的成员身份。 尽管受信任主机应当只属于一个计算机组，要成为多个 NAG 的成员也是可能的。 尽量使用尽可能少的 NAG，以限制解决方案的复杂性。

为用户帐户向 NAG 分配成员身份时，确定控制访问的密切程度。 对于已经在使用标准共享和文件权限来确保正确的控制级别的资源，分配成员身份最简单的方式，是向 Domain Users 分配用户的 NAG 成员身份，这些域用户来自林中每个要求访问资源的受信任域。 此方法几乎还原了 Authenticated Users 原始默认值的行为，但不包括本地用户帐户。 如果要求本地用户或服务帐户，则基于域的 GPO 可能是配置“允许”和“拒绝”网络登录权限的最佳方法。 “允许”和“拒绝”用户权限分配并不会将几个 GPO 中的设置进行合并。 因此，应当避免向该计算机基于域的 GPO 分配“允许”和“拒绝”，并应当使用自定义的本地 GPO。 如果基于域的 GPO（提供 IPsec 策略指派）与 用于提供网络登录权限的 GPO 不同，基于域的 GPO（用于提供 IPsec 策略指派）仍然可被使用。

此外，可使用“允许 NAG”或“拒绝 NAG”，或者两者都使用来确定如何实施入站访问需求。 确定要创建哪种 NAG 类型，完全基于什么是目标行为，以及什么能将管理操作降到最低。 所述因素可能有帮助：预先存在、但空的用户“拒绝 NAG”，以及计算机“拒绝 NAG”，其 GPO 中已经填充了权限“拒绝从网络访问这台计算机”。

对于高安全性方案，用户 NAG 的成员身份可分配给特定的用户或组。 如果使用此方法，则应当了解：不是该组成员的用户，会被阻止在网络上访问计算机，即使这些用户是本地管理员组的成员，并对所有的共享和文件权限拥有完全控制权限。

对于 Woodgrove Bank 方案，NAG_EncryptedResourceAccess_Users 成员身份被分配给 Domain Users，如下表所记录：

表 4.8：已分配成员身份 Woodgrove Bank 网络访问组

NAG 名称	成员身份	描述
ANAG_EncryptedResourceAccess_Users	User7	该组用于所有被授权可对加密隔离组计算机进行受 IPsec 保护的入站连接的用户。
ANAG_EncryptedResourceAccess_Computers	IPS-SQL-DFS-01 IPS-SQL-DFS-02 IPS-ST-XP-05	该组包括所有被授权可对加密隔离组的计算机进行受 IPsec 保护的入站连接的计算机。
DNAG_EncryptionIG_Computers	CG_BoundaryIG_Computers	该组包括所有未被授权对加密隔离组的计算机进行受 IPsec 保护的入站连接的计算机。

注：NAG 中的成员身份不控制 IPsec 通信流保护的级别。 IPsec 策略设置控制用于保护通信流的安全措施，并与 IKE 所验证的身份无关。 IKE 协商只了解 Kerberos 计算机身份是否通过或未通过身份验证过程。 它不能实施策略“如果 3 号用户连接就加密”或“如果是受信任主机 IPS-SQL-DFS-01 或 IPS-SQL-DFS-02 就加密”。 管理员必须通过对加密隔离组中的服务器使用 IPsec 策略来实现目标行为，此隔离组要求“为任何入站的受信任主机连接加密”，同样要求“为任何到受信任主机的出站连接加密”。

到目前为止，该设计过程还未论述 IPsec 策略设计的细节。 第 5 章将提供 Woodgrove 的 IPsec 策略设计的详细信息。

在设计过程的这个阶段，已完成了所要求的任务，以将需求转化为草案设计。 本节帮助制作了创建 IPsec 策略所必需的设计和文档。

可能影响设计的限制因素

以下问题可能会影响设计，因此在认为设计完成之前必须加以考虑：

•

不同主机到使用 IPsec 的服务器并发连接的最大数量。 在使用频繁的服务器上，IPsec 实施是否平稳进行，或是由于 IKE 或 IPsec 处理使 CPU 超负荷，并发连接的数量是关键因素。 每个成功的 IKE 协商都建立 SA，大约占用 5 kb 的用户模式内存。 需要 CPU 资源来维护当前的 IKE SA 状态以及所有并发连接的对等端。 有关伸缩的详细信息，请参阅白皮书“Improving Security with Domain Isolation: Microsoft IT implements IP Security (IPsec)”，网址为 www.microsoft.com/technet/itsolutions/msit/security/ipsecdomisolwp.mspx。

•

使用 IPsec 的主机 Kerberos 令牌的最大限制。 实际限制大约为每个用户 1,000 组，如果超过此值，GPO 应用可能失败。 有关此主题的详细信息，请参阅 Microsoft 知识库 (KB) 文章 327825“New Resolution for Problems That Occur When Users Belong to Many Groups”（网址为 http://support.microsoft.com/?kbid=327825）以及 306259“Members of an Extremely Large Number of Groups Cannot Log On to the Domain”（网址为 http://support.microsoft.com/?kbid=306259）。 尽管这些文章专门论述用户，计算机帐户也存在问题，因为 Kerberos MaxTokenSize 也应用于计算机帐户。 尽管在大多数实施中很少达到该限制，如果决定将计算机放入（也许是客户端）大量 NAG 中，需要了解此问题。

如果设计会受这些问题的影响，则需要重新审核设计过程以解决问题。 例如，可通过将负载很重的服务器移到免除列表中，解决并发连接的最大数量问题。 通过减少设计中使用的 NAG 数量，可解决最大 Kerberos 令牌大小限制。

如果这些限制对设计没有影响，则下一个任务是考虑如何将设计部署到组织中。

返回页首

组实施方法

创建了初始设计之后，必须仔细考虑部署 IPsec 的过程。 只有在规模最小的环境下，才有可能简单向所有的计算机部署策略，并期望 IPsec 平稳工作，对用户的影响小到可以接受。

在大型组织中，复杂性和风险使得分阶段部署策略成为必要。 通过使用这一方法，组织可帮助减少与这种环境的基本变更相关的风险。 没有细致的规划，求助电话和效率低下会迅速增加部署的成本。

在组织中部署 IPsec 有许多方式。 一些有助于确定部署方法的因素包括：

•	环境的开始和最终状态。
•	组配置的复杂性。
•	域结构的复杂性。
•	组织的风险承受度。
•	安全要求。

以下部署方法没有全部包含，但提供了可采用的可能方案的实例。 也可以使用这些方案的组合。 通常，最初组织不应当部署限制或阻止通信的 IPsec 策略，以确保有足够的时间解决问题，以减少复杂环境的管理协调。

无论使用哪种方法部署 IPsec，大力建议在实验室中对部署方案进行彻底测试，包括配置步骤和策略更改的特定序列和时间。 此外，使用要求 IPsec 功能的筛选器操作，但使用“回退到使用明文”通信方式接收明文通信。 此方案有助于将初始部署的影响降到最低。 部署完成之后，采用更安全的操作模式，要求通信流受 IPsec 保护。

对于生产环境中的部署，强烈建议对部署的每个主要阶段进行初始试验。 分析影响 IPsec 策略更改的尤为重要，因为在生产环境下，作为 Kerberos 票证生命周期、组策略轮询间隔和 IPsec 策略轮询间隔的结果，这些更改会产生作用。 应当实施具有回滚策略和回滚标准的正式更改控制过程，以确保所有受影响的 IT 组织了解更改和其影响，并知道如何向决策者协调反馈。

按组部署

“按组部署”的方法使用完整定义的 IPsec 策略，但通过在提供策略的 GPO 上使用组和 ACL 控制策略的应用。

在“按组部署”方法中，最终配置时在 Active Directory 中创建 IPsec 策略。 每个 IPsec 策略都具有所有的免除和安全子网，由所启用的适当的筛选器操作定义。

然后，IPsec 策略管理员为每个 IPsec 策略创建 GPO。 此外，在域中创建计算机组，管理和应用这些新创建的 GPO。 对 GPO 上的 ACL 进行修改，使得 Authenticated Users 成员不再具有“应用”权限。 合适的管理员用户组（管理和应用策略），也被授予 GPO 的权限。

下一步，将合适的 IPsec 策略指派给相应的 GPO。 此外，GPO 被链接到 Active Directory 中合适的对象。 此时，环境中没有一台计算机应当接收策略，因为控制 GPO 指派的 ACL（读取 GPO 的能力）为空。

最后，确定要接收策略的计算机，这些计算机的帐户放在合适的计算机组中，这些计算机组能够读取访问 GPO。 用组成员身份信息更新计算机的 Kerberos 票证之后，GPO 与相应的 IPsec 策略一起会在下一个组策略轮询间隔应用。

注：限制域计算机读取 IPsec 策略对象的 ACL 或 Active Directory 中的 IPsec 策略容器不建议使用。

设想组织定义了两套 IPsec 策略的情况，即 IPsec 标准策略和 IPsec 加密策略。 IPsec 标准策略为默认策略，要求入站通信流使用 IPsec，但如果启动到非基于 IPsec 的计算机，则不允许系统回退到使用明文。 IPsec 加密策略要求始终与加密的 IPsec 进行协调。

在此例中，组织的管理小组在 Active Directory 中创建了两个 GPO：标准 IPsec GPO 和 加密 IPsec GPO。 此外，它们标识下表中的组：

表 4.9：IPsec 管理组

组名	组类型	描述
IPsecSTD	通用	控制 IPsec 标准策略的应用
IPsecENC	通用	控制 IPsec 加密策略的应用

两个新创建的 GPO 上的 ACL 被更新，以便它们没有自动应用到 Authenticated Users 组以及适当的应用组和管理组被授予正确的权限。 管理小组根据下表中的信息修改了两个 GPO 的 ACL：

表 4.10：GPO 上的组权限

组	标准 IPsec GPO	加密 IPsec GPO
Authenticated Users	读取	读取
IPsecENC	无	读取 应用组策略
IPsecSTD	读取 应用组策略	无

注：此表只显示了添加或修改的权限。 也有一些具有权限的附加组。

管理人员将两个 GPO 链接到 Active Directory 中的域。 此方法确保策略应用到域中的任何计算机，不需要修改计算机的位置（除非计算机位于阻止策略的 OU）。

随着计算机的确定，计算机的帐户被添加到 IPsecSTD 组或 IPsecEnc 组。 一段时间之后，相应的 IPsec 策略会应用并生效。

此方法要求细致的规划，以确保通信不中断。 例如，如果服务器放置在 IPsecEnc 组中，但依赖于该服务器的多个客户端不能与 IPsec 协商，这些客户端和服务器之间的通信会中断。

按策略构建部署

此部署方法使用一种技术，即 IPsec 策略可以在部署过程中从头开始创建。 此方法的优点是与 IPsec 的协调只占用整个 TCP/IP 通信流很小比例，而不是按组部署的方法中占用所有的内部子网。 此方法也允许测试内部网络到该目标子网的所有网络路径，以确定网络传递 IKE 协商和受 IPsec 保护的通信流没有问题。 另一个优点是，IPsec 的轮询间隔能够更迅速地提供 IPsec 策略更新（包括回滚），而不必依赖组成员身份在 Kerberos 票证授权票证 (TGT) 或服务票证中的更改。 此方法的缺点是应用于所有隔离域或组中的计算机，而不是象“按组部署方法”一样，应用于特定的计算机。 另外，当与指定子网通信时，有时候所有的计算机会具有三秒钟的延迟用于回退到使用明文。

在此部署方法中，最初 IPsec 策略只包括异常；在 IPsec 策略中，不存在计算机协商安全的规则。 此方法首先测试和确保任何可能正在使用的先前已有的本地 IPsec 策略被删除。 要管理那些具有特殊过程的系统，管理小组应当能够提前确定哪些主机正在使用本地定义的 IPsec 策略。 如果本地 IPsec 策略被域策略取代，会造成通信中断，受影响的计算机会在安全性方面受到损害。 不象被域策略应用覆盖的本地策略，Windows Server 2003 的永久策略与域策略应用的结果合并。 包含永久策略的系统可能看起来工作正常，但永久策略的配置会改变行为，或实际上降低了域策略所提供的安全性，或在安全子网规则添加到策略之后中断通信。

下一步，可使用组织网络中只影响单个子网的筛选器创建安全性规则，例如，“从任何 IP 到子网 A 所有的通信流，协商。”此规则会通过一个筛选器操作来接收入站明文，并触发所有到该子网的出站通信流的协商，该子网启用了“回退到使用明文”。 随着此 IPsec 策略在所有域的部署生效，通信会逐渐从软 SA 转移到该子网中受信任主机正常的 IPsec 安全关联。 任何 IKE 协商的失败，都会被调查和解决。 任何应用不兼容都会被确定和解决。 IPsec 会保护该子网中受信任主机之间的通信。 与该子网之外的受信任主机通信，会在三秒延迟之后回退到使用明文。 将附加子网添加到安全规则，直到策略构建到最终状态。

设想组织定义了单个 IPsec 策略，称为 IPsec 标准策略，该策略要求 IPsec 协商，但若失败则回退到使用明文通信。 此策略在 Active Directory 中创建，只包含免除规则。

创建并链接标准的 IPsec GPO，以便将其应用于环境中的所有计算机。 此外，将 IPsec 标准策略指派给该新的 GPO。

最终会将该 IPsec 策略指派给所有的计算机。 由于该域策略将替代现有的本地策略，因此会发现本地 IPsec 策略的任何问题。 问题会不断得到解决，直到所有的子网都列入安全子网筛选器列表。

返回页首

Woodgrove Bank 的组实施

Woodgrove Bank 选择了首先使用构建的方法，将所有的计算机移到边界组来实施其生产部署。 此方法允许管理员以缓慢的方式进行部署，并解决任何突出的问题，而不会对所有系统之间的通信造成重大影响。 首先部署不带任何安全子网的策略，管理小组可以确定任何已指派本地 IPsec 策略的系统，并将此信息用于其他考虑。 随着将子网加入到策略中，发现的所有其他冲突都得到解决。

计算机在边界组策略下运行后，管理小组已实施了隔离域、无回退以及加密组。 部署这些组使用了“按组部署”的方法。 选择了一组计算机来进行试验，并将它们添加到控制新策略的适当组中。 问题一经发现即得到解决，将其他计算机添加到组，直到组达到饱和。

下表列出了解决方案完全部署之后计算机组和 NAG，以及它们的成员身份：

表 4.11：计算机和网络访问组成员身份

计算机或网络访问组	成员
CG_IsolationDomain_Computers	Domain computers
CG_BoundaryIG_Computers	IPS-PRINTS-01
CG_NoFallbackIG_Computers	IPS-LT-XP-01
CG_EncryptionIG_Computers	IPS-SQL-DFS-01 IPS-SQL-DFS-02
ANAG_EncryptedResourceAccess_Users	User7
ANAG_EncryptedResourceAccess_Computers	IPS-SQL-DFS-01 IPS-SQL-DFS-02 IPS-ST-XP-05
DNAG_EncryptionIG_Computers	CG_BoundaryIG_Computers

注意：ANAG_EncryptedResourceAccess_Computers 组包含了加密隔离组中的服务器。 这样就能够按要求与自身通信，并互相通信。 如果不要求这些服务器进行通信，则不需要将其添加到该组。

返回页首

总结

本章描述了服务器和域隔离解决方案的设计过程。 任务包括：确定计算机组和 NAG 的需要、了解基础隔离组、添加附加隔离组、完成通信流模型、给组分配成员身份，以及规划部署方法。

本章也在 Woodgrove Bank（一个虚构的组织）使用了 IPsec 实施，以帮助说明实际的设计过程，并在 Microsoft 测试实验室中检验设计。

根据业务需求和从前两章所获得的发现信息进行组的设计，并记录在电子表格 Business_Requirements.xls 中（在“工具和模板”文件夹中）。 对 IPsec 在网络中影响的评价，也是重要的考虑因素。

阅读完本章后，应当掌握以下方面足够的信息：开始规划隔离组、记录组之间的通信需求，以及规划高层的 IPsec 策略。 这些任务为第 5 章“为隔离组创建 IPsec 策略”作好准备。

更多信息

本部分提供了到其他信息的链接，这些信息在实施该解决方案时可能有帮助。

IPSec

以下链接提供了广泛的特定于 Windows 的 IPsec 内容：

•	白皮书“Using Microsoft Windows IPSec to Help Secure an Internal Corporate Network Server”介绍了第一个模型，使用 IPsec 保护对处理或存储敏感信息的内部服务器的网络访问。 此白皮书的下载网址为 www.microsoft.com/downloads/ details.aspx?FamilyID=a774012a-ac25-4a1d-8851-b7a09e3f1dc9&displaylang=en。
•	案例研究“Improving Security with Domain Isolation: Microsoft IT implements IP Security (IPSec)”中对 Microsoft 部署 IPsec 以保护所有域成员进行了描述，网址为 www.microsoft.com/technet/itsolutions/msit/ security/ipsecdomisolwp.mspx。
•	“Windows 2000 的 IPsec”页面，网址为 www.microsoft.com/windows2000/technologies/communications/ipsec/。
•	Microsoft Windows Server 2003“IPsec”页面，网址为 www.microsoft.com/windowsserver2003/technologies/networking/ipsec/。

安全性

•	Microsoft IT 安全风险评估方法请参见“Microsoft 的 IT 安全实践”白皮书，网址为 www.microsoft.com/technet/itsolutions/msit/security/mssecbp.mspx。

Windows Server 2003 Active Directory

有关 Active Directory 的详细信息，请参阅：

•	“Windows Server 2003 Active Directory”页面，网址为 www.microsoft.com/windowsserver2003/technologies/directory/activedirectory/。