基于RBAC的安全管理模塊的設計與實現(xiàn)*

周志烽 王晶

（1 北京郵電大學網(wǎng)絡與交換技術國家重點實驗室 北京 100876）

（2 東信北郵信息技術有限公司 北京 100191）

基于角色管理權限的思想在20世紀70年代已經(jīng)出現(xiàn)，但首個RBAC（Role Based Access Control）模型是由David Ferraiolo和Rick Kuhn在1992年提出的。1996年，Ravi Sandhu等人提出了具有代表性和規(guī)范性的RBAC96模型，給出了一個結構完整、定義規(guī)范的RBAC模型。在此基礎上，人們對RBAC做了更深入的研究，提出了大量擴展模型。由于RBAC易用高效的授權方式和授權模型維護方式，RBAC及其擴展模型廣泛應用于各類資源管理系統(tǒng)中。

而Ferraiolo等人只是對RBAC模型做出了抽象的描述，并沒有提及如何將其應用于實際系統(tǒng)中。本文沒有提出新的RBAC模型，而是論述了一種實現(xiàn)方式。本文對RBAC中的4個實體（用戶、角色、權限、對話）和兩個動作（賦予角色給用戶、賦予權限給角色）以及它們的約束，都提供一種明確的設計原則和實現(xiàn)方式，這些對Web系統(tǒng)安全管理模塊設計，例如智能網(wǎng)的接入控制，都具有一定的參考意義。

1 RBAC模型設計

1.1 設計原則

首先要明確一點，雖然RBAC簡化了權限的管理，但并不能滿足所有要求。例如一個財務系統(tǒng)有這樣的需求：1萬元以下的報銷可以由部門經(jīng)理審核，1～5萬元的報銷需要中心經(jīng)理審核，5萬元以上的報銷只有總經(jīng)理才能審核。如果要求RBAC實現(xiàn)上述控制，將會導致權限集合的爆炸。而且上述邏輯很容易出現(xiàn)變動，而一旦變動，安全管理模塊也要隨之改動，這是很不利于維護的。

經(jīng)分析不難發(fā)現(xiàn)，凡是涉及業(yè)務邏輯的控制，使用RBAC進行權限管理都是比較困難的。RBAC優(yōu)勢在于解決對象（資源）層面上的權限管理，即執(zhí)行者能否操作某個對象，能夠對其進行何種操作。而對于數(shù)據(jù)層面上的權限管理，RBAC在實現(xiàn)校驗上是非常低效而且復雜的。

因此在進行RBAC模型設計之前，需要定義一個原則：RBAC只負責對象（資源）級權限管理，而數(shù)據(jù)級權限管理應該交由業(yè)務邏輯處理（目前比較流行的方法是使用規(guī)則引擎實現(xiàn)業(yè)務邏輯的動態(tài)管理，但這不屬于本文討論范圍）。

1.2 權限的設計

權限是操作和對象（資源）的聚合，權限的自然屬性決定于實際的應用系統(tǒng)，例如在醫(yī)療管理系統(tǒng)中，權限是“修改病人的處方”；在教學管理系統(tǒng)中，權限則是“登記學生數(shù)學成績”。下面定義權限的約束條件：

權限可具有前置關系，即權限P1可能需要具有權限P2才有效。例如讀取一個文件，需要具有讀取文件所在目錄的權限。

權限不具有包含關系，即對于任意權限P1、 P2，不具有關系P1P2。因為在定義權限時，如果出現(xiàn)權限P1、 P2，有P1P2，則可以將權限定義為P1、P2-P1。

權限也不具有互斥關系。本文定義的權限代表的是一種“正面”的能力，代表執(zhí)行者能夠做什么。一個足夠強大的執(zhí)行者完全可以具備系統(tǒng)提供的所有能力。

在滿足上述3個約束條件的前提下，還必須遵循一個原則：為實際系統(tǒng)建立權限集合時，權限的粒度決定于對象（資源）的粒度。例如在教學管理系統(tǒng)中，對象（資源）的粒度是“英語成績”、“數(shù)學成績”，那么權限的粒度應該是“修改英語成績”、“修改數(shù)學成績”。至于實現(xiàn)“只能查詢04101班數(shù)學成績”這種控制，已經(jīng)涉及到業(yè)務邏輯，不應該將其放到RBAC模型中實現(xiàn)，而應該放到規(guī)則引擎等管理業(yè)務規(guī)則的模塊中實現(xiàn)。

