对于资源的访问控制是我们在代码中经常看到的，当你规定某种数据只有某些人才可以访问和操作时，那实际上这就是访问控制了。如果把用户登录认证看做是健身房的会员卡，那访问控制就是健身房中你的储物柜的钥匙；有了会员卡你才能进入到健身房进行健身，而储物柜钥匙限制了你只能使用你自己的那个柜子。
实现一个访问控制可以看做是：规定用户/主体（Subject）通过某些权限/规则（Permission/Rule）去操作某些资源/客体（Resource/Object）。
也可以把权限控制看做是一组规则的集合（规则引擎），当用户试图去访问某个资源时，就去这个规则集合搜索和过滤，然后得出一个结果，看用户是否有权限去访问这个资源。
常见的访问控制模型有：
- 访问控制列表（ACL: Access Control List）
- 自主访问控制（DAC: Discretionary Access Control）
- 强制访问控制（MAC: Mandatory Access Control）
- 基于角色的访问控制（RBAC: Role-Based Access Control）
- 基于属性的访问控制（ABAC: Attribute-Based Access Control）
下面我们对这几种访问控制模型进行一个简单的介绍。
访问控制列表（ACL: Access Control List）
访问控制列表就是用一个列表的形式来维护对某个资源的访问控制。
如图所示，表中列出了所有人可以如何对Post进行操作。ACL是早期的实现访问控制的模型，把人直接和权限对应起来。
优点：
- 很直观
- 实现简单
缺点
- 维护这个表的成本比较高，特别是在用户很多时，基本就很难去维护了
- 无法批量修改用户的权限
- 冗余数据多。上图中的Alice和Bob拥有一样的权限，而表中的数据却是存两份，而不是一份
后来基于ACL模型演化出了基于角色的访问控制模型（RBAC: Role-Based Access Control），很好地解决了难以维护的问题。
目前我们听到的ACL，有时候不是指这里提到的ACL（Access Control List），而是有点Access Control Layer的意思，变成了Access Control的代称。
自主访问控制（DAC: Discretionary Access Control）
DAC是指资源的拥有者可以将其拥有的权限分配给其他用户。
大多数UNIX系统的访问控制模型就是DAC。UNIX中的权限分为三种：读，写和执行（rwx），假设你在UNIX系统中创建了一个文件，然后你把这个文件的读和执行权限分配给了A用户，而没有分配写权限，之后A用户就可以读取文件的信息（r）和打开（x）该文件了，但当A用户修改了文件内容并试图保存时就会失败，因为你没有分配写（w）权限给他。
DAC和上面提到的ACL非常类似，区别是资源的拥有者可以将其拥有的权限分配给其他用户。
强制访问控制（MAC: Mandatory Access Control）
MAC是指所有的访问控制策略都由系统管理员来制定，用户无法改变。
MAC一般会给用户和资源进行分级，比如：
用户级别：高级，中级，普通
文件级别：绝密，保密，公开
系统管理员会制定访问策略，比如高级用户可以访问所有类型的文件，中级用户可以访问保密级别以下的文件，而普通用户只能访问公开的文件。
MAC通常用在对保密性要求比较高的系统中，比如军方机构。商业系统中使用MAC的有SE Linux和Trusted Solaris。
基于角色的访问控制（RBAC: Role-Based Access Control）
前面提到了ACL的缺点（难以维护，无法批量修改，冗余数据多），RBAC正是为了解决这些缺点而生的，和ACL的结构类似，只不过把人和权限的关系变成了角色（role）和权限的关系。
这样同样是一个列表，和ACL相比，现在只需要维护两行就行了，因为图中的Member这个role对应着两个人：Alice和Bob，如果要批量修改，只需要修改对应的Member这个role对应的权限就行了。
RBAC是目前商业应用中最流行的访问控制模型，因为它简单又能满足大部分的需求。
基于属性的访问控制（ABAC: Attribute-Based Access Control）
ABAC基于任意的属性组合来达到访问控制的目的，是最灵活的访问控制模型，从另外一个角度来看，也是最复杂的模型。想象一个人拥有以下属性：
- name: Alice
- type: developer
- department: software
- timezone: 8
- location: Beijing
有一个用户支持的系统，那访问控制可以这样设置：
让timezone为8，type为developer的人只能看到来自亚洲的所有用户的feedback
ABAC也比较适合跨系统的情景，假设我想开发一个系统C，目的是集成系统A和系统B的用户信息并加上访问控制，A系统中的用户数据结构是这样的：
- name: Alice
- type: developer
- department: software
而B系统中的用户数据结构是这样的：
- name: Bob
- type: engineer
- department: development
实际上这两个用户对于系统C来说应该具有同样的权限，这样的情况就可以用ABAC来实现访问控制。
看起来ABAC很好很强大是吧，可事实上ABAC尚未流行，原因可能就是因为ABAC太复杂了。一般的系统可以从RBAC（粗粒度）开始，然后结合ABAC（细粒度）来就足够了。
总结
本文介绍了5种访问控制模型，包括：
- 访问控制列表（ACL: Access Control List）
- 自主访问控制（DAC: Discretionary Access Control）
- 强制访问控制（MAC: Mandatory Access Control）
- 基于角色的访问控制（RBAC: Role-Based Access Control）
- 基于属性的访问控制（ABAC: Attribute-Based Access Control）
并介绍了它们之间的关系以及优缺点。如果你开发一个商业应用，那首选RBAC基本不会错了。
参考：
- https://en.wikipedia.org/wiki/Discretionary_access_control
- https://www.techopedia.com/definition/229/discretionary-access-control-dac
- https://sites.google.com/site/jimmyxu101/concepts/accesscontrol
- https://www.techotopia.com/index.php/Mandatory,_Discretionary,_Role_and_Rule_Based_Access_Control
- http://blog.identityautomation.com/rbac-vs-abac-access-control-models-iam-explained
- https://www.axiomatics.com/attribute-based-access-control/
- https://www.jianshu.com/p/ce0944b4a903
- https://juejin.im/post/5c3ff01de51d455231348971
- https://avaj.iteye.com/blog/657185
- https://segmentfault.com/a/1190000016766750
