B端系统的角色权限设计是保障系统安全、提升操作效率的核心框架，直接影响产品的灵活性与可扩展性！这篇文章聚焦“从0到1构建灵活权限架构”，以经典的RBAC模型为核心，详解设计全流程。
在B端系统架构中，角色和权限可以说是支撑系统的框架，它关系到系统的安全性、便捷性和延展性。
本文将探讨一下如何从0开始设计一个灵活可扩展的权限架构。
绘制出企业组织架构图，理解岗位、小组、部门之间的层级关系、管理关系。
例如普通销售应只能查看自己客户的基本信息、消费记录等，而部门经理可查看本部门下所有销售的客户信息。
最好能够至少一个岗位挑一位员工访谈，明确他们日常工作内容、需要操作及查看的业务、数据。
选择一个合适的权限模型作为技术实现的蓝图。
目前最经典且广泛应用的是RBAC（基于角色的访问控制） 模型。
这里先简单介绍一下RBAC模型。
RBAC模型的三要素：用户 -> 角色 -> 权限
权限的精细化分级：
一般功能权限和操作权限是结合一起设置的，就称为“功能权限”。
例如想给一个用户配置了“合同管理”页面的“新增”操作权限，那他肯定是有“合同管理”这个菜单权限的。
基于RBAC模型，我们可以对每个岗位的功能权限、数据权限包装成一个聚合角色。（当然，其中要去除线下业务。）
如销售专员可以包装成“销售专员”角色 ，各分店的销售专员岗位都可以授权这个角色。
有的同学可能疑惑，角色和岗位名称基本都是一致的，为什么不直接授权给岗位，非要多包一层“角色”用来授权呢？
理论上直接授权给岗位也是可行的，但是实际中会存在一些问题。
以下通过举几种实际情况来说明RBAC模型优势：
（1）一个岗位对应多个角色
例如“销售主管”岗位，既对应“销售经理”角色又对应“部门负责人”，又对应“订单审核员”角色。
那只需要将“销售主管”岗位对应匹配上这三个已经设置好权限的角色就好，无需再一个个勾选繁多的功能/数据权限。
（2）多个岗位权限一致
另外，例如像“销售专员”、“客服代表”如果权限完全一致，那可以都授权“客户管理人员”这个角色就行，就不需要每个岗位都一一去配置权限了。
（3）员工岗位变动
例如公司组织架构调整，合并部门、撤销更为等，当员工岗位变动时，只需更改其背后绑定的角色，其权限即可自动更新，不需要重新梳理权限。
系统角色与上方所说的业务角色“销售主管”“销售经理”不同，
通常指“超级系统管理员”“系统管理员”等对系统、用户、账号、数据进行管理的角色。
系统角色一般是与业务角色区分开在不同页面模块进行授权管理。
主要是设置例如“创建角色”“恢复数据”这样的系统权限。
但大部分系统只设一个系统管理员角色，且默认为最高权限，不会将系统角色的授权放在前端页面上。
3-1 . 先聊一下数据权限的几种划分维度：
（1）基于组织架构的数据权限
这是最常见的一种维度。一般分为：
（2）基于数据归属的数据权限
这个维度也是较为常见的。一般分为：
（3）基于其他维度划分的数据权限
例如按项目划分。一般分为：
项目具体基于什么维度，怎样划分需要根据组织架构及业务去制定。
3-2 . 数据访问范围的“交集”
例如HR仅能查看本机构自己负责的招聘人员信息。
则给HR授权角色的数据权限时，需授权“本机构的”且“我负责的”权限。
3-3. 数据访问范围的“并集”
例如销售可以看到归属自己的客户及他有参与的项目的客户信息。
则给销售分配角色权限时，需要授权“归属我的”及“我参与的项目”的数据权限。
给角色取名时，一般都会采用和岗位名称一致的名称，这样较简单直观。且大部分同个岗位的权限是一致的，创建对应的一个“聚合角色”就可以。
对于有特殊需求的员工，例如兼岗需要额外负责某项工作（以某个营销专员还需要审批合同为例），就需要授权聚合角色（营销专员）+功能角色（合同审批人员）。
设计好角色权限对一个B端系统来说非常重要，这涉及到产品的搭建架构和后续扩展性。若初期没有通盘考虑好，等后期要推翻原有逻辑，就会造成大量的重构成本。
本文由人人都是产品经理作者【Zoe】，微信公众号：【Zoe life】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。