Web服务安全性问题综述.docx

《Web服务安全性问题综述.docx》由会员分享，可在线阅读，更多相关《Web服务安全性问题综述.docx（7页珍藏版）》请在三一办公上搜索。

1、Web服务安全性问题综述1. 概述现有的Web服务体系架构缺少有效的安全性支持，所以需要一个安全框架模型来解决Web服务中的各种安全问题。本文结合Web服务的基本组件和协议，说明了如何利用现有的安全技术和设施来确保Web服务的安全，并着重指出了如何在Web服务环境中添加一些基本的保护机制和安全信息。在此基础上，分析了在安全框架的指导下建立的各种应用和扩展规范，阐明了如何构建可互操作的安全的Web服务集成方案。2. Web服务概述Web服务(Web Services)是一种完全基于XML(eXtensible Markup Language)的软件技术。它提供了一个标准的方式，用于应用程序之间的

2、通信和互操作，而不管这些应用程序运行在什么样的平台上和使用什么架构。W3C把Web服务定义为由一个URI(Uniform Resource Identifier)识别的软件系统，使用XML来定义和描述公共界面及其绑定。使用这种描述和定义，应用系统之间可以通过在互联网上传送基于XML的消息进行互操作。从使用者的角度而言，Web服务实际上是一种部署在Web上的对象/组件。通过Web服务，企业可以包装现有的业务处理过程，把它们作为服务来发布（publish）,查找和订阅其他的服务，以及在企业间交换信息和集成对方的服务。Web服务使得应用到应用的电子交易成为可能，免除了人的参与，极大的提高了效率。 2

3、.1Web服务协议栈 为了完成在松散耦合下的对象访问，Web服务定义了一系列的协议规范，如图 1所示。5服务发布/发现：UDDIManagement：管理界面4服务描述 :WSDL3XML 消息: SOAP2传输协议: HTTP,SMTP1Internet :ipv4,ipv6HTTP: Hyper Text Transfer Protocol ，超文本传输协议SMTP: Simple Mail Transfer Protocol，简单邮件传输协议SOAP: Simple Object Access Protocol ，简单对象访问协议 WSDL：Web Services Descriptio

4、n Language，Web服务描述语言 UDDI：Universal Description,Discovery and Integration，统一描述，发现和集成 图 1. Web 服务协议层次其中，第 1，2 两层是已经定义好的并且广泛使用的传输层和网络层的标准：IP、HTTP、SMTP等。而第3，4，5三层是目前开发的Web服务的相关标准协议，包括服务调用协议SOAP、服务描述协议WSDL和服务发现/集成协议UDDI。图中右侧部分是各个协议层的公用机制，这些机制一般由外部的正交机制来完成。 2.2. Web服务的调用过程 利用Web服务可以建立面向服务的集成系统。这就是说，不用改变现

5、有的各种应用，也不关心它们技术的不同(比如是java,还是.net),利用Web服务的消息驱动机制，让他们协同工作和交互。Web服务体系结构最基础的支柱是XML 消息传递。目前XML 消息传递的行业标准协议是SOAP，服务的调用者通过在传输层协议之上绑定SOAP消息来请求服务。 图 2 Web 服务的消息调用模式图2表示了Web服务的消息调用模型，图中省去了诸如Web server , SOAP server, Web服务模块的表示。他们也可能在一个中间节点上。 假设SOAP绑定在http之上，那么它就会利用http的请求/响应消息模型，将SOAP请求的参数放在http请求里面，而将SOAP响

6、应的结果放在http响应里面。Web服务的这种调用模式使得应用程序的集成更为方便，快捷，和廉价。部署的Web服务将可以随时在不同的环境下通过网络进行访问。 3. Web服务的安全问题分析 Web服务的关键能力是提供一种综合的，全方位的，交互的，容易集成的解决方案。目前，SSL(Secure Socket Layer)和TLS(Transport Layer Security)被用来提供传输层的Web服务安全，SSL/TLS在点对点（point-to-point）的会话中,可以完成包括审计，数据完整性，机密性这样的要求。网络层的IPSec对于Web 服务安全来说，也是一个很重要的标准。同SSL/

