:::info
权限分配问题，基本集中在企业后台管理项目中，也就是B端项目
衡量一个B端系统好坏的重要标准是：它的权限是否足够细致，拓展性是否很强
权限管理是系统的基础，良好的权限功能设计可使系统稳定发展，避免后续由于业务变化导致权限功能大改甚至推倒重做的情况发生
:::
前言
权限的重要性：
- 安全性：防止误操作，人为破环，数据泄露。
- 责权明确：明确不同用户的不同权限和责任；通过系统权限，让不同系统权限的用户可以查看不同的系统；通过菜单，让拥有不同菜单权限让不同用户可以查看不同的页面；通按钮权限（接口权限），让拥有不同按钮权限的人可以操作不同的按钮。这是从操作层面保证数据的安全性。
- 数据隔离：不同的数据权限能看到及操作的数据不同，从可视化层面保证数据的让不同角色看到，从而保证数据的安全性
1 权限控制类型
1.1 功能权限-对象
对象指赋予权限的 组织、角色、岗位、人
1.1.1 人
1.1.2 角色
角色适用场景：如后台管理系统，财务的角色只能看财务相关功能，营销的角色只能看活动相关功能。
1.1.3 组织
组织适用场景：例如，某公司有华东、华南、华西、华北、华中五大区域，限制华东区域不能查看华南区域的战略资料，华东区域的A门店和B门店的策略不能互相查看。
1.1.4 岗位
岗位适用场景：如运营的岗位默认可以查看订单的模块和数据。
1.2 功能权限-级别
级别也称账号安全级别，一般通过0-100的数字控制用户账号的功能权限，通常设置的数值越大，权限范围越大。
适用场景：比如创建的正式员工默认安全级别为10，外包的NCC员工默认为0，则当某个功能开放给所有人，并且这个功能仅限正式员工可操作时，可通过限制此功能的安全级别（调整为10）控制只能正式员工查看。
功能组合：安全级别还可与对象（组织、角色、岗位、人）组合，达到更精细化控制权限的目的，比如安全级别与部门相搭配，可控制此部门下特定的安全范围的人可以操作功能。
1.3 数据权限-时间
权限中的时间是指数据到达某个时间节点后，是否要继续给用户同步。
应用场景：比如外部审计人员需要查看某一年度的数据时，只需开放对应时间的数据给他们，这么做就可以保证数据的安全，不会遭到泄露。
1.4 数据权限-区域
权限中的区域也可以理解为范围，是指某一区间的值。
应用场景：比如门店设备的维护人员只需查看他所负责的区域的设备即可，即网格化管理。
2 系统权限扩展
2.1 菜单权限
对于没有权限操作的用户，直接隐藏对应的页面入口或菜单选项。这种方法简单快捷直接，对于一些安全不太敏感的权限，使用这种方式非常高效。
- 前端菜单权限，指用户层面操作的菜单页面。
- 后端菜单权限，系统管理员、系统运维人员层面操作的菜单页面。
2.2 按钮权限
具体到某个元素的权限，颗粒度更小的划分。通常指页面内的增删改查按钮2.3 字段权限
具体到业务数据的某些字段。比如有人拥有修改权限，但是没有特定字段的修改权限2.4 黑白名单
脱离基础权限的一些人。
白名单：某些用户自身不拥有某部门的顶级角色，但处于业务需求，需要给他角色外的高级权限，那么我们可以设计限制范围的白名单，将需要的用户添加进去即可。
在安全流程中，我们仅需要对白名单设计安全流程，即可审核在白名单中的特殊用户，做到监控拥有特殊权限的用户，减少安全隐患。
黑名单：比较常见的黑名单场景是某些犯了错误的员工，虽然在职，但已经不能给他们任何公司权限了。这种既不能取消角色关联，也不能完全停用账号的情况，可以设置黑名单，让此类用户可以登录账号，查看基本信息，但大多数关键权限已经被黑名单限制。
2.5 虚拟角色
部门角色中的等级，可以授权同等级的员工拥有相同的权限，但某些员工因工作原因，需要调用角色等级之外的权限，相同等级不同员工需要使用的权限还不相同。这种超出角色等级又合理的权限授予，我们可以设置虚拟角色。
这一虚拟角色可集成这一工作所需的所有权限，然后将它赋予具体的员工即可。这样即不用调整组织架构和对应的角色，也可以满足工作中特殊情况的权限需求。
2.6 权限转移、继承
员工从原部门调走，离职等情况的发生，当有新员工接手他的工作时，则需要权限转移的功能。
3 常见的五种权限模型
主流的权限模型主要分为以下五种：
- ACL模型：访问控制列表
- DAC模型：自主访问控制
- MAC模型：强制访问控制
- ABAC模型：基于属性的访问控制
- RBAC模型：基于角色的权限访问控制
ACL模型：访问控制列表
Access Control List，ACL是最早的、最基本的一种访问控制机制，是基于客体进行控制的模型，在其他模型中也有ACL的身影。为了解决相同权限的用户挨个配置的问题，后来也采用了用户组的方式。
原理：每一个客体都有一个列表，列表中记录的是哪些主体可以对这个客体做哪些行为，非常简单。
例如：当用户A要对一篇文章进行编辑时，ACL会先检查一下文章编辑功能的控制列表中有没有用户A，有就可以编辑，无则不能编辑。再例如：不同等级的会员在产品中可使用的功能范围不同。
缺点：当主体的数量较多时，配置和维护工作就会成本大、易出错。
DAC模型：自主访问控制
Discretionary Access Control，DAC是ACL的一种拓展。
原理：在ACL模型的基础上，允许主体可以将自己拥有的权限自主地授予其他主体，所以权限可以任意传递。
例如：常见于文件系统，LINUX，UNIX、WindowsNT版本的操作系统都提供DAC的支持。
缺点：对权限控制比较分散，例如无法简单地将一组文件设置统一的权限开放给指定的一群用户。主体的权限太大，无意间就可能泄露信息。
MAC模型：强制访问控制
Mandatory Access Control，MAC模型中主要的是双向验证机制。常见于机密机构或者其他等级观念强烈的行业，如军用和市政安全领域的软件。
原理：主体有一个权限标识，客体也有一个权限标识，而主体能否对该客体进行操作取决于双方的权限标识的关系。
例如：将军分为上将>中将>少将，军事文件保密等级分为绝密>机密>秘密，规定不同军衔仅能访问不同保密等级的文件，如少将只能访问秘密文件；当某一账号访问某一文件时，系统会验证账号的军衔，也验证文件的保密等级，当军衔和保密等级相对应时才可以访问。
缺点：控制太严格，实现工作量大，缺乏灵活性。
ABAC模型：基于属性的访问控制
Attribute-Based Access Control，能很好地解决RBAC的缺点，在新增资源时容易维护。
原理：通过动态计算一个或一组属性是否满足某种机制来授权，是一种很灵活的权限模型，可以按需实现不同颗粒度的权限控制。
属性通常有四类：
- 主体属性，如用户年龄、性别等；
- 客体属性，如一篇文章等；
- 环境属性，即空间限制、时间限制、频度限制；
- 操作属性，即行为类型，如读写、只读等。
例如：早上9:00，11:00期间A、B两个部门一起以考生的身份考试，下午14:00，17:00期间A、B两个部门相互阅卷。
缺点：规则复杂，不易看出主体与客体之间的关系，实现非常难，现在应用的很少。
RABC模型：基于角色的权限访问控制
现在主流软件都在使用的模型，具体信息如下
3 代码层面权限设计思路
3.1 后端设计
目前比较通用的就是 RABC (Role-Based Access Control) 设计模式，核心在于用户只和角色关联，而角色代表权限，是一系列权限的集合。
RBAC三要素：用户、角色、权限。
- 用户：系统中所有的账户
- 角色：一系列权限的集合（如：管理员，开发者，审计管理员等）
- 权限：菜单，按钮，数据的增删改查等详细权限。
在 RBAC 中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。
角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。
角色可依新的需求和系统的合并而赋予新的权限，而权限也可根据需要而从某角色中回收。角色与角色的关系同样也存在继承关系防止越权。
优点：
- 便于角色划分；
- 更灵活的授权管理；
- 最小颗粒度授权；
- 便于职责分离；
- 便于客体分类；
缺点：
- 没有提供操作顺序的控制机制，这一缺陷使RBAC模型很难适应那些对操作顺序有严格要求的系统。例如，公司采购流程就没有办法用 RBAC 模型授权控制采购过程中每一个流程中应该怎么样授权。
RBAC模型可以分为：RBAC0、RBAC1、RBAC2、RBAC3 四个阶段，一般公司使用 RBAC0 的模型就可以。另外，RBAC0相当于底层逻辑，后三者都是在RBAC0模型上的增量。
3.1.1 RBAC0模型
基本模型 RBAC0（Core RBAC）
用户和角色、角色和权限多对多关系。
简单来说就是一个用户拥有多个角色，一个角色可以被多个用户拥有，这是用户和角色的多对多关系；同样的，角色和权限也是如此。
3.1.2 RBAC1模型
角色分层模型 RBAC1（Hierarchal RBAC）
相对于RBAC0模型，增加了角色分级的逻辑，类似于树形结构，下一节点继承上一节点的所有权限。
3.1.3 RBAC2模型
角色限制模型 RBAC2（Constraint RBAC
基于RBAC0模型，对角色增加了更多约束条件。如角色互斥、基数限制、先决条件约束、动态职责分离。
- 角色互斥，比较经典的案例是财务系统中出纳不得兼管稽核，那么在赋予财务系统操作人员角色时，同一个操作员不能同时拥有出纳和稽核两个角色。
- 基数限制，一个用户拥有的角色数量是有限的，一个角色拥有的可配置用户数量也是有限的。例如：一个角色专门为公司 CEO 创建的，最后发现公司有 10 个人拥有 CEO 角色，一个公司有 10 个 CEO？这就是对角色数量的限制，它指的是有多少用户能拥有这个角色。
- 先决条件约束：用户想要获得高级角色，首先必须拥有低级角色。
- 动态职责分离DSD(Dynamic Separation of Duty)。可以动态的约束用户拥有的角色，例如一个用户可以拥有两个角色，但是运行时只能激活一个角色。
RBAC2 模型主要是为了增加角色赋予的限制条件，这也符合权限系统的目标：权责明确，系统使用安全、保密。
例如：iconfont 和蓝湖的用户与角色就采用了约束的概念，超级管理员只允许只有一个。
3.1.4 RBAC3模型
统一模型 RBAC3（Combines RBAC）
同样是基于RBAC0模型，但是综合了RBAC1和RBAC2的所有特点，包含继承和约束。
其中涉及到的概念有用户组、组织、职位。
1. 用户组平台用户多，角色类型增多，有一部分人具有相同的属性。比如生产部的所有员工等，如果直接给这些用户分配角色，就会增加管理员的工作量。如果给这些用户分组，并给用户组分配角色，用户组里的每个用户都具有用户组下的角色。如果用户退出用户组，就撤销用户组下的角色，这样就大大减少了管理员的工作量，无需管理员手动管理角色。用户组又分为具有上下级关系的用户组、普通用户组。具有上下级关系的用户组，和部门、职位关联起来。按照部门和职位对用户进行分组。普通用户组，没有上下级没关系，和部门职位也没有关系。纯粹地对用户进行分组。
2. 组织对于组织结构复杂的公司，可以把组织架构和角色关联起来。一旦把某个人加入某个组织，该用户就会拥有该组织下的所有角色。
Authing就是基于 RBAC3，进行了定制化改进的授权模型。
3.2 前端设计
3.2.1 前端路由权限
在路由守卫中获取用户信息，获取角色值，利用 router.addRoutes 实现，根据用户权限，加载不同的路由表访问不同的页面。
对于菜单的权限，可封装成指令，进行权限控制。
3.2.2 后端路由权限
在路由守卫中获取用户信息包含后端路由表信息、菜单信息等，动态加载。
4 权限设计中的更多实践细节
4.1 超级管理员
超级管理员是用来启动系统，配置系统的账号。这个账号应该在配置好系统，创建管理员之后被隐藏起来。超级管理员账号拥有系统中全部权限，可穿梭查看各部门数据，如果使用不恰当，是系统管理的安全隐患。
4.2 互斥角色如何处理
当用户已经有用的角色和即将添加的角色互相互斥时，应该在添加新角色时，提示管理员因角色互斥的原因，无法进行新角色添加。如需添加，要先撤销掉前一个角色，再添加新角色。
4.3 无权提示页
有时员工 A 会直接给员工 B 分享他当下正在操作的页面，但有可能员工 B 无权查看。此时我们应该在这里考虑添加「无权提示页」，避免粗暴的 404 页面让员工 B 以为是系统出错了。
4.4 用户管理权限系统设计一定要简单清晰
在设计权限系统之处，一定要理清思路，一切从简，能不增加的多余角色和权限逻辑，就一定不要增加。因为随着公司业务的扩大，权限和角色也会随之增多，如果初期设计思路不严谨，那么权限系统会随着业务的扩大而无限混乱下去，此时再来整理权限，已经太晚了。所以初期设计就一定要条理清晰，简单明了，能避免后续非常多不必要的麻烦。
参考文献：
【1】技术详解 | 使用 RBAC 让你的访问管理更容易https://www.authing.cn/blog/427
