電商行業中，後臺會有客服、採購、財務等不同的角色，對應展示不同許可權、介面資料。在設計B端後臺許可權模組時，簡單的用許可權勾選即可，然而複雜的需要涉及到多角色、多許可權相互匹配的場景中，則需要引入一個概念——RBAC許可權模型。本文作者對RBAC許可權模型進行了介紹，一起來看一下吧。
這是一篇
實戰經驗+概念解釋
文章。
想法來自近期在進行一個後臺產品中，涉及到許可權管理的設計，需要設計多種角色、並需要對應不同級別，需要區分不同許可權的設計，說半天，上個圖！
大概意思就是在D的角色下會有A、B、C這3人，而C又包含角色A、B的許可權，角色A、B下方又有A-1、B-1等人；而D擁有最大許可權，對應下分不同角色配對不同許可權，而下一級又是不同許可權！於是一層層套娃開始了！
做過電商行業的應該都知道，在後臺會有客服、採購、財務等不同的角色，對應展示不同許可權、介面資料。
這就要求設計師在設計時，就要從業務角度上，去對每個角色進行代入、根據實際業務理解後進行設計。
通常在設計B端後臺許可權模組時，需要先釐清角色與許可權之前的關係，比如對子賬號進行角色管理、許可權分配等場景進行分類，如果簡單一點的模式設計就很好處理，用許可權勾選即可，但複雜一點的就需要涉及到
多角色、多許可權相互匹配
的場景中，簡單許可權勾選就不足以支撐起許可權模組了。
因此，在B端後臺介面設計中，就需要引入一個概念：
RBAC許可權模型
，現今許可權設定幾乎都是在RBAC模型上進行擴充套件的，本文下面將會對RBAC許可權模型進行簡略介紹。
一、RBAC模型定義
那說起RBAC許可權模型，那我們來看下它在“維基”上的定義：
可以看到：RBAC是Role-Based Access Control的英文縮寫，意思就是以【角色】為基礎進行【許可權】的【控制】。
換句話說：就是
劃定【許可權】範圍，賦予【角色】，再將【角色】賦予【賬戶】
，這樣【賬戶】擁有了許可權，許可權邊界會很清晰，而去命定賬戶許可權時只要去管理角色即可。
還是不懂？看圖？？？？
例：RBAC簡單示例
再用王者榮耀來比喻：
角色 == 英雄人物
許可權 == 英雄技能
賬戶 == QQ/微信賬號
使用【英雄人物】的就是你的賬戶，賬戶可以擁有多個英雄人物，管理許可權的時候只要去管理【英雄人物】就行了。
二、RBAC模型細項說明
在RBAC模型中，有三個比較重要的概念：
許可權：原子級別功能，能夠訪問某個資料或者進行某個操作的資格或權力
角色：分子級別功能，對某一類共同擁有許可權集合群體名稱
賬戶：組合功能，對擁有角色集合的群體名稱
下面對每個概念進行說明。
1. 許可權說明
在計算機系統中，許可權是指某個特定的使用者具有特定的系統資源的使用權力，在後臺管理中，系統資源指的是系統模組、頁面、操作功能等。
大致可以將許可權分為：
功能操作許可權、資料許可權
。
功能操作許可權：在系統的操作、互動都是功能許可權，操作都需要頁面承載，所以包瀏覽頁面許可權、操作按鈕許可權都歸屬功能操作許可權
資料許可權：對資料進行增刪改查
例：許可權的構成圖
2. 角色說明
角色是一定數量的許可權的集合以及載體，很好理解，就是界定好哪幾個角色擁有哪些許可權。
比如角色一擁有：檢視訂單、修改訂單價格、確認發貨、訂單評價 等許可權，那角色一其實定義的是客服角色，那就可以給角色一命名為【客服】。
如下圖所示：
例：新增角色操作介面
3. 賬戶說明
賬戶是對角色的囊括，也是角色集合的載體，即界定賬戶擁有哪些角色，對應擁有哪些角色的許可權。
如下圖所示：
例：賬戶對應的角色
4. 升級模型：RBAC1模式
上述所有模型是基礎模型，實際業務中僅有基礎模式是不夠使用的。
比如一個系統中有了角色：管理員、客服、採購、財務等。
但財務下會有多種角色，例如：總賬會計、明細帳會計、出納等角色，故此對RBAC模型進行升級，會把一開始沒有上下級關係的稱為
RBAC0模型
，在RBAC0基礎上引入角色間的上下級關係，升級後稱為為
RBAC1模型
。
如下圖所示：
例：RBAC1模型
在RBAC1之後還有RBAC2、RBAC3等關係，較為複雜，不在本次討論範圍之內。
三、設計中引用RBAC模型的好處
RBAC中具有角色的概念，設想一下，如果系統中沒有角色，那麼需要設定每個賬戶的許可權，如果較複雜系統中，涉及到許可權都非常多，每個賬戶都單獨設定一遍，無疑是一件繁瑣且工作量巨大的任務，可以說引用RBAC模型可以大大提高生產力。
在還未引入模型時，需要對每個賬戶都進行許可權限定，參考下圖，線條代表了需要操作的次數。
如果引入角色後，只需要給
將角色給不同賬戶
，
給角色賦予許可權，這樣賬戶擁有的角色就直接擁有了該角色下的所有許可權。
四、實戰：如何設計RBAC模型
1. 梳理許可權
可以對頁面當中擁有哪些可操作項收集，通常許可權都是由系統、頁面操作限定的，可以梳理一下產品整體框架，對所有許可權進行分類。
比如千牛商家後臺，在【店鋪】一級頁面下，擁有【店鋪管理】【商戶中心】【神筆】【營銷管理】四大許可權，在這四大許可權之下又擁有次級頁面，在次級頁面下擁有各個模組的操作，這樣從功能操作+資料上實現了集合。
如下圖：
例：千牛商家自定義許可權
2. 命定角色
從擁有【店鋪】整體許可權來分析，其實更多是關於到整體運營層屬性，所以在歸屬【店鋪】許可權，可以對應到【運營組長】【運營專員】等角色。
如下圖：
例：千牛商家命定角色
3. 賬號限定
其實對賬號的限定很簡單，重點是對賬號擁有哪些角色範圍圈定，圈定角色之後就隸屬於哪個部門使用賬號的問題了
如下圖：
例：千牛商家命定賬號
大功告成！完成這3步就完成整體設定啦！
總結一下
B端後臺許可權設計引入RBAC許可權模型設計，是基於角色進行的許可權訪問控制，再進行對角色進行賬號匹配。在進行產品設計時，儘量使用許可權、賬號分開模式去設計，而使用角色——許可權匹配模式來做解耦。
後臺類或者TO B內部產品，不會像C端使用者一樣許可權簡單，也不會追求極致使用者體驗，而是追求明確、結構清晰，不要在互動操作或文字上，讓使用者有疑惑，尤其針對許可權一塊，或涉及業務功能設計上，儘量減少歧義，避免造成返工、錯誤理解等情況。
另附帶RBAC模型升級概念解釋，下期見！
RBAC0：是RBAC的核心思想
RBAC1：RBAC基礎上增加了角色分層模型，即進行了角色上下級區分
RBAC2：RBAC基礎上增加了約束模型，什麼是約束呢，就是賬號想要獲得高階許可權，必須先擁有低階許可權，否則無法命定
RBAC3：其實是RBAC2 + RBAC1，雙重限定條件
本文由 @無塵弟弟 原創釋出於人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基於 CC0 協議。
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供資訊儲存空間服務。