Web服務安全性問題綜述

1、Web服務安全性問題綜述1. 概述現(xiàn)有的Web服務體系架構缺少有效的安全性支持，所以需要一個安全框架模型來解決Web服務中的各種安全問題。本文結合Web服務的基本組件和協(xié)議，說明了如何利用現(xiàn)有的安全技術和設施來確保Web服務的安全，并著重指出了如何在Web服務環(huán)境中添加一些基本的保護機制和安全信息。在此基礎上，分析了在安全框架的指導下建立的各種應用和擴展規(guī)范，闡明了如何構建可互操作的安全的Web服務集成方案。2. Web服務概述Web服務(Web Services)是一種完全基于XML(eXtensible Markup Language)的軟件技術。它提供了一個標準的方式，用于應用程序之間的

2、通信和互操作，而不管這些應用程序運行在什么樣的平臺上和使用什么架構。W3C把Web服務定義為由一個URI(Uniform Resource Identifier)識別的軟件系統(tǒng)，使用XML來定義和描述公共界面及其綁定。使用這種描述和定義，應用系統(tǒng)之間可以通過在互聯(lián)網(wǎng)上傳送基于XML的消息進行互操作。從使用者的角度而言，Web服務實際上是一種部署在Web上的對象/組件。通過Web服務，企業(yè)可以包裝現(xiàn)有的業(yè)務處理過程，把它們作為服務來發(fā)布（publish）,查找和訂閱其他的服務，以及在企業(yè)間交換信息和集成對方的服務。Web服務使得應用到應用的電子交易成為可能，免除了人的參與，極大的提高了效率。 2

3、.1Web服務協(xié)議棧 為了完成在松散耦合下的對象訪問，Web服務定義了一系列的協(xié)議規(guī)范，如圖 1所示。5服務發(fā)布/發(fā)現(xiàn)：UDDIManagement：管理界面4服務描述 :WSDL3XML 消息: SOAP2傳輸協(xié)議: HTTP,SMTP1Internet :ipv4,ipv6HTTP: Hyper Text Transfer Protocol ，超文本傳輸協(xié)議SMTP: Simple Mail Transfer Protocol，簡單郵件傳輸協(xié)議SOAP: Simple Object Access Protocol ，簡單對象訪問協(xié)議 WSDL：Web Services Descriptio

4、n Language，Web服務描述語言 UDDI：Universal Description,Discovery and Integration，統(tǒng)一描述，發(fā)現(xiàn)和集成  圖 1. Web 服務協(xié)議層次其中，第 1，2 兩層是已經(jīng)定義好的并且廣泛使用的傳輸層和網(wǎng)絡層的標準：IP、HTTP、SMTP等。而第3，4，5三層是目前開發(fā)的Web服務的相關標準協(xié)議，包括服務調(diào)用協(xié)議SOAP、服務描述協(xié)議WSDL和服務發(fā)現(xiàn)/集成協(xié)議UDDI。圖中右側部分是各個協(xié)議層的公用機制，這些機制一般由外部的正交機制來完成。 2.2. Web服務的調(diào)用過程     利

5、用Web服務可以建立面向服務的集成系統(tǒng)。這就是說，不用改變現(xiàn)有的各種應用，也不關心它們技術的不同(比如是java,還是.net),利用Web服務的消息驅動機制，讓他們協(xié)同工作和交互。Web服務體系結構最基礎的支柱是XML 消息傳遞。目前XML 消息傳遞的行業(yè)標準協(xié)議是SOAP，服務的調(diào)用者通過在傳輸層協(xié)議之上綁定SOAP消息來請求服務。 圖 2 Web 服務的消息調(diào)用模式圖2表示了Web服務的消息調(diào)用模型，圖中省去了諸如Web server , SOAP server, Web服務模塊的表示。他們也可能在一個中間節(jié)點上。 假設SOAP綁定在http之上，那么它就會利用http的請求/響應消息模

6、型，將SOAP請求的參數(shù)放在http請求里面，而將SOAP響應的結果放在http響應里面。Web服務的這種調(diào)用模式使得應用程序的集成更為方便，快捷，和廉價。部署的Web服務將可以隨時在不同的環(huán)境下通過網(wǎng)絡進行訪問。 3. Web服務的安全問題分析 Web服務的關鍵能力是提供一種綜合的，全方位的，交互的，容易集成的解決方案。目前，SSL(Secure Socket Layer)和TLS(Transport Layer Security)被用來提供傳輸層的Web服務安全，SSL/TLS在點對點（point-to-point）的會話中,可以完成包括審計，數(shù)據(jù)完整性，機密性這樣的要求。網(wǎng)絡層的IPSe

