今天來聊聊權(quán)限系統(tǒng)的設(shè)計以及主流的五種權(quán)限模型。

權(quán)限管控可以通俗地理解為權(quán)力限制，即不同的人由于擁有不同權(quán)力，他所看到的、能使用的可能不一樣。對應(yīng)到一個應(yīng)用系統(tǒng)，其實就是一個用戶可能擁有不同的數(shù)據(jù)權(quán)限（看到的）和操作權(quán)限（使用的）。

主流的權(quán)限模型主要分為以下五種：

• ACL模型：訪問控制列表
• DAC模型：自主訪問控制
• MAC模型：強制訪問控制
• ABAC模型：基于屬性的訪問控制
• RBAC模型：基于角色的權(quán)限訪問控制

ACL模型：訪問控制列表

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

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

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

缺點：當主體的數(shù)量較多時，配置和維護工作就會成本大、易出錯。

DAC模型：自主訪問控制

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

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

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

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

MAC模型：強制訪問控制

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

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

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

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

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

Attribute-Based Access Control，能很好地解決RBAC的缺點，在新增資源時容易維護。

原理：通過動態(tài)計算一個或一組屬性是否滿足某種機制來授權(quán)，是一種很靈活的權(quán)限模型，可以按需實現(xiàn)不同顆粒度的權(quán)限控制。

屬性通常有四類：

1. 主體屬性，如用戶年齡、性別等；
2. 客體屬性，如一篇文章等；
3. 環(huán)境屬性，即空間限制、時間限制、頻度限制；
4. 操作屬性，即行為類型，如讀寫、只讀等。

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

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

RBAC，基于角色的權(quán)限訪問控制

Role-Based Access Control，核心在于用戶只和角色關(guān)聯(lián)，而角色代表對了權(quán)限，是一系列權(quán)限的集合。

RBAC三要素：

1. 用戶：系統(tǒng)中所有的賬戶
2. 角色：一系列權(quán)限的集合（如：管理員，開發(fā)者，審計管理員等）
3. 權(quán)限：菜單，按鈕，數(shù)據(jù)的增刪改查等詳細權(quán)限。

在RBAC中，權(quán)限與角色相關(guān)聯(lián)，用戶通過成為適當角色的成員而得到這些角色的權(quán)限。

角色是為了完成各種工作而創(chuàng)造，用戶則依據(jù)它的責任和資格來被指派相應(yīng)的角色，用戶可以很容易地從一個角色被指派到另一個角色。

角色可依新的需求和系統(tǒng)的合并而賦予新的權(quán)限，而權(quán)限也可根據(jù)需要而從某角色中回收。角色與角色的關(guān)系同樣也存在繼承關(guān)系防止越權(quán)。

優(yōu)點：便于角色劃分，更靈活的授權(quán)管理；最小顆粒度授權(quán)；

RBAC的深度拓展

RBAC模型可以分為：RBAC0、RBAC1、RBAC2、RBAC3 四個階段，一般公司使用RBAC0的模型就可以。另外，RBAC0相當于底層邏輯，后三者都是在RBAC0模型上的拔高。

我先簡單介紹下這四個RBAC模型：

1. RBAC0模型

用戶和角色、角色和權(quán)限多對多關(guān)系。

簡單來說就是一個用戶擁有多個角色，一個角色可以被多個用戶擁有，這是用戶和角色的多對多關(guān)系；同樣的，角色和權(quán)限也是如此。

RBAC0模型如下圖：沒有畫太多線，但是已經(jīng)能夠看出多對多關(guān)系。

2. RBAC1模型

相對于RBAC0模型，增加了角色分級的邏輯，類似于樹形結(jié)構(gòu)，下一節(jié)點繼承上一節(jié)點的所有權(quán)限，如role1根節(jié)點下有role1.1和role1.2兩個子節(jié)點

角色分級的邏輯可以有效的規(guī)范角色創(chuàng)建（主要得益于權(quán)限繼承邏輯），我之前做過BD工具（類CRM），BD之間就有分級（經(jīng)理、主管、專員），如果采用RBAC0模型做權(quán)限系統(tǒng)，我可能需要為經(jīng)理、主管、專員分別創(chuàng)建一個角色（角色之間權(quán)限無繼承性），極有可能出現(xiàn)一個問題，由于權(quán)限配置錯誤，主管擁有經(jīng)理都沒有權(quán)限。

而RBAC1模型就很好解決了這個問題，創(chuàng)建完經(jīng)理角色并配置好權(quán)限后，主管角色的權(quán)限繼承經(jīng)理角色的權(quán)限，并且支持針對性刪減主管權(quán)限。

