ylbtech-雜項-權限管理：RBAC

基于角色的權限訪問控制（Role-Based Access Control）作為傳統訪問控制（自主訪問，強制訪問）的有前景的代替受到廣泛的關注。在RBAC中，權限與角色相關聯，用戶通過成為適當角色的成員而得到這些角色的權限。這就極大地簡化了權限的管理。在一個組織中，角色是為了完成各種工作而創造，用戶則依據它的責任和資格來被指派相應的角色，用戶可以很容易地從一個角色被指派到另一個角色。角色可依新的需求和系統的合并而賦予新的權限，而權限也可根據需要而從某角色中回收。角色與角色的關系可以建立起來以囊括更廣泛的客觀情況。

1.返回頂部

1、簡介 RBAC支持三個著名的安全原則：最小權限原則，責任分離原則和數據抽象原則。 （1）最小權限原則之所以被RBAC所支持，是因為RBAC可以將其角色配置成其完成任務所需要的最小的權限集。 （2）責任分離原則可以通過調用相互獨立互斥的角色來共同完成敏感的任務而體現，比如要求一個計帳員和財務管理員共參與同一過帳。 （3）數據抽象可以通過權限的抽象來體現，如財務操作用借款、存款等抽象權限，而不用操作系統提供的典型的讀、寫、執行權限。然而這些原則必須通過RBAC各部件的詳細配置才能得以體現。 RBAC有許多部件(BUCU)，這使得RBAC的管理多面化。尤其是，我們要分割這些問題來討論：用戶與角色的指派；角色與權限的指派；為定義角色的繼承進行的角色與角色的指派。這些活動都要求把用戶和權限聯系起來。然而在很多情況下它們最好由不同的管理員或管理角色來做。對角色指派權限是典型的應用管理者的職責。銀行應用中，把借款、存款操作權限指派給出納角色，把批準貸款操作權限指派給經理角色。而將具體人員指派給相應的出納角色和管理者角色是人事管理的范疇。角色與角色的指派包含用戶與角色的指派、角色與權限的指派的一些特點。更一般來說，角色與角色的關系體現了更廣泛的策略。 2、

2.返回頂部

1、 基本概念 RBAC認為權限授權實際上是Who、What、How的問題。在RBAC模型中，who、what、how構成了訪問權限三元組,也就是“Who對What(Which)進行How的操作”。 Who：權限的擁用者或主體（如Principal、User、Group、Role、Actor等等）。 What：權限針對的對象或資源（Resource、Class）。 How：具體的權限（Privilege,正向授權與負向授權）。 Operator：操作。表明對What的How操作。也就是Privilege+Resource Role：角色，一定數量的權限的集合。權限分配的單位與載體,目的是隔離User與Privilege的邏輯關系. Group：用戶組，權限分配的單位與載體。權限不考慮分配給特定的用戶而給組。組可以包括組(以實現權限的繼承)，也可以包含用戶，組內用戶繼承組的權限。User與Group是多對多的關系。Group可以層次化，以滿足不同層級權限控制的要求。 RBAC的關注點在于Role和User, Permission的關系。稱為User assignment(UA)和Permission assignment(PA).關系的左右兩邊都是Many-to-Many關系。就是user可以有多個role，role可以包括多個user。 凡是用過RDBMS都知道，n:m 的關系需要一個中間表來保存兩個表的關系。這UA和PA就相當于中間表。事實上，整個RBAC都是基于關系模型。 Session在RBAC中是比較隱晦的一個元素。標準上說：每個Session是一個映射，一個用戶到多個role的映射。當一個用戶激活他所有角色的一個子集的時候，建立一個session。每個Session和單個的user關聯，并且每個User可以關聯到一或多個Session. 在RBAC系統中，User實際上是在扮演角色(Role)，可以用Actor來取代User，這個想法來自于Business Modeling With UML一書Actor-Role模式?？紤]到多人可以有相同權限，RBAC引入了Group的概念。Group同樣也看作是Actor。而User的概念就具象到一個人。 這里的Group和GBAC（Group-Based Access Control）中的Group（組）不同。GBAC多用于操作系統中。其中的Group直接和權限相關聯，實際上RBAC也借鑒了一些GBAC的概念。 Group和User都和組織機構有關，但不是組織機構。二者在概念上是不同的。組織機構是物理存在的公司結構的抽象模型，包括部門，人，職位等等，而權限模型是對抽象概念描述。組織結構一般用Martin fowler的Party或責任模式來建模。 Party模式中的Person和User的關系，是每個Person可以對應到一個User，但可能不是所有的User都有對應的Person。Party中的部門Department或組織Organization，都可以對應到Group。反之Group未必對應一個實際的機構。例如，可以有副經理這個Group，這是多人有相同職責。 引入Group這個概念，除了用來解決多人相同角色問題外，還用以解決組織機構的另一種授權問題：例如，A部門的新聞我希望所有的A部門的人都能看。有了這樣一個A部門對應的Group，就可直接授權給這個Group。 2、

