中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

在Saas類產(chǎn)品中，權(quán)限系統(tǒng)是一個(gè)非常重要的控制模型。本文作者分享了RBAC權(quán)限模型的相關(guān)經(jīng)驗(yàn)，供大家參考。

一、為什么需要權(quán)限系統(tǒng)（背景與目的）

每個(gè)企業(yè)都有自己的分工協(xié)作體系；不同崗位的員工，負(fù)責(zé)不同的工作內(nèi)容；不屬于崗位職責(zé)范圍內(nèi)的事情，員工通常不具有參與權(quán)和知情權(quán)。

如果每個(gè)崗位地員工都可以參與所有的工作、看到所有的信息，就會(huì)給企業(yè)的分工協(xié)作體系造成巨大沖擊，導(dǎo)致內(nèi)部管理混亂。

企業(yè)通過對(duì)員工在系統(tǒng)中擁有的權(quán)限進(jìn)行控制，讓不同崗位、層級(jí)的員工，只能使用和看到其職權(quán)范圍內(nèi)的功能和信息，以確保分工協(xié)作體系能順暢運(yùn)作，同時(shí)維護(hù)企業(yè)信息安全。

二、權(quán)限系統(tǒng)解決什么問題

權(quán)限系統(tǒng)，是指對(duì)用戶在系統(tǒng)中可操作的功能、可查看數(shù)據(jù)范圍進(jìn)行控制的功能模塊。

通俗的解釋是：權(quán)限系統(tǒng)通過設(shè)定不同的用戶角色，再將權(quán)限分配給各個(gè)角色，控制不同的用戶，能在系統(tǒng)中使用什么功能、查看什么信息，是企業(yè)對(duì)員工進(jìn)行權(quán)限控制的工具。

• 設(shè)定運(yùn)營人員為“電商運(yùn)營”角色，并分配商品管理、訂單管理、活動(dòng)管理權(quán)限。
• 權(quán)限系統(tǒng)允許了運(yùn)營人員查看和編輯商品信息、訂單信息、活動(dòng)信息，禁止了他們對(duì)財(cái)務(wù)等非崗位職責(zé)范圍內(nèi)的功能操作和信息查看。

并非所有的系統(tǒng)都需要做權(quán)限控制——只有當(dāng)系統(tǒng)功能足夠多、使用角色多樣時(shí)，才有對(duì)用戶進(jìn)行權(quán)限控制的必要。

三、權(quán)限模型有哪些

在權(quán)限系統(tǒng)中我們會(huì)遇到類似這樣的權(quán)限：

• 訪問權(quán)限：控制用戶能否登錄系統(tǒng)和訪問系統(tǒng)資源的權(quán)限。
• 功能權(quán)限：控制用戶可以使用的系統(tǒng)功能和操作的權(quán)限。
• 數(shù)據(jù)權(quán)限：控制用戶可以訪問、查看、修改或刪除的數(shù)據(jù)的權(quán)限。 配置權(quán)限：控制用戶可以修改系統(tǒng)配置和設(shè)置的權(quán)限。
• 審計(jì)權(quán)限：控制用戶可以查看系統(tǒng)日志和審計(jì)記錄的權(quán)限。 安全權(quán)限：控制用戶可以管理系統(tǒng)賬戶和權(quán)限的權(quán)限。
• 文件權(quán)限：控制用戶可以操作系統(tǒng)文件和文件夾的權(quán)限。 執(zhí)行權(quán)限：控制用戶可以執(zhí)行哪些程序、腳本或命令的權(quán)限。
• 通信權(quán)限：控制用戶可以使用哪些通信方式和進(jìn)行何種通信的權(quán)限。

常見的權(quán)限設(shè)計(jì)控制模型有：自主訪問控制（DAC）強(qiáng)制訪問控制（MAC）訪問控制列表(ACL)、基于角色的訪問控制(RBAC) 、基于任務(wù)和工作流的訪問控制(TBAC) 、基于任務(wù)和角色的訪問控制(T-RBAC)、基于對(duì)象的訪問控制（OBAC）、使用控制模型( UCON)、基于屬性的訪問控制（ABAC）

四、權(quán)限系統(tǒng)的要求

穩(wěn)定可靠、靈活方便、容易實(shí)現(xiàn)、維護(hù)成本不高

五、RBAC權(quán)限模型（Role-Based-Access-Control）

權(quán)限設(shè)計(jì)