7、TLS一样，它也提供主机审计认证，数据完整性和数据机密性的功能。 然而，仅有传输层和网络层的这些安全机制是远远不够的。Web服务的基本工作过程是通过发送SOAP消息到一个由URI来鉴别的服务点（由一个SOAP server来接受消息），来请求特定的Web服务(操作)，接收到消息的响应结果或者错误提示。从图2种我们可以看到，在传输层之外，当消息数据被接受和中转的时候，数据的完整性以及其他的安全信息就可能泄漏或者丢失。这要求Web服务的请求者/提供者必须信任那些中间节点对消息的获得和处理（那些中间节点可能需要处理消息，生成新的消息）。 除了消息的安全性之外，对于合法的请求方按照消息的内容作出适当的

8、反应和行为，也即权限策略控制都是现有的安全机制无法解决的。现在SOAP通常都绑定在http上进行传送，而在常见的Web服务器(比如apache,IIS)上普遍使用的安全技术就是IP阻塞（IP blocking）。其实，它就是识别特定IP地址的过程，服务器通常保存一个禁止访问的IP地址列表。这样的安全措施显然是粗糙的，让那些潜在的客户无法访问，Web服务的接口描述(WSDL文件)他们也无法获得，更为全面的安全策略也无法实现。尤其是现在很多公司提供的Web服务都和相应的Web站点捆绑在一起，这也让那些对Web服务无效的IP地址不能正确的访问这个Web站点。 所以单一的传输解决方案或者是普通的防火墙

9、（FireWall）是无法确保服务安全性的。它们缺少下列特征：端到端的保护、不可抵赖性、选择性保护（保护消息的一部分）、灵活的认证机制以及消息层的保护。 一个可能的办法是对于安全性要求不同的服务提供各种级别的SOAP server（对应不同的URI）,那么不同的安全策略就可以被强迫执行在不同级别上。然而Web服务并非是为那些基于浏览器的手工参与的客户端准备的，它真正的优势是要实现链式的事物化的服务之间的相互调用，通过众多的SOAP server来解决这一问题，不仅是昂贵的，也是复杂的，更为重要的是，也违背了可重用性的要求，通过Web服务描述语言(WSDL)得到的Web服务接口应该是统一的，这样

10、才能让Web服务的机制完整的实现。 概括来说，一个完整的Web服务安全解决方案应该通过利用Web 服务模型核心组件的可扩展性，建立一整套的安全规范。这些规范建立在一些基础技术如SOAP、WSDL、XML 数字签名（XML Digital Signature）、XML 加密（XML Encryption）和SSL/TLS 的基础之上。让Web 服务提供者和请求者在这个实用框架下，开发满足他们应用程序的特殊安全性需求的解决方案。 这样的解决方案应该是把那些不兼容的安全技术，比如PKI、Kerberos 和其它安全性技术能放在一起，建立一个安全模型，让那些异构的系统在改建为Web服务的时候，可以安全

11、的互操作，同时又尽量利用已有的设施，同时这样的安全模型也可以添加到传输级别的安全解决方案之中。 4. Web服务安全模型和安全规范分析 Web服务面向的是机器到机器的系统集成，那些异构的系统可能会使用不同的安全机制和基础结构作为安全设施，为了以Web服务的形式对它们进行集成进而安全的互操作，这就需要一个实用的安全模型，针对实际情况允许用户开发和定制特殊的解决方案。这个模型实际上是一组原理和准则的集合。通过一组相应的规范来指导用户如何实现这个目标，比如怎么样实现消息的加密，怎么样进行不同安全令牌的交换。 显然，这个模型建立在XML SOAP的基础之上，所以如何利用SOAP协议层来构建这个模型就是

12、一个关键问题。 4.1 SOAP安全问题分析 4.1.1 SOAP协议概览 SOAP（Simple Object Access Protocol ）简单对象访问协议是一个轻型的分布式计算协议，它允许在一个分散、分布式的环境中交换信息，是一个基于XML的协议。作为Web服务最主要的组件，它的设计目标是简单性和可扩展性。 SOAP是个跨平台的协议，每一个通过网络的远程调用都可以通过SOAP封装起来，然后被绑定在传输层协议（HTTP,SMTP）上进行传送。在形式上，它是一个XML格式的结构化封装，图3简单的表达了SOAP消息的组成。SOAP封装(envelop)定义了一个描述消息中的内容是什么，是谁

