相比傳統(tǒng)的電信網(wǎng)，NGN面臨著眾多的安全威脅，NGN的業(yè)務(wù)安全也面臨著巨大的挑戰(zhàn)。業(yè)務(wù)的開發(fā)和部署需要考慮到更多的安全特性和安全功能。利用UML安全擴(kuò)展UMLsec對(duì)NGN中的業(yè)務(wù)安全需求進(jìn)行分析建模，提出了一種細(xì)粒度的安全需求分析方法，通過抽象出安全功能抽象類說明NGN業(yè)務(wù)的安全特性需求。并通過用例討論了基于安全應(yīng)用接口的安全需求實(shí)現(xiàn)，使得各種安全特性能夠更方便、更靈活地集成到業(yè)務(wù)中。

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

目前，已經(jīng)有眾多的安全機(jī)制用于保證網(wǎng)絡(luò)和計(jì)算設(shè)備的安全，但這些安全機(jī)制都是針對(duì)某一個(gè)或某幾個(gè)特定安全問題和特定的環(huán)境設(shè)計(jì)的，如密鑰分配、實(shí)體認(rèn)證、機(jī)密性保護(hù)、完整性保護(hù)等，NGN業(yè)務(wù)針對(duì)不同的業(yè)務(wù)特征和業(yè)務(wù)執(zhí)行環(huán)境有著不同的、綜合的安全需求。如何理清業(yè)務(wù)的安全需求，并盡量通過已有的網(wǎng)絡(luò)安全能力是業(yè)務(wù)開發(fā)者面臨的一個(gè)問題。

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

一、NGN業(yè)務(wù)安全需求分析

1.UMLsec擴(kuò)展

UMLsec是基于UML標(biāo)準(zhǔn)擴(kuò)展機(jī)制的一個(gè)UMLprofile，通過在UML元模型中增加安全相關(guān)的約束、標(biāo)簽、定型等建模元素，使用UML圖來表達(dá)安全相關(guān)的語義和系統(tǒng)需求與約束。但目前的UMLsec是基于計(jì)算機(jī)網(wǎng)絡(luò)的環(huán)境定義的，將其用于NGN業(yè)務(wù)安全分析中來還需要進(jìn)行相應(yīng)的擴(kuò)展。主要的擴(kuò)展在于在UMLsec的元素中增加具備與NGN環(huán)境相關(guān)的定義，使其能夠更明確、更有針對(duì)性地表達(dá)NGN業(yè)務(wù)的特點(diǎn)與需求。本文中將業(yè)務(wù)的承載、執(zhí)行節(jié)點(diǎn)定義為NGN中業(yè)務(wù)的基礎(chǔ)架構(gòu)，并在UML元模型中對(duì)這些元素進(jìn)行定義，如圖1所示。
 

                                                                                   圖1 NGN基礎(chǔ)架構(gòu)模型擴(kuò)展

該擴(kuò)展針對(duì)Link和Node和兩個(gè)元類增加了NGN中關(guān)于承載和節(jié)點(diǎn)的定型。可以根據(jù)需要對(duì)該模型作進(jìn)一步擴(kuò)展，如可以增加關(guān)于接入網(wǎng)承載的定型等。

2.基于UMLsec的威脅分析

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

                                                                                              表1 NGN基礎(chǔ)架構(gòu)的威脅函數(shù)

攻擊者對(duì)于IP承載的數(shù)據(jù)能夠執(zhí)行讀寫和刪除操作，故其能夠針對(duì)IP承載的業(yè)務(wù)進(jìn)行攻擊。如攻擊者可以修改正常的SIP消息以改變呼叫的路由，發(fā)出BYE等SIP消息拆除正常的SIP會(huì)話，通過截獲RTP承載的語音包并解碼以實(shí)現(xiàn)竊聽，可以在IP網(wǎng)絡(luò)中插入大量數(shù)據(jù)降低VoIP的QoS實(shí)現(xiàn)DoS攻擊，等等。