7、c對于Web 服務安全來說，也是一個很重要的標準。同SSL/TLS一樣，它也提供主機審計認證，數(shù)據(jù)完整性和數(shù)據(jù)機密性的功能。 然而，僅有傳輸層和網(wǎng)絡層的這些安全機制是遠遠不夠的。Web服務的基本工作過程是通過發(fā)送SOAP消息到一個由URI來鑒別的服務點（由一個SOAP server來接受消息），來請求特定的Web服務(操作)，接收到消息的響應結果或者錯誤提示。從圖2種我們可以看到，在傳輸層之外，當消息數(shù)據(jù)被接受和中轉的時候，數(shù)據(jù)的完整性以及其他的安全信息就可能泄漏或者丟失。這要求Web服務的請求者/提供者必須信任那些中間節(jié)點對消息的獲得和處理（那些中間節(jié)點可能需要處理消息，生成新的消息）。 除

8、了消息的安全性之外，對于合法的請求方按照消息的內(nèi)容作出適當?shù)姆磻托袨椋布礄嘞薏呗钥刂贫际乾F(xiàn)有的安全機制無法解決的?，F(xiàn)在SOAP通常都綁定在http上進行傳送，而在常見的Web服務器(比如apache,IIS)上普遍使用的安全技術就是IP阻塞（IP blocking）。其實，它就是識別特定IP地址的過程，服務器通常保存一個禁止訪問的IP地址列表。這樣的安全措施顯然是粗糙的，讓那些潛在的客戶無法訪問，Web服務的接口描述(WSDL文件)他們也無法獲得，更為全面的安全策略也無法實現(xiàn)。尤其是現(xiàn)在很多公司提供的Web服務都和相應的Web站點捆綁在一起，這也讓那些對Web服務無效的IP地址不能正確的訪

9、問這個Web站點。 所以單一的傳輸解決方案或者是普通的防火墻（FireWall）是無法確保服務安全性的。它們?nèi)鄙傧铝刑卣鳎憾说蕉说谋Ｗo、不可抵賴性、選擇性保護（保護消息的一部分）、靈活的認證機制以及消息層的保護。 一個可能的辦法是對于安全性要求不同的服務提供各種級別的SOAP server（對應不同的URI）,那么不同的安全策略就可以被強迫執(zhí)行在不同級別上。然而Web服務并非是為那些基于瀏覽器的手工參與的客戶端準備的，它真正的優(yōu)勢是要實現(xiàn)鏈式的事物化的服務之間的相互調(diào)用，通過眾多的SOAP server來解決這一問題，不僅是昂貴的，也是復雜的，更為重要的是，也違背了可重用性的要求，通過Web服

10、務描述語言(WSDL)得到的Web服務接口應該是統(tǒng)一的，這樣才能讓Web服務的機制完整的實現(xiàn)。 概括來說，一個完整的Web服務安全解決方案應該通過利用Web 服務模型核心組件的可擴展性，建立一整套的安全規(guī)范。這些規(guī)范建立在一些基礎技術如SOAP、WSDL、XML 數(shù)字簽名（XML Digital Signature）、XML 加密（XML Encryption）和SSL/TLS 的基礎之上。讓Web 服務提供者和請求者在這個實用框架下，開發(fā)滿足他們應用程序的特殊安全性需求的解決方案。 這樣的解決方案應該是把那些不兼容的安全技術，比如PKI、Kerberos 和其它安全性技術能放在一起，建立一個

11、安全模型，讓那些異構的系統(tǒng)在改建為Web服務的時候，可以安全的互操作，同時又盡量利用已有的設施，同時這樣的安全模型也可以添加到傳輸級別的安全解決方案之中。 4. Web服務安全模型和安全規(guī)范分析 Web服務面向的是機器到機器的系統(tǒng)集成，那些異構的系統(tǒng)可能會使用不同的安全機制和基礎結構作為安全設施，為了以Web服務的形式對它們進行集成進而安全的互操作，這就需要一個實用的安全模型，針對實際情況允許用戶開發(fā)和定制特殊的解決方案。這個模型實際上是一組原理和準則的集合。通過一組相應的規(guī)范來指導用戶如何實現(xiàn)這個目標，比如怎么樣實現(xiàn)消息的加密，怎么樣進行不同安全令牌的交換。 顯然，這個模型建立在XML SO

