楊福軍 丁 濤 付 眸 張培紅 周 鑄

(中國空氣動力研究與發(fā)展中心計算空氣動力研究所 四川 綿陽 621000)

0 引 言

隨著計算機領(lǐng)域不斷延伸到各行各業(yè)，系統(tǒng)權(quán)限的復雜度不斷增加。在特定的業(yè)務場景中，業(yè)務系統(tǒng)權(quán)限通常指用戶具有對計算機軟硬件資源的訪問、修改、使用等權(quán)力。例如，在Windows操作系統(tǒng)中，將用戶分為了管理員、一般用戶、游客、網(wǎng)絡(luò)訪問用戶等類別，不同類別具有不同的權(quán)限[1]。傳統(tǒng)的DAC權(quán)限管理一定程度上減輕了權(quán)限配置負擔，但隨著用戶的增多，權(quán)限管理也會越來越復雜，往往需要專人負責權(quán)限的規(guī)劃、分配、管理、監(jiān)控等事務。文獻[2]提出了一種DAC(Discretionary Access Control)到RBAC的遷移方法，但該方法只是對DAC進行了兼容，面對大型系統(tǒng)，仍然存在很多問題。因此，我們需要更好的權(quán)限管理方法，尤其是隨著各業(yè)務系統(tǒng)加入網(wǎng)絡(luò)，對于用戶的隱私泄露的問題也亟需解決[3]。

基于角色訪問控制的系統(tǒng)權(quán)限管理方法，在一定程度上給系統(tǒng)權(quán)限的管理帶來方便，但角色管理方法也存在一些潛在問題：(1)關(guān)鍵角色可同時被賦予多個用戶而導致沖突；(2)角色繼承后缺乏權(quán)限管理的安全性；(3)沒有考慮各類系統(tǒng)設(shè)計實現(xiàn)RBAC模型時，權(quán)限管理功能的復雜性問題[4]，可能造成人為的數(shù)據(jù)的泄露、丟失和篡改；(4)不當?shù)臋?quán)限配置還可能導致系統(tǒng)宕機。在云計算領(lǐng)域，權(quán)限管理不僅需要更多靈活性，還要保證數(shù)據(jù)安全性[5]。例如，通常Software-as-a-service云是使用多租戶方式，既要保證數(shù)據(jù)安全，又要防止內(nèi)部攻擊導致服務崩潰[6]。文獻[7]提出了一種在云環(huán)境中的CRUAC(Role and Usage based Access Control in Cloud Computing)訪問控制模型，主要從用戶管理、約束管理、資源管理、授權(quán)管理4個角度的權(quán)限控制管理。

1 系統(tǒng)權(quán)限分析

1.1 數(shù)據(jù)庫權(quán)限配置

在現(xiàn)代業(yè)務系統(tǒng)中，一般會將權(quán)限信息保存于數(shù)據(jù)庫中，數(shù)據(jù)庫相對于業(yè)務系統(tǒng)，具有獨立的權(quán)限管理機制[8]，比如Oracle數(shù)據(jù)庫權(quán)限管理非常龐大復雜。應用程序訪問后臺數(shù)據(jù)庫時，一般會讀取配置文件中設(shè)置的數(shù)據(jù)庫的配置參數(shù)，數(shù)據(jù)庫的連接方式都有相同范式，Oracle連接參數(shù)如表1所示。

表1 Oracle訪問參數(shù)表

數(shù)據(jù)庫系統(tǒng)往往與業(yè)務系統(tǒng)分開，通常成熟的大型數(shù)據(jù)庫系統(tǒng)有特殊的權(quán)限管理方法，可將操作權(quán)限細分到行級。數(shù)據(jù)庫系統(tǒng)為業(yè)務系統(tǒng)提供數(shù)據(jù)存儲服務，往往使用中間件進行連接。成功建立連接后，中間件會與Oracle建立會話進程，操作系統(tǒng)會分配一段內(nèi)存作為此次會話的緩沖區(qū)，直到連接關(guān)閉、會話結(jié)束。在實際業(yè)務場景中，業(yè)務系統(tǒng)往往會并發(fā)與數(shù)據(jù)庫建立多個連接，生成多個會話，連接持有的權(quán)限也各不相同，此時的權(quán)限概念與業(yè)務系統(tǒng)的權(quán)限概念不同，在數(shù)據(jù)庫系統(tǒng)中的權(quán)限使用內(nèi)部權(quán)限管理方式，與業(yè)務系統(tǒng)分離。

