相比傳統的電信網，NGN面臨著眾多的安全威脅，NGN的業務安全也面臨著巨大的挑戰。業務的開發和部署需要考慮到更多的安全特性和安全功能。利用UML安全擴展UMLsec對NGN中的業務安全需求進行分析建模，提出了一種細粒度的安全需求分析方法，通過抽象出安全功能抽象類說明NGN業務的安全特性需求。并通過用例討論了基于安全應用接口的安全需求實現，使得各種安全特性能夠更方便、更靈活地集成到業務中。

下一代網絡(NGN)是基于分組網絡的、多業務融合并開放網絡能力的電信網絡。其基于分組交換的核心網絡為業務融合提供了傳輸基礎設施;其網絡能力的開放提高了業務的擴展性，為第三方業務提供者進入電信業務市場提供了良好的契機。但NGN中相對于傳統電信網而言松耦合的、開放的業務結構特性和豐富的業務功能恰好與NGN基于通用計算平臺和IP傳輸網絡的基礎設施在安全架構上形成了矛盾。采用基于IP的分組網絡作為業務的承載網絡使得許多針對IP網絡的攻擊行為在電信網絡中成為可能，采用通用計算設備作為網絡中的控制實體將計算機的安全問題引入到網絡中的各個節點[1]。網絡能力和業務能力的開放也帶來了一系列業務層特有的安全問題。

目前，已經有眾多的安全機制用于保證網絡和計算設備的安全，但這些安全機制都是針對某一個或某幾個特定安全問題和特定的環境設計的，如密鑰分配、實體認證、機密性保護、完整性保護等，NGN業務針對不同的業務特征和業務執行環境有著不同的、綜合的安全需求。如何理清業務的安全需求，并盡量通過已有的網絡安全能力是業務開發者面臨的一個問題。

鑒于業務開發過程面臨的復雜的安全需求，本文提出使用形式化建模語言UMLsec[3，4]對業務安全需求進行分析，利用建模語言將業務所需的安全特性抽象成安全感知的類，通過這些類表達細粒度的安全功能，通過這些類的組合表達業務的安全需求。這些類的功能通過安全應用接口實現，如GSS-API[5]、NGSS-API[6]，從而將安全特征集成到業務中。以便業務開發者在業務開發過程中擺脫安全機制實現細節的困擾，并且使得開發出來的業務安全特征具備可移植性。

一、NGN業務安全需求分析

1.UMLsec擴展

UMLsec是基于UML標準擴展機制的一個UMLprofile，通過在UML元模型中增加安全相關的約束、標簽、定型等建模元素，使用UML圖來表達安全相關的語義和系統需求與約束。但目前的UMLsec是基于計算機網絡的環境定義的，將其用于NGN業務安全分析中來還需要進行相應的擴展。主要的擴展在于在UMLsec的元素中增加具備與NGN環境相關的定義，使其能夠更明確、更有針對性地表達NGN業務的特點與需求。本文中將業務的承載、執行節點定義為NGN中業務的基礎架構，并在UML元模型中對這些元素進行定義，如圖1所示。
 

                                                                                   圖1 NGN基礎架構模型擴展

該擴展針對Link和Node和兩個元類增加了NGN中關于承載和節點的定型。可以根據需要對該模型作進一步擴展，如可以增加關于接入網承載的定型等。

2.基于UMLsec的威脅分析

針對圖1中定義的定型以及對網絡安全構成威脅的攻擊者的類型，可以定義出威脅函數TheatA(s)。其中A表示攻擊者類型，這里假定攻擊者為具備一般能力的外部攻擊者，即其可以竊聽到廣播信道上的數據流量，并可以插入或刪除數據流量，能夠利用系統漏洞入侵系統;表示為模型中定義的定型威脅函數的值域為{delete，read，insert，access}。根據NGN中承載網絡和計算節點的特性，我們可以得出如下威脅函數，如表1所示。
 

                                                                                              表1 NGN基礎架構的威脅函數

