基于角色的授權(quán)與訪問控制的研究

1、基于角色的授權(quán)與訪問控制的研究         關(guān)鍵詞  RBAC；角色；權(quán)限；用戶；訪問控制     1  引言    隨著計算機網(wǎng)絡(luò)技術(shù)和信息技術(shù)的迅速發(fā)展，通過網(wǎng)絡(luò)傳輸和處理的信息和數(shù)據(jù)越來越多，需要進行訪問控制的資源數(shù)量迅速擴大，訪問控制的難度不斷增加，對系統(tǒng)資源訪問控制的要求也越來越高。    在網(wǎng)絡(luò)和分布式應(yīng)用環(huán)境下，對于安全性要求較高的信息資源，既要求能夠由信息資源的管理部門統(tǒng)一進行管理，確保

2、信息資源受控、合法、安全地使用，又需要授權(quán)管理和訪問控制的復(fù)雜度不能因為資源和用戶數(shù)量的增長而迅速增加，以確保授權(quán)和訪問控制的可管理性，實現(xiàn)統(tǒng)一、高效、靈活的訪問控制。傳統(tǒng)的訪問控制機制，如自主訪問控制（DAC，Discretionary Access Control）、強制訪問控制（MAC，Mandatory Access Control）等已遠遠不能滿足訪問控制的上述要求。    20世紀90年代以來發(fā)展起來的基于角色的訪問控制（RBAC，Role Based Access Control）技術(shù)可以減少授權(quán)管理的復(fù)雜度，降低管理開銷，提高訪問控制的安全性，而且

3、能夠?qū)崿F(xiàn)基于策略的授權(quán)和訪問控制。    2  基于角色的授權(quán)與訪問控制的框架圖1 基于角色的訪問控制框架模型    2.1  RBAC模型中名詞定義    1) 對象（object）    對象是信息系統(tǒng)為用戶提供服務(wù)所必需擁有和使用的一種資源，也是信息系統(tǒng)訪問控制的目標。對象的范圍很廣，可以是具體的數(shù)據(jù)庫記錄、文件目錄、EJB方法或網(wǎng)頁頁面，也可以是一個業(yè)務(wù)功能或業(yè)務(wù)流程，甚至是應(yīng)用系統(tǒng)。    2) 角色（role）&#

4、160;   角色是對用戶擁有的職能和權(quán)限的一種抽象。根據(jù)機構(gòu)、部門、崗位和職稱、職務(wù)的設(shè)置，可以確定能夠訪問信息系統(tǒng)的各種角色，并根據(jù)用戶的職責和權(quán)限將一組角色分配給用戶，以便用戶能夠擁有訪問系統(tǒng)所必需的權(quán)限。    3) 權(quán)限（privilege）    權(quán)限是授予用戶訪問系統(tǒng)中特定對象，對對象執(zhí)行特定操作的一種能力。權(quán)限可以描述為對指定的對象是否能夠進行指定的操作，是否能夠創(chuàng)建一個文件。    4) 用戶（user）    指信息系統(tǒng)的使用者和參與者

5、，根據(jù)信息系統(tǒng)的安全要求，他們需要被授予一定的權(quán)限，并根據(jù)權(quán)限訪問系統(tǒng)，使用、處理和操作允許的對象。    5) 會話（session）    會話表示的是用戶和角色之間的關(guān)系。用戶每次必須通過建立會話來激活角色，得到相應(yīng)的訪問權(quán)限。    6) 約束（Constraints）    模型中的約束在具體應(yīng)用中可體現(xiàn)為職責分離關(guān)系（Separation of Duty），用于控制沖突（Conflict）。靜態(tài)職責分離（Static SD）指定角色的互斥關(guān)系，用于用戶指派階段，避

6、免同一用戶擁有互斥的角色。實現(xiàn)簡單，角色互斥語義關(guān)系清楚，便于管理，不夠靈活，不能處理某些實際情況。動態(tài)職責分離（Dynamic SD）指定角色的互斥關(guān)系，用于角色激活階段。允許同一用戶擁有某些互斥的角色，但是不允許該用戶同時激活互斥的角色。更靈活，直接與會話掛鉤，適應(yīng)實際管理需要，實現(xiàn)復(fù)雜，不易管理。    2.2  基于角色訪問控制的基本思想    基于角色的訪問控制的基本思想就是把對用戶的授權(quán)分成兩部分，用角色來充當用戶行使權(quán)限的中介。這樣，原本在用戶和權(quán)限之間的分配關(guān)系就變成了用戶與角色之間，以及角色與權(quán)限之間兩個多

