XML WebService 安全篇

XML Web Service 安全性

　　鉴于安全性涉及诸多方面（例如身份验证和授权、数据隐私和完整性等），以及 SOAP 规范中根本没有提及安全性这一事实，我们不难理解人们为什么认为答案是否定的。但是，请不要低估了 Microsoft? XML Web Service。如今，您可以采取许多措施来创建安全的 XML Web Service。

　　要解决 XML Web Service 的安全性问题，我们需要考虑以下问题：

　　要达到什么样的目的？- 仅允许授权用户访问 XML Web Service；禁止他人未经授权擅自查看消息等。
如何达到预期效果？- 网络、传输层、OS、服务或应用。

　　解决方案中需要什么级别的互操作性？- 局部或全局。

　　那么，我们如何确保当今 XML Web Service 的安全呢？答案就是：先回答上述问题，然后应用保护任何其他 Web 应用程序时所使用的相同技术，即：

　　保护连接安全

　　对交互操作进行身份验证和授权

　　正如您下面将要了解到的，这些技术提供了多种选择，您可以将这些选择结合起来以获得额外的效果。例如，可以将防火墙与 XML Web Service 一起使用，从而根据客户端的身份以及为他们所建立的相应规则来限制对某些功能（方法）的访问。

　　让我们先来回顾一下保护现有基础结构的各种选择，了解它们的功能。

　　保护基础结构的安全

　　一个安全的 XML Web Service 的核心是安全基础结构。Microsoft 提供了广泛的技术，如果把这些技术与总体安全保护计划结合起来，企业就可以有效地保护其 IT 结构的安全。正确实施的规划过程包括：

　　详细了解潜在的环境危险（例如病毒、黑客和自然灾害）。

　　对与危险有关的安全漏洞的后果进行预先分析并制定对策。

　　在这种理解和分析的基础上，创建一个精心规划的实现策略，将安全保护措施应用到企业网络的各个方面。

　　保护连接安全

　　保护 XML Web Service 安全的最简单的一种方法就是确保 XML Web Service 客户端与服务器之间的连接安全。根据网络的范围和交互操作的活动配置文件，我们可以通过多种技术来达到这一目的。最流行也最广泛使用的三种技术为：基于防火墙的规则、安全套接字层 (SSL) 和虚拟专用网络 (VPN)。

　　如果您确切知道哪些计算机需要访问您的 XML Web Service，则可以使用防火墙规则将访问限制在已知 IP 地址的计算机范围内。如果需要限制对专用网络（例如公司的 LAN/WAN）中的计算机的访问，并且不用担心将消息内容保留为秘密（加密），那么这种技术非常有用。防火墙（例如 Microsoft Internet Security and Acceleration [ISA] Server）可以提供先进的基于策略的规则，这些规则可以根据客户端的原始位置或标识，对不同的客户端提供不同的限制。当不同的客户端访问相同 XML Web Service 上的不同功能（方法）时，这种技术很有用。

　　安全套接字层可用于在非托管网络（例如 Internet）上建立安全连接。SSL 可以对客户端和服务器之间发送的消息进行加密和解密。通过加密数据，您可以防止消息在传送过程中被读取。SSL 先对客户端的消息进行加密，然后将其传送到服务器。服务器接收到消息后，SSL 将对其进行解密并验证消息是否来自正确的发送者（此过程称为身份验证）。服务器或者客户端和服务器可能具有证书，这些证书用作身份验证过程的一部分在连接加密的顶层提供身份验证功能。虽然 SSL 是创建安全通信的一种非常有效的方法，但应当考虑其性能成本。Microsoft XML Web Service 既支持客户端中的集成 SSL，也支持服务器中的集成 SSL。

　　虚拟专用网络是专用网络的扩展，它可以连接共享网络或公共网络（如 Internet）。VPN 使您可以在两台安全连接的计算机之间发送数据。VPN 与 SSL 相似，但 VPN 是一个长期的点对点连接。这使 VPN 可以高效安全地应用于 XML Web Service，但要求建立长期的连接并保持运行才能达到这种效果。

　　身份验证和授权

