基礎(chǔ)技術(shù)簡介
對于計算機系統(tǒng)的訪問控制瘦穆，一般有以下幾種訪問機制和類型：
1. 自主訪問控制（DAC: Discretionary Access Control）
自主訪問控制 Wikipedia
根據(jù)主體（如用戶烦感、進程或 I/O 設(shè)備等）的身份和所屬組來限制對客體的訪問。所謂的自主，是因為擁有訪問權(quán)限的主體修肠，可以直接（或間接）地將訪問權(quán)限賦予其他主體（除非受到強制訪問控制的限制）
自主訪問控制可以讓用戶或管理員自主定義資源（如數(shù)據(jù)庫、操作系統(tǒng)文件等）的訪問權(quán)限，其中訪問權(quán)限通常由 ACL（Access Control List）訪問控制列表來定義谈截。DAC 的一個典型例子為 Windows 的文件權(quán)限管理，用戶可定義某一個文件的訪問控制列表如下：
同時自主訪問控制允許擁有客體權(quán)限的用戶將權(quán)限分配給其它用戶涧偷，這也是 自主 的主要含義簸喂。
但由于能夠自主傳遞權(quán)限，在傳遞的過程中燎潮，可能導(dǎo)致用戶間接獲得本不該具有的權(quán)限喻鳄，因此自主訪問控制也是一種比較寬松的訪問控制。
2. 強制訪問控制（MAC: Mandatory Access Control）
強制訪問控制 Wikipedia
主體和對象各自具有一組安全屬性确封。每當(dāng)主體嘗試訪問對象時除呵，都會由操作系統(tǒng)內(nèi)核強制施行授權(quán)規(guī)則——檢查安全屬性并決定是否可進行訪問。通過強制訪問控制爪喘，安全策略由安全策略管理員集中控制颜曾；用戶無權(quán)覆蓋策略，例如不能給被否決而受到限制的文件授予訪問權(quán)限秉剑。
在歷史上泛豪，MAC 強制訪問控制經(jīng)常用在專業(yè)的軍用系統(tǒng)中，因此 MAC 有著高度嚴(yán)格的權(quán)限約束侦鹏。MAC 強制訪問控制只可由系統(tǒng)定義權(quán)限規(guī)則且由系統(tǒng)強制執(zhí)行诡曙，用戶與他們的進程不可修改權(quán)限規(guī)則。
MAC 強制訪問控制的實現(xiàn)有 Linux 的 SELinux 和 AppArmor略水。
MAC 的權(quán)限控制嚴(yán)格价卤，但同時靈活性不高房维，對于一般的互聯(lián)網(wǎng)軟件的適用度不高浇衬。
3. 基于屬性的訪問控制（ABAC: Attribute-Based Access Control）
Attribute-based access control Wikipedia
ABAC 也被稱為 PBAC（Policy-Based Access Control）质帅，其定義了訪問控制范例，通過使用屬性組合的策略來向用戶授予訪問權(quán)限慷暂。
我們知道現(xiàn)實中存在著各種實體，不同實體可通過不同的實體特性進行區(qū)分亡蓉，這些實體特性并稱為屬性录豺。
在一個權(quán)限系統(tǒng)中，可能會涉及到主體盖文、客體嘱蛋、權(quán)限、環(huán)境等概念五续，而這些概念實際上均可視為實體洒敏，更為重要的是可以通過屬性來描述表達這些實體。即：使用屬性統(tǒng)一描述和表達權(quán)限控制所涉及到的各類實體（其中包括訪問策略也同樣使用屬性表達）疙驾。
ABAC 被視為權(quán)限控制的未來凶伙，與下文即將介紹的 RBAC 基于角色的訪問控制相比，ABAC 擁有更為靈活與更為強大的權(quán)限控制能力它碎。
尤其是在分布式的開放環(huán)境中函荣，系統(tǒng)可能分布在不同的安全域之內(nèi)，相互之間只能知曉彼此的部分信息扳肛。此時基于角色的權(quán)限控制將會存在極大的局限性：不同系統(tǒng)之間角色模型不可能完全重合傻挂，建立關(guān)聯(lián)又將極其復(fù)雜。
但如果是以屬性為粒度挖息，那么系統(tǒng)之間則完全不需要了解彼此的“調(diào)用方”金拒，權(quán)限判斷完全基于“屬性”。這使得 ABAC 具有足夠的靈活性和可擴展性套腹，提高了系統(tǒng)之間的可交互性和安全性绪抛。
因此 ABAC 在分布式開發(fā)環(huán)境下，具有傳統(tǒng)訪問控制不具有的細(xì)粒度控制能力和大規(guī)模主體動態(tài)授權(quán)能力沉迹，同時擁有極強的靈活性和可擴展性睦疫。但基于屬性進行實體描述、策略表達鞭呕、權(quán)限判斷等需要較為復(fù)雜的模型設(shè)計與工程實現(xiàn)蛤育，固目前并沒有在工程上得到廣泛應(yīng)用（如 Kubernetes 曾使用 ABAC，但由于實現(xiàn)的復(fù)雜且難以理解葫松，之后轉(zhuǎn)而使用 RBAC）瓦糕。而 RBAC 依然是目前應(yīng)用最為廣泛和普遍的權(quán)限控制（RBAC 其實也只是 ABAC 的一種特例，角色 ID 可視為一個屬性）腋么。
4. 基于角色的訪問控制（RBAC: Role-Based Access Control)
基于角色的訪問控制是較為靈活也較為容易理解的一種訪問控制策略咕娄，其通過權(quán)限賦予角色，角色賦予用戶的方式將角色與用戶解耦珊擂，從而用戶與權(quán)限的靈活關(guān)聯(lián)圣勒。
基于角色的訪問控制是目前應(yīng)用最為廣泛的權(quán)限控制策略费变，固下文將單獨詳細(xì)的介紹該策略。
RBAC 訪問控制
RBAC 基于角色的訪問控制主要涉及到三種實體：
- 權(quán)限：對資源的訪問權(quán)限圣贸，比如對某文件的讀挚歧、更新等權(quán)限。在一些系統(tǒng)實現(xiàn)中吁峻，喜歡將其劃分為頁面權(quán)限滑负、操作權(quán)限、數(shù)據(jù)權(quán)限等類型用含。但想到標(biāo)簽包含了分類矮慕，所以實際上是否可以不劃分為頁面權(quán)限、操作權(quán)限啄骇、數(shù)據(jù)權(quán)限痴鳄。而只是在資源上打上頁面、操作缸夹、數(shù)據(jù)等標(biāo)簽夏跷？
- 角色：權(quán)限的集合
- 用戶：可被授予不同的角色
其中用戶可以有 ”組“ 的概念，將用戶分配到某個用戶組明未，即可擁有該用戶組下的權(quán)限，從而省去每個權(quán)限單獨授予的步驟壹蔓。
同時權(quán)限也可有 “組” 的概念趟妥，可以將一些使用場景相對固定的一組功能或權(quán)限封裝成組。將其賦予某個角色佣蓉，該角色將擁有該組下的所有權(quán)限披摄。但是一般而言系統(tǒng)的權(quán)限是可控，所以實際情況中較少使用權(quán)限組勇凭。
RBAC 的實現(xiàn)模型
RBAC 在不同場景下會有一定的不同擴展疚膊，因此衍生出了幾種不同的實現(xiàn)模型：
1. RBAC0
最基礎(chǔ)、最原始的 RBAC 實現(xiàn)模型虾标，同時也是下文中其它實現(xiàn)模型的基礎(chǔ)寓盗。
RBAC0 模型如下圖所示：
其中用戶與角色，角色與權(quán)限為多對多的關(guān)系璧函，用戶可擁有不同角色傀蚌，角色可包含不同權(quán)限。
RBAC0 包含了 RBAC 最基本的要素蘸吓，通過角色實現(xiàn)了用戶與權(quán)限的解耦善炫，但除此之外也沒有其它多余的關(guān)系或約束。
2. RBAC1
在許多業(yè)務(wù)場景中库继，角色之間是具有上下級或繼承的關(guān)系的箩艺。例如在一家中大型企業(yè)里窜醉，通常有員工、組長艺谆、部門總經(jīng)理等角色榨惰，且角色之間存在著上下級關(guān)系。
RBAC1 在 RBAC0 的基礎(chǔ)上引入了角色的繼承關(guān)系擂涛，能夠使的角色之間層次更加分明读串，實現(xiàn)角色的分層分組。
RBAC1 模型如下圖所示：
3. RBAC2
角色之間除了簡單的繼承關(guān)系撒妈，有時還存在一些約束關(guān)系恢暖。例如某些角色不能同時存在或擁有，即角色之間是互斥的狰右。
RBAC2 在 RBAC0 的基礎(chǔ)上引入了對角色的約束和限制杰捂。這些限制可大體分為兩類：
- 靜態(tài)職責(zé)分離 SSD
- 互斥角色：不能同時擁有互斥角色
- 基數(shù)約束：用戶擁有的角色數(shù)有一定限制，即一個用戶的角色數(shù)量是有限的棋蚌。
- 先決條件角色：想要擁有某個角色嫁佳，需要事先擁有另一個先決角色（通常是低一級的角色）
- 動態(tài)職責(zé)分離 DSD
- 運行時互斥，靜態(tài)時可以有兩種角色谷暮，但運行時不能同時激活運行時互斥角色蒿往。
RBAC2 模型如下圖所示：
4. RBAC3
即 RBAC1 與 RBAC2 的合集，在對角色進行分層的同時湿弦，也對角色增加各種約束和限制瓤漏。
RBAC3 模型如下圖所示：
參考資料
有贊權(quán)限系統(tǒng)(SAM)
自主訪問控制 Wikipedia
強制訪問控制 Wikipedia
Trusted Extensions 提供自主訪問控制和強制訪問控制
ABAC Wikipedia
基于屬性的訪問控制研究進展 王小明，付紅颊埃，張立臣 - 電子學(xué)報
基于屬性的訪問控制模型 李曉峰蔬充，馮登國，陳朝武班利，房子河 - 通信學(xué)報, 2008
Ravi S. Sandhu... “Role-basedaccess control models,” IEEE Computer, 29(2):38-47, February 1996.
What is the difference between RBAC and DAC/ACL?
汪
汪
