发现每次设计权限体系都很痛苦，归根结底就是没有沉淀出一套方法论。看了下网上的文章大多是讲RBAC权限管理模型RBAC0介绍到RBAC3，看的吐血了，还是自己总结点实际点的东西。

设计B端产品，无可避免会涉及权限管理的问题。

为什么呢？

因为B端产品生来就是带着组织结构属性的，它辅助我们分工、协调和合作。所以我们的产品必须紧紧切合职、责、权这三个主题。

简介

权限管理，一般指根据系统设置的安全规则或者安全策略，用户可以访问而且只能访问自己被授权的资源，不多不少。

原因

为什么要做权限管理呢？

• 权利不同可以了解的数据内容不同，保证数据隐私，避免数据泄密；
• 职责不同所需要页面不同，保证操作效率，避免页面干扰；
• 技术水平不同可以操作的功能不同，保证系统安全，避免操作风险。

还有其他要素，都注定了要独立出一个权限管理模块来规范操作和数据权限。

原则

权责明晰：

• 权：专人做专事，既可以防止误操作，又避免干扰。比如自身才可以编辑和删除。
• 责：能将错误行为定位到人，落实责任。比如操作作业和表都带上责任人的信息。

界限分明：

• 功能：将功能按不同层级或者属性进行划分；
• 数据：将数据按业务类型或者组织架构特性进行划分。

流程规范：

• 依赖：允许用户依赖别人作业和查看作业信息，保证组织的流畅性；
• 继承：根据实际情况要考虑流程的容错性，比如是否可以跨节点确认。

原理

所以每个用户都需要权限限定，但是直接给用户赋上权限，会有很多问题：

• 工作量大，需要给每个用户依次赋上权限；
• 灵活度低，如果某个操作权限关掉了，需要一个个找出用户依次修改权限。

所以基于传统的权限模型进行改建，RBAC模型是一个成熟的权限模型，虽然被讲烂了，但是还是假装不知道重新介绍下。

RBAC（Role-Based Access Control）基于角色的访问控制，不同于传统的权限模型直接赋予使用者权限，而是将权限赋予角色。

• 用户与角色相关联，是多对多关系；
• 角色与权限相关联，是多对多关系。

项目管理

项目是用来隔离数据和用户的，用户加入当前项目才可以享受该项目下的资源。你可以把项目当做部门就明白了，A部门的用户不可以查看B部门的数据。

注意：删除项目，需要提示是否删除项目下的数据，如果删除有很多风险，那就禁用删除吧。还有一种折中的方法，就是删除时允许将项目下的资源迁移到其他项目。

用户管理

管理用户信息，以及对用户进行增删改查，包括用户名称、所属部门、联系电话等信息，至于密码，一般只能重置密码，而不是显示密码允许修改。

注意：

• 源：一般我们可以和OA关联拿取账号，而不需要在产品里添加，保证内部系统信息一致性。
• 目标：在产品中一些页面需要读取用户管理的用户信息。
• 交接：如果用户的信息被产品某些功能所引用，必须考虑用户离职后，其创建的资源管理的问题，这时候被赋予所有权限的管理员是个很好的接盘侠。

用户组管理

用户组其实就是批量给用户赋予角色，将多个用户绑定为一个小组，再给这个小组赋予一个角色。

注意：如果内部组织架构不复杂的话，最好不要加入用户组，不然增加了权限体系的复杂性，毕竟杀鸡焉用牛刀。

角色管理

管理角色信息，对角色进行增删改查，包括角色名称、角色描述和角色状态等。

可以将角色理解为将权限打包成一个小组，那个小组就是一个角色。

注意：角色停用后，用户被赋予这个权限就不生效。

权限

• 页面权限：页面权限指用户可以看到的页面。如果你的产品比较复杂，可能你需要从模块权限到菜单权限最后到页面权限。
• 操作权限：操作权限指用户可以操作的内容，即按钮权限，是否有增删改查的权限。

思考

• 衔接自然：比如根据项目区分数据权限，根据岗位区分角色，将现实的角色与产品角色相关联，显得更自然。
• 轻装上阵：很多人一讲到权限管理，就希望把它设计的非常全面严谨，但是逻辑上的全面严谨和功能上的全面严谨完全是两回事。如果前期不需要，完全没必要多抽象出几个概念，需要考虑的反而越多。所以在能满足权限的需求下，就不要多设概念，比如抽象出用户组这种，很可能基本用不到，而且还增加了系统复杂度。
• 随机应变难道一定要遵从RBAC模型吗？等你真正参与项目，就会发现，RBAC模型仅仅只是个开始，它只是帮你打好基础，之后还会有各种各样个性化的需求，绝对不仅仅现在说的这么简单······

参考

大数据开发平台权限管理

后台经验分享：如何做权限管理系统设计

后台系统：账号权限系统设计

以RBAC模型为基础，分析B端权限系统的设计思路（业务技能）

一个案例，三个角色，简单说下B端产品的权限设计

本文由 @ 安琪Angela 原创发布于人人都是产品经理。未经许可，禁止转载

题图作者提供