從業(yè)務(wù)分類上來講權(quán)限可以分為數(shù)據(jù)查看權(quán)限，數(shù)據(jù)修改權(quán)限等，對(duì)應(yīng)到系統(tǒng)設(shè)計(jì)中有頁面權(quán)限、菜單權(quán)限、按鈕權(quán)限等。菜單也分一級(jí)菜單、二級(jí)菜單甚至三級(jí)菜單，菜單對(duì)應(yīng)的頁面里又有很多按鈕，我們?cè)谠O(shè)計(jì)的時(shí)候最好把權(quán)限設(shè)計(jì)成樹形結(jié)構(gòu)，這樣在申請(qǐng)權(quán)限的時(shí)候就可以一目了然的看到菜單的結(jié)構(gòu)，需要哪些權(quán)限就非常的明了了，如下圖所示：

為什么需要角色

權(quán)限結(jié)構(gòu)梳理清晰之后，需要思考怎么把權(quán)限分配給用戶，用戶少的情況下，可以直接分配，一個(gè)用戶可以有多個(gè)權(quán)限，統(tǒng)一一個(gè)權(quán)限可以被多個(gè)用戶擁有，用戶-權(quán)限的模型結(jié)構(gòu)如下所示：

這種模型能夠滿足權(quán)限的基本分配能力，但是隨著用戶數(shù)量的增長，這種模型的弊端就凸顯出來了，每一個(gè)用戶都需要去分配權(quán)限，非常的浪費(fèi)管理員的時(shí)間和精力，并且用戶和權(quán)限雜亂的對(duì)應(yīng)關(guān)系會(huì)給后期帶來巨大的維護(hù)成本。用戶-權(quán)限對(duì)應(yīng)關(guān)系圖：

這種對(duì)應(yīng)關(guān)系在用戶多的情況下基本無法維護(hù)了。其實(shí)很多用戶負(fù)責(zé)同一個(gè)業(yè)務(wù)模塊所需要的權(quán)限是一樣的，這樣的話我們是不是可以借助第三個(gè)媒介，把需要相同的權(quán)限都分配給這個(gè)媒介，然后用戶和媒介關(guān)聯(lián)起來，用戶就擁有了媒介的權(quán)限了。這就是經(jīng)典的RBAC模型，其中媒介就是我們通常所說的角色。

權(quán)限模型的演進(jìn)

RBAC0模型

有了角色之后可以把權(quán)限分配給角色，需要相同權(quán)限的用戶和角色對(duì)應(yīng)起來就可以了，一個(gè)權(quán)限可以分配給多個(gè)角色，一個(gè)角色可以擁有多個(gè)權(quán)限，同樣一個(gè)用戶可以分配多個(gè)角色，一個(gè)角色也可以對(duì)應(yīng)多個(gè)用戶，對(duì)應(yīng)模型如下所示：

這就是經(jīng)典的RBAC模型了（role-based-access-control），在這里面角色起到了橋梁左右，連接了用戶和權(quán)限的關(guān)系，每個(gè)角色可以擁有多個(gè)權(quán)限，每個(gè)用戶可以分配多個(gè)角色，這樣用戶就擁有了多個(gè)角色的多個(gè)權(quán)限。

同時(shí)因?yàn)橛薪巧鳛槊浇?，大大降低了錯(cuò)綜復(fù)雜的交互關(guān)系，比如一家有上萬人的公司，角色可能只需要幾百個(gè)就搞定了，因?yàn)楹芏嘤脩粜枰臋?quán)限是一樣的，分配一樣的角色就可以了。這種模型的對(duì)應(yīng)關(guān)系圖如下所示：

用戶和角色，角色和權(quán)限都是多對(duì)多的關(guān)系，這種模型是最通用的權(quán)限管理模型，節(jié)省了很大的權(quán)限維護(hù)成本， 但是實(shí)際的業(yè)務(wù)千變?nèi)f化，權(quán)限管理的模型也需要根據(jù)不同的業(yè)務(wù)模型適當(dāng)?shù)恼{(diào)整，比如一個(gè)公司內(nèi)部的組織架構(gòu)是分層級(jí)的，層級(jí)越高權(quán)限越大，因?yàn)閷蛹?jí)高的人不僅要擁有自己下屬擁有的權(quán)限，二期還要有一些額外的權(quán)限。

RBAC模型可以給不同層級(jí)的人分配不同的角色，層級(jí)高的對(duì)應(yīng)角色的權(quán)限就多，這樣的處理方式可以解決問題，但是有沒有更好的解決辦法呢，答案肯定是有的，這就引出角色繼承的RBAC模型。

RBAC1模型（角色繼承的RBAC模型）

角色繼承的RBAC模型又稱RBAC1模型。每個(gè)公司都有自己的組織架構(gòu)，比如公司里管理財(cái)務(wù)的人員有財(cái)務(wù)總監(jiān)、財(cái)務(wù)主管、出納員等，財(cái)務(wù)主管需要擁有但不限于出納員的權(quán)限，財(cái)務(wù)總監(jiān)需要擁有但不限于財(cái)務(wù)主管的權(quán)限，像這種管理關(guān)系向下兼容的模式就需要用到角色繼承的RBAC模型。角色繼承的RBAC模型的思路是上層角色繼承下層角色的所有權(quán)限，并且可以額外擁有其他權(quán)限。