軟設(shè)備通?；谕ㄓ玫牟僮飨到y(tǒng)、數(shù)據(jù)庫等軟件。這些通用軟件以及協(xié)議棧的實(shí)現(xiàn)都可能具備能被攻擊者利用的漏洞。通過這些安全漏洞，攻擊者可以對(duì)這些設(shè)備發(fā)起拒絕服務(wù)攻擊(DoS)或獲得設(shè)備的訪問權(quán)。

由于NGN的基礎(chǔ)設(shè)施針對(duì)一般攻擊者的攻擊函數(shù)值通常都不為空，因此需要在業(yè)務(wù)開發(fā)和部署時(shí)利用安全機(jī)制來保證業(yè)務(wù)的安全。

3.業(yè)務(wù)的安全需求分析

業(yè)務(wù)的安全需求可能包括用戶信息的機(jī)密性、完整性、業(yè)務(wù)本身的可用性等方面。NGN中不同類型的業(yè)務(wù)有著不同的安全需求，如會(huì)話類業(yè)務(wù)的主要安全需求是可用性，消息類業(yè)務(wù)的主要安全需求是完整性。同一類型的業(yè)務(wù)其安全需求應(yīng)該也是可以根據(jù)業(yè)務(wù)場(chǎng)景定制的，如普通兩方呼叫要求即使在網(wǎng)絡(luò)中出現(xiàn)入侵的情況下也應(yīng)保證呼叫的正確路由，并確保語音流的服務(wù)質(zhì)量。而如果用戶要求呼叫需被保密，則還需保證信令消息的機(jī)密性和語音流的機(jī)密性，需要對(duì)信令和語音流進(jìn)行加密處理。不同業(yè)務(wù)的安全需求是安全特性的組合。利用建模語言，業(yè)務(wù)所需要的安全特性可以抽象成為安全感知的類來表示。這些類中的功能可以使用安全應(yīng)用接口提供的安全能力實(shí)現(xiàn)，而業(yè)務(wù)的安全需求則表示為類的組合。為了清晰表達(dá)業(yè)務(wù)的安全需求，并便于業(yè)務(wù)安全需求的實(shí)現(xiàn)，本文將業(yè)務(wù)的安全需求抽象為細(xì)粒度的安全功能類，每個(gè)安全功能類表達(dá)了業(yè)務(wù)對(duì)其各個(gè)組件(如信令、媒體、業(yè)務(wù)功能等)的不同安全特性(如機(jī)密性、完整性、認(rèn)證等)的需求。

下面以基于SIP的兩方會(huì)話為例說明如何使用UMLsec描述業(yè)務(wù)安全需求。假定兩方呼叫發(fā)生在同一SIPProxy轄域的兩個(gè)用戶之間，要求保證用戶UA與SIPProxy之間的信令的完整性，不能被非法入侵者篡改。該場(chǎng)景的用例圖和部署圖分別如圖2、圖3所示。
 

                                                                            圖2 信令完整性用例圖
 

                                                           圖3 信令完整性保護(hù)部署圖

圖3中的UA代表UserA或UserB的UA，因?yàn)閮蓚€(gè)UA的信令交互需要通過Proxy，且其安全需求是一致的，故在圖中只表現(xiàn)出一方。UA和Proxy均是基于通用計(jì)算平臺(tái)的節(jié)點(diǎn)，其訪問控制需要受到保護(hù)，故對(duì)其標(biāo)記上定型《guardedaccess》。UA中除處理信令外，還需處理媒體流的編解碼與控制，這個(gè)用例中只涉及信令的安全性，故在UA中只關(guān)注進(jìn)行信令控制的組件。UA與Proxy之間的通信基于IP承載，根據(jù)表1定義的威脅函數(shù)：ThreatA(IP Carrier)={delete，read，insert}，信令的完整性在攻擊下可能遭到破壞，需要采用相應(yīng)的安全機(jī)制對(duì)信令交互加以保護(hù)。

 　Sender類和Receiver類是通過對(duì)通信安全功能的抽象而得出的兩個(gè)類。這兩個(gè)類具備保證發(fā)送方和接收方之間消息傳送的完整性的安全能力。通過在UA的信令控制功能和Proxy的呼叫控制功能中聚合這兩個(gè)類，可以在高層的需求層面上滿足UA和Proxy通信的信令完整性需求。

