后台系统的权限管理系统这个功能，可谓是难倒了一大批产品经理。本文总结了B 端权限系统的概念及原理，希望对你有所帮助。
发现最近好多人在问，后台系统的权限管理怎么做。
权限管理这个功能，可以说难倒了一大批产品经理。
虽然讲权限的文章一大堆，但真正讲透的屈指可数。
刚好前段时间，我设计的多租户权限系统上线了，做的过程中也总结了一些经验，这里简单聊聊。
什么是权限？
权限是后台的基础模块之一，没有它的话每个用户都是超级管理员，系统数据可以任意操作、改写，如果是这样那公司就乱套啦。
为了避免这种情况发生，后台需要上线权限功能。
它确保了不同用户进行合理分工和操作，避免了风险管理、数据安全等问题。
产品经理如果想搞懂和设计权限系统，需要先学会这 3 个基础概念：用户、权限、角色。
权限看起来很复杂，其实说起来只有这两种分类：功能权限、数据权限。
功能权限，主要控制账号的组件可视范围，常见的有目录、菜单、按钮等。
数据权限则决定了用户能看哪些数据，一般通过“部门、品牌、区域”等维度划分数据权限。
例如广东地区的同事，只能看到广东地区的销售数据，其他海南、青岛等区域的数据，在系统界面将隐藏。
权限模型有很多种，例如“ACL 模型、DAC 模型、MAC 模型、RBAC 模型、ABAC 模型”等。
这些权限模型为什么会产生？主要是公司基于“组织体量、业务背景、实施成本”等因素权衡取舍后的解决方案。
而我们在日常过程中，由于业务不大、公司架构简单等因素，一般只需要用到“ACL 模型、RBAC 模型”这两种。
ACL 模型中，涉及了“用户、权限”这两个概念，主要通过用户绑定多个权限，实现了权限控制管理。
例如 A 账号是客服在用，它绑定了“内容管理、订单管理”等权限，而 B 账号作为老板专属，当然是权限全开啦。
这种方案比较适合小公司，开发量较少。
但弊端是，当维护的用户足够多，而且它们权限大差不大时，配置权限的那个人一定很崩溃。
为了解决配置繁琐的问题，我们需要使用 RBAC 模型。
RBAC 模型相比 ACL，多了一个角色的概念。
角色主要是为了将用户、权限进行解耦，以达到权限“批量配置、随时更新”的目的。
例如将原先的 A 账号权限，分配给客服角色，然后再把老板 B 账号，给到“超级管理员”角色。
那么当公司有 20 个客服，3 个老板时，通过 RBAC 模型，配置权限就只需要几分钟。
如果你觉得一项知识太高深难懂，也许只是还没找到学它的正确姿势。——好夕雷
说了这么多概念和模型， 听起来可能比较抽象。
我们试着用一些简单的 Excel 表（为了便于理解，简化了部分数据），来理解 ACL 模型、RBAC 模型的权限原理。
在 ACL 模型中，想实现权限控制，我们首先需要“用户、权限”这两个主表。
现在问题来了，你上司突然要你搞定下面的权限配置，该怎么做？
听起来真是头大阿！躺平行不行？
要想实现上司的权限需求，你还需要用到第三个表“用户权限关联”。
这个表的作用，是将用户与权限的关系进行绑定，方便系统确认不同用户的权限范围。
按上司的要求，我们完成了用户权限的配置。
无论界面交互层如何花里胡哨，功能实现的本质还是数据操作。——好夕雷
由于在数据库中，这些关系是通过 ID、代号表示的，看起来比较抽象。
我们试着用文字替代。
怎样，看起来是不是容易理解多啦？
前面我们讲到，RBAC 模型相比 ACL 模型多了角色的概念。
所以除了“用户、权限”表之外，我们还需要一个“角色”主表，并按需求配置 3 个角色。
由于权限逻辑变了，所以原先那个“用户权限”表就没啥用了。
我们还需要“用户角色关联、角色权限关联”这两个新表，来实现 RBAC 模型的权限控制。
上图中，其实有两个问题需要注意：
权限系统看起来很复杂，其实只要你掌握了权限的概念、分类、模型、原理，那么想要设计一个权限方案也不算难。
本文由 @好夕雷 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。