iweroulsdjf

保護面向服務(wù)的體系結(jié)構(gòu)（service-oriented architecture，SOA）中的應(yīng)用程序具有挑戰(zhàn)性，因為 SOA 的松耦合特性可能暴露現(xiàn)有安全實現(xiàn)的弱點。以下解決方案包括定義明確的信任模型（基于可接受的驗證形式），并糅合了策略、Web 服務(wù)安全性和安全工程最佳實踐。

引言

對于任何應(yīng)用程序來說，保護信息訪問的安全都是最基本的要求。由于按 SOA 原則構(gòu)造的實現(xiàn)的服務(wù)、應(yīng)用程序以及跨組織操作的松耦合，因此安全對其甚至更為重要。這種環(huán)境往往會暴露現(xiàn)有安全實現(xiàn)的弱點或局限性。

即使不考慮通過由模型驅(qū)動的開發(fā)和基于 SOA 的服務(wù)管理所提高的效率，業(yè)務(wù)應(yīng)用程序仍須保護信息。只保護周邊設(shè)施（如防火墻和路由器）是不夠的，因為隨需應(yīng)變的企業(yè)必須能夠隨著其合作伙伴、客戶和雇員之間的關(guān)系發(fā)展而建立和斷絕動態(tài)信任關(guān)系。因此，安全的隨需應(yīng)變企業(yè)需要靈活的、可自定義的基礎(chǔ)設(shè)施，以適應(yīng)新要求和規(guī)章制度。要提供這種靈活性，不應(yīng)將策略生搬硬套到基礎(chǔ)設(shè)施中；應(yīng)該通過由策略驅(qū)動的基礎(chǔ)設(shè)施滿足安全模型的要求，這任務(wù)可不簡單。

本文將闡釋業(yè)務(wù)應(yīng)用程序利用隨需應(yīng)變安全基礎(chǔ)設(shè)施的安全功能的方式，以及建立用于保護面向服務(wù)的應(yīng)用程序的編程模型的設(shè)計原則。

業(yè)務(wù)應(yīng)用程序和安全基礎(chǔ)設(shè)施

安全集成以及對業(yè)務(wù)應(yīng)用程序和信息的訪問通常是通過身份驗證、授權(quán)和責(zé)任實現(xiàn)的。企業(yè)探討管理身份驗證、授權(quán)和責(zé)任的方式在很大程度上取決于其對客戶、雇員和合作伙伴之間的信任關(guān)系的看法；這些關(guān)系對業(yè)務(wù)應(yīng)用程序安全的影響；以及這些應(yīng)用程序的相對重要性和安全性。

在業(yè)務(wù)合作伙伴之間交換敏感信息時，敏感信息必須受到保護。可能還需要用安全的方式保存敏感信息。必須保證消息源的完整性（如通過公證服務(wù)）才能在必要時啟用驗證、審核和認可。可能需要對敏感信息進行加密以實現(xiàn)機密性，或?qū)ζ溥M行數(shù)字簽名以實現(xiàn)完整性。（數(shù)字簽名也可用于認可。）完整的 SOA 設(shè)計必須不但涵蓋消息級和傳輸級安全性，而且還要滿足保護保存的內(nèi)容以遵守政府規(guī)章制度和業(yè)界最佳實踐的需要。

安全策略的制定和執(zhí)行以及所執(zhí)行的安全級別，基本上都取決于企業(yè)及其雇員、客戶和合作伙伴之間的信任關(guān)系。證書和密鑰之類的相關(guān)技術(shù)可用于反映和管理這些信任關(guān)系。工具可用于建立業(yè)務(wù)合作伙伴、客戶和企業(yè)等之間的信任關(guān)系模型并指定信任關(guān)系，還可以將信任定義轉(zhuǎn)換成適用于 IT 環(huán)境的技術(shù)。

SOA 安全模型

SOA 安全模型基于 Web 服務(wù)可能需要其中的傳入消息以驗證一系列聲明的過程。名稱、密鑰、權(quán)限和功能都是聲明的例子。根據(jù)所提供的證據(jù)，會在請求者、服務(wù)端點和一系列可能的中介之間應(yīng)用適當(dāng)?shù)男湃文Ｐ汀?/p>

消息可能會通過請求者和目標(biāo)服務(wù)之間的若干中介。端到端安全性必須考慮到請求者、中介和最終端點服務(wù)（提供者）之間的信任模型，如圖 1 所示。

對于消息處理，網(wǎng)絡(luò)和傳輸中介（如防火墻、路由器和代理服務(wù)器）一般不受信任。應(yīng)該防止傳輸中的所有消息受到不可靠中介的篡改。

