abac权限模型（熟悉这四种权限管理模型）

不管是2C产品经理还是2B产品经理，都要将权限管理法则烂熟于心。只有熟悉权限管理法则，才能更好地理解自己产品的架构，做到每次产品迭代都心里有数。

从本质来说，无论何种类型的权限管理模型都可以抽象出三个基本的要素——即：用户（user）、系统/应用（system/application）、策略（policy）。

策略决定了用户和不同功能应用之间如何交互。反过来，也就是说，无论设计何种权限管理的模型，都是基于这三个基本要素来展开。

本文聚焦于目前应用最广的RBAC模型，但在这里提出三个基本要素，主要是为了帮助大家更好的理解权限管理，不至于在众多权限模型中迷失。

不同的公司或软件提供商，设计了无数种控制用户访问功能或资源的方法。但无论哪种设计，都可归到四种经典权限模型里——自主访问控制(DAC，Discretionary Access Control)、强制访问控制 (MAC，Mandatory Access Control)、基于角色访问控制 (RBAC，Role-based Access Control) 和基于属性访问控制 (ABAC，Attribute-based Access Control).

（我觉得翻译不好，但也找不到更贴切的。本文下面内容均以英文首字母来代替：DAC，MAC，RBAC，ABAC）。

一、DAC，MAC

本文主要就RBAC展开分析该模型的使用场景，以及如何基于该模型设计出合适的权限管理体系。但从文章便于理解的完整性的角度来考虑，会对DAC，MAC和ABAC进行简要的介绍。

DAC：被操作对象，根据访问控制规则，来判断操作主体可对操作对象做哪些操作，比如只读或者是可写的权限。而自主的含义，则是拥有某种权限的用户，可以把权限赋予其他用户。

MAC：被操作对象及用户两方均有各自的权限标识，用户能否对对象进行操作，取决于权限标识的对照关系。这种模型多用于等级制度明显，信息访问安全性要求高的场景，比如军事。

ABAC和RBAC有很多相通的地方，而且相比较而言ABAC实际上更灵活，符合未来发展的方向。因此，我们分析完RBAC后，再回过头来看ABAC。

二、那么，什么是RBAC呢？

Role-based Access Control，基于角色的权限控制模型。

顾名思义，给用户定义角色，通过角色来控制权限。目前来说基于角色权限控制模型是应用较广的一个。特别是2B方向SAAS领域，应用尤其常见。

如上图示，用户拥有角色，且可拥有多个角色，而每个角色对应不同权限。

这样的好处是：不必为每一个用户去配置权限，拥有极大的灵活性和便利性。而当用户及权限的量级又大到另一个级别时，又引入了角色组和权限组概念，此处不做延伸，有兴趣的读者可以去搜些资料来看。

三、怎么利用RBAC模型来进行权限体系的设计？

我们已经知道什么是RBAC模型了，在分析怎么来根据此模型来设计权限体系之前，我们再把这个模型要素进行拆分一下。

首先是：用户、角色、权限。

而权限，具体到某个软件来说，实际上包含两个方面。一个是菜单权限，另一个是数据权限。

不同的行业会有不同的使用场景，用户角色权限模型也会有不同程度上的变化。但归到底层来说，还是离不开上面我画的这个图。

上面这个图是从***看到的，销售自动化领域十分典型的用户权限管理设计。

接下来，我们来抽象一个场景或者说案例，来辅助我们理解整个权限管理设计的过程。假设A公司是个中大型的生产制造公司，公司有OA、HR、CRM、ERP一系列管理软件。公司员工以万计，不同人员职责不同，体现在管理软件上，就是会需要使用不同的功能来完成工作。

帐号管理

帐号是人和软件进行交互时的一个身份的转化。账号的背后，代表了这个操作的人。账号管理应该是所有需要和系统交互的人的统一管理，包含基础信息，比如：这个人的名字，性别、手机号、部门以及其他属性。

角色管理

角色管理，就是要从实际场景出发，比如：使用系统的企业或者团体，有哪几类使用的角色——也就是说，有哪几类人，是需要有不同的业务菜单和业务数据的。

说到底，角色管理，就是把这个角色对应的人平时工作需要的菜单、功能给划到一个组里。给这一个个的操作组定义不同的名称——即角色名称。

当然，这个角色管理除了规定了该角色的人平时可对哪些功能进行查看操作，还需规定这个角色，能看到哪些范围内的数据。也就是前面提到的，权限实际上包含的是菜单权限和数据权限两部分。

系统内功能控制的颗粒度越细，对使用者来说配置角色便越灵活，但对系统的设计者来说，系统的复杂度自然也会上升，成本也会增加。

因此，到底控制到哪一层级，就要视具体业务场景来定，比如：有些行业的系统，可能控制到一级菜单就可以（某些SAAS工具），但有些系统，不仅需要控制所有的子级菜单，每一个按钮操作，甚至还会需要控制到不同的字段（比如Salesforce的权限控制系统）。

不过，我们抽象出了基本的模型，根据实际业务再去发散，就不是最困难的事了。

四、看看ABAC，顺便畅想下未来的权限模式

至此，我们可以了解到：RBAC模型实际上能解决大部分的权限设计问题了。

那么，ABAC到底是什么呢？它存在的意义在哪里？关于未来的权限设计趋势，它能带给我们什么启发呢？

带着这些问题，我们先来看看到底什么是ABAC模型。

ABAC，Attribute-based Access Control. 基于属性的访问控制。而属性，总的来说有三类：用户属性、系统或应用被访问属性（数据和操作）、环境属性。

也就是说，系统根据一组或多组属性是否满足预设规则来动态的控制，谁可以访问哪些功能数据和操作。RBAC模型，其实可以看成是静态的、单组属性的ABAC模型。

用例子来理解这个模型就是：只有当用户角色为Admin，在工作时间内，且处在C栋大楼B实验室，才可以访问D文件。

实际上，ABAC是个可以以最细颗粒度来管理权限的模型。它可以让设计者，利用任何一个用户属性、环境属性，或者多个属性之间的交集、并集等来组合出动态的权限判断逻辑。

它是这么强大，既可以有效的帮助信息辨别能力差的用户过滤垃圾信息。也可以让商家用到营销广告填满你生活的每个角落却不自知。

但我一直坚信，科技绝对是让生活更美好。

五、所以一下

权限管理，可能是每个2B产品经理需要面对的问题。但无论C端还是B端的产品，了解权限管理的设计法则，让自己更好的理解产品的架构，让产品的每次迭代都心里有数。