從模型圖中可以看出下級(jí)角色擁有的權(quán)限，上級(jí)角色都擁有，并且上級(jí)角色可以擁有其他的權(quán)限。角色的層級(jí)關(guān)系可以分為兩種，一種是下級(jí)角色只能擁有一個(gè)上級(jí)角色，但是上級(jí)角色可以擁有多個(gè)下級(jí)角色，這種結(jié)構(gòu)用圖形表示是一個(gè)樹形結(jié)構(gòu)，如下圖所示：

還有一種關(guān)系是下級(jí)角色可以擁有多個(gè)上級(jí)角色，上級(jí)角色也可以擁有多個(gè)下級(jí)角色，這種結(jié)構(gòu)用圖形表示是一個(gè)有向無環(huán)圖，如下圖所示：

樹形圖是我們比較常用的，因?yàn)橐粋€(gè)用戶一般情況下不會(huì)同時(shí)有多個(gè)直屬上級(jí)，比如財(cái)務(wù)部只能有一個(gè)財(cái)務(wù)總監(jiān)，但是可以有多個(gè)財(cái)務(wù)主管和收納員。

RBAC2模型（帶約束的RBAC模型）

帶約束的RBAC模型又成RBAC2模型。在實(shí)際工作中，為了安全的考慮會(huì)有很多約束條件，比如財(cái)務(wù)部里同一個(gè)人不能即是會(huì)計(jì)又是審核員，跟一個(gè)人同一時(shí)間不能即是運(yùn)動(dòng)員又是裁判員是一個(gè)道理的，又比如財(cái)務(wù)部的審核員不能超過2個(gè)，不能1個(gè)也沒有。因?yàn)榻巧蜋?quán)限是關(guān)聯(lián)的，所以我們做好角色的約束就可以了。

常見的約束條件有：角色互斥、基數(shù)約束、先決條件約束等。

角色互斥：如果角色A和角色B是互斥關(guān)系的話，那么一個(gè)用戶同一時(shí)間不能即擁有角色A，又擁有角色B，只能擁有其中的一個(gè)角色。

比如我們給一個(gè)用戶賦予了會(huì)計(jì)的角色就不能同時(shí)再賦予審核員的角色，如果想擁有審核員的角色就必須先去掉會(huì)計(jì)的角色。假設(shè)提交角色和審核角色是互質(zhì)的，我們可以用圖形表示：

基數(shù)約束：同一個(gè)角色被分配的用戶數(shù)量可以被限制，比如規(guī)定擁有超級(jí)管理員角色的用戶有且只有1個(gè)；用戶被分配的角色數(shù)量也需要被限制，角色被分配的權(quán)限數(shù)量也可以被限制。

先決條件約束：用戶想被賦予上級(jí)角色，首先需要擁有下級(jí)角色，比如技術(shù)負(fù)責(zé)人的角色和普通技術(shù)員工角色是上下級(jí)關(guān)系，那么用戶想要用戶技術(shù)負(fù)責(zé)人的角色就要先擁有普通技術(shù)員工的角色。

用戶劃分

用戶組

我們創(chuàng)建角色是為了解決用戶數(shù)量大的情況下，用戶分配權(quán)限繁瑣以及用戶-權(quán)限關(guān)系維護(hù)成本高的問題。抽象出一個(gè)角色，把需要一起操作的權(quán)限分配給這個(gè)角色，把角色賦予用戶，用戶就擁有了角色上的權(quán)限，這樣避免了一個(gè)個(gè)的給用戶分配權(quán)限，節(jié)省了大量的資源。

同樣的如果有一批用戶需要相同的角色，我們也需要一個(gè)個(gè)的給用戶分配角色，比如一個(gè)公司的客服部門有500多個(gè)人，有一天研發(fā)部研發(fā)了一套查詢后臺(tái)數(shù)據(jù)的產(chǎn)品，客服的小伙伴都需要使用，但是客服由于之前并沒有統(tǒng)一的一個(gè)角色給到所有的客服小伙伴，這時(shí)候需要新加一個(gè)角色，把權(quán)限分配給該角色，然后再把角色一個(gè)個(gè)分配給客服人員，這時(shí)候會(huì)發(fā)現(xiàn)給500個(gè)用戶一個(gè)個(gè)添加角色非常的麻煩。但是客服人員又有共同的屬性，所以我們可以創(chuàng)建一個(gè)用戶組，所有的客服人員都屬于客服用戶組，把角色分配給客服用戶組，這個(gè)用戶組下面的所有用戶就擁有了需要的權(quán)限。

