RPC over HTTP 部署建议

本部分介绍在通过 HTTP 使用 RPC 时实现最大安全性和性能的最佳做法和建议的部署配置。 此处的各种配置适用于不同的组织，具体取决于不同的大小、预算和安全要求。 每个配置还提供了部署注意事项，有助于确定哪种方案最适合给定方案。

有关高容量 RPC over HTTP 方案的信息，请参阅 Microsoft RPC 负载均衡。

以下建议适用于所有配置：

• 使用支持 RPC over HTTP v2 的 Windows 版本。
• 在 IIS 6.0 模式下运行 RPC 代理的计算机上放置 IIS。
• 禁止匿名访问 RPC 代理虚拟目录。
• 从不启用 AllowAnonymous 注册表项。
• 使 RPC over HTTP 客户端使用 CertificateSubjectField (请参阅 RpcBindingSetAuthInfoEx 以获取详细信息) 验证连接到的 RPC 代理是否是所需的 RPC 代理。
• 将 ValidPorts 注册表项配置为仅包含 RPC over HTTP 客户端将连接到的计算机。
• 请勿在 ValidPorts 键中使用通配符;这样做可以节省时间，但完全意外的计算机也可能适合通配符。
• 在 RPC over HTTP 客户端上使用 SSL。 如果遵循这些部分中所述的准则，则 RPC over HTTP 客户端将无法在没有使用 SSL 的情况下进行连接。
• 将 RPC over HTTP 客户端配置为除使用 SSL 外，还使用 RPC 加密。 如果 RPC over HTTP 客户端无法访问 KDC，则只能使用 Negotiate 和 NTLM。
• 将客户端计算机配置为使用 NTLMv2。 将 LMCompatibilityLevel 注册表项设置为 2 或更高。 有关 LMCompatibilityLevel 密钥的详细信息，请参阅 msdn.microsoft.com。
• 使用上述配置运行 RPC 代理计算机的 Web 场。
• 在 Internet 和 RPC 代理之间部署防火墙。
• 为了获得最佳性能，请将 IIS 配置为针对不成功的错误代码发送简短响应。 由于 IIS 响应的使用者是一个自动化过程，因此无需将用户友好的解释发送到客户端;RPC over HTTP 客户端只会忽略它们。

从安全性、性能和可管理性的角度来看，RPC 代理的基本目标如下：

• 为传入服务器网络的 RPC over HTTP 流量提供单一入口点。 将 RPC over HTTP 流量单一入口点引入服务器网络有两main优势。 首先，由于 RPC 代理面向 Internet，因此大多数组织将此类计算机隔离在称为不受信任的外围网络的特殊网络中，该网络独立于正常的组织网络。 不受信任的外围网络中的服务器经过非常仔细的管理、配置和监视，能够抵御来自 Internet 的攻击。 不受信任的外围网络中的计算机越少，就越容易配置、管理、监视和保证它们的安全。 其次，由于安装了 RPC 代理的单个 Web 场可以通过驻留在公司网络上的 HTTP 服务器为任意数量的 RPC 提供服务，因此通过 HTTP 服务器将 RPC 代理与 RPC 分离，并让 RPC 代理驻留在不受信任的外围网络中非常有意义。 如果 RPC 代理与 RPC over HTTP 服务器位于同一台计算机上，则组织将被迫将其所有后端服务器放入不受信任的外围网络，这使得确保不受信任的外围网络更加困难。 分离 RPC 代理和 RPC over HTTP 服务器的角色有助于组织保持不受信任的外围网络中的计算机数量可管理，因此更安全。
• 充当服务器网络的安全保险丝。 RPC 代理设计为服务器网络的消耗性保险丝 - 如果 RPC 代理出现问题，它只会发出，从而通过 HTTP 服务器保护真正的 RPC。 如果到目前为止已遵循本部分中概述的最佳做法，则除了 SSL 之外，还会使用 RPC 加密对 RPC over HTTP 流量进行加密。 RPC 加密本身在客户端和服务器之间，而不是在客户端和代理之间。 这意味着代理不理解并且无法解密它收到的 RPC 流量。 它仅了解客户端发送给它的一些控制序列，这些控制序列由处理连接建立、流控制和其他隧道详细信息。 它无法访问 RPC over HTTP 客户端发送到服务器的数据。 此外，RPC over HTTP 客户端必须独立地向 RPC 代理和 RPC over HTTP 服务器进行身份验证。 这提供了深层防御。 如果 RPC 代理计算机由于某些配置错误或某种类型的安全漏洞而遭到入侵，则通过它传递的数据仍可受到篡改。 获得 RPC 代理控制权的攻击者最多可以中断流量，但不能读取流量或篡改流量。 这是 RPC 代理的融合角色发挥作用的地方 -- 它是消耗的，而不会损害 RPC over HTTP 流量的安全性。
• 在 Web 场中运行 RPC 代理的多台计算机之间分发一些访问检查和解密工作。 RPC 代理在 Web 场中运行良好，使组织能够卸载 SSL 解密和某些访问检查，从而在后端服务器上释放更多容量进行处理。 通过使用 RPC 代理计算机的 Web 场，组织还可以通过增加其前端服务器上的容量来增强其抵御拒绝服务 (DoS) 攻击的能力。

在迄今制定的准则中，组织仍有选择。 每个组织在用户不便、安全性和成本之间都有选择和妥协：

• 使用基本身份验证或 Windows 集成身份验证向 RPC 代理进行身份验证？ RPC over HTTP 目前仅支持 NTLM ， 它不支持 Kerberos。 此外，如果 RPC over HTTP 客户端与 RPC 代理（ 通过 杂注插入 HTTP 标头）之间存在 HTTP 代理或防火墙，则 NTLM 身份验证将不起作用。 如果不是这种情况，组织可以在基本身份验证和 NTLM 身份验证之间进行选择。 基本身份验证的优点是更快、更简单，因此拒绝服务攻击的机会更少。 但 NTLM 更安全。 根据组织的优先级，它可以选择“基本”、“NTLM”或允许用户在两者之间选择。 如果只选择了一个，最好从 RPC 代理虚拟目录关闭另一个，以降低攻击风险。
• 对 RPC 代理和 RPC over HTTP 服务器使用相同的凭据集，还是对每个凭据使用不同的凭据集？ 此决策的权衡在于用户的便利性和安全性。 很少有用户喜欢输入多个凭据。 但是，如果在不受信任的外围网络中发生安全漏洞，则为 RPC 代理和 RPC over HTTP 服务器使用单独的凭据集可提供额外的保护。 请注意，如果使用单独的凭据，并且一组凭据是用户的域凭据，则建议将用户的域凭据用于 RPC over HTTP 服务器，而不是 RPC 代理。