1.2 業(yè)務系統(tǒng)權(quán)限分析

數(shù)據(jù)庫系統(tǒng)為業(yè)務系統(tǒng)提供了數(shù)據(jù)存儲服務，同時，業(yè)務系統(tǒng)中的權(quán)限也以表的形式保存于數(shù)據(jù)庫系統(tǒng)，通過DBMS本身的用戶管理模式，如果給每個用戶建立一個登錄數(shù)據(jù)庫的用戶，用戶的授權(quán)工作由數(shù)據(jù)庫管理員實施和維護;每增加一個用戶，都需要在數(shù)據(jù)庫中也增加相應用戶，并賦予相應權(quán)限；隨著系統(tǒng)的不斷擴展，權(quán)限維護工作會愈發(fā)繁重。

在一個成熟的業(yè)務系統(tǒng)中，管理員與數(shù)據(jù)庫的交互一般采用網(wǎng)頁/客戶端的交互模式，即需要中間應用服務器建立連接并操作數(shù)據(jù)庫(見圖1)。從數(shù)據(jù)庫系統(tǒng)的角度來看，業(yè)務系統(tǒng)的權(quán)限也是一種數(shù)據(jù)，以表的形式保存在數(shù)據(jù)庫。這些特定的權(quán)限表保存著業(yè)務系統(tǒng)中的所有使用人員、權(quán)限分配方式、訪問控制等信息，因此權(quán)限表的安全性特別重要。

圖1 數(shù)據(jù)庫交互模型

權(quán)限管理包含兩部分內(nèi)容:(1)對數(shù)據(jù)資源進行篩選過濾，只將有限的數(shù)據(jù)開放給用戶；(2)用戶對這些開放的資源是否具有增加、刪除、修改、查詢的權(quán)限。在本文中，把數(shù)據(jù)權(quán)限定義為對表的訪問權(quán)控制，又分為行控制和列控制。比如，當要求用戶只能操作自己的數(shù)據(jù)時，需要進行行控制；當要求用戶不能看到其他數(shù)據(jù)的來源信息時，需要進行列控制[9]。

同時，對每個權(quán)限賦予有效期限，在有效期內(nèi)，權(quán)限才有效，未做特別時間約束的權(quán)限會一直有效。將時間、身份特征段作為權(quán)限的屬性，設(shè)計完善從訪問控制模型、基于屬性的密文訪問控制和外包數(shù)據(jù)的訪問控制三個方面的權(quán)限方法可極大增加系統(tǒng)安全性[10]。一些大型業(yè)務系統(tǒng)不僅權(quán)限數(shù)量多，而且權(quán)限種類多種多樣，還需要經(jīng)常變化，于是對權(quán)限進行分門別類，就產(chǎn)生了角色(Role)的概念。角色是某一類權(quán)限的集合。綜上所述，總結(jié)出了用戶、角色、權(quán)限和資源的關(guān)系如圖2所示。

圖2 用戶-角色-權(quán)限-資源關(guān)系

2 RBAC層次模型

通常RBAC模型由4個子權(quán)限模型組成，分別是基本權(quán)限模型RBAC0、角色分級權(quán)限模型RBAC1、角色限制權(quán)限模型RBAC2和統(tǒng)一權(quán)限模型RBAC3[11]。

2.1 RBAC0層分類

在系統(tǒng)中的所有最小粒度權(quán)限，可分為五個類別：用戶類(U)、角色類(R)、對象類(O)、操作類(J)、許可類(P)。這些最小粒度權(quán)限用RBAC0表示。五個類別權(quán)限相互之間可定義1 ∶N，M∶N關(guān)系，如下：

(1)U∶R=M∶N

(2)O∶J=1 ∶N

(3)R∶P=1 ∶N

(4)O∶P=1 ∶N

(5)J∶P=M∶N

權(quán)限被賦予角色,而不是用戶，當一個角色被指定給一個用戶時，此用戶就擁有了該角色所包含的權(quán)限。會話是用戶與激活的角色集合之間的映射。RBAC0與傳統(tǒng)訪問控制的差別在于增加一層間接性帶來了靈活性，RBAC1、RBAC2、RBAC3都是先后在RBAC0上的擴展[12]。

