提到權(quán)限管理，自然離不開(kāi)RBAC模型。怎么理解RBAC模型呢？這篇文章里，作者結(jié)合自己的思考，探討了RBAC模型的分類，及RBAC模型之外的數(shù)據(jù)權(quán)限。一起來(lái)看看本文的闡述。

最近在設(shè)計(jì)一套面向票據(jù)中介的金融SaaS系統(tǒng)，又是一個(gè)從0到1的項(xiàng)目。雖然只是完成了第一期的設(shè)計(jì)，但是在系統(tǒng)設(shè)計(jì)的過(guò)程中有很多思考，權(quán)限管理就是其中重大的一環(huán)。權(quán)限管理作為系統(tǒng)的根基，就如房子的地基一樣，是重中之重。如果地基不穩(wěn)固，那么房子就可能要拆掉重建，而系統(tǒng)就有可能需要重構(gòu)或者二次開(kāi)發(fā)，非常浪費(fèi)時(shí)間和精力。在系統(tǒng)設(shè)計(jì)之初，最好就按照未來(lái)公司‘做大做強(qiáng)’的規(guī)劃進(jìn)行設(shè)計(jì)，以保證這塊功能的長(zhǎng)期可用性。

權(quán)限管理，一言蔽之就是‘讓不同的系統(tǒng)用戶有不同的權(quán)限去看和操作’。在C端產(chǎn)品中，就如boss直聘，普通會(huì)員和付費(fèi)會(huì)員在app中就會(huì)有不同的權(quán)限，就如之前寫的文章《 BOSS直聘買VIP有用嗎？》一樣，平臺(tái)會(huì)對(duì)普通會(huì)員和付費(fèi)會(huì)員設(shè)置不同權(quán)限，以滿足運(yùn)營(yíng)需求（只是有些甚是雞肋，攤手）；

而在面向企業(yè)經(jīng)營(yíng)的B端產(chǎn)品中，對(duì)于公司員工而言，就是讓不同的部門和員工有不同的權(quán)限，就如運(yùn)營(yíng)部門和銷售部門的權(quán)限是會(huì)不同的，而一線銷售人員和銷售總監(jiān)的權(quán)限又是不同的。

說(shuō)到權(quán)限管理，自然離不開(kāi)RBAC模型。那么，什么是RBAC模型呢？

一、什么是RBAC模型？

RBAC模型（Role-Based Access Control）就是基于角色的訪問(wèn)控制。它基于“角色”這一核心理念，將用戶權(quán)限的管理和分配與用戶的具體身份解耦合，從而簡(jiǎn)化權(quán)限管理，以便維護(hù)和擴(kuò)展。

簡(jiǎn)單來(lái)說(shuō)，就是我將系統(tǒng)權(quán)限賦予‘角色’，用戶再繼承角色來(lái)獲取權(quán)限。用類圖來(lái)表示他們之間的關(guān)系的話，如下圖：

• 一個(gè)用戶可以有0到多個(gè)角色。
• 一個(gè)角色可以分配給0到多個(gè)用戶。
• 一個(gè)角色可以有0到多個(gè)權(quán)限。
• 一個(gè)權(quán)限可以分配給0到多個(gè)用戶。

當(dāng)今的大部分B端系統(tǒng)的權(quán)限管理都會(huì)涉及到RBAC模型，只是功能的繁簡(jiǎn)程度不同而已。

二、RBAC模型的分類

RBAC模型分為RBAC0、RBAC1、RBAC2和RBAC3這四種，其中RBAC0為這四種分類中的基礎(chǔ)，其他三類均是RBAC0基礎(chǔ)上的變形。

1. RBAC0基本模型

我們先來(lái)聊聊RBAC模型中的基礎(chǔ)，RBAC0模型。

RBAC0是基于角色的訪問(wèn)控制的完美體現(xiàn)，也就是把權(quán)限賦予角色，然后再把角色賦予用戶，很多B端系統(tǒng)都是基于RBAC0搭建的權(quán)限管理。

從系統(tǒng)設(shè)計(jì)角度來(lái)說(shuō)，角色管理設(shè)計(jì)也比較簡(jiǎn)單，如下圖：

只需給對(duì)應(yīng)的角色配置系統(tǒng)中的權(quán)限（菜單/操作/字段），完成角色創(chuàng)建后，再將角色賦予系統(tǒng)用戶即可。這樣在用戶登錄后，就能獲取該用戶的所屬角色，然后通過(guò)角色來(lái)找到擁有的權(quán)限，再加載對(duì)應(yīng)的權(quán)限資源。

完成RBAC0基本模型的搭建，基本就能滿足當(dāng)下絕大部分系統(tǒng)的權(quán)限管理的需求。

但是，如果一個(gè)部門人員很多，就如我前司，一級(jí)部門向下還有二級(jí)部門，二級(jí)部門向下才是員工，這樣就導(dǎo)致如果采用RBAC0模型進(jìn)行權(quán)限管理的話，則很有可能錯(cuò)配權(quán)限的問(wèn)題。

那么，有什么方案解決呢？

有！那就是RBAC1角色分層模型。

2. RBAC1角色分層模型

RBAC1模型相較于RBAC0模型增加了角色繼承的概念，有了角色繼承就有父子的關(guān)系，即子角色可擁有父角色的權(quán)限。

從系統(tǒng)設(shè)計(jì)角度來(lái)看，如下圖：

在配置角色的時(shí)候可以增加父角色的選擇，可在父角色的基礎(chǔ)上進(jìn)行刪減權(quán)限，以避免錯(cuò)配權(quán)限的問(wèn)題。

