在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 中，一个操作是否被允许是基于对象、资源、操作和环境信息共同动态计算决定的。可以细粒度地授权在何种情况下对某个资源具备某个特定的权限。比如时间、位置、设备、加密强度等在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端产品绕不过去的知识点，希望此文章能帮助初学者理解权限设计。是以记。