12、AP的基礎之上，所以如何利用SOAP協(xié)議層來構建這個模型就是一個關鍵問題。 4.1 SOAP安全問題分析 4.1.1 SOAP協(xié)議概覽 SOAP（Simple Object Access Protocol ）簡單對象訪問協(xié)議是一個輕型的分布式計算協(xié)議，它允許在一個分散、分布式的環(huán)境中交換信息，是一個基于XML的協(xié)議。作為Web服務最主要的組件，它的設計目標是簡單性和可擴展性。 SOAP是個跨平臺的協(xié)議，每一個通過網(wǎng)絡的遠程調(diào)用都可以通過SOAP封裝起來，然后被綁定在傳輸層協(xié)議（HTTP,SMTP）上進行傳送。在形式上，它是一個XML格式的結構化封裝，圖3簡單的表達了SOAP消息的組成。SOAP

13、封裝(envelop)定義了一個描述消息中的內(nèi)容是什么，是誰發(fā)送的，誰應當接受并處理它以及如何處理它們的框架,從而實現(xiàn)了Web服務的耦合調(diào)用。SOAP消息一般會和實現(xiàn)模式結合，例如請求/響應的http模型。至于SOAP和傳輸層協(xié)議（比如HTTP）的綁定和映射不是本文關心的重點，但是SOAP協(xié)議的可擴展機制為實現(xiàn)Web 服務安全提供了途徑。 圖3 SOAP協(xié)議消息結構SOAP實現(xiàn)了跨平臺的，不依靠編程語言的，松散的Web服務調(diào)用，按照服務描述協(xié)議（WSDL）所提供的Web服務接口，封裝RPC調(diào)用的各個條目，最后把他們變成固定格式的XML消息。按照w3c 的SOAP xml schema規(guī)范，這個

14、消息頭部可以包含很多適當?shù)臄U展條目。圖4給出了一個簡單的SOAP調(diào)用示意。     *Xml parser:xml解析器，比如apache SOAP. 圖4 典型的SOAP調(diào)用框架4.1.2 XML加密 XML加密主要是指對那些以XML格式存儲或者傳遞的數(shù)據(jù)進行加密。SOAP消息本身是XML，所以它的安全問題可以使用XML加密來解決。不必關心用什么具體的安全技術(比如數(shù)字簽名，對稱私鑰，非對稱加密等),對于XML文檔來說，加密的方式可以是整篇文檔進行加密，也可以是針對某個元素（tag）或者元素的內(nèi)容進行加密。 W3C和OASIS以及IETF正在或者已經(jīng)發(fā)布了一系列

15、的XML安全標準。W3C和IETF共同發(fā)布了XML數(shù)字簽名規(guī)范（XML Signature specification），旨在解決完整性和審計功能。W3C還發(fā)布了一個XML加密規(guī)范(XML Encryption)，規(guī)范了如何使用加密技術保證XML數(shù)據(jù)的機密性。使用的安全技術包括非隊稱加密(Asymmetric cryptography)，對稱加密(Symmetric cryptography)，消息摘要(Message digests)，數(shù)字簽名(Digital signatures)，以及證書(Certificates)。 4.1.3 SOAP消息中的安全集成 SOAP消息的這種XML 結構

16、化封裝，可以很自然的利用XML的加密技術，結合SOAP的擴展機制，把那些安全元素加入到SOAP消息中，以保證服務調(diào)用的安全（消息的機密性、完整性，用戶審計認證權限策略等）。 利用上面提到的兩個XML安全標準，微軟，IBM等公司制訂了Ws-Security(Web服務安全規(guī)范說明)，已經(jīng)提交給了OASIS,它針對SOAP提出了Web服務的安全實現(xiàn)方法，加密的數(shù)據(jù)被放進SOAP的XML標簽里面。這個規(guī)范主要是用于SOAP的安全實現(xiàn)問題，包括在一個SOAP消息里面，如何實現(xiàn)數(shù)字簽名，消息摘要，加密數(shù)據(jù)和加密算法等。 這條SOAP消息經(jīng)過對其頭部(陰影部分)進行擴展，加入了數(shù)字簽名后的信息，那么消息的

