本文將從什么是RBAC模型、RBAC模型的分類、什么是權限、用戶組的使用、實例分析這幾個方面來整理說明。

目前這份工作做的大部分系統都是ToB性質，幾乎每個都涉及到了權限管理。經過多個系統的設計，知識的豐富，慢慢的發現主流的權限管理系統都是RBAC模型（Role-Based Access Control 基于角色的訪問控制）的變形和運用，只是根據不同的業務和設計方案，呈現不同的顯示效果。于是在前人的基礎上，加上自己的理解，認真總結一下RBAC模型的相關知識。

在正式討論RBAC模型之前，我們先思考一個問題，為什么我們要做角色權限系統？

大家先給自己1分鐘時間思考（產品經理要學會隨時思考哦）。

…思考10s

…思考30s

…思考50s

好的，1分鐘到了，下面揭曉答案：

一個很明顯的答案就是系統存在不同權限的用戶，而根據業務要求的不同，每個用戶能使用的功能、查看的內容是不同的。舉個最簡單的例子：釘釘后臺，普通員工和行政能看到的菜單、使用的功能是不同的，行政可以查看所有員工的出勤記錄而普通員工則不行。

接下來，本文將從以下幾個方面進行整理說明：什么是RBAC模型、RBAC模型的分類、什么是權限、用戶組的使用、實例分析。

一、什么是RBAC模型

RBAC（Role-Based Access Control）即：基于角色的權限控制。通過角色關聯用戶，角色關聯權限的方式間接賦予用戶權限。

如下圖：

有人會問為什么不直接給用戶分配權限，還多此一舉的增加角色這一環節呢？

其實是可以直接給用戶分配權限，只是直接給用戶分配權限，少了一層關系，擴展性弱了許多，適合那些用戶數量、角色類型少的平臺。

對于通常的系統，比如：存在多個用戶擁有相同的權限，在分配的時候就要分別為這幾個用戶指定相同的權限，修改時也要為這幾個用戶的權限進行一一修改。有了角色后，我們只需要為該角色制定好權限后，將相同權限的用戶都指定為同一個角色即可，便于權限管理。

對于批量的用戶權限調整，只需調整用戶關聯的角色權限，無需對每一個用戶都進行權限調整，既大幅提升權限調整的效率，又降低了漏調權限的概率。

二、RBAC模型的分類

RBAC模型可以分為：RBAC0、RBAC1、RBAC2、RBAC3 四種。其中RBAC0是基礎，也是最簡單的，相當于底層邏輯，RBAC1、RBAC2、RBAC3都是以RBAC0為基礎的升級。

一般情況下，使用RBAC0模型就可以滿足常規的權限管理系統設計了。

2.1 RBAC0模型

最簡單的用戶、角色、權限模型。這里面又包含了2種：

1. 用戶和角色是多對一關系，即：一個用戶只充當一種角色，一種角色可以有多個用戶擔當。
2. 用戶和角色是多對多關系，即：一個用戶可同時充當多種角色，一種角色可以有多個用戶擔當。

那么，什么時候該使用多對一的權限體系，什么時候又該使用多對多的權限體系呢？

如果系統功能比較單一，使用人員較少，崗位權限相對清晰且確保不會出現兼崗的情況，此時可以考慮用多對一的權限體系。其余情況盡量使用多對多的權限體系，保證系統的可擴展性。如：張三既是行政，也負責財務工作，那張三就同時擁有行政和財務兩個角色的權限。

2.2 RBAC1模型

相對于RBAC0模型，增加了子角色，引入了繼承概念，即子角色可以繼承父角色的所有權限。

使用場景：如某個業務部門，有經理、主管、專員。主管的權限不能大于經理，專員的權限不能大于主管，如果采用RBAC0模型做權限系統，極可能出現分配權限失誤，最終出現主管擁有經理都沒有的權限的情況。

而RBAC1模型就很好解決了這個問題，創建完經理角色并配置好權限后，主管角色的權限繼承經理角色的權限，并且支持在經理權限上刪減主管權限。

2.3 RBAC2模型

基于RBAC0模型，增加了對角色的一些限制：角色互斥、基數約束、先決條件角色等。

• 角色互斥：同一用戶不能分配到一組互斥角色集合中的多個角色，互斥角色是指權限互相制約的兩個角色。案例：財務系統中一個用戶不能同時被指派給會計角色和審計員角色。
• 基數約束：一個角色被分配的用戶數量受限，它指的是有多少用戶能擁有這個角色。例如：一個角色專門為公司CEO創建的，那這個角色的數量是有限的。
• 先決條件角色：指要想獲得較高的權限，要首先擁有低一級的權限。例如：先有副總經理權限，才能有總經理權限。
• 運行時互斥：例如，允許一個用戶具有兩個角色的成員資格，但在運行中不可同時激活這兩個角色。

2.4 RBAC3模型

稱為統一模型，它包含了RBAC1和RBAC2，利用傳遞性，也把RBAC0包括在內，綜合了RBAC0、RBAC1和RBAC2的所有特點，這里就不在多描述了。

三、什么是權限

說了這么久用戶-角色-權限，可能小伙伴們都了解了什么是用戶、什么是角色。但是有的小伙伴會好奇，那權限又是個什么玩意呢？