OASIS Web 服務(wù)安全性（Web Services Security，WSS）規(guī)范提供對傳輸中的簡單對象訪問協(xié)議（Simple Object Access Protocol，SOAP）消息的保護。可用 WSS 防止消息的真實性、完整性和機密性受到不可靠網(wǎng)絡(luò)和傳輸中介的攻擊。

并不是所有中介都不可靠。Web 服務(wù)網(wǎng)關(guān)和企業(yè)服務(wù)總線中介服務(wù)都是消息轉(zhuǎn)換中介的例子，其在 SOA 內(nèi)的功能包括檢查，在某些情況下還包括對消息有效負載的修改 [請參閱此系列中的第 4 部分，“IBM 企業(yè)服務(wù)總線簡介”（developerworks，2005 年）]。在設(shè)計 SOA 安全基礎(chǔ)設(shè)施時，請考慮允許某些受信任的中介。

處理請求者和應(yīng)用程序服務(wù)主機之間的信任關(guān)系的消息代理可能是另一個受信任的中介。在這種設(shè)計中，安全責(zé)任由代理和服務(wù)端點來分擔(dān)。如圖 2 所示，消息中介將負責(zé)消息級安全、請求者和提供者環(huán)境之間的身份聯(lián)合，以及管理請求者和服務(wù)提供者之間的信任關(guān)系。服務(wù)只有為了滿足特定于服務(wù)的安全要求（如建立（通過中介映射和聯(lián)合）訪問特定于消息有效負載中應(yīng)用程序數(shù)據(jù)的服務(wù)、完整性和機密性數(shù)據(jù)的身份）才會繼續(xù)起安全作用。通過分解業(yè)務(wù)應(yīng)用程序中脆弱或復(fù)雜的基礎(chǔ)設(shè)施代碼并將其委派給容器，基于 SOA 的安全方法可以提高靈活性并降低發(fā)生不測事件的可能性。

消息安全性

WSS 規(guī)范還提供一系列有助于 Web 服務(wù)開發(fā)人員保護 SOAP 交換的基本消息級完整性、機密性和身份驗證機制。可用各種方式組合這些機制，以便用各種加密技術(shù)建立各種安全模型。

WSS 還提供可擴展的機制，以便將安全令牌與含有各種身份驗證及授權(quán)格式和機制的消息相關(guān)聯(lián)。例如，客戶機可能會提供身份證據(jù)及其具有特定業(yè)務(wù)證書的已簽名聲明。然后收到這種消息的 Web 服務(wù)就可以確定是否要信任其聲明和信任的程度。

安全令牌聲明可由授權(quán)機構(gòu)核準(zhǔn)或不核準(zhǔn)。一組已核準(zhǔn)的聲明通常表示為安全令牌（經(jīng)過數(shù)字簽名或受到授權(quán)機構(gòu)加密保護）。X.509 證書就是一個熟悉的已簽名安全令牌例子；它斷言某人的身份和公鑰之間的綁定關(guān)系。安全令牌可以“推送到”消息中或者在消息中攜帶安全令牌，也可以通過引用表示安全令牌，以便接收方從授權(quán)機構(gòu)“拉取”該聲明。

因為安全令牌是在信任域內(nèi)起作用的，所以需要有鏈接信任域作用范圍的方式。可通過協(xié)議或通過實現(xiàn)一系列規(guī)則強制執(zhí)行信任策略來手動鏈接。這樣，如果發(fā)送方和接收方之間有已確立的信任關(guān)系，則可信任未經(jīng)核準(zhǔn)的聲明。例如，如果發(fā)送方和接收方使用的是其通過帶外信任關(guān)系建立的可靠連接，則發(fā)送方為 Bob 的未核準(zhǔn)聲明足以讓某些接收方認為發(fā)送方實際上就是 Bob。在本例中，此可靠連接的存在可作為確鑿的證據(jù)。

防止消息內(nèi)容受到非法訪問（機密性）或非法修改（完整性）是主要的安全事務(wù)。WSS 規(guī)范提供通過對主體、標(biāo)題、附件或其任意組合（或部分）進行加密和/或數(shù)字簽名保護消息的方法。

身份驗證請求基于可選網(wǎng)絡(luò)、由傳輸支持的安全性和消息中已批準(zhǔn)的信息（聲明）的組合，這種技術(shù)稱為消息源身份驗證可能更好一些。通過網(wǎng)絡(luò)和由傳輸提供的安全性、消息中已批準(zhǔn)的聲明，以及用收件人已知的密鑰對請求進行加密，請求者可以對收件人進行身份驗證。

