王 倩,包 巖

（1.天津職業(yè)大學(xué)網(wǎng)絡(luò)中心,300402；2.天津鋼鐵集團(tuán)有限公司煉鋼廠檢修自動化組,300301）

1 訪問控制和RBAC

訪問控制是通過某種途徑顯式的準(zhǔn)許或者限制主體對客體訪問能力及范圍的一種方法，它是針對越權(quán)使用系統(tǒng)資源的防御措施，通過顯式的訪問受保護(hù)的資源，防止非法用戶的入侵或因為合法用戶的不慎操作所造成的破壞，從而保證系統(tǒng)資源受控地、合法的使用。訪問控制技術(shù)是網(wǎng)絡(luò)安全防范和信息資源保護(hù)的核心策略。

1996 年，美國George Mason 大學(xué)的Ravi S.Sandhu 等完整的描述了RBAC 基本框架。該模型包括用戶、角色和訪問權(quán)限3 個實體。其基本思想是在應(yīng)用系統(tǒng)中定義多種角色，每個角色涵蓋一種或者多種對資源的訪問權(quán)限，代表了用戶在系統(tǒng)內(nèi)可執(zhí)行的操作集合。單個用戶可屬于一個或多個角色，若用戶要獲得對某一類資源的訪問授權(quán)，先要授權(quán)具有訪問此類資源的角色。用戶與資源之間不建立直接關(guān)系，而是通過角色在用戶與資源之間建立聯(lián)系。

標(biāo)準(zhǔn)RBAC 模型由4 個部件模型組成，這4 個部件模型分別是基本模型RBAC0（Core RBAC）、角色分級模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和統(tǒng)一模型RBAC3（Combines RBAC）。RBAC0 模型如圖1 所示：

圖1 RBAC 0 模型

RBAC0 定義了能構(gòu)成一個RBAC 控制系統(tǒng)的最小的元 素 集 合。在RBAC 之 中, 包 含 用 戶users(USERS)、角 色roles(ROLES)、目標(biāo)objects(OBS)、操作operations(OPS)、許可權(quán)permissions(PRMS)五個基本數(shù)據(jù)元素，權(quán)限被賦予角色，而不是用戶，當(dāng)一個角色被指定給一個用戶時，此用戶就擁有了該角色所包含的權(quán)限。會話sessions 是用戶與激活的角色集合之間的映射。RBAC0 與傳統(tǒng)訪問控制的差別在于增加一層間接性帶來了靈活性，RBAC1、RBAC2、RBAC3 都是先后在RBAC0 上的擴(kuò)展。

RBAC1 引入角色間的繼承關(guān)系。角色間的繼承關(guān)系可分為一般繼承關(guān)系和受限繼承關(guān)系。RBAC2 模型中添加了責(zé)任分離關(guān)系，它的約束規(guī)定了權(quán)限被賦予角色時，或角色被賦予用戶時，以及當(dāng)用戶在某一時刻激活一個角色時所應(yīng)遵循的強制性規(guī)則。RBAC3 包含了RBAC1 和RBAC2。既提供了角色間的繼承關(guān)系，又提供了責(zé)任分離關(guān)系。建立角色定義表。因為有繼承的問題，所以角色體現(xiàn)出的是一個樹形結(jié)構(gòu)。

2 RBAC 在數(shù)字化校園體系中的應(yīng)用局限性

數(shù)字化校園中包含的業(yè)務(wù)管理系統(tǒng)包羅萬象：既包含面向功能科室類的：科研管理系統(tǒng)、人事管理系統(tǒng)等；還包含面向教學(xué)的：教務(wù)排課、考務(wù)管理系統(tǒng)等；在一定的時期還會有特殊功能系統(tǒng)：迎新管理系統(tǒng)、離校管理系統(tǒng)、獎學(xué)金管理系統(tǒng)等。并且隨著信息化的發(fā)展，新的管理系統(tǒng)還會陸續(xù)的加進(jìn)來。若采用RBAC 的角色控制方式來管理權(quán)限，就應(yīng)該考慮到目前乃至將來的可能會出現(xiàn)的情況，這是不可能做到的。另外，同屬于一個角色的用戶，其權(quán)限也會不同。隨著學(xué)校人事的變動，用戶的權(quán)限也同時改變，就要賦予他們新的角色，對于權(quán)限控制功能子系統(tǒng)來說，每次都是不小的維護(hù)工作量。最后，如果一個系統(tǒng)中定義的角色是特定的，其角色分類不能直接套用到其他管理系統(tǒng)中，也是缺乏通用性，會造成系統(tǒng)及資源的浪費。

3 一種改進(jìn)的擴(kuò)展權(quán)限模型

考慮到RBAC 模型在數(shù)字化校園體系中的局限性，在原權(quán)限模型中添加如下功能組合：

1）用戶組授權(quán)功能

