RBAC與數(shù)據(jù)轉(zhuǎn)發(fā)技術(shù)在系統(tǒng)開發(fā)中的應(yīng)用

郭玉靜，甘 雷

（1. 唐山學(xué)院 科研處，唐山 063000；2. 唐山學(xué)院 網(wǎng)絡(luò)教育中心，唐山 063000 )

0 引言

起源于70年代的訪問控制技術(shù),隨著網(wǎng)絡(luò)技術(shù)的發(fā)展也一直在革新完善著。從傳統(tǒng)的自主訪問控制(DiscretionaryAccessControl)、強(qiáng)制訪問控制(MandatoryAccessControl)到今天較成熟的基于角色的訪問控制RBAC(Role-BasedAccessContro,l RBAC)[1],其中RBAC在大型網(wǎng)絡(luò)應(yīng)用系統(tǒng)以及數(shù)據(jù)資源的安全管理方面發(fā)揮了極大的作用。

訪問控制定義了主體對(duì)客體的訪問權(quán)限，其目的是保證系統(tǒng)、任務(wù)或資源在合法的范圍內(nèi)被合法程序或用戶執(zhí)行或訪問，不讓非法資源執(zhí)行未授權(quán)的任務(wù)或訪問相應(yīng)的數(shù)據(jù)對(duì)象，決策支持系統(tǒng)系統(tǒng)中的安全訪問控制技術(shù)已被予以很大的關(guān)注。一個(gè)包含項(xiàng)目、合同、項(xiàng)目、質(zhì)量等多個(gè)子模塊的系統(tǒng)，公用一個(gè)權(quán)限管理子系統(tǒng)，這樣就對(duì)權(quán)限管理帶來了較高的要求。

圖1 通用權(quán)限控制系統(tǒng)架構(gòu)

1 RBAC基本思想

企業(yè)環(huán)境中的訪問控制策略一般有3種：自主型訪問控制方法、強(qiáng)制型訪問控制方法和基于角色的訪問控制方法(RBAC)。其中，自主式太弱，強(qiáng)制式太強(qiáng)，二者工作最大，不便于管理?；诮巧脑L問控制方法是目前公認(rèn)的解決大型企業(yè)的統(tǒng)一資源訪問控制的有效方法。其最著的2大特征是：1）減小授權(quán)管理的復(fù)雜性，降低管理開銷；2）靈活地支持企業(yè)的安全策略，并對(duì)企業(yè)的變化有很大的伸縮性。

基于角色訪問控制（RBAC）模型[2]是目前國際上流行的先進(jìn)的安全訪問控制方法。它通過分配和取消角色來完成用戶權(quán)限的授予和取消，并且提供角色分配規(guī)則。安全管理人員根據(jù)需要定義各種角色，并設(shè)置合適的訪問權(quán)限，而用戶根據(jù)其責(zé)任和資歷再被指派為不同的角色。這樣，整個(gè)訪問控制過程就分成兩個(gè)部分，即訪問權(quán)限與角色相關(guān)聯(lián)，角色再與用戶關(guān)聯(lián)，從而實(shí)現(xiàn)了用戶與訪問權(quán)限的邏輯分離。

由于實(shí)現(xiàn)了用戶與訪問權(quán)限的邏輯分離，基于角色的策略極大的方便了權(quán)限管理。例如，如果一個(gè)用戶的職位發(fā)生變化，只要將用戶當(dāng)前的角色去掉，加入代表新職務(wù)或新任務(wù)的角色即可。研究表明，角色/權(quán)限之間的變化比角色/用戶關(guān)系之間的變化相對(duì)要慢得多，并且給用戶分配角色不需要很多技術(shù)，可以由行政管理人員來執(zhí)行，而給角色配置權(quán)限的工作比較復(fù)雜，需要一定的技術(shù)，可以由專門的技術(shù)人員來承擔(dān)，但是不給他們給用戶分配角色的權(quán)限，這與現(xiàn)實(shí)中的情況正好一致。

RBAC包含了6個(gè)最基本的元素：用戶(Users)、角色集(Roles)、對(duì)象集(Objects，OBS)、操作集(Operations，OPS)、許可集(Permissions)和會(huì)話集合(SESSIONS)。

圖2 RBAC模型