　　AccessGuard類是用于隔離對(duì)保護(hù)對(duì)象的訪問的類，通過在被保護(hù)對(duì)象上標(biāo)識(shí){guard=AccessGuard}標(biāo)記，所有的對(duì)保護(hù)對(duì)象的訪問請(qǐng)求需先提交給AccessGuard類，AccessGuard類根據(jù)具體的訪問控制機(jī)制和訪問控制策略進(jìn)行訪問權(quán)限的判定后，訪問請(qǐng)求才能在被保護(hù)對(duì)象上執(zhí)行。

　　Sender類和Receiver類可以針對(duì)業(yè)務(wù)對(duì)安全需求的不同控制粒度進(jìn)一步細(xì)化，通過對(duì)send()方法的重載加以實(shí)現(xiàn)。如在調(diào)用send()方法時(shí)可以使用QoP[5，7](QualityofProtection)參數(shù)說明業(yè)務(wù)對(duì)安全功能的保護(hù)級(jí)別的需求。QoP體現(xiàn)了處理安全問題的開銷與安全保護(hù)需求之間的動(dòng)態(tài)平衡。某一級(jí)別的QoP可以對(duì)應(yīng)于某一具體安全機(jī)制中所采用的加密算法強(qiáng)度、密鑰長(zhǎng)度、認(rèn)證機(jī)制強(qiáng)度等。但目前QoP的定義還依賴于具體的安全機(jī)制，且具有一定的隨意性，沒有一個(gè)客觀的標(biāo)準(zhǔn)。

　　在更細(xì)的粒度上，用戶可以在send()方法中指定具體安全機(jī)制的相關(guān)參數(shù)，對(duì)所使用的安全機(jī)制進(jìn)行更精確的控制。

　　圖5是對(duì)通信機(jī)密性進(jìn)行保護(hù)的安全能力抽象類的類圖。其send()方法應(yīng)能保證消息的加密傳輸。Receiver類的receive()方法用于接收并解密消息。同完整性保護(hù)一樣，更加細(xì)致和更加可控的機(jī)密性保護(hù)可通過對(duì)send()和receive()方法的重載實(shí)現(xiàn)。

　　除了圖4和圖5中列舉的用于保護(hù)通信完整性和機(jī)密性以及實(shí)體訪問控制的安全能力抽象類外，還可以根據(jù)業(yè)務(wù)的實(shí)際安全需求抽象更多的安全能力抽象類。每個(gè)類實(shí)現(xiàn)某一特定的安全功能，如可以在多媒體會(huì)議中定義群密鑰管理功能抽象類，用于滿足群密鑰生成、分發(fā)與認(rèn)證的功能。

　　圖4 安全功能抽象類圖示例

　　圖5 消息機(jī)密性安全功能類

　　二、業(yè)務(wù)安全的實(shí)現(xiàn)機(jī)制

　　基于上述分析，可以將NGN業(yè)務(wù)的安全需求從安全特性上加以劃分并進(jìn)行抽象，形成一系列細(xì)粒度的安全功能抽象類。通過對(duì)每一個(gè)安全功能抽象類的實(shí)現(xiàn)可以滿足業(yè)務(wù)的安全需求。文獻(xiàn)[8]提出了一種基于模型驅(qū)動(dòng)的細(xì)粒度的訪問控制框架AC-PIM，將一個(gè)統(tǒng)一的高層的訪問控制模型(AC-PIM)映射到多種具體的訪問控制機(jī)制中，如OASIS的SAML(SecurityAssertionMarkupLanguage)和XACML(eXtensible Access Control Markup Language)，OMG的RAD(Resource Access Decision Facility)以及Java Authentication and Authorization中定義的Java訪問控制模型。AC-PIM提供了一個(gè)實(shí)現(xiàn)圖4中的AccessGuard抽象類的途徑。