2.2 RBAC1繼承關(guān)系

RBAC1定義角色的繼承關(guān)系，繼承關(guān)系使得權(quán)限管理靈活性得到提升，從管理角度出發(fā)，管理者擁有普通員工的權(quán)限，也擴展相應職能特權(quán)，則管理者繼承了普通員工權(quán)限[13]。RBAC1也可實現(xiàn)多繼承關(guān)系，進一步提升角色間權(quán)限賦予的靈活性。

2.3 RBAC2約束關(guān)系

RBAC2定義了權(quán)限約束關(guān)系，包括權(quán)限間繼承的約束、用戶指派角色的約束、活動用戶行使的權(quán)限范圍約束。在RBAC2中，具體訪問許可由用戶、角色、權(quán)限三者關(guān)系決定。RBAC2約束關(guān)系使得權(quán)限管理安全性提升，但過多的約束關(guān)系會使得RBAC1的繼承關(guān)系管理變得更加繁瑣。因此，RBAC2約束關(guān)系的定義應從總體需求出發(fā)進行規(guī)劃。

2.4 RBAC3復合關(guān)系模型

RBAC3是包含一系列復合關(guān)系的模型，是對角色-用戶關(guān)系的定義，關(guān)系模型為M∶N；稱為用戶角色分配和角色許可分配[14]。

2.5 RBAC-權(quán)限集模型分析

傳統(tǒng)的RBAC只針對用戶作為權(quán)限擁有者，用戶具有對資源、數(shù)據(jù)、網(wǎng)絡(luò)等操作的許可，RBAC1、RBAC2、RBAC3是用戶權(quán)限關(guān)系的集合。隨著業(yè)務系統(tǒng)的復雜性增加，本文將系統(tǒng)中一些用戶分組，提取分組用戶所有權(quán)限，稱為權(quán)限集，按照繼承關(guān)系-約束關(guān)系-復合關(guān)系分析組內(nèi)權(quán)限，計算復雜度，按復雜度進行權(quán)限修正。RBAC子權(quán)限集要滿足安全性、靈活性、便捷性三個特點，進一步分析梳理，確定參與權(quán)限集復雜運算的主要包含對象有：用戶數(shù)、角色、分組權(quán)限類別、RBAC層次權(quán)值、權(quán)限關(guān)系權(quán)重。主要的關(guān)系有：分配用戶(組)角色、分配角色權(quán)限;將用戶與權(quán)限通過角色隔離開,減少了用戶權(quán)限賦值關(guān)系太多時帶來的管理難度。用戶-角色-組關(guān)系如圖3所示。

圖3 用戶-角色-組關(guān)系

角色：一定數(shù)量的權(quán)限的集合。角色權(quán)限分配的原則是：不與其他角色所擁有的權(quán)限產(chǎn)生交集。在本模型中，角色權(quán)限來源于RBAC0層。

用戶組：用戶組與角色是M∶N的關(guān)系，即用戶組可以有多個角色，角色可以有多個用戶組。按照角色權(quán)限分配原則，在遇到1 ∶N關(guān)系時，用戶組需要進行并集運算，提取權(quán)限元素，避免角色之間產(chǎn)生權(quán)限交集。

2.6 RBAC分層模型分析

2.6.1便于授權(quán)管理

在傳統(tǒng)的訪問控制中，用戶或其職能發(fā)生變化時，需要進行大量的授權(quán)更改工作。在RBAC中，用戶的職能改變時，重新指定相關(guān)角色即可，而角色的權(quán)限一旦定義好,就很少去更改。要對角色的權(quán)限進行更改，只需要修改角色的功能或定義新角色，而不必更新每一個用戶的權(quán)限設(shè)置。

2.6.2角色劃分

RBAC將角色組織起來，能夠很自然地反映組織內(nèi)部人員之間的職權(quán)、責任、賦予關(guān)系，也可以使用類似PowerDesigner的工具，導出權(quán)限關(guān)系，為系統(tǒng)權(quán)限設(shè)置優(yōu)化提供參考。

2.6.3賦予最小權(quán)限原則