2 權(quán)限控制實(shí)現(xiàn)

項(xiàng)目控制權(quán)限的方法是把系統(tǒng)中所有需要權(quán)限控制的按鈕都設(shè)計(jì)到數(shù)據(jù)庫中，每一個(gè)菜單對(duì)應(yīng)一個(gè)或多個(gè)按鈕，分配權(quán)限時(shí)給用戶分配能操作的按鈕權(quán)限。

1）系統(tǒng)的層次分為模塊、主菜單、子菜單、按鈕、字段五級(jí)。

2）用戶進(jìn)入系統(tǒng)會(huì)根據(jù)數(shù)據(jù)庫記錄的用戶權(quán)限找出該用戶所對(duì)應(yīng)的模塊進(jìn)行權(quán)限的初始化。

3）當(dāng)用戶每點(diǎn)擊進(jìn)入一個(gè)模塊時(shí)會(huì)把該用戶在該模塊下的菜單權(quán)限進(jìn)行初始化，然后用戶點(diǎn)擊進(jìn)入菜單時(shí)再根據(jù)數(shù)據(jù)庫中記錄的權(quán)限對(duì)該頁面的按鈕權(quán)限進(jìn)行初始化，沒有權(quán)限的按鈕將被禁用。

4）考慮到有些用戶可能會(huì)用url地址對(duì)系統(tǒng)進(jìn)行破壞性的侵入，用戶每點(diǎn)擊一次模塊時(shí)，都會(huì)把該用戶在該模塊下所擁有的動(dòng)作權(quán)限都記錄到session當(dāng)中，用戶點(diǎn)擊按鈕進(jìn)行操作時(shí)都會(huì)產(chǎn)生一個(gè)動(dòng)作，在BaseAction中會(huì)對(duì)這個(gè)動(dòng)作跟session中的動(dòng)作名稱進(jìn)行比對(duì)，沒有權(quán)限將轉(zhuǎn)到無權(quán)限的信息提示頁。

上面介紹解決了權(quán)限控制基本問題，但在用戶的多個(gè)角色有交集時(shí)權(quán)限合并存在困難，在合并時(shí)會(huì)出現(xiàn)權(quán)限放大的情況。因?yàn)闄?quán)限跟角色之間、角色跟用戶之間都是多對(duì)多關(guān)系。中介授權(quán)隱含的問題是：一個(gè)用戶本身需要的權(quán)限構(gòu)成一個(gè)集合，當(dāng)他被被賦予多個(gè)角色后，多個(gè)角色與權(quán)限關(guān)聯(lián)構(gòu)成另一個(gè)集合，保證兩個(gè)集合相等很不容易。采取下面方法解決上述多角色權(quán)限合并問題：

1）通過對(duì)角色進(jìn)行分級(jí)處理來解決用戶權(quán)限合并中的優(yōu)先級(jí)問題：分為超級(jí)、中心級(jí)、部門級(jí)和用戶級(jí)；

2）多個(gè)角色權(quán)限合并時(shí)通過采用把對(duì)多個(gè)角色結(jié)果集角色的權(quán)限各自結(jié)果集的合并。

合并時(shí)采用Oracle函數(shù)，可以提高查詢效率

通過對(duì)在角色集中引入維數(shù)的概念，對(duì)RBAC模型框架進(jìn)行了必要的擴(kuò)展，通過這種多維RBAC模型，在一個(gè)基于角色訪問控制的決策管理與支持系統(tǒng)中得以實(shí)現(xiàn)，有效地解決了上面提到地幾個(gè)問題，而且這種模型簡化了角色配置管理，進(jìn)一步加強(qiáng)了對(duì)數(shù)據(jù)庫訪問的安全控制。

3 數(shù)據(jù)庫邏輯設(shè)計(jì)

項(xiàng)目管理中的主線為提出申請(qǐng)等待領(lǐng)導(dǎo)審批審批結(jié)束后進(jìn)入下一個(gè)流程。以科研立項(xiàng)申請(qǐng)表為例，B類項(xiàng)目交部門項(xiàng)目管理員和部門領(lǐng)導(dǎo)審核，A類和E類由項(xiàng)目管理員和部門領(lǐng)導(dǎo)進(jìn)行初審，由中心項(xiàng)目管理員、財(cái)務(wù)處、總工辦等進(jìn)行復(fù)審。