　　身份验证：身份验证就是验证标识的过程，即验证某人（或某物）与其声称的人（或物）是否一致。该人或物称为“当事者”。身份验证要求证据，称为“凭据”。例如，客户端应用程序可以将密码用作凭据。如果客户端应用程序提供正确的凭据，则认为它与所声称的人或物一致。

　　授权：完成对当事者标识的身份验证后，便可以进行授权了。服务器通过检查有关当事者的某些访问控制信息（例如访问控制列表 [ACL]）来确定访问权限。客户端可能具有不同的访问级别。例如，某些客户端可以完全访问 XML Web Service；而其他客户端则只能访问某些操作。某些客户端可以完全访问所有数据，某些客户端只能访问数据的子集，而某些客户端只能进行只读访问。

　　在 XML Web Service 中实现身份验证的一个简单而直接的方法是，利用信息交换所使用的协议的身份验证功能。对于大多数 XML Web Service 来说，这意味着利用 HTTP 的身份验证功能。将 Microsoft Internet Information Server (IIS) 和 ISA 服务器与 Windows 2000 服务器配合使用，能为 HTTP 提供多种身份验证机制的集成支持。

　　基本身份验证 - 使用客户端的非安全或半安全标识，因为用户名和密码是以 base64 编码文本发送的，而该文本易于解码。如果凭据能与有效的用户帐户匹配，IIS 将授予客户端访问 XML Web Service 的权限。
SSL 上的基本身份验证 - 与基本身份验证相同，唯一区别在于通信通道被加密，从而保护了用户名和密码。对 Internet 方案而言，这是一个很好的选择，但使用 SSL 会对性能产生很大影响。

　　简要身份验证 - 使用散列以安全方式传送客户端凭据。但是，这种方法可能不会受到用于构建 XML Web Service 客户端的开发人员工具的广泛支持。如果凭据能与有效的用户帐户匹配，IIS 将授予客户端访问 XML Web Service 的权限。

　　集成 Windows 身份验证 - 主要用于 Intranet 方案。使用 NTLM 或 Kerberos。客户端必须属于服务器所在的域，或者属于服务器域的托管域。如果凭据能与有效的用户帐户匹配，IIS 将授予客户端访问 XML Web Service 的权限。

　　SSL 上的客户端证书 - 要求每个客户端获取一个证书。证书被映射至用户帐户，IIS 将使用这些证书来授权对 XML Web Service 的访问。尽管目前数字证书尚未广泛使用，但这仍然不失为 Internet 方案的一种可行选择。这种方法可能不会受到用于构建 XML Web Service 客户端的开发人员工具的广泛支持。只能通过 SSL 连接使用这种方法，因此性能可能是一个需要考虑的问题。

　　从 XML Web Service 实施者的角度来看，使用上述任何一种身份验证机制都有一个好处，即，无需在 XML Web Service 中进行代码更改，因为在调用 XML Web Service 之前，IIS/ISA 服务器将执行所有的身份验证和 ACL 授权检查。但是，在执行客户端时，还需要完成其他一些工作。客户端应用程序需要响应服务器的身份验证凭据请求。

　　在 XML Web Service 中进行身份验证的其他方法包括：使用第三方服务（例如 Microsoft? .NET Passport 中的服务），使用 Microsoft ASP.NET 的会话功能，或者创建自定义身份验证方法。

　　下一步：互操作性

　　您可能会发现，如今，用于 Web 应用程序安全保护的标准技术可以单独使用或组合使用，以建立安全的 XML Web Service。这些技术建立在丰富的经验基础之上，并且非常有效。不过，它们并没有在 XML Web Service 体系结构中提供集成解决方案。随着 XML Web Service 方案日益复杂（例如跨托管边界以及分布于多个系统或企业中），XML Web Service 实施者需要创建有效但并不提供普遍互操作性的自定义解决方案。

　　为满足这些需要并增强 XML Web Service 的互操作性，Microsoft 及其合作伙伴正在制定一套安全规范。该规范建立于 SOAP 规范的扩展性机制之上，提供集成至 XML Web Service 结构中的增强型安全保护功能。

