企業應用Web服務安全：問題介紹(圖)

2019-11-18 12:22:47

字體：大中小

來源：轉載

供稿：網友

　　介紹：為何需要Web服務安全
　　
　　本文關于如何在企業環境中實現和應用基于Web服務安全技術(WS-Security)的安全防護方案這一系列文章的第一篇。使用訪問控制機制來保護公司的Web服務資源的安全，是企業應用的典型特征之一，此特征同其它特征一起組建企業應用環境。此系列中將要提出的針對開發安全防護方案的建議和設計多數來源于筆者在實現TransactionMinder，一個先進的Web服務安全保護系統中獲得的第一線開發經驗以及客戶的需求。筆者在此處特意作了一般化處理，使得這些思想和設計可以應用在其他可比較的安全保護系統中。
　　
　　本系列文章沒有討論到的問題
　　
　　首先，WS-Security理論基礎的方方面面以及如何使用WS-Security來保護SOAP Web服務的資料隨處可見。因此，關于WS-Security、xml安全、XML加密、XML簽名、SAML(Security Assertion Markup Language: 安全聲明標記語言)、PKI(Public Key InfrastrUCture: 公鑰基礎設施)等技術的理論基礎及一般討論請參考相關出版物以及在線資源--請參考下面的資源部分。
　　
　　當然，對于涉及到的技術，以及在討論組件實現的相關章節中提到的不同組件的目的會給出解釋，不過筆者假設讀者對這些主題有最低程度的基本理解。
　　
　　其次，許多討論如下主題的文章已經發表:
　　
　　●Web服務在業務流程自動化以及異構系統互聯等領域的良好前景
　　
　　●在上述領域中應用Web服務的障礙。首先并且最主要的是Web服務安全保護機制的(或者是覺察到的)缺乏
　　
　　此處，沒有必要重復為安全通信提供標準和工具的重要性，也沒有必要重復令人費解的安全標準制定過程以及標準發展的復雜性。
　　
　　從Internet商業化的開始階段起，就存在對于構建標準B2B自動處理鏈技術的不斷嘗試(某些做的確實不錯)。在此處理鏈中，每個Web服務參與節點需要依次扮演服務器和客戶(當它向處理鏈中的下一個節點請求服務時)的角色。從安全的觀點看，一個節點需要向下一個節點提交自己的信用標記，或者抽取并向下一個節點傳遞信用標記以聲明自己信任此信用標記。在SAML的術語中，這兩種方法分別被稱為“密鑰擁有者”(Holder-of-Key, HK)以及“發送方擔保”(Sender-Vouches, SV)，它們被用來聲明加密信息所使用的加密運算的私鑰的擁有者(請參考 "安全聲明標記語言綁定和概要" PDF文檔的第5節)。圖1中，Web服務節點A、B之間通信使用“密鑰擁有者”(HK)方法，節點B、C之間通信使用“發送方擔保”(Sender-Vouches, SV)方法。
　　　企業應用Web服務安全：問題介紹(圖)（圖一）

