RBAC與數據轉發技術在系統開發中的應用

郭玉靜，甘 雷

（1. 唐山學院 科研處，唐山 063000；2. 唐山學院 網絡教育中心，唐山 063000 )

0 引言

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

訪問控制定義了主體對客體的訪問權限，其目的是保證系統、任務或資源在合法的范圍內被合法程序或用戶執行或訪問，不讓非法資源執行未授權的任務或訪問相應的數據對象，決策支持系統系統中的安全訪問控制技術已被予以很大的關注。一個包含項目、合同、項目、質量等多個子模塊的系統，公用一個權限管理子系統，這樣就對權限管理帶來了較高的要求。

圖1 通用權限控制系統架構

1 RBAC基本思想

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

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

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

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

圖2 RBAC模型

2 權限控制實現

項目控制權限的方法是把系統中所有需要權限控制的按鈕都設計到數據庫中，每一個菜單對應一個或多個按鈕，分配權限時給用戶分配能操作的按鈕權限。

1）系統的層次分為模塊、主菜單、子菜單、按鈕、字段五級。

2）用戶進入系統會根據數據庫記錄的用戶權限找出該用戶所對應的模塊進行權限的初始化。

3）當用戶每點擊進入一個模塊時會把該用戶在該模塊下的菜單權限進行初始化，然后用戶點擊進入菜單時再根據數據庫中記錄的權限對該頁面的按鈕權限進行初始化，沒有權限的按鈕將被禁用。

4）考慮到有些用戶可能會用url地址對系統進行破壞性的侵入，用戶每點擊一次模塊時，都會把該用戶在該模塊下所擁有的動作權限都記錄到session當中，用戶點擊按鈕進行操作時都會產生一個動作，在BaseAction中會對這個動作跟session中的動作名稱進行比對，沒有權限將轉到無權限的信息提示頁。

上面介紹解決了權限控制基本問題，但在用戶的多個角色有交集時權限合并存在困難，在合并時會出現權限放大的情況。因為權限跟角色之間、角色跟用戶之間都是多對多關系。中介授權隱含的問題是：一個用戶本身需要的權限構成一個集合，當他被被賦予多個角色后，多個角色與權限關聯構成另一個集合，保證兩個集合相等很不容易。采取下面方法解決上述多角色權限合并問題：

1）通過對角色進行分級處理來解決用戶權限合并中的優先級問題：分為超級、中心級、部門級和用戶級；

2）多個角色權限合并時通過采用把對多個角色結果集角色的權限各自結果集的合并。

合并時采用Oracle函數，可以提高查詢效率

通過對在角色集中引入維數的概念，對RBAC模型框架進行了必要的擴展，通過這種多維RBAC模型，在一個基于角色訪問控制的決策管理與支持系統中得以實現，有效地解決了上面提到地幾個問題，而且這種模型簡化了角色配置管理，進一步加強了對數據庫訪問的安全控制。

3 數據庫邏輯設計

項目管理中的主線為提出申請等待領導審批審批結束后進入下一個流程。以科研立項申請表為例，B類項目交部門項目管理員和部門領導審核，A類和E類由項目管理員和部門領導進行初審，由中心項目管理員、財務處、總工辦等進行復審。

3.1 申請表

以立項申請表1為例，填寫基本信息并記錄審批流程，判斷申請表到了什么狀態，有幾個人審批，還有幾個人沒有審批。

表1 立項申請表

3.2 申請分類表

科研中心內部有多個審批表，如立項申請表、合同申請表等。然而每一個的轉發流程都一樣。因此用申請分類表用來統一管理申請表的名稱。表2所示：

表2 申請分類表

3.3 申請分類狀態表

每一個申請表都對應多個審批狀態。如：立項申請表對應：部門立項申請意見、部門意見、中心項目管理意見、財務處意見、總工辦意見等。而出國申請表對應中心辦審查、總工辦審查、部門領導審查等。因此申請分類狀態表用來管理每個申請表所對應的不同狀態。

3.4 待辦事項表

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

4 數據轉發實現

數據分發共分為三類用戶。

第一類：普通用戶在前臺填寫各類申請表，如立項申請表、合同申請表、項目申請表等。

第二類：項目管理員在后臺進行數據分發，根據不同的申請表將申請表轉發到角色或者個人。第三類:審批人員進行申請表的審批只能看到自己所要審批的內容。

1）申請表填寫：不同部門根據需求填寫不同的申請表；

2）管理員根據狀態指定審批流程同一類型的申請表可群發；

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

4）轉發到具體人員或角色,其中轉發到人員可以根據部門選擇人員或者模糊查詢直接搜索人員；

5）根據選定的人員選擇狀態；

6）查看審批信息，如果轉發錯誤，可以撤銷重新轉發。

在決策支持系統系統中，采用統一的安全管理設計思想，規范化設計和先進的技術架構體系，構建一個通用的、完善的、安全的、易于管理的、有良好的可移植性和擴展性的權限管理系統，使得權限管理系統真正成為權限控制的核心，在維護系統安全方面發揮重要的作用，是十分必要的。

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

[2] 葉春曉,符云清,吳中福.RBAC中權限擴展的實現[J].計算機工程,2005,(9):150-151,80.