　　这套安全规范的核心是 XML Web Service 安全语言 (WS-Security)，它为 SOAP 消息提供了三种增强功能：凭据传送、消息集成和消息保密。这些功能自身不能提供完整的安全保护解决方案；但 WS-Security 是一个构建块，它可以与基础结构和其他 XML Web Service 协议结合使用，以满足各种应用程序的安全保护要求。Microsoft Global XML Web Service 体系结构是 WS-Security 和相关规范的主要内容，它为 XML Web Service 基础结构的发展提供框架。

为Web Services设计安全架构

Web services是一种技术，它承诺通过应用与驱动Web革命相同的基于XML的技术，使系统集成发生革命性的变化。然而，尽管许下了这个庄严的誓言，Web services技术还是经常被人误解。主要的原因在于它的名称本身，“Web services”暗示着是“在World Wide Web上提供的服务”。然而事实上，第一波Web services正隐退到防火墙之后，用于把后台系统链接在一起。大多数企业没有意向在不久的将来跨防火墙发送XML。那么，这个因素是否意味着安全不是问题呢？不幸的是，答案是否定的。让我们看一看Web services带来的安全性挑战，现今如何使用安全架构来解决它们，以及当XML穿过防火墙时，如何针对未来的需要扩展前述安全架构。
　　首先，让我们回顾一下什么是Web services，以及为什么它们会带来安全性挑战？Web services是允许应用程序使用XML相互通信的一组技术。简单对象访问协议（Simple Object Access Protocol，SOAP）规范描述了通过给XML数据应用封套（envelope），从而在应用程序之间发送这些XML消息的方法。SOAP原本计划用作在对象之间发送函数调用的一种方式，因此才使用这个首字母缩写词。然而，从SOAP 1.2开始，“SOAP”不再代表它原来的意义，因为它的用途已经扩展，远不止用于在软件对象之间进行通信这么简单。SOAP正逐渐确立自己的合适定位，即作为应用程序之间的消息传送系统，也就是应用程序的e-mail。
　　SOAP消息一般是基于标准的Web协议通过HTTP发送的。在过去的5年中，安全套接字层（Secure Sockets Layer，SSL）已经广泛用作用于HTTP的安全技术。通过使用X.509数字证书进行加密和身份验证，SSL可以为HTTP流量提供机密性。另外，有许多授权工具控制对Web站点的访问，并跨Web站点管理单点登录会话。这些年来，Web services和Web应用程序已经暴露出许多安全问题，这些问题均被完整地记录在案，而且也出现了大量的最佳实践信息，用于描述如何解决和补救这些问题。考虑所有这些信息，对于保护Web services来说，现有的安全解决方案，比如SSL、Web访问控制工具和频繁地打补丁是否已经足够？答案是否定的。让我们看一看上述方案都不如SOAP的三个安全性原因。

三个安全问题
　　为什么使用SSL尚不足够? 尽管SOAP经常基于HTTP发送消息（术语称为“绑定到HTTP”），但是它不一定非得如此。SOAP是独立于底层通信层的。SOAP消息也可以基于e-mail（即简单邮件传输协议）或FTP（就像早期的做法那样）进行发送。事实上，因为HTTP是无状态的，并非完全可靠，许多企业都没有意向使用它来传输SOAP消息。
　　在一个事务环境中，对一条简单的SOAP消息可以使用多种不同的传输方式——例如，对传输的第一段使用HTTP，然后对下一段使用SMTP，等等。正如我们看到的那样，SSL为单个点到点HTTP会话提供机密性和身份验证，但它不提供用于保证会话发生的审核追踪（audit trail）。
　　针对这个问题的解决方案是将安全性应用给SOAP消息本身，而不是依赖于发送SOAP消息时使用的传输协议。这种解决方案确保即使是基于不安全的传输协议发送SOAP消息，或者如果它通过几段不被信任的服务器，也仍然是安全的。记住，我们把SOAP链接到应用程序之间的e-mail，以e-mail类推在这里也成立。如果在Internet上发送e-mail消息，仅仅对e-mail服务器之间的链接进行加密是不够的。必须对e-mail消息本身进行加密。SOAP消息也是如此。万维网联盟（World Wide Web Consortium，W3C)和结构化信息标准促进组织（Organization for the Advancement of Structured Information Standards，OASIS）已经为此目的制订出一些新的规范。XML Signature和XML Encryption描述了如何强制实现XML文档的完整性和机密性，而WS-Security则把这些XML安全技术应用到SOAP消息。
　　谁要访问这个Web services? SOAP请求是由应用程序，而不是人生成的。然而，安全决策通常依赖于人的身份。设想一种情况，保险中介对在索赔门户中使用的密码进行身份验证，然后使用请求索赔信息填写一个Web表单（参见图1）。SOAP消息代表代理从索赔门户被发送到许多保险公司。保险公司使用传输层安全对SOAP请求的发送者（即索赔门户）进行身份验证。然而，如果保险公司要求具有能够查看谁是代理或者关于代理的属性信息的能力，应该怎么办呢？安全环境必须从使用密码身份验证的最终用户扩展到使用SOAP消息运行的Web services。这里的安全难题是将有关最终用户的安全信息插入到SOAP消息中。该信息涉及到代理的身份验证状态，已授权他们执行的操作，以及可用于进行访问控制决策的其他代理属性。

