本文我们讨论的是面向服务体系架构（SOA）的安全应用。在展开讨论之前，首先让我们来解析面向服务体系架构的实际含义。面向服务体系架构是一种涉及若干以服务为导向的应用软件的体系架构。最初面向服务体系架构中的服务与一系列技术相关，包括SOAP, WSDL和UDDI。不过许多研发人员对REST（表象化状态转变，简称REST）服务显示出更大的兴趣，由此REST成为面向服务体系架构中广为接受的组成部分。由于REST被广泛应用于Web 2.0软件，因此Web2.0的兴起也巩固了REST在面向服务体系架构领域中的地位。最近云服务（诸如亚马逊在线的简单查询服务SQS）也开始和本地服务并驾齐驱，共同创建混合面向服务体系架构环境。所有这些使得面向服务体系架构成为包含最初的SOAP/REST/VDDI堆栈，REST服务和云的集合体。从安全应用的专业角度来看，所有这些都必须得到安全保障。

　　提及面向服务体系架构安全，首先要问的是为什么。为什么要对面向服务体系架构实施安全保障呢？毋庸置疑的答案就是要保护面向服务体系架构不受攻击。这是一个合理的理由，但是应用面向服务体系架构安全还有其他不可忽视的动因，诸如监控面向服务体系架构中服务的使用。我们首先从审查面向服务体系架构技术（包括SOAP和REST）的攻击漏洞开始。然后我们将审核诸如WS-Security等安全标准如何应用到面向服务体系架构，如何通过协议实现控制使用和监控，最后我们将检查企业在整合本地网站应用软件和云计算服务时可能产生的安全隐患。

　　面向服务体系架构风险综述

　　在面向服务体系架构中影响XML和REST服务的内容风险是什么？在XML里，有几种大家所熟知的攻击风险，诸如XML Entity-Expansion和SQL注入式攻击。

　　SQL注入式攻击

　　在面向服务体系架构中，SQL注入式攻击会将SQL碎片插入XML数据，然后将错误的数据返回，或者制造泄露数据库访问信息的错误。

　　在面向服务体系架构中能实施成功的SQL注入式攻击需要两个先决条件：

　　--面向服务体系架构中服务接受的数据被直接插入SQL Statement。

　　--SQL Statement在执行攻击时有足够的优先权

　　为了避免受到攻击，必须确保从可疑用户处接受的数据不会直接插入SQL Statement。对接受的文件内容执行内容验证和风险侦测以便进行防范。

　　捕捉-重放攻击（Capture-replay attack）

　　想象一下：面向服务体系架构中的服务受到协议的保护，服务请求需要数字签名。这看起来很安全，但结果真是这样吗？答案是这种系统存在重放攻击的弱点，系统只需简单的重新播放验证的签名信息就能实现未经授权的访问。

　　解决这种问题的答案涉及时间戳的使用。网络服务安全性（WS-Security）标准就包括对时间戳的支持。网络服务协议（WS-Policy）可以用来掌控信息中出现的签名时间戳，因此重新播放的信息时间戳过期就会被系统侦测到。用户必须认真制定时间戳信任间隔。这个间隔必须足够短，只有这样攻击者才没有时间对验证信息进行捕捉，破解和重放。但是时间戳信任间隔又必须足够长，以便在网络服务系统时钟和网络服务请求之间细微的差别不会导致验证信息被阻隔。

　　XML外部实体攻击（External Entity Attack）

　　所谓的XML外部实体攻击是通过DTD（文件类型定义）入口将外部数据嵌入到XML文档中。通过指定一个本地文件会产生某些XML引擎，通过本地文件系统访问未经授权的信息。请注意SOAP不允许使用DTD。

　　XPath注入（XPath Injection）

　　XPath注入式攻击与SQL注入类似，它被用于从XML数据库中窃取信息。如果能确保进入XPath的数据本身不包含XPath，那么XPath注入攻击就能被阻断。

　　XML拒绝服务（XDOS）

　　这种攻击包含了文件类型定义的特性，即攻击可以进入DTD定义的实体。通过递归进入实体，攻击者可以制造在内存中爆炸的XML信息（因此这个术语也被称之为"XML炸弹"），从而导致拒绝服务。

　　有害的SOAP附件

