訪問控制策略一般有以下幾種方式：
-
自主型訪問控制（Discretionary Access Control-DAC）：用戶/對象來決定訪問權限。信息的所有者來設定誰有權限來訪問信息以及操作類型（讀、寫、執(zhí)行。。。）。是一種基于身份的訪問控制。例如UNIX權限管理。
-
強制性訪問控制（Mandatory Access Control-MAC）：系統(tǒng)來決定訪問權限。安全屬性是強制型的規(guī)定，它由安全管理員或操作系統(tǒng)根據(jù)限定的規(guī)則確定的，是一種規(guī)則的訪問控制。
-
基于角色的訪問控制（格/角色/任務）：角色決定訪問權限。用組織角色來同意或拒絕訪問。比MAC、DAC更靈活，適合作為大多數(shù)公司的安全策略，但對一些機密性高的政府系統(tǒng)部適用。
-
規(guī)則驅動的基于角色的訪問控制：提供了一種基于約束的訪問控制，用一種靈活的規(guī)則描述語言和一種ixn的信任規(guī)則執(zhí)行機制來實現(xiàn)。
-
基于屬性證書的訪問控制：訪問權限信息存放在用戶屬性證書的權限屬性中，每個權限屬性描述了一個或多個用戶的訪問權限。但用戶對某一資源提出訪問請求時，系統(tǒng)根據(jù)用戶的屬性證書中的權限來判斷是否允許或句句
模型的主要元素
-
可視化授權策略生成器
-
授權語言控制臺
-
用戶、組、角色管理模塊
-
API接口
-
授權決策引擎
-
授權語言解釋器
RBAC(Role-Based Access Control - 基于角色的訪問控制)模型是20世紀90年代研究出來的一種新模型，但從本質上講，這種模型是對前面描述的訪問矩陣模型的擴展。這種模型的基本概念是把許可權（Permission）與角色（Role）聯(lián)系在一起，用戶通過充當合適角色的成員而獲得該角色的許可權。
這種思想世紀上早在20世紀70年代的多用戶計算時期就被提出來了，但直到20世紀90年代中后期，RBAC才在研究團體中得到一些重視。本章將重點介紹美國George Mason大學的RBAC96模型。
在實際的組織中，為了完成組織的業(yè)務工作，需要在組織內部設置不同的職位，職位既表示一種業(yè)務分工，又表示一種責任與權利。根據(jù)業(yè)務分工的需要，支援被劃分為不同群體，各個群體的人根據(jù)其工作任務的需要被賦予不同的職責和權利，每個人有權了解與使用與自己任務相關的信息與資源，對于那些不應該被知道的信息則應該限制他們訪問。這就產(chǎn)生了訪問控制的需求。
例如，在一個大學中，有校長、副校長、訓練部長、組織處長、科研處長、教保處長等不同的職位，在通常情況下，職位所賦予的權利是不變的，但在某個職位上工作的人可以根據(jù)需要調整。RBAC模型對組織內部的這些關系與訪問控制要求給出了非常恰當?shù)拿枋觥?/p>
在RBAC模型中，工作職位被描述為“角色”，職位所具有的權利稱為許可權。角色是RBAC模型中的核心概念，圍繞這一概念實現(xiàn)了訪問控制策略的形式化。特殊的用戶集合和許可權的集合通過角色這一媒介在某個特定的時間內聯(lián)系在一起。而角色確實相對穩(wěn)定的，因為任何組織的分工、活動或功能一般是很少經(jīng)常改變的。
可以有不同的動機去構造一個角色。角色可以表示完成特殊任務的資格，例如，是一個醫(yī)師還是一個藥師；橘色也可以表示一種權利與責任，如工程監(jiān)理。權利與責任不同于資格，例如，Alice可能有資格領導幾個部門，但他只能被分配負責一個部門的領導。通過多個用戶的輪轉，角色可以映射特殊責任的分配，例如，醫(yī)師可以轉換為管理者。RBAC的模式及其實現(xiàn)可以方便的適應這種角色概念的多種表現(xiàn)。
在實際的計算機信息系統(tǒng)中，角色由系統(tǒng)管理員定義，角色的增加與刪除、角色權利的增加與減少等uanli工作都是由系統(tǒng)管理員完成的。根據(jù)RBAC的要求，用戶被分配為某個特定角色后，就被賦予了該角色所擁有的權利和責任，這種授權方式是強制性的，用戶只能被動的接受，不能自主的決定為角色增加或減少權力，也不能把自己角色的權利轉首給用戶，顯然，這是一種非自主型的訪問控制模式。
角色與用戶組有何區(qū)別？
兩者的主要區(qū)別是：用戶組是用戶的集合，但不可許可權的集合；而角色卻同時具有用戶集合和許可權集合的概念，角色的作用是把這兩個集合聯(lián)系在一起的中間媒介。
在一個系統(tǒng)中，如果用戶組的許可權和成員僅可以被系統(tǒng)安全員修改的話，在這種機制下，用戶組的機制是非常接近于角色的概念的。角色也可以在用戶組的基礎上實現(xiàn)，這有利于保持原有系統(tǒng)中的控制關系。在這種情況下，角色相當于一個策略不見，與用戶組的授權及責任關系相聯(lián)系，而用戶組是實現(xiàn)角色的機制，因此，兩者之間是策略與實現(xiàn)機制之間的關系。
雖然RBAC是一種無確定性質策略的模型，但它支持公認的安全原則：最小特權原則、責任分離原則和數(shù)據(jù)抽象原則。最小特權原則得到支持，是因為在RBAC模型中可以通過限制分配給角色權限的多少和大小來實現(xiàn)，分配給與某用戶對應的角色的權限只要不超過該用戶完成其任務的需要就可以了。
責任分離原則的實現(xiàn)，是因為在RBAC模型中可以通過在完成敏感任務過程中分配兩個責任上互相約束的兩個角色來實現(xiàn)，例如在清查賬目時，只需要設置財務管理員和會計連個角色參加就可以了。
數(shù)據(jù)抽象是借助于抽象許可權這樣的概念實現(xiàn)的，如在賬目管理活動中，可以使用信用，借方等抽象許可權，而不是使用操作系統(tǒng)提供的讀、寫、執(zhí)行等具體的許可權。但RBAC并不強迫實現(xiàn)這些原則，安全管理員可以允許配置 RBAC模型使它不支持這些原則。因此，RBAC支持數(shù)據(jù)抽象的程度與RBAC模型的實現(xiàn)細節(jié)有關。
在20世紀90年代期間，大量的專家學者和專門研究單位對RBAC的概念進行了深入研究，先后提出了許多類型的RBAC模型，其中以美國George Mason大學信息安全技術實驗室（LIST）提出的RBAC96模型最具有系統(tǒng)性，得到普遍的公認。
RBAC96是一個模型族，其中包括RBAC0~RBAC3四個概念性模型。基本模型RBAC0定義了完全支持RBAC概念的任何系統(tǒng)的最低需求。RBAC1和RBAC2兩者都包含RBAC0，但各自都增加了獨立的特點，它們被成為高級模型。在RBAC1中增加了角色分級的概念，一個角色可以從另一個角色繼承許可權。RBAC2增加了一些限制，強調在RBAC的不同組件中在配置方面的一些限制。
RBAC1和RBAC2之間是不可比的。RBAC3被成為統(tǒng)一模型，它包含了RBAC1和RBAC2，利用傳遞性，也把RBAC0包括在內。這些模型構成了RBAC96模型族。圖ap08-01表示了族內各模型間的關系，圖ap08-02是RBAC3模型的概念示意圖。
RBAC0的模型結構可以參看圖ap08-02，但需要把途中的限制和角色等級兩部分不包含在RBAC0模型中。該模型中包括用戶（U）、角色（R）和許可權（P）的那個三類實體集合，此外還有一個會話集合（S）。
其中用戶代表一個組織的職員；角色表示該組織內部的一項任務的功能或某個工作職務，它也表示該角色成員所擁有的權利和職責；許可權是用戶對系統(tǒng)中各課題訪問或操作的權利，客體是指系統(tǒng)中的數(shù)據(jù)客體和資源客體，例如，目錄、文件、記錄、端口、設備、內存或子網(wǎng)都是客體。
許可權因客體不同而不同，例如，對于目錄、文件、設備、端口等類客體的操作權是讀、寫、執(zhí)行等；對應數(shù)據(jù)庫管理系統(tǒng)的客體是關系、元素、屬性、記錄、庫文件、視圖等，相應的操作權是Select、Update、Delete、Insert等；在會計應用中，相應的操作權是預算、信用、轉移、創(chuàng)建和刪除一個賬目等。
圖ap08-02說明了關系用戶指派UA（User Assignment）與許可權指派PA（Permission Assignment）的含義，兩者都是多對多的關系。RBAC的關鍵就在于這兩個關系，通過它們，一個用戶將最終獲得某些許可權并執(zhí)行的權力。從圖中角色的位置可以看粗，它是用戶能夠獲取許可權的中間媒介。
會話集中的每個會話表示一個用戶可以對應多個角色（指向角色有兩個箭頭）。在某個會話的持續(xù)期間，一個用戶可以同時激活多個角色，而該用戶所獲得的許可權是所有這些角色的所擁有許可權的并集。
每個用戶可以同時打開多個回話，每個會話都可以在工作站屏幕上用一個窗口顯示。每個會話可以有不同活動角色的組合。RBAC0的這一特點將受到最小特權原則的限制。如果一個用戶在一次會話中激活所有角色的權利超過該用戶被允許的權利，將受到最小權利原則的限制。
定義1 RBAC0模型由以下描述確定：
U、R、P、S分別表示用戶集合、角色集合、許可權集合和會話集合。
PA P×R表示許可權與角色之間多對多的指派關系。
UA U×R表示用戶與角色之間多對多的指派關系。
用戶：S→U 每個會話si到單個用戶user(si)的映射函數(shù)（常量代表會話的聲明周期）。
角色：S→2R 每個會話si到角色子集roles(si) {r|user(si, r')∈UA}（能隨時間改變）的映射函數(shù)，會話si有許可權Ur∈roles(si){p|(p,r')∈PA}。
在使用RBAC0模型時，應該要求每個許可權和每個用戶至少應該被分配給一個角色。兩個角色被分配的許可權完全一樣是可能的，但仍是兩個完全獨立的角色，用戶也有類似情況。角色可以適當?shù)谋豢醋鍪且环N語義結構，是訪問控制策略形式化的基礎。
RBAC0把許可權處理未非解釋符號，因為其精確含義只能由實現(xiàn)確定且與系統(tǒng)有關。RBAC0中的許可權只能應用于數(shù)據(jù)和資源類客體，但不能應用于模型本身的組件。修改集合U、R、P和關系PA和UA的權限稱為管理權限，后面將介紹RBAC的管理模型。因此，在RBAC0中假定只有安全管理員才能修改這些組件。
會話是由單個用戶控制的，在模型中，用戶可以創(chuàng)建會話，并有選擇的激活用戶角色的某些子集。在一個會話中的角色的激活是由用戶來決斷的，會話的終止也是由用戶初始化的。RBAC0不允許由一個會話去創(chuàng)建另一個會話，會話只能由用戶創(chuàng)建。
RBAC1模型的特色是模型中的角色是分級的，不同級別的角色由不同的職責與權力，橘色的級別形成偏序關系。圖ap08-03說明了角色等級的概念。在途中位置處于較高處的角色的等級高于較低位置角色的等級。利用角色的分級概念可以限制繼承的范圍（scope）。
圖中項目成員的等級最低，角色程序員和測試員的等級都高于角色項目成員，并都可以繼承項目成員的權利；角色管理員具有最高的等級，它可以繼承測試員和程序員的權利。為了滿足實際組織中一個角色不完全繼承另一個角色所有權利與責任的需求，模型中引入了私有角色的概念，如圖中的測試員'和程序員'分別是測試員和程序員的私有uese，它們可以分別繼承測試員和程序員的某些專用權利。
顯然，角色的等級關系具有自反性（自己可以繼承自己）、傳遞性（A繼承B，B繼承C，則A繼承C）和反對稱性（A繼承B，B繼承A，則A=B），因此是偏序關系，下面是RBAC1的形式定義。
U、R、P、S分別表示用戶集合、角色集合、許可權集合和會話集合。
PA P×R表示許可權與角色之間多對多的指派關系。
UA U×R表示用戶與角色之間多對多的指派關系。
RH R×R是對R的偏序關系，稱為角色等級或角色支配關系，也可用≥符號表示。
用戶：S→U 每個會話si到單個用戶user(si)的映射函數(shù)（常量代表會話的聲明周期）。
角色：S→2R 每個會話si到角色子集roles(si) {r|(r'≥r)[user(si, r')∈UA]}（能隨時間改變）的映射函數(shù)，會話si有許可權Ur∈roles(si){p|(r''≤r)[(p,r'')∈PA]}。
RBAC2模型是在RBAC0模型增加限制后形成的，它與RBAC1并不兼容。RBAC2定義如下：
除了在RBAC0中增加了一些限制因素外，RBAC2未加改變的來自于RBAC0，這些限制是用于確定RBAC0中各個組件的值是否是可接受的，只有那些可接受的值才是允許的。
RBAC2中引入的限制可以施加到RBAC0模型中的所有關系和組件上。RBAC2中的一個基本限制時互斥角色的限制，互斥角色是指各自權限尅一互相制約的兩個角色。對于這類角色一個用戶在某一次活動中只能被分配其中的一個角色，不能同時獲得兩個角色的使用權。
例如，在審計活動中，一個角色不能同時被指派給會計角色和審計員角色。又如，在公司中，經(jīng)理和副經(jīng)理的角色也是互斥的，合同或支票只能由經(jīng)理簽字，不能由副經(jīng)理簽字。在為公司建立的RBAC2模型中，一個用戶不能同時兼得經(jīng)理和副經(jīng)理兩個角色。模型匯總的互斥限制可以支持權責分離原則的實現(xiàn)。
更一般化而言，互斥限制可以控制在不同的角色組合中用戶的成員關系是否是可接受的。例如，一個用戶可以既是項目A的程序言，也可以是項目B的測試員和項目C的驗收員，但他不能同時成為同一個項目中的這3個角色。RBAC2模型可以對這種情況進行限制。
另一個用戶指派限制的例子是一個角色限制其最大成員數(shù)，這被稱為角色的基數(shù)限制。例如，一個單位的最高領導只能為1人，中層干部的數(shù)量也是有限的，一旦分配給這些角色的用戶數(shù)超過了角色基數(shù)的限制，就不再接受新配給的用戶了。
限制角色的最小基數(shù)實現(xiàn)起來有些困難。例如，如果規(guī)定占用某個角色的最小用戶數(shù)，問題是系統(tǒng)如何在任何時刻都能知道這些占用者中的某個人沒有消失，如果消失的話，系統(tǒng)又應該如何去做。
在為用戶指派某個角色A時，在有的情況下要求該用戶必須是角色B的一個成員，B角色成為角色A的先決角色。先決角色（Prerequisite Roles）的概念來自于能力和適應性。對先決絕對的限制成為先決限制。一個通俗的例子是，一個數(shù)學副教授應該從數(shù)學講師中提拔，講師是任副教授的先決角色。但在實際系統(tǒng)中，不兼容角色之間的先決限制的情況也會發(fā)生。
在圖ap08-03中，可以限制只有本項目的成員才有資格擔任程序員的角色，通常在一個系統(tǒng)中，先決角色比新指派的角色的級別要低一些。但有的情況下，卻要求只有當用戶不是某個特殊角色時，才能擔任另一個角色A。如，需要執(zhí)行回避策略時需要這樣做，例如，本課題組成員不應當是本項目成果鑒定委員會的成員。這類限制也可以推廣到許可權方面。
由于用戶與角色的作用會與會話聯(lián)系在一起，因此對會話也可以施加限制。例如，可以允許一個用戶被指派給兩個角色，但不允許在同一時間內把該用戶在兩個角色中都激活。另外，還可以限制一個用戶在同一時間內可以激活的會話的數(shù)量，相應的，對該用戶所激活的會話中所分配許可權的數(shù)量也可以施加限制。
前面提到的繼承概念也可以視為一種限制。被分配給低級別角色的權限，也必須分配給該角色的所有上級角色。或等價的，一個指派給較高級別的角色的用戶必須指派給該角色的所有下級角色。因此從某種角度上講，RBAC1模型是冗余的，它被包含在RBAC2中。但RBAC1模型比較簡潔，用繼承代替限制可使概念更清晰。
實現(xiàn)時可以用函數(shù)來實現(xiàn)限制，當為用戶指定角色或為角色分配權限時就調用這些函數(shù)進行檢查，根據(jù)函數(shù)返回的結果決定分配是否滿足限制的要求，通常只對那些可被有效檢查和那些慣例性的一些簡單限制給與實現(xiàn)，因為這些限制可以保持較長的時間。
模型中的限制機制的有效性建立在每個用戶只有唯一標識符的基礎上，如果一個實際系統(tǒng)支持用戶擁有多標識符，限制將會失效。同樣，如果同一個操作可以有兩個以上的許可權來比準，那么，RBAC系統(tǒng)也無法實施加強的基本限制和責任分離餓限制。因此要求用戶與其標識符，許可與對應的操作之間一一對應。
RBAC3把RBAC1和RBAC2組合在一起，提供角色的分級和繼承的能力。但把這兩種概念組合在一起也引起一些新問題。
限制也可以應用于角色等級本身，由于角色間的等級關系滿足偏序關系，這種限制對模型而言是本質性的，可能會影響這種偏序關系。例如，附加的限制可能會限制一個給定角色的應有的下級角色的數(shù)量。
兩個或多個角色由可能被限制成沒有公共的上級角色或下級角色。這些類型的限制在概念角色等級的權力已經(jīng)被分散化的情況下是有用哦，但是安全主管卻希望對所有允許這些改變的方法加以限制。
在限制和角色的等級之間也會產(chǎn)生敏感的相互影響。在圖ap08-03的環(huán)境中，一個項目成員不允許同時擔任程序言與測試員的角色，但項目管理員所處的位置顯然是違反了該限制。在某種情況i下由高等級的角色違反這種限制是可接受的，但在其他情況下又不允許這種違反現(xiàn)象發(fā)生。
從嚴格性的角度來講，模型的規(guī)則不應該是一些情況下不允許而在另一情況下是允許的。類似的情況也會發(fā)生在對基數(shù)的限制上。假定限制一個用戶之多能分配給一個橘色，那么對圖中的測試員的一個指派能夠未被這種限制嗎？換句話說，基數(shù)限制是不是只能用于直接成員，是否也能應用于繼承成員上？
私有角色的概念可以說明這些限制是有用的。同樣在圖ap08-03的環(huán)境中，可以把測試員'，程序員'和項目管理員3個角色說明為互斥的，它們處于同一等級，沒有共同的上級角色，所以管理員角色沒有違反互斥限制。通常私有角色和其他角色之間沒有公共上級角色，因為它們是這個等級的最大元素，所以私有角色之間互斥關系可以無沖突的定義。
諸私有角色之間的相同部分可以被說明為具有0成員的最大技術限制。根據(jù)這種方法，測試員必須被指派給測試員'這個角色，而測試員角色就作為與管理員角色共享許可權的一種工具。
在前面的討論中，我們都假設RBAC的所有組件都是由單個的安全員來管理里。但是，對于一個大系統(tǒng)而言，系統(tǒng)中的角色可能成百上千，再加上它們之間的復雜關系，使得集中式的管理任務成為非常可怕的工作，因此通常由幾個管理員小組來完成。能否用RBAC管理自己本身呢？
RBAC的管理模型示于圖ap08-04。該圖的上半部分本質上與圖ap08-02相同，圖中的限制時針對所有成分的，圖的下半部分是對上半部分關于管理角色AR和管理許可權AP與正規(guī)角色集R和許可權集P是分別不可相交的。這個模型顯示，正規(guī)許可權只能分配給正規(guī)角色（RBAC模型中定義的角色），管理許可權只能分配給管理角色。
管理許可權AP有權改變組成RBAC0、RBAC1、RBAC2或RBAC3的所有成分，但正規(guī)許可權P不能。管理許可權與正規(guī)許可權不相交，即AP∩P=。管理許可權和正規(guī)許可權只能分別分配給管理角色AR和正規(guī)角色R，并且AR∩R=。
在圖ap08-04的上半部可以對應RBAC0、RBAC1、RBAC2和RBAC3模型，類似地下半部可以對應ARBAC0、ARBAC1、ARBAC2和ARBAC3模型，此處的A表示“管理”。ARBAC0~ARBAC3形成了RBAC的管理模型族，成為ARBAC97。通常我們期望管理模型比RBAC模型本身簡單一些，因此可以利用ARBAC0管理RBAC3，而不是用ARBAC3去管理RBAC0模型。
URA87：用戶-角色指派。該組件涉及用戶-指派關系UA的管理，該關系把用戶與角色關聯(lián)在一起。對該關系的修改權由管理角色控制，這樣，管理角色中的成員有權管理正規(guī)角色中的成員關系。把一個用戶指定為管理角色是在URA97以外完成的，并假定是由安全員完成的。
PRA97：許可權-角色指派。該組件涉及角色-許可權的指派與撤銷。從角色觀點來看，用戶和許可權有類似的特點，它們都是由角色聯(lián)系在一起的實在實體。因此，可以把PRA97看做是URA97的對偶組件。
RRA97：角色-角色指派。為了便于對角色的管理，對角色又進行了分類。該組件涉及3類角色，它們是：
-
能力（Abilities）角色——進以許可權和其他能力做成成員的角色。
-
組（Groups）角色——僅以用戶和其他組為成員的一類角色。
-
UP-角色——表示用戶與許可權的角色，這類角色對其成員沒有限制，成員可以使用戶、角色、許可權、能力、組或其他UP-角色。
區(qū)別這三類模型的主要原因是可以應用不同的管理模型去建立不同類型角色之間的關系。區(qū)分的動因首先是對能力的考慮，能力是許可權的集合，可以把該集合中所有許可權作為一個單位指派給一個角色。類似的，組是用戶的集合，可以把該集合中所有許可權作為一個單位指派給一個角色。組和能力角色都似乎可以劃分等級的。
在一個UP-角色中，一個能力是否是其的一個成員是由UP-角色是否支配該能力決定的，如果支配就是，否則就不是。相反的，如果一個UP-角色被一個組角色支配，則這個組就是該UP-角色的成員。
對ARBAC97管理模型的研究還在繼續(xù)之中，對能力-指派與組-指派的形式化已基本完成，對UP-角色概念的研究成果還未形式化。
符合各類組織機構的安全管理需求。RBAC模型支持最小特權原則、責任分離原則，這些原則是任何組織的管理工作都需要的。這就使得RBAC模型由廣泛的應用前景。
RBAC模型支持數(shù)據(jù)抽象原則和繼承概念。由于目前主流程序設計語言都支持面向對象技術，RBAC的這一特性便于在實際系統(tǒng)中應用實現(xiàn)。
模型中概念與實際系統(tǒng)緊密對應。RBAC模型中的角色、用戶和許可權等概念都是實際系統(tǒng)實際存在的實體，便于設計者建立現(xiàn)存的或待建系統(tǒng)的RBAC模型。
RBAC模型仍素具訪問控制類模型，本質是對訪問矩陣模型的擴充，能夠很好的解決系統(tǒng)中主體對客氣的訪問控制訪問權力的分配與控制問題，但模型沒有提供信息流控制機制，還不能完全滿足信息系統(tǒng)的全部安全需求。
雖然也有人認為可以用RBAC去仿真基于格的訪問控制系統(tǒng)（LBAC），但RBAC對系統(tǒng)內部信息流的控制不是直觀的，需要模型外的功能支持。有關信息流控制的作用域原理將在第四章介紹，屆時讀者可以進一步理解RBAC模型的這種缺陷。
RBAC模型沒有提供操作順序控制機制。這一缺陷使得RBAC模型很難應用關于那些要求有嚴格操作次序的實體系統(tǒng)，例如，在購物控制系統(tǒng)中要求系統(tǒng)對購買步驟的控制，在客戶未付款之前不應讓他把商品拿走。RBAC模型要求把這種控制機制放到模型外去實現(xiàn)。
RBAC96模型和RBAC97uanli模型都故意回避了一些問題，如是否允許一個正在會話的用戶再創(chuàng)建一個新會話，管理模型不支持用戶和許可權的增加與刪除等管理工作燈，都是需要解決而未提供支持的問題，這些問題都還在研究中，但是如果缺少這些能力的支持，模型的而應用也將受到影響。相反，訪問絕陣模型提供了用戶和權限修改功能，因此，不能說RBAC模型能夠完全取代訪問矩陣模型。
posted on 2009-08-18 17:18
憶風 閱讀(1508)
評論(0) 編輯 收藏 所屬分類:
Java EE