ACL 访问控制列表
规定 资源可以被哪些 主体进行哪些 操作
场景：部门隔离 适用资源：客户页面、人事页面
在ACL权限模型下，权限管理是围绕资源来设定的。我们可以对不同部门的页面设定可以访问的用户。配置形式如下：
ACL配置表 资源: 客户页面 主体: 销售部（组） 操作：增删改查 主体: 王总（用户） 操作: 增删改查 资源: 人事页面 主体: 王总（组） 操作: 增删改查
注：主体可以是用户，也可以是组。
在维护性上，一般在粗粒度和相对静态的情况下，比较容易维护。
在细粒度情况下，比如将不同的客户视为不同的资源，1000个客户就需要配置1000张ACL表。如果1000个客户的权限配置是有规律的，那么就要对每种资源做相同的操作；如果权限配置是无规律的，那么ACL不妨也是一种恰当的解决方案。
在动态情况下，权限经常变动，每添加一名员工，都需要配置所有他需要访问的资源，这在频繁变动的大型系统里，也是很难维护的。
在一些情况下，ACL也可应用于细粒度场景，接下来将介绍两种ACL的拓展。
DAC 自主访问控制
规定 资源可以被哪些 主体进行哪些 操作 同时， 主体可以将 资源、 操作的权限，授予其他 主体
场景：文件系统 适用资源：人事培训文档
DAC是ACL的一种实现，强调灵活性。纯粹的ACL，权限由中心管理员统一分配，缺乏灵活性。为了加强灵活性，在ACL的基础上，DAC模型将授权的权力下放，允许拥有权限的用户，可以自主地将权限授予其他用户。
比如，在纯粹ACL模型下，每次新人培训，人事总监都要通知IT部，将培训文档的访问权限授予新人。在DAC模型下，人事总监只需将文档的访问权限授予人事专员。之后，每次新人培训，由人事专员将文档的访问权限授予不同的新人。
MAC 强制访问控制
a. 规定 资源可以被哪些 类别的主体进行哪些 操作 b. 规定 主体可以对哪些 等级的资源进行哪些 操作 当一个操作，同时满足a与b时，允许操作。
场景：保密系统 适用资源：机密档案
MAC是ACL的另一种实现，强调安全性。MAC会在系统中，对资源与主体，都划分类别与等级。比如，等级分为：秘密级、机密级、绝密级；类别分为：军事人员、财务人员、行政人员。
比如，一份机密级的财务档案，可以确保只有主体的等级是机密级，且是财务人员才能访问。如果是机密级的行政人员就无法访问。
资源配置表 资源: 财务文档 主体: 财务人员 等级：机密级 操作：查看 主体配置表 主体: 李女士 类别: 财务人员 等级：机密级
所以，MAC的优势就是实现资源与主体的双重验证，确保资源的交叉隔离，提高安全性。
RBAC 基于角色的访问控制
a. 规定 角色可以对哪些 资源进行哪些 操作 b. 规定 主体拥有哪些 角色 当一个操作，同时满足a与b时，允许操作。
场景：企业数据 适用资源：客户信息
RBAC的思想，来源于现实世界的企业结构。比如，销售角色，拥有查看客户信息的权限。当一个销售人员小王入职了，可以把销售角色赋予小王，那么小王就拥有了查看客户的权限。这种方式，避免了ACL模型下，每次新人入职，需要逐个配置资源表的情况。同样，权限变动也变得很方便，只要修改角色，即可实现多用户的权限修改。
权限表 名称：创建客户 资源: 客户信息 操作：创建 名称：删除客户 资源: 客户信息 操作：删除 名称：查看客户 资源: 客户信息 操作：查看 名称：修改客户 资源: 客户信息 操作：修改
角色表 名称：销售角色 权限: 创建客户、删除客户、查看客户、修改客户
用户表 主体：小王 角色: 销售角色
RABC并不总能满足所有权限的场景。比如，我们无法对销售角色，进行个体定制。比如，销售角色拥有创建、删除的权限。如果我们要对销售小李，去掉删除的权限。那么，我们就必须创建另一个角色，来满足需求。如果这种情况很频繁，就会丧失角色的统一性，降低系统的可维护性。
角色和组两个概念可能会让人混淆，在这里做个区分：
- 角色赋予的是主体，主体可以是用户，也可以是组
- 角色是权限的集合
- 组是用户的集合
ABAC 基于属性的访问控制
规定哪些 属性的主体可以对哪些 属性的资源在哪些 属性的情况下进行哪些 操作，
场景：防火墙 适用资源：端口访问
ABAC其中的属性就是与主体、资源、情况相关的所有信息。
- 主体的属性：指的是与主体相关的所有信息，包括主体的年龄、性别、职位等。
- 资源的属性：指的是与资源相关的所有信息，包括资源的创建时间、创建位置、密级等。
- 情况的属性：指的是客观情况的属性，比如当前的时间、当前的位置、当前的场景（普通状态、紧急状态）。
- 操作：含义还是一样，比如增删改查等。
设定一个权限，就是定义一条含有四类属性信息的策略（Policy）。
策略表 效果：允许 操作：流入 主体：来自上海IP的客户端 资源：所有以33开头的端口（如3306） 情况：在北京时间 9:00~18:00 效果：禁止 操作：流出 主体：任何 资源：任何 情况：任何
一个请求会逐条匹配策略，如果没有匹配到策略，则返回默认效果，默认效果可以根据场景定制，可以是默认拒绝或是默认允许。另外，匹配方式也可以根据场景定制，可以使用逐条顺序匹配，匹配到策略直接返回。也可以使用完全匹配，匹配所有的策略，如果有一个拒绝（允许），则拒绝（允许）。
阿里云的RAM访问控制运用的就是ABAC模型：
阿里云RAM策略配置表 { "Version": "1", "Statement": [{ "Effect": "Allow", "Action": ["oss:List*", "oss:Get*"], "Resource": ["acs:oss:*:*:samplebucket", "acs:oss:*:*:samplebucket/*"], "Condition": { "IpAddress": { "acs:SourceIp": "42.160.1.0" } } }] }
ABAC可以发挥权限系统最大的灵活性，但在灵活的同时，如果不对策略加以管理，也有可维护性的问题。