3.返回頂部

1、 模型

RBAC96模型

1、基本模型RBAC0模型 定義：RBAC0模型由以下描述確定： U、R、P、S分別表示用戶集合、角色集合、許可權集合和會話集合。 PA P×R表示許可權與角色之間多對多的指派關系。 UA U×R表示用戶與角色之間多對多的指派關系。 用戶：S→U每個會話si到單個用戶user(si)的映射函數（常量代表會話的聲明周期）。 角色：S→R每個會話si到角色子集roles(si) {r|user(si, r')∈UA}（能隨時間改變）的映射函數，會話si有許可權Ur∈roles(si){p|(p,r')∈PA}。 在使用RBAC0模型時，應該要求每個許可權和每個用戶至少應該被分配給一個角色。兩個角色被分配的許可權完全一樣是可能的，但仍是兩個完全獨立的角色，用戶也有類似情況。角色可以適當的被看做是一種語義結構，是訪問控制策略形式化的基礎。 RBAC0把許可權處理為非解釋符號，因為其精確含義只能由實現確定且與系統有關。RBAC0中的許可權只能應用于數據和資源類客體，但不能應用于模型本身的組件。修改集合U、R、P和關系PA和UA的權限稱為管理權限，后面將介紹RBAC的管理模型。因此，在RBAC0中假定只有安全管理員才能修改這些組件。 會話是由單個用戶控制的，在模型中，用戶可以創建會話，并有選擇的激活用戶角色的某些子集。在一個會話中的角色的激活是由用戶來決斷的，會話的終止也是由用戶初始化的。RBAC0不允許由一個會話去創建另一個會話，會話只能由用戶創建。 2、角色分級模型RBAC1 定義：RBAC1由以下內容確定 U、R、P、S分別表示用戶集合、角色集合、許可權集合和會話集合。 PA P×R表示許可權與角色之間多對多的指派關系。 UA U×R表示用戶與角色之間多對多的指派關系。 RH R×R是對R的偏序關系，稱為角色等級或角色支配關系，也可用≥符號表示。 用戶：S→U每個會話si到單個用戶user(si)的映射函數（常量代表會話的聲明周期）。 角色：S→R每個會話si到角色子集roles(si) {r|(r'≥r)[user(si,r')∈UA]}（能隨時間改變）的映射函數，會話si有許可權Ur∈roles(si){p|(r''≤r)[(p,r'')∈PA]}。 3、限制模型RBAC2 RBAC2模型是在RBAC0模型增加限制后形成的，它與RBAC1并不兼容。RBAC2定義如下： 定義：除了在RBAC0中增加了一些限制因素外，RBAC2未加改變的來自于RBAC0，這些限制是用于確定RBAC0中各個組件的值是否是可接受的，只有那些可接受的值才是允許的。 RBAC2中引入的限制可以施加到RBAC0模型中的所有關系和組件上。RBAC2中的一個基本限制是互斥角色的限制，互斥角色是指各自權限可以互相制約的兩個角色。對于這類角色一個用戶在某一次活動中只能被分配其中的一個角色，不能同時獲得兩個角色的使用權。 例如，在審計活動中，一個角色不能同時被指派給會計角色和審計員角色。又如，在公司中，經理和副經理的角色也是互斥的，合同或支票只能由經理簽字，不能由副經理簽字。在為公司建立的RBAC2模型中，一個用戶不能同時兼得經理和副經理兩個角色。模型匯總的互斥限制可以支持權責分離原則的實現。 更一般化而言，互斥限制可以控制在不同的角色組合中用戶的成員關系是否是可接受的。例如，一個用戶可以既是項目A的程序員，也可以是項目B的測試員和項目C的驗收員，但他不能同時成為同一個項目中的這3個角色。RBAC2模型可以對這種情況進行限制。 另一個用戶指派限制的例子是一個角色限制其最大成員數，這被稱為角色的基數限制。例如，一個單位的最高領導只能為1人，中層干部的數量也是有限的，一旦分配給這些角色的用戶數超過了角色基數的限制，就不再接受新配給的用戶了。 限制角色的最小基數實現起來有些困難。例如，如果規定占用某個角色的最小用戶數，問題是系統如何在任何時刻都能知道這些占用者中的某個人沒有消失，如果消失的話，系統又應該如何去做。 在為用戶指派某個角色A時，在有的情況下要求該用戶必須是角色B的一個成員，B角色成為角色A的先決角色。先決角色（PrerequisiteRoles）的概念來自于能力和適應性。對先決絕對的限制成為先決限制。一個通俗的例子是，一個數學副教授應該從數學講師中提拔，講師是任副教授的先決角色。但在實際系統中，不兼容角色之間的先決限制的情況也會發生。 在圖ap08-03中，可以限制只有本項目的成員才有資格擔任程序員的角色，通常在一個系統中，先決角色比新指派的角色的級別要低一些。但有的情況下，卻要求只有當用戶不是某個特殊角色時，才能擔任另一個角色A。如，需要執行回避策略時需要這樣做，例如，本課題組成員不應當是本項目成果鑒定委員會的成員。這類限制也可以推廣到許可權方面。 由于用戶與角色的作用會與會話聯系在一起，因此對會話也可以施加限制。例如，可以允許一個用戶被指派給兩個角色，但不允許在同一時間內把該用戶在兩個角色中都激活。另外，還可以限制一個用戶在同一時間內可以激活的會話的數量，相應的，對該用戶所激活的會話中所分配許可權的數量也可以施加限制。 前面提到的繼承概念也可以視為一種限制。被分配給低級別角色的權限，也必須分配給該角色的所有上級角色?；虻葍r的，一個指派給較高級別的角色的用戶必須指派給該角色的所有下級角色。因此從某種角度上講，RBAC1模型是冗余的，它被包含在RBAC2中。但RBAC1模型比較簡潔，用繼承代替限制可使概念更清晰。 實現時可以用函數來實現限制，當為用戶指定角色或為角色分配權限時就調用這些函數進行檢查，根據函數返回的結果決定分配是否滿足限制的要求，通常只對那些可被有效檢查和那些慣例性的一些簡單限制給與實現，因為這些限制可以保持較長的時間。 模型中的限制機制的有效性建立在每個用戶只有唯一標識符的基礎上，如果一個實際系統支持用戶擁有多標識符，限制將會失效。同樣，如果同一個操作可以有兩個以上的許可權來比準，那么，RBAC系統也無法實施加強的基本限制和責任分離和限制。因此要求用戶與其標識符，許可與對應的操作之間一一對應。 4、統一模型RBAC3 RBAC3把RBAC1和RBAC2組合在一起，提供角色的分級和繼承的能力。但把這兩種概念組合在一起也引起一些新問題。 限制也可以應用于角色等級本身，由于角色間的等級關系滿足偏序關系，這種限制對模型而言是本質性的，可能會影響這種偏序關系。例如，附加的限制可能會限制一個給定角色的應有的下級角色的數量。 兩個或多個角色由可能被限制成沒有公共的上級角色或下級角色。這些類型的限制在概念角色等級的權力已經被分散化的情況下是有用的，但是安全主管卻希望對所有允許這些改變的方法加以限制。 在限制和角色的等級之間也會產生敏感的相互影響。在圖ap08-03的環境中，一個項目成員不允許同時擔任程序員與測試員的角色，但項目管理員所處的位置顯然是違反了該限制。在某種情況i下由高等級的角色違反這種限制是可接受的，但在其他情況下又不允許這種違反現象發生。 從嚴格性的角度來講，模型的規則不應該是一些情況下不允許而在另一情況下是允許的。類似的情況也會發生在對基數的限制上。假定限制一個用戶至多能分配給一個角色，那么對圖中的測試員的一個指派能夠違背這種限制嗎？換句話說，基數限制是不是只能用于直接成員，是否也能應用于繼承成員上？ 私有角色的概念可以說明這些限制是有用的。同樣在圖ap08-03的環境中，可以把測試員'，程序員'和項目管理員3個角色說明為互斥的，它們處于同一等級，沒有共同的上級角色，所以管理員角色沒有違反互斥限制。通常私有角色和其他角色之間沒有公共上級角色，因為它們是這個等級的最大元素，所以私有角色之間互斥關系可以無沖突的定義。 諸私有角色之間的相同部分可以被說明為具有0成員的最大技術限制。根據這種方法，測試員必須被指派給測試員'這個角色，而測試員角色就作為與管理員角色共享許可權的一種工具。

