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