在产品设计中，我们会接触各种权限管理模型，但需要先对模型有所了解，才能选择适合产品本身的模型。这篇文章，作者总结了七种权限模型及对应优缺点，供大家参考。

1. 目的

探究市面上主流的各类权限管理模型，如基于用户、角色组、实体等等的权限模型，结合产品本身的业务、面临的问题和未来的发展兼容，进行权限模型选型，找到适合产品本身的权限范式体系。

2. 模型

2.1 ACL权限模型

在OA系统中，接触了ACL（access control list）模型的权限设计。ACL是一种面向资源的访问控制模型。ACL实体模型的核心在于用户可以直接和权限挂钩，权限模型包括：资源标识、用户标识、授权状态。

ACL的原理为：每一项资源，都配有一个列表，这个列表记录的就是哪些用户可以对这项资源执行增加(Create)、检索(Retrieve)、更新(Update)和删除(Delete)等操作。当用户试图访问这项资源时，会首先检查这个列表中是否有关于当前用户的访问权限，从而确定当前用户是否可执行相应的操作。总体来说，ACL是一种面向资源的访问控制模型，它的机制是围绕“资源”展开的。

优点：

• ACL权限模型原理简单，直接将权限赋给用户，便于理解和操作。
• 可以满足个性化的需求，即为系统中的用户单独分配权限。

缺点：

• 由于需要维护每个用户的访问权限列表，管理者工作量大，所以需要解决复用性问题。

改进：

ACL不仅记录用户—资源—操作表，还记录用户组—资源—操作表，用于记录用户或者用户组对资源拥有的权限。改进之后的权限模型包括：资源标识、主体标识、主体类型（用户或用户组）、授权状态。

2.2 RBAC权限模型

RBAC（Role-Based Access Control ）基于角色的访问控制。RBAC认为权限的过程可以抽象概括为：判断【Who对What是否可进行How的访问操作】：

• Who：权限的拥用者或主体（如Principal、User、Group、Role、Actor等等）。
• What：权限针对的对象或资源（Resource、Class）。
• How：具体的权限（Privilege，正向授权与负向授权）。

RBAC的核心思想就是将访问权限与角色相关联，通过给用户分配适合的角色，让用户与访问权限相联系。角色是根据组织内为完成各种不同的任务需要而设置的，根据用户在组织中的职权和责任来设定他们的角色，用户可以在角色间进行转换，系统可以添加、删除角色，还可以对角色的权限进行添加、删除。这样通过应用RBAC可将安全性放在一个接近组织结构的自然层面上进行管理。权限被赋予角色,而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的权限。一个用户拥有若干角色，一个角色拥有若干权限，这就构成“用户-角色-权限”的授权模型。

在RBAC之中，用户和角色是多对多的关系，角色与权限也是多对多关系：

• 一个用户在不同的场景下可以拥有不同的角色，例如项目经理也可以是项目架构师等。
• 一个角色可以给多个用户，例如一个项目中有多个组长，多个组员等。
• 一个角色可以拥有多项权限，同一个权限也可以授给多个角色。

RBAC引入了角色的概念，目的是为了隔离用户与权限。角色（Role）作为一个用户（User）与权限（Privilege）的代理层，解耦了权限和用户的关系，所有的授权应该给予角色而不是直接给用户。

基于角色的访问控制方法（RBAC）的显著的两大特征是：

1.由于角色/权限之间的变化比角色/用户关系之间的变化相对要慢得多，减小了授权管理的复杂性，降低管理成本。

2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。

优点：

• RBAC是把用户按角色进行归类，通过用户的角色来确定用户能否针对某项资源进行某项操作。相对于ACL最大的优势就是它简化了用户与权限的管理，通过对用户进行分类，使得角色与权限关联起来，而用户与权限变成了间接关联，从而解耦。
• 通过对角色设置权限，可一次性对角色下的所有用户设置权限。在角色组中增删单个成员，也不会对角色组整体产生影响。

缺点：

• 由于权限是以角色为载体分配的，因此无法对某一角色下的个别用户需要进行特别的权限定制，只能再重新创建角色。即不可对角色组下的单个成员进行个性化权限设置。
• RBAC模型只给角色赋予了权限，没有提供这些权限的操作顺序控制机制。这一缺陷使得RBAC模型很难应用关于那些要求有严格操作顺序的实体系统。例如，在购物控制系统中要求系统对购买步骤的控制，在客户未付款之前不应让他把商品拿走。RBAC模型要求把这种控制机制放到权限模型中预设好。

改进：

