在上一篇文章中，我们讨论了不同种类的攻击，以及如何进行配置以免受到攻击。本文中，我们将集中讨论如何进行设计和开发，以免受到攻击。
首先，我想介绍两个非常好的新工具，它们是 Microsoft® 开发的，可使您的 Web 服务器获得最大的安全性。IIS Lockdown Tool（英文）可以最大限度地防止可能的攻击者对您的 Microsoft® Internet Information Server (IIS) 进行访问。锁定工具还提供了“advanced”选项，您可以在其中选择所需设置。此外还提供了“rollback changes”选项。当您对所做更改不满意时可选择该选项。请尝试该工具。
另一个重要工具是用于 IIS 5.0 的 Hotfix Checking Tool（英文）。该工具会查询由 Microsoft 发布的所有可用安全性修补程序的 XML 文档（该文档是不断更新的），然后将此文档与本机安装的文档进行比较并报告其差异。使用该工具可以更轻松地管理单个 Web 服务器或大型 Web 领域的安全修补程序。

设计问题

设计 Web 服务时必须认真考虑安全问题，以及如何能够使遭受攻击的危险性降到最低。许多在试图防止攻击时可能起作用的因素都可以在设计时予以考虑。例如考虑如何进行身份验证，或希望返回哪类错误等问题。
确定安全需求

在 XML Web 服务设计的早期，您需要确定所需的安全级别。某些 XML Web 服务根本不需要身份验证，而其他服务对于确定使用该服务的用户有非常严格的要求。由 XML Web 服务接收和发送的数据需要何种隐私级别？如果某个 XML Web 服务用户声明他们未请求您记录中所指明的服务，则在工时、处理能力或法律费用方面可能要花费哪些成本？
首先，让我们来看一下身份验证。某些种类的身份验证会比其他身份验证更容易遭受攻击。在低端，如果您使用“HTTP 基本身份验证”，则可以看到网络上的数据包的所有用户都能看到您的用户名和密码。如果通过 Internet 发送请求，则您无法控制能看到您的数据包的用户。在身份验证级别的高端，您可以考虑使用 SSL 客户端证书进行身份验证，该证书提供了一个编码的通道，并使数据包的恶意攻击者很难进行攻击。有关身份验证选项的详细讨论，请参阅 At Your Service 专栏中 Mary Kirtland 的 Authentication and Authorization（英文）。
我们已经间接提到了身份验证过程中的隐私问题，当涉及到电子欺骗时您应考虑此问题。您还需要知道与所有从 XML Web 服务发送和接收的数据有关的隐私问题，而不仅仅是用户名和密码。例如，您可能会为通过身份验证的用户生成一个会话密钥，该用户将此密钥随每个请求一起发送以标识自身。如果此密钥未加密发送，则数据包的恶意攻击者可以看到此密钥，并用它向您的 Web 服务发送自己的请求，这样您的 Web 服务会将其看作是原来那个合法用户。
另一个隐私问题是由 Web 服务发送和接收的简单数据。该数据是否因其敏感性强而需要加密？SSL 加密的代价是 Web 服务会发送和接收整个加密的通道，从而降低性能。您或许可以只加密请求中的敏感项，但您随后可能需要在客户端上安装自定义编写的软件以启用加密/解密。使用 SSL 加密整个通道的一个优点是：目前大多数客户端平台都支持基本 SSL 通信，而不需要针对应用程序编写特定代码。
就基本安全性设计而言，还必须考虑否认的概念，即一个用户可以拒绝承认其通过 XML Web 服务执行的操作。例如，如果您提供股票交易服务，而某些人声称他们没有要求您的系统为其出售股票，并且要否认此出售命令。很明显，与其他服务相比，某些 XML Web 服务对这种问题可能会更为关心，但是您应该确定您的服务可能会遇到的危险，以及在方案中应采取什么样的有效措施。
使用安全的身份验证系统肯定是避免出现这类危险的首要步骤。例如，使用 HTTP 基本身份验证可能是不安全的，但是通过使用 SSL 的加密通道来使用此身份验证则是安全的。如果用户使用空密码或容易猜到的密码，即使具有安全的身份验证系统也是没有用的。强制使用强加密密码是防止出现此类问题的重要步骤。总之，用户和服务执行者都有责任防止密码泄露。
最后，如果不审核通过服务发生的事件，当出现否认情况时，安全的身份验证和强加密密码都是毫无意义的。当事务中存在否认威胁时，应记录这些事务及其用户、时间、日期等足够多的信息以标识事务的详细信息。否则，当出现争论时，您可能缺少足够的证据以证实您的观点。
审核、报告和监视

