基于RBAC的權限復雜性與可靠性控制模型研究

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

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

0 引 言

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

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

1 系統權限分析

1.1 數據庫權限配置

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

表1 Oracle訪問參數表

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

1.2 業務系統權限分析

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

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

圖1 數據庫交互模型

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

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

圖2 用戶-角色-權限-資源關系

2 RBAC層次模型

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

2.1 RBAC0層分類

在系統中的所有最小粒度權限，可分為五個類別：用戶類(U)、角色類(R)、對象類(O)、操作類(J)、許可類(P)。這些最小粒度權限用RBAC0表示。五個類別權限相互之間可定義1 ∶N，M∶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

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

2.2 RBAC1繼承關系

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

2.3 RBAC2約束關系

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

2.4 RBAC3復合關系模型

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

2.5 RBAC-權限集模型分析

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

圖3 用戶-角色-組關系

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

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

2.6 RBAC分層模型分析

2.6.1便于授權管理

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

2.6.2角色劃分

RBAC將角色組織起來，能夠很自然地反映組織內部人員之間的職權、責任、賦予關系，也可以使用類似PowerDesigner的工具，導出權限關系，為系統權限設置優化提供參考。

2.6.3賦予最小權限原則

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

2.6.4職責分離

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

3 權限治理策略

權限治理策略主要是建立在系統穩定的基礎上，將權限劃分為三個治理方向：可靠性策略、復雜性策略、權限修正。

3.1 可靠性計算

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

表2 SRGM特點

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

(1)

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

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

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

N0=N0-1

(2)

在一個時間間隔內，產生錯誤數與系統中剩余錯誤個數成正比，設Ne為產生錯誤數，Nr為剩余錯誤數，存在一個常數φ使Ne與Nr線性相關。設該比例為:

(3)

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

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

(4)

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

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

(5)

可靠性度量函數為：

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

(6)

在不同業務系統中，發生錯誤的概率有所不同，比如，一般權限集與管理權限集產生的錯誤不同，概率分布函數用式(7)表示。

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

(7)

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

由可靠性度量函數得似然函數:

(8)

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

(9)

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

(10)

(11)

(12)

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

(13)

式中：T表示總時間。

(14)

3.2 復雜度計算

本文將對系統中所有權限進行復雜性分析，目的是在不同規模的系統中，提供相應的權限設置。如果系統規模太小，又設置了太復雜的權限，對系統的管理提出了挑戰；如果系統規模太大，權限設置太簡單，系統的安全性又得不到保障。在2.1節中，梳理了權限關系，這為復雜性計算提供了重要參考。

文獻[15]提出了一種基于數據的復雜性計算方法，該方法中，提出的數據結構復雜性表征方法對本文有重要借鑒意義，對其進行修改后，可用于計算權限復雜性。

3.2.1類權限復雜性

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

(15)

則類權限復雜性計算式：

(16)

(17)

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

3.2.2系統總權限復雜度

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

圖4 RBAC0層元素關系

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

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

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

系統權限總復雜度為：

L=Libt+Libs

(18)

系統權限復雜度由初始化階段計算得到，此后當權限發生更改，則重新計算一次。

3.3 權限修正

(19)

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

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

圖5 系統權限修正流程

4 實驗分析

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

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

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

(4)進行系統修正修復后，P≥J，否則迭代權限修正。

4.1 實驗一：建立權限模型

本實驗實現了一個內網管理系統，主要功能是實現對內網成員上網權限管理，采用drupal內核二次開發，權限表保存在Oracle數據庫中，權限表結構如下。

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

表3 系統權限表清單

表4 對象表

表5 操作權限表

表6 操作類權限表

表7 用戶權限表

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

表8 用戶權限視圖表

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

表9 單位權限視圖表

表10 角色權限視圖表

表11 許可類權限表

以上表保存了系統所有權限，并且按照RBAC進行了規范處理。生成權限表以及相關權限關系，使用SQL語句；限于篇幅，這里只展示對象權限表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");

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

圖6 權限關系圖

4.2 實驗二：可靠性實驗

本實驗的軟硬件環境如表12所示。

表12 運行環境參數

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

表13 樣本參數

續表13

圖7 可靠性計算實驗結果

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

4.3 實驗三：復雜性實驗

4.3.1關系復雜度實驗

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

圖8 關系復雜度計算結果

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

4.3.2權限元素量復雜度實驗

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

圖9 權限元素量復雜度實驗結果

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

5 結 語

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

治理策略從三個方向對系統權限進行了梳理：

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

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

(3)權限修正。這是在問題發生后，對錯誤原因進行排查，此時需要人工介入，非權限原因導致的系統問題不列入修正內容。修正后重新對可靠性與復雜性進行計算，得出系統穩態值，如果穩態值低于宕機前，則迭代修復過程。

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