第 4 章 –安全通信

了解保障分布式 .NET Web 应用程序各层之间的网络通信安全的原因和方法。

了解以下三项用于实现安全通信的重要技术（SSL/TLS、IPSec 和 RPC 加密）的目的、功能和局限性。

确定 SSL/TLS、IPSec 和 RPC 加密这三项技术中哪一项技术最适合保护您的分布式 Web 应用程序中不同元素之间的通信安全。

Windows XP 或 Windows 2000 Server (Service Pack 3) 以及更高版本的操作系统

Microsoft Internet 信息服务 (IIS) 5.0 以及更高版本

SQL Server 2000 (Service Pack 2) 以及更高版本

阅读第 1 章简介。本章详细说明了安全通信对于分布式 Web 应用程序的重要性。

阅读第 2 章 ASP.NET 应用程序的安全模型。本章概述了创建分布式 ASP.NET Web 应用程序时所采用的体系结构和技术，并重点说明了该体系结构中哪些地方需要保证通信安全。

阅读以下各章，它们演示了本章所讨论的各项安全通信技术：

保密性。保密性是指确保数据处于私有和保密状态，并且不会被可能使用网络监控软件的窃听者查看到。通常借助加密来达到保密目的。

完整性。安全的通信通道还必须能确保数据受到保护，以防止数据在传输过程中遭到意外或蓄意（恶意）的修改。完整性通常是通过使用“消息身份验证代码”(Message Authentication Code, MAC) 实现的。

安全套接字层/传输层安全 (SSL/TLS)。它通常用于确保浏览器与 Web 服务器之间的通道安全。不过，还可以用于保护从运行 Microsoft® SQL Server™ 2000 的数据库服务器进出的 Web 服务消息和通信的安全。

Internet 协议安全性 (IPSec)。IPSec 提供了传输层安全通信解决方案，可以用于保护在两台计算机（例如应用程序服务器和数据库服务器）之间传送的数据的安全。

远程过程调用 (RPC) 加密。分布式 COM (Distributed COM, DCOM) 使用的 RPC 协议提供了一个身份验证级别（数据包保密性），它对客户端和服务器之间传送的每个数据包都进行加密。

Q257591 Description of the Secure Sockets Layer (SSL) Handshake（安全套接字层 (SSL) 握手说明）

Q257587 Description of the Server Authentication Process During the SSL Handshake（SSL 握手期间的服务器身份验证过程说明）

Q257586 Description of the Client Authentication Process During the SSL Handshake（SSL 握手期间的客户端身份验证过程说明）

应用 SSL 时，客户端使用 HTTPS 协议（并指定 https:// URL），而且服务器在 TCP 端口 443 上侦听。

启用 SSL 时，您应该监控应用程序的性能。
SSL 使用复杂的加密功能对数据进行加密和解密，因此对应用程序的性能有所影响。初始握手时使用非对称的公钥/私钥加密，此时对性能的影响最大。此后（生成并交换了安全会话密钥后），将使用速度更快的对称加密来对应用程序数据进行加密。

您应该在使用 SSL 的页面中使用较少的文字和简单的图形，从而对页面进行优化。

由于在建立会话期间，SSL 对性能的影响最大，因此请确保连接不超时。
您可以通过增大 ServerCacheTime 注册表项的值来做相应调整。有关详细信息，请参见 Microsoft 知识库文章 Q247658 HOW TO: Configure Secure Sockets Layer Server and Client Cache Elements（如何：配置安全套接字层服务器和客户端缓存元素）。

SSL 要求将服务器身份验证证书安装在 Web 服务器上（如果您要使用 SSL 与SQL Server 2000 通信，则安装在数据库服务器上）。有关安装服务器身份验证证书的详细信息，请参见本指南中的如何在 Web 服务器上设置 SSL。

对两台计算机之间传送的所有数据加密，从而实现消息机密性。

在两台计算机之间提供消息完整性（但不加密数据）。

在两台计算机（而非用户）之间相互验证身份。例如，您可以建立只允许特定客户端计算机（例如应用程序服务器或 Web 服务器）所发请求的策略，从而帮助保护数据库服务器的安全。