原来模型关系为“用户—角色—权限”，为了解决个性化问题，可在此基础上，增加“用户—权限”的关联关系。除了可以给角色授权外，还可以给用户直接授权。这样一来，用户拥有的所有权限，就是用户个人拥有的权限与该用户所在角色拥有的权限之和。

2.3 DAC权限模型

DAC是自主访问控制模型。定义：规定资源可以被哪些主体进行哪些操作，同时，主体可以将资源、操作的权限，授予其他主体。

在ACL的基础上，DAC模型将授权的权力下放，允许拥有权限的用户，可以自主地将权限授予其他用户。

DAC的应用场景：DAC常见于文件系统，LINUX，UNIX、WindowsNT版本的操作系统都提供DAC的支持。在实现上，先对用户鉴权，然后根据控制列表决定用户能否访问资源。用户控制权限的修改通常由特权用户或者管理员组实现。

缺点：

• DAC最大缺陷是对权限控制过于分散，比如无法简单地将一组文件设置统一的权限开放给指定的一群用户。
• 主体的权限太大，授权其他用户时，无意间可能造成泄露信息。

2.4 MAC权限模型

MAC是强制访问控制模型，是为了弥补DAC权限控制过于分散的问题而诞生的。主体被赋予一定的安全级别，客体被赋予一定的安全级别，主体能否访问客体由双方的关系安全级别决定，这个判断通常有系统硬性限制。

定义：当一个操作，同时满足a与b时，允许操作

• a. 规定资源可以被哪些类别的主体进行哪些操作
• b. 规定主体可以对哪些等级的资源进行哪些操作

MAC是在ACL基础上的另一种实现，强调安全性。MAC会在系统中，对资源与主体，都划分类别与等级。MAC非常适合机密机构或者其他等级观念强烈的行业，但对于类似商业服务系统，则因为不够灵活而不能适用。MAC可以继续使用DAC的模型，但是要对用户进行等级划分，比如一级，二级，三级……，对对象资源也要做划分，比如机密，秘密和最高机密。用户访问的资源的时候，根据用户等级与资源访问级别来做判断，比如一级用户只能访问机密文件，如果访问的是最高机密文件，系统就会拒绝。这一系列规则是优先于DAC的，如果MAC与DAC混用，要先校验MAC再校验DAC。

优点：

MAC的优势就是实现资源与主体的双重验证，确保资源的交叉隔离，提高安全性。

缺点：

只适用于特定的安全性高要求较高的场景。过重强调保密性，使得管理不够灵活。

改进：

在实现上，MAC和DAC通常为每个用户赋予对客体的访问权限规则集，考虑到管理的方便，在这一过程中还经常将具有相同职能的用户聚集为组，然后再为每个用户组分配权限。

2.5 ABAC权限模型

ABAC是基于属性的访问控制权限模型。定义：规定哪些属性的主体可以对哪些属性的资源在哪些属性的环境下进行哪些操作属性。

ABAC其中的属性就是与主体、资源、环境相关的所有信息：

• 主体的属性：指的是与主体相关的所有信息，包括主体的年龄、性别、职位等。
• 资源的属性：指的是与资源相关的所有信息，包括资源的创建时间、创建位置、密级等。
• 环境的属性：指的是客观情况的属性，比如当前的时间、当前的位置、当前的场景（普通状态、紧急状态）。
• 操作属性：指的是可进行的全部操作，如增删改查等。

当企业中参与权限管理的用户数量很多、或者角色数量很多时，传统的RBAC模型会显露出一些缺点，比如容易遗漏需要参与到权限管理的部分用户，并且容易受到“角色数量爆炸”的影响。RBAC虽然是目前最普遍的权限控制模型。

但是某些情况下，RBAC是无法满足并且也实现不了的。比如业务员1和业务员2都属于业务员角色，都有查看客户订单的权限。当有一个需求，要求业务员1只能查看北京地区的客户的订单，业务员2只能查看上海的客户的订单。这单单使用RBAC是无法实现。借助RBAC，可行的做法是，分地区创建角色，然后程序中根据角色做数据的过滤，这种做法缺点是，每次需求变更的时候可能都需要修改代码。

此时需要新的权限管理方法来控制对企业的访问，允许特定用户在特定场景下拥有特定权限。通常考虑的第一种解决方案是基于属性的访问控制（ABAC），会在系统中设置好基于用户属性、资源属性、环境属性和操作权限的预定义规则，当某个用户进入到系统中时，会获取用户和当前场景的属性，基于这些属性，自动为该用户分配权限。所以说，ABAC中可以完全自动化——可根据所获取到的属性进行自动判定和授权，而不需要使用管理员手动设置授权。

