目录
概述
一、ACL模型：访问控制列表
二、DAC模型：自主访问控制
三、MAC模型：强制访问控制
四、ABAC模型：基于属性的访问控制
五、RBAC，基于角色的权限访问控制
RBAC的深度拓展
1. RBAC0模型
2. RBAC1模型
3. RBAC2模型
4. RBAC3模型
RBAC 权限管理的在实际系统中的应用
1.用户管理
2.角色管理
1. 自动获得基础角色
2. 临时角色与失效时间
3. 虚拟角色
4. 黑白名单
3. 权限管理
1. 页面/菜单权限
2. 操作权限
3. 数据权限
4. 数据权限如何管控
用户管理系统权限设计中的更多实践细节
1.超级管理员
2.互斥角色如何处理
3.用户管理权限系统设计一定要简单清晰
4.无权提示页
六、TBAC模型：基于任务的访问控制
七、T-RBAC模型：基于任务和角色的访问控制模型
八、OBAC模型：基于对象的访问控制
九、UCON模型：使用控制( UsageControl:UCON) 模型
概述
软件系统的权限控制几乎是非常常见且必备的，这篇文章整理下常见的九种模型，几乎基本够你用了，主流的权限模型主要有以下9种：
1、ACL模型
访问控制列表
2、DAC模型
自主访问控制
3、MAC模型
强制访问控制
4、ABAC模型
基于属性的访问控制，更灵活复杂
5、RBAC模型
基于角色的权限访问控制，最常用
6、TBAC模型
基于任务和工作流的访问控制
7、T-RBAC模型
基于任务和角色的访问控制
8、OBAC模型
基于对象的访问控制
9、UCON模型
使用控制模型
一、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的缺点，在新增资源时容易维护。
原理：通过动态计算一个或一组属性是否满足某种机制来授权，是一种很灵活的权限模型，可以按需实现不同颗粒度的权限控制。这个模型在云系统中使用的比较多，比如 AWS，阿里云等。
考虑下面这些场景的权限控制：
授权某个人具体某本书的编辑权限 当一个文档的所属部门跟用户的部门相同时，用户可以访问这个文档 当用户是一个文档的拥有者并且文档的状态是草稿，用户可以编辑这个文档 早上九点前禁止 A 部门的人访问 B 系统 在除了上海以外的地方禁止以管理员身份访问 A 系统 用户对 2022-06-07 之前创建的订单有操作权限 可以发现上述的场景通过 RBAC模型 很难去实现，因为 RBAC模型 仅仅描述了用户可以做什么操作，但是操作的条件，以及操作的数据，RBAC模型 本身是没有这些限制的。但这恰恰是 ABAC模型 的长处，ABAC模型 的思想是基于用户、访问的数据的属性、以及各种环境因素去动态计算用户是否有权限进行操作。
在 ABAC模型 中，一个操作是否被允许是基于对象、资源、操作和环境信息共同动态计算决定的。
对象：对象是当前请求访问资源的用户。用户的属性包括 ID，个人资源，角色，部门和组织成员身份等 资源：资源是当前用户要访问的资产或对象，例如文件，数据，服务器，甚至 API 操作：操作是用户试图对资源进行的操作。常见的操作包括“读取”，“写入”，“编辑”，“复制”和“删除” 环境：环境是每个访问请求的上下文。环境属性包含访问的时间和位置，对象的设备，通信协议和加密强度等 在 ABAC模型 的决策语句的执行过程中，决策引擎会根据定义好的决策语句，结合对象、资源、操作、环境等因素动态计算出决策结果。每当发生访问请求时，ABAC模型 决策系统都会分析属性值是否与已建立的策略匹配。如果有匹配的策略，访问请求就会被通过。
例如：早上9:00，11:00期间A、B两个部门一起以考生的身份考试，下午14:00，17:00期间A、B两个部门相互阅卷。
缺点：规则复杂，不易看出主体与客体之间的关系，实现非常难，现在应用的很少。
五、RBAC，基于角色的权限访问控制
Role-Based Access Control，核心在于用户只和角色关联，而角色代表对了权限，是一系列权限的集合。
RBAC三要素：
用户：系统中所有的账户
角色：一系列权限的集合（如：管理员，开发者，审计管理员等）
权限：菜单，按钮，数据的增删改查等详细权限。
在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。
角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。
角色可依新的需求和系统的合并而赋予新的权限，而权限也可根据需要而从某角色中回收。角色与角色的关系同样也存在继承关系防止越权。
优点：便于角色划分，更灵活的授权管理；最小颗粒度授权；
以一个简单的场景（Gitlab 的权限系统）为例，用户系统中有 Admin、Maintainer、Operator 三种角色，这三种角色分别具备不同的权限，比如只有 Admin 具备创建代码仓库、删除代码仓库的权限，其他的角色都不具备。
我们授予某个用户「Admin」这个角色，他就具备了「创建代码仓库」和「删除代码仓库」这两个权限。
不直接给用户授权策略，是为了之后的扩展性考虑。比如存在多个用户拥有相同的权限，在分配的时候就要分别为这几个用户指定相同的权限，修改时也要为这几个用户的权限进行一一修改。有了角色后，我们只需要为该角色制定好权限后，给不同的用户分配不同的角色，后续只需要修改角色的权限，就能自动修改角色内所有用户的权限。
RBAC的深度拓展
RBAC模型可以分为：RBAC0、RBAC1、RBAC2、RBAC3 四个阶段，一般公司使用RBAC0的模型就可以。另外，RBAC0相当于底层逻辑，后三者都是在RBAC0模型上的拔高。
简单介绍下这四个RBAC模型：
1. RBAC0模型