3. RBAC2模型

基于RBAC0模型，對角色增加了更多約束條件。

如角色互斥，比較經(jīng)典的案例是財務(wù)系統(tǒng)中出納不得兼管稽核，那么在賦予財務(wù)系統(tǒng)操作人員角色時，同一個操作員不能同時擁有出納和稽核兩個角色。

如角色數(shù)量限制，例如：一個角色專門為公司CEO創(chuàng)建的，最后發(fā)現(xiàn)公司有10個人擁有CEO角色，一個公司有10個CEO？這就是對角色數(shù)量的限制，它指的是有多少用戶能擁有這個角色。

RBAC2 模型主要是為了增加角色賦予的限制條件，這也符合權(quán)限系統(tǒng)的目標：權(quán)責明確，系統(tǒng)使用安全、保密。

4. RBAC3模型

同樣是基于RBAC0模型，但是綜合了RBAC1和RBAC2的所有特點

這里就不在多描述，讀者返回去看RBAC1和RBAC2模型的描述即可。

RBAC 權(quán)限管理的在實際系統(tǒng)中的應(yīng)用

RBAC 權(quán)限模型由三大部分構(gòu)成，即用戶管理、角色管理、權(quán)限管理。

用戶管理按照企業(yè)架構(gòu)或業(yè)務(wù)線架構(gòu)來劃分，這些結(jié)構(gòu)本身比較清晰，擴展性和可讀性都非常好。

角色管理一定要在深入理解業(yè)務(wù)邏輯后再來設(shè)計，一般使用各部門真實的角色作為基礎(chǔ)，再根據(jù)業(yè)務(wù)邏輯進行擴展。

權(quán)限管理是前兩種管理的再加固，做太細容易太碎片，做太粗又不夠安全，這里我們需要根據(jù)經(jīng)驗和實際情況來設(shè)計。

1.用戶管理

用戶管理中的用戶，是企業(yè)里每一位員工，他們本身就有自己的組織架構(gòu)，我們可以直接使用企業(yè)部門架構(gòu)或者業(yè)務(wù)線架構(gòu)來作為線索，構(gòu)建用戶管理系統(tǒng)。

需要特殊注意：實際業(yè)務(wù)中的組織架構(gòu)可能與企業(yè)部門架構(gòu)、業(yè)務(wù)線架構(gòu)不同，需要考慮數(shù)據(jù)共享機制，一般的做法為授權(quán)某個人、某個角色組共享某個組織層級的某個對象組數(shù)據(jù)。

2.角色管理

在設(shè)計系統(tǒng)角色時，我們應(yīng)該深入理解公司架構(gòu)、業(yè)務(wù)架構(gòu)后，再根據(jù)需求設(shè)計角色及角色內(nèi)的等級。

一般角色相對于用戶來說是固定不變的，每個角色都有自己明確的權(quán)限和限制，這些權(quán)限在系統(tǒng)設(shè)計之處就確定了，之后也輕易不會再變動。

1. 自動獲得基礎(chǔ)角色

當員工入職到某部門時，該名員工的賬號應(yīng)該自動被加入該部門對應(yīng)的基礎(chǔ)角色中，并擁有對應(yīng)的基礎(chǔ)權(quán)限。這種操作是為了保證系統(tǒng)安全的前提下，減少了管理員大量手動操作。使新入職員工能快速使用系統(tǒng)，提高工作效率。

2. 臨時角色與失效時間

公司業(yè)務(wù)有時需要外援來支持，他們并不屬于公司員工，也只是在某個時段在公司做支持。此時我們需要設(shè)置臨時角色，來應(yīng)對這種可能跨多部門協(xié)作的臨時員工。

如果公司安全級別較高，此類賬號默認有固定失效時間，到達失效時間需再次審核才能重新開啟。避免臨時賬號因為流程不完善，遺忘在系統(tǒng)中，引起安全隱患。

3. 虛擬角色

部門角色中的等級，可以授權(quán)同等級的員工擁有相同的權(quán)限，但某些員工因工作原因，需要調(diào)用角色等級之外的權(quán)限，相同等級不同員工需要使用的權(quán)限還不相同。

這種超出角色等級又合理的權(quán)限授予，我們可以設(shè)置虛擬角色。這一虛擬角色可集成這一工作所需的所有權(quán)限，然后將它賦予具體的員工即可。這樣即不用調(diào)整組織架構(gòu)和對應(yīng)的角色，也可以滿足工作中特殊情況的權(quán)限需求。

4. 黑白名單