传统的 RBAC 与 ACL 等访问控制机制，可以认为是 ABAC 的子集。

对于 RBAC来说，访问机制的实现只是基于主体的属性“角色”而已，ACL 只是基于主体的属性是“单个用户”。而ABAC 基于更多的属性，能做到更细粒度的授权管理。例如，ABAC权限模型中通过众多属性来决策实现，只有姓张的工程师在处理项目A时才能访问某个资源，其中“姓张、工程师、项目A”都是决策所依据的属性。因此，ABAC模型不需要关注特定的用户好角色，只需要对提炼出的各种“属性”进行授权规则设置，管理对象为属性和权限。

ABAC对用户本身的属性进行标识，通过属性标识来判断用户权限。这样的设计使得ABAC非常灵活，可扩展性也很高。ABAC一般来说，都是搭配着ACL或RBAC一起使用，不会单独成体系。以上述业务员查看订单为例，说明ABAC的一种实现方式：

• 在RBAC的基础上，扩展一个实体规则。其中，订单就是实体，地区是实体的属性。
• 然后针对实体（订单）的属性（地区）设置一系列规则。规则存储格式可以是json、SQL语句等等，能解析即可。规则为：业务员1只能查看北京地区的客户的订单，业务员2只能查看上海的客户的订单。
• 保存规则，包括规则内容(即json、SQL语句等)、规则实体(即订单)、适用操作（即增删改查等）。
• 将创建好实体的规则与角色做关联，也就是将北京地区的规则关联到北京地区业务员角色上，上海地区的规则关联到上海地区业务员角色上。
• 后端做权限校验的时候，还是先按RBAC模型的控制方式进行校验(是否具备订单查看权限)，然后根据当前操作对象(也就是实体)，取出用户所属角色关联的对应实体的规则。然后解析规则，动态拼接Sql语句。

以上只是针对地区属性实现了动态权限控制。实际业务中，要控制可能更多，比如字段权限、数据范围等等。要满足这些复杂的控制，需要制定一套完整的规则，以及针对规则编写相应的解析程序。

优点：

• 可适用于用户数量和角色数量很多的权限管理场景，在设置好预定义规则之后，系统可对用户进行自动授权，不需要使用管理员手动设置授权。

缺点：

• 当采用ABAC模型时，随着属性数量的不断增加，定义与单个用户相关联的每个属性的复杂性也随之增加，从而增加了管理整个企业的访问管理的难度。需要IT团队部署和维护。
• 实现成本高：ABAC非常的灵活，但是实现比较困难。这其中涉及到逻辑的动态执行，数据动态过滤等，更加具体就是动态拼接SQL语句。

基于属性的访问控制模型(ABAC)被认为是访问控制模型的未来。但并不是当前权限管理场景下的最优方案。

2.6 TBAC权限模型

TBAC是基于任务的访问控制模型。它从工作流中的任务角度建模,可以依据任务和任务状态的不同,对权限进行动态管理。适用于工作流、分布式处理和事务管理系统中的决策制定与权限管理。

ACL、RBAC、DAC、MAC都是从系统的角度(控制环境是静态的)出发保护资源。其访问控制的原理可以简单地描述为:如果主体对某客体有访问操作请求,而且主体拥有操作权限,则提供访问操作。

工作流是为完成某一目标而由多个相关的任务(即活动)构成的业务流程。工作流所关注的问题是处理过程的自动化，对人和其他资源进行协调管理，从而完成整个工作流程。当数据在工作流中流动时,执行操作的用户在改变，用户的权限也在改变，这与数据处理的前后节点环境相关。采用传统的访问控制技术，如 DAC、MAC等，则难以做到这一点；若采用 RBAC，也需要频繁地更换角色，且不适合工作流程的运转。TBAC则可对工作流中的各任务节点进行动态权限管理。在 TBAC 中，主体（即角色组等）的访问权限并不是静止不变的，而是随着工作流的任务流转不断发生变化。在工作流中，每一步对数据的处理都与以前的处理相关，相应的访问控制也是这样，因而TBAC是一种与前后任务节点相关的访问控制模型。

基于任务的权限模型有以下特点：

• TBAC不仅能对不同工作流实行不同的访问控制策略,也能对同一工作流的不同任务节点实行不同的访问控制策略。
• 因为任务都有时效性（即工作流流转到下个任务节点时，当前任务节点时效结束），所以TBAC中，用户对于授予他的权限使用也是有时效性的。

优点：

在业务流、工作流等特定情况下，可以动态管理权限，比传统的静态权限模型更贴合场景。

缺点：