權(quán)限的分配應以實際業(yè)務需求為標準，即用戶盡可能分配職責規(guī)則的權(quán)限，避免用戶擁有冗余權(quán)限而帶來安全問題。本文分析了RBAC權(quán)限繼承、約束、復合關(guān)系，定義了關(guān)系間的分配原則，從不同維度解釋權(quán)限關(guān)系。

2.6.4職責分離

在一些業(yè)務場景，往往需要多個不同角色的用戶完成一項業(yè)務，例如企業(yè)流程審批，需要多個用戶參與。如果讓某一個用戶完成該業(yè)務處理，則該用戶需要賦予較大權(quán)限，這在一些金融、政府、軍隊等行業(yè)容易造成人為的安全事故。因此，對于某些特定的操作，需要進行職責分離，RBAC較為靈活地提供了該支持。

3 權(quán)限治理策略

權(quán)限治理策略主要是建立在系統(tǒng)穩(wěn)定的基礎(chǔ)上，將權(quán)限劃分為三個治理方向：可靠性策略、復雜性策略、權(quán)限修正。

3.1 可靠性計算

在軟件系統(tǒng)工程領(lǐng)域，廣泛使用可靠性增長模型(Software Reliability Growth Model，SRGM)進行建模分析故障數(shù)量、累積檢測率、排除故障數(shù)等數(shù)據(jù)[15]。SRGM研究的機理是對系統(tǒng)運行和測試過程中各隨機變量間建立適當?shù)臄?shù)學模型，通常SRGM有兩類：隨機過程與非隨機過程，如表2所示。

表2 SRGM特點

非隨機過程需要人為提前設(shè)計相關(guān)參數(shù)和用例，基于貝葉斯的SRGM需要收集系統(tǒng)研發(fā)過程中的測試用例和結(jié)果。本文中的權(quán)限配置模型不對具體的軟件開發(fā)過程進行研究，即面向系統(tǒng)成品中的權(quán)限配置。隨機過程中的執(zhí)行時間過程模型假定了故障間隔與時間服從某種概率關(guān)系[16]，其應用場景限制在了特定的環(huán)境中，比如在線購物商城、電力調(diào)度系統(tǒng)、電子支付等，但不適用于本文提出的權(quán)限控制模型。馬爾可夫與NHPP建立的模型都可根據(jù)已檢測故障計算出系統(tǒng)可靠性，NHPP在針對RBAC的權(quán)限配置過程中的計算，需要構(gòu)建有效的均值函數(shù)，設(shè)[N(t),t≥0]為隨機計數(shù)過程，N(t)為[0,t]內(nèi)累積檢測錯誤，NHPP如下：

(1)

式中：m(t)為均值函數(shù)。本文將RBAC進行了分層處理，定義了權(quán)限類關(guān)系；構(gòu)建均值函數(shù)需要對不同的關(guān)系類型，如1 ∶N、N∶M、1 ∶1等進行加權(quán)處理，將進一步引入加權(quán)函數(shù)，使得NHPP的計算更加復雜。文獻[15]對SRGM的研究現(xiàn)狀進行了分析比較，馬爾可夫模型滿足在不完美排錯環(huán)境下且符合新故障引入機制。本節(jié)主要參考文獻[17-18]基于馬爾可夫的JM方法進行數(shù)學建模。

設(shè)N0為權(quán)限集合中可造成安全事故的權(quán)限分配數(shù)，進一步定義為不合理權(quán)限分配、系統(tǒng)錯誤生、角色權(quán)限沖突(相同)。

排除安全事故后且沒有新的錯誤產(chǎn)生，則每次迭代運算時:

N0=N0-1

(2)

在一個時間間隔內(nèi)，產(chǎn)生錯誤數(shù)與系統(tǒng)中剩余錯誤個數(shù)成正比，設(shè)Ne為產(chǎn)生錯誤數(shù)，Nr為剩余錯誤數(shù)，存在一個常數(shù)φ使Ne與Nr線性相關(guān)。設(shè)該比例為:

(3)

設(shè)ti為0時刻到i時刻之間的錯誤時間間隔。發(fā)生第i-1個錯誤至第i個錯誤之間，失效(故障)函數(shù)可表示為：

μ(ti)=φ(N0-i+1)

(4)

