基于UML模型的NGN業(yè)務(wù)安全分析
2009/03/24
相比傳統(tǒng)的電信網(wǎng),NGN面臨著眾多的安全威脅,NGN的業(yè)務(wù)安全也面臨著巨大的挑戰(zhàn)。業(yè)務(wù)的開發(fā)和部署需要考慮到更多的安全特性和安全功能。利用UML安全擴展UMLsec對NGN中的業(yè)務(wù)安全需求進行分析建模,提出了一種細粒度的安全需求分析方法,通過抽象出安全功能抽象類說明NGN業(yè)務(wù)的安全特性需求。并通過用例討論了基于安全應(yīng)用接口的安全需求實現(xiàn),使得各種安全特性能夠更方便、更靈活地集成到業(yè)務(wù)中。圖1 NGN基礎(chǔ)架構(gòu)模型擴展
該擴展針對Link和Node和兩個元類增加了NGN中關(guān)于承載和節(jié)點的定型。可以根據(jù)需要對該模型作進一步擴展,如可以增加關(guān)于接入網(wǎng)承載的定型等。
2.基于UMLsec的威脅分析
針對圖1中定義的定型以及對網(wǎng)絡(luò)安全構(gòu)成威脅的攻擊者的類型,可以定義出威脅函數(shù)TheatA(s)。其中A表示攻擊者類型,這里假定攻擊者為具備一般能力的外部攻擊者,即其可以竊聽到廣播信道上的數(shù)據(jù)流量,并可以插入或刪除數(shù)據(jù)流量,能夠利用系統(tǒng)漏洞入侵系統(tǒng);表示為模型中定義的定型威脅函數(shù)的值域為{delete,read,insert,access}。根據(jù)NGN中承載網(wǎng)絡(luò)和計算節(jié)點的特性,我們可以得出如下威脅函數(shù),如表1所示。
攻擊者對于IP承載的數(shù)據(jù)能夠執(zhí)行讀寫和刪除操作,故其能夠針對IP承載的業(yè)務(wù)進行攻擊。如攻擊者可以修改正常的SIP消息以改變呼叫的路由,發(fā)出BYE等SIP消息拆除正常的SIP會話,通過截獲RTP承載的語音包并解碼以實現(xiàn)竊聽,可以在IP網(wǎng)絡(luò)中插入大量數(shù)據(jù)降低VoIP的QoS實現(xiàn)DoS攻擊,等等。
軟設(shè)備通;谕ㄓ玫牟僮飨到y(tǒng)、數(shù)據(jù)庫等軟件。這些通用軟件以及協(xié)議棧的實現(xiàn)都可能具備能被攻擊者利用的漏洞。通過這些安全漏洞,攻擊者可以對這些設(shè)備發(fā)起拒絕服務(wù)攻擊(DoS)或獲得設(shè)備的訪問權(quán)。
由于NGN的基礎(chǔ)設(shè)施針對一般攻擊者的攻擊函數(shù)值通常都不為空,因此需要在業(yè)務(wù)開發(fā)和部署時利用安全機制來保證業(yè)務(wù)的安全。
3.業(yè)務(wù)的安全需求分析
業(yè)務(wù)的安全需求可能包括用戶信息的機密性、完整性、業(yè)務(wù)本身的可用性等方面。NGN中不同類型的業(yè)務(wù)有著不同的安全需求,如會話類業(yè)務(wù)的主要安全需求是可用性,消息類業(yè)務(wù)的主要安全需求是完整性。同一類型的業(yè)務(wù)其安全需求應(yīng)該也是可以根據(jù)業(yè)務(wù)場景定制的,如普通兩方呼叫要求即使在網(wǎng)絡(luò)中出現(xiàn)入侵的情況下也應(yīng)保證呼叫的正確路由,并確保語音流的服務(wù)質(zhì)量。而如果用戶要求呼叫需被保密,則還需保證信令消息的機密性和語音流的機密性,需要對信令和語音流進行加密處理。不同業(yè)務(wù)的安全需求是安全特性的組合。利用建模語言,業(yè)務(wù)所需要的安全特性可以抽象成為安全感知的類來表示。這些類中的功能可以使用安全應(yīng)用接口提供的安全能力實現(xiàn),而業(yè)務(wù)的安全需求則表示為類的組合。為了清晰表達業(yè)務(wù)的安全需求,并便于業(yè)務(wù)安全需求的實現(xiàn),本文將業(yè)務(wù)的安全需求抽象為細粒度的安全功能類,每個安全功能類表達了業(yè)務(wù)對其各個組件(如信令、媒體、業(yè)務(wù)功能等)的不同安全特性(如機密性、完整性、認證等)的需求。
下面以基于SIP的兩方會話為例說明如何使用UMLsec描述業(yè)務(wù)安全需求。假定兩方呼叫發(fā)生在同一SIPProxy轄域的兩個用戶之間,要求保證用戶UA與SIPProxy之間的信令的完整性,不能被非法入侵者篡改。該場景的用例圖和部署圖分別如圖2、圖3所示。
圖3 信令完整性保護部署圖
圖3中的UA代表UserA或UserB的UA,因為兩個UA的信令交互需要通過Proxy,且其安全需求是一致的,故在圖中只表現(xiàn)出一方。UA和Proxy均是基于通用計算平臺的節(jié)點,其訪問控制需要受到保護,故對其標(biāo)記上定型《guardedaccess》。UA中除處理信令外,還需處理媒體流的編解碼與控制,這個用例中只涉及信令的安全性,故在UA中只關(guān)注進行信令控制的組件。UA與Proxy之間的通信基于IP承載,根據(jù)表1定義的威脅函數(shù):ThreatA(IP
Carrier)={delete,read,insert},信令的完整性在攻擊下可能遭到破壞,需要采用相應(yīng)的安全機制對信令交互加以保護。
Sender類和Receiver類是通過對通信安全功能的抽象而得出的兩個類。這兩個類具備保證發(fā)送方和接收方之間消息傳送的完整性的安全能力。通過在UA的信令控制功能和Proxy的呼叫控制功能中聚合這兩個類,可以在高層的需求層面上滿足UA和Proxy通信的信令完整性需求。
AccessGuard類是用于隔離對保護對象的訪問的類,通過在被保護對象上標(biāo)識{guard=AccessGuard}標(biāo)記,所有的對保護對象的訪問請求需先提交給AccessGuard類,AccessGuard類根據(jù)具體的訪問控制機制和訪問控制策略進行訪問權(quán)限的判定后,訪問請求才能在被保護對象上執(zhí)行。
Sender類和Receiver類可以針對業(yè)務(wù)對安全需求的不同控制粒度進一步細化,通過對send()方法的重載加以實現(xiàn)。如在調(diào)用send()方法時可以使用QoP[5,7](QualityofProtection)參數(shù)說明業(yè)務(wù)對安全功能的保護級別的需求。QoP體現(xiàn)了處理安全問題的開銷與安全保護需求之間的動態(tài)平衡。某一級別的QoP可以對應(yīng)于某一具體安全機制中所采用的加密算法強度、密鑰長度、認證機制強度等。但目前QoP的定義還依賴于具體的安全機制,且具有一定的隨意性,沒有一個客觀的標(biāo)準(zhǔn)。
在更細的粒度上,用戶可以在send()方法中指定具體安全機制的相關(guān)參數(shù),對所使用的安全機制進行更精確的控制。
圖5是對通信機密性進行保護的安全能力抽象類的類圖。其send()方法應(yīng)能保證消息的加密傳輸。Receiver類的receive()方法用于接收并解密消息。同完整性保護一樣,更加細致和更加可控的機密性保護可通過對send()和receive()方法的重載實現(xiàn)。
除了圖4和圖5中列舉的用于保護通信完整性和機密性以及實體訪問控制的安全能力抽象類外,還可以根據(jù)業(yè)務(wù)的實際安全需求抽象更多的安全能力抽象類。每個類實現(xiàn)某一特定的安全功能,如可以在多媒體會議中定義群密鑰管理功能抽象類,用于滿足群密鑰生成、分發(fā)與認證的功能。
圖5 消息機密性安全功能類
二、業(yè)務(wù)安全的實現(xiàn)機制
基于上述分析,可以將NGN業(yè)務(wù)的安全需求從安全特性上加以劃分并進行抽象,形成一系列細粒度的安全功能抽象類。通過對每一個安全功能抽象類的實現(xiàn)可以滿足業(yè)務(wù)的安全需求。文獻[8]提出了一種基于模型驅(qū)動的細粒度的訪問控制框架AC-PIM,將一個統(tǒng)一的高層的訪問控制模型(AC-PIM)映射到多種具體的訪問控制機制中,如OASIS的SAML(SecurityAssertionMarkupLanguage)和XACML(eXtensible
Access Control Markup Language),OMG的RAD(Resource Access Decision
Facility)以及Java Authentication and Authorization中定義的Java訪問控制模型。AC-PIM提供了一個實現(xiàn)圖4中的AccessGuard抽象類的途徑。
下面說明如何利用GSS-API實現(xiàn)保證通信完整性的安全能力抽象類,通過狀態(tài)圖說明保證通信完整性的Sender類的send()方法及Receiver類的receive()方法的GSS-API實現(xiàn)。本文中給出的是一個示意性的說明,忽略了一些錯誤處理過程。
圖6中,在send()方法被調(diào)用后,Sender首先檢測是否已有可用的安全上下文,如果可用的安全上下文已經(jīng)存在,則可以利用該上下文的句柄作為參數(shù)之一,調(diào)用GSS-API的Get_GetMIC()方法。參數(shù)還包括有待進行簽名的消息和可選的QoP。如果對消息簽名可以正常完成,Sender就可以將消息與簽名后生成的token一起送到目的地。如果簽名發(fā)生異常,則可以通過返回的錯誤碼判斷原因。
圖6 {integrity}Sender的GSS-API實現(xiàn)
如果在調(diào)用GSS_GetMIC()方法之前不存在可用的安全上下文,則Sender需要首先與Receiver之間建立安全上下文,通過安全機制信息的交互建立好安全上下文后可以繼續(xù)調(diào)用GSS_GetMIC()方法對需要發(fā)送的消息簽名。
通信完整性抽象類Receiver用于對消息完整性進行檢測,過程如圖7所示。經(jīng)過GSS_VerifyMIC()方法檢測接收到的消息及其簽名是否一致以判定其完整性。如果沒有合適的上下文可用,則應(yīng)先建立安全上下文然后再調(diào)用GSS_VerifyMIC()。
圖7 {integrity}Receiver的GSS-API實現(xiàn)
如果需要實現(xiàn)的機密性保護,則Sender類和Receiver類的約束用{secrecy}表示?赏ㄟ^GSS-API的GSS_Warp()方法和GSS_Unwrap()方法實現(xiàn)Sender和Receiver的安全功能。
Sender和Receiver還可以通過NGSS-API來實現(xiàn)。NGSS-API是ParlayAPI架構(gòu)下的安全應(yīng)用接口,對網(wǎng)絡(luò)的安全能力進行抽象,并為業(yè)務(wù)提供安全能力。NGSS-API中提供了IpCredentialManager、IpContextManager、IpContext等類分別用于管理證書、管理安全上下文以及基于安全上下文的完整性、機密性等網(wǎng)絡(luò)中的安全機制提供的安全能力。使用NGSS-API實現(xiàn)通信的完整性、機密性保護的過程與GSS-API類似。
GSS-API和NGSS-API都可用于實現(xiàn)根據(jù)業(yè)務(wù)安全需求抽象出的安全功能抽象類。GSS-API通常由本地的程序語言類庫實現(xiàn),適合于運行在終端和網(wǎng)絡(luò)實體上的業(yè)務(wù)實例使用,保證本地與目的地交互的安全性。NGSS-API基于ParlayAPI,主要面向應(yīng)用服務(wù)器等第三方業(yè)務(wù)實體,適合于運行在應(yīng)用服務(wù)器上、與Parlay網(wǎng)關(guān)進行交互的業(yè)務(wù)實例使用,其安全需求通過Parlay網(wǎng)關(guān)協(xié)調(diào)網(wǎng)絡(luò)中的實體實現(xiàn),保證整體的安全性。GSS-API考慮的安全粒度是消息級的,而NGSS-API考慮的安全粒度相對要大一些,從應(yīng)用服務(wù)器業(yè)務(wù)邏輯的視點出發(fā),保證一個呼叫方或一個用戶接口的安全性。
GSS-API和NGSS-API都獨立于具體的安全機制,可以采用不同的安全機制和安全協(xié)議實現(xiàn)。
三、結(jié)語
本文根據(jù)NGN的網(wǎng)絡(luò)特點對UMLsec進行了擴展,利用擴展后的UMLsec對NGN的網(wǎng)絡(luò)環(huán)境和業(yè)務(wù)的安全需求進行了分析。將NGN業(yè)務(wù)的安全需求抽象成細粒度的安全能力抽象類,用UMLsec加以描述,通過這些類的組合完整表達NGN業(yè)務(wù)所需的安全特性。通過對安全能力抽象類的實現(xiàn)可以滿足NGN業(yè)務(wù)的安全需求。本文通過用例說明了如何利用安全應(yīng)用接口實現(xiàn)安全能力抽象類;诎踩珣(yīng)用接口的實現(xiàn)與具體安全機制的細節(jié)無關(guān),且具有可移植性,使得業(yè)務(wù)的安全特性在不同的環(huán)境下可通過不同的安全機制實現(xiàn)。下一步的研究工作將包括對業(yè)務(wù)可用性等安全特征進行建模,并完善需求模型與實現(xiàn)模型之間的轉(zhuǎn)換規(guī)則,以實現(xiàn)模型之間的自動轉(zhuǎn)換與驗證。
下一代廣電網(wǎng)有多少值得期待? 2009-03-24 |
NGN技術(shù)在大型企業(yè)中的應(yīng)用 2009-03-23 |
FTTx將成為下一代網(wǎng)絡(luò)基礎(chǔ) 2009-03-23 |
NGN:邁向更高速率、更好質(zhì)量 2009-03-17 |
NGN領(lǐng)域:接入網(wǎng)光纖化是NGN建設(shè)重點 2009-03-13 |