图 1. 基于身份的决策

　　传输层安全对SOAP请求的发送者进行身份验证。正如我们这个代理保险公司的例子中指出的那样，安全环境必须从使用密码身份验证的最终用户扩展到使用SOAP消息运行的Web services。安全难题是将有关最终用户的安全信息插入到SOAP消息中。
　　OASIS发布的安全断言标记语言（Security Assertion Markup Language ，SAML）规范描述了如何把这类信息作为关于最终用户的断言格式化到XML中，而且OASIS中的WS-Security小组正在定义如何把这些断言放入SOAP消息。企业已经拥有目录和用户配置文件，它们希望通过重用这些来保护对Web services的访问。
　　将坏人拒之门外。可以将XML Signature、XML Encryption、WS-Security和SAML这样的技术视作Web services安全的正面，这些新的规范和协议将当前的安全技术扩展到了XML世界。相反，保护不受新类型的黑客攻击就是负面。如果要求用户按照其角色行事，Web services和Web services安全工具就是无用的。如果一个使用SAML和WS-Security的完善身份验证系统运行在一个Web services上，而CodeRed攻击可以禁用该Web services，那么这个身份验证系统就是无用的。
　　Web services面临的大多数新威胁实际上过去就已存在，比如由编程错误和配置失误引起的缓存溢出，但是攻击SOAP的手段却是新的。传统上，防火墙可以保护开放源代码促进会（Open Source Initiative，OSI）堆栈的下层不受攻击。防火墙的功能已经逐渐向上移动到OSI堆栈的应用层。对于防火墙来说，针对SOAP的智能能力意味着基于消息的内容和格式过滤SOAP消息，具体方法是依靠XML Schema定义和XPath语句来验证它们。

防火墙有哪些功能?
　　许多防火墙的配置只运行Web（HTTP、SSL）和e-mail（POP、SMTP）流量通过。其他TCP/IP端口和其他协议均被封锁。有效地伪装成普通的Web流量，然后通过Web端口（HTTP使用80端口，SSL使用443端口）连接到其他应用程序已经成为标准的实践。这类伪装通常出于恶意的目的，而不是实用的目的，因为所有其他端口均被封锁。
　　我们已经明白，SOAP经常绑定到HTTP。当防火墙检查一个通过HTTP接收到的SOAP请求时，它可能断定这个请求是有效的HTTP流量，并让其通过。当面对SOAP时，防火墙往往要么不起作用，要么全部拦截，而这样做不好。SOAP级别的防火墙应该能够：1)识别进入的SOAP请求是不是以计划给请求者使用的Web services为目标，2)识别进入的SOAP消息的内容对目标Web services是否有效。该第二项功能类似于网络层的功能，即网络层检查IP包的内容，以确保它们适合于要访问的网络服务。然而，在应用层，这个过程需要精确地了解Web services期望的XML数据的格式和内容。XML Schema 和Web services描述语言（Web servicesDescription Language ，WSDL）可以提供这类精确的信息。
　　Web services在WSDL文件中表示它们接口的详细信息，该文件有效地假定，“此处给出我期望从你处收到的请求的描述”，吸引黑客发送给它不正确的数据，看看会发生什么事情。WSDL文件可能包含如下行：

<xsd:element name= "tickerSymbol" type="string"/>