17、完整性得到了保證，而且，可以確認這條消息是來自于這個公鑰的持有者，也即完成了用戶的審計(authentication)。 除了數(shù)字簽名以外，還可以使用諸如x.509證書，或者消息摘要，對稱私鑰加密這樣的方法。 4.2 Web服務安全模型框架和規(guī)范 從Web服務工作的基本過程來看，我們可以把保護Web服務分成對SOAP消息的安全（機密性、完整性）保護和如何讓服務方對合法的消息中所聲明的內(nèi)容作出適當?shù)捻憫▽徲?，權限和角色控制策略）?SOAP和鏈式的Web服務通常工作在一個多跳段（multi-hop）的拓撲邏輯中，所以，我們把這個模型定義為一個提供端到端（end-to-end）安全解決辦法的機制

18、，它同時能夠利用傳輸層和應用層的安全機制來實現(xiàn)全面的安全能力。顯然，這樣可以保證和實現(xiàn)Web服務調(diào)用或者異構系統(tǒng)集成的安全。 為了說明這個相對抽象的模型，安全模型定義了兩個概念術語：安全令牌（Security Token），這是指一組與安全相關的信息集合，比如x.509證書，或者移動終端設備中的sim卡的安全編碼；Web服務端點策略(Endpoint Policy)，這是指服務一方對自己的或者被要求的聲明（Claims）和對這個聲明必須的相關信息，比如說明自己有某種執(zhí)行權限同時給出證據(jù)（給出身份）。 這樣，我們把Web服務的安全模型建立在三個層次上：傳輸層（以下）的點對點安全，應用服務級（自定

19、義）的安全和策略，和端對端的安全性。下面的過程描述了Web服務安全模型是如何達到目的的： 1. 服務方可以要求請求者的消息證明一組聲明（例如，名稱、密鑰、許可、性能等等）。這一組聲明和相關的信息就是端點策略。 2. 請求方可以通過把安全令牌與消息關聯(lián)起來發(fā)送。這樣，消息既可以要求特定的操作又證明了發(fā)送者具有要求該操作的聲明。 3. 如果請求者無法給出必需的聲明，那么請求者或它們的代表可以通過與其它Web服務聯(lián)系設法獲得必需的聲明。這些其它的Web 服務，稱為安全性令牌服務（security token service），可以接下來要求它們自己的一組聲明。安全性令牌服務通過簽發(fā)安全性令牌代理不同

20、信任域之間的信任。圖5說明了這種情況。 圖5 Web服務安全令牌模型這個模型允許使用如X.509 公用密鑰證書、Kerberos 這樣已有的技術，還利用了傳輸層和網(wǎng)絡層的安全措施，建立更高層次的密鑰交換，認證，授權，審計和信任機制。 對于一些不兼容的技術，需要集成的時候，可以利用這個框架來實現(xiàn)不同安全技術之間的橋梁。因為根據(jù)前面提到的安全集成過程，建立在不同的安全基礎架構上的系統(tǒng)是可以通過安全令牌交換服務得到需要訪問的服務的安全令牌的。 實際上，Web服務的安全問題最終依靠的是按照上述模型制訂的一系列安全規(guī)范。安全模型只是一定意義上的問題劃分和實現(xiàn)準則。它為這些安全規(guī)范提供了方向和目標。IBM

21、和Microsoft在Web服務安全白皮書里面給出了一整套安全性規(guī)范，用于針對不同的情況，如何開發(fā)和實現(xiàn)安全機制。圖6是由IBM, Microsoft, Versign共同發(fā)布的最新安全規(guī)范情況。     注：Ws-Policy Attachments,Web服務策略附件；Policy Assertions:通用策略斷言。圖6 Web服務安全規(guī)范框架圖這些規(guī)范描述了如何實施和實現(xiàn)安全機制，也就是如何把安全功能放到Web服務的環(huán)境中去。這些規(guī)范是靈活的，可以任意匹配使用。但是可能還存在一些通用性的問題，這包括一些通用的算法和適配程序。其中Ws-security是這些規(guī)范的基礎規(guī)范，提供了把消息完整性