iweroulsdjf

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

引言

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

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

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

業務應用程序和安全基礎設施

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

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

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

SOA 安全模型

SOA 安全模型基于 Web 服務可能需要其中的傳入消息以驗證一系列聲明的過程。名稱、密鑰、權限和功能都是聲明的例子。根據所提供的證據，會在請求者、服務端點和一系列可能的中介之間應用適當的信任模型。

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

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

OASIS Web 服務安全性（Web Services Security，WSS）規范提供對傳輸中的簡單對象訪問協議（Simple Object Access Protocol，SOAP）消息的保護?？捎?WSS 防止消息的真實性、完整性和機密性受到不可靠網絡和傳輸中介的攻擊。

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

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

消息安全性

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

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

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

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

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

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

信任模型

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

如果請求者沒有向服務證明請求的聲明所必要的令牌，則可與相應的授權機構（我們稱為安全令牌服務）聯系，并用正當的聲明請求所需的令牌。安全令牌通過發布一系列安全令牌（可用于在不同的信任域之間代理信任關系）來形成信任的基礎。

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

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

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

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

如果滿足了這些條件，而且請求者有權執行操作，則服務可以處理服務請求。

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

編程模型設計原則

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

由基礎設施管理的安全與由應用程序管理的安全

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

我們建議復雜的組織在基礎設施中集中實現與解決方案相關的安全策略——也就是驗證用戶質詢（如用戶 ID/密碼）、控制對應用程序的訪問（如對 travelService 執行 reserve() 方法），以及委派身份（如運行方式 travelAgency id），以確保方法一致。可在某些部署構件（如 J2EE 應用程序的部署描述符）中定義初始應用程序安全策略。部署完畢后，熟悉大部分應用程序邏輯時就可以向部署環境提供策略信息了?？蓪⒉呗月暶鞲爬ǔ筛呒壊呗砸?，以備將來細化成實現約束條件，這被認為是部署階段的工作。

應用程序設計中引入了有關由基礎設施管理的安全與由應用程序管理的安全的決策。安全約束和條件是附加到實現構件的。決定是讓基礎設施處理安全，還是將安全轉換成應用程序中的代碼的時機在實現階段，此時通?？梢缘玫接嘘P應用程序平臺（如 Java? Platform Enterprise Edition (J2EE) 和 Microsoft? .NET）的信息。

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

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

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

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

												
														<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>
			
												
										

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

選擇的靈活性

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

例如，TravelService Web 服務可聲明其要求某些安全令牌類型的意圖和機密性要求。實現方案可通過描述符支持意圖聲明。工具則可進而生成必要的機器級詳細信息（如 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>
			
												
										

安全工程

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

總結

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