為什么傳統的安全措施不適合SOA
原創【51CTO.com獨家翻譯】許多企業正在開始投向SOA的懷抱，使之作為一個增加應用軟件靈活性以及整合更易于管理，更低開發成本，更統一的技術體系的方案。SOA的吸引力在于：它把公司的IT基礎設施分解成服務，每一個服務實現了一個可供用戶或者服務消費的商業過程。
舉個例子，某個服務可能會暴露添加一個新雇員到雇員工資名單和福利系統中的功能。為了使服務在多種環境中可用，也為了降低成本和增加處理的一致性，每一個服務都提供一個契約（contract）來描述它如何被使用及包含的功能。
但是，SOA方法和今天企業使用的傳統安全方法截然不同。SOA服務的“混合和匹配”（mix-and-match）的性質，以及它使用消息作為SOA的復合應用程序的協調機制，使得企業無法建立明確邊界和安全屏障。非常特別的一點是，SOA的靈活性反而也增加安全風險。
服務契約（Service contract）會暴露你的寶藏
讓我們來考察一下典型的服務是怎樣在典型的SOA基礎設施上執行的：用戶和服務的通信依賴于彼此間通過ESB（企業服務總線）傳遞的消息。ESB作為企業的消息管道，需要理解可用的服務，它們的語義和怎樣在點和點之間獲取一個應用程序的消息。每一個在ESB上的服務必須使用ESB的標準消息傳遞協議（通常是SOAP）來尋址。
為了使服務易于使用，每一個服務必須有一個方法來描述自身以及服務是怎樣被使用的。這個描述被稱為服務契約（Service contract），并通常通過WSDL（網絡服務描述語言）來描述。很少有像SOA這樣嚴格執行交互契約的開發方法。為了簡化收集和發現新的契約，在許多SOA構架中，每一個服務提供給客戶詢問和找回契約的方法。這個找回契約的方法常常是標準化的，不是由應用程序框架供應商操作，就是由SOA從業者自己操作。
標準化的契約和契約找回方法使SOA系統更加容易被攻擊者發現，因此這些都是SOA潛藏著的新的安全風險。
雖然這種免費提供的契約非常有助于開發商為整個企業構建新的服務和重用現有的服務，但不幸的是，有利于開發商的元素同樣也有利于想要了解企業及其服務的攻擊者。攻擊者可以收集這些契約，并利用它們輕易地創建一個企業內部的“藏寶圖”。為了確定高價值目標，攻擊者可以使用這種“地圖”，并審查那些認證薄弱的、或者負責高價值服務（如安全管理）的契約。
SOA從業者可以通過在認證或離線分配時禁用匿名發布服務契約來禁止攻擊者建立這樣一張地圖。雖然這是一個很實在的安全決定，但它并不適用于所有服務和所有企業。這是因為限制契約的分配會使得合法用戶更難發現服務，還使得開發工具無縫引入契約變得更加不可能。
消息層安全反而有助于攻擊者找到入侵的途徑
具有諷刺意味的是，消息層安全的使用和另一個SOA的漏洞相關。消息層安全使開發人員能夠挑選出消息中需要簽署或加密的部分。為了支持尋址和ESB上的路由，郵件的目的地信息往往被排除在該郵件的加密部分。選擇性加密/簽名的方式不同于其他點到點或傳輸層安全協議，諸如保護整個連接的SSL。
由于有了消息層安全，攻擊者通過被動地監控網絡可以獲取在發送者和接受者之間傳遞的關于應用層消息的深入信息。有選擇地應用安全增加了復雜性，開發人員或管理員對特定消息實施關鍵安全保護失敗的可能性也會增加。——51CTO王文文：駭客可以用Sniffer工具監控網絡，但加密的數據會對他們造成一些麻煩。
在某些環境下，服務信息的暴露可能不會存在高風險，但也不能掉以輕心。攻擊者獲得的信息越多，攻擊就越有具有針對性。在SOA以前，通過使用廣泛的協議來實現分離的系統還具有一定的模糊性，在這樣一個環境中攻擊者很難發現和理解所有的系統，然而SOA卻消除了這一障礙，反而大大提高了攻擊者執行探測的能力。
中介信息的使用增加了潛在的攻擊目標數
SOA改變單一軟件為自我包含的軟件的情況，可以根據需要精心配制相應的組件，這使系統變得更加動態。為了協調這些組件，SOA推薦當消息在ESB上傳送時使用消息路由器和服務注冊。為了消息路由器能夠操作消息，要么讓部分的消息不能加密，要么郵件路由器必須能夠解密關鍵信息。這種方法意味著你不能在服務提供商和服務客戶之間使用傳輸層安全協議。同時它還意味著，黑客可以利用這些管理信息和協調中介機構來對終端發起攻擊。——51CTO王文文：對安全有過研究的朋友應該知道Man-in-the-middle Attacks中間人攻擊吧？
乍一看，你可能認為在“以明碼傳遞路由信息”和“在SSL一類的協議報文中以明碼表示IP和TCP頭”并沒有多大的不同。但這實際上卻很不相同：作為中介的SSL在保證整個信息已簽名和加密的條件下，只提供關于消息流內容很少的信息，并且不允許中介進行“轉發信息”以外的操作。但是作為中介的SOA通常更進一步，而且往往在簽名還未失效的情況下就對信息本身進行了修改。在攻擊者試圖改變SOA環境時，這種操縱窗口給攻擊者提供了一個可用的工具。
的確，在消息安全上，WS-Security可以提供類似SSL的保障，但WS-Security標準的靈活性和復雜性卻增加了“消息中的敏感信息不能被恰當加密和完整保護”的風險。
同樣，服務注冊表是有風險的中介機構，SOA方法依賴它來工作的。它們類似于DNS提供服務的方式，當一個服務消費者希望找到適當的服務供應商，消費者從服務注冊表找到該服務提供者的當前地址。在許多部署方式中，服務注冊表可以由管理員或由提供者動態地更新。這為SOA可以更容易的重新配置，因為服務的地址會隨著服務地址而相應的改變。
但是，正是配置控制功能使服務注冊表成為了對攻擊者來說有吸引力的目標。例如，黑客可以操縱注冊表返回地址，讓其指向被黑客攻擊的服務主機的地址。如果攻擊者鎖定了正確的服務（如安全服務），攻擊者可以給嘗試使用安全服務的客戶偽造客戶響應。在一個客戶端的部署中，已證明能夠劫持安全服務，并完全批準所有的訪問請求。
部署一個安全、動態的SOA，開發者和架構者必須考慮系統的哪些部分需要動態處理、哪些部分需要保持靜態。使的重配置生效的 SOA的配置元素 必須再次審查，從而使得攻擊者無法全面了解系統的信息。
在ESB內部和ESB直接的通訊為攻擊者提供了新的切入點
任何重大SOA部署的中心都是一個能夠處理消息路由、并提供所需基本服務的ESB。通常情況下，企業會使用數個通過網橋連接的ESB。
不管你有一個還是多個ESB，只要是使用了ESB就無法安裝傳統的“軟”防火墻，這使ESB成為一個攻擊目標——特別當它是關鍵服務（如記錄和認證）的主機時。“軟”防火墻是當連接方沒有使用相同的協議時對通信所采取人為限制。因此，即使攻擊者登錄了某個系統，協議的不兼容將限制其攻擊范圍。例如，攻占了Web服務器的攻擊者可能無法到達大型主機，因為大型主機使用令牌網協議，而在TCP / IP網上的Web服務器并沒有把二者連接起來。
ESB的目的是為了消除通信障礙，這意味著如果部署了SOA攻擊者可以很容易的從Web服務器到達大型主機。同樣，SOA再次有利于攻擊。
ESB高連通性使得內部、外部和ESB服務的部署更加需要一個堅實的應用程序安全措施。在把那些防護脆弱的傳統大型機連接到ESB上時，需要審查其安全屬性，從而確保該系統能夠在充滿威脅的環境中運行。你需要站在攻擊者的角度，考查在你的SOA中所實現的全新通訊環境，并對攻擊可能從一個被攻克的服務器中蔓延開來的距離進行建模，然后再制定出一個緩解方案，從而控制和制止攻擊的蔓延。
部署類似于SOA這樣靈活的系統是一種真正的安全挑戰，但如果你從一開始就采取正確的步驟，保證系統的安全性也不是一件不可能的事情。
【51CTO.COM 獨家翻譯，轉載請注明出處及作者！】
【編輯推薦】