7、對多的分配關(guān)系：    用戶角色分配：也稱用戶角色授權(quán)。用戶與角色之間是多對多的關(guān)系，即一個用戶可以被分配給多個角色，多個用戶也可以分配給同一個角色。    權(quán)限角色分配：也成角色特權(quán)授權(quán)。角色與權(quán)限之間同樣也是多對多的關(guān)系，即一個權(quán)限可以與多個角色相關(guān)，一個角色也可以包含多重權(quán)限。    系統(tǒng)提供角色定義工具允許用戶根據(jù)自己的需要（職權(quán)、職位以及分擔的權(quán)利和職責）定義相應(yīng)的角色，即將不同權(quán)限分配給不同的角色。角色之間有相應(yīng)的繼承關(guān)系，當一個角色r2繼承了另一個角色r1時（記為r1->r2），r2就

8、自動擁有了r1的訪問權(quán)限。角色繼承關(guān)系自然地反映了一個組織內(nèi)部權(quán)利和職責的關(guān)系，為方便權(quán)限管理提供了幫助。角色繼承關(guān)系提供了對已有角色的擴充和分類的手段，使定義新的角色可以在已有的角色的基礎(chǔ)上進行，擴充就是通過增加父角色的權(quán)限去定義子角色，分類通過不同子角色繼承同一父角色來實現(xiàn)。另外，還允許多繼承，即一個角色繼承多個父角色，如圖2，角色r3繼承了r1和r5的權(quán)限，這種多繼承體現(xiàn)了對角色的綜合能力。角色的繼承關(guān)系如圖2所示。圖2 角色繼承關(guān)系    在角色定義好之后，將相應(yīng)的角色分配給對應(yīng)的用戶，從而使用戶獲得權(quán)限。在給用戶分配角色時可以采用組角色分配的方法來減少用

9、戶角色的分配量。組是一系列用戶所組成的集合。直接給具有相同權(quán)限的用戶所組成的用戶組分配角色，使得該用戶組下的所有用戶都擁有相應(yīng)的權(quán)限，避免了給多個用戶分別分配相同角色的重復(fù)工作。    3  基于角色的授權(quán)與訪問控制系統(tǒng)的實現(xiàn)    下面以一個辦公自動化公文系統(tǒng)為例來具體介紹基于角色的訪問控制系統(tǒng)的設(shè)計。這個即將建立的基于角色的訪問控制的公文系統(tǒng)包括：電子公告牌系統(tǒng)、電子郵件系統(tǒng)和電子公文系統(tǒng)。     3.1  辦公系統(tǒng)的角色定義     辦公系統(tǒng)中一個

10、用戶的角色，即其權(quán)限由以下幾類信息組合而成：用戶的行政級別、用戶所屬（轄）部門以及用戶的業(yè)務(wù)角色。     用戶的級別從縱向以較粗的粒度來界定用戶，級別的例子如局長、處長、一般員工，不同級別的用戶具有不同的權(quán)限。     用戶所屬（轄）部門則從另一個維度來定義用戶的職權(quán)范圍。在保密單位的辦公系統(tǒng)的安全需求中，一個原則是用戶只能查看和處理其業(yè)務(wù)范圍內(nèi)的事情，這個業(yè)務(wù)范圍就是通過用戶所屬（轄）部門來表示的。     系統(tǒng)提供的一種靈活的控制是通過業(yè)務(wù)角色這個概念來實施的。業(yè)務(wù)角色可以定義得相當細，用來描述上述

11、級別和部門兩種概念無法定義的權(quán)限。在某些具體的業(yè)務(wù)中，存在某些特殊的用戶具有特殊的職權(quán)，如公文處理中的機要員，這種特殊的職權(quán)無法用上述的級別和范疇的概念來表達，比如機要員和外收發(fā)人員都屬于一般工作人員，并且都屬于同一個部門，但是他們在公文處理中的職權(quán)就有明顯的不同，因此我們引入業(yè)務(wù)角色的概念。業(yè)務(wù)角色是針對某項具體業(yè)務(wù)的一個權(quán)限的集合，一個用戶在不同的業(yè)務(wù)中可能負責不同的職能，因此允許一個用戶具有多個業(yè)務(wù)角色。     3.2  具體實現(xiàn)     如何根據(jù)應(yīng)用的需求采用恰當?shù)姆绞浇⒂脩艚巧珯?quán)限這三者之間多對多的映射關(guān)系，將