　　这一行表明Web services期望的参数之一是一个字符串，叫做tickerSymbol。对此Web services进行的可能攻击包括，发送给它许多而不是一个字符串，或者发送给它一个非常大的字符串，目的是使该Web services过载。因此，在被定向到Web services的入站数据进行完整性检查（sanity check）是很重要的。这类检查的形式可能是检查XML Schema的SOAP参数。

选择架构
　　对于Web services安全有三种主要的架构选择。XML Gateway、Interceptor和自定义编码的XML Gateway——有时候称为XML防火墙或XML代理——是用于过滤Web的XML流量并在未授权流量到达受保护Web services之前阻塞它的软件包或应用程序（参见图2）。XML Gateway实施访问控制规则，具体方法是处理包含在进入的SOAP消息中的安全性标记，以及确保XML格式和内容对于目标而言是正确的。它可以使用SAML建立最终用户的身份验证状态，或者请求用于做出访问控制决策的属性信息。有一点很重要，即XML Gateway包含用于现有安全技术的安全性适配器，这些技术包括LDAP 目录、传统的防火墙和PKI。另外，把规则和用户配置文件重新嵌入到XML Gateway 中所带来的开销是不被允许的。XML Gateway 应该尽可能地重用已经预先配置用户、组和角色的安全性基础架构。

图2. XML Gateway 架构

　　XML Gateway——或者XML防火墙或XML代理——是用于过滤Web services的XML流量，并在未授权的流量到达受保护的Web services之前阻塞它的软件包或工具。
　　单个XML Gateway可以保护许多Web services平台。XML Gateway不必与目标Web services共享一个操作系统，因为它们位于单独的主机之上。这种独立性意味着基于Linux的XML Gateway工具可以保护基于.Net和Java 2 Platform，Enterprise Edition（J2EE）的混合Web services。XML Gateway经常执行转换功能和安全功能。在XML世界中，这项功能等同于实现XSLT。
　　可以选择的另一种架构是在Web services平台上部署Interceptor。这些轻量级的Interceptor使用特定于平台的钩子，比如ISAPI Filters、JAX-RPC处理器或Apache Axis处理器。接着，Interceptor（有时称为“代理”）与集中式的XML安全服务器进行通信，该安全服务器负责处理安全规则（参见图3）。与XML Gateway的选择相比，这个架构将安全性实施放在更靠近Web services应用程序的地方。就像在XML Gateway场景中一样，它集中了安全性处理，这意味着Web services应用程序没有深陷在处理器密集型的功能（如加密）中。此外，就像XML Gateway架构一样，Interceptor架构为SOAP流量提供一个管理和报告的集中点。Interceptor架构与Gateway架构安全的区别在于，它的安全是在Web services端点自身上实施的，而不是要求XML流量从基础架构架设备通过以获得保护。

图3. Interceptor架构

　　Interceptor或代理与负责处理安全规则的集中式XML安全服务器进行通信。与XML Gateway选择进行比较时，Interceptor架构将安全性实施放在了离Web services应用程序更近的地方。
　　第三个选择是在Web services自身中编写安全代码。.Net通用语言运行库（Common Language Runtime，CLR）包括XML Signature、XML Encryption和WS-Security的实现。程序员编写以.Net为宿主的Web services时可以使用这项功能。类似地，J2EE环境也包含开发人员可用的安全功能。用于自定义编码的参数是熟悉的“构建还是购买”的权衡。尽管Gateway和Interceptor模型为集中式管理和报告提供针对多个Web services进行全局修改的能力，但是如果编写特定于平台的解决方案，则必须定制这项功能。当然，编写您自己的解决方案可以免去软件许可证方面的费用，而且可能对拥有大批IT员工的企业来说更有意义。
　　无论选择何种解决方案，有一点很重要，即它并不限于第一代的、企业内部的Web services，在合适的时候，还可以将其应用于B2B Web services。在企业内部中部署可能对于学习Web services十分有用，但是如果要将一个不同的安全解决方案用于B2B Web services，那么前面的学习都将白费。Web services面临着新的安全问题，但是新的行业标准和新的XML安全产品将会解决这些问题。涉及XML安全性时，要选择架构，尽可能早地做出这些抉择是很重要的。