為了方便權限集合的管理，本文引入了“虛權限”的概念。虛權限并不是對某一個具體對象（資源）操作的能力，是對一類操作能力的概括。虛權限是其概括權限的前置權限，而且也是這些權限的父權限，權限集合變成了樹狀結構，如圖1所示，虛線框代表的是虛權限。引入“虛權限”之后，也方便了Web系統(tǒng)視圖層的控制。例如權限“修改數(shù)學成績”控制了一個按鈕的顯示與否，而權限“修改成績”則可控制一個頁面菜單的顯示與否。

圖1 權限樹

1.3 角色的設計

對于一個具體的系統(tǒng)，角色是比較固定的，它是一組權限的集合，下面定義角色的約束條件：角色可具有互斥關系。具有互斥關系的角色不能被賦予給同一個用戶。例如在財務管理系統(tǒng)中，會計和出納不能是同一個人，否則很容易出現(xiàn)監(jiān)守自盜的行為。這個約束條件實現(xiàn)了靜態(tài)職責分離（Static Separation of Duty）的思想。

但如Ferraiolo提到的“這樣的策略（SSD）可能太過嚴格以至于耗費反而比沒有安全機制所造成的損失大”。在實際的應用系統(tǒng)中，要求系統(tǒng)能夠滿足動態(tài)職責分離（Dynamic Separation of Duty），有時是很有必要的。

但是DSD有兩種情況，一種情況是“一個人既是訂單創(chuàng)建者和訂單確認者，而他不能確定自己創(chuàng)建的訂單”，這種情況已經(jīng)涉及到業(yè)務邏輯，不應該納入安全管理模塊的考慮范圍；另一種情況是用戶可以同時擁有兩種角色，但在一次會話中只能激活其中一個角色，只能行使被激活角色的能力，這種情況是需要納入RBAC中實現(xiàn)的。

角色可以繼承，但是具有互斥關系的角色不能被同一角色繼承。角色擁有被繼承角色的所有權限，另外還可能包含一些被繼承角色所不具有的權限。角色繼承時，互斥關系也會被繼承。

1.4 用戶的設計

一個用戶只能對應一個執(zhí)行者，因為如果一個執(zhí)行者能夠擁有多個用戶身份，那么基于角色的權限管理就失去了意義。

用戶只有激活其被賦予的角色之后，才能執(zhí)行權限。而要激活角色，用戶首先必須通過認證。未經(jīng)過認證的用戶是非法用戶，是不具備任何能力的。

1.5 會話的設計

在RBAC引入會話機制，是為了實現(xiàn)最小權限原則。會話允許只激活賦予給用戶的部分角色，如果沒有會話，所有角色將會處于活動狀態(tài)，這可能會違反了最小權限原則。然而如RBAC模型的創(chuàng)建者所說，“在實際應用中，堅持激活所有角色可能會有用的，如果社區(qū)有足夠的興趣，未來可能會將其作為一個修訂的標準”。

考慮到通用性，以及為了滿足角色的動態(tài)職責分離，會話應該設計成可以激活用戶的一個或多個（包括所有）角色。而“堅持激活所有角色”則屬于一個特殊的實現(xiàn)。

1.6 角色被賦予權限的設計

角色和權限是多對多關系，一個角色可以擁有多個權限，而一個權限也可以被賦予給多個角色。下面定義角色被賦予權限時的約束條件：權限分配的角色數(shù)可以有限制，這是為了防止某些能力強大的權限被濫用。

1.7 用戶被賦予角色的設計

角色和用戶是多對多關系，一個用戶可以扮演多個角色，而一個角色也可以被賦予給多個用戶。下面定義用戶被賦予角色時的約束條件：具有互斥關系的角色不能被賦予同一個用戶。

角色分配的用戶數(shù)可以有限制。例如公司總裁，一個公司只會有一個。實現(xiàn)這個約束條件是為了防止某些能力強大的角色被故意或錯誤地賦予給不恰當?shù)挠脩簟?/p>

1.8 ER關系設計

