简单了解常见的权限系统
1. ACL（Access Control List）模型：列表控制访问，常用于文件系统，用户访问某文件时，通过文件来判断用户的权限，是读、写、禁止访问 这里可以把系统的对象，比如是某个文件拟人化，它作为一个文件处于一个固定的位置，有A、B、C，共3个人来访问这个文件；对于这个文件来说，它需要“记住”这个系统上所有用户是否可以访问它，是否可以进行读写操作；而对于整个系统来说，可能有很多个文件，每个文件都需要记住所有的人能对自己进行什么操作。
通过文件来查看所有用户权限是可以的，反过来，以用户为一个列表来说明这个人的文件权限也是可行的，如“文件权限矩阵表”里的“用户A”，他目前可以看见的权限是文件2的查看权限+文件3的编辑权限，那么将上表按用户进行汇总也就是“用户权限列表”
如果这里有一个仅使用了ACL模型的权限系统，供100人的公司来使用，系统里又有100份文件，那么这100个文件都需要单独对这100人进行权限的设置，如果发生了人员的增减，那么所有的权限都需要重新再设置一遍。
所以ACL模型还有一个升级的版本，在用户和权限之间增加一个用户组，处于一个用户组的人，有着相同的权限，一个用户也可以处于多个用户组内，这里的用户组和权限之间有着较强的关联性，与RBAC不同。
2. DAC（Discretionary Access Control）模型：自主访问控制，基于ALC的优化版本，可以理解为主要多了“分享权限“的权限和其他一些规则，如：用户A可以把自己拥有的全部或一部分权限授权给另一用户B。这里举一个不太恰当的例子，用户A拥有在线文档1的编辑、查看权限，他可以将在线文档1分享给用户B，并给用户B查看+编辑权限（或仅查看权限），这在日常的协作中是很常见的。
3. MAC（Mandatory Access Control）模型：强制访问控制，这是一个基于DAC模型的一个升级版本。 拿到文件系统里说，用户和文件需要双向验证是否有权限访问，甚至可以严格到这个文件每次只允许1个用户访问；系统可以记录某个用户的拥有的权限，分别是由哪些用户授权的，而且有些特定的权限，禁止用户间的互相授权；对于权限的发放，需要专门的管理员或拥有管理权限的人才能进行分配。 一般存在于对于保密要求非常严格的系统里，可以理解为给用户和文件分别打上各类级别的标签，不同标签的用户可以看到的文件范围是不同的，同时需要访问时，还需要特定的密码才能访问。
3.1. 用户：普通、低、中、高级别
3.2. 对象：绝密、机密、保密、公开
但事无绝对，目前很多系统里都由超级管理员或管理员来进行分配权限，这里面有MAC模型的影子。
在ACL模型里，还可以直接将权限组成一个集合可以作为权限组，或将一些用户组成用户组，权限组或用户组就是充当一个抽象的”角色“，和RBAC模型有些相似
4. RBAC(Role-based Access Control)模型：基于角色的访问控制模型，这个是目前使用比较广泛的一个权限模型，它在用户和权限中间添加了一个对象，称作“角色”，权限、角色和用户是分别独立存在的，我根据个人理解和查阅的资料做一个定义：
● 用户：访问系统的人
● 角色：一些相关联权限的集合
● 权限：能够执行某种操作的许可
按这三个概念举一些例子：用户可以是登录用户、未登录用户（游客）···；角色可以是管理员、超级管理员、某些模块的管理员···；权限可以大致分为设备权限（摄像头、麦克风···）、应用权限（访问、安装、删除···）、文件权限（增删改查···），在这个概念下：
● 权限是有很多个的，不过权限是需要区分颗粒度的，有些简单的系统权限可以是粗粒度的，把一整个页面作为一个权限；也可以是细粒度的，详细到某个按钮，某个数据的权限。
● 角色也是有很多个的，根据业务的需要，可以提前设置一些虚拟的人在系统里，这些虚拟人拥有一部分权限。
● 用户也可能是多个的（作为系统的使用人员们）
然后将权限→角色→用户，按照多对多的形式进行授权，RBAC经过了多个版本的优化，可以在NIST网站里查到描述
RBAC0：角色、权限、用户分开，一个基本模型
RBAC1：支持子角色，角色权限继承
RBAC2：各种关联角色的限制
SSD(Static Separation of Duty)模型：静态职责分离，赋予角色时限制（互斥角色：不能同时拥有某两个角色；用户拥有角色限制：一个用户最多拥有几个角色；先决条件限制：想要获得某权限，需要先获得某权限）
DSD(Dynamic Separation of Duty)：动态职责分离，用户拥有多个角色，一次会话中，不能同时使用有冲突的角色。
RBAC3：包含了0、1、2所有规则，属于RBAC模型的完全体
方便理解，这里需要举一些例子
RBAC1里的角色权限继承：相当于用户A是部门主管，他可以将自己系统内拥有的权限分配给自己部门的其他人；又或者用户B离职了，可以将用户B拥有的权限直接都给用户C，方便交接。
RBAC2里的角色限制：用户A不能又有采购模块权限又有财务模块权限；用户B同时只能被赋予固定数量的角色；用户C需要获得某角色的权限，需要先申请普通角色，再申请高一级别的角色；用户D拥有两个互斥角色AB，登陆时选择A，此时想要切换成B，需要“退出”，重新“登陆”为B。
5. ABAC（Attribute-Based Access Control）模型：基于属性的权限控制，用户访问某对象时，判断多个属性是否都匹配，仅从权限属性的观点来考虑，ACL和RBAC都是在考虑不同的属性而已，所有ACL和RBAC都可以当作ABAC的特殊情况 权限是属性可以大致分为：环境属性、用户属性、资源属性、操作属性
比如在一个系统里，有用户A、B、C，一共3个人，需要对使用设备进行限制，不同的部门的员工需要看见不同的页面，对于各种列表或文件甚至按钮权限也有单独的要求。这时候可以使用ABAC的权限模型，不光对页面或模块可以设置权限，对于单独的一些细颗粒的权限也可以灵活设置，这样对于权限的变动和修改来说更为灵活。
6. PBAC（Policy-Based Access Control）模型：基于策略的访问控制
PBAC和ABAC十分相似的，2者其实都是属性+策略来控制权限，只是ABAC更注重权限，PBAC更注重于策略，下面按自然语言举2个例子：
● 用户A使用window设备，在连接公司网络的情况下，可以在系统里某个模块里，自己上传的文件，进行查看和编辑操作。
● 用户B使用手机，在早上8点到晚上22点的时间段，可以在某系统的某模块进行添加、编辑、删除的操作
7. RAdAC(Risk-Adaptive Access Control）模型：风险适应性访问控制
它结合了有关个人或机器可信度的信息、有关公司It基础设施的信息和环境风险因素，并使用所有这些信息来创建一个总体的可量化风险度量，这个判断条件可以包括基于从其他来源收集的数据，组织面临的当前威胁级别的信息等。
我个人理解：RAdAC是根据系统内+系统外的情况灵活自动的配置实时的权限，使整个系统看起来更加的智能，减少的权限分配的操作，但是对于系统的信息收集要求也很高，对于系统收集到信息的及时性和可信度要求也很高，这个模型在ai技术比较成熟后可能会实现的更好。
实际在使用的过程中，我们的各种系统都不太会严格要求各种模型来使用，都是根据业务的要求和发展进行权限的设置，暂时还没有一个完美的权限系统，只有更适合当前业务的权限系统，我们在很多系统的权限设计里都可以看见上述一个或多个模型的影子。