造成權(quán)限配置出錯的原因大多在初始配置時刻，即這與初始安全人員的專業(yè)技能水平等因素相關(guān)，則存在強度函數(shù)，用以表示錯誤率發(fā)生強度，該函數(shù)為:

F(ti)=φ(N0-i+1)e-φ(N0-i+1)ti

(5)

可靠性度量函數(shù)為：

R(ti)=e-φ(N0-i+1)ti

(6)

在不同業(yè)務系統(tǒng)中，發(fā)生錯誤的概率有所不同，比如，一般權(quán)限集與管理權(quán)限集產(chǎn)生的錯誤不同，概率分布函數(shù)用式(7)表示。

Ι(ti)=1-e-φ(N0-i+1)ti

(7)

式(7)中φ與N0未知，使用最大似然法對φ與N0進行估算。

由可靠性度量函數(shù)得似然函數(shù):

(8)

式(8)進行對數(shù)運算，得：

(9)

對式(9)中的φ和N0求偏導：

(10)

(11)

(12)

式(12)進一步化簡(省略中間計算)得:

(13)

式中：T表示總時間。

(14)

3.2 復雜度計算

本文將對系統(tǒng)中所有權(quán)限進行復雜性分析，目的是在不同規(guī)模的系統(tǒng)中，提供相應的權(quán)限設(shè)置。如果系統(tǒng)規(guī)模太小，又設(shè)置了太復雜的權(quán)限，對系統(tǒng)的管理提出了挑戰(zhàn)；如果系統(tǒng)規(guī)模太大，權(quán)限設(shè)置太簡單，系統(tǒng)的安全性又得不到保障。在2.1節(jié)中，梳理了權(quán)限關(guān)系，這為復雜性計算提供了重要參考。

文獻[15]提出了一種基于數(shù)據(jù)的復雜性計算方法，該方法中，提出的數(shù)據(jù)結(jié)構(gòu)復雜性表征方法對本文有重要借鑒意義，對其進行修改后，可用于計算權(quán)限復雜性。

3.2.1類權(quán)限復雜性

類權(quán)限有五種：用戶類、角色類、操作類、對象類、許可類。每類有權(quán)限集合域{x1,x2,…,xn}，每個單位權(quán)限對系統(tǒng)總權(quán)限復雜度的平均信息量貢獻為:

(15)

則類權(quán)限復雜性計算式：

(16)

(17)

式中：Shannon對信息熵的定義，b通常取2；I(xi)為隨機變數(shù)；L為類權(quán)限復雜度。

3.2.2系統(tǒng)總權(quán)限復雜度

設(shè)每類權(quán)限集合域中有單位權(quán)限元素ni，則該類權(quán)限的復雜信息量為Li。如圖4所示，每類權(quán)限有三種關(guān)系：M∶N、1 ∶N(N∶1)、二元關(guān)系(1 ∶1)。分別對每種關(guān)系進行復雜度計算:

圖4 RBAC0層元素關(guān)系

(1)在權(quán)限集合域中有單位權(quán)限元素ni，則二元關(guān)系可表示為nib，Lib為二元關(guān)系復雜度。

(2)在權(quán)限集合域中有單位權(quán)限元素ni，二元關(guān)系可表示為nib，則M∶N關(guān)系復雜度為Libs。

(3)在權(quán)限集合域中有單位權(quán)限元素ni，二元關(guān)系可表示為nib，則1 ∶N關(guān)系復雜度為Libt[19]。

系統(tǒng)權(quán)限總復雜度為：

L=Libt+Libs

(18)

系統(tǒng)權(quán)限復雜度由初始化階段計算得到，此后當權(quán)限發(fā)生更改，則重新計算一次。

3.3 權(quán)限修正

(19)

式中：α為初始復雜度，該復雜度并不隨著權(quán)限更改而觸發(fā)計算，而是當有因為權(quán)限導致的安全事故時，重新觸發(fā)計算；β為業(yè)務系統(tǒng)未出現(xiàn)因權(quán)限導致安全事故的正常運行天數(shù)，系統(tǒng)無故障運行越久，則穩(wěn)定值越高。β初始值為0，當出現(xiàn)安全事故，則β=β-1，即前一天的穩(wěn)定態(tài)。如果P≥J，則系統(tǒng)處于穩(wěn)定態(tài)；如果P

