起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識RBAC模型：基于用戶-角色-權限控制的一些思考
本文將從什么是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種：
- 用戶和角色是多對一關系，即：一個用戶只充當一種角色，一種角色可以有多個用戶擔當。
- 用戶和角色是多對多關系，即：一個用戶可同時充當多種角色，一種角色可以有多個用戶擔當。
那么，什么時候該使用多對一的權限體系，什么時候又該使用多對多的權限體系呢？
如果系統功能比較單一，使用人員較少，崗位權限相對清晰且確保不會出現兼崗的情況，此時可以考慮用多對一的權限體系。其余情況盡量使用多對多的權限體系，保證系統的可擴展性。如：張三既是行政，也負責財務工作，那張三就同時擁有行政和財務兩個角色的權限。
2.2 RBAC1模型
相對于RBAC0模型，增加了子角色，引入了繼承概念，即子角色可以繼承父角色的所有權限。
使用場景：如某個業務部門，有經理、主管、專員。主管的權限不能大于經理，專員的權限不能大于主管，如果采用RBAC0模型做權限系統，極可能出現分配權限失誤，最終出現主管擁有經理都沒有的權限的情況。
而RBAC1模型就很好解決了這個問題，創建完經理角色并配置好權限后，主管角色的權限繼承經理角色的權限，并且支持在經理權限上刪減主管權限。
2.3 RBAC2模型
基于RBAC0模型，增加了對角色的一些限制：角色互斥、基數約束、先決條件角色等。
- 角色互斥：同一用戶不能分配到一組互斥角色集合中的多個角色，互斥角色是指權限互相制約的兩個角色。案例：財務系統中一個用戶不能同時被指派給會計角色和審計員角色。
- 基數約束：一個角色被分配的用戶數量受限，它指的是有多少用戶能擁有這個角色。例如：一個角色專門為公司CEO創建的，那這個角色的數量是有限的。
- 先決條件角色：指要想獲得較高的權限，要首先擁有低一級的權限。例如：先有副總經理權限，才能有總經理權限。
- 運行時互斥：例如，允許一個用戶具有兩個角色的成員資格，但在運行中不可同時激活這兩個角色。
2.4 RBAC3模型
稱為統一模型，它包含了RBAC1和RBAC2，利用傳遞性，也把RBAC0包括在內，綜合了RBAC0、RBAC1和RBAC2的所有特點，這里就不在多描述了。
三、什么是權限
說了這么久用戶-角色-權限，可能小伙伴們都了解了什么是用戶、什么是角色。但是有的小伙伴會好奇，那權限又是個什么玩意呢？
權限是資源的集合，這里的資源指的是軟件中所有的內容，包括模塊、菜單、頁面、字段、操作功能（增刪改查）等等。具體的權限配置上，目前形式多種多樣，按照我個人的理解，可以將權限分為：頁面權限、操作權限和數據權限（這種分類法，主要是結合自己在工作中的實際情況理解總結而來，若有不足之處，也請大家指出）。
頁面權限：所有系統都是由一個個的頁面組成，頁面再組成模塊，用戶是否能看到這個頁面的菜單、是否能進入這個頁面就稱為頁面權限。
如下圖：
客戶列表、客戶黑名單、客戶審批頁面組成了客戶管理這個模塊。對于普通用戶，不能進行審批操作，即無客戶審批頁面權限，在他的賬號登錄后側邊導航欄只顯示客戶列表、客戶黑名單兩個菜單。
操作權限：用戶凡是在操作系統中的任何動作、交互都是操作權限，如增刪改查等。
數據權限：一般業務管理系統，都有數據私密性的要求：哪些人可以看到哪些數據，不可以看到哪些數據。
簡單舉個例子：某系統中有銷售部門，銷售專員負責推銷商品，銷售主管負責管理銷售專員日常工作，經理負責組織管理銷售主管作業。
如下圖：
按照實際理解，‘銷售專員張三’登錄時，只能看到自己負責的數據；銷售主管2登錄時，能看到他所領導的所有業務員負責的數據，但看不到其他團隊業務員負責的數據。
換另外一句話就是：我的客戶只有我和我的直屬上級以及直屬上級的領導能看到，這就是我理解的數據權限。
要實現數據權限有多種方式：
- 可以利用RBAC1模型，通過角色分級來實現。
- 在‘用戶-角色-權限’的基礎上，增加用戶與組織的關聯關系，用組織決定用戶的數據權限。
具體如何做呢？
①組織層級劃分：
②數據可視權限規則制定：上級組織只能看到下級組織員工負責的數據，而不能看到其他平級組織及其下級組織的員工數據等。
通過以上兩點，系統就可以在用戶登錄時，自動判斷要給用戶展示哪些數據了。
四、用戶組的使用
當平臺用戶基數增大，角色類型增多時，如果直接給用戶配角色，管理員的工作量就會很大。這時候我們可以引入一個概念“用戶組”，就是將相同屬性的用戶歸類到一起。
例如：加入用戶組的概念后，可以將部門看做一個用戶組，再給這個部門直接賦予角色（1萬員工部門可能就幾十個），使部門擁有部門權限，這樣這個部門的所有用戶都有了部門權限，而不需要為每一個用戶再單獨指定角色，極大的減少了分配權限的工作量。
同時，也可以為特定的用戶指定角色，這樣用戶除了擁有所屬用戶組的所有權限外，還擁有自身特定的權限。
用戶組的優點，除了減少工作量，還有更便于理解、增加多級管理關系等。如：我們在進行組織機構配置的時候，除了加入部門，還可以加入科室、崗位等層級，來為用戶組內部成員的權限進行等級上的區分。
關于用戶組的詳細疑難解答，請查看https://wen.woshipm.com/question/detail/88fues.html。在這里也十分感謝為我解答疑惑的朋友們！
五、實例分析
5.1 如何設計RBAC權限系統
首先，我們思考一下一個簡單的權限系統應該具備哪些內容？
答案顯而易見，RBAC模型：用戶-角色-權限。所以最基本的我們應該具備用戶、角色、權限這三個內容。
接下來，我們思考，究竟如何將三者關聯起來?；仡櫱拔?，角色作為樞紐，關聯用戶、權限。所以在RBAC模型下，我們應該：創建一個角色，并為這個角色賦予相應權限，最后將角色賦予用戶。
將這個問題抽象為流程，如下圖：
現在，基本的流程邏輯已經抽象出來了，接下來，分析該如何設計呢？
- 第一步，需要角色管理列表，在角色管理列表能快速創建一個角色，且創建角色的同時能為角色配置權限，并且支持創建成功的角色列表能隨時進行權限配置的的修改；
- 第二步，需要用戶管理列表，在用戶管理列表能快速添加一個用戶，且添加用戶時有讓用戶關聯角色的功能。
簡單來說權限系統設計就包含以上兩步，接下來為大家進行實例分析。
5.2 實例分析
①創建角色列表
在角色列表快速創建一個角色：點擊創建角色，支持創建角色時配置權限。
②創建用戶列表
在用戶列表快速創建一個用戶：支持用戶關聯角色的功能。
上述案例是基于最簡單的RBAC0模型創建，適用于大部分常規的權限管理系統。
下面再分析一下RBAC1中角色分級具體如何設計。
- 在RBAC0的基礎上，加上角色等級這個字段。
- 權限分配規則制定：低等級角色只能在高等級角色權限基礎上進行刪減權限。
具體界面呈現如下圖：
以上就是簡單的RBAC系統設計，若需更復雜的，還請讀者根據上面的分析自行揣摩思考，盡管樣式不同，但萬變不離其宗，理解清楚RBAC模型后，結合自己的業務就可以設計出一套符合自己平臺需求的角色權限系統，具體的就不再多闡述了。
六、小結
文章的內容主要是自己工作中實際的使用場景，抱著他山之石可以攻玉的想法，參考了現有的方法論，結合自己系統的實際情況，對RBAC模型做了細致的總結理解。若有不足之處，還請大家多多溝通，共同進步。
本文由 @?珣玗琪 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
要實現數據權限有多種方式：
可以利用RBAC1模型，通過角色分級來實現。
在‘用戶-角色-權限’的基礎上，增加用戶與組織的關聯關系，用組織決定用戶的數據權限。
如何抉擇哪一種更適合
你最后那張圖，分配權限：分為頁面權限&操作權限。感覺不是太靈活，比如針對某一X角色我想分配給他A頁面的查看權限，B頁面的編輯權限，這時你這個模型就不能滿足，但是如果把2個細分拆分去組合形成某一具體權限（如A頁面編輯權限），則又感覺會使產品操作體驗下降，所以想交流下，有沒有什么折中或者替代更優方案？
可以把頁面權限和功能權限放一起，頁面下包含功能。
能不能用這個頁面，能不能用這個頁面下的功能
有點疑惑，什么樣的場景需要多大的靈活度呢？比如：針對某一X角色我想分配給他A頁面的查看權限，B頁面的編輯權限，這種情況 我就會一邊擔心過度開發，一邊擔心不夠靈活。
針對頁面做操作權限配置，配置起來確實挺麻煩的?；蛘哒沓鲎罨A的權限，比如就是查看，角色擁有查看權限，對用戶賦予角色后，再給用戶單獨針對某個頁面掛一個編輯權限？
實例里 基于 RBAC1 設計的原型邏輯上是不是有漏洞呢？
等級 2 只允許在等級 1 的基礎上刪減，但如果存在相同的多個等級為 1 的角色，在創建新角色的時候，選擇等級 2，那該角色要繼承哪個等級為 1 的權限列表呢？
另外，數據權限的設計沒有在實例里體現，所以對這個模塊還是有疑問，希望作者有空可以繼續完善啦~ 辛苦??！
等級是與角色關聯起來的，即一個角色對應一個等級。
在創建新角色時，可以選擇他的上級角色是哪個
按照RBAC1 模型的原理，有個父角色和子角色的話，是不是不需要設定用戶組也可以完成權限控制，滿足需求
用戶組不還是要把用戶手動分組，一萬個用戶都要分組，這個工作量也不小 吧
我的理解是，比如用戶組是部門，那么這一萬人的分組，是在入職時已經分好的。
當配置權限的時候，不需要再次將一萬人進行分組，而且依據組織結構中的部門，對部門進行權限配置，部門下的員工就能獲得該部門的權限，這樣，工作量由一萬減少到幾十個。
1. 可以利用RBAC1模型，通過角色分級來實現。
2. 在‘用戶-角色-權限’的基礎上，增加用戶與組織的關聯關系，用組織決定用戶的數據權限。
這兩種 選擇上傾向哪種呢？
1、RBAC1是理論的支撐，增加用戶、組織的關系是結合了實際使用場景，便于使用者理解，提高用戶體驗的設計方式。
2、具體如何選擇，還是需要根據實際需求情況考慮，比如：
某組織下，各個部門權限不同，對部門A分配權限1~5，部門下存在各個崗位，所有崗位的權限均來源于部門A擁有的權限，即1~5，不同崗位又有不同權限，可能有的崗位有權限1和3，有的崗位有權限2、3、4，部門領導可以有1~5全部的權限
這樣既有角色分級的理論存在，又結合了部門-崗位-人員（組織關系）的實際組織架構設計
如果有個同事身兼數職、他在運營部門、兼顧資產工作、他只有運營部門權限、那資產權限怎給他分配呢、創業小公司很多這種身兼數職 部門組織架構不嚴謹情況
總結的很好，以前做的一直是基于URL的權限控制，這種基于資源的增/刪/改/查操作，如何確定到URL？
url 可以和 資源 手動關聯，以便管理
謝謝作者，我是初級產品經理，真是解決我的燃眉之急。
思考大于行動
還需要考慮異常，想請教下如果角色A被刪除，那么關聯的用戶怎么處理？
如果要刪除角色，先決條件是要保證旗下用戶為空
一個部門下，多個相同等級的角色，哪個被繼承？
這個應該后續還要選擇被繼承的角色吧？不然建立不了關聯關系。
學習了，謝謝~
百變不離其中
想加你微信，請教你
可以的，yx634326454
總結到位厲害，另外問下ROAC3使用場景有哪些呢，想不到啊??
RBAC3是綜合了前面幾種情況，比如：系統中運用了RBAC1模型來對市場部角色的用戶做數據權限區分，也運用了RBAC2來對某些角色進行了基數設置。不知道這樣解釋你是否能懂。
ps：是RBAC模型 不是ROAC哈
贊