1.     概念

訪問控制技術是由美國國防部（Department of Defense, DoD）資助的研究和開發成果演變而來的。這一研究導致兩種基本型別訪問控制的產生：自主訪問控制（Discretionary Access Control, DAC）和強制訪問控制（Mandatory Access Control, MAC）。最初的研究和應用主要是為了防止機密資訊被未經授權者訪問，近期的應用主要是把這些策略應用到為商業領域。

自主訪問控制，允許把訪問控制權的授予和取消留給個體使用者來判斷。為沒有訪問控制權的個體使用者授予和廢除許可。自主訪問控制機制允許使用者被授權和取消訪問其控制之下的任何客體（object），換句話說，使用者就是他們控制下的客體的擁有者。對於這些組織，公司或代理機構是事實上的系統客體和處理他們的程式的擁有者。訪問優先權受組織控制，而且也常常基於僱員功能而不是資料所有權。

強制訪問控制，在美國國防部 Trusted Computer Security Evaluation Criteria (TCSEC) 中定義如下：“一種限制訪問客體的手段，它以包含在這些客體中的資訊敏感性和訪問這些敏感性資訊的主體的正式授權資訊（如清除）為基礎”。

什麼是基於角色訪問控制（Role-Based Access Control, RBAC）？NIST 有如下定義。

訪問是一種利用計算機資源去做某件事情的的能力，訪問控制是一種手段，通過它這種能力在某些情況下被允許或者受限制（通常是通過物理上和基於系統的控制）。基於計算機的訪問控制不僅可規定是“誰”或某個操作有權使用特定系統資源，而且也能規定被允許的訪問型別。這些控制方式可在計算機系統或者外部裝置中實現。

就基於角色訪問控制而言，訪問決策是基於角色的，個體使用者是某個組織的一部分。使用者具有指派的角色（比如醫生、護士、出納、經理）。定義角色的過程應該基於對組織運轉的徹底分析，應該包括來自一個組織中更廣範圍使用者的輸入。

訪問權按角色名分組，資源的使用受限於授權給假定關聯角色的個體。例如，在一個醫院系統中，醫生角色可能包括進行診斷、開據處方、指示實驗室化驗等；而研究員的角色則被限制在收集用於研究的匿名臨床資訊工作上。
    
    控制訪問角色的運用可能是一種開發和加強企業特殊安全策略，進行安全管理過程流程化的有效手段。

2.     核心物件模型設計（RBAC0）

根據RBAC模型的許可權設計思想，建立許可權管理系統的核心物件模型.物件模型中包含的基本元素主要有：使用者（Users）、使用者組（Group）、角色（Role）、控制物件（Resource Class）、訪問模式（Access Mode）、操作（Operator）。主要的關係有：分配角色許可權PA（Permission Assignment）、分配使用者角色UA（Users Assignmen描述如下：

1.        控制物件：是系統所要保護的資源（Resource Class），可以被訪問的物件。資源的定義需要注意以下兩個問題：

a)        資源具有層次關係和包含關係。例如，網頁是資源，網頁上的按鈕、文字框等物件也是資源，是網頁節點的子節點，如可以訪問按鈕，則必須能夠訪問頁面。

b)        這裡提及的資源概念是指資源的類別（Resource Class），不是某個特定資源的例項（Resource Instance）。資源的類別和資源的例項的區分，以及資源的粒度的細分，有利於確定許可權管理系統和應用系統之間的管理邊界，許可權管理系統需要對於資源的類別進行許可權管理，而應用系統需要對特定資源的例項進行許可權管理。兩者的區分主要是基於以下兩點考慮：

                         i.              一方面，資源例項的許可權常具有資源的相關性。即根據資源例項和訪問資源的主體之間的關聯關係，才可能進行資源的例項許可權判斷。 例如，在管理資訊系統中，需要按照營業區域劃分不同部門的客戶，A區和B區都具有修改客戶資料這一受控的資源，這裡“客戶檔案資料”是屬於資源的類別的範疇。如果規定A區只能修改A區管理的客戶資料，就必須要區分出資料的歸屬，這裡的資源是屬於資源例項的範疇。客戶檔案（資源）本身應該有其使用者的資訊（客戶資料可能就含有營業區域這一屬性），才能區分特定資源的例項操作，可以修改屬於自己管轄的資訊內容。

                       ii.              另一方面，資源的例項許可權常具有相當大的業務邏輯相關性。對不同的業務邏輯，常常意味著完全不同的許可權判定原則和策略。

2.        操作（許可權）：完成資源的類別和訪問策略之間的繫結。

