网站内容管理系统后台 设计(1..jpeg2.三大模块搭建后台用户角色权限设计模型)

　　网站内容管理系统后台 设计(1..jpeg2.三大模块搭建后台用户角色权限设计模型)

　　一. 用户角色权限系统说明1. RBAC 权限设计模型

　　RBAC（Role-Based Access Control，基于角色的访问控制）是用户将角色与权限相关联，以获得使用某些功能的权限。权限分配给角色，而不是用户，但一个用户可以拥有多个角色。将角色分配给用户时，该用户具有该角色中收录的功能权限。

　　简单来说，一个用户有几个角色，每个角色都有几个功能权限。这样就构建了一个“用户-角色-权限”的授权模型。在这个模型中，用户和角色之间、角色和权限之间是多对多的关系。如下所示：

　　图像.jpeg

　　2. 三个模块搭建后台用户角色权限体系

　　一个后台用户角色权限系统总可以大致分为三个模块：用户管理、角色管理、权限管理。

　　角色权限系统属于策略设计的范畴，其设计考验的是PM对业务的理解和对自身背景所有功能的熟悉程度。在制作角色权限系统之前，首先要对后台的业务流程和所有功能模块有一个深入的了解。不明白的可以向相关同事请教，避免在角色权限系统的设计过程中出现错误和逻辑漏洞。

　　图像.jpeg

　　二.用户角色权限体系建设三大模块1.用户管理

　　用户管理中的用户主要是功能系统的用户。这些用户是个体员工。这些个体往往分为两个维度：行政关系（部门结构）和业务部门（业务结构）。用户管理就是在这两个维度上对个别员工进行初步的分组或分组。划分为行政部门或业务线部门后，相应部门或组的用户具有基本相似的系统功能使用要求和权限等级；

　　图像.jpeg

　　注：上图为按管理关系划分的用户管理方式

　　图像.jpeg

　　注：上图为根据业务线关系划分的用户管理模式

　　2. 角色管理（1） 角色管理

　　角色往往是系统根据业务管理需求预先设置的固定标签。每个角色对应明确的系统权限。它所拥有的系统权限一般不会随意改变，角色也不会随用户而改变。通过添加和删除进行更改，比用户管理更稳定；

　　图像.jpeg

