SOAP消息監(jiān)控
基于SOAP偵聽的SOA消息監(jiān)控是構(gòu)建高效SOA安全性解決方案基礎(chǔ)的一種手段。SOAP偵聽
圖1 一個用于監(jiān)控SOAP消息的SOAP攔截器用作這個SOA中的安全性基礎(chǔ)。SOAP攔截器分析它監(jiān)控的SOAP消息的標(biāo)題頭中包含的用戶身份，并將其與保存在現(xiàn)有安全性基礎(chǔ)架構(gòu)中的名稱相比較。結(jié)果就是對SOAP消息發(fā)送方和接收方進(jìn)行了身份驗證和授權(quán)。
就是在web服務(wù)消費(fèi)者和web服務(wù)之間來回傳遞的SOAP消息的路徑中放入一個叫做“SOAP攔截器”的特殊軟件塊。因為其分類、監(jiān)控、復(fù)制和轉(zhuǎn)發(fā)包
含大量數(shù)據(jù)的SOAP消息的能力，SOAP攔截器可以在SOA安全性方面發(fā)揮重大作用。如圖7所示，一個SOA安全性解決方案“監(jiān)視”著到達(dá)web服務(wù)的
SOAP調(diào)用消息和對這些服務(wù)調(diào)用的響應(yīng)。當(dāng)它“看見”一條消息時，SOA安全性解決方案就會進(jìn)行檢查，以確保發(fā)出請求的實體是經(jīng)過身份驗證和授權(quán)可以使
用web服務(wù)的。SOA安全性解決方案通過檢查SOAP消息標(biāo)題頭中包含的數(shù)據(jù)實現(xiàn)了這一點(diǎn)。
在大多數(shù)情況下，SOA安全性解決方案是
對現(xiàn)有安全性解決方案的擴(kuò)展，而現(xiàn)有安全性解決方案是在遷移到SOA之前為保護(hù)整個企業(yè)而部署的。因此，SOA安全性解決方案很可能不得不與現(xiàn)有安全性基
礎(chǔ)架構(gòu)進(jìn)行連接和通信。如圖7所示，SOA中的用戶身份驗證和授權(quán)發(fā)生在基于企業(yè)的授權(quán)用戶數(shù)據(jù)庫檢查用戶證書的時候。偵聽SOAP消息，并把消息標(biāo)題頭
中列出的用戶與保存在現(xiàn)有安全性基礎(chǔ)架構(gòu)中的用戶進(jìn)行比較，便可實現(xiàn)身份驗證和授權(quán)。
SAML和聯(lián)邦身份驗證
當(dāng)需要
對企業(yè)外部的SOA用戶進(jìn)行身份驗證和授權(quán)時，又會怎么樣呢？SOA的開放性使得上述情況比以往任何時候都更可能出現(xiàn)。您可能會面臨這樣一個難題：在一組
在現(xiàn)有安全性基礎(chǔ)架構(gòu)中沒有記錄的用戶中，搞清楚每個用戶的身份。為了解決保護(hù)第三方過程中固有的安全性問題，SOA安全性解決方案可以使用聯(lián)邦身份驗
證。聯(lián)邦身份驗證是這樣一個過程：通過這個過程，多方可以達(dá)成一致，使用一組給定的標(biāo)準(zhǔn)來對一組指定的用戶進(jìn)行身份驗證。聯(lián)邦身份驗證方法的使用者可以創(chuàng)
建一個聯(lián)邦身份管理系統(tǒng)(Federated Identity Management
System)，這是一個已驗證用戶的庫。SOA安全性解決方案可以通過檢查聯(lián)邦身份管理系統(tǒng)來對某個用戶進(jìn)行身份驗證。換句話說，一些相互通信的系統(tǒng)的
“聯(lián)邦”，可以一致同意某個用戶是合法的。
在某些情況下，身份驗證過程會導(dǎo)致在SOA安全性解決方案中創(chuàng)建安全斷言標(biāo)記語言
（Security Assertion Markup
Language，SAML）斷言，用于以一種可為用戶調(diào)用的web服務(wù)所接受的方式表達(dá)用戶的真實性。SAML是一種基于XML的標(biāo)準(zhǔn)，它為以標(biāo)準(zhǔn)方式
描述安全性信息提供了一個框架。WS-Security是迄今為止得到認(rèn)可的安全性標(biāo)準(zhǔn)集合的總稱。許多SOA安全性解決方案都利用了這些新興的安全性標(biāo)
準(zhǔn)。如圖8所示，SOA安全性解決方案可以偵聽SOAP消息，然后使其經(jīng)過一個對用戶進(jìn)行身份驗證的過程。接下來，SOA安全性解決方案把SOAP消息傳
遞給目的web服務(wù)，但是會附加上一個SAML斷言。注意：SAML斷言不依賴于聯(lián)邦身份驗證過程。
圖2
要在SOA安全性中使用聯(lián)邦身份驗證，SOAP攔截器必須把傳入的SOAP消息轉(zhuǎn)發(fā)給安全性解決方案，該安全性解決方案再把SOAP消息標(biāo)題頭中包含的用
戶身份與聯(lián)邦身份驗證數(shù)據(jù)庫中列出的用戶進(jìn)行匹配。如果匹配成功，SOA安全性解決方案就會創(chuàng)建一個安全“斷言”，內(nèi)容是用戶已經(jīng)在安全斷言標(biāo)記語言文檔
中通過了身份驗證，該文檔是在SOAP消息到達(dá)它要調(diào)用的web服務(wù)時附加給該SOAP消息的。
應(yīng)用程序代理
一種非
常有效的保護(hù)核心系統(tǒng)的方法是避免讓任何人訪問駐留平臺的服務(wù)。可以通過為SOA中的web服務(wù)部署一個代理做到這一點(diǎn)。如圖9所示，一個受保護(hù)的代理可
以代表實際的web服務(wù)接收所有web服務(wù)請求，并對其做出響應(yīng)，從而保護(hù)web服務(wù)免遭惡意的侵害。代理方法的另一個好處在于，它能夠減輕企業(yè)安全性基
礎(chǔ)架構(gòu)的負(fù)擔(dān)。代理可以降低網(wǎng)絡(luò)流量，具體方法是集中管理和緩存對web服務(wù)請求的身份驗證和授權(quán)，而不是每次用戶想調(diào)用web服務(wù)時，就在網(wǎng)絡(luò)上使用大
量消息對該用戶進(jìn)行身份驗證和授權(quán)。代理還在消息中插入了身份驗證和授權(quán)SAML斷言，從而消除了實際web服務(wù)直接查詢安全性系統(tǒng)的需要。
契約管理
在下一章中，我們將花大量時間來講述這個主題，但是作為主要的SOA管理問題之一，契約管理同樣在SOA安全性中起著舉足輕重的作用。契約就是用于管理
web服務(wù)使用情況的一組規(guī)則。例如，某個契約可能會規(guī)定，某個特定用戶有權(quán)每天調(diào)用某個特定的web服務(wù)十次。而且在調(diào)用過程中，服務(wù)水平必須滿足特定
的參數(shù)，比如一秒鐘的響應(yīng)時間。
在安全性方面，契約有助于確定SOA是否運(yùn)行正常，或者由于違反安全性規(guī)則而誤用。如圖10所示，
SOA攔截器把web服務(wù)請求和響應(yīng)數(shù)據(jù)發(fā)送給SOA安全性解決方案，然后該SOA安全性解決方案再確定是否滿足契約。如果某個安全性問題（比如DoS攻
擊）使web服務(wù)的速度降低到契約規(guī)定的服務(wù)水平以下，SOA安全性解決方案就會警告管理方有問題存在。當(dāng)然，一次足夠嚴(yán)重的攻擊可以導(dǎo)致整個網(wǎng)絡(luò)崩潰，
但是安全性解決方案至少可以發(fā)出有問題存在的通知。
圖3 通過處理SOAP消息流量，降低企業(yè)安全性基礎(chǔ)架構(gòu)的負(fù)擔(dān)，并保護(hù)web服務(wù)免于誤用，web服務(wù)代理有助于保護(hù)SOA。
圖4 SOA安全性解決方案監(jiān)控服務(wù)水平，并在安全性問題導(dǎo)致web服務(wù)降低到契約規(guī)定的服務(wù)水平以下時發(fā)出警告。
證書、密鑰和加密
這些年來，IT領(lǐng)域先后出現(xiàn)了很多消息級的安全性技術(shù)，包括密碼術(shù)。現(xiàn)在，也可以對SOA應(yīng)用這些技術(shù)。這些過程，包括數(shù)字簽名、證書、密鑰和加密，都
可用來保護(hù)SOA。在這里我聲明一點(diǎn)：對于這4種安全性技術(shù)中的每一種，都可以寫出一本甚至是好幾本著作。請把本節(jié)看作是對與SOA相關(guān)的基于加密的安全
性的一個概述。
如果希望讓SOA擁有健壯的安全性，保證web服務(wù)的用戶都可以得到適當(dāng)?shù)纳矸蒡炞C，而未經(jīng)身份驗證的人無法讀取在
web服務(wù)及調(diào)用它們的應(yīng)用程序之間往返的信息，那么無疑需要對SOA安全性解決方案應(yīng)用功能強(qiáng)大的公鑰/私鑰加密工具。密鑰是一個具有某種特殊的數(shù)學(xué)特
性的大數(shù)（數(shù)百個數(shù)位）。盡管形式和大小各不相同，但密鑰都有一個基本屬性，即，可以與另一個密鑰進(jìn)行惟一關(guān)聯(lián)。也就是說，當(dāng)一個密鑰遇到其惟一的匹配密
鑰時，雙方都會說，“哦，就是你了，我惟一的匹配…不會再有其他的什么人了?！?/p>
惟一的密鑰對具有如下兩個基本功能：
- 因為它們是惟一的，所以它們是非常強(qiáng)大的身份驗證工具。
- 由于它們的數(shù)學(xué)特性，它們可用于創(chuàng)建經(jīng)過不可測知的過程進(jìn)行加密的惟一消息，這些消息只能被擁有惟一的匹配密鑰對的用戶所讀取。
下面講述當(dāng)兩個用戶想交換加密信息時的工作原理：用戶A創(chuàng)建一個惟一的密鑰對。然后，他在自己的系統(tǒng)中隱藏其中的一個密鑰（“私鑰”），卻把另一個密鑰
（“公鑰”）發(fā)送到用戶B可訪問的網(wǎng)絡(luò)上某處。然后，用戶B使用公鑰來加密他想要發(fā)送給用戶A的信息。實際過程涉及到大量讓我想一想就頭痛的數(shù)學(xué)知識，但
是基本上，公鑰和消息數(shù)據(jù)是通過一個加密算法來運(yùn)作的，該加密算法生成一個沒有私鑰不可能打開的加密文件。接下來，用戶B把經(jīng)過加密的消息發(fā)送給用戶A，
而用戶A則使用最初隱藏的私鑰來對加密數(shù)據(jù)進(jìn)行解密。結(jié)果，用戶A是世界上惟一一個能夠解密這些加密數(shù)據(jù)的人，因為（只有）他擁有與用戶B的公鑰匹配的惟
一私鑰。
現(xiàn)在，如果您像我一樣愛刨根問底，您可能會想，但是用戶A如何知道用戶B真的是用戶B呢？如果某位黑客侵入到用戶B的系統(tǒng)中，
并找到了他使用的公鑰，那怎么辦呢？為了回答這個有效性問題，人們使用了大量實體來確保特定用戶的真實性，并授予他們證明其真實性的數(shù)字證書。這些實體叫
做certificate authority (認(rèn)證機(jī)構(gòu)，CA)。CA的一個著名例子是VeriSign，它提供用于電子商務(wù)事務(wù)的證書。
使用密鑰、加密和證書來實現(xiàn)保密性和身份驗證的SOA安全性解決方案如圖11所示。在我們的制造商例子中，供應(yīng)商系統(tǒng)想發(fā)送一條SOAP消息給制造商的
web服務(wù)。為了做到這一點(diǎn)，制造商必須首先發(fā)送一個公鑰給CA。然后，供應(yīng)商系統(tǒng)從CA請求一個證書。供應(yīng)商收到的證書包含與制造商系統(tǒng)中存在的私鑰相
匹配的公鑰。然后，供應(yīng)商使用證書的公鑰加密其消息，然后再把消息發(fā)送給制造商。然而，和前面的例子一樣，SOA安全性解決方案偵聽消息，并使用CA檢查
證書的有效性。這可以驗證供應(yīng)商的身份。只有在通過身份驗證之后，加密后的SOAP消息才能被發(fā)送給制造商。SOAP消息到達(dá)之后，制造商就使用它的私鑰
對消息進(jìn)行解密和處理。
如果您覺得這聽起來更多地像是在發(fā)送消息，那么您想得沒錯。就像在IT的其他領(lǐng)域中一樣，SOA中的安全性會帶
來大量“開銷”。在到達(dá)目的地之前，每條消息都必須經(jīng)過好幾個地方。證書文件可能會很大，從而給網(wǎng)絡(luò)造成很大的負(fù)擔(dān)，而且整個過程往往會降低性能。但是遺
憾的是，它仍然是必不可少的。
XML加密
圖 5 在安全性SOA中使用公鑰/私鑰加密和證書的步進(jìn)式過程
圖字：
- 制造商將公鑰發(fā)送給認(rèn)證機(jī)構(gòu)，并將私鑰隱藏在自己的域中
- 供應(yīng)商從認(rèn)證機(jī)構(gòu)請求包含制造商公鑰的證書
- 供應(yīng)商向制造商發(fā)送使用公鑰進(jìn)行加密并包含證書的消息
- SOA安全性解決方案向認(rèn)證機(jī)構(gòu)發(fā)送證書，以便對供應(yīng)商進(jìn)行身份驗證
- SOA安全性解決方案向制造商發(fā)送使用私鑰進(jìn)行加密的SOAP消息
為了保留SOA的開放性，同時制訂嚴(yán)格的消息級的安全性標(biāo)準(zhǔn)，您很可能想在加密時使用XML。當(dāng)SOA安全性解決方案使用密鑰對消息進(jìn)行加密時，它會把
消息轉(zhuǎn)換為一段經(jīng)過加密的XML。消息是XML格式的，但是內(nèi)容并不可見，因為使用加密算法將其隱藏起來了。這樣做的好處在于，接收消息的系統(tǒng)可以把它當(dāng)
作XML來接收、解密和處理，而不依賴于定制或?qū)Ｓ械南鬟f標(biāo)準(zhǔn)。這樣我們就獲得了安全性，同時系統(tǒng)仍然基于開放標(biāo)準(zhǔn)。
數(shù)字簽名
數(shù)字簽名是另一種消息級的安全性形式，它是證書、密鑰和加密等安全性方法的變體。數(shù)字簽名就是附加給SOAP消息的證明真實性的數(shù)學(xué)語句。數(shù)字簽名是一
個基于密鑰的數(shù)（同樣是一個非常大的數(shù)），它對您的身份和消息內(nèi)容進(jìn)行惟一的處理，具體方法是對兩組數(shù)據(jù)（密鑰和消息）運(yùn)行一個特殊的算法。舉一個簡單的
例子，如果您的消息是“hello”而密鑰是12345，算法將處理這兩種輸入——單詞“hello”的數(shù)值和密鑰數(shù)12345——并生成第三個數(shù)，這第
三個數(shù)就是數(shù)字簽名。當(dāng)接收系統(tǒng)獲得消息和附加的數(shù)字簽名時，它可以使用密鑰來驗證以下內(nèi)容：
- 您是消息的真正創(chuàng)建者（身份驗證），
- SOAP消息在傳輸過程中沒有改變。
如果消息被改變了，那么惟一的數(shù)字簽名將不再與密鑰和用于創(chuàng)建密鑰的原始消息相匹配。數(shù)字簽名和先前描述的完整加密過程之間的區(qū)別在于，如果使用數(shù)字簽
名，不必對整條消息進(jìn)行加密。因此，系統(tǒng)的性能得到了提升。只要您不介意別人可以看到您的純文本格式的消息，那么數(shù)字簽名就可以為SOA提供高度的數(shù)據(jù)安
全性和完整性。
簽名可以是一個不可否認(rèn)性（nonrepudiation）組成部分，該特性是一個需要在SOA環(huán)境中解決的安全性重要
方面。不可否認(rèn)性是指一個組織的一種能力：驗證發(fā)生了特定的處理，并從而不給發(fā)送方提供否定進(jìn)行了處理的機(jī)會。例如，如果您針對某種商品下了一份電子訂
單，而該訂單并沒有以某種方式（比如使用數(shù)字簽名）進(jìn)行驗證，那么對方就有可能否認(rèn)收到該訂單。如果批發(fā)商的系統(tǒng)提供不可否認(rèn)性，那么批發(fā)商就可以肯定該
訂單已經(jīng)送達(dá)。
重放攻擊保護(hù)和審計
最后，SOA安全性解決方案應(yīng)該提供一種用于跟蹤SOAP請求的工具，從而降低
DoS攻擊帶來損害的可能性。通常，跟蹤特性將監(jiān)控SOAP消息的發(fā)送方及其創(chuàng)建時間。在某些情況下，SOA安全性解決方案將使用一個惟一的識別碼給
SOAP消息打上印記。如果解決方案被設(shè)置為阻塞復(fù)制消息，那么同一條消息是不可能被發(fā)送兩次的。消除這種可能性有助于降低黑客使用復(fù)制請求淹沒SOA的
可能性，這是DoS攻擊中常用的一種手法。
審計是SOAP消息跟蹤功能的進(jìn)一步發(fā)展。如果SOA安全性解決方案被配置為跟蹤消息，那么
它應(yīng)該能夠生成特定時期中SOA消息流量的使用日志和審計報告。審計有很多用途，但是在安全性領(lǐng)域中，它用于記錄所發(fā)生的事情，以便研究安全性問題并診斷
潛在的安全漏洞。這類日志已經(jīng)成為實現(xiàn)管理目標(biāo)（比如對Sarbanes-Oxley法案的服從）所必不可少的。
明智的管理人員所給出的忠告：不要讓安全性嚇倒了您
SOA安全性是一個很大的主題。我可以就這個主題寫一本書。（事實上，這是一個不錯的主意…）在本章中，我的目的是提供一個概述，好讓您可以評估自己對
這個主題所掌握的信息。如果您是一位企業(yè)主管，我的建議是，要避免被安全性問題嚇倒。人們很容易被安全性嚇倒，安全人員也不例外，這阻止了他們做些實際工
作以消除對于安全性問題的恐懼。實際上，我本來可以提出一個您正在考慮的IT解決方案，并讓您了解到圍繞該解決方案的大量安全性噩夢，這些噩夢足以使您遠(yuǎn)
離該解決方案。
相反，我建議您尋求安全性方面的高質(zhì)量建議，并探討企業(yè)中已經(jīng)實施了哪些。如果您這樣做，那么您的企業(yè)就很可能會擁有一
個（或一些）相當(dāng)健壯的安全性系統(tǒng)。實施SOA的難點(diǎn)在于如何把現(xiàn)有的安全措施擴(kuò)展成為由SOA構(gòu)成的web服務(wù)。許多SOA安全性解決方案的設(shè)計目的就
是為了與現(xiàn)有的安全功能有效互連。如果實現(xiàn)的話，安全性風(fēng)險可能稍微易于管理一些，而您也可以繼續(xù)實施您的計劃了。
結(jié)束語
安全性是SOA中的一個焦點(diǎn)問題，因為SOA強(qiáng)調(diào)機(jī)器與機(jī)器的交互，而大多數(shù)IT安全性都是基于人與機(jī)器的交互。身份驗證和授權(quán)在這個環(huán)境中變得更加富
于挑戰(zhàn)性。在未受保護(hù)的SOA中，想要阻止web服務(wù)的未授權(quán)使用實際上是不可能的；未授權(quán)用戶可以非常輕松地訪問web服務(wù)。Web服務(wù)不具備跟蹤誰在
使用它們或者誰被允許使用它們的固有功能。無法阻止不必要的監(jiān)聽和消息偵聽。未受保護(hù)的SOA讓黑客有機(jī)會監(jiān)聽SOAP消息并看到私密信息。此外，在未受
保護(hù)的SOA中，偵聽SOAP消息并（出于危害和欺騙的目的）重新發(fā)送消息或轉(zhuǎn)換消息內(nèi)容要相對容易一些。
由于SOA架構(gòu)的開放性本
質(zhì)，您無法保護(hù)SOA中未知的第三方。第二級和第三級用戶（例如您的合作伙伴的合作伙伴）是可以訪問未受保護(hù)的SOA的。因此，未受保護(hù)的SOA很容易超
負(fù)荷運(yùn)轉(zhuǎn)。如果沒有訪問控制，未受保護(hù)的SOA很容易被來自黑客的大量SOAP消息所“淹沒”。結(jié)果可能導(dǎo)致DoS攻擊損害系統(tǒng)的正常功能。最后，您還沒
有處理記錄。未受保護(hù)的SOA無法跟蹤其用戶或消息。因此，沒有可用于研究安全性問題或診斷安全性漏洞的可審計使用記錄。
存在一些可以
解決所有這些問題的預(yù)打包和定制的SOA安全性解決方案。在分析SOA安全性需求時，可以考慮實現(xiàn)一個支持SOAP消息監(jiān)控、聯(lián)邦身份驗證、應(yīng)用程序代
理、契約管理、證書、密鑰和加密以及審計記錄的SOA安全性解決方案。這個清單似乎很長，但是事實上，如果缺少其中任何一項，SOA的所有優(yōu)點(diǎn)都可能遭到
破壞。
SOAP消息監(jiān)控利用了一個SOAP攔截器模型，以便在將SOAP消息從調(diào)用系統(tǒng)發(fā)送給web服務(wù)時對其進(jìn)行偵聽和監(jiān)控。
SOAP消息監(jiān)控是SOA安全性的基礎(chǔ)，因為它讓安全性解決方案能夠停止和分析每條消息，以進(jìn)行用戶身份驗證和授權(quán)。為了保護(hù)第三方，安全性解決方案可以
利用聯(lián)邦身份驗證。應(yīng)該通過一個聯(lián)邦身份驗證過程提供對系統(tǒng)中的用戶進(jìn)行身份驗證的能力。最終將獲得一個為web服務(wù)的用戶提供可信身份驗證的SAML斷
言。
Web服務(wù)應(yīng)用程序代理在實際的web服務(wù)中接收和處理SOAP請求，從而對安全性有所幫助。它可以使所有的用戶都遠(yuǎn)離實際的服務(wù)。代理不僅可以減輕網(wǎng)絡(luò)的負(fù)載，還可以為SOA提供一個額外的安全性層。
契約管理是另一項對安全性有所幫助的SOA管理特性。契約確立了誰有權(quán)使用web服務(wù)以及何時可以使用它。契約通過消除非契約方的使用，提高了SOA的安全性。
對于一個真正安全的SOA來說，證書、密鑰和加密同樣是必不可少的。最健壯的SOA安全性都源于實現(xiàn)了使用來自認(rèn)證機(jī)構(gòu)的私鑰/公鑰進(jìn)行身份驗證的加密
消息傳遞。XML加密允許web服務(wù)用戶發(fā)送保留XML格式的加密SOAP消息。因此，系統(tǒng)實現(xiàn)了安全性，但卻仍然基于標(biāo)準(zhǔn)。數(shù)字簽名是加密模型的一種變
體，它使得web服務(wù)的用戶可以創(chuàng)建一個惟一確認(rèn)的數(shù)字“簽名”，其用途有二：驗證用戶身份和確保消息數(shù)據(jù)的完整性。
最后，為了跟蹤SOA的使用，有必要采用可以保存所有SOAP消息請求和響應(yīng)的動態(tài)審計日志的SOA安全性解決方案。審計日志對于在SOA中研究安全性問題和診斷安全性漏洞，以及實現(xiàn)管理規(guī)章服從性，都是必需的。