用戶組是具有某一類共同特征的若干用戶組成的集合，一個用戶組可以包含許多不同的用戶，一個用戶可以分屬于多個不同的用戶組。將角色權(quán)限直接授權(quán)給用戶組而不是用戶，用戶繼承所在用戶組的角色，并且當(dāng)一個用戶同時屬于不同的用戶組時，它的角色是所屬用戶組角色的并集。

2）角色類型功能

建立一個角色類型表，每個角色可以歸屬一個角色類型，方便應(yīng)用程序的引用。

3）角色優(yōu)先功能

定義一個優(yōu)先級別表，給每個角色賦予優(yōu)先級別。在處理角色的請求時，根據(jù)角色的優(yōu)先級別排入鏈表里進(jìn)行處理，鏈表里的角色請求可以根據(jù)優(yōu)先級別的不同動態(tài)調(diào)整，系統(tǒng)在處理角色請求時，每次都從隊首取一個角色請求，再將隊首指針指向下一個角色請求。

4）角色生存周期功能

由于RBAC 是主客體的被動安全模型，在這種模型中授權(quán)是靜態(tài)的，主體一旦擁有某種權(quán)限在任務(wù)執(zhí)行完成會繼續(xù)擁有這種權(quán)限，沒有考慮到操作的上下文，這顯然對系統(tǒng)而言是極大的安全威脅。解決這種漏洞可以指定角色的生存時間，時間可以是用戶根據(jù)任務(wù)來設(shè)定的，也可以是根據(jù)某個條件來觸發(fā)決定的。

5）角色根據(jù)責(zé)任鏈動態(tài)變更權(quán)限功能

在一個責(zé)任鏈里，一個客戶程序發(fā)出請求，這個請求將沿著責(zé)任鏈進(jìn)行傳遞，責(zé)任鏈里的每個結(jié)點將依次處理該請求，如果結(jié)點不能處理該請求，則將此請求轉(zhuǎn)發(fā)到責(zé)任鏈的下一結(jié)點上；或者是，責(zé)任鏈中的每一個結(jié)點都對該請求進(jìn)行處理。在處理的過程中，角色的權(quán)限將根據(jù)需求動態(tài)變化。

6）角色根據(jù)狀態(tài)動態(tài)變更權(quán)限功能

在應(yīng)用系統(tǒng)中可能存在多種狀態(tài)，比如在一個應(yīng)用程序中，當(dāng)用戶狀態(tài)是鎖定時，和用戶狀態(tài)在活動時，它的功能是不一樣的，那么角色需要根據(jù)這種狀態(tài)的變更而動態(tài)變更權(quán)限集，以便適應(yīng)這種應(yīng)用程序的要求。

7）在功能權(quán)限的基礎(chǔ)上增加數(shù)據(jù)權(quán)限的管理功能

增加數(shù)據(jù)權(quán)限的管理功能，實現(xiàn)功能權(quán)限的數(shù)據(jù)權(quán)限處理。功能權(quán)限：用戶在系統(tǒng)中能做什么的問題，比如教師添加考生的考試科目，考生的考試成績，人事處下達(dá)考核指標(biāo)；數(shù)據(jù)權(quán)限：用戶在系統(tǒng)下能看到些什么的問題，比如：學(xué)生能看到自己的考試成績，看到自己下學(xué)期要學(xué)習(xí)的課程安排。

4 擴(kuò)展權(quán)限控制模型的研究與實現(xiàn)

圖2 權(quán)限管理流程圖

4.1 設(shè)計思路

將權(quán)限分為兩級，一級為初始登錄權(quán)限，即用戶門戶權(quán)限；另一級為訪問數(shù)字化校園各個功能子系統(tǒng)以及在子系統(tǒng)間跳轉(zhuǎn)的用戶權(quán)限，即用戶功能權(quán)限。在用戶登錄數(shù)字化校園時，訪問控制服務(wù)器根據(jù)數(shù)據(jù)庫當(dāng)中存儲的權(quán)限信息，來決定用戶是否能夠登錄以及合法用戶登錄后所能夠看到的模塊和所能夠使用的操作。當(dāng)用戶請求某一個權(quán)限的時候，訪問控制服務(wù)器又會根據(jù)數(shù)據(jù)庫中的權(quán)限信息，檢查用戶是否具有使用這些資源的權(quán)限。如圖2 所示：

1）當(dāng)用戶訪問一個功能資源時，首先通過權(quán)限過濾器，權(quán)限過濾器加載該用戶所擁有角色的功能權(quán)限，然后判斷用戶是否具有該功能的操作權(quán)限，如沒有權(quán)限，則禁止該訪問的請求。

2）當(dāng)用戶擁有功能的操作權(quán)限時，如該角色配置了數(shù)據(jù)權(quán)限，則通過API 去調(diào)用該用戶所歸屬角色配置的數(shù)據(jù)權(quán)限，根據(jù)傳遞的業(yè)務(wù)對象名，去加載相關(guān)的SQL 表達(dá)式。