ARBAC97模型

ARBAC97模型是基于角色的角色管理模型，包括三個部分： URA97：用戶-角色指派。該組件涉及用戶-指派關系UA的管理，該關系把用戶與角色關聯在一起。對該關系的修改權由管理角色控制，這樣，管理角色中的成員有權管理正規角色中的成員關系。把一個用戶指定為管理角色是在URA97以外完成的，并假定是由安全員完成的。 PRA97：許可權-角色指派。該組件涉及角色-許可權的指派與撤銷。從角色觀點來看，用戶和許可權有類似的特點，它們都是由角色聯系在一起的實在實體。因此，可以把PRA97看做是URA97的對偶組件。 RRA97：角色-角色指派。為了便于對角色的管理，對角色又進行了分類。該組件涉及3類角色，它們是：

能力（Abilities）角色——進以許可權和其他能力做成成員的角色。

組（Groups）角色——僅以用戶和其他組為成員的一類角色。

UP-角色——表示用戶與許可權的角色，這類角色對其成員沒有限制，成員可以使用戶、角色、許可權、能力、組或其他UP-角色。

區別這三類模型的主要原因是可以應用不同的管理模型去建立不同類型角色之間的關系。區分的動因首先是對能力的考慮，能力是許可權的集合，可以把該集合中所有許可權作為一個單位指派給一個角色。類似的，組是用戶的集合，可以把該集合中所有許可權作為一個單位指派給一個角色。組和能力角色都似乎可以劃分等級的。 在一個UP-角色中，一個能力是否是其的一個成員是由UP-角色是否支配該能力決定的，如果支配就是，否則就不是。相反的，如果一個UP-角色被一個組角色支配，則這個組就是該UP-角色的成員。 對ARBAC97管理模型的研究還在繼續之中，對能力-指派與組-指派的形式化已基本完成，對UP-角色概念的研究成果還未形式化。?[2]?

