用户管理是每个产品必不可少的管理后端。 最基本的用户管理只需要添加和删除账户两个功能。 但是，一旦用户数量开始增多，权限变得有点复杂，我们就需要认真思考用户管理权限的逻辑了。 避免日后用户突然增加时埋下无法解决的深坑。
1.基础权限管理系统——简单清晰但无法处理复杂需求
基础权限系统的设计一般是从“用户-权限”两个维度出发。 管理员需要为每个用户单独定义权限。
上图为synology服务器权限设置背景。 每次向服务器添加新的访问帐户时，管理员都需要配置权限表。 如果系统中的用户数量在几十个左右，权限变化也不是太多，这种“用户-权限”的权限管理逻辑简单、清晰、易用。 但当系统中的用户数量开始增加，达到数千或数万时，这种管理方法的局限性就暴露出来了。
2.基于RBAC模型的权限设计——引入角色概念
当用户数量达到一定规模，管理员想要修改一组用户的权限时，在“用户-权限”模型中手动完成几乎是不可能的。 这时我们就引入了用户之间的角色和权限的概念。 将用户和权限的直接对应关系改为用户关联的角色，角色关联的权限授予用户权限，即“用户-角色-权限”。
引入角色的好处是将抽象权限可视化。 我们只需要思考应该给每个角色授予哪些权限，然后将对应的用户指向该角色即可完成账户授权。
1.RBAC权限模型概述
“用户-角色-权限”的权限逻辑就是业界常用的RBAC（基于角色的访问控制）权限模型。 其核心是引入角色的概念，以角色为中介，使用户和权限配置更加灵活。
2、RBAC权限模型的优点
（1）将抽象权限具体化，让您在分配权限时不再考虑抽象问题。
例如：新入职的初级销售人员小张要求管理员开户。 管理员无需担心是否授予小张“查看部门销售”的权限。 他只需要将小张的账号指向“初级销售”的角色即可。 ，这个角色有什么样的权限已经定义好了。
(2)批量调整权限
例如：有时公司推出新的业务模块时，管理员需要授权某个属性的用户查看该模块的数据。 例如，如果公司推出新的直播功能，运营团队需要能够运营直播后端。 此时管理员只需要修改“操作”角色的权限即可修改所有操作组成员的账户权限。
3、RBAC权限模型的多种应用场景
RBAC权限模型清晰、简单的管理逻辑在实际应用中得到了很好的体现。 接下来我们通过具体的例子来理解这个权限架构的逻辑思维。
(1)RBAC基本类型：“用户-角色-权限”
RBAC的基础仅包括“用户-角色-权限”的概念。 在该模型中，用户与角色、角色与权限之间存在多对多的关系。 用户的权限是其所属的所有角色的权限的总和。 对于大多数产品的用户管理来说地图场景，使用基础版的RBAC就可以完成良好的权限控制。
例如：公司小王是财务部出纳，同时负责货物的入库、保管和盘点工作。 那么我们首先创建两个角色，财务部门的出纳和仓储部门的仓管员。 角色非常具体，管理员可以轻松授予角色权限。 然后将小王的账号给这两个身份，小王就会在系统中获得相应的权限。 权限模型逻辑简单明了。
（2）进入“级别”概念的RBAC模型——“用户-角色【级别】-权限”
引入了“级别”的概念，即角色内部存在上下级关系。 每个级别都有不同的权限。 高级别权限向下兼容低级别权限。 即同一角色内，高级权限包含所有低级权限。 引入“级别”概念，可以更细粒度地分配权限。
例如：并非属于同一部门的每个人都可以查看所有部门数据。 所以这个时候我们引入了“级别”的概念。 部门负责人可以查看所有部门的数据，各部门组长只能查看本组的数据，组员只能查看自己的数据。
(3)“用户-角色[级别]-权限[限制]”
在权限控制上，为了系统安全和工作流程逻辑流畅，我们不仅对账户进行权限授予，还对账户进行系统级别的限制。
有时不同角色在同一操作界面上可能会出现数据或操作冲突。 在这种情况下，我们需要限制用户在同一时间只能使用一种身份。 这样可以避免很多不必要的麻烦。
3、RBAC权限管理在实际系统中的应用
RBAC权限模型由三部分组成，即用户管理、角色管理、权限管理。 用户管理按照企业架构或者业务线架构来划分。 这些结构本身都比较清晰，具有非常好的扩展性和可读性。 角色管理必须在深入理解业务逻辑之后进行设计。 一般以各部门的真实角色为基础，然后根据业务逻辑进行扩展。 权限管理是前两种管理的强化。 太详细了，就太碎片化了，太粗糙了，又不够安全。 这里我们需要根据经验和实际情况来设计。
1.用户管理
用户管理中的用户是企业中的每一位员工。 他们有自己的组织结构。 我们可以直接以企业部门架构或者业务线架构为线索来构建用户管理系统。
2. 角色管理
在设计系统角色时，我们应该深入了解公司架构和业务架构，然后根据需要设计角色以及角色内的层级。 一般来说，角色相对于用户来说是固定的。 每个角色都有自己明确的权限和限制。 这些权限是在系统设计时就确定的，以后不会轻易更改。
(1)自动获取基本字符
当员工加入某个部门时rbac角色权限表设计，该员工的账号应自动添加到该部门对应的基础角色中rbac角色权限表设计，并拥有相应的基础权限。 这样做是为了保证系统安全，减少管理员大量的手动操作。 让新员工能够快速使用系统，提高工作效率。
(2) 临时角色及失效时间
公司的业务有时需要外部的支持。 他们不是公司的员工，仅在一定时期内为公司提供支持。 此时我们需要设置临时角色来应对可能跨多个部门协作的临时员工。
如果公司安全级别较高，此类账户默认会有固定的过期时间。 一旦达到过期时间，需要再次审核后才能重新开放。 避免因流程不完善而导致临时账户被遗忘在系统中，造成安全风险。
(3)虚拟角色
部门角色中的级别可以授权同级别的员工拥有相同的权限。 但部分员工因工作原因需要使用超出角色级别的权限。 同一级别的不同员工需要使用不同的权限。 对于这种超越角色级别的合理权限授予，我们可以设置虚拟角色。 该虚拟角色整合了工作所需的所有权限，然后将其分配给特定员工。 这样，无需调整组织架构和相应角色，也能满足工作中特殊情况的权限要求。
(4)黑白名单
3.权限管理
权限管理一般受到三个方面的限制。 页面/菜单权限、操作权限、数据权限。
(1)页面/菜单权限
对于没有权限操作的用户，直接隐藏相应的页面入口或菜单选项。 这种方法简单、快速、直接，对于一些对安全性不是很敏感的权限来说非常高效。
（二）操作权限
操作权限通常是指不同用户是否可以对同一组数据进行添加、删除、修改、查看等操作。 对于某些用户来说，它是只读浏览数据，而对于某些用户来说，它是可编辑数据。
(3) 数据权限
对于安全性要求较高的权限管理，仅从前端限制隐藏菜单和编辑按钮是不够的。 您还需要对数据接口施加限制。 如果用户试图通过非法手段编辑不属于其权限的数据，服务器将识别、记录并限制访问。
4、用户管理系统权限设计中更多实用细节
1.超级管理员
超级管理员是用于启动系统和配置系统的帐户。 配置系统并创建管理员后，应隐藏此帐户。 超级管理员账户拥有系统中的所有权限，可以穿梭和查看各部门的数据。 如果使用不当，会给系统管理带来安全风险。
2. 如何处理互斥角色
当已经对用户有用的角色和即将添加的角色互斥时，在添加新角色时，应提示管理员由于角色互斥而无法添加新角色。 如果需要添加，必须先撤销之前的角色，然后再添加新的角色。
3、用户管理权限系统的设计必须简单明了
在设计权限系统时，一定要理清思路，一切从简，尽可能不要添加多余的角色和权限逻辑。 因为随着公司业务的扩大，权限和角色也会增加。 如果最初的设计思路不严谨，随着业务的扩展，权限体系就会变得无限混乱。 这个时候再去梳理权限就来不及了。 所以，最初的设计一定要清晰、简单、明了，才能避免日后带来很多不必要的麻烦。
4.无权限提示页面
有时员工A会直接将自己正在处理的页面分享给员工B，但员工B可能没有查看权限。 这时候我们就应该考虑在这里添加一个“未经授权的提示页面”数据报告，避免出现粗鲁的404页面，让员工B认为系统出现了错误。
常用的权限系统模型
实际开发中，可能会有多组织权限、多产品线权限、职位权限、应用管理权限等需求，只要明白原理，我认为不会有什么大问题，只是举一例。