RBAC模型添加用戶組之后的模型圖如下所示：

很多朋友會(huì)問，用戶組和角色有什么區(qū)別呢？簡單的來說，用戶組是一群用戶的組合，而角色是用戶和權(quán)限之間的橋梁。用戶組把相同屬性的用戶組合起來，比如同一個(gè)項(xiàng)目的開發(fā)、產(chǎn)品、測試可以是一個(gè)用戶組，同一個(gè)部門的相同職位的員工可以是一個(gè)用戶組， 一個(gè)用戶組可以是一個(gè)職級(jí)，可以是一個(gè)部門，可以是一起做事情的來自不同崗位的人。

用戶可以分組，權(quán)限也可以分組，權(quán)限特別多的情況下，可以把一個(gè)模塊的權(quán)限組合起來成為一個(gè)權(quán)限組，權(quán)限組也是解決權(quán)限和角色對(duì)應(yīng)關(guān)系復(fù)雜的問題。

比如我們定義權(quán)限的時(shí)候一級(jí)菜單、二級(jí)菜單、按鈕都可以是權(quán)限，一個(gè)一級(jí)菜單下面有幾十個(gè)二級(jí)菜單，每個(gè)二級(jí)菜單下面又有幾十個(gè)按鈕，這時(shí)候我們把權(quán)限一個(gè)個(gè)分配給角色也是非常麻煩的，可以采用分組的方法把權(quán)限分組，然后把分好的組賦予角色就可以了。

給權(quán)限分組也是個(gè)技術(shù)活，需要理清楚權(quán)限之間的關(guān)系，比如支付的運(yùn)營后臺(tái)我們需要查各種信息，賬務(wù)的數(shù)據(jù)、訂單的數(shù)據(jù)、商戶的數(shù)據(jù)等等，這些查詢的數(shù)據(jù)并不在一個(gè)頁面，每個(gè)頁面也有很多按鈕，我們可以把這幾個(gè)頁面以及按鈕對(duì)應(yīng)的權(quán)限組合成一個(gè)權(quán)限組賦予角色。加入權(quán)限組之后的RBAC模型如下所示：

實(shí)際工作中我們很少給權(quán)限分組，給用戶分組的場景會(huì)多一些，有的時(shí)候用戶組也可以直接和權(quán)限關(guān)聯(lián)，這個(gè)看實(shí)際的業(yè)務(wù)場景是否需要，權(quán)限模型沒有統(tǒng)一的，業(yè)務(wù)越復(fù)雜業(yè)務(wù)模型會(huì)約多樣化。

組織

每個(gè)公司都有自己的組織架構(gòu)，很多時(shí)候權(quán)限的分配可以根據(jù)組織架構(gòu)來劃分。因?yàn)橥粋€(gè)組織內(nèi)的小伙伴使用的大部分權(quán)限是一樣的。如下所示一個(gè)公司的組織架構(gòu)圖：

按照這個(gè)組織架構(gòu)，每一個(gè)組織里的成員使用的基礎(chǔ)權(quán)限很可能是一樣的，比如人力資源都需要看到人才招聘的相關(guān)信息，市場推廣都需要看到行業(yè)分析的相關(guān)信息，按照組織來分配角色會(huì)有很多優(yōu)勢：

實(shí)現(xiàn)權(quán)限分配的自動(dòng)化：和組織關(guān)系打通之后，按照組織來分配角色，如果有新入職的用戶，被劃分在某個(gè)組織下面之后，會(huì)自動(dòng)獲取該組織下所有的權(quán)限，無需人工分配。又比如有用戶調(diào)崗，只需要把組織關(guān)系調(diào)整就可以了，權(quán)限會(huì)跟著組織關(guān)系自動(dòng)調(diào)整，也無需人工干預(yù)。這么做首先需要把權(quán)限和組織關(guān)系打通。

控制數(shù)據(jù)權(quán)限：把角色關(guān)聯(lián)到組織，組織里的成員只能看到本組織下的數(shù)據(jù)，比如市場推廣和大客定制，市場推廣針對(duì)的是零散的客戶，大可定制針對(duì)的是有一定體量的客戶，相互的數(shù)據(jù)雖然在一個(gè)平臺(tái)，但是只能看自己組織下的數(shù)據(jù)。

加入組織之后的RBAC模型如下所示：

用戶可以在多個(gè)組織中，因?yàn)榻M織也有層級(jí)結(jié)構(gòu)，一個(gè)組織里只可以有多個(gè)用戶，所以用戶和組織的關(guān)系是多對(duì)多的關(guān)系，組織和角色的關(guān)系是一對(duì)一的關(guān)系。這個(gè)在工作中可以根據(jù)實(shí)際情況來確定對(duì)應(yīng)關(guān)系。