审核对减少否认危险程度起着重要的作用；在识别其他种类的攻击过程中，也起着关键作用。例如，如果不是您的审核记录中的统计数据表明您的服务存在异常使用情况，您可能根本意识不到您的服务正在遭受攻击。例如，您是否注意到某个人正在对登录方式进行字典攻击？所以，我们将讲述在审核、报告和监视时需要考虑的问题，以保护 XML Web 服务免受攻击。
审核的概念就是记录所发生的每个事件的所有信息。但是，当通过 XML Web 服务的数据量很大时，此想法可能是不切实际的。审核记录至少应包括所有请求的时间、日期和 IP 地址。如果 XML Web 服务经过身份验证，您需要在每个审核记录中包括用户名。如果您的服务支持多种方法或消息格式，您需要标识调用的是哪一个。最后，您需要包括足够的信息以满足您标识调用详细信息的需要。例如，如果 XML Web 服务使用了一种方法，您可能希望记录传递给该方法的所有参数。
您还需要考虑其他需要，例如当站点遭到攻击时您可能需要回滚事务。而且，您的审核记录往往是某些报告的最佳信息源。由于审核记录可能相当大，您需要协调审核设计和备份策略。
审核处理的是通过您的服务同时发生的所有事件的记录，报告则是向用户、操作员和管理员汇报系统的使用信息。报告是保护 XML Web 服务免受攻击的一个重要部分，因为通过它可以观察服务的使用情况。一种主要的报告类型是报告发生的错误。报告 XML Web 服务所遇到的错误的能力是最重要的。同样，您还需要报告那些可能指出恶意客户端企图的错误。例如，如果所接收请求中的某个参数是一个异常的长字符串，则您需要以一种容易引人注意的方式来报告该错误。对于这种类型的错误，您应该在应用程序事件日志中创建事件，这样可以相应地对它们进行监视。有关如何将事件写入事件日志的详细信息，请参阅操作系统平台 SDK 中的 Event Logging（英文）。
另一种对您的服务至关重要的报告类型是汇总服务使用情况的报告。它应该有两种形式：首先，创建供您个人进行分析的全局报告，您可以使用该报告检测使用级别或异常模式。应该对正常报告的外观具有足够的了解，这样您才能够发现异常使用的情况。其次，需要为您的用户提供报告。您的用户还应能够监视他们对服务的使用情况。很有可能出现这样的情况：在全局报告中未记录攻击行为，而个别用户却能立即在其各自的报告中发现问题。
如果 XML Web 服务正在 Internet Information Server (IIS) 上运行，那么我们就有必要提及一种能免费得到的非常有用的报告类型。即，为所有传入的 HTTP 请求（包括对您服务的请求）进行的 IIS 日志记录。您可以使用 IIS 日志中提供的信息来改进自己的报告。 '
最后，实施了审核及适当的报告方法后，您需要使用某种机制以发现所报告的问题。这就是监视。
可以以不同级别进行监视。当然，定期手动查看报告是监视 XML Web 服务的使用情况的一种方式，但是还应检查事件日志中已报告的错误，使用性能监视日志，并利用可以监视 Web 服务器停机时间的多种工具中的一种。性能监视对于检测攻击可能是非常关键的。幸好，与 IIS 关联的大量性能计数器可以为检测问题提供许多重要的统计数据。
您可能还希望为 XML Web 服务创建自己的性能计数器。有关创建您自己的性能计数器的详细信息，请参阅 Performance Monitoring（英文）。为了确保引起您对异常情况的特殊关注，应以某种形式通知您正在发生的事件，这点是非常重要的。可以在异常事件发生时，利用性能监视警报发送弹出式消息，或运行某个程序。图 1 显示的性能监视警报会监视未完成的 IIS ISAPI 请求的数量，以及当前队列中的 ASP 请求的数量。
<IMG SRC="http://www.microsoft.com/china/msdn/images/service09192001.gif" border=0>
图 1：创建性能监视警报
如果不对可能发生的问题采取一些措施，则对滥用的操作进行审核、报告和监视不会有任何用处。拒绝服务攻击可能会被定义到特定的 IP 地址，这意味着您可能需要在路由器中过滤来自该地址的请求。但是，拒绝服务攻击或电子欺骗攻击可能与 XML Web 服务的特定用户相关。您必须能够在这种问题发生时禁用帐户。完成此操作可能仅需在 Microsoft&reg; Active Directory&#8482; 中禁用 Windows 用户帐户。或者，如果使用的是自己设计的身份验证方式，则意味着必须在用户记录中添加一个可以表示禁用