权限
权限控制（AC）
即 Access Control，一句话介绍：「谁（Who）可以对什么资源（What）进行什么操作（How）」
什么是资源
资源是一个非常宽泛的概念，任何需要控制的实体都可以定义为资源，如：页面、链接、接口、数据
操作有什么
读写，或者更详细一些：增删改查
什么是权限
对某种资源的某个操作，称为权限
常用的权限模型
- ACL(Access Control List)(访问控制列表)
- DAC(Discretionary Access Control)(自主访问控制)
- MAC(Mandatory Access Control)(强制访问控制)
- RBAC(Role-Based Access Control)(基于角色的访问控制)
- ABAC(Attribute-Based Access Control)(基于属性的访问控制)
ACL(访问控制列表)
ACL是最早也是最基本的一种访问控制机制，它是用来描述用户和权限之间关系的数据列表。
它的原理非常简单：每一项资源，都配有一个列表，这个列表记录的就是哪些用户可以对这项资源执行CRUD等操作。当试图访问这项资源时，会首先检查这个列表中是否有关于当前用户的访问权限，从而确定当前用户可否执行相应的操作。
由于ACL的简单性，使得它几乎不需要任何基础设施就可以完成访问控制。但同时它的缺点也是很明显的，由于需要维护大量的访问权限列表
为了解决这些问题，便有了对ACL设计的改进，相同权限的用户放到同一个分组里，分组与权限挂钩，不再是用户直接与权限挂钩。以及后来出现的RBAC(基于角色的访问控制)，角色与分组也是差不多的概念，角色直接与权限挂钩，用户再与角色进行关联。
DAC(自主访问控制)
拥有对象权限的用户，又可以将该对象的权限分配给其他用户，所以称之为“自主（Discretionary）”控制。
DAC是传统的UNIX访问控制模型，也是Windows文件系统的访问控制模型。
MAC(强制访问控制)
MAC是为了弥补DAC权限控制过于分散的问题而诞生的，用户不能改变自身和资源对象的安全级别，只有系统管理员或管理程序才能 控制资源对象和用户的级别。
MAC非常适合机密机构或者其他等级观念强烈的行业
RBAC(基于角色的访问控制)
RBAC 96 模型族 为目前最为主流的理论模型，由美国 George Mason（乔治梅森）大学信息安全技术实验室（LIST）提出。
RBAC就是在用户与权限之间引入了角色的概念。用户与角色之间做关联，权限列表维护的是角色与功能的关系。
RBAC 0 - 最基本的 RBAC 模型
【用户 - 角色】和【角色 - 权限】的对应关系都可以是 1:N 或者 1:1，视具体情况而定
RBAC 1 - 限制了角色的 RBAC 模型
解决了角色继承问题
RBAC 2 - 基于 RBAC0 增加了角色、和权限本身限制的 RBAC 模型
静态职责分离 SSD
- 互斥角色限制：角色间存在互斥关系，用户只能选择其中一个角色；
- 基数限制：一个用户拥有的角色数量是有上限的，一个角色对应的权限数量也是有上限的；
- 先决条件限制：角色之间存在前置依赖关系，用户必须先获得低级角色才能拥有高级角色；
动态职责分离 DSD
- 如果用户拥有两个及以上角色，则同一时间段内有且只有一个角色可以生效
ABAC(基于属性的权限控制)
出现背景
如果在复杂的权限管控场景中，RBAC显得有些力不从心，比如说：
- 用户在晚上不能访问这个系统，但是白天可以
- 用户只能在内网对订单具备修改权限，而在外网就只有查看权限
- 用户对2021-03-19日之前创建的订单有操作权限
- 用户只能在深圳进行查看订单，而去了国外就不可以
- 用户在公司内部可以访问所有数据，但是在外部就只能访问公开数据
我们很容易就发现，RBAC仅仅描述了用户可以做什么操作，但是操作的条件，以及操作的数据，模型本身是没有这些限制的
使用场景
A这个模型在如今的云系统中使用的比较多，比如AWS，阿里云，腾讯云，京东云等，它们都是用ABAC来管控IaaS以及PaaS的资源，曾经K8s也使用过这个模型来进行权限管控。
设计本质
我们从之前的文章中能够明白，ABAC设计的目的是为了能够满足控制请求者在某些条件下是否对请求数据具备某个操作（API） 的能力，目前来看，ABAC还暂时没有什么标准建模（policy不是由实体组成），一般都是policy的语法设计，这个指的就是用一个json或者一个xml来描述一个policy ，这个policy会和用户或者其他实体绑定，然后这个用户或者是实体就具备了在某些条件下对某些数据的操作能力。
参考
\