13、发送的，谁应当接受并处理它以及如何处理它们的框架,从而实现了Web服务的耦合调用。SOAP消息一般会和实现模式结合，例如请求/响应的http模型。至于SOAP和传输层协议（比如HTTP）的绑定和映射不是本文关心的重点，但是SOAP协议的可扩展机制为实现Web 服务安全提供了途径。 图3 SOAP协议消息结构SOAP实现了跨平台的，不依靠编程语言的，松散的Web服务调用，按照服务描述协议（WSDL）所提供的Web服务接口，封装RPC调用的各个条目，最后把他们变成固定格式的XML消息。按照w3c 的SOAP xml schema规范，这个消息头部可以包含很多适当的扩展条目。图4给出了一个简单的SO

14、AP调用示意。 *Xml parser:xml解析器，比如apache SOAP. 图4 典型的SOAP调用框架4.1.2 XML加密 XML加密主要是指对那些以XML格式存储或者传递的数据进行加密。SOAP消息本身是XML，所以它的安全问题可以使用XML加密来解决。不必关心用什么具体的安全技术(比如数字签名，对称私钥，非对称加密等),对于XML文档来说，加密的方式可以是整篇文档进行加密，也可以是针对某个元素（tag）或者元素的内容进行加密。 W3C和OASIS以及IETF正在或者已经发布了一系列的XML安全标准。W3C和IETF共同发布了XML数字签名规范（XML Signature spe

15、cification），旨在解决完整性和审计功能。W3C还发布了一个XML加密规范(XML Encryption)，规范了如何使用加密技术保证XML数据的机密性。使用的安全技术包括非队称加密(Asymmetric cryptography)，对称加密(Symmetric cryptography)，消息摘要(Message digests)，数字签名(Digital signatures)，以及证书(Certificates)。 4.1.3 SOAP消息中的安全集成 SOAP消息的这种XML 结构化封装，可以很自然的利用XML的加密技术，结合SOAP的扩展机制，把那些安全元素加入到SOAP消息

16、中，以保证服务调用的安全（消息的机密性、完整性，用户审计认证权限策略等）。 利用上面提到的两个XML安全标准，微软，IBM等公司制订了Ws-Security(Web服务安全规范说明)，已经提交给了OASIS,它针对SOAP提出了Web服务的安全实现方法，加密的数据被放进SOAP的XML标签里面。这个规范主要是用于SOAP的安全实现问题，包括在一个SOAP消息里面，如何实现数字签名，消息摘要，加密数据和加密算法等。 这条SOAP消息经过对其头部(阴影部分)进行扩展，加入了数字签名后的信息，那么消息的完整性得到了保证，而且，可以确认这条消息是来自于这个公钥的持有者，也即完成了用户的审计(authe

17、ntication)。 除了数字签名以外，还可以使用诸如x.509证书，或者消息摘要，对称私钥加密这样的方法。 4.2 Web服务安全模型框架和规范 从Web服务工作的基本过程来看，我们可以把保护Web服务分成对SOAP消息的安全（机密性、完整性）保护和如何让服务方对合法的消息中所声明的内容作出适当的响应（审计，权限和角色控制策略）。 SOAP和链式的Web服务通常工作在一个多跳段（multi-hop）的拓扑逻辑中，所以，我们把这个模型定义为一个提供端到端（end-to-end）安全解决办法的机制，它同时能够利用传输层和应用层的安全机制来实现全面的安全能力。显然，这样可以保证和实现Web服务调