信任模型

演示安全令牌已授權(quán)應(yīng)用的一種方式是，添加采用相關(guān)聯(lián)密鑰（來自于占有證據(jù)令牌）的數(shù)字簽名。這會使請求者可通過將安全令牌（如 X.509 公鑰基礎(chǔ)設(shè)施（Public Key Infrastructure for X.509，PKIX）證書或 X.509 證書）與消息相關(guān)聯(lián)來證明所請求的聲明組。

如果請求者沒有向服務(wù)證明請求的聲明所必要的令牌，則可與相應(yīng)的授權(quán)機構(gòu)（我們稱為安全令牌服務(wù)）聯(lián)系，并用正當(dāng)?shù)穆暶髡埱笏璧牧钆啤０踩钆仆ㄟ^發(fā)布一系列安全令牌（可用于在不同的信任域之間代理信任關(guān)系）來形成信任的基礎(chǔ)。

一種機制是應(yīng)用 WS-Trust（對于有關(guān) WS-Trust 規(guī)范的更多信息，請參閱參考資料）中所定義的質(zhì)詢回應(yīng)協(xié)議。這種機制由 Web 服務(wù)用來對請求者進行更多質(zhì)詢，以確保消息不過時，以及驗證安全令牌的使用是否已經(jīng)授權(quán)。圖 3 所示的就是此模型，可以看出任何請求者也都可以是服務(wù)，請求者和目標(biāo)服務(wù)都具有受信任的第三方安全令牌服務(wù)，這種服務(wù)有助于驗證每個目標(biāo)服務(wù)策略所需的安全令牌。

此 SOA 安全模型（聲明、策略和安全令牌）還含有并支持若干特定模型，如基于身份的授權(quán)、訪問控制列表和基于功能的授權(quán)。通過該模型可使用現(xiàn)有的技術(shù)，如 X.509 公鑰證書、基于 XML 的令牌、Kerberos 共享秘密票證，甚至口令摘要。SOA 模型結(jié)合 Web 服務(wù)安全對話語言（Web Services Secure Conversation Language，WSSC）和 Web 服務(wù)策略框架基本要素，這足以構(gòu)造高級密鑰交換、身份驗證、基于策略的訪問控制、審核和復(fù)雜的信任關(guān)系。

將對 Web 服務(wù)應(yīng)用策略，Web 服務(wù)會從請求者收到可能包括安全令牌的消息，還可能會對其通過 WSSC 機制應(yīng)用某些保護措施。下面是由 Web 服務(wù)的信任引擎執(zhí)行的主要步驟：

• 驗證令牌中的聲明是否足以遵從策略，以及消息是否與策略一致。
• 驗證申請人的特征是否可由簽名來證明。在代理式信任模型中，簽名不可以證明申請人的身份；簽名可以證明中介（只是可斷言申請人的身份）的身份。聲明經(jīng)過批準(zhǔn)或不是基于策略。
• 驗證安全令牌（包括所有相關(guān)和即將頒發(fā)的安全令牌）的頒發(fā)者是否可信，可以頒發(fā)其所作的聲明。信任引擎可能需要外部驗證或代理令牌（也就是向安全令牌提供服務(wù)發(fā)送令牌，以便用其交換其他可直接用在其評估中的安全令牌）。

如果滿足了這些條件，而且請求者有權(quán)執(zhí)行操作，則服務(wù)可以處理服務(wù)請求。

可將 IP 安全（IP Security，IPSec）或傳輸層安全/安全套接字層（Transport Layer Security/Secure Sockets Layer，TLS/SSL）之類的網(wǎng)絡(luò)和傳輸保護機制與此 SOA 安全模型結(jié)合使用，以支持不同的安全要求和方案。如果可用，作為附加安全技術(shù)，請求者應(yīng)該考慮采用網(wǎng)絡(luò)或傳輸安全機制，以便在頒發(fā)、驗證或更新安全令牌時對收件人預(yù)先進行身份驗證。

編程模型設(shè)計原則