12、是整個辦公自動化系統(tǒng)安全可靠和高效運行的關(guān)鍵。此外，所建立的映射關(guān)系應(yīng)提供靈活的配置功能，使映射關(guān)系具有可更改和可擴充性，以適應(yīng)可能變化的應(yīng)用需求，同時還可根據(jù)某些特殊需求來進行動態(tài)授權(quán)。     為了實現(xiàn)基于角色的訪問控制，這里定義了四張表來實現(xiàn)對象到權(quán)限、角色到用戶、角色到權(quán)限的分配，如表1、2、3、4所示。 表1對象信息表編號數(shù)據(jù)項標識數(shù)據(jù)項名稱類型長度可否為空1.    OBJINDEX對象索引碼INT 否、主鍵、唯一2.    OBJNAME對象名稱CHAR128否3. &#

13、160;  OBJSECL對象安全級別CHAR2是4.    OBJOPRG對象開放范圍CHAR2是5.    OBJTYPE對象類別CHAR4否 表2權(quán)限信息表編號數(shù)據(jù)項標識數(shù)據(jù)項名稱類型長度可否為空1PERINDEX權(quán)限索引碼INT 否、主鍵、唯一2PERJNAME權(quán)限名稱CHAR128否3OPR_OBJ操作對象CHAR128是4PERTYPE權(quán)限類型CHAR4是表3角色權(quán)限信息表編號數(shù)據(jù)項標識數(shù)據(jù)項名稱類型長度可否為空1.       RO

14、LEINDEX基本角色索引碼INT 否、主鍵、唯一2.       ROLENAME基本角色名稱CHAR64否3.       ROL_PER角色擁有的權(quán)限CHAR128否 表4 用戶權(quán)限信息表編號數(shù)據(jù)項標識數(shù)據(jù)項名稱類型長度可否為空1 USERINDEX用戶索引碼INT 否、主鍵、唯一2USERNAME用戶名稱CHAR64否3USERLEVEL用戶級別CHAR8是4USER_ROLE用戶擁有的角色CHAR128否  

15、;  在用戶申請某操作時候，系統(tǒng)需要檢測用戶所擁有的角色集合，并且根據(jù)這些角色集合所包含的權(quán)限來判斷該用戶是否可以進行該操作，如果可行則置許可證發(fā)放標志為真，這種方式稱為用戶牽引方式。同時，系統(tǒng)為了執(zhí)行某些靜態(tài)約束，比如同一用戶不能屬于兩個互斥的角色，還定義了互斥角色表。 3.3  相關(guān)權(quán)限管理     (1) 動態(tài)授權(quán)與動態(tài)約束     基于角色的訪問控制中用戶所擁有的權(quán)限具有相對的穩(wěn)定性，但在公文處理中往往會出現(xiàn)某些特殊事件需要做特殊的處理，動態(tài)授權(quán)機制用來反映這一需求。    

16、例如，用戶1出差，需要用戶2在其出差期間代理其部分業(yè)務(wù)工作，這就需要用戶2在限定的一段時間內(nèi)獲得他權(quán)限之外的權(quán)限。     約束是基于角色的訪問控制中重要的安全策略，是對用戶執(zhí)行權(quán)限的一些限制。靜態(tài)約束在系統(tǒng)設(shè)計時定義，而動態(tài)約束在系統(tǒng)運行時執(zhí)行。所謂動態(tài)授權(quán)就是系統(tǒng)在特殊工作狀態(tài)下，將用戶A的職權(quán)委托給用戶B的特殊授權(quán)方式。動態(tài)約束其實是依照相關(guān)模型的安全策略對動態(tài)授權(quán)進行相應(yīng)約束，防止動態(tài)授權(quán)濫用而帶來安全隱患。     (2) 集中授權(quán)管理     集中授權(quán)管理是在多種業(yè)務(wù)系統(tǒng)組合的復(fù)雜系統(tǒng)中，每個

17、業(yè)務(wù)系統(tǒng)集中在一個安全機構(gòu)進行授權(quán)的管理方式。    4  小結(jié)    基于角色的訪問控制技術(shù)實現(xiàn)了用戶與訪問權(quán)限的邏輯分離，將對訪問者的控制轉(zhuǎn)換為對角色的控制，從而使授權(quán)管理更為方便實用、效率更高。同時，角色與角色之間可以繼承權(quán)限，使各個角色的權(quán)限劃分更為清晰、明確，降低了權(quán)限管理的復(fù)雜性，提高了管理效率。    參考文獻1 Ferraiolo D, Kuhn R. Role-Based access controls. In: Proceedings of the 15th NIST-NCS

18、C National Computer Security Conference. 1992. 554563. 2 Coulouris G, Dollimore J, Roberts M. Role and task-based access control in the PerDiS groupware platform. In: Proceedings of the ACM Workshop on Role-Based Access Control. George Mason University, 1998. 115121.3 OASIS, Core and Hierarchical Role Based Access Control (RBAC) profile of XACML, Version 2.0, Committee draft 01. 16 Septe