3）數(shù)據(jù)權(quán)限配置參數(shù)將被注入到基本的查詢操作中，用戶得到的將是被過濾數(shù)據(jù)后的結(jié)果。

4.2 數(shù)據(jù)庫設(shè)計

基于角色的權(quán)限管理系統(tǒng)傳統(tǒng)的方法一般采用最簡單的基于角色的權(quán)限管理由功能、角色、用戶、角色功能授權(quán)和用戶角色關(guān)系五部分組成，為實現(xiàn)數(shù)據(jù)權(quán)限控制，對基于角色的權(quán)限管理的數(shù)據(jù)模型進(jìn)行了擴(kuò)充如下圖所示：

1）增加數(shù)據(jù)權(quán)限表和數(shù)據(jù)權(quán)限配置表兩張表，數(shù)據(jù)權(quán)限表記錄系統(tǒng)數(shù)據(jù)權(quán)限，如院系、處室、教師、學(xué)生等權(quán)限數(shù)據(jù)；數(shù)據(jù)權(quán)限配置表記錄數(shù)據(jù)權(quán)限在不同業(yè)務(wù)對象上用來控制權(quán)限的參數(shù)。

2）增加數(shù)據(jù)權(quán)限表，實現(xiàn)數(shù)據(jù)權(quán)限與角色的關(guān)聯(lián)，這樣將不同的數(shù)據(jù)權(quán)限配置到不同的角色上。

4.3 實現(xiàn)方法

項目整體采用了Struts2+Spring+Hibernate 的JavaEE 框架結(jié)構(gòu)，將安全性放在了首要位置。其中Struts2 實現(xiàn)從視圖層到業(yè)務(wù)邏輯層的跳轉(zhuǎn)控制、參數(shù)傳遞等，Spring 用來解決對象之間的依賴關(guān)系，簡化對象的獲取，Hibernate 簡化數(shù)據(jù)庫的操作，使數(shù)據(jù)庫一致性得到很好的保證。

按照縱向分割的思想，數(shù)據(jù)接口層用來創(chuàng)建、維護(hù)權(quán)限控制框架所要用到的數(shù)據(jù)庫表，將所有的數(shù)據(jù)交互處理都設(shè)計為Dao類，實現(xiàn)了模塊之間的解耦，更加符合軟件開發(fā)的原則。

4.3.1 登錄實現(xiàn)

登錄功能采用HTTP Post 方法向傳遞LoginAction 類傳遞用戶名和密碼參數(shù)，覆蓋了父類的Execute 方法。方法的具體實現(xiàn)為：新建一個用戶實體，將傳遞來的參數(shù)（用戶名和密碼）傳遞給新建的實體 UserBean，調(diào)用用戶數(shù)據(jù)處理類UserDao 的setUser（UserBean）和getUser（）方法返回用戶的詳細(xì)信息。如果不存在該用戶名密碼對應(yīng)的用戶，則返回為空。如果該用戶的信息合法，則返回詳細(xì)信息后，User 實體置入HttpSession，該用戶通過審核。如圖4 所示：

4.3.2 權(quán)限操作實現(xiàn)

權(quán)限操作由于不需要用戶直接進(jìn)行交互，所以權(quán)限操作只有對應(yīng)的實體類和Dao 類，AuthorityBean 實體類中定義了權(quán)限實體對應(yīng)的私有屬性和對應(yīng)的訪問和賦值方法，它是針對權(quán)限操作的對象。AuthorityDao 類是所有數(shù)據(jù)庫和權(quán)限操作的接口，它是對于數(shù)據(jù)庫的增、刪、改、查的實現(xiàn)類。

5 結(jié)束語

圖3 改進(jìn)的數(shù)據(jù)庫模型圖

本文根據(jù)數(shù)字化校園綜合管理系統(tǒng)的訪問與權(quán)限控制機(jī)制的需求，對已有的訪問控制模型進(jìn)行分析研究，在其應(yīng)用不足之處改進(jìn)，構(gòu)建了一個通用的、安全的、完善的、易于管理的、有良好的擴(kuò)展性和可移植性的權(quán)限管理系統(tǒng)，使得系統(tǒng)的權(quán)限管理模塊真正成為權(quán)限控制和安全防護(hù)的核心，在系統(tǒng)安全運維過程中發(fā)揮著重要的作用。

圖4 登錄過程流圖

[1]沈海波、洪帆.訪問控制模型研究綜述[J].計算機(jī)應(yīng)用研究，2005,6:9-11

[2]Ravi Sandhu,Edward Coyne,Hal Feinstein,et a1.Role-based access control models[J].IEEE Computer,1996,29(2):38-47.

[3]Ferraiolo D,Sandhu R,Gavrila S,et a1.A proposed standard for role-based access control[J].ACM Transactions on Information and System Security,2001,4(3):224-274.