　　下面說明如何利用GSS-API實(shí)現(xiàn)保證通信完整性的安全能力抽象類，通過狀態(tài)圖說明保證通信完整性的Sender類的send()方法及Receiver類的receive()方法的GSS-API實(shí)現(xiàn)。本文中給出的是一個(gè)示意性的說明，忽略了一些錯(cuò)誤處理過程。

　　圖6中，在send()方法被調(diào)用后，Sender首先檢測(cè)是否已有可用的安全上下文，如果可用的安全上下文已經(jīng)存在，則可以利用該上下文的句柄作為參數(shù)之一，調(diào)用GSS-API的Get_GetMIC()方法。參數(shù)還包括有待進(jìn)行簽名的消息和可選的QoP。如果對(duì)消息簽名可以正常完成，Sender就可以將消息與簽名后生成的token一起送到目的地。如果簽名發(fā)生異常，則可以通過返回的錯(cuò)誤碼判斷原因。

　　圖6 {integrity}Sender的GSS-API實(shí)現(xiàn)

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

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

　　圖7 {integrity}Receiver的GSS-API實(shí)現(xiàn)

　　如果需要實(shí)現(xiàn)的機(jī)密性保護(hù)，則Sender類和Receiver類的約束用{secrecy}表示?？赏ㄟ^GSS-API的GSS_Warp()方法和GSS_Unwrap()方法實(shí)現(xiàn)Sender和Receiver的安全功能。

　　Sender和Receiver還可以通過NGSS-API來實(shí)現(xiàn)。NGSS-API是ParlayAPI架構(gòu)下的安全應(yīng)用接口，對(duì)網(wǎng)絡(luò)的安全能力進(jìn)行抽象，并為業(yè)務(wù)提供安全能力。NGSS-API中提供了IpCredentialManager、IpContextManager、IpContext等類分別用于管理證書、管理安全上下文以及基于安全上下文的完整性、機(jī)密性等網(wǎng)絡(luò)中的安全機(jī)制提供的安全能力。使用NGSS-API實(shí)現(xiàn)通信的完整性、機(jī)密性保護(hù)的過程與GSS-API類似。

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

　　GSS-API和NGSS-API都獨(dú)立于具體的安全機(jī)制，可以采用不同的安全機(jī)制和安全協(xié)議實(shí)現(xiàn)。

　　三、結(jié)語

　　本文根據(jù)NGN的網(wǎng)絡(luò)特點(diǎn)對(duì)UMLsec進(jìn)行了擴(kuò)展，利用擴(kuò)展后的UMLsec對(duì)NGN的網(wǎng)絡(luò)環(huán)境和業(yè)務(wù)的安全需求進(jìn)行了分析。將NGN業(yè)務(wù)的安全需求抽象成細(xì)粒度的安全能力抽象類，用UMLsec加以描述，通過這些類的組合完整表達(dá)NGN業(yè)務(wù)所需的安全特性。通過對(duì)安全能力抽象類的實(shí)現(xiàn)可以滿足NGN業(yè)務(wù)的安全需求。本文通過用例說明了如何利用安全應(yīng)用接口實(shí)現(xiàn)安全能力抽象類?；诎踩珣?yīng)用接口的實(shí)現(xiàn)與具體安全機(jī)制的細(xì)節(jié)無關(guān)，且具有可移植性，使得業(yè)務(wù)的安全特性在不同的環(huán)境下可通過不同的安全機(jī)制實(shí)現(xiàn)。下一步的研究工作將包括對(duì)業(yè)務(wù)可用性等安全特征進(jìn)行建模，并完善需求模型與實(shí)現(xiàn)模型之間的轉(zhuǎn)換規(guī)則，以實(shí)現(xiàn)模型之間的自動(dòng)轉(zhuǎn)換與驗(yàn)證。