　　像电子邮件信息一样，SOAP信息也包含附件。如果这些附件很大而且很难打开，那么它可能含有病毒或者其它危险。解决这个问题的方案是确保SOAP附件可以基于MIME类型进行阻断和过滤，或者通过病毒扫描进行侦测。

　　XML签名差异攻击（Signature dereference attack）

　　XML签名包括指向签名数据的参考要素。解析应用软件必须对参考URI解除参照。XML签名标准陈述如下："XML签名应用软件必须能够解析URI语法。我们推荐在HTTP中对URI进行参照解除"。不过如果参考数据是伪造的就会带来风险。

　　REST，Web 2.0和面向服务体系架构

　　尽管面向服务体系架构最初是和SOAP，WSDL和VDDI三者联系在一起的，但许多研发人员宁愿使用REST服务，因为REST更加接近网站上的浏览器界面。Web 2.0的蓬勃发展对其起到了推波助澜的作用，因为丰富互联网应用软件（RIS）就是利用REST服务将数据从网络服务器传递到浏览器。能利用Web 2.0的技术包括浏览器端的JavaScript，多数称之为REST网络服务的部分都是在服务器端发生的。举例来说，Flickr网站包括在浏览器中运行的JavaScript脚本，我们称之为服务器端的网络服务，可以对照片进行更名。为了撤销XML或者JSON（JavaScript目标符号）数据，客户端的"AJAX"（非同步JavaScript和XML）可以召回服务器上的网络服务。这种行为不是同步发生的，用户无需浏览新的网页。

　　在Web 2.0的世界中，这成为攻击关键点的后端网络服务。有时这种网络服务被定义为Web 2.0的"大型攻击界面"。攻击者会试图通过它的客户端界面攻击应用软件，或者他们会简单的绕过后端网络服务界面长驱直入。

　　问题依然存在

　　在这点上，很多读者可能会认为"这和传统的网络应用软件并没有实质不同，因此为什么要对它单独进行安全保障？"，毕竟在Web 2.0 环境中，用到的是网络浏览器和网络服务器，涉及的是一个用户。确实当数据在网络浏览器和网络服务器之间传输时，对SQL注入或者交叉脚本的攻击迹象进行数据扫描就可以了。当XML在网络上，你就必须对XML拒绝服务或者XPath注入等攻击也进行扫描。另外，保证译码安全也同样重要。浏览器上的丰富应用软件承担着增强安全译码的职责。如果攻击者将JavaScript脚本插入递归下行至浏览器的数据，那么交叉脚本也是可能的。因为许多Web 2.0的脚本交叉都取决于服务于客户的JavaScript。带病毒的JavaScript传播的可能性就会变为现实。因此也必须进行侦测和隔离。

　　Freemium模式和数据被盗的风险

　　所谓的Freemium网络服务指的是免费提供的基础服务，如果有特殊需求或者增强型服务再另行收取额外费用。Freemium这个词本身是两种商业模式，免费和收费合二为一的混合词。

　　允许某些在面向服务体系架构中的服务在Freemium模式下运行是很很吸引眼球的，因为它提供了一种付费商业模式的途径。不过这种模式的实用性更加复杂。 Freemium模式要预先设定面向服务体系架构安全框架，这个框架能够侦测服务的过度使用，强迫用户对使用的服务进行付费。使用服务必须通过验证以便系统能侦测到某个特别用户过度使用了服务，从而要求用户进行付费。通常Freemium模式是使用研发人员代号来实现的。这些代号是嵌入在网络服务符号库中的，能传递给所提供的服务。举例来说，用户可以使用搜索服务来寻找特定的点，但是他们无法在不被察觉的情况下进行数据搜索，系统会要求他们进行付费。

　　当用户在面向服务体系架构中实行Freemium服务模式时，企业可以选择编译自定义代码来执行，或者使用非定制的产品来实现，诸如XML网关。XML网关的优势是在无需改变实际代码的前提下就能更改模式中的参数。XML网关也能对我们前文所讨论的攻击进行扫描，诸如病毒代码注入。

　　身份验证和标准

　　了解是谁在使用面向服务体系架构中的服务是很重要的，使用这些信息进行访问控制和通过审计跟踪维护信息安全也是如此。对服务的访问控制服务也要利用各种不同的标准，某些标准是X.509证书类型的，某些是SAML和网络服务安全这样的新标准。重要的是我们不要被这些标准所蒙蔽，特别是当他们以一种复杂的方式组合在一起时。