職位

一個(gè)組織下面會(huì)有很多職位，比如財(cái)務(wù)管理會(huì)有財(cái)務(wù)總監(jiān)、財(cái)務(wù)主管、會(huì)計(jì)、出納員等職位，每個(gè)職位需要的權(quán)限是不一樣的，可以像組織那樣根據(jù)職位來分配不同的角色，由于一個(gè)人的職位是固定的，所以用戶跟職位的對(duì)應(yīng)關(guān)系時(shí)一對(duì)一的關(guān)系，職位跟角色的對(duì)應(yīng)關(guān)系可以是多對(duì)多的關(guān)系。加入職位的RBAC模型如下所示：

理想的RBAC模型

RBAC模型根據(jù)不同業(yè)務(wù)場景的需要會(huì)有很多種演變，實(shí)際工作中業(yè)務(wù)是非常復(fù)雜的，權(quán)限分配也是非常復(fù)雜的，想要做出通用且高效的模型很困難。我們把RBAC模型的演變匯總起來會(huì)是一個(gè)支撐大數(shù)據(jù)量以及復(fù)雜業(yè)務(wù)的理想的模型。把RBAC、RBAC1、RBAC2、用戶組、組織、職位匯總起來的模型如下所示：

按照這個(gè)模型基本上能夠解決所有的權(quán)限問題，其中的對(duì)應(yīng)關(guān)系可以根據(jù)實(shí)際的業(yè)務(wù)情況來確定，一般情況下，組織和職位是一對(duì)多的關(guān)系，特殊情況下可以有多對(duì)多的情況，需要根據(jù)實(shí)際情況來定。

理想的RBAC模型并不是說我們一開始建權(quán)限模型就可以這么做，而是數(shù)據(jù)體量、業(yè)務(wù)復(fù)雜度達(dá)到一定程度之后可以使用這個(gè)模型來解決權(quán)限的問題，如果數(shù)據(jù)量特別少，比如剛成立的公司只有十幾個(gè)人，那完全可以用用戶-權(quán)限模型，都沒有必要使用RBAC模型。

六、從0到1搭建RBAC權(quán)限系統(tǒng)

權(quán)限系統(tǒng)的業(yè)務(wù)框架

權(quán)限系統(tǒng)在實(shí)際的企業(yè)it系統(tǒng)中起到一個(gè)中轉(zhuǎn)的作用，業(yè)務(wù)系統(tǒng)將想要控制的內(nèi)容同步到權(quán)限系統(tǒng)，權(quán)限系統(tǒng)再將控制結(jié)果下發(fā)到各個(gè)業(yè)務(wù)系統(tǒng)，從而達(dá)到權(quán)限控制的目的。

權(quán)限控制的維度

權(quán)限是用戶可以訪問的資源，包括菜單功能權(quán)限，數(shù)據(jù)權(quán)限；

• 功能權(quán)限：包括系統(tǒng)的目錄導(dǎo)航、菜單的訪問權(quán)限，以及按鈕和 API 操作的權(quán)限
• 數(shù)據(jù)權(quán)限：包括定義數(shù)據(jù)的查詢范圍權(quán)限，包括可見、不可見等

功能權(quán)限

功能權(quán)限為可見、可以操作的功能范圍；常見的有菜單目錄、功能按鈕等。

數(shù)據(jù)權(quán)限

數(shù)據(jù)權(quán)限為用戶可見的數(shù)據(jù)信息；常見的有行數(shù)據(jù)、字段數(shù)據(jù)；

附錄：其他權(quán)限控制模型

常見的權(quán)限設(shè)計(jì)控制模型有：自主訪問控制（DAC）強(qiáng)制訪問控制（MAC）訪問控制列表(ACL)、基于角色的訪問控制(RBAC) 、基于任務(wù)和工作流的訪問控制(TBAC) 、基于任務(wù)和角色的訪問控制(T-RBAC)、基于對(duì)象的訪問控制（OBAC）、使用控制模型( UCON)、基于屬性的訪問控制（ABAC）

一、ACL模型：訪問控制列表

Access Control List，ACL是最早的、最基本的一種訪問控制機(jī)制，是基于客體進(jìn)行控制的模型，在其他模型中也有ACL的身影。為了解決相同權(quán)限的用戶挨個(gè)配置的問題，后來也采用了用戶組的方式。

原理：每一個(gè)客體都有一個(gè)列表，列表中記錄的是哪些主體可以對(duì)這個(gè)客體做哪些行為，非常簡單。