DRBAC

DRBAC是動態結盟環境下的分布式RBAC模型。 DRBAC區別于以前的信任管理和RBAC方法就在于它支持3個特性： 1.第三方指派：一個實體如果被授權了指派分配后，就可以指派它的名字空間以外的角色。 2.數字屬性：通過分配處理與角色有關的數值的機制來調整訪問權限。 3.指派監控：用pub/sub結構對建立的信任關系進行持續監控來跟蹤可被取消的指派的狀態。 DRBAC是由在結盟環境下對資源的訪問控制這個問題引出的。“結盟環境”可以是軍事上幾個國家一起工作達到一個共同的目標，或者商業上幾個公司合伙。結盟環境定義的特點是存在多個組織或多個實體沒有共同的可信的授權中心。在這種情況下，實體在保護它們各自的資源的同時還必須協作來共享對結盟來說必要的受保護資源的部分。Internet上網絡服務的增長使這樣的需求很普遍。 DRBAC結合了RBAC和信任管理系統的優點，是既管理靈活又可分散地，可擴展的實現的系統。DRBAC表示依據角色的受控行為，角色在一個實體的信任域內定義并且可以將這個角色傳遞地指派給不同信任域內的其他角色。DRBAC利用PKI來鑒別所有與信任敏感操作有關的實體以及確認指派證書。從角色到授權的名字空間的映射避免了確認額外的策略根源的需要。 2、

4.返回頂部

5.返回頂部

1、 https://baike.baidu.com/item/RBAC 2、

6.返回頂部

作者：ylbtech 出處：http://ylbtech.cnblogs.com/ 本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利。

轉載于:https://www.cnblogs.com/storebook/p/9139662.html

總結

以上是生活随笔為你收集整理的杂项-权限管理：RBAC的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。