售后服务W服务安全性问题综述.docx

售后服务W服务安全性问题综述.docx

《售后服务W服务安全性问题综述.docx》由会员分享，可在线阅读，更多相关《售后服务W服务安全性问题综述.docx（9页珍藏版）》请在冰豆网上搜索。

售后服务W服务安全性问题综述

（售后服务）W服务安全性问题综述

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．服务发布/发现：

UDDI

Management：

管理界面

4．服务描述:

WSDL

3．XML消息:

SOAP

2．传输协议:

HTTP,SMTP

1．Internet:

ipv4,ipv6

HTTP:

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服务调用或者异构系统集成的安全。

为了说明这个相对抽象的模型，安全模型定义了俩个概念术语：

安全令牌（SecurityToken），这是指壹组和安全关联的信息集合，比如x.509证书，或者移动终端设备中的sim卡的安全编码；Web服务端点策略（EndpointPolicy），这是指服务壹方对自己的或者被要求的声明（Claims）和对这个声明必须的关联信息，比如说明自己有某种执行权限同时给出证据（给出身份）。

这样，我们把Web服务的安全模型建立于三个层次上：

传输层（以下）的点对点安全，应用服务级（自定义）的安全和策略，和端对端的安全性。

下面的过程描述了Web服务安全模型是如何达到目的的：

1.服务方能够要求请求者的消息证明壹组声明（例如，名称、密钥、许可、性能等等）。

这壹组声明和关联的信息就是端点策略。

2.请求方能够通过把安全令牌和消息关联起来发送。

这样，消息既能够要求特定的操作又证明了发送者具有要求该操作的声明。

3.如果请求者无法给出必需的声明，那么请求者或它们的代表能够通过和其它Web服务联系设法获得必需的声明。

这些其它的Web服务，称为安全性令牌服务（securitytokenservice），能够接下来要求它们自己的壹组声明。

安全性令牌服务通过签发安全性令牌代理不同信任域之间的信任。

图5说明了这种情况。

图5Web服务安全令牌模型

这个模型允许使用如X.509公用密钥证书、Kerberos这样已有的技术，仍利用了传输层和网络层的安全措施，建立更高层次的密钥交换，认证，授权，审计和信任机制。

对于壹些不兼容的技术，需要集成的时候，能够利用这个框架来实现不同安全技术之间的桥梁。

因为根据前面提到的安全集成过程，建立于不同的安全基础架构上的系统是能够通过安全令牌交换服务得到需要访问的服务的安全令牌的。

实际上，Web服务的安全问题最终依靠的是按照上述模型制订的壹系列安全规范。

安全模型只是壹定意义上的问题划分和实现准则。

它为这些安全规范提供了方向和目标。

IBM和Microsoft于Web服务安全白皮书里面给出了壹整套安全性规范，用于针对不同的情况，如何开发和实现安全机制。

图6是由IBM,Microsoft,Versign共同发布的最新安全规范情况。

注：

Ws-PolicyAttachments,Web服务策略附件；PolicyAssertions:

通用策略断言。

图6Web服务安全规范框架图

这些规范描述了如何实施和实现安全机制，也就是如何把安全功能放到Web服务的环境中去。

这些规范是灵活的，能够任意匹配使用。

可是可能仍存于壹些通用性的问题，这包括壹些通用的算法和适配程序。

其中Ws-security是这些规范的基础规范，提供了把消息完整性和机密性功能程序添加到Web服务中所必需的基本元素，且且提供把安全性令牌和策略（例如，数字证书和Kerberos票据）关联到SOAP消息的方法（比如例2）。

策略是壹个宽泛的术语，包含了诸如安全性、可靠性、事务、隐私等壹系列内容。

类似的，表达策略的能力也不局限于通用策略或安全性策略的表达。

目的于于使基本的策略框架能够适应特定域（比如安全性）的策略语言的表达，且且适应的方式是于壹个壹致的Web服务框架中利用不同域的知识。

WS-PolicyAttachments提供了几种使用Web服务来宣传策略断言的方式。

它是于现有的WSDL规范和UDDI规范之上建立的，但同时支持可扩展性。

WS-Policy断言语言（WS-PolicyAssertions）提供了这种类型的公共策略表达，它定义了壹组通用的Web服务策略断言。

WS-SecureConversantion建立于以安全性令牌为基础的信任这壹概念之上。

它描述了如何于策略定义的信任关系上下文中使用安全性令牌来使得多个服务请求者和服务提供者能于会话期间安全地交换信息。

WS-Trust旨于支持创建多种安全性令牌格式，以适应各种认证和授权机制。

发出安全性令牌服务接受壹个输入请求（通常仍有身份证明），然后以指定的身份所请求的令牌（即壹个特定的业务证书）作为响应。

Web服务注册中心（UDDIREGISTRY）的最新规范（v3.0）中已经开始集成了指定策略的鉴别系统，壹组实现安全规范的API也被定义，UDDI本身提供的注册，查询等Web服务也开始支持诸如数字签名这样的安全机制，渐渐的取代了以前的企业间约定的信任模型。