例如：當(dāng)用戶A要對(duì)一篇文章進(jìn)行編輯時(shí)，ACL會(huì)先檢查一下文章編輯功能的控制列表中有沒有用戶A，有就可以編輯，無則不能編輯。再例如：不同等級(jí)的會(huì)員在產(chǎn)品中可使用的功能范圍不同。

缺點(diǎn)：當(dāng)主體的數(shù)量較多時(shí)，配置和維護(hù)工作就會(huì)成本大、易出錯(cuò)。

二、DAC模型：自主訪問控制

Discretionary Access Control，DAC是ACL的一種拓展。

原理：在ACL模型的基礎(chǔ)上，允許主體可以將自己擁有的權(quán)限自主地授予其他主體，所以權(quán)限可以任意傳遞。

例如：常見于文件系統(tǒng)，LINUX，UNIX、WindowsNT版本的操作系統(tǒng)都提供DAC的支持。

缺點(diǎn)：對(duì)權(quán)限控制比較分散，例如無法簡單地將一組文件設(shè)置統(tǒng)一的權(quán)限開放給指定的一群用戶。主體的權(quán)限太大，無意間就可能泄露信息。

三、MAC模型：強(qiáng)制訪問控制

Mandatory Access Control，MAC模型中主要的是雙向驗(yàn)證機(jī)制。常見于機(jī)密機(jī)構(gòu)或者其他等級(jí)觀念強(qiáng)烈的行業(yè)，如軍用和市政安全領(lǐng)域的軟件。

原理：主體有一個(gè)權(quán)限標(biāo)識(shí)，客體也有一個(gè)權(quán)限標(biāo)識(shí)，而主體能否對(duì)該客體進(jìn)行操作取決于雙方的權(quán)限標(biāo)識(shí)的關(guān)系。

例如：將軍分為上將>中將>少將，軍事文件保密等級(jí)分為絕密>機(jī)密>秘密，規(guī)定不同軍銜僅能訪問不同保密等級(jí)的文件，如少將只能訪問秘密文件；當(dāng)某一賬號(hào)訪問某一文件時(shí)，系統(tǒng)會(huì)驗(yàn)證賬號(hào)的軍銜，也驗(yàn)證文件的保密等級(jí)，當(dāng)軍銜和保密等級(jí)相對(duì)應(yīng)時(shí)才可以訪問。

缺點(diǎn)：控制太嚴(yán)格，實(shí)現(xiàn)工作量大，缺乏靈活性。

四、ABAC模型：基于屬性的訪問控制

Attribute-Based Access Control，能很好地解決RBAC的缺點(diǎn)，在新增資源時(shí)容易維護(hù)。

原理：通過動(dòng)態(tài)計(jì)算一個(gè)或一組屬性是否滿足某種機(jī)制來授權(quán)，是一種很靈活的權(quán)限模型，可以按需實(shí)現(xiàn)不同顆粒度的權(quán)限控制。這個(gè)模型在云系統(tǒng)中使用的比較多，比如 AWS，阿里云等。

考慮下面這些場景的權(quán)限控制：

授權(quán)某個(gè)人具體某本書的編輯權(quán)限

當(dāng)一個(gè)文檔的所屬部門跟用戶的部門相同時(shí)，用戶可以訪問這個(gè)文檔

當(dāng)用戶是一個(gè)文檔的擁有者并且文檔的狀態(tài)是草稿，用戶可以編輯這個(gè)文檔

早上九點(diǎn)前禁止 A 部門的人訪問 B 系統(tǒng)

在除了上海以外的地方禁止以管理員身份訪問 A 系統(tǒng)

用戶對(duì) 2022-06-07 之前創(chuàng)建的訂單有操作權(quán)限

可以發(fā)現(xiàn)上述的場景通過 RBAC模型 很難去實(shí)現(xiàn)，因?yàn)?RBAC模型 僅僅描述了用戶可以做什么操作，但是操作的條件，以及操作的數(shù)據(jù)，RBAC模型 本身是沒有這些限制的。但這恰恰是 ABAC模型 的長處，ABAC模型 的思想是基于用戶、訪問的數(shù)據(jù)的屬性、以及各種環(huán)境因素去動(dòng)態(tài)計(jì)算用戶是否有權(quán)限進(jìn)行操作。

在 ABAC模型 中，一個(gè)操作是否被允許是基于對(duì)象、資源、操作和環(huán)境信息共同動(dòng)態(tài)計(jì)算決定的。

對(duì)象：對(duì)象是當(dāng)前請(qǐng)求訪問資源的用戶。用戶的屬性包括 ID，個(gè)人資源，角色，部門和組織成員身份等

資源：資源是當(dāng)前用戶要訪問的資產(chǎn)或?qū)ο?，例如文件，?shù)據(jù)，服務(wù)器，甚至 API