圖5中，權(quán)限的修正與修復需要人工介入，該處可引入三員管理。即將超級管理員的權(quán)限進一步劃分為三部分，相互制約，避免了單一管理員權(quán)限過大，缺乏監(jiān)督和評審，造成人為的錯誤[20]。本文不對三員管理方式進行具體規(guī)約，但強調(diào)若按本文方法進行權(quán)限控制，三員管理中需要有一員權(quán)限為“管理權(quán)限的管理員”。

圖5 系統(tǒng)權(quán)限修正流程

4 實驗分析

(1)按照第2節(jié)的RBAC層次進行建模。建模主要使用PowerDesigner工具完成，并生成圖。

(2)計算出符合要求的權(quán)限可靠性值；因為可靠性值引入了時間因素，所以對參與的時間(單位:天)手工填寫，發(fā)生的系統(tǒng)錯誤也通過手工觸發(fā)。

(3)計算出總權(quán)限系統(tǒng)復雜度，并且隨著權(quán)限單元的增加，總復雜度也增加。

(4)進行系統(tǒng)修正修復后，P≥J，否則迭代權(quán)限修正。

4.1 實驗一：建立權(quán)限模型

本實驗實現(xiàn)了一個內(nèi)網(wǎng)管理系統(tǒng)，主要功能是實現(xiàn)對內(nèi)網(wǎng)成員上網(wǎng)權(quán)限管理，采用drupal內(nèi)核二次開發(fā)，權(quán)限表保存在Oracle數(shù)據(jù)庫中，權(quán)限表結(jié)構(gòu)如下。

系統(tǒng)權(quán)限表清單存儲系統(tǒng)中權(quán)限類，為了進一步細分，新增了三個視圖：操作權(quán)限表、用戶權(quán)限表、角色權(quán)限表。系統(tǒng)權(quán)限表、對象表、操作權(quán)限表、操作類權(quán)限表、用戶權(quán)限表如表3-表7所示。

表3 系統(tǒng)權(quán)限表清單

表4 對象表

表5 操作權(quán)限表

表6 操作類權(quán)限表

表7 用戶權(quán)限表

用戶權(quán)限與其他類別權(quán)限存在繼承關(guān)系，為了更加方便觀察用戶所有權(quán)限，建立了視圖如表8所示。

表8 用戶權(quán)限視圖表

為了更加方便觀察系統(tǒng)中所有權(quán)限，建立了單位權(quán)限視圖，該視圖中的權(quán)限為五類權(quán)限并集，單位權(quán)限表、角色權(quán)限表、許可類權(quán)限表如表9-表11所示。

表9 單位權(quán)限視圖表

表10 角色權(quán)限視圖表

表11 許可類權(quán)限表

以上表保存了系統(tǒng)所有權(quán)限，并且按照RBAC進行了規(guī)范處理。生成權(quán)限表以及相關(guān)權(quán)限關(guān)系，使用SQL語句；限于篇幅，這里只展示對象權(quán)限表SQL代碼:

CREATE TABLE "T_SAFE_RES" (

"SEQNUM_RES" INT NOT NULL,

"SEQNUM_TASK" INT,

"SEQNUM_TYPEDATA" INT,

"SEQNUM_DEPARTMENT" INT,CONSTRAINT

PK_T_SAFE_RES PRIMARY KEY("SEQNUM_RES"));

ALTER TABLE "T_SAFE_RES"

ADD CONSTRAINT

FK_T_SAFE_R_REFERENCE_T_LIST_T FOREIGN KEY

("SEQNUM_TASK")

REFERENCES "T_LIST_TASK"("SEQNUM_TASK");

ALTER TABLE "T_SAFE_RES"

ADD CONSTRAINT

FK_T_SAFE_R_REFERENCE_T_LIST_T FOREIGN KEY

("SEQNUM_TYPEDATA")

REFERENCES "T_LIST_TYPEDATA"

("SEQNUM_TYPEDATA");

ALTER TABLE "T_SAFE_RES"

ADD CONSTRAINT

FK_T_SAFE_R_REFERENCE_T_LIST_D FOREIGN KEY

("SEQNUM_DEPARTMENT")

REFERENCES "T_LIST_DEPARTMENT"

("SEQNUM_DEPARTMENT");