　　圖1. “密鑰擁有者” 請求(Holder-of-Key, HK)以及“發送方擔保”(Sender-Vouches,(SV)請求
　　
　　標記解釋：　A auto token, A的驗證標記; A public key, A 的公鑰; A signature, A的簽名; B public key, B 的公鑰; B signature, B的簽名。
　　
　　從理論轉回來，考慮當前企業軟件環境，首先需要注重的是作為Web服務保護機制的訪問控制系統(如Digital Evolution的TransactionMinder 或 Management Point　)的存在。這些保護機制普遍用于保護系統防御輸入的SOAP消息中潛伏的攻擊，因此比傳統的防火墻復雜得多。它們除提供標準防火墻功能外，還提供對于WS-Security以及相關技術的支持。
　　
　　因此，為支持實現上述的自動服務鏈，作為請求方的Web服務節點應該對輸出的信息進行適當處理，使其可以被保護目的Web服務節點的訪問控制系統所接受。
　　
　　在本系列文章的主要關注點是對于位于不同的訪問控制系統后的Web服務節點互聯問題提供(膠水)方案。這需要實現傳統的WS-Security的功能的子集，但是又略微不同。實現細節會在下面的需求部分討論，一個示例(工具包)實現會在后續的文章中展開。
　　
　　鏈條的缺失部分：問題
　　
　　顯然，企業級的訪問控制系統不會孤立存在，它們同后臺的用戶目錄服務器和訪問策略服務器連接。這些服務器可以提供用戶信用標記以及基于訪問策略做出訪問控制決定。
　　
　　典型的訪問控制系統需要處理驗證和授權任務。基于不同的配置方案，系統可以接受許多種類的信用標記。對于Web服務訪問控制系統，除其他需求外，非凡地需要支持不同的基于Web服務安全的方案。系統需要從輸入的Web服務信息頭部的WS-Security信息部分提取并使用用戶信用標記來驗證請求者。另外，如圖2所示，訪問控制系統還需要能夠修改輸入的請求信息，如添加額外的安全頭部信息，添加特定的驗證標記和簽名，以及進行消息解密等。
　　　企業應用Web服務安全：問題介紹(圖)（圖二）

　　圖2. 訪問控制系統的角色
　　
　　標記注釋： Validation, 確認； Authentication, 驗證；Authorization, 授權； policy store, 策略庫；User Directory，用戶目錄對Web服務輸出信息自動地進行安全處理以及對輸入請求的狀態信息和信用標記自動的進行提取，現有的訪問控制系統還無法做到。實現這樣功能可能需要一個非凡的復雜代理或者網關，在輸出信息輸出前對其進行修改處理。當前，這方面的工作多數集中在硬件方面(比如DataPower的 XS40 XML Security Gateway)。軟件實現，雖然提供了豐富的類似硬件代理的功能，但是實際上很有限。
　　
　　因此，企業Web服務的開發者不得不手工編寫代碼來提取信用標記并對輸出信息進行適當的安全處理。這需要對XML進行手工解析, 或者利用常見的XML簽名加密(Apache XML Security 項目，IBM XML Security Suite)、SAML(SourceID SAML 1.1 工具包 )、或者WS-Security(Apache的 WSS4J 項目, Phaos' WSSE Toolkit)等工具包。
　　
　　由于WS-Security涉及相當廣泛的技術，因此其實現必然依靠于許多外部的軟件開發包。現在可用的軟件開發包不少，不過彼此之間存在的兼容性很差，利用所有的工具包使其兼容本身就是一個大挑戰。不兼容的問題舉例如下：支持的算法集合不同、不兼容的證書格式、使用的JDK版本的沖突、依靠的XML解析器的不兼容性。
　　
　　WS-Security標準本身具有通用性，功能豐富，實現完整支持標準的通用WS-Security SDK, 將導致異常復雜的API。進而，組織內開發者基于特定需求需要對此API簡化包裝時，通常需要付出額外的開發工作。
　　
　　最后不得不提到的是，現有的安全SDK通常是自依靠的——其功能等依靠于自己提供的信用標記存儲結構及其訪問接口，對于企業現有的策略以及用戶目錄服務器等并未提供良好的掛鉤(hook)。企業開發者需要利用已有的存儲設備等基礎設施，實現新的系統需要與已有設備連接。因此，通常需要在系統中整合多種類型的信用標記存儲方案和標記格式，這意味著需要為兼容性進行多層次的封裝工作。
　　
　　目的：解決方案的需求
　　
　　這里考慮非凡的案例——作為在已有訪問控制系統下開發企業Web服務的開發者，我們并不需要一個完全支持標準的膨脹的SDK。相反，在此環境下為保護自動化處理鏈的安全，需要一個相對輕量簡單的API來幫助解決現存的方案的不足。
　　
　　在請求信息到達目的Web服務節點前，目的節點前端的訪問控制系統需要對請求信息進行特定的安全處理。非凡的處理包括首先進行的消息驗證(消息結構和完整性)，以及簽名驗證和對任何加密內容的解密等。在我們的實現中Web服務的請求輸入點上應該是(可能)附帶已經驗證的WS-Security頭部信息的有效SOAP信息，以及頭部附加的特定驗證標記。在圖3中Web服務節點B處，工具包應該協助開發者從(請求A的)輸入中提取驗證標記，構造新的(位于請求B中的)Web-Security標記，或為了滿足目標系統(Web服務節點C)的策略需求而改變已有(請求A中包含的)信用標記。
　　企業應用Web服務安全：問題介紹(圖)（圖三）

　　圖3. Web服務鏈
　　
　　開發的WS-Security工具包應該滿足的更確切需求如下：
　　
　　●現有的訪問控制系統已經使用了種類廣泛的后臺策略及用戶信息服務器。為任何工業級別應用而開發的安全工具包的一個必須特性是能夠與已有的基礎設施集成。雖然要求工具包支持所有不同來源、不同形式的基礎設施是不現實的，但是它必須提供簡單通用的適配接口，這些接口答應(通過配置)在現有工具包中添加為特定存儲提供者開發的插件來添加相應功能。
　　
　　●通過第3方SDK提供對于XML簽名、XML加密功能的支持。前面已經提到，現在有一些相應的實現。很可惜，它們的相互兼容性很差。同時為避免嚴重依靠于特定的SDK提供者和(或)其特定版本, 工具包必須開放適當的掛鉤，以便插入其它不同實現的包裝器。這些開放掛鉤的接口應位于SDK結構層次的底層，如此保有對其他SDK的供給者的最廣泛的兼容性。很幸運，上面提到，在本案例所需的密碼運算功能有限，不需要進行簽名驗證、解密、以及其他一些標準密碼運算等功能。
　　
　　●通過掛接點使用第3方SAML SDK提供的SAML標記生成功能。將實現的工具包僅關心如何正確地在消息頭部添加已生成的SAML標記(參考安全聲明標記語言　標記概要 PDF文檔 )。.
　　
　　●Web服務技術本身的異構特性決定工具包不能依靠于特定的平臺。假如需要平臺相關的特性，可以通過調用工具包公開API中的平臺封裝層來添加。
　　
　　●為降低開發工作量，選擇工具包支持的安全標記的類型時, 有必要做出的一定的限制。同時工具包的設計要合理，當需要添加并支持新的安全標記類型時，工作不會太復雜以致無法完成。也就是說，工具包的設計過程應當盡可能的抽象，同時注重擴展性。
　　
　　●最后，前面曾提到，工具包應該保持相對輕量、具有簡單的供外部調用的API，同時應該以解決當前的特定問題為導向而開發。這樣可以避免開發者學習使用另一個復雜API的負擔。
　　
　　對于企業Web服務，當前的訪問控

上一篇：安全技術 Java與安全性，第2部分二

下一篇：java非對稱加密的源代碼(RSA)