限制哪些计算机能够相互通信。您也可以限制只与特定的 IP 协议和 TCP/UDP 端口通信。

IPSec 既可以用于身份验证，又可以用于加密。

没有供开发人员以程序设计方式控制设置的 IPSec API。IPSec 完全是通过本地安全策略 Microsoft 管理控制台 (MMC) 内的 IPSec 管理单元进行控制和配置的。

Microsoft Windows® 2000 操作系统中的 IPSec 并不能保护所有 IP 通信类型的安全。
具体来说，它不能用于保护广播通信、多路广播通信、Internet 密钥交换通信或 Kerberos（已经是一个安全协议）通信的安全。

有关详细信息，请参见 Microsoft 知识库文章 Q253169 Traffic That Can--and Cannot--Be Secured by IPSec（IPSec 能够保护和不能保护的通信）。

您可以使用 IPSec 筛选器控制何时应用 IPSec。
若要测试 IPSec 策略，请使用 IPSec 监视器。IPSec 监视器 (Ipsecmon.exe) 提供有关哪个 IPSec 策略是活动的以及计算机之间的安全通道是否已经建立的信息。

有关详细信息，请参见下列 Microsoft 知识库文章：

若要在两个服务器之间建立信任关系，可以使用具有相互身份验证的 IPSec。这种方法使用证书来验证两台计算机的身份。

有关详细信息，请参见下列 Microsoft 知识库文章：

如果您需要使用 IPSec 来保护两台被防火墙隔开的计算机间的通信安全，请确保防火墙没有使用网络地址转换 (Network Address Translation, NAT)。IPSec 不能在任何基于 NAT 的设备上运行。

有关详细信息和配置步骤，请参见 Microsoft 知识库文章 Q233256 HOW TO Enable IPSec Traffic through a Firewall（如何使 IPSec 通讯能够通过防火墙）和本指南中的如何使用 IPSec 在两个服务器之间进行安全通信。

浏览器到 Web 服务器

Web 服务器到远程应用程序服务器

应用程序服务器到数据库服务器

您使用的是“窗体”身份验证，并且需要保护从登录窗体提交给 Web 服务器的明文凭据的安全。
在这种情况下，您应该使用 SSL 保护所有页面（而不仅仅是登录页面）的访问安全，以确保初始身份验证过程中生成的身份验证 Cookie 在客户端浏览器与应用程序的会话期间保持安全状态。

您使用的是“基本”身份验证，并且需要保护（Base64 编码的）明文凭据的安全。
此时，您应该使用 SSL 确保所有页面（而不仅仅是初始登录页）的访问安全，因为“基本”身份验证会随对应用程序的所有请求（不仅仅是初始请求）将明文凭据传送到 Web 服务器。

注意：Base64 用于将二进制数据编码为可打印的 ASCII 文本。与加密不同的是，它不提供消息的完整性和保密性。

您的应用程序在浏览器和 Web 服务器之间传递机密数据（例如，信用卡号码或银行帐户明细）。

企业服务。如果您的远程服务器中承载了一个或多个服务组件（在企业服务服务器应用程序中），并且您直接与这些服务组件通信（使用 DCOM），则请使用“RPC 数据包保密性”加密。

有关如何在 Web 应用程序和远程服务组件之间配置 RPC 加密的详细信息，请参见第 9 章企业服务安全性。

Web 服务。如果您的远程服务器上承载了 Web 服务，则可以选择 IPSec 或 SSL。
由于 Web 服务已使用 HTTP 传输，因此通常您应使用 SSL。SSL 还使您可以只对从 Web 服务传入和传出的数据（而不是在这两台计算机之间的所有通信）进行加密。IPSec 则会使在两台计算机之间的所有通信都进行加密。

注意：消息级别安全（包括数据加密）由全球 XML Web 服务体系结构 (Global XML Web Services Architecture, GXA) 提案（具体说就是WS 安全规范）所提出。Microsoft 提供了 Web 服务开发工具包，能让您开发消息级别安全解决方案。该工具包可从 http://msdn.microsoft.com/webservices/building/wsdk/ 下载获得。