白名單：某些用戶自身不擁有某部門的頂級角色，但處于業(yè)務(wù)需求，需要給他角色外的高級權(quán)限，那么我們可以設(shè)計限制范圍的白名單，將需要的用戶添加進去即可。

在安全流程中，我們僅需要對白名單設(shè)計安全流程，即可審核在白名單中的特殊用戶，做到監(jiān)控擁有特殊權(quán)限的用戶，減少安全隱患。

黑名單：比較常見的黑名單場景是某些犯了錯誤的員工，雖然在職，但已經(jīng)不能給他們?nèi)魏喂緳?quán)限了。這種既不能取消角色關(guān)聯(lián)，也不能完全停用賬號的情況，可以設(shè)置黑名單，讓此類用戶可以登錄賬號，查看基本信息，但大多數(shù)關(guān)鍵權(quán)限已經(jīng)被黑名單限制。

3. 權(quán)限管理

權(quán)限管理一般從三個方面來做限制。頁面/菜單權(quán)限，操作權(quán)限，數(shù)據(jù)權(quán)限。

1. 頁面/菜單權(quán)限

對于沒有權(quán)限操作的用戶，直接隱藏對應(yīng)的頁面入口或菜單選項。這種方法簡單快捷直接，對于一些安全不太敏感的權(quán)限，使用這種方式非常高效。

2. 操作權(quán)限

操作權(quán)限通常是指對同一組數(shù)據(jù)，不同的用戶是否可以增刪改查。對某些用戶來說是只讀瀏覽數(shù)據(jù)，對某些用戶來說是可編輯的數(shù)據(jù)。

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

對于安全需求高的權(quán)限管理，僅從前端限制隱藏菜單，隱藏編輯按鈕是不夠的，還需要在數(shù)接口上做限制。如果用戶試圖通過非法手段編輯不屬于自己權(quán)限下的數(shù)據(jù)，服務(wù)器端會識別、記錄并限制訪問。

4. 數(shù)據(jù)權(quán)限如何管控

數(shù)據(jù)權(quán)限可以分為行權(quán)限和列權(quán)限。行權(quán)限控制：看多少條數(shù)據(jù)。列權(quán)限控制：看一條數(shù)據(jù)的多少個字段

簡單系統(tǒng)中可以通過組織架構(gòu)來管控行權(quán)限，按照角色來配置列權(quán)限，但是遇到復(fù)雜情況，組織架構(gòu)是承載不了復(fù)雜行權(quán)限管控，角色也更不能承載列的特殊化展示。

目前行業(yè)的做法是提供行列級數(shù)據(jù)權(quán)規(guī)則配置，把規(guī)則當成類似權(quán)限點配置賦予某個角色或者某個用戶。

用戶管理系統(tǒng)權(quán)限設(shè)計中的更多實踐細節(jié)

1.超級管理員

超級管理員是用來啟動系統(tǒng)，配置系統(tǒng)的賬號。這個賬號應(yīng)該在配置好系統(tǒng)，創(chuàng)建管理員之后被隱藏起來。超級管理員賬號擁有系統(tǒng)中全部權(quán)限，可穿梭查看各部門數(shù)據(jù)，如果使用不恰當，是系統(tǒng)管理的安全隱患。

2.互斥角色如何處理

當用戶已經(jīng)有用的角色和即將添加的角色互相互斥時，應(yīng)該在添加新角色時，提示管理員因角色互斥的原因，無法進行新角色添加。如需添加，要先撤銷掉前一個角色，再添加新角色。

3.用戶管理權(quán)限系統(tǒng)設(shè)計一定要簡單清晰

在設(shè)計權(quán)限系統(tǒng)之處，一定要理清思路，一切從簡，能不增加的多余角色和權(quán)限邏輯，就一定不要增加。因為隨著公司業(yè)務(wù)的擴大，權(quán)限和角色也會隨之增多，如果初期設(shè)計思路不嚴謹，那么權(quán)限系統(tǒng)會隨著業(yè)務(wù)的擴大而無限混亂下去，此時再來整理權(quán)限，已經(jīng)太晚了。所以初期設(shè)計就一定要條理清晰，簡單明了，能避免后續(xù)非常多不必要的麻煩。

4.無權(quán)提示頁

有時員工 A 會直接給員工 B 分享他當下正在操作的頁面，但有可能員工 B 無權(quán)查看。此時我們應(yīng)該在這里考慮添加「無權(quán)提示頁」，避免粗暴的 404 頁面讓員工 B 以為是系統(tǒng)出錯了。

原文鏈接：https://mp.weixin.qq.com/s/FnBgM4m593e8M_UkJ_RWSg