在RBAC1模型中，我認(rèn)為主要解決的就是同部門不同層級(jí)人員權(quán)限配置問(wèn)題，以達(dá)到精準(zhǔn)和快速配置權(quán)限。

就比如金融本部有一級(jí)部門負(fù)責(zé)人、二級(jí)部門負(fù)責(zé)人、小組長(zhǎng)和專員，這樣就可以在完成一級(jí)部門負(fù)責(zé)人的權(quán)限配置之后，再在一級(jí)部門負(fù)責(zé)人的基礎(chǔ)上配置其他角色的權(quán)限，以實(shí)現(xiàn)其他角色的權(quán)限均在一級(jí)部門負(fù)責(zé)人的權(quán)限之內(nèi)。

3. RBAC2角色限制模型

RBAC2模型是RBAC0的另一變種，對(duì)用戶、角色和權(quán)限三者之間增加了一些限制。這些限制可以分成兩類，即靜態(tài)職責(zé)分離SSD(Static Separation of Duty)和動(dòng)態(tài)職責(zé)分離DSD(Dynamic Separation of Duty)。

靜態(tài)職責(zé)分離：

• 互斥角色限制：一個(gè)用戶不能同時(shí)分配互斥角色中的多個(gè)角色，即只能選擇一個(gè)。
• 基數(shù)限制：一個(gè)用戶擁有的角色是有限的。
• 先決條件限制：一個(gè)用戶想獲得更高級(jí)的角色，首先需先擁有低級(jí)角色。

動(dòng)態(tài)職責(zé)分離：

動(dòng)態(tài)限制：一個(gè)用戶可以擁有兩個(gè)角色，但是運(yùn)行時(shí)只能激活一個(gè)角色。

其實(shí)RBAC2模型在我歷史經(jīng)歷的系統(tǒng)中基本沒(méi)有應(yīng)用到了，靜態(tài)和動(dòng)態(tài)職責(zé)分離的限制條件，我感覺(jué)只滿足了5%或者更少的應(yīng)用場(chǎng)景。如果讀者有設(shè)計(jì)過(guò)包含此模型的系統(tǒng)，也可和我溝通交流，我倒是想知道誰(shuí)家這么變態(tài)。

4. RBAC3統(tǒng)一模型

RBAC3=RBAC1+RBAC2，既包含了角色分層，也包含了角色限制，不贅述。

三、RBAC模型之外的數(shù)據(jù)權(quán)限

就如文中所說(shuō)，其實(shí)RBAC0基礎(chǔ)模型已經(jīng)滿足了絕大部分的應(yīng)用場(chǎng)景，是應(yīng)該掌握的，其他三個(gè)模型了解即可。在RBAC模型之外，我想再聊聊數(shù)據(jù)權(quán)限。

角色管理系統(tǒng)中的資源，資源包括菜單（頁(yè)面）權(quán)限、操作（按鈕）權(quán)限和字段權(quán)限。那么，數(shù)據(jù)權(quán)限要通過(guò)什么進(jìn)行管理？

沒(méi)錯(cuò)，就是組織架構(gòu)。通過(guò)角色管理用戶在系統(tǒng)中能使用的資源，然后通過(guò)組織架構(gòu)管理用戶能看到的數(shù)據(jù)范圍，這樣就完整的搭建了SaaS系統(tǒng)的權(quán)限管理。

為什么通過(guò)組織架構(gòu)能管理數(shù)據(jù)權(quán)限？

一般大型企業(yè)都是全國(guó)性質(zhì)的，就如我的前司，作為中國(guó)頭部的物流公司，產(chǎn)生的物流單是全國(guó)范圍的，那么不同區(qū)域/不同層級(jí)對(duì)于數(shù)據(jù)的管理需求也就順其自然產(chǎn)生了。

那么通過(guò)‘訂單+門店’和組織架構(gòu)就能管理數(shù)據(jù)權(quán)限，訂單產(chǎn)生于不同的門店，不同的門店又隸屬于不同的組織架構(gòu)之下，不同的用戶再在系統(tǒng)中配置對(duì)應(yīng)的部門，即可實(shí)現(xiàn)數(shù)據(jù)權(quán)限。

這里為了數(shù)據(jù)權(quán)限控制的靈活度，在角色管理中還可以設(shè)置角色的數(shù)據(jù)權(quán)限范圍，如下圖：

數(shù)據(jù)權(quán)限可以限制為‘本人/本部門/下級(jí)部門/本部門和下級(jí)部門/自定義部門/全部’等屬性，以控制用戶對(duì)于不同范圍的數(shù)據(jù)查看權(quán)限。

思考

以上就是SaaS系統(tǒng)的管理的全部?jī)?nèi)容，我認(rèn)為‘RBAC0模型+數(shù)據(jù)權(quán)限’就可滿足系統(tǒng)可見(jiàn)發(fā)展范圍內(nèi)的權(quán)限管理需求了。

當(dāng)公司發(fā)展到一定程度，內(nèi)部孵化的項(xiàng)目系統(tǒng)也會(huì)越來(lái)越多，那么將權(quán)限管理抽離，抽象成單獨(dú)的「統(tǒng)一授權(quán)平臺(tái)」也勢(shì)在必行。

用統(tǒng)一的權(quán)限管理平臺(tái)進(jìn)行管理不同系統(tǒng)的權(quán)限，這部分的輪子抽象后是可以復(fù)用的。讀者們也可以思考下要實(shí)現(xiàn)這部分的功能，要將系統(tǒng)的哪些模塊進(jìn)行抽離才可實(shí)現(xiàn)。