從安全的角度來看，編程模型包括對于誰負責(zé)實現(xiàn)安全策略（如基礎(chǔ)設(shè)施或應(yīng)用程序）所作的決策，以及需要讓請求者得到此信息的哪一部分。除了操作方面，某些設(shè)計期間的策略（如在 J2EE 描述符中捕獲的）也有助于管理應(yīng)用程序。是通過使基礎(chǔ)設(shè)施能夠?qū)崿F(xiàn)安全模型，還是通過將安全的實現(xiàn)轉(zhuǎn)換成每個應(yīng)用程序中的代碼來最大程度地滿足業(yè)務(wù)需求，這是關(guān)鍵實現(xiàn)決策之一。要考慮的另一方面是調(diào)用服務(wù)的變數(shù)。服務(wù)的消費者是否通過可在訂閱期間定制的選擇得到了靈活性？最后，在實現(xiàn)安全解決方案時，應(yīng)該考慮安全工程——用于構(gòu)建安全應(yīng)用程序的工程方法。

由基礎(chǔ)設(shè)施管理的安全與由應(yīng)用程序管理的安全

每個組織通常都會讓某些人負責(zé)確定和實現(xiàn)其安全策略。在許多情況下此過程都是手動的，從而導(dǎo)致組織投入大量資源在不同的實體和應(yīng)用程序之間協(xié)調(diào)訪問。

我們建議復(fù)雜的組織在基礎(chǔ)設(shè)施中集中實現(xiàn)與解決方案相關(guān)的安全策略——也就是驗證用戶質(zhì)詢（如用戶 ID/密碼）、控制對應(yīng)用程序的訪問（如對 travelService 執(zhí)行 reserve() 方法），以及委派身份（如運行方式 travelAgency id），以確保方法一致。可在某些部署構(gòu)件（如 J2EE 應(yīng)用程序的部署描述符）中定義初始應(yīng)用程序安全策略。部署完畢后，熟悉大部分應(yīng)用程序邏輯時就可以向部署環(huán)境提供策略信息了。可將策略聲明概括成高級策略要求，以備將來細化成實現(xiàn)約束條件，這被認為是部署階段的工作。

應(yīng)用程序設(shè)計中引入了有關(guān)由基礎(chǔ)設(shè)施管理的安全與由應(yīng)用程序管理的安全的決策。安全約束和條件是附加到實現(xiàn)構(gòu)件的。決定是讓基礎(chǔ)設(shè)施處理安全，還是將安全轉(zhuǎn)換成應(yīng)用程序中的代碼的時機在實現(xiàn)階段，此時通常可以得到有關(guān)應(yīng)用程序平臺（如 Java? Platform Enterprise Edition (J2EE) 和 Microsoft? .NET）的信息。

我們建議將應(yīng)用程序的重點放在業(yè)務(wù)邏輯、延遲服務(wù)訪問的保護和送往基礎(chǔ)設(shè)施的消息（承載應(yīng)用程序的運行時容器）上。在這種由基礎(chǔ)設(shè)施管理的方法中，附加到設(shè)計構(gòu)件的安全策略將被轉(zhuǎn)換成特定于平臺的策略 [例如，通過統(tǒng)一建模語言（Unified Modeling Language，UML）模型表示的要求將轉(zhuǎn)換成 J2EE 部署描述符]。

在由應(yīng)用程序管理的方法中，安全實現(xiàn)是在應(yīng)用程序中實現(xiàn)的，必須實現(xiàn)相應(yīng)的安全調(diào)用。即使是由應(yīng)用程序管理的安全也必須通過 Java 身份驗證和授權(quán)服務(wù)（Java Authentication and Authorization Service，JAAS）將其安全調(diào)用（如 authenticate()）轉(zhuǎn)換成相應(yīng)的特定于平臺的功能[如 loginContext.login()]。

授權(quán)和訪問控制的粒度粗細不等。細粒度訪問（對于解決方案本身）與粗粒度訪問（對于其操作之一）的選擇通常取決于業(yè)務(wù)和技術(shù)考慮。粒度也會受各種因素的影響，包括信息實體的實例（如特定游客的信用帳戶概要信息）、上下文信息，如用戶特征（如旅行社）、時間約束（如從早上九點到下午五點）、訪問目的（如進行旅游預(yù)訂的目的）、訪問路徑（例如，內(nèi)部網(wǎng)請求與外部請求），以及許多其他因素。

可通過定義應(yīng)用程序角色概括與授權(quán)相關(guān)的策略，其中的角色是指一組通過其可對特定應(yīng)用程序資源執(zhí)行某些操作的權(quán)限。例如，旅行應(yīng)用程序可聲明對 ReservationBean 執(zhí)行的 view() 或 change() 預(yù)訂方法可由 TravelAgent 角色訪問。換句話說，TravelAgent 是由實現(xiàn)方案定義的角色，可以確定可由“旅行社”執(zhí)行的操作；根據(jù)一組用于對各自企業(yè) JavaBean（Enterprise JavaBean，EJB）調(diào)用特定方法的權(quán)限。在實現(xiàn)階段不大可能定義的是誰擁有 TravelAgent 特權(quán)。用戶到角色的指派通常是在部署時開始的，然后會在應(yīng)用程序的整個生命周期內(nèi)對其進行管理。清單 1 所示的是用于定義某些基于角色的方法權(quán)限的示例代碼。

												
														<method-permission>