綜合上述設計原則，本文得出如圖2所示的ER（Entity Relationship）關系圖。

本文給出的是一個基本的較為完備的RBAC模型設計。所謂基本，是指沒有定義用戶、角色、權限的詳細信息；所謂較為完備，是指涵蓋了上述的設計思想。在實現(xiàn)具體系統(tǒng)的安全管理模塊時，并不一定需要角色繼承等，而且甚至可以限定一個用戶只能對應一個角色。

圖2 RBAC模型的ER關系圖

2 利用Spring Security框架實現(xiàn)設計

在傳統(tǒng)的Web系統(tǒng)中，所有的權限驗證邏輯都混雜在業(yè)務邏輯中，用戶的每個操作可能都需要對用戶是否有進行該項操作的權限進行判斷，來達到認證授權的目的。類似這樣的權限驗證邏輯代碼被分散在系統(tǒng)的許多地方，難以維護。Spring Security很好的解決了此類問題，它將系統(tǒng)的安全邏輯的實現(xiàn)從業(yè)務中分離出來，作為系統(tǒng)一個單獨的“切面”進行管理，其主要組件如圖3所示。

圖3 Spring Security基本組件

Spring Security作為安全管理框架，其內部機制可分為兩大部分，其一是認證授權，其二是權限校驗。Web系統(tǒng)引入Spring Security框架之后，一個請求通過安全管理的流程如圖 4所示。

但是，Spring Security框架先天并不符合RBAC模型。一是在Spring Security中，角色和權限的概念是等同的，即受保護的對象（資源）直接與角色掛鉤，這顯然是不符合RBAC的思想的。二是，Spring Security沒有實現(xiàn)RBAC動態(tài)職責分離的要求，因為Spring Security中角色的概念與RBAC的不一樣，所以也無從談角色的動態(tài)職責分離。

圖4 流經(jīng)Spring Security框架的請求

為了讓Spring Security實現(xiàn)真正意義上的RBAC，需要實現(xiàn)自定義的UserDetailsService，如圖5所示，函數(shù)obtainGrantedAuthorities封裝了權限的獲取，它首先獲取user被激活的角色集合，然后遍歷角色集合，獲取角色被賦予的權限；函數(shù)getActiveRoles則封裝了user被激活角色的獲取。

在Spring Security中，受保護資源所要求的授權默認是以“ROLE_”開頭的，為了避免概念的混淆，建議將授權名稱的默認前綴由“ROLE_”改為“P_”。這樣在使用Spring Security框架時，無論從形式上和內容上都符合RBAC的思想。

圖5 UserDetailsService接口的實現(xiàn)

3 結束語

采用基于RBAC模型的安全管理，由于角色與權限之間的變化比角色與用戶關系之間的變化相對要慢得多，減小了授權管理的復雜性，降低管理開銷；在操作上，權限分配直觀、容易理解，便于使用，重用性強。

采用Spring Security框架作為RBAC模型的實現(xiàn)方式，提供了一種基于Spring的松弛耦合、依賴注入和面向切面編程基本原理的機制來保護用戶的應用程序。使用Spring Security，無需直接在你的應用程序代碼中編寫任何安全代碼，即可達到保護應用系統(tǒng)的目的。

[1]Ferraiolo D F, Kuhn R D. Role-based access controls. 15th National Computer Security Conference (1992) Baltimore, 1992, 554～563

[2]Sandhu R S, Coynek E J, Feinsteink H L， Youmank C E. Rolebased access control models, IEEE Computer, 1996, 29(2)：38～47

[3]朱于軍，王柏，廖建新，陳俊亮，基于增強型智能網(wǎng)的接入控制及協(xié)議. 電子學報，2000，(5)

[4]Ferraiolo D F, Barkley J, Kuhn D R. A role based access control model and reference implementation within a corporate intranet. ACM Transactions on Information Systems Security, Volume 1, Number 2,February 1999

[5]Ferraiolo D F, Kuhn R, Sandhu R. RBAC standard rationale: comments on a critique of the ANSI standard on role based access control. IEEE Security & Privacy, 2007, 5(6): 51～53

[6]Walls C，Breidenbach R著. Spring in Action（第二版）中文版.北京：人民郵電出版社，2008