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

B端產(chǎn)品設(shè)計離不開權(quán)限控制。本篇來介紹一下最常用的權(quán)限控制體系：RBAC模型。

一、權(quán)限控制五問

1. 什么是權(quán)限控制？

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

2. 為什么做權(quán)限控制？

保障業(yè)務(wù)的安全性和穩(wěn)定性。

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

3. 權(quán)限控制都包含哪些方面？

包含功能權(quán)限和數(shù)據(jù)權(quán)限。功能權(quán)限又包含菜單權(quán)限和按鈕權(quán)限。

• 菜單權(quán)限：指某一頁面是否可見。
• 按鈕權(quán)限：指頁面上某些按鈕是否可見。
• 數(shù)據(jù)權(quán)限：指頁面上某些數(shù)據(jù)對用戶是否可見。

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

4. 什么時候需要做權(quán)限控制？

當系統(tǒng)有多個職能的用戶，且數(shù)據(jù)和操作敏感時，就會涉及權(quán)限控制。

5. 怎么做權(quán)限控制？

權(quán)限控制最常見的模型共4個：

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

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

如何定义B端产品及B端产品经理方法论

相较于C端产品，B端产品最大的特点是：面向特定领域用户，且数量少得多，但更注重对用户专业领域操作流程的深度挖掘——也就是专业性更强，与业务的结合更紧密。

查看详情 >

這種設(shè)計最常見的應(yīng)用就是文件系統(tǒng)的權(quán)限設(shè)計。

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

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

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

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

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

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

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

二、RBAC模型介紹

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

引入角色的概念。通過用戶對應(yīng)角色，角色對應(yīng)權(quán)限，來實現(xiàn)權(quán)限控制。

2. RBAC的應(yīng)用

1）權(quán)限定義：給需要被控制的權(quán)限做一個定義，最基礎(chǔ)的字段有：

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

而此權(quán)限定義，一般是產(chǎn)品提出需求需要控制，前端研發(fā)完成實際定義。

2）在權(quán)限系統(tǒng)完成配置

將此研發(fā)的定義，在權(quán)限系統(tǒng)中進行配置。一般公司都會有自己的權(quán)限系統(tǒng)，大家使用公共能力。配置頁面最基礎(chǔ)的有3個：

1. 權(quán)限定義：將研發(fā)的權(quán)限名稱和權(quán)限碼在權(quán)限系統(tǒng)中完成定義。
2. 角色定義：將角色和權(quán)限完成匹配；
3. 用戶權(quán)限賦予：將用戶和角色完成匹配。

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

4）業(yè)務(wù)系統(tǒng)根據(jù)權(quán)限系統(tǒng)返回的權(quán)限碼，匹配自己系統(tǒng)的配置，將對應(yīng)的權(quán)限進行展示。

3. RBAC模型的優(yōu)勢和問題

優(yōu)勢：引入角色的概念，降低配置的復(fù)雜度。

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

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

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

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

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

1）引入崗位的概念

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

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

3）權(quán)限分級：在權(quán)限創(chuàng)建時，確定權(quán)限的危險級別，對待高危權(quán)限，進行特殊的申請流程。

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