操作：操作是用戶試圖對(duì)資源進(jìn)行的操作。常見的操作包括“讀取”，“寫入”，“編輯”，“復(fù)制”和“刪除”

環(huán)境：環(huán)境是每個(gè)訪問請(qǐng)求的上下文。環(huán)境屬性包含訪問的時(shí)間和位置，對(duì)象的設(shè)備，通信協(xié)議和加密強(qiáng)度等

在 ABAC模型 的決策語句的執(zhí)行過程中，決策引擎會(huì)根據(jù)定義好的決策語句，結(jié)合對(duì)象、資源、操作、環(huán)境等因素動(dòng)態(tài)計(jì)算出決策結(jié)果。每當(dāng)發(fā)生訪問請(qǐng)求時(shí)，ABAC模型 決策系統(tǒng)都會(huì)分析屬性值是否與已建立的策略匹配。如果有匹配的策略，訪問請(qǐng)求就會(huì)被通過。

例如：早上9:00，11:00期間A、B兩個(gè)部門一起以考生的身份考試，下午14:00，17:00期間A、B兩個(gè)部門相互閱卷。

缺點(diǎn)：規(guī)則復(fù)雜，不易看出主體與客體之間的關(guān)系，實(shí)現(xiàn)非常難，現(xiàn)在應(yīng)用的很少

六、TBAC模型：基于任務(wù)的訪問控制

對(duì)象的訪問權(quán)限控制并不是靜止不變的，而是隨著執(zhí)行任務(wù)的上下文環(huán)境發(fā)生變化。

TBAC模型由工作流，授權(quán)結(jié)構(gòu)體，受托人集，許可集四部分組成。

TBAC模型一般用五元組（主體，客體，許可，生命周期，授權(quán)步）來表示。

如：去銀行辦理：柜員在窗口有讀取權(quán)，上交上一級(jí)后失去這個(gè)權(quán)利。

被賦予某個(gè)任務(wù)的時(shí)候才能有這個(gè)權(quán)限。

七、T-RBAC模型：基于任務(wù)和角色的訪問控制模型

T-RBAC 模型把任務(wù)和角色置于同等重要的地位， 它們是兩個(gè)獨(dú)立而又相互關(guān)聯(lián)的重要概念。任務(wù)是RBAC 和TBAC能結(jié)合的基礎(chǔ)。

T-RBAC 模型中是先將訪問權(quán)限分配給任務(wù)，再將任務(wù)分配給角色，角色通過任務(wù)與權(quán)限關(guān)聯(lián)，任務(wù)是角色和權(quán)限交換信息的橋梁。

在T-RBAC模型中， 任務(wù)具有權(quán)限，角色只有在執(zhí)行任務(wù)時(shí)才具有權(quán)限， 當(dāng)角色不執(zhí)行任務(wù)時(shí)不具有權(quán)限;權(quán)限的分配和回收是動(dòng)態(tài)進(jìn)行的，任務(wù)根據(jù)流程動(dòng)態(tài)到達(dá)角色， 權(quán)限隨之賦予角色，當(dāng)任務(wù)完成時(shí)，角色的權(quán)限也隨之收回;角色在工作流中不需要賦予權(quán)限。這樣， 不僅使角色的操作、維護(hù)和任務(wù)的管理變得簡單方便， 也使得系統(tǒng)變得更為安全。

八、OBAC模型：基于對(duì)象的訪問控制

將訪問控制列表與受控對(duì)象或受控對(duì)象的屬性相關(guān)聯(lián)，并將訪問控制選項(xiàng)設(shè)計(jì)成為用戶，組或角色及其對(duì)應(yīng)權(quán)限的集合。

允許對(duì)策略和規(guī)則進(jìn)行重用，繼承和派生操作。派生對(duì)象可以繼承父對(duì)象的訪問控制設(shè)置。

可以減輕由于信息資源的派生，演化和重組等帶來的分配

一個(gè)單位可能混合使用五種訪問控制機(jī)制。最常用是OBAC，強(qiáng)制訪問控制比較少。學(xué)校里有基于角色的，有基于任務(wù)的。

網(wǎng)絡(luò)訪問控制的應(yīng)用

MAC地址過濾：自主訪問控制，網(wǎng)橋自行定義。

ACL訪問控制列表：自主訪問控制，用IP來做訪問控制。有一個(gè)路由表（選路，確定網(wǎng)域）。

VLAN隔離：OBAC，虛擬網(wǎng)絡(luò)需要一個(gè)表，網(wǎng)域切分。

防火墻訪問控制：TBAC任務(wù)流，決定賬號(hào)，packet等能不能通過，由于機(jī)制比較多，使用比較多的表。

