在B端產品設計中，權限控制體系設計是十分重要的一個環節，其中，不可避免地會提到RBAC模型。那么，什么是RBAC模型？RBAC模型有哪些優勢所在？這篇文章里，作者做了梳理和總結，一起來看看吧。

B端產品設計離不開權限控制。本篇來介紹一下最常用的權限控制體系：RBAC模型。

一、權限控制五問

1. 什么是權限控制？

權限控制是指在系統中，對不同角色、部門或用戶進行訪問控制和權限管理的能力。它能夠確保系統中的數據和功能僅對有權限的用戶可見和可用。

2. 為什么做權限控制？

保障業務的安全性和穩定性。

1. 避免員工看到職責外的敏感功能和數據；
2. 避免員工操作職責外的敏感功能和數據。

3. 權限控制都包含哪些方面？

包含功能權限和數據權限。功能權限又包含菜單權限和按鈕權限。

• 菜單權限：指某一頁面是否可見。
• 按鈕權限：指頁面上某些按鈕是否可見。
• 數據權限：指頁面上某些數據對用戶是否可見。

case：公司有多個職能角色，商家運營負責和商家溝通一切事宜，商品運營負責對商品的覆蓋度和質量，活動運營對活動進行管理。同時，商家在橫向還存在多個部門，比如快消部門、3C部門等按照不同類目的部門。此時，不同類型的權限可能如下表所示。

4. 什么時候需要做權限控制？

當系統有多個職能的用戶，且數據和操作敏感時，就會涉及權限控制。

5. 怎么做權限控制？

權限控制最常見的模型共4個：

1）DAC（Discretionary Access Control）自主訪問控制：

系統會識別用戶，然后根據被操作對象（Subject）的權限控制列表或者權限控制矩陣的信息來決定用戶是否能對其進行哪些操作，例如讀取或修改。而擁有對象權限的用戶，又可以將該對象的權限分配給其他用戶，所以稱之為“自主（Discretionary）”控制。

這種設計最常見的應用就是文件系統的權限設計。

2）MAC（Mandatory Access Control）強制訪問控制模型

在 MAC 的設計中，每一個對象都有一些權限標識，每個用戶同樣也會有一些權限標識，而用戶能否對該對象進行操作取決于雙方權限標識的關系，這個關系的判斷通常是由系統硬性限制的。MAC 非常適合機密機構或者其他等級觀念強烈的行業，但對于類似商業服務系統，則因為不夠靈活而不能適用。

3）RBAC（Role-Based Access Control）基于角色的訪問控制模型

最常用的系統權限控制就是RBAC模型，能覆蓋絕大部分的場景。也是本篇詳細介紹的模型和實際應用中的一些場景。

4）ABAC（Attribute-Based Access Control）基于屬性的訪問控制模型

在 ABAC 中，一個操作是否被允許是基于對象、資源、操作和環境信息共同動態計算決定的?？梢约毩６鹊厥跈嘣诤畏N情況下對某個資源具備某個特定的權限。比如時間、位置、設備、加密強度等在RBAC中不使用的一些屬性信息。比如：早上九點前禁止 A 部門的人訪問B系統。

但是ABAC使用過于復雜，一般場景就是RBAC模型，本篇也著重介紹RBAC模型。

二、RBAC模型介紹

1. 什么是RBAC模型（Role-Based Access Control）

引入角色的概念。通過用戶對應角色，角色對應權限，來實現權限控制。

2. RBAC的應用

1）權限定義：給需要被控制的權限做一個定義，最基礎的字段有：

• 權限名稱：名稱；
• 權限碼：唯一的編碼，一般用英文和符號。

而此權限定義，一般是產品提出需求需要控制，前端研發完成實際定義。

2）在權限系統完成配置

將此研發的定義，在權限系統中進行配置。一般公司都會有自己的權限系統，大家使用公共能力。配置頁面最基礎的有3個：

1. 權限定義：將研發的權限名稱和權限碼在權限系統中完成定義。
2. 角色定義：將角色和權限完成匹配；
3. 用戶權限賦予：將用戶和角色完成匹配。

3）在用戶訪問系統時，調用權限系統提供接口，查詢用戶擁有的權限碼合集。此時一般權限系統返回的都是權限碼，而不是角色了。角色時便于配置使用的。

4）業務系統根據權限系統返回的權限碼，匹配自己系統的配置，將對應的權限進行展示。

3. RBAC模型的優勢和問題

優勢：引入角色的概念，降低配置的復雜度。

如果沒有角色，直接給每個用戶配置權限。當存在100個用戶，20個權限時。每個用戶需要單獨配置一次權限，會配置100次。而其中如果新增一個權限，還需要給100個用戶單獨配置。新增一個用戶，也得單獨配置好20個權限（如果需要篩選，還得每個權限衡量是否可添加）。

而引入了角色，可以將100個用戶分成多個組，將權限也分成多個組。如果實際屬于3個部門，那可以配置3個角色。配置3次角色和權限的關系，再配置100次人和角色的關系（此時可以考慮優化此處的效率）而其中如果新增一個權限，還指需要增加1次角色和權限的配置。新增一個用戶，也只需要再3個角色中衡量是否可以添加。

優勢也是問題：因為角色是自定義的，所以能靈活支持各種權限場景的權限控制。但是另一方面，可能帶來的問題是角色太多，從而造成：

1. 業務不清楚自己要申請什么角色；
2. 業務申請超過自己工作職責外的角色。

怎么解決以上問題呢？實踐中應用過幾種手段：

1）引入崗位的概念

1. 角色定義時，更多的傾向于崗位定義而不是功能定義。比如，角色名稱我們可以叫商家運營，然后包含商家運營在各個業務系統內的權限，這樣當我作為商家運營入職時，申請此角色即可。
2. 創建角色和崗位的關系。把某些角色和崗位在權限系統建立關系，這樣當用戶作為此崗位登錄時，自動可擁有此角色。

2）通過功能反向查詢對應的角色：覆蓋場景，用戶需要某一單一功能但是不清楚對應的角色是什么。就可以通過崗位查詢相關的角色從而進行申請。

3）權限分級：在權限創建時，確定權限的危險級別，對待高危權限，進行特殊的申請流程。

權限設計是每一個B端產品繞不過去的知識點，希望此文章能幫助初學者理解權限設計。是以記。