　　新与旧：密码，X.509证书和网络服务安全（WS-Security）

　　密码的使用已经由来已久。目前在面向服务体系架构安全中依然应用广泛。在很多情况下只是HTTP验证这种简单的问题，可以通过SSL传递出去以便密码不会被泄露。事实上即使是使用了数字签名验证，密码的泄露也很难完全避免，因此为了阻隔特定的捕捉-重放攻击，SSL还应该别使用。尽管通过SSL进行HTTP验证是一项古老的技术，但它在面向服务体系架构的点对点身份验证中依然应用广泛。

　　X.509证书被应用于SSL验证中，网络服务可以向客户证明它的身份，或者在双向SSL中，客户还能向服务证明自己的身份。在这种情况下身份验证是没有定形的，因为网络服务交叉性经常会涉及应用程序与应用程序的对话。由此这里的验证也是对应用程序的验证。这些情况都是使用X.509证书，信任也是基于X.509证书的发行者（即授权机构，简称CA）。

　　和SSL一样，X.509证书经常会用于数字签名。XML签名是定义XML数据如何使用与X.509证书吻合的私人密钥来进行数字签名的标准，这样任何持有X.509证书签名方的用户都可以对签名进行验证。

　　XML加密也是一项定义XML数据如何加密的标准。或许你会问"在加密XML数据和加密其他类型数据之间有什么不同？"，答案是XML数据可以有选择性的进行加密，比如说有选择性的对医疗记录中患者姓名进行加密。由于面向服务体系架构中的信息多数都是XML的（REST和用于Web 2.0的JSON除外），XML加密在隐私保护方面非常有用。

　　Kerberos也是一项成熟的技术，能继续应用在面向服务体系架构安全中。特别是Kerberos经常会用于Windows环境中，因为它也加强了Windows网络中的身份验证和单一签名安全。

　　所有这些已经存在的安全技术都会继续应用在面向服务体系架构安全之中。

　　网络服务安全（WS-Security）

　　网络服务安全是在2004年才实施标准化的一项新兴技术，它是在先前技术的基础上建立起来的。它是定义XML加密和XML签名如何应用到SOAP的标准，这样SOAP信息就可以被加密或者签名。另外，它还定义了密码和X.509证书在SOAP信息中的位置，SOAP如何与Kerberos共同运作。使用网络服务安全标准可是实现不同应用程序之间的协同工作。

　　诸如Suns Glassfish和微软.NET这样的平台都能与网络服务安全标准相结合。这些技术能处理签名XML（使用网络服务安全标准的XML签名），身份验证（使用密码，Kerberos或证书）和加密（使用网络服务安全标准的XML加密）。

　　XML网关

　　XML网关能通过提供网络上的安全处理和硬件加速来保障面向服务体系架构的安全。XML网关将安全协议应用到需要保护的面向服务体系架构服务。它代表的是位于真实网络服务前端的虚拟服务。这些虚拟服务可以被提速，还可以包括在真实面向服务体系架构服务之前发生的过渡服务。举例来说，XML网关可以呈现在真实 SOAP网络服务前端的REST界面。用这种方法，XML网关通常能提供协议调解，信息过渡，硬件加速以及安全。

　　面向服务体系架构安全到云的未来

　　根据内部应用软件到网络应用软件的概念进行定义，面向服务体系架构目前正在寻找与云计算的连接。由亚马逊在线，Force.com和谷歌等提供的服务都是这种全球性面向服务体系架构。他们能提供多种网络服务，通常都可以通过与应用软件结合的REST和AJAX界面来实现访问。

　　目前占据主导地位的方式是混合模式，即在本地面向服务体系架构上的服务和云上的服务混合使用。举例来说，本地应用软件可能已经将销售数据从数据库中导出，然后将其放在 TIBCO Rendezvous查询中。Force.com中召回的数据在放入Rendezvous查询之前可能会被用于丰富数据。另一个例子是本地应用软件使用亚马逊S3服务来进行存储。

　　在连接到云上的本地面向服务体系架构的混合模式中，很重要的一点是确保没有私人数据被传输到云上。也可以通过对传输到云上的数据进行选择性加密来实现安全保障。另外，网络中断或者云服务故障不会经常影响到本地应用软件也很重要。用户可以使用XML网关作为本地“Cloud Broker”来控制从本地面向服务体系架构到云上的连接。