.NET 组件（使用 .NET Remoting）。如果您的远程服务器承载了一个或多个 .NET 组件，并且您通过 TCP 通道与这些组件连接，则可以使用 IPSec 来提供安全的通信链路。如果将 .NET 组件驻留在 ASP.NET 内，则可以使用 SSL（以 IIS 配置）。

您连接到数据库服务器，并且没有使用 Windows 身份验证。例如，您可能对 SQL Server 使用的是 SQL 身份验证，或者您可能连接到一个非 SQL Server 数据库。在上述情况下，将以明文方式传递凭据，因此可能存在严重的安全问题。

注意：对 SQL Server 使用 Windows 身份验证的一个主要优点是：这意味着不会在网络中传递凭据。有关 Windows 身份验证和 SQL 身份验证的详细信息，请参见第 12 章数据访问安全性。

您的应用程序可能会将机密数据提交到数据库并从数据库中检索机密数据（例如，工资单数据）。

若要使 SSL 生效，您必须在数据库服务器计算机上的计算机存储区中安装服务器身份验证证书。客户端计算机上也必须具有由颁发服务器证书的同一（或信任的）证书颁发机构颁发的根“证书颁发机构”证书。

客户端必须已经安装了 SQL Server 2000 连接库。早期版本或通用库会无法运行。

SSL 只适用于 TCP/IP（为 SQL Server 推荐采用的通信协议）和命名管道。

您可以将服务器配置为对所有（来自所有客户端的）连接都强制使用加密。

您可以在客户端上执行以下操作：

当客户端或服务器 IP 地址发生更改时，并不需要更改配置。这一点与 IPSec 不同。

本指南中的如何使用 SSL 来确保与 SQL Server 2000 安全通信。

网络广播：Microsoft SQL Server 2000: How to Configure SSL Encryption (April 23, 2002)（Microsoft SQL Server 2000：如何配置 SSL 加密（2002 年 4 月 23 日））

IPSec 可以用于保护计算机间的所有 IP 通信安全；而 SSL 则特定于个别的应用程序。

IPSec 是计算机范围的设置，因此不支持特定网络连接的加密。但是，网站可以划分为使用或不使用 SSL。此外，当您使用 SSL 连接到 SQL Server 时，可以按连接（从客户端应用程序）来选择是否使用 SSL。

IPSec 对于应用程序是透明的，因此它可以与在 IP 之上运行的安全协议结合使用，例如 HTTP、FTP 和 SMTP。而 SSL/TLS 却与应用程序紧密地联系在一起。

除了加密之外，IPSec 还可以用于计算机的身份验证。这对于受信任的子系统方案尤其重要，在这种方案中，数据库授权来自特定应用程序（在特定的计算机上运行）的固定身份。IPSec 可用于确保只有特定的应用程序服务器能够连接到数据库服务器，以防止来自其他计算机的攻击。

IPSec 要求两台计算机都运行 Windows 2000 或更高版本。

SSL 可以穿过基于 NAT 的防火墙工作，而 IPSec 则不能。

对于通过 Internet 和公司 Intranet 传递的数据来说，通道安全是个值得关心的问题。

考虑 Web 浏览器到 Web 服务器、Web 服务器到应用程序服务器以及应用程序服务器到数据库服务器等链接的安全要求。

安全通信提供保密性和完整性。它无法防止不可否认性（这需要客户端证书）。

通道安全选项包括 SSL、IPSec 和 RPC 加密。当您的应用程序使用 DCOM 与远程服务组件通信时，适合使用最后一个选项。

如果您使用 SSL 与 SQL Server 通信，应用程序可以选择（基于每个连接）是否对连接加密。

IPSec 会对两台计算机之间的所有 IP 通信都进行加密。

安全机制的选择取决于传输协议、操作系统版本和网络注意事项（包括防火墙）。

在安全通信与性能之间始终存在一种此消彼长的关系。请选择适合您的应用程序要求的安全级别。