權限是資源的集合，這里的資源指的是軟件中所有的內容，包括模塊、菜單、頁面、字段、操作功能（增刪改查）等等。具體的權限配置上，目前形式多種多樣，按照我個人的理解，可以將權限分為：頁面權限、操作權限和數據權限（這種分類法，主要是結合自己在工作中的實際情況理解總結而來，若有不足之處，也請大家指出）。

頁面權限：所有系統都是由一個個的頁面組成，頁面再組成模塊，用戶是否能看到這個頁面的菜單、是否能進入這個頁面就稱為頁面權限。

如下圖：

客戶列表、客戶黑名單、客戶審批頁面組成了客戶管理這個模塊。對于普通用戶，不能進行審批操作，即無客戶審批頁面權限，在他的賬號登錄后側邊導航欄只顯示客戶列表、客戶黑名單兩個菜單。

操作權限：用戶凡是在操作系統中的任何動作、交互都是操作權限，如增刪改查等。

數據權限：一般業務管理系統，都有數據私密性的要求：哪些人可以看到哪些數據，不可以看到哪些數據。

簡單舉個例子：某系統中有銷售部門，銷售專員負責推銷商品，銷售主管負責管理銷售專員日常工作，經理負責組織管理銷售主管作業。

如下圖：

按照實際理解，‘銷售專員張三’登錄時，只能看到自己負責的數據；銷售主管2登錄時，能看到他所領導的所有業務員負責的數據，但看不到其他團隊業務員負責的數據。

換另外一句話就是：我的客戶只有我和我的直屬上級以及直屬上級的領導能看到，這就是我理解的數據權限。

要實現數據權限有多種方式：

1. 可以利用RBAC1模型，通過角色分級來實現。
2. 在‘用戶-角色-權限’的基礎上，增加用戶與組織的關聯關系，用組織決定用戶的數據權限。

具體如何做呢？

①組織層級劃分：

②數據可視權限規則制定：上級組織只能看到下級組織員工負責的數據，而不能看到其他平級組織及其下級組織的員工數據等。

通過以上兩點，系統就可以在用戶登錄時，自動判斷要給用戶展示哪些數據了。

四、用戶組的使用

當平臺用戶基數增大，角色類型增多時，如果直接給用戶配角色，管理員的工作量就會很大。這時候我們可以引入一個概念“用戶組”，就是將相同屬性的用戶歸類到一起。

例如：加入用戶組的概念后，可以將部門看做一個用戶組，再給這個部門直接賦予角色（1萬員工部門可能就幾十個），使部門擁有部門權限，這樣這個部門的所有用戶都有了部門權限，而不需要為每一個用戶再單獨指定角色，極大的減少了分配權限的工作量。

同時，也可以為特定的用戶指定角色，這樣用戶除了擁有所屬用戶組的所有權限外，還擁有自身特定的權限。

用戶組的優點，除了減少工作量，還有更便于理解、增加多級管理關系等。如：我們在進行組織機構配置的時候，除了加入部門，還可以加入科室、崗位等層級，來為用戶組內部成員的權限進行等級上的區分。

關于用戶組的詳細疑難解答，請查看https://wen.woshipm.com/question/detail/88fues.html。在這里也十分感謝為我解答疑惑的朋友們！

五、實例分析

5.1 如何設計RBAC權限系統

首先，我們思考一下一個簡單的權限系統應該具備哪些內容？

答案顯而易見，RBAC模型：用戶-角色-權限。所以最基本的我們應該具備用戶、角色、權限這三個內容。

接下來，我們思考，究竟如何將三者關聯起來?；仡櫱拔?，角色作為樞紐，關聯用戶、權限。所以在RBAC模型下，我們應該：創建一個角色，并為這個角色賦予相應權限，最后將角色賦予用戶。

將這個問題抽象為流程，如下圖：

現在，基本的流程邏輯已經抽象出來了，接下來，分析該如何設計呢？

• 第一步，需要角色管理列表，在角色管理列表能快速創建一個角色，且創建角色的同時能為角色配置權限，并且支持創建成功的角色列表能隨時進行權限配置的的修改；
• 第二步，需要用戶管理列表，在用戶管理列表能快速添加一個用戶，且添加用戶時有讓用戶關聯角色的功能。

簡單來說權限系統設計就包含以上兩步，接下來為大家進行實例分析。

5.2 實例分析

①創建角色列表

在角色列表快速創建一個角色：點擊創建角色，支持創建角色時配置權限。

②創建用戶列表

在用戶列表快速創建一個用戶：支持用戶關聯角色的功能。

上述案例是基于最簡單的RBAC0模型創建，適用于大部分常規的權限管理系統。

下面再分析一下RBAC1中角色分級具體如何設計。

1. 在RBAC0的基礎上，加上角色等級這個字段。
2. 權限分配規則制定：低等級角色只能在高等級角色權限基礎上進行刪減權限。

具體界面呈現如下圖：

以上就是簡單的RBAC系統設計，若需更復雜的，還請讀者根據上面的分析自行揣摩思考，盡管樣式不同，但萬變不離其宗，理解清楚RBAC模型后，結合自己的業務就可以設計出一套符合自己平臺需求的角色權限系統，具體的就不再多闡述了。

六、小結

文章的內容主要是自己工作中實際的使用場景，抱著他山之石可以攻玉的想法，參考了現有的方法論，結合自己系統的實際情況，對RBAC模型做了細致的總結理解。若有不足之處，還請大家多多溝通，共同進步。

本文由 @?珣玗琪 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議