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

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

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

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

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

一、什么是RBAC模型？

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

做了8年产品经理后，我是这么看产品经理的

我个人是从非常初级的产品经理做起，再到负责一个大产品的项目管理，现在有幸跳出了日常基础的工作更多的去看产品的PMF，product strategy...

查看详情 >

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

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

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

二、RBAC模型的分類

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

1. RBAC0基本模型

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

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

從系統(tǒng)設(shè)計角度來說，角色管理設(shè)計也比較簡單，如下圖：

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

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

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

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

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

2. RBAC1角色分層模型

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

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

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

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

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

3. RBAC2角色限制模型

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

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

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

動態(tài)職責分離：

動態(tài)限制：一個用戶可以擁有兩個角色，但是運行時只能激活一個角色。

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

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

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

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

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

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

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

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

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

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

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

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

思考

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

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

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