所有權(quán)限及權(quán)限關(guān)系建立后，使用PowerDesigner工具對以上各表進行分析，得到的權(quán)限關(guān)系圖如圖6所示。

圖6 權(quán)限關(guān)系圖

4.2 實驗二：可靠性實驗

本實驗的軟硬件環(huán)境如表12所示。

表12 運行環(huán)境參數(shù)

權(quán)限復合關(guān)系分析、權(quán)限的依賴關(guān)系分析、權(quán)限的繼承關(guān)系分析將消耗大量內(nèi)存，因此本實驗初始配置32 GB內(nèi)存，視實驗情況酌情增加。本實驗主要驗證RBAG在每一次權(quán)限修復后，可靠性值是否符合SRGM增長規(guī)律。

表13 樣本參數(shù)

續(xù)表13

圖7 可靠性計算實驗結(jié)果

計算結(jié)果表明，在不引入新的錯誤前提下，系統(tǒng)錯誤被不斷檢出、修正，可靠性得到不斷提升，并且計算出提升幅度。

4.3 實驗三：復雜性實驗

4.3.1關(guān)系復雜度實驗

在3.2節(jié)中，將權(quán)限關(guān)系復雜度列入總復雜度計算。本實驗在總權(quán)限單元不變的情況下，增加權(quán)限單元之間的關(guān)系，如圖6權(quán)限關(guān)系圖，取M∶N、1 ∶N、二元三種關(guān)系進行實驗，且每次實驗一種關(guān)系時，其他兩種關(guān)系取值為1。計算結(jié)果如圖8所示。

圖8 關(guān)系復雜度計算結(jié)果

隨著權(quán)限之間的聯(lián)系不斷增加，總復雜度也不斷提升，且復雜度M∶N>N∶1>二元，符合前文理論分析。通過實驗可知，隨著系統(tǒng)復雜度的增加，M∶N關(guān)系是增加權(quán)限復雜度的主要因素。

4.3.2權(quán)限元素量復雜度實驗

RBAC層次中定義了繼承關(guān)系，比如權(quán)限集a可以從權(quán)限集b中繼承n個權(quán)限元素。本實驗中，對于繼承關(guān)系a、b，取二者并集。同時，五個類別的權(quán)限每次實驗時，只取一種權(quán)限進行計算，其他四類權(quán)限數(shù)量限定為10，對于權(quán)限關(guān)系，只建立必要的連接，至少為1。實驗結(jié)果如圖9所示。

圖9 權(quán)限元素量復雜度實驗結(jié)果

以上實驗結(jié)果中，五個權(quán)限類復雜度呈上升趨勢，增量各有不同，這是因為權(quán)限類別中還存在依賴、繼承關(guān)系，導致對復雜度的貢獻值不同。

5 結(jié) 語

本文選用了RBAC模型，從不同維度對權(quán)限關(guān)系進行了論述，重新定義了權(quán)限之間的連接關(guān)系并建模。采用了JM數(shù)學模型對可靠性進行度量，改進了文獻[15]的復雜度算法，實驗結(jié)果表明，各項結(jié)果符合預期。

治理策略從三個方向?qū)ο到y(tǒng)權(quán)限進行了梳理：

(1)可靠性策略。主要是可靠性計算，這依賴系統(tǒng)運行中，因權(quán)限問題帶來的系統(tǒng)損壞、宕機、不同級別報警等錯誤的處理。

(2)復雜性策略。主要是通過對系統(tǒng)進行復雜性計算后，給出對于管理人員具有參考意義的值，同時也參與穩(wěn)定性計算。

(3)權(quán)限修正。這是在問題發(fā)生后，對錯誤原因進行排查，此時需要人工介入，非權(quán)限原因?qū)е碌南到y(tǒng)問題不列入修正內(nèi)容。修正后重新對可靠性與復雜性進行計算，得出系統(tǒng)穩(wěn)態(tài)值，如果穩(wěn)態(tài)值低于宕機前，則迭代修復過程。

本文對某些方面未做進一步研究，比如：權(quán)限修正過程可以劃分為更多維度進行計算；系統(tǒng)穩(wěn)定態(tài)算法也可以考慮更多變量，使得結(jié)果更精確。在本文中沒有改善的問題，可作為下一步研究方向，或為相關(guān)領(lǐng)域研究者提供些許思路。