業務的安全需求可能包括用戶信息的機密性、完整性、業務本身的可用性等方面。NGN中不同類型的業務有著不同的安全需求，如會話類業務的主要安全需求是可用性，消息類業務的主要安全需求是完整性。同一類型的業務其安全需求應該也是可以根據業務場景定制的，如普通兩方呼叫要求即使在網絡中出現入侵的情況下也應保證呼叫的正確路由，并確保語音流的服務質量。而如果用戶要求呼叫需被保密，則還需保證信令消息的機密性和語音流的機密性，需要對信令和語音流進行加密處理。不同業務的安全需求是安全特性的組合。利用建模語言，業務所需要的安全特性可以抽象成為安全感知的類來表示。這些類中的功能可以使用安全應用接口提供的安全能力實現，而業務的安全需求則表示為類的組合。為了清晰表達業務的安全需求，并便于業務安全需求的實現，本文將業務的安全需求抽象為細粒度的安全功能類，每個安全功能類表達了業務對其各個組件(如信令、媒體、業務功能等)的不同安全特性(如機密性、完整性、認證等)的需求。
下面以基于SIP的兩方會話為例說明如何使用UMLsec描述業務安全需求。假定兩方呼叫發生在同一SIPProxy轄域的兩個用戶之間，要求保證用戶UA與SIPProxy之間的信令的完整性，不能被非法入侵者篡改。該場景的用例圖和部署圖分別如圖2、圖3所示。
圖2 信令完整性用例圖
圖3 信令完整性保護部署圖
圖3中的UA代表UserA或UserB的UA，因為兩個UA的信令交互需要通過Proxy，且其安全需求是一致的，故在圖中只表現出一方。UA和Proxy均是基于通用計算平臺的節點，其訪問控制需要受到保護，故對其標記上定型《guardedaccess》。UA中除處理信令外，還需處理媒體流的編解碼與控制，這個用例中只涉及信令的安全性，故在UA中只關注進行信令控制的組件。UA與Proxy之間的通信基于IP承載，根據表1定義的威脅函數：ThreatA(IP Carrier)={delete，read，insert}，信令的完整性在攻擊下可能遭到破壞，需要采用相應的安全機制對信令交互加以保護。
Sender類和Receiver類是通過對通信安全功能的抽象而得出的兩個類。這兩個類具備保證發送方和接收方之間消息傳送的完整性的安全能力。通過在UA的信令控制功能和Proxy的呼叫控制功能中聚合這兩個類，可以在高層的需求層面上滿足UA和Proxy通信的信令完整性需求。
AccessGuard類是用于隔離對保護對象的訪問的類，通過在被保護對象上標識{guard=AccessGuard}標記，所有的對保護對象的訪問請求需先提交給AccessGuard類，AccessGuard類根據具體的訪問控制機制和訪問控制策略進行訪問權限的判定后，訪問請求才能在被保護對象上執行。
Sender類和Receiver類可以針對業務對安全需求的不同控制粒度進一步細化，通過對send()方法的重載加以實現。如在調用send()方法時可以使用QoP[5，7](QualityofProtection)參數說明業務對安全功能的保護級別的需求。QoP體現了處理安全問題的開銷與安全保護需求之間的動態平衡。某一級別的QoP可以對應于某一具體安全機制中所采用的加密算法強度、密鑰長度、認證機制強度等。但目前QoP的定義還依賴于具體的安全機制，且具有一定的隨意性，沒有一個客觀的標準。
在更細的粒度上，用戶可以在send()方法中指定具體安全機制的相關參數，對所使用的安全機制進行更精確的控制。
圖5是對通信機密性進行保護的安全能力抽象類的類圖。其send()方法應能保證消息的加密傳輸。Receiver類的receive()方法用于接收并解密消息。同完整性保護一樣，更加細致和更加可控的機密性保護可通過對send()和receive()方法的重載實現。
除了圖4和圖5中列舉的用于保護通信完整性和機密性以及實體訪問控制的安全能力抽象類外，還可以根據業務的實際安全需求抽象更多的安全能力抽象類。每個類實現某一特定的安全功能，如可以在多媒體會議中定義群密鑰管理功能抽象類，用于滿足群密鑰生成、分發與認證的功能。
圖4 安全功能抽象類圖示例
圖5 消息機密性安全功能類
二、業務安全的實現機制
基于上述分析，可以將NGN業務的安全需求從安全特性上加以劃分并進行抽象，形成一系列細粒度的安全功能抽象類。通過對每一個安全功能抽象類的實現可以滿足業務的安全需求。文獻[8]提出了一種基于模型驅動的細粒度的訪問控制框架AC-PIM，將一個統一的高層的訪問控制模型(AC-PIM)映射到多種具體的訪問控制機制中，如OASIS的SAML(SecurityAssertionMarkupLanguage)和XACML(eXtensible Access Control Markup Language)，OMG的RAD(Resource Access Decision Facility)以及Java Authentication and Authorization中定義的Java訪問控制模型。AC-PIM提供了一個實現圖4中的AccessGuard抽象類的途徑。
下面說明如何利用GSS-API實現保證通信完整性的安全能力抽象類，通過狀態圖說明保證通信完整性的Sender類的send()方法及Receiver類的receive()方法的GSS-API實現。本文中給出的是一個示意性的說明，忽略了一些錯誤處理過程。
圖6中，在send()方法被調用后，Sender首先檢測是否已有可用的安全上下文，如果可用的安全上下文已經存在，則可以利用該上下文的句柄作為參數之一，調用GSS-API的Get_GetMIC()方法。參數還包括有待進行簽名的消息和可選的QoP。如果對消息簽名可以正常完成，Sender就可以將消息與簽名后生成的token一起送到目的地。如果簽名發生異常，則可以通過返回的錯誤碼判斷原因。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