攻擊者對于IP承載的數據能夠執行讀寫和刪除操作，故其能夠針對IP承載的業務進行攻擊。如攻擊者可以修改正常的SIP消息以改變呼叫的路由，發出BYE等SIP消息拆除正常的SIP會話，通過截獲RTP承載的語音包并解碼以實現竊聽，可以在IP網絡中插入大量數據降低VoIP的QoS實現DoS攻擊，等等。

軟設備通常基于通用的操作系統、數據庫等軟件。這些通用軟件以及協議棧的實現都可能具備能被攻擊者利用的漏洞。通過這些安全漏洞，攻擊者可以對這些設備發起拒絕服務攻擊(DoS)或獲得設備的訪問權。

由于NGN的基礎設施針對一般攻擊者的攻擊函數值通常都不為空，因此需要在業務開發和部署時利用安全機制來保證業務的安全。

3.業務的安全需求分析

業務的安全需求可能包括用戶信息的機密性、完整性、業務本身的可用性等方面。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一起送到目的地。如果簽名發生異常，則可以通過返回的錯誤碼判斷原因。

　　圖6 {integrity}Sender的GSS-API實現

　　如果在調用GSS_GetMIC()方法之前不存在可用的安全上下文，則Sender需要首先與Receiver之間建立安全上下文，通過安全機制信息的交互建立好安全上下文后可以繼續調用GSS_GetMIC()方法對需要發送的消息簽名。

　　通信完整性抽象類Receiver用于對消息完整性進行檢測，過程如圖7所示。經過GSS_VerifyMIC()方法檢測接收到的消息及其簽名是否一致以判定其完整性。如果沒有合適的上下文可用，則應先建立安全上下文然后再調用GSS_VerifyMIC()。

　　圖7 {integrity}Receiver的GSS-API實現

　　如果需要實現的機密性保護，則Sender類和Receiver類的約束用{secrecy}表示。可通過GSS-API的GSS_Warp()方法和GSS_Unwrap()方法實現Sender和Receiver的安全功能。

　　Sender和Receiver還可以通過NGSS-API來實現。NGSS-API是ParlayAPI架構下的安全應用接口，對網絡的安全能力進行抽象，并為業務提供安全能力。NGSS-API中提供了IpCredentialManager、IpContextManager、IpContext等類分別用于管理證書、管理安全上下文以及基于安全上下文的完整性、機密性等網絡中的安全機制提供的安全能力。使用NGSS-API實現通信的完整性、機密性保護的過程與GSS-API類似。

　　GSS-API和NGSS-API都可用于實現根據業務安全需求抽象出的安全功能抽象類。GSS-API通常由本地的程序語言類庫實現，適合于運行在終端和網絡實體上的業務實例使用，保證本地與目的地交互的安全性。NGSS-API基于ParlayAPI，主要面向應用服務器等第三方業務實體，適合于運行在應用服務器上、與Parlay網關進行交互的業務實例使用，其安全需求通過Parlay網關協調網絡中的實體實現，保證整體的安全性。GSS-API考慮的安全粒度是消息級的，而NGSS-API考慮的安全粒度相對要大一些，從應用服務器業務邏輯的視點出發，保證一個呼叫方或一個用戶接口的安全性。

　　GSS-API和NGSS-API都獨立于具體的安全機制，可以采用不同的安全機制和安全協議實現。

　　三、結語

　　本文根據NGN的網絡特點對UMLsec進行了擴展，利用擴展后的UMLsec對NGN的網絡環境和業務的安全需求進行了分析。將NGN業務的安全需求抽象成細粒度的安全能力抽象類，用UMLsec加以描述，通過這些類的組合完整表達NGN業務所需的安全特性。通過對安全能力抽象類的實現可以滿足NGN業務的安全需求。本文通過用例說明了如何利用安全應用接口實現安全能力抽象類。基于安全應用接口的實現與具體安全機制的細節無關，且具有可移植性，使得業務的安全特性在不同的環境下可通過不同的安全機制實現。下一步的研究工作將包括對業務可用性等安全特征進行建模，并完善需求模型與實現模型之間的轉換規則，以實現模型之間的自動轉換與驗證。