在上文，我们简单介绍了一下为什么需要权限，那么本人将介绍如何来设计权限系统
权限管控可以通俗地理解为权力限制，即不同的人由于拥有不同权力，他所看到的、能使用的可能不一样。对应到一个应用系统，其实就是一个用户可能拥有不同的数据权限（看到的）和操作权限（使用的）。
目前权限模型主要分为以下五种：
- ACL 模型：访问控制列表
- DAC 模型：自主访问控制
- MAC 模型：强制访问控制
- ABAC 模型：基于属性的访问控制
- RBAC 模型：基于角色的权限访问控制
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 的缺点，在新增资源时容易维护。
原理：通过动态计算一个或一组属性是否满足某种机制来授权，是一种很灵活的权限模型，可以按需实现不同颗粒度的权限控制。
属性通常有四类：
主体属性，如用户年龄、性别等； 客体属性，如一篇文章等； 环境属性，即空间限制、时间限制、频度限制； 操作属性，即行为类型，如读写、只读等。
例如：早上 9:00，11:00 期间 A、B 两个部门一起以考生的身份考试，下午 14:00，17:00 期间 A、B 两个部门相互阅卷。
缺点：规则复杂，不易看出主体与客体之间的关系，实现非常难，现在应用得很少。
RBAC，基于角色的权限访问控制
Role-Based Access Control，核心在于用户只和角色关联，而角色代表对了权限，是一系列权限的集合。
RBAC 三要素：
- 用户：系统中所有的账户
- 角色：一系列权限的集合（如：管理员，开发者，审计管理员等）
- 权限：菜单，按钮，数据的增删改查等详细权限。
在 RBAC 中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。
角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。
角色可依新的需求和系统的合并而赋予新的权限，而权限也可根据需要而从某角色中回收。角色与角色的关系同样也存在继承关系防止越权。
优点：便于角色划分，更灵活的授权管理；最小颗粒度授权；
RBAC 的深度拓展
RBAC 模型可以分为：RBAC0、RBAC1、RBAC2、RBAC3 四个阶段，一般公司使用 RBAC0 的模型就可以。另外，RBAC0 相当于底层逻辑，后三者都是在 RBAC0 模型上的拔高。
我先简单介绍下这四个 RBAC 模型：
1. RBAC0 模型
用户和角色、角色和权限多对多关系。
简单来说就是一个用户拥有多个角色，一个角色可以被多个用户拥有，这是用户和角色的多对多关系；同样的，角色和权限也是如此。
RBAC0 模型如下图：没有画太多线，但是已经能够看出多对多关系。
2. RBAC1 模型
相对于 RBAC0 模型，增加了角色分级的逻辑，类似于树形结构，下一节点继承上一节点的所有权限，如 role1 根节点下有 role1.1 和 role1.2 两个子节点
角色分级的逻辑可以有效的规范角色创建（主要得益于权限继承逻辑），我之前做过 BD 工具（类 CRM），BD 之间就有分级（经理、主管、专员），如果采用 RBAC0 模型做权限系统，我可能需要为经理、主管、专员分别创建一个角色（角色之间权限无继承性），极有可能出现一个问题，由于权限配置错误，主管拥有经理都没有权限。
而 RBAC1 模型就很好解决了这个问题，创建完经理角色并配置好权限后，主管角色的权限继承经理角色的权限，并且支持针对性删减主管权限。
3. RBAC2 模型
基于 RBAC0 模型，对角色增加了更多约束条件。
如角色互斥，比较经典的案例是财务系统中出纳不得兼管稽核，那么在赋予财务系统操作人员角色时，同一个操作员不能同时拥有出纳和稽核两个角色。
如角色数量限制，例如：一个角色专门为公司 CEO 创建的，最后发现公司有 10 个人拥有 CEO 角色，一个公司有 10 个 CEO？这就是对角色数量的限制，它指的是有多少用户能拥有这个角色。
RBAC2 模型主要是为了增加角色赋予的限制条件，这也符合权限系统的目标：权责明确，系统使用安全、保密。
4. RBAC3 模型
同样是基于 RBAC0 模型，但是综合了 RBAC1 和 RBAC2 的所有特点
这里就不在多描述，读者返回去看 RBAC1 和 RBAC2 模型的描述即可。
RBAC 权限管理的在实际系统中的应用
RBAC 权限模型由三大部分构成，即用户管理、角色管理、权限管理。
用户管理按照企业架构或业务线架构来划分，这些结构本身比较清晰，扩展性和可读性都非常好。
角色管理一定要在深入理解业务逻辑后再来设计，一般使用各部门真实的角色作为基础，再根据业务逻辑进行扩展。
权限管理是前两种管理的再加固，做太细容易太碎片，做太粗又不够安全，这里我们需要根据经验和实际情况来设计。
本文章到此结束，下一篇我们将介绍如何选择对应的权限模型
