SOA安全：允许的安全技术 接驳云计算

　　在本文中，我们将讨论如何在SOA中部署安全措施。在此之前，我们先了解一下什么是SOA，SOA是一种涉及应用程序(即“服务”)架构方法。最初，SOA中的服务是与很多技术相关的，包括SOAP、WSDL以及UDDI。然而，很多基层开发者随后证明REST(表象化状态转变)比SOAP信息更加优先，这也使REST现在成为SOA被接受的部分。Web2.0的发展以及REST在Web2.0的广泛运用更加巩固了REST在SOA世界的地位。最近，云服务(如Amazon的SQS)以及一些本地服务可能会被用来创建一种“混合的”SOA环境。所有这一切的结果就是，SOA现在已经结合了原先的 SOAP/REST/UDDI、REST服务以及云计算。从专业的安全角度来看，SOA必须受到保护。

　　那么为什么要在SOA部署安全措施呢?明显的答案就是需要保护SOA基础设施免受攻击。这是个不错的理由，当然也包括很多其他原因，例如检测SOA 中服务的用法的功能等。我们将从针对SOA技术(SOAP和REST)的攻击开始探讨，然后，哪些标准(如WS-Security等)是允许用于SOA 的，最后探讨企业将本地应用与云计算服务混合时的安全问题。

　　SOA威胁

　　在SOA中，主要有哪些影响XML和REST的基于内容的威胁呢?在XML方面，存在几种公开的攻击，例如XML Entity-Expansion和SQL注入式攻击。

　　1 SQL注入式攻击

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

　　在SOA中能实施成功的SQL注入式攻击需要两个先决条件：

　　--SOA中服务接受的数据被直接插入SQL语句中

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

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

　　2 抓取-重放攻击

　　想象一下这种情况：SOA中的服务受到协议的保护，以确保服务请求进行了数字签名。这虽然看起来很安全，但真是这样吗?这种系统很容易受到重放攻击，只需简单的重新播放有效的签名信息，就能进行未经授权的访问。

　　解决这种问题的答案涉及时间戳的使用。WS-Security标准就能够支持时间戳，而网络服务协议(WS-Policy)可以用来掌控信息中出现的签名时间戳，那么重放的信息时间戳如果过期就会被系统侦测到。用户必须认真制定时间戳信任间隔，因为只有当这个间隔足够短，这样攻击者才没有时间捕捉，破解和重放有效签名信息。但是时间戳信任间隔又必须足够长，以便在网络服务系统时钟和网络服务请求之间细微的差别不会导致有效信息被阻拦。

　　3 XML外部实体攻击

　　“XML外部实体攻击”主要是利用这样一个事实：外部数据可以通过DTD(文件类型定义)被嵌入到XML文档中。通过指定一个本地文件，某些XML 引擎就可以从本地文件系统中访问未经授权的信息。请注意SOAP不允许使用DTD。

　　4 XPath注入攻击

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

　　5 XML拒绝服务(XDOS)

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

　　6 SOAP附件攻击

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

　　7 XML签名差异攻击

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

　　8 REST Web 2.0和SOA

　　尽管SOA最初是和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这个词本身是两种商业模式，免费和收费合二为一的混合词。

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

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

　　身份验证和标准

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

　　密码，X.509证书和WS-Security

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

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

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

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

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

　　所有这些已经存在的安全技术都会继续应用在SOA之中。

　　WS-Security

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

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

　　XML网关

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

　　SOA安全的未来以及与云计算的结合运用

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

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

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