标题: 服务器群集：Windows 2000 和 Windows Server 2003 安全性最佳做法 [打印本页] 作者: suncon 时间: 2003-8-17 09:39 标题: 服务器群集：Windows 2000 和 Windows Server 2003 安全性最佳做法 服务器群集：Windows 2000 和 Windows Server 2003 安全性最佳做法
摘要
本文介绍与服务器群集安全性相关的最佳做法。本文提供了与服务器群集的管理、操作和编写应用程序相关的准则和最佳做法，适用于 Windows 2000 及更高版本。本文分两部分介绍安全性最佳做法：一部分针对负责部署和管理服务器群集的管理员，一部分针对负责编译识别群集的应用程序或将要部署在群集上的应用程序的开发人员。
一般性假设
应该为基础结构设置一些一般性假设和可行的最佳操作，以确保服务器群集运行环境的安全。
服务器和存储器应处于真正安全的位置。
设置检测不规则通信的实用安全实现，例如防火墙、网络探测和管理工具。
在类似管理、日志存储、备份和恢复这样的领域，坚持安全方面的最佳做法/常识。
在分配管理权限、ACL 资源和其他内务处理角色方面，坚持平台级安全性最佳做法。
Active Directory、DNS、DHCP、WINS 等网络基础结构服务必须是安全的。任何危及这些基础结构服务安全的做法均可导致危及群集服务自身的安全。
群集管理员必须确保在受信任的计算机上运行调用群集 API (ClusAPI) 的应用程序。危及执行这些应用程序（由群集管理员运行）的计算机的安全均可危及群集的安全。例如，如果在运行管理工具的工作站上存在具有提升权限的不受信任的用户，群集管理员可能会在本人毫无察觉的情况下对群集运行不可信代码或恶意代码。
对于由群集服务创建和维护的对象集，切勿将这些对象的默认设置调整为限制较少的设置，以免危及它们的访问安全。群集服务可利用操作系统中的一系列对象，例如文件、设备、注册表项等。这些对象都具有默认的安全设置，可确保非特权用户无法影响群集配置或群集上运行的应用程序。将这些安全设置改为限制较少的安全设置可能导致危及群集的安全并损坏应用程序数据。
部署与操作管理
备注 从群集中脱离节点时不会将群集服务帐户从本地管理员组中删除。将节点从群集中删除后，应当手动将群集服务帐户从本地管理员组中删除，以免接纳对计算机具有本地管理员权限的过期帐户。
服务器群集中的节点可使用经过身份验证的通信机制，以确保在群集内的协议中只有该群集的有效成员可以参与。群集中每个节点都具有相同的群集服务帐户是非常重要的，因为这样才能提供身份验证的一致性。这也是 Microsoft® Windows Server 2003 中引入的群集服务帐户密码实用程序的要求。
在设置群集服务器过程中，这些权限会在本地授予帐户。无论何时需要手动重新创建群集服务帐户，都必须授予这些附加权限。知识库文章 269229：How to Manually Re-Create the Cluster Service Account（如何手动重新创建群集服务帐户）描述了重新创建群集服务帐户所需的步骤。
Windows 2000
群集中所有节点上的群集服务帐户都必须匹配，以确保可以成功地对群集内通信进行身份验证。在各种条件下群集服务本身会在群集节点之间发送消息，如果这些通信中的任何一个失败，群集节点将从群集中被删除（即群集服务将被停止）。不可能确定群集服务何时建立通信，因此没有明确的窗口可用来以可靠的方式更改群集服务帐户，同时确保群集仍然运行。
在 Windows 2000 中，只能使用以下步骤可靠地更改群集帐户密码：
停止群集中所有节点上的群集服务
更改域控制器中的群集服务帐户的密码
更新所有群集节点上的服务控制管理器密码
重新启动所有群集节点上的群集服务
Windows Server 2003
Windows Server 2003 中的 cluster.exe 命令能够动态地更改群集帐户密码，而无须关闭任何节点上的群集服务。cluster.exe 命令可更改域帐户密码并更新群集中所有节点上的服务控制管理器帐户信息。
备注 此命令仅适用于 Windows Server 2003 节点。如果群集中有任何 Windows 2000 节点，则这些节点的群集服务帐户密码将不被更改。
Cluster /cluster:cluster_name1[,cluster_name2,] /changepassword[:new_password[,old_password]] [/skipdc] [/force] [/options]
最佳做法
群集服务帐户不能是域管理员帐户。
应该授予所有帐户尽可能少的权限和特权，以免给定帐户泄漏时出现潜在的安全问题。
使用委派为群集中所有节点上的特定帐户授予管理权限。
如果单个域中有多个群集，在所有节点上使用同一群集服务帐户可简化管理工作。
对多个群集使用单个帐户既可以简化管理，同时又带来潜在的安全风险，您需要在这二者之间做出权衡。如果帐户泄漏，受影响的范围取决于涉及到多少个群集。
使用 Windows Server 2003，可以同时更改多个群集中的群集服务帐户密码。
如果已经在群集服务帐户上设置了密码过期策略，则不应对其他服务使用此帐户。
例如，如果已经设置了密码过期策略，不要对 SQL Server 2000 或 Exchange 2000 使用群集服务帐户。如果有多个服务使用同一个帐户，在群集服务和其他服务之间协调密码更改将会非常复杂，并导致密码轮换期间整个群集和/或服务不可用。最好对每项服务使用一个专用帐户，以便可以独立维护各个帐户。
使用 Windows Server 2003，可以联机更改群集服务帐户密码，而不必仅当没有服务使用同一服务帐户时关闭群集。
更改 Windows 2000 上的群集服务帐户需要完全关闭群集，然后才能更改帐户密码。关闭并重新启动群集可能意味着群集无法满足可用性要求。例如，对应用程序和服务来说 99.999% 的运行时间需要每年 少于五分钟的停机时间。如果群集由于密码循环而关闭，则无法达到此可用性级别。使用 Windows 2000 时，在这些高可用性环境中，群集服务帐户的密码过期策略应为永远不过期。
用 Windows 2000 SP3 和 Windows Server 2003，群集服务可以发布虚拟服务器作为 Active Directory 中的计算机对象。要确保操作正确，群集服务帐户应有适当的访问权限或特权以便能够创建和操作 Active Directory 计算机容器中的这些对象。
请参阅“在服务器群集中使用 Kerberos 身份验证”一节。
如果打算使用不同的群集服务帐户部署多个群集，则应创建一个实现上述所有策略并具有上述所有特权的全局组或通用组。然后，应该将每个群集服务帐户放入该组中。
通过为所有群集服务帐户提供一个容器并提供一个管理位置来更改帐户策略，从而简化了群集服务帐户的管理。
在服务器群集中使用 Kerberos 身份验证
Windows 2000 中的 Kerberos 身份验证是作为 Windows 平台的一部分发布的。它是 Windows 平台能够向前发展的主要（和默认）安全机制，并且与以前的身份验证机制（例如 NTLM）相比，它有许多优点：
提供客户端和服务器之间的相互身份验证：服务器确保客户端可以访问服务器上提供的服务或应用程序，而客户端可以确保它正在与之通信的服务器确实是它所需要的那台服务器。
允许在多台计算机之间进行委派身份验证：在多层应用程序部署中，允许与原始请求关联的基于凭据的端对端模拟。例如，一个 Web 站点中可能包含一个 IIS Web 服务器前端、在中间层的业务对象和一个后端的数据库。Kerberos 允许在所有 Web 服务器到数据库的所有层之间执行原始客户身份验证，以实现端到端的身份验证和授权。
它是一种允许在多个平台之间实现通用身份验证机制的工业标准。
有关 Kerberos 及其工作原理的详细信息，请访问 TechNet Web 站点：http://www.microsoft.com/technet/tr...ts/kerberos.asp
在服务器群集中，应用程序部署在虚拟服务器 中。虚拟服务器是一个服务器群集资源组，它包含 IP 地址资源和网络名称资源以及给定的服务或应用程序所需的任何资源。客户端使用与服务关联的 IP 地址或网络名称连接到群集服务。当应用程序从一个节点故障转移到另一个节点时，IP 地址和网络名称资源也会相应地转移过去，因此，不论客户端当前是由群集中的哪台计算机承载的，客户端都将继续使用服务或应用程序原来的目标位置。
对于 Windows 2000（SP2 以下）中的服务器群集，可用于根据虚拟服务器名称对客户端进行身份验证的唯一机制是 NTLM，因此 Kerberos 提供的好处对于包含服务器群集的部署不可用。
在 Windows 2000 SP3 和 Windows Server 2003 中，Kerberos 身份验证将可用于群集服务器应用程序，允许在高度可用的部署中实现端对端模拟。
虚拟服务器计算机对象
Kerberos 身份验证需要在 Active Directory 中发布一个后备计算机对象 (CO)。在 Windows 2000 SP3 和更高版本中，网络名称群集资源可以在 Active Directory 中为虚拟服务器发布计算机对象。这是通过新资源属性 RequireKerberos 的下列值控制的：
RequireKerberos = 0
网络名称资源不在 Active Directory 中创建对象。这提供了与 Windows 2000（SP2 以下）相同的语义，并且是默认值，可确保实现向后兼容以及滚动升级过程中的正确操作1。
RequireKerberos = 1
网络名称资源在 Active Directory 中创建对象，从而能够根据虚拟服务器计算机名称进行 Kerberos 身份验证。
本节的稍后部分将介绍此属性的完整语义。
备注 虽然网络名称资源在 Active Directory 中发布计算机对象，但是不应该将此计算机对象用于管理任务，如应用组策略。Windows 2000 和 Windows Server 2003 中虚拟服务器计算机对象的唯一作用就是使识别群集和 Active Directory 的服务（例如 MSMQ）能够使用 Kerberos 身份验证和委派，以发布服务提供程序信息。
计算机对象的寿命
网络名称资源根据某些因素（包括资源属性设置和资源自身的寿命）控制计算机对象的创建和删除。
创建计算机对象
当 RequireKerberos 资源属性设置为 1（默认值为 0）时，网络名称资源将创建计算机对象。将此值设置为 1 要求群集服务帐户必须能够访问 Active Directory，这可以通过具有将工作站添加到域 特权或授予访问 Active Directory 的特定权限来实现。如果帐户没有访问权限，则网络名称资源将无法联机。
如果与虚拟计算机名称对应的 Active Directory 中存在孤立计算机对象或由域管理员创建的计算机对象，同时群集服务帐户具有该对象的访问权限，而且该对象没有禁用，则网络名称资源将截获该现有计算机对象。如果向域中添加新计算机，而该域包含具有相同名称的旧的、并且未使用的计算机对象，则会出现同样的问题。
网络名称资源将计算机对象的 DnsHostName 属性设置为网络名称资源 Name 属性的完全合格的 DNS 名称加上节点的主 DNS 后缀2。
重命名计算机对象
计算机对象与网络名称资源公开的虚拟网络名称联系密切。如果更改网络名称资源的 Name 属性，这种更改一定会在计算机对象中反映出来。这些变化是紧密搭配并且是同步的，因此，仅当网络名称资源脱机时才能更改 Name 属性。如果由于任何原因重命名计算机对象失败，对 Name 属性的更改也将失败。
备注 诸如 MSMQ 和 SQL Server 等许多应用程序和服务都不支持更改网络名称资源的 Name 属性。
密码轮换
当颁发 Kerberos 票证时计算机对象维护用于身份验证的密码。在最新的 Windows 2000 SP3 和 Windows Server 2003 实现中，在计算机对象创建之后，其中的密码将不会更改。
警告、问题和注意事项
孤立计算机对象
许多操作系统服务和应用程序都使用协商 安全程序包，它是 Windows 平台提供的一个组件，允许客户端通过某项服务进行身份验证。此程序包隐藏任何给定身份验证方案的细节，并且允许客户端尝试 Kerberos 身份验证，如果 Kerberos 身份验证不可用，则恢复到 NTLM 身份验证。如果 Active Directory 中有一个计算机对象与客户端正在使用的目标名称相对应，则协商程序包将假定 Kerberos 身份验证是必需的3。如果 Active Directory 中存在虚拟计算机对象（已禁用或未禁用），则将来与该虚拟服务器名称的客户端连接不会恢复到 NTLM。
如果对虚拟服务器的身份验证失败，并且该虚拟服务器使用的应该是 NTLM，那么应检查与该虚拟服务器名称对应的 Active Directory 中是否有孤立或旧的计算机对象。
识别群集和识别 Active Directory 的服务
有些服务既识别群集又识别 Active Directory，例如 SQL Server 2000、Exchange 2000 和 MSMQ。其中有些服务会将服务信息附加到计算机对象。例如，MSMQ 会将服务信息附加到虚拟服务器计算机对象。
从网络名称资源中删除 Kerberos 身份验证时，计算机对象将被禁用，系统管理员必须明确决定是否删除计算机对象。如果计算机对象被删除，由识别 Active Directory 的应用程序附加的属性也将被删除，从而导致应用程序可能无法再正常运行。从网络名称资源中删除 Kerberos 身份验证时要格外小心。
Active Directory 复制延迟
到目前为止，我们都是将 Active Directory 作为一个高度一致的基础结构进行讨论的。在生产环境中，会部署多个域控制器以确保域基础结构高度可用。对 Active Directory 的更改会在多个节点之间复制，有些情况下复制延迟时间可能很长。这可能导致出现一些看上去不一致的情况，这是您需要注意的：
客户端无法看到网络名称资源的计算机对象
不同的节点可能访问不同的域控制器。如果在某个域控制器上创建计算机对象，客户端可能无法看到该对象，直到它被复制到其他域控制器。
最佳做法
在群集中使用 Kerberos 身份验证时，请仔细规划：
在那些对您的部署有意义的虚拟服务器上启用 Kerberos 身份验证。
除非您完全理解使用虚拟服务器的服务以及虚拟服务器对该服务的影响，否则不要禁用虚拟服务器上的 Kerberos 身份验证。计算机对象和附加到其中的任何服务信息都将被删除（假设有正确的特权），这可能导致服务不可用或无法恢复。
群集服务帐户应具有将工作站添加到域 特权，以允许该帐户在 Active Directory 中创建计算机对象。如果您不想将该特权授予群集服务帐户，必须在启用 Kerberos 身份验证之前在 Active Directory 中手动创建计算机对象。
备注 将工作站添加到域 特权允许从该帐户创建 10 个默认的计算机对象。另外，将工作站添加到域 本身不允许删除该帐户或重命名计算机对象。
群集服务帐户应该具有写入所有属性 访问权限，以允许该帐户重命名计算机对象。
许多服务（包括 MSMQ 和 SQL Server 2000）都不支持更改网络名称资源的 Name 属性。仅当您完全理解更改此属性的含义时，才能更改此属性。有些情况下，更改网络名称资源的 Name 属性可能导致数据丢失或服务失败。
在允许客户端访问新创建的与网络名称资源相关联的计算机对象之前，或将资源故障转移到群集中的其他节点之前，应该确保域控制器有机会复制这些计算机对象。否则，可能导致无法预料的结果（请参阅“Active Directory 复制延迟”一节）。
网络安全性
流氓服务器
群集服务通过群集 API 提供远程管理功能，以便可以从管理站管理群集。群集 API 使用 NTLM 进行服务器身份验证。这使服务器能够验证客户端是否具有足够的权限和特权来管理群集，但是它不提供相互身份验证。也就是说，客户端不能完全确保它连接到的节点或群集是真正的群集。如果流氓计算机使用相同的 IP 地址或网络名称出现在网络上（如果 DNS 信息的安全被打破），则该流氓计算机可能会伪装成群集。如果该流氓计算机看起来还实现了群集服务 API，则发送到群集的任何管理命令都将被该流氓计算机截获。许多情况下，这并不代表威胁的存在，因为管理员只会收到一个虚假的关于操作是否已执行的报告。但是，在有些敏感的操作（例如，更改群集配置）中，未经授权的接收方可能潜在地收集群集配置数据，而这可能会助长扩大攻击面。
这种类型的攻击需要许多因素才可能发生：
必须能够在与目标群集相同的子网中看到流氓计算机，并且流氓计算机必须能够响应群集 IP 地址的通信（这可能是物理计算机的 IP 地址，也可能是此计算机承载的虚拟服务器的 IP 地址）。
在典型环境中，只有群集节点或虚拟服务器没有运行时，流氓计算机才能占用它们的 IP 地址。
流氓计算机看起来必须实现群集 API。对于典型的管理操作，客户端应用程序对服务器进行多次调用，有些情况下，将返回后续调用的句柄。
管理员/操作过程必须更改包括机密数据的配置（例如，管理员必须更改群集帐户密码）。
最佳做法
危害群集安全的攻击通常与群集位于同一子网上。要防止这些攻击，应该保护子网：
在受到 IPSec 保护的连接中，在第一阶段协商中将创建一个 IKE SA。在第二阶段协商中将创建两个 IPSec SA。超时值与 IKE 和 IPSec SA 关联。如果不使用“主密钥完整转发安全性”(Master Perfect Forward Secrecy)，则使用 IKE SA 中的密钥材料创建 IPSec SA。如果这样的话，客户端必须等待入站 IPSec SA 的默认超时或寿命结束，然后等待与 IKE SA 相关联的超时或寿命结束。
就安全性而言，常规文件共享是最灵活和最容易理解的一种方法。唯一真正的区别就是您使用群集用户界面而不是 Windows 资源管理器来管理共享级安全。使用标准 Windows 工具（如 Windows 资源管理器）管理群集磁盘上文件的 NTFS 安全设置。有关管理群集文件共享的更多信息，请参阅服务器群集的联机文档。
备注 请始终使用群集管理工具更改群集文件共享的安全性。如果使用文件共享管理工具，当文件共享故障转移到群集中的其他节点时，所有配置都将丢失。
共享子目录
高于 Windows NT® 4.0 Service Pack 4 的 Windows 版本中都提供了子目录共享。使用共享子目录，管理员可以使用一种群集资源快速创建能够承载大量共享的目录，如主目录。系统会指定根目录共享，指定根目录的下一级的所有子目录都被创建为常规文件共享。
作为域控制器的群集服务器节点
为使服务器群集正常工作（其中每个节点上都启动群集服务），组成群集的节点必须能够验证群集服务域帐户，该帐户是您配置群集时配置的帐户。为此，每个节点都必须能够与域控制器建立安全通道，以验证此帐户。如果无法验证此帐户，群集服务将无法启动。对于必须验证帐户才能启动服务的其他群集程序（如 Microsoft SQL Server 和 Microsoft Exchange）也是如此。
如果群集部署与 Windows NT 4.0 域、Windows 2000 域或 Windows Server 2003 域之间都没有链接，则必须将群集节点作为域控制器配置，以便总是能够验证群集服务帐户，使群集功能得以正常运行。
群集服务帐户策略
不要让密码过期。在 Windows Server 2003 中，可以使用密码更改机制确保密码定期循环。
对群集服务帐户使用强密码。
Active Directory
要确保 Kerberos 身份验证能够按预期的方式工作，群集服务帐户必须能够访问 Active Directory。“在服务器群集中使用 Kerberos 身份验证”一节讨论了这方面的内容。
DNS
群集服务帐户需要能够发布记录。在由 DNS 支持的安全区域中，DNS 管理员可以选择限制用户的访问权限。必须授予群集服务帐户创建记录的权限，或者可以预先创建记录。如果预先创建记录，则不应该将区域设置为动态更新。
多数节点集注意事项
Windows Server 2003 提供了一种新的能够进行仲裁的资源，称为多数节点集。此资源的主要目的是保持群集中数据的多个副本永远同步。可使用它在群集中提供仲裁资源，而不使用仲裁数据的共享磁盘，主要针对以下情况：
不要删除此文件共享。
不要从能够访问此共享的帐户组中删除群集服务帐户。
不要更改此文件共享的默认访问控制
文件共享目标是 %windir%\Cluster\MSCS 目录中的目录。不要更改文件或目录的默认访问权限。
永远不要将其他文件放入 MNS 目标目录 %windir%\Cluster\MSCS\MNS.guid-representation 中。如果将其他文件放入该目录，在删除 MNS 资源后进行清理时，它们将被删除。
升级到 Windows Server 2003 时的注意事项
Windows 2000 和 Windows NT4 的默认安全属性存储在 %windir%\Cluster 目录和仲裁目录中，这两个目录允许任何已通过身份验证的用户读取其中的内容。在 Windows Server 2003 中，这两个目录的安全性已得到加强，以防止非管理员用户访问，并确保未经授权的用户无法获取有关群集配置的信息。但是，在升级到 Windows Server 2003 时，这些安全属性不会修改，因此在升级后的 Windows Server 2003 计算机上，所有通过身份验证的用户可能都具有对这两个目录的读取权限。您可能需要考虑手动设置权限，以符合最低的访问要求。
调用服务器群集 API
服务器群集 API 是受保护的，使任意的、不受信任的用户不能影响群集的状态或应用程序的可用性。群集服务维护一个安全描述符以便控制访问。只有属于安全描述符的帐户才能调用群集 API（实际上，安全描述符控制哪些帐户能够打开群集的句柄，由于其他群集服务器 API 需要群集的句柄，因此这可以有效地限制访问）。
使用此机制时有一点需要注意。Windows Server 2003 中提供的群集配置机制要求向群集中添加节点的用户必须在群集中的每个节点上都具有本地管理员权限。如果用户在现有群集节点上没有本地管理员权限，则该用户无法将新节点成功添加到群集中。因此，为了赋予帐户对群集的管理权限，您应该：
将该帐户添加到群集服务安全描述符中。
确保该帐户在群集中的所有计算机上都是本地管理员组的成员。
这些操作可以通过使用群集 API 和安全性 API 以编程方式完成。有关更多详细信息，请参见 Platform SDK。
安全检查是通过 OpenCluster API 完成的。如果调用成功返回，说明调用方具有有效的句柄并且能够任意更改群集配置或枚举群集配置。没有以可读方式打开或以可写方式打开的概念。
备份/恢复 API
指定的备份 API 的备份路径应该受到保护。此 API 返回的数据中包含群集配置信息，这些信息可能被用于扩大攻击面（例如，列出所有群集 IP 地址）。
在恢复操作中，备份 API 接受要注入的群集配置。这些数据必须受到保护，因为它们将用于通过覆盖当前存在的任何配置来恢复群集。
确保资源 DLL 在文件系统级别受到保护，只允许本地管理员和群集服务帐户访问。
对于指定的任何路径都要非常小心。关于路径存在几个已知问题，特别是包含空格的路径（请按照 419 页上“编写安全代码”中的建议操作）。创建资源类型时，如果没有把握，应指定完全限定的资源 DLL 路径。
对于 MSMQ 所需的网络名称，默认情况下将启用 RequireKerberos，以确保在升级完成后 MSMQ 能够继续按预期的方式工作。
群集中的所有节点必须位于同一 NT 和 DNS 域中。
在整个 Windows Server 2003 域中，这将按预期的方式工作。
注意，这并不意味着您无法在群集节点上创建域根目录，因为群集节点就像任何其他服务器一样，但是它们不是群集资源。
通用脚本仅在 Windows Server 2003 中可用
本文中包含的信息代表了在发布之日，Microsoft Corporation 对所讨论问题的当前看法。由于 Microsoft 必须顺应不断变化的市场情况，不要将本文理解为 Microsoft 一方的承诺，Microsoft 不保证所提供的信息自发布之日后的准确性。
本文仅供参考。MICROSOFT 对本文中的信息没有任何明示或暗示保证。
遵守所有适用的版权法是用户的责任。在不限制版权法所规定的权利的情况下，未得到 Microsoft 公司明确的书面许可，不得出于任何目的、以任何形式或手段（电子的、机械的、影印、录制等）复制、传播本文的任何部分，也不得将其存储或引入到检索系统中。
Microsoft 可能拥有本文中的主题所涉及的专利、专利申请、商标、版权或其他知识产权。除非 Microsoft 的任何书面许可协议中有明确表述，否则获得本文并不代表您同时获得这些专利、商标、版权或其他知识产权的许可证。 作者: xyqy 时间: 2003-8-17 21:39 标题: 服务器群集：Windows 2000 和 Windows Server 2003 安全性最佳做法 如何才能把windows2000系统彻底卸载掉？当然不是用格式化，因为很多的数据和程序我还是想保留的。