控制策略和控制規(guī)則是OBAC訪問控制系統(tǒng)的核心所在，在基于受控對(duì)象的訪問控制模型中，將訪問控制列表與受控對(duì)象或受控對(duì)象的屬性相關(guān)聯(lián)，并將訪問控制選項(xiàng)設(shè)計(jì)成為用戶、組或角色及其對(duì)應(yīng)權(quán)限的集合；同時(shí)允許對(duì)策略和規(guī)則進(jìn)行重用、繼承和派生操作。這樣，不僅可以對(duì)受控對(duì)象本身進(jìn)行訪問控制，受控對(duì)象的屬性也可以進(jìn)行訪問控制，而且派生對(duì)象可以繼承父對(duì)象的訪問控制設(shè)置，這對(duì)于信息量巨大、信息內(nèi)容更新變化頻繁的管理信息系統(tǒng)非常有益，可以減輕由于信息資源的派生、演化和重組等帶來的分配、設(shè)定角色權(quán)限等的工作量。

OBAC從信息系統(tǒng)的數(shù)據(jù)差異變化和用戶需求出發(fā)，有效地解決了信息數(shù)據(jù)量大、數(shù)據(jù)種類繁多、數(shù)據(jù)更新變化頻繁的大型管理信息系統(tǒng)的安全管理。OBAC從受控對(duì)象的角度出發(fā)，將訪問主體的訪問權(quán)限直接與受控對(duì)象相關(guān)聯(lián)，一方面定義對(duì)象的訪問控制列表，增、刪、修改訪問控制項(xiàng)易于操作，另一方面，當(dāng)受控對(duì)象的屬性發(fā)生改變，或者受控對(duì)象發(fā)生繼承和派生行為時(shí)，無須更新訪問主體的權(quán)限，只需要修改受控對(duì)象的相應(yīng)訪問控制項(xiàng)即可，從而減少了訪問主體的權(quán)限管理，降低了授權(quán)數(shù)據(jù)管理的復(fù)雜性。

九、UCON模型：使用控制( UsageControl:UCON) 模型

使用控制( UsageControl:UCON) 模型 ， 也稱ABC模型。UCON模型包含三個(gè)基本元素: 主體、客體、權(quán)限和另外三個(gè)與授權(quán)有關(guān)的元素: 授權(quán)規(guī)則、條件、義務(wù)。

UCON模型中的主要元素如下:

主體( Subjects)。它是具有某些屬性和對(duì)客體(Objects)操作權(quán)限的實(shí)體。主體的屬性包括身份、角色、安全級(jí)別、成員資格等。這些屬性用于授權(quán)過程?？腕w( Objects) 。它是主體的操作對(duì)象，它也有屬性，包括安全級(jí)別、所有者、等級(jí)等。這些屬性也用于授權(quán)過程。

權(quán)限( Rights)。它是主體擁有的對(duì)客體操作的一些特權(quán)。權(quán)限由一個(gè)主體對(duì)客體進(jìn)行訪問或使用的功能集組成。UCON中的權(quán)限可分成許多功能類， 如審計(jì)類、修改類等。

授權(quán)規(guī)則( AuthorizationRules) 。它是允許主體對(duì)客體進(jìn)行訪問或使用前必須滿足的一個(gè)需求集。授權(quán)規(guī)則是用來檢查主體是否有資格訪問客體的決策因素。

條件( Conditions)。它是在使用授權(quán)規(guī)則進(jìn)行授權(quán)過程中， 允許主體對(duì)客體進(jìn)行訪問權(quán)限前必須檢驗(yàn)的一個(gè)決策因素集。條件是環(huán)境的或面向系統(tǒng)的決策因素。條件可用來檢查存在的限制， 使用權(quán)限是否有效，哪些限制必須更新等。

義務(wù)( Obligations)。它是一個(gè)主體在獲得對(duì)客體的訪問權(quán)限后必須履行的強(qiáng)制需求。分配了權(quán)限， 就應(yīng)有執(zhí)行這些權(quán)限的義務(wù)責(zé)任。

在UCON模型中， 授權(quán)規(guī)則、條件、義務(wù)與授權(quán)過程相關(guān)，它們是決定一個(gè)主體是否有某種權(quán)限能對(duì)客體進(jìn)行訪問的決策因素?；谶@些元素， UCON有四種可能的授權(quán)過程， 并由此可以證明:UCON模型不僅包含了DAC，MAC， RBAC， 而且還包含了數(shù)字版權(quán)管理(DRM)、信任管理等。UCON 模型涵蓋了現(xiàn)代商務(wù)和信息系統(tǒng)需求中的安全和隱私這兩個(gè)重要的問題。因此， UCON模型為研究下一代訪問控制提供了一種有希望的方法， 被稱作下一代訪問控制模型。