3.        使用者：許可權的擁有者或主體。使用者和許可權實現分離，通過授權管理進行繫結。

4.        使用者組：一組使用者的集合。在業務邏輯的判斷中，可以實現基於個人身份或組的身份進行判斷。系統弱化了使用者組的概念，主要實現使用者（個人的身份）的方式。

5.        角色：許可權分配的單位與載體。角色通過繼承關係支援分級的許可權實現。例如，科長角色同時具有科長角色、科內不同業務人員角色。

6.        分配角色許可權PA：實現操作和角色之間的關聯關係對映。

7.        分配使用者角色UA：實現使用者和角色之間的關聯關係對映。

3.     HR資料許可權模型設計初稿

3.1.   訪問主體

在本系統中訪問主體是員工和使用者組。

如圖3.1.1中每個主體都有多個角色。每個角色又可能同時屬於多個主體。

公司、部門、職位一定有對應的一個使用者組，但使用者組不一定是公司、部門、職位當中一個，也可能是虛擬出來的一個組，比如：工會組織、公司籃球隊等等。

（圖3.1.1）

3.2.   分配使用者角色（Users Assignmen）

如圖3.1.1這裡的Users指的是所有訪問主體。使用者組、員工。

使用者組是可以無限制擴充的。

無論新增幾個主體到最後都會對映到角色（roles）表中，成為多個角色。

然後對角色分配訪問許可權控制。

3.3.     操作

操作（許可權）=訪問模式+資源（resource class）

如圖3.3.1，比如：頁面A有個查詢員工資訊的功能，我們在這裡把他看成一個“訪問客體”，被許可權控制的資源（resource class）。再假設訪問模式中有個“執行”模式，那麼兩者組合起來就是有個有效的操作（許可權），然後把這個許可權賦予角色，就OK了。

（圖3.3.1）

3.4.     分配角色許可權（Permission Assignment）

3.3節中提到，根據資源和訪問模式、我們這裡就有了很多操作，也就是許可權。

那麼我們只需要把這些許可權分配到角色就可以了。如圖3.4.1

（圖3.4.1）

3.5.     資源類別（Resources Class）

根據以上的描述可以看出來，在本模型中主體是可以無限制擴充的。那麼客體呢？我們可以看到，不管你有多少客體，到最後也都是分解成了多個資源類別（和主體一樣，把每個主體都分解成了多個角色），然後和訪問模式組成了操作（許可權），最後賦給角色。

我們再分析下資源類別模型。

我認為我們系統的資源類別可以分為2個方向，頁面功能和流程。

比如：員工資料查詢，這個頁面上就有查詢這個客體資源類別。

而員工轉正流程中又有直接主管審批這個資源。

那麼我們把資源類別（resources class）設計成如圖3.5.1

（圖3.5.1）

功能模組表中存放“流程”或“頁面功能”。

“功能模組類別”用來區分，這條記錄是“頁面功能”還是“流程”。

一個流程有多個審批操作。我們可以放到資源類別中。

頁面功能同理。

4.     小結

該物件模型最終將訪問控制模型轉化為訪問矩陣形式。訪問矩陣中的行對應於使用者，列對應於操作，每個矩陣元素規定了相應的角色，對應於相應的目標被准予的訪問許可、實施行為。按訪問矩陣中的行看，是訪問能力表CL(Access Capabilities)的內容；按訪問矩陣中的列看，是訪問控制表ACL（Access Control Lists）的內容。如表4.1

（表4.1）

圖4.1為整個許可權模型。

（圖4.1）

5.     思考

5.1.   相對角色

在很多時候我們都會用到相對角色這個概念。比如：員工轉正流程中就有個直接主管審批，那麼這個直接主管這個角色就是一個相對角色。這個相對角色在資料庫許可權模型中其實也是一個角色，只用新增到角色表中給這個角色賦許可權（操作）就可以了，但在開發過程中一定要注意相對角色的設定，特別是設定方法，公式。

5.2.   使用者組的聯想

使用者組可以是組織架構中的實體單位。同時也可以是虛擬的，由使用者自己新增、配置的一個角色的集合。角色又是許可權的集合。

那麼我們可以這麼做，新增一個系統管理員組，然後通過角色為這個組，分配好應有的許可權。以後如果有新的系統管理員，我們只需要放到這個組裡面去就可以，沒必要再重新配置一個使用者。

這樣就完全可以實現windows的許可權管理了。

5.3.   角色的繼承