<role-name>TravelAgent</role-name>
<method>
   <ejb-name>ReservationBean</ejb-name>
<method-permission>
<role-name>TravelAgent</role-name>
<method>
   <ejb-name>ReservationBean</ejb-name>
   <method-name> view</method-name>
   <method-name> change</method-name>
</method>
</method-permission>
			
												
										

在執(zhí)行某些業(yè)務(wù)邏輯之前要求提供通過身份驗證的身份信息的應(yīng)用程序必須從基礎(chǔ)設(shè)施中得到該信息。例如，在 J2EE 環(huán)境中，運行時會在身份驗證后確定用戶的身份；應(yīng)用程序可通過 API（如 getCallerPrincipal()）檢索此信息。

選擇的靈活性

客戶機運行時有時需要某些對訪問服務(wù)本身的要求或約束（包括身份驗證、完整性和機密性要求）。而支持各種客戶機運行時（如瀏覽器客戶機、非瀏覽器客戶機和 PDA 瘦客戶機）可能是令人滿意的。要支持各種客戶機運行時，請發(fā)布斷言客戶機運行時必須確保消息機密性，并必須提供用戶身份的證據(jù)（用戶 ID/密碼或證書）的策略。身份驗證的策略概括可列出替代選項，如可接受的憑據(jù)類型，或所信任的憑據(jù)頒發(fā)機構(gòu)。

例如，TravelService Web 服務(wù)可聲明其要求某些安全令牌類型的意圖和機密性要求。實現(xiàn)方案可通過描述符支持意圖聲明。工具則可進而生成必要的機器級詳細信息（如 WS-SecurityPolicy 表達式），如清單 2 所示。

												
														<wsp:Policy>
  <sp:SymmetricBinding>
    <wsp:Policy>
      <sp:ProtectionToken>
        <wsp:Policy>
          <sp:KerberosV5APREQToken
              sp:IncludeToken=".../IncludeToken/Once" />
        </wsp:Policy>
      </sp:ProtectionToken>
      <sp:SignBeforeEncrypting />
      <sp:EncryptSignature />
    </wsp:Policy>
  </sp:SymmetricBinding>
  <sp:SignedParts>
    <sp:Body/>
    <sp:Header
       Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"
    />
  </sp:SignedParts>
  <sp:EncryptedParts>
    <sp:Body/>
  </sp:EncryptedParts>
</wsp:Policy>
			
												
										

安全工程

在開發(fā)安全解決方案的過程中，安全工程是最佳實踐之一——請遵循定義明確的模式，以使您的應(yīng)用程序、服務(wù)或組件可以完全實現(xiàn)其設(shè)計者和用戶的期望。您應(yīng)該估計每個實現(xiàn)方案構(gòu)件中固有的風(fēng)險，對其進行設(shè)計和實現(xiàn)以防其暴露在弱點下（例如，高效的內(nèi)存管理并避免出現(xiàn)隱蔽的通道）。工具支持和代碼評審也有助于將對從中部署解決方案的環(huán)境的損害降到最低（或徹底避免）。

總結(jié)

SOA 編程模型必須確保每個服務(wù)調(diào)用都符合對請求者和服務(wù)端點均有效的安全策略。安全基礎(chǔ)設(shè)施（包括對請求者進行身份驗證和對其授予服務(wù)訪問權(quán)的能力、基于基本信任模型跨 Web 服務(wù)請求傳播安全上下文、審核重要事件，以及有效地保護數(shù)據(jù)和內(nèi)容）形成了有助于保護組件和服務(wù)的 SOA 環(huán)境的結(jié)構(gòu)。所有 SOA 安全的核心都是基于策略的基礎(chǔ)設(shè)施和策略的管理。在理想的情況下，SOA 應(yīng)用程序的重點在于業(yè)務(wù)邏輯、委派安全策略的實現(xiàn)，以及處理基礎(chǔ)設(shè)施的信任關(guān)系。基于 Web 服務(wù)安全規(guī)范的 Web 服務(wù)安全模型和方法有助于解決保護面向服務(wù)的應(yīng)用程序的難題。