Web服务安全性问题综述

Web服务安全性问题综述1.概述现有的Web服务体系架构缺少有效的安全性支持，所以需要一个安全框架模型来解决Web服务中的各种安全问题。本文结合Web服务的基本组件和协议，说明了如何利用现有的安全技术和设施来确保Web服务的安全，并着重指出了如何在Web服务环境中添加一些基本的保护机制和安全信息。在此基础上，分析了在安全框架的指导下建立的各种应用和扩展规范，阐明了如何构建可互操作的安全的Web服务集成方案。2.Web服务概述Web服务(WebServices)是一种完全基于XML(eXtensibleMarkupLanguage)的软件技术。它提供了一个标准的方式，用于应用程序之间的通信和互操作，而不管这些应用程序运行在什么样的平台上和使用什么架构。W3C把Web服务定义为由一个URI(UniformResourceIdentifier)识别的软件系统，使用XML来定义和描述公共界面及其绑定。使用这种描述和定义，应用系统之间可以通过在互联网上传送基于XML的消息进行互操作。从使用者的角度而言，Web服务实际上是一种部署在Web上的对象/组件。通过Web服务，企业可以包装现有的业务处理过程，把它们作为服务来发布（publish）,查找和订阅其他的服务，以及在企业间交换信息和集成对方的服务。Web服务使得应用到应用的电子交易成为可能，免除了人的参与，极大的提高了效率。2.1．Web服务协议栈为了完成在松散耦合下的对象访问，Web服务定义了一系列的协议规范，如图1所示。5．服务发布/发现：UDDIManagement：管理界面4．服务描述:WSDL3．XML消息:SOAP2．传输协议:HTTP,SMTP1．Internet:ipv4,ipv6HTTP:HyperTextTransferProtocol，超文本传输协议SMTP:SimpleMailTransferProtocol，简单邮件传输协议SOAP:SimpleObjectAccessProtocol，简单对象访问协议WSDL：WebServicesDescriptionLanguage，Web服务描述语言UDDI：UniversalDescription,DiscoveryandIntegration，统一描述，发现和集成图1.Web服务协议层次其中，第1，2两层是已经定义好的并且广泛使用的传输层和网络层的标准：IP、HTTP、SMTP等。而第3，4，5三层是目前开发的Web服务的相关标准协议，包括服务调用协议SOAP、服务描述协议WSDL和服务发现/集成协议UDDI。图中右侧部分是各个协议层的公用机制，这些机制一般由外部的正交机制来完成。2.2.Web服务的调用过程利用Web服务可以建立面向服务的集成系统。这就是说，不用改变现有的各种应用，也不关心它们技术的不同(比如是java,还是.net),利用Web服务的消息驱动机制，让他们协同工作和交互。Web服务体系结构最基础的支柱是XML消息传递。目前XML消息传递的行业标准协议是SOAP，服务的调用者通过在传输层协议之上绑定SOAP消息来请求服务。图2Web服务的消息调用模式图2表示了Web服务的消息调用模型，图中省去了诸如Webserver,SOAPserver,Web服务模块的表示。他们也可能在一个中间节点上。假设SOAP绑定在http之上，那么它就会利用http的请求/响应消息模型，将SOAP请求的参数放在http请求里面，而将SOAP响应的结果放在http响应里面。Web服务的这种调用模式使得应用程序的集成更为方便，快捷，和廉价。部署的Web服务将可以随时在不同的环境下通过网络进行访问。3.Web服务的安全问题分析Web服务的关键能力是提供一种综合的，全方位的，交互的，容易集成的解决方案。目前，SSL(SecureSocketLayer)和TLS(TransportLayerSecurity)被用来提供传输层的Web服务安全，SSL/TLS在点对点（point-to-point）的会话中,可以完成包括审计，数据完整性，机密性这样的要求。网络层的IPSec对于Web服务安全来说，也是一个很重要的标准。同SSL/TLS一样，它也提供主机审计认证，数据完整性和数据机密性的功能。然而，仅有传输层和网络层的这些安全机制是远远不够的。Web服务的基本工作过程是通过发送SOAP消息到一个由URI来鉴别的服务点（由一个SOAPserver来接受消息），来请求特定的Web服务(操作)，接收到消息的响应结果或者错误提示。从图2种我们可以看到，在传输层之外，当消息数据被接受和中转的时候，数据的完整性以及其他的安全信息就可能泄漏或者丢失。这要求Web服务的请求者/提供者必须信任那些中间节点对消息的获得和处理（那些中间节点可能需要处理消息，生成新的消息）。除了消息的安全性之外，对于合法的请求方按照消息的内容作出适当的反应和行为，也即权限策略控制都是现有的安全机制无法解决的。现在SOAP通常都绑定在http上进行传送，而在常见的Web服务器(比如apache,IIS)上普遍使用的安全技术就是IP阻塞（IPblocking）。其实，它就是识别特定IP地址的过程，服务器通常保存一个禁止访问的IP地址列表。这样的安全措施显然是粗糙的，让那些潜在的客户无法访问，Web服务的接口描述(WSDL文件)他们也无法获得，更为全面的安全策略也无法实现。尤其是现在很多公司提供的Web服务都和相应的Web站点捆绑在一起，这也让那些对Web服务无效的IP地址不能正确的访问这个Web站点。所以单一的传输解决方案或者是普通的防火墙（FireWall）是无法确保服务安全性的。它们缺少下列特征：端到端的保护、不可抵赖性、选择性保护（保护消息的一部分）、灵活的认证机制以及消息层的保护。一个可能的办法是对于安全性要求不同的服务提供各种级别的SOAPserver（对应不同的URI）,那么不同的安全策略就可以被强迫执行在不同级别上。然而Web服务并非是为那些基于浏览器的手工参与的客户端准备的，它真正的优势是要实现链式的事物化的服务之间的相互调用，通过众多的SOAPserver来解决这一问题，不仅是昂贵的，也是复杂的，更为重要的是，也违背了可重用性的要求，通过Web服务描述语言(WSDL)得到的Web服务接口应该是统一的，这样才能让Web服务的机制完整的实现。概括来说，一个完整的Web服务安全解决方案应该通过利用Web服务模型核心组件的可扩展性，建立一整套的安全规范。这些规范建立在一些基础技术如SOAP、WSDL、XML数字签名（XMLDigitalSignature）、XML加密（XMLEncryption）和SSL/TLS的基础之上。让Web服务提供者和请求者在这个实用框架下，开发满足他们应用程序的特殊安全性需求的解决方案。这样的解决方案应该是把那些不兼容的安全技术，比如PKI、Kerberos和其它安全性技术能放在一起，建立一个安全模型，让那些异构的系统在改建为Web服务的时候，可以安全的互操作，同时又尽量利用已有的设施，同时这样的安全模型也可以添加到传输级别的安全解决方案之中。4.Web服务安全模型和安全规范分析Web服务面向的是机器到机器的系统集成，那些异构的系统可能会使用不同的安全机制和基础结构作为安全设施，为了以Web服务的形式对它们进行集成进而安全的互操作，这就需要一个实用的安全模型，针对实际情况允许用户开发和定制特殊的解决方案。这个模型实际上是一组原理和准则的集合。通过一组相应的规范来指导用户如何实现这个目标，比如怎么样实现消息的加密，怎么样进行不同安全令牌的交换。显然，这个模型建立在XMLSOAP的基础之上，所以如何利用SOAP协议层来构建这个模型就是一个关键问题。4.1SOAP安全问题分析4.1.1SOAP协议概览SOAP（SimpleObjectAccessProtocol）简单对象访问协议是一个轻型的分布式计算协议，它允许在一个分散、分布式的环境中交换信息，是一个基于XML的协议。作为Web服务最主要的组件，它的设计目标是简单性和可扩展性。SOAP是个跨平台的协议，每一个通过网络的远程调用都可以通过SOAP封装起来，然后被绑定在传输层协议（HTTP,SMTP）上进行传送。在形式上，它是一个XML格式的结构化封装，图3简单的表达了SOAP消息的组成。SOAP封装(envelop)定义了一个描述消息中的内容是什么，是谁发送的，谁应当接受并处理它以及如何处理它们的框架,从而实现了Web服务的耦合调用。SOAP消息一般会和实现模式结合，例如请求/响应的http模型。至于SOAP和传输层协议（比如HTTP）的绑定和映射不是本文关心的重点，但是SOAP协议的可扩展机制为实现Web服务安全提供了途径。图3SOAP协议消息结构SOAP实现了跨平台的，不依靠编程语言的，松散的Web服务调用，按照服务描述协议（WSDL）所提供的Web服务接口，封装RPC调用的各个条目，最后把他们变成固定格式的XML消息。按照w3c的SOAPxmlschema规范，这个消息头部可以包含很多适当的扩展条目。图4给出了一个简单的SOAP调用示意。*Xmlparser:xml解析器，比如apacheSOAP.图4典型的SOAP调用框架4.1.2XML加密XML加密主要是指对那些以XML格式存储或者传递的数据进行加密。SOAP消息本身是XML，所以它的安全问题可以使用XML加密来解决。不必关心用什么具体的安全技术(比如数字签名，对称私钥，非对称加密等),对于XML文档来说，加密的方式可以是整篇文档进行加密，也可以是针对某个元素（tag）或者元素的内容进行加密。W3C和OASIS以及IETF正在或者已经发布了一系列的XML安全标准。W3C和IETF共同发布了XML数字签名规范（XMLSignaturespecification），旨在解决完整性和审计功能。W3C还发布了一个XML加密规范(XMLEncryption)，规范了如何使用加密技术保证XML数据的机密性。使用的安全技术包括非队称加密(Asymmetriccryptography)，对称加密(Symmetriccryptography)，消息摘要(Messagedigests)，数字签名(Digitalsignatures)，以及证书(Certificates)。4.1.3SOAP消息中的安全集成SOAP消息的这种XML结构化封装，可以很自然的利用XML的加密技术，结合SOAP的扩展机制，把那些安全元素加入到SOAP消息中，以保证服务调用的安全（消息的机密性、完整性，用户审计认证权限策略等）。利用上面提到的两个XML安全标准，微软，IBM等公司制订了Ws-Security(Web服务安全规范说明)，已经提交给了OASIS,它针对SOAP提出了Web服务的安全实现方法，加密的数据被放进SOAP的XML标签里面。这个规范主要是用于SOAP的安全实现问题，包括在一个SOAP消息里面，如何实现数字签名，消息摘要，加密数据和加密算法等。这条SOAP消息经过对其头部(阴影部分)进行扩展，加入了数字签名后的信息，那么消息的完整性得到了保证，而且，可以确认这条消息是来自于这个公钥的持有者，也即完成了用户的审计(authentication)。除了数字签名以外，还可以使用诸如x.509证书，或者消息摘要，对称私钥加密这样的方法。4.2Web服务安全模型框架和规范从Web服务工作的基本过程来看，我们可以把保护Web服务分成对SOAP消息的安全（机密性、完整性）保护和如何让服务方对合法的消息中所声明的内容作出适当的响应（审计，权限和角色控制策略）。SOAP和链式的Web服务通常工作在一个多跳段（multi-hop）的拓扑逻辑中，所以，我们把这个模型定义为一个提供端到端（end-to-end）安全解决办法的机制，它同时能够利用传输层和应用层的安全机制来实现全面的安全能力。显然，这样可以保证和实现Web服务调用或者异构系统集成的安全。为了说明这个相对抽象的模型