起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識基于RBAC模型的權限設計：如何設計系統權限體系？
RBAC目前使用最為廣泛的權限模型，筆者通過平常工作及工作外的積累，整理了幾種比較經典的權限體系，希望對大家有所幫助！
一、什么是RABC
RBAC（基于角色的權限控制）模型的核心是在用戶和權限之間引入了角色的概念。取消了用戶和權限的直接關聯，改為通過用戶關聯角色、角色關聯權限的方法來間接地賦予用戶權限（如下圖），從而達到用戶和權限解耦的目的。
RABC的好處
- 職能劃分更謹慎。對于角色的權限調整不僅僅只影響單個用戶，而是會影響關聯此角色的所有用戶，管理員下發/回收權限會更為謹慎；
- 便于權限管理。對于批量的用戶權限調整，只需調整用戶關聯的角色權限即可，無需對每一個用戶都進行權限調整，既大幅提升權限調整的效率，又降低漏調權限的概率；
在不斷的發展過程中，RBAC也因不同的需求而演化出了不同的版本，目前主要有以下幾個版本：
- RBAC0，這是RBAC的初始形態，也是最原始、最簡單的RBAC版本；
- RBAC1，基于RBAC0的優化，增加了角色的分層（即：子角色），子角色可以繼承父角色的所有權限；
- RBAC2，基于RBAC0的另一種優化，增加了對角色的一些限制：角色互斥、角色容量等；
- RBAC3，最復雜也是最全面的RBAC模型，它在RBAC0的基礎上，將RBAC1和RBAC2中的優化部分進行了整合；
二、基于RBAC的幾種權限體系設計
1、用戶-角色-權限
這種權限體系其實就是RBAC0的模式了。這里面又包含了2種：
- 用戶和角色是多對一關系，即：一個用戶只充當一種角色，一種角色可以有多個用戶擔當；
- 用戶和角色是多對多關系，即：一個用戶可同時充當好幾種角色，一種角色可以有多個用戶擔當；
如上圖：對于左邊的用戶-角色對應，每個人只能同時擁有一種角色，但是同一個角色里邊，可能會含有多個用戶（如：李四和王麻子都是業務員）；而右邊的用戶-角色對應，是在左邊的基礎上，增加了一個用戶可擁有多種角色的情況（如：小馬哥既是經理，也要負責財務的工作）；
那么，什么時候該使用多對一的權限體系，什么時候又該使用多對多的權限體系呢？
我的建議是：盡量可能地使用多對多的權限體系。如果這個系統的功能比較單一、使用人員較少、崗位權限相對清晰且不會出現兼崗的情況，這種情況也可以考慮用多對一的權限體系。
2、用戶-組織-角色-權限
一般公司的業務管理系統，都有數據私密性的要求：哪些人可以看到哪些數據，哪些人不可以看到哪些數據。這個時候，我們就需要把這些東西也考慮到你的權限體系內了。
假設上圖是一家公司業務部門的組織架構圖，公司要求你基于這個組織架構設計一個業務管理系統，并要求系統需要滿足不同用戶的數據私密性，比如：“張三”登錄時，只能看到“張三”負責的數據；“張三”的領導登錄時，能看到“團隊A”的所有業務員負責的數據，但看不到其他團隊業務員負責的數據等等。
在這種情況下，上一種權限體系就不適用了，但我們可以對其進行一些小改造后，即可達到數據管控的目的，如下圖：
在“用戶-角色-權限”的基礎上，我們增加了用戶與組織的關聯關系，組織決定了用戶的數據可視權限。但要想真正達到這個效果，我們還需要做2件事：
- 組織層級劃分。如下圖，我們需要對組織進行梳理，并劃分層級；
- 數據可視權限規則制定。比如：上級組織職能看到下級組織員工負責的數據，而不能看到其他平級組織及其下級組織的員工數據等。
通過以上兩點，系統就可以在用戶登錄時，自動判斷要給用戶展示哪些數據了！
3、用戶-組織-崗位-角色-權限
第三種權限體系又是在第二種權限體系上進行優化的，增加了用戶與崗位的關聯關系，示意圖如下：
增加崗位有以下幾點好處：
- 識別用戶的主要身份。一個人可能身兼多職（多個角色），但是他的主要職能是固定的，那怎么告訴系統用戶的主要職能是什么呢？答案就是：通過崗位！拿上面的小馬哥舉例：小馬哥雖然身兼經理和財務兩種身份，但他的本職工作是“經理”，因此，他的系統崗位應該“經理”。當他登錄時，系統會識別他的身份為“經理”，只不過這個“經理”剛好兼具了其他崗位的職能而已；
- 通過“組織-崗位”關聯，快速甄別用戶崗位。公司在不斷地發展的過程中，系統的用戶角色也會不斷增加，當角色達到一定數量以后，管理員每新增一個用戶都要花相當的時間去尋找角色。引入崗位后，可將組織和崗位、崗位和角色提前進行關聯，配置賬號時，管理員只要選定組織，系統就給出與該組織關聯的崗位，而這些崗位，又是提前關聯好角色的，選擇起來，既方便又高效！
三、總結
以上是基于RBAC模型的三種權限體系，不難看出，三種權限體系的本質都是用戶和權限進行解耦，以達到權限的靈活運用。
在最后，也給大家留下兩個小問題，大家有興趣的話可以思考下并在評論區寫出你的答案哦：
- 在不增加“組織”的情況下（即：第一種權限體系），能否達到數據私密性的控制？如何達到？
- 在第二種權限體系中，如何做到將“團隊A”的員工和管理者設置在同一個組織下，但又能保證員工只能看到自己的數據，而管理者可以看到該團隊所有員工的數據？
本文由 @沒有昵稱 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自unsplash，基于CC0協議
我個人認為兩個問題是否可以如下解決：
1. 采用角色繼承的方式，如 經理-》業務員，財務，老板-》 經理，這樣建立層級關系，達到數據范圍的控制。
2. 在建立組織架構樹時，增加一個【是否管理人員】的標識。在權限驗證部分，讀取到管理人員標識時，則開放部門權限，否則，只開放個人權限。
以上僅是針對上述兩個問題的粗略思考。
實際過程中，行數據權限 我認為至少應包括4種模型，（1）所有數據權限 （2）縱向組織架構權限 （3）橫向分管范圍權限 （4）個人權限
在提一個小建議，上述文章中，重點描述了 用戶，組織，崗位，角色內容，是否忽略了 權限 -》 資源部分內容；即如何定義權限，定義資源；資源包括哪些，如何抽象，如何落地等。
試著回答兩個問題，當作是個人的讀后小結吧
1，可以。方法: 每一條數據對應到具體用戶，可以把原來的組織想象成一個用戶一個單獨的組織。
2，可以。方法: 按組織取出數據的同時，根據角色篩選。
RBAC模型中，個人理解其實還有一層，也就是權限的分類：操作權限，資源權限。權限的概念，指的是對某資源（比如頁面，按鈕，數據庫中的某條（某些）數據）是否允許某操作，所以有兩個層面的主體：資源與操作?；氐阶畛醯挠脩?權限模型，就是“某一個用戶，對某一個資源，允許某一些操作”的集合。然后在這個基礎上做分類和解耦
通過 角色 做權限管理 和 通過 組織的邊界在哪？
樓主留的2個問題，我覺得是同一個問題。在不引入xx的情況下，實現數據的控制。有一個思路，在用戶級，直接設定其上級用戶。
感謝分享，超級受用。第一點里小標題 “RABC的好處” RBAC RABC我也要看花眼啦 ??
非常感謝作者的分享！有時間也很想把自己在權限方面的一些心得拿出來跟大家交流，因為在權限管理很重要很重要很重要，開始沒設計好，后面迭代起來非常的麻煩。
1、第一個問題的本質應該是數據權限到底應該如何控制的問題？要給劃分數據的范圍，就必須給每一條數據打上一個可以用來劃分的標識。那到底用什么來做標識，要根據數據劃分的需求來分析。文中提到的數據私密性的要求，就很容易讓人想到用組織架構。因為每一條數據都是由用戶創建的，用戶又一定屬于某一個組織節點，那數據肯定就一定會有組織節點。有沒有應用場景是不需要根據組織架構來劃分數據權限的呢？當然有，例如商業地產。數據的管理需求是根據項目來劃分的，那就需要我們在做產品設計的時候就考慮到，每一條數據的產生一定是屬于某一個項目的。那這時候，就可以根據項目這個標識來劃分數據權限的范圍。
2、第二個問題就簡單一些，我們首先確認每個用戶可以查看哪些組織節點的數據，再加一層控制，可以查看這個節點下面自建的數據還是全部的數據就好了。
您好，我是做公寓租賃管理系統的，和您比較像，想請教您一個問題。數據權限的確是根據項目（或者樓棟）來劃分的，但系統不同模塊的數據是有公私之分的，例如：
1.客戶管理模塊，同項目的兩個招商人員各自只能看到自己的客戶，而招商主管可以看到項目的所有客戶，如何在后臺配置呢？
2.房源&合同管理模塊，同項目的兩個運營人員都可以看到該項目的所有房源和合同，但是只能編輯和修改自己錄入的合同，這個要怎么配置呢？
??
像這種情況應該不需要設置。角色這塊已經固定了。
1.后臺只需要根據角色加上條件去查就行了。
2.合同都有一個錄入人，前臺做判斷看運營人員和錄入人員是否同一人就行啊。
你說的非常好！厲害
1：我對于作者問的第一個問題其實不是很清晰。
2：RABC模型的解釋是 基于角色的權限控制，所以我們可以在角色這里思考。建立角色組和父子角色概念，對于一個團隊而言，每個成員有一個或多個角色，把每個成員的角色歸屬到一個角色組里面，在把角色組給團隊leader，leader就擁有整個團隊的權限。應為作者說 了這里是團隊的 leader和團隊成員是屬于同級組織里面。當我們的組織結構樹往上走的時候，當為這個管理幾個團隊的領導奉陪權限的時候，我們就可以引入父子角色概念。
“比如：上級組織職能看到下級組織員工負責的數據，而不能看到其他平級組織及其下級組織的員工數據等?！边@一句的后半句是不是應該為“及其上級組織員工” ？
【其他平級組織及其下級組織的員工數據】這個是一句話
“比如：上級組織職能看到下級組織員工負責的數據，而不能看到其他平級組織及其下級組織的員工數據等?！边@一句的后半句是不是應該為“及其上級組織員工” ？
感謝作者的分享~
回答一下上面的問題：我的理解，問題一和問題二都是把團隊的員工和該團隊的管理者放在了一個目錄下，普通員工只能看到自己的數據，而管理者可以看到該團隊的數據，我想應該建一個“管理者”的角色，配置到團隊，即有該角色的用戶就可以查看對應團隊所有數據的權限，否則只能查看自己的數據。
數據權限與角色是無關的。角色是控制操作權限的，組織是控制數據權限的
我做的也是RBAC的改進，不過我設計的是將權限分為操作權限和資源權限，操作權限的集合即為角色，資源權限的集合為職位，角色表示了該角色的用戶所能進行的操作，職位表示該用戶所能操作的資源，職位相當于每一個權限所對應的資源列表。
問題一：權限在定向圖中從上向下流動，上級角色為父角色，下級角色為子角色，權限由父角色為子角色分配。相同角色的用戶擁有不同職位，實現數據私密性。
問題二：我覺得組織機構和權限系統是分開的，因為父子角色已經可以實現子角色的權限是父角色的子集，同時還能實現當有多個上級時，每個上級的權限都只能看到自己能管理的數據，無法看到子角色所有數據。
有這樣一個場景，若幾個相同職位的人，寫了同一份資源列表，如何管理他們使得他們只能看到列表中自己創建的那部分資源數據。這才是數據權限問題，因此其實你對數據權限和操作權限的理解有誤
是的，17年的時候對這塊了解不夠深入。問題二現在想想也只有在組織上再加一層控制，管理員數據權限等于組織，其他用戶的數據權限除了自己建的以外需要管理員授權
寫得很通俗易懂，受用
感謝作者的分享~
小答一下兩個問題：
問題一：可以達到。如果沒有“組織”，可以根據需求在權限部分建立子分類，比如編輯權限下可以分為編輯A區域內容、編輯B區域內容。
問題二：這個問題沒太明白作者的意圖，因為在文章中已經提到了答案——設定數據可視權限規則