3.1 申請(qǐng)表

以立項(xiàng)申請(qǐng)表1為例，填寫基本信息并記錄審批流程，判斷申請(qǐng)表到了什么狀態(tài)，有幾個(gè)人審批，還有幾個(gè)人沒有審批。

表1 立項(xiàng)申請(qǐng)表

3.2 申請(qǐng)分類表

科研中心內(nèi)部有多個(gè)審批表，如立項(xiàng)申請(qǐng)表、合同申請(qǐng)表等。然而每一個(gè)的轉(zhuǎn)發(fā)流程都一樣。因此用申請(qǐng)分類表用來統(tǒng)一管理申請(qǐng)表的名稱。表2所示：

表2 申請(qǐng)分類表

3.3 申請(qǐng)分類狀態(tài)表

每一個(gè)申請(qǐng)表都對(duì)應(yīng)多個(gè)審批狀態(tài)。如：立項(xiàng)申請(qǐng)表對(duì)應(yīng)：部門立項(xiàng)申請(qǐng)意見、部門意見、中心項(xiàng)目管理意見、財(cái)務(wù)處意見、總工辦意見等。而出國申請(qǐng)表對(duì)應(yīng)中心辦審查、總工辦審查、部門領(lǐng)導(dǎo)審查等。因此申請(qǐng)分類狀態(tài)表用來管理每個(gè)申請(qǐng)表所對(duì)應(yīng)的不同狀態(tài)。

3.4 待辦事項(xiàng)表

填寫審批意見、審批時(shí)間，記錄審批人審批時(shí)間等信息。

4 數(shù)據(jù)轉(zhuǎn)發(fā)實(shí)現(xiàn)

數(shù)據(jù)分發(fā)共分為三類用戶。

第一類：普通用戶在前臺(tái)填寫各類申請(qǐng)表，如立項(xiàng)申請(qǐng)表、合同申請(qǐng)表、項(xiàng)目申請(qǐng)表等。

第二類：項(xiàng)目管理員在后臺(tái)進(jìn)行數(shù)據(jù)分發(fā)，根據(jù)不同的申請(qǐng)表將申請(qǐng)表轉(zhuǎn)發(fā)到角色或者個(gè)人。第三類:審批人員進(jìn)行申請(qǐng)表的審批只能看到自己所要審批的內(nèi)容。

1）申請(qǐng)表填寫：不同部門根據(jù)需求填寫不同的申請(qǐng)表；

2）管理員根據(jù)狀態(tài)指定審批流程同一類型的申請(qǐng)表可群發(fā)；

3）科研中心部分文件可以多人處理因此管理員需要根據(jù)轉(zhuǎn)發(fā)文件和部門的需求進(jìn)行轉(zhuǎn)發(fā)角色或用戶的選擇；

4）轉(zhuǎn)發(fā)到具體人員或角色,其中轉(zhuǎn)發(fā)到人員可以根據(jù)部門選擇人員或者模糊查詢直接搜索人員；

5）根據(jù)選定的人員選擇狀態(tài)；

6）查看審批信息，如果轉(zhuǎn)發(fā)錯(cuò)誤，可以撤銷重新轉(zhuǎn)發(fā)。

在決策支持系統(tǒng)系統(tǒng)中，采用統(tǒng)一的安全管理設(shè)計(jì)思想，規(guī)范化設(shè)計(jì)和先進(jìn)的技術(shù)架構(gòu)體系，構(gòu)建一個(gè)通用的、完善的、安全的、易于管理的、有良好的可移植性和擴(kuò)展性的權(quán)限管理系統(tǒng)，使得權(quán)限管理系統(tǒng)真正成為權(quán)限控制的核心，在維護(hù)系統(tǒng)安全方面發(fā)揮重要的作用，是十分必要的。

[1] FerraioloD,KuhR.Role-BasedAccessControl[C].Proceedings.of15thNationalComputerSecurityConference.1992.

[2] 葉春曉,符云清,吳中福.RBAC中權(quán)限擴(kuò)展的實(shí)現(xiàn)[J].計(jì)算機(jī)工程,2005,(9):150-151,80.