給角色分配許可權（操作）其實也是件比較複雜的工作。如果角色間存在一定的關係，可以直接把另外一個角色的許可權直接複製過來，然後再新增自己需要的其他許可權，這樣不是會方便很多嗎？

繼承可分為兩種方式，一般繼承關係和受限繼承關係。一般繼承關係僅要求角色繼承關係是一個絕對偏序關係（不能繼承自己的子類），允許角色間的多繼承。而受限繼承關係則進一步要求角色繼承關係是一個樹結構（單繼承）。

5.4.   資源例項（Resource Instance）

場景1：有一個功能頁面，查詢員工資料。可訪問角色有“人事專員”和“部門經理”。“人事專員”進入可以查出全公司的所有員工資料。“部門經理”進入後，只能查出自己部門的員工資料。

場景1的解決方案：

1.        在功能模組（functionmodule）表中新增“查詢員工資料”這個功能。

2.        在功能資源（functionresource）表中新增這個“查詢員工資料”的兩個資源，“部門經理查詢”和“人事專員查詢”。

3.        抽象成資源類別（resourcesclass）。

4.        資源類別（resourcesclass）和訪問模式（accessmode）組合成2個操作（許可權）。

5.        把這兩個許可權分別賦予部門經理組所擁有的角色和人事專員組所擁有的角色。

6.        在開發過程中就可以根據兩個不同的資源，在這個頁面做查詢條件的處理。

場景2：有一個功能頁面，部門花名冊。可訪問角色有“部門經理”和任何登入後的員工。根據員工部門自動顯示所在部門的花名冊。如果是“部門經理”，就顯示一些“部門經理”可以看到的敏感資訊。比如，工資。

場景2的解決方案：

1.        在功能模組（functionmodule）表中新增“部門花名冊”這個功能。

2.        在功能資源（functionresource）表中新增這個“部門花名冊”的一個資源，“部門經理花名冊”。

3.        抽象成資源類別（resourcesclass）。

4.        資源類別（resourcesclass）和訪問模式（accessmode）組合成1個操作（許可權）。

5.        把這個許可權賦予部門經理組所擁有的角色。

6.        在開發過程中進入這個功能頁面，沒有這個許可權的顯示一般花名冊。有這個許可權的顯示部門經理花名冊。

小結：

資源例項讓我們在按鈕級許可權的基礎上，加上了對記錄和欄位的控制。當然，你也可以把場景1和場景2結合起來。記錄、欄位一起控制，這個肯定是可以的。

再擴充套件下。場景二中，如果有一天部門經理所能看到的東西改變了，加一項或少一項，怎麼辦呢？難道去改程式碼？

其實在很多情況下，都是可以做死的。比如場景二中大家都只能看到自己部門的花名冊。肯定不會有一天要看公司的花名冊，如果真有這個需求，那麼就應該再做個功能頁面。叫做“公司花名冊”。

但也有些情況，是要可以調整的。同樣是場景二，部門經理能看到的東西。哪天公司想變變，這個也是有可能的。

其實這個功能實現起來也非常簡單。如圖5.4.1。

無論什麼，到最後都會變成資源類別，我們直接給這個類別記錄一些屬性。到時候你只要根據這些屬性顯示就可以了，要變的時候把這些屬性變了就行了。只要願意，完全可以做個維護頁面。

表資源設定（resourcesetting）記錄一些訪問條件。比如，這個資源按部門查詢。如果需要你可以把他改成按公司查詢。

表字段設定（fieldsetting）記錄的是這個資源的欄位資訊。比如，部門經理可以看到“部門花名冊”的欄位。

（圖5.4.1）

6.     總結

本模型的主要設計思想是把所有訪問主體，包括部門、職位、公司、人等等。全部分解成一個或多個角色。

把所有訪問控制客體全部分解成一個和多個資源類別（Resources Class）。

把資源類別加上訪問模式（讀、寫、刪、執行等）成為一個操作，也就是許可權。

然後把這個許可權賦予到角色。

這個模型支援頁面級許可權、按鈕級許可權、記錄級許可權、欄位級許可權和這幾種許可權的任意組合。

在角色的分配上。他本身是支援一個客體有多個角色，一個角色屬於多個客體。支援使用者組角色、角色繼承、相對角色等。特別是使用者組這個設計。部門、職位、公司這些組織都可以抽象成一個使用者組，直接給這個組分配許可權就可以了。但使用者組不僅僅只有抽象實體組織這功能，他還可以無限制的擴充套件。比如可以新增一個虛擬的系統管理員組。他本身就是一個員工的集合，你可以以任何形式去組合人員。