实现成本高，需要IT团队开发和维护。工作流的任务节点数量和形式可能不固定，各节点的流转要求也不尽相同，每次进行调整时都要对权限模型进行修改。只有在结构稳定工作流中，才可稳定运行。

2.7 EBAC权限模型

EBAC是基于受控实体的访问控制技术。对各种客观存在的和逻辑定义的企业信息资源（即主体拥有访问权限的客体），定义为受控实体。

传统的访问控制策略 DAC和 MAC存在安全缺陷和应用复杂性等问题，当前企业应用系统中采用较多的是RBAC。在访问控制对象和操作比较明确的系统中，RBAC 能够提供一种灵活、有效的用户行为能力的组织机制。但 RBAC 是一种被动的、提前授权的访问控制技术，主体可以无限制使用其拥有的客体及客体资源的访问权限，不能依据操作环境进行访问主体和客体的动态变更。

TBAC通过对工作流中任务步骤的动态授权，可以清晰地表达复杂工作流的控制机制，主体权限的时效性也因任务的时效性得以解决，在一定程度上能够实现授权管理的自动化。但是TBAC强调工作流各任务的原子性，受限于工作流和任务的数量，造成权限配置的复杂性。其次，主体访问权限的动态性和频繁改变的特性，增加了系统安全控制实现的难度，也给整个系统的运行效率造成影响。

EBAC模型以受控实体为访问客体，并以其为中心实现安全控制机制。一方面，用户通过对受控实体的管理，间接获取访问权限；另一方面，受控实体可动态地对用户权限集和属性集的访问进行自主控制。EBAC 是一个随受控实体业务调度变化的动态访问控制模型。

EBAC 充分利用企业资源类属的有限性和依据管理策略组织的特性，以受控实体为访问客体，并由其自主控制访问主体对访问客体权限集和属性集的访问能力，采用静态权限分配和动态权限授予相结合的方式。

3. 分析

3.1 ACL与RBAC模型改进比较

ACL由于用户和权限直接挂钩，可以满足个性化，即为系统中的用户单独分配权限；RBAC由于角色和权限直接挂钩，使得权限可以被复用，把用户按角色进行归类。

两种模型的改进，都是为了弥补自身不足而演变而来的，即ACL需要解决复用性问题，RBAC需要解决个性化问题。其实，两种改进模型都驶向了一个平衡点，虽然RBAC改进模型中会让表个数增多，但是原理还是一样的。

RBAC在ACL的基础上加入了角色的概念，权限列表或访问控制列表里维护的不再是用户与功能的关系，而是角色与功能的关系。ACL可以和RBAC混着用，既可以在角色上设置权限，也可以直接给用户设置权限，更加灵活。借助角色的思想，可以在用户组，组织，职位等等上设置权限，以便更好的做好权限管理，也就是将权限设置从单一个体转移到某一类组合上。

3.2 RBAC与ABAC模型比较

RBAC权限模型是粗粒度和静态的权限模型，ABAC是细粒度和动态的权限模型。

要真正的落地实现ABAC比较复杂。每次都要针对具体情况获取属性解析规则，对程序的性能也会造成影响，就算使用缓存，命中的概率也是非常的小，因为很多因素都是动态的。所以，如果需要根据属性做权限判断的场景不是很多的话，还是建议使用RBAC，在程序中做判断也比较省事省力。

3.3 ABAC与TBAC模型比较

ABAC、TBAC模型都是动态授权模型。但两种模型做出动态配置的依据不同，ABAC模型是根据主体、资源和环境做出动态权限配置。TBAC模型是根据任务和任务状态做出动态权限配置。

4. 总结

权限系统作为中后台的基础能力之一，能够让不同组织下的不同人员专注于自己的工作领域，降低数据风险，实现人员和数据的高效管理。

在选择权限模型时：

• 面向用户量和权限量少、更新频次低、无明确职能划分的小型组织进行权限设计时，可以考虑参考开发成本低的ACL权限列表权限设计，基于账号进行授权设计；
• 面向用户量和权限量多、更新频次多、有明确职能划分的中型组织进行权限设计时，可以考虑维护成本低的RBAC角色权限设计，基于角色进行授权设计；面向用户量和权限量多、更新频次高、无明确职能划分、有安全合规诉求、权限定制多样化的大型组织，可以考虑在保障效率的同时降低安全风险的ABAC属性权限设计，基于属性规则进行授权设计。

在权限设计时需要基于业务角度考虑多个方面：

• 页面的赋权设计需要注意关联体现页面间的层级关系与对应操作权限；
• 操作的赋权设计需要注意数据状态变化导致的操作变化；
• 数据的赋权设计需要注意多业务数据是否需要基于安全性进行分隔处理。