　　(2）自动赋能：用户自动进入角色

　　如果管理关系下的角色与组织部门存在绑定关系，如果用户进入组织部门，该用户将自动添加到对应的角色中，并拥有该角色的所有系统权限。

　　例如，财务人员【小张】加入财务部门后，用户可以查看部门内员工可以查看的财务数据报表以及相应的操作权限（如经营财务审批等）。相应的财务报告系统，无需额外授权。;

　　(3）角色授权：用户被添加到角色中

　　业务在不断创新和发展，随着业务的发展，会设置和创造越来越多的新角色。

　　例如，公司新推出了企业团餐项目。项目部从各个部门找了多名员工组成项目组，项目的业务权限只授权给这些员工查看和操作。然后，在这个项目中，会新建一个角色“财务1”，系统的高级管理员将从财务部门选出的财务【小张】添加到“财务1”的角色中，然后【小张】 ] 可以查看企业集团对业务数据报表和餐饮项目操作的权限。这种权限的授予不能通过用户管理关系的自动绑定来实现；

　　(4）角色继承：角色权限的继承

　　权限可以是唯一的或继承的。每个角色都有自己的权限集，角色继承其实就是继承父角色的权限。一般来说，一个角色在继承其父角色的所有权限的基础上，还有一些额外的权限。而系统角色继承往往存在于用户分级管理明确的团队或公司中；

　　(5）角色互斥：角色收录的权限互斥

　　角色互斥的业务背景：当一个业务流程出于风控原因需要划分为多个独立的步骤时，需要为这些不同的步骤授权不同的角色，并为这些角色分配不同的角色。相互排斥。

　　比如在大额财务报销的审批过程中，财务人员【小张】获得审批人权限后，不能将审核确认的授权授予小张，以规避财务风险由一人完成大额报销造成的；

　　(6）临时角色

　　临时角色通常是为特殊群体设置的。比如公司有专门的拜访团队，这些特殊的客户需要被赋予一些临时的身份来体验一定的功能操作。那么在部门的组织架构中加入这些人显然是不合适的，因为这些人只是临时设置者，不是企业员工；

　　其次，这些客户需要体验的功能操作往往跨越多个业务模块和产品线（比较复杂）。一般企业没有现成的固定角色满足客户要求的所有操作权限，所以需要为这些客户开通。临时角色，支持临时角色的最大权限选择空间；

　　(7）黑白名单

　　顾名思义，黑名单不能有任何权限，白名单可以有相应的权限。这需要根据业务需要进行特殊设置。

　　3. 权限管理（1） 权限管理

　　权限管理更多是从功能菜单、功能操作、数据参数三个不同粒度级别考虑。具体粒度取决于公司结构和团队规模。如果不是业务属性，则需要将权限控制到非常精细的级别。实际上，没有必要将权限的粒度拆分为具体的操作或按钮。毕竟后端产品的核心是业务管理平台，主要目标是辅助业务的管理和推广。

　　图像.jpeg

　　注：图片为某后端产品的部分截图，其中功能菜单页面、功能操作按钮和数据字段均可见。

　　(2）功能菜单权限

　　对于后端产品来说，为功能菜单划分用户权限，其实是一种比较粗粒度的管理方式。该模式下，用户一经授权，即可使用菜单栏下的所有数据查看权限和功能操作权限；

　　(3）函数操作权限

　　功能操作层的权限比功能菜单更深入。这种情况下，不同角色的用户可以进入同一个菜单页面的后台查看相同的数据字段信息，但可以进行不同的功能操作；

　　(4）数据字段权限

　　数据字段级别是更细粒度的拆分。它将实现不同角色的用户进入同一个菜单页面的后台时，可见的数据字段是不同的。比如销售人员进入销售绩效管理后台，可以看到自己的绩效提升数据，而财务人员看到的是业务工单的费用字段。这些字段共存于同一个菜单页面，但受到不同角色的限制。仅限许可。

　　(5）数据权限

　　数据是指系统中某些类型的需要获得操作权限的数据。比如也是*敏*感*词*，但是不同渠道的客户需要划分，分配给不同的管理者进行管理。例如，员工拥有编辑*敏*感*词*的权限，但未经许可，无法操作相应编辑的*敏*感*词*。

　　三.案例研究1.推广权限系统权限连接

　　以某促销活动的后台从无权限限制到访问用户角色权限管理系统为例，具体如下：

　　图像.jpeg

　　图像.jpeg

　　注：以上为某产品促销管理后台截图

　　2. 推广前后台访问权限系统

　　在促销活动后台接入权限系统之前，几乎所有系统权限都处于裸奔状态。所有业务线成员都可以查看后台的运营活动内容和运营结果数据，可以进行相对敏感的操作。这种情况显然存在一定的管理风险，所以后台系统需要接入权限管理系统，进行系统的管理和风险控制；

　　3. 推广后台连接权限系统时

　　在接入促销活动权限管理系统的过程中，需要对功能模块的权限元素进行拆解（到一定粒度）。因此，需要根据业务特点来判断需要拆分的粒度，无论是对功能菜单、功能操作还是数据。字段的级别，明确划分粒度后，权限管理系统可以根据粒度给不同的角色授予权限；

　　4. 推广后台接入权限系统后

　　推广接入权限管理系统后，当对应角色的用户再次登录后台时，后台首先会检查用户的角色是否具有功能模块的权限，以及操作权限和角色权限对应的数据字段。权限，验证结果经过服务器处理后会在产品端显示给用户。此时，同一用户在后台的可见和可执行操作可能与访问权限管理系统之前有很大不同。这就是基于用户角色的权限管理系统带来的变化。

　　四. 问答

　　1. 一个用户有多个角色。如果多个角色之间存在互斥关系怎么办？

　　如果已将用户添加到角色范围内，当将与当前角色具有互斥权限关系的角色添加到该用户时，系统会进行互斥判断，后续角色无法添加到该用户。成功;

　　2. 在业务开发过程中，如何保证不同角色之间权限的明确分离？

　　随着业务的快速发展，会不断增加不同的角色和更多的功能模块，这些角色和功能权限之间的关系会越来越混乱。这个时候，产品经理和业务方需要齐心协力，及时开会。针对业务的发展变化，及时快速梳理业务调整范围并做出相应的变更；

　　3. 用户权限管理系统的核心难点是早期产品设计吗？

　　用户权限管理系统最难的不是前期产品设计，而是后续运维，因为权限系统的结构往往不是随意改变的，而是随着业务角色的快速发展和功能模块，为了防止角色和功能权限之间的关系变得混乱，在建立新角色和分配权限时需要思路清晰，仔细调整。