18、用或者异构系统集成的安全。 为了说明这个相对抽象的模型，安全模型定义了两个概念术语：安全令牌（Security Token），这是指一组与安全相关的信息集合，比如x.509证书，或者移动终端设备中的sim卡的安全编码；Web服务端点策略(Endpoint Policy)，这是指服务一方对自己的或者被要求的声明（Claims）和对这个声明必须的相关信息，比如说明自己有某种执行权限同时给出证据（给出身份）。 这样，我们把Web服务的安全模型建立在三个层次上：传输层（以下）的点对点安全，应用服务级（自定义）的安全和策略，和端对端的安全性。下面的过程描述了Web服务安全模型是如何达到目的的： 1. 服

19、务方可以要求请求者的消息证明一组声明（例如，名称、密钥、许可、性能等等）。这一组声明和相关的信息就是端点策略。 2. 请求方可以通过把安全令牌与消息关联起来发送。这样，消息既可以要求特定的操作又证明了发送者具有要求该操作的声明。 3. 如果请求者无法给出必需的声明，那么请求者或它们的代表可以通过与其它Web服务联系设法获得必需的声明。这些其它的Web 服务，称为安全性令牌服务（security token service），可以接下来要求它们自己的一组声明。安全性令牌服务通过签发安全性令牌代理不同信任域之间的信任。图5说明了这种情况。 图5 Web服务安全令牌模型这个模型允许使用如X.509

20、公用密钥证书、Kerberos 这样已有的技术，还利用了传输层和网络层的安全措施，建立更高层次的密钥交换，认证，授权，审计和信任机制。 对于一些不兼容的技术，需要集成的时候，可以利用这个框架来实现不同安全技术之间的桥梁。因为根据前面提到的安全集成过程，建立在不同的安全基础架构上的系统是可以通过安全令牌交换服务得到需要访问的服务的安全令牌的。 实际上，Web服务的安全问题最终依靠的是按照上述模型制订的一系列安全规范。安全模型只是一定意义上的问题划分和实现准则。它为这些安全规范提供了方向和目标。IBM和Microsoft在Web服务安全白皮书里面给出了一整套安全性规范，用于针对不同的情况，如何开发

21、和实现安全机制。图6是由IBM, Microsoft, Versign共同发布的最新安全规范情况。 注：Ws-Policy Attachments,Web服务策略附件；Policy Assertions:通用策略断言。图6 Web服务安全规范框架图这些规范描述了如何实施和实现安全机制，也就是如何把安全功能放到Web服务的环境中去。这些规范是灵活的，可以任意匹配使用。但是可能还存在一些通用性的问题，这包括一些通用的算法和适配程序。其中Ws-security是这些规范的基础规范，提供了把消息完整性和机密性功能程序添加到Web 服务中所必需的基本元素，并且提供把安全性令牌和策略（例如，数字证书和Ke

22、rberos 票据）关联到SOAP 消息的方法（比如例2）。 策略是一个宽泛的术语，包含了诸如安全性、可靠性、事务、隐私等一系列内容。类似的，表达策略的能力也不局限于通用策略或安全性策略的表达。目的在于使基本的策略框架能够适应特定域（比如安全性）的策略语言的表达，并且适应的方式是在一个一致的Web 服务框架中利用不同域的知识。 WS-PolicyAttachments 提供了几种使用Web 服务来宣传策略断言的方式。它是在现有的WSDL 规范和UDDI 规范之上建立的，但同时支持可扩展性。WS-Policy 断言语言（WS-Policy Assertions）提供了这种类型的公共策略表达，它定

23、义了一组通用的Web 服务策略断言。 WS-Secure Conversantion 建立在以安全性令牌为基础的信任这一概念之上。它描述了如何在策略定义的信任关系上下文中使用安全性令牌来使得多个服务请求者和服务提供者能在会话期间安全地交换信息。 WS-Trust 旨在支持创建多种安全性令牌格式，以适应各种认证和授权机制。发出安全性令牌服务接受一个输入请求（通常还有身份证明），然后以指定的身份所请求的令牌（即一个特定的业务证书）作为响应。 Web服务注册中心（UDDI REGISTRY）的最新规范（v3.0）中已经开始集成了指定策略的鉴别系统，一组实现安全规范的API也被定义，UDDI本身提供的注册，查询等Web服务也开始支持诸如数字签名这样的安全机制，渐渐的取代了以前的企业间约定的信任模型。