首先，我想介绍两个非常好的新工具，它们是 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 服务对这种问题可能会更为关心，但是您应该确定您的服务可能会遇到的危险，以及在方案中应采取什么样的有效措施。
审核对减少否认危险程度起着重要的作用；在识别其他种类的攻击过程中，也起着关键作用。例如，如果不是您的审核记录中的统计数据表明您的服务存在异常使用情况，您可能根本意识不到您的服务正在遭受攻击。例如，您是否注意到某个人正在对登录方式进行字典攻击？所以，我们将讲述在审核、报告和监视时需要考虑的问题，以保护 XML Web 服务免受攻击。
审核的概念就是记录所发生的每个事件的所有信息。但是，当通过 XML Web 服务的数据量很大时，此想法可能是不切实际的。审核记录至少应包括所有请求的时间、日期和 IP 地址。如果 XML Web 服务经过身份验证，您需要在每个审核记录
