熟悉这四种权限管理模型，产品迭代才能心里有数

Posted 2023-04-20

参考技术A

从本质来说，无论何种类型的权限管理模型都可以抽象出三个基本的要素——即：用户（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）。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

题图来自Unspalsh, 基于CC0协议。

2B产品的用户权限管理问题与RBAC模型

让产品从0到1>  第 13 辑

产品微言 第  131  期

权限管理，就是解决 “Who对What(Which)进行How的操作” 问题。

文  |  人人都是产品经理专栏作家  杜松

前文我们讨论了 2B产品的用户角色设计 问题，着重探讨了在整个系统中，用户和角色的关系，并基于业务过程对角色进行了场景的细分，并详细的解释了为什么要在做产品原型设计之前分析业务角色，设计各个角色的关系。

本文则讨论如何基于用户角色进行权限管理。

01

权限管理的基本概念

系统的权限管理，简单的说就是针对不同身份的用户设置不同级别的访问、请求和处理数据的范围级别。考虑的是企业的数据安全和信息隐私问题。

对2B的产品而言，必须充分考虑到业务的复杂性和扩展性，使得产品的业务管理和控制权限能够随着业务和组织架构的发展而快速部署，需要特别注意的是，不同的业务形态、不同的管理机制，都会给权限系统的设计带来重要影响。

这也是为什么2B的产品难以标准化的一个因素——业务的独特性和（管理）文化的独特性。

权限管理，本质上是对用户，以及用户的行为的范围控制，通过一种巧妙的设计，约束不同身份的用户在系统上的操作路径和操作权限。

一言以蔽之，就是 解决Who（用户）对 What (资源) 进行 How（行为）操作的问题。

• who——是权限的拥有者或主体（如：User、Role）

• what——是资源或对象（Resource、Class)，如菜单、按钮

• how——具体的操作权限（Privilege,正向授权与负向授权）

这里涉及到三个关键问题。

1、用户与角色

用户，指的是真实“人”，是系统上每一个具体的操作实体(系统的一个账号)，而角色这是一个抽象概念。比如管理员是一个角色，一个系统可以配置多个管理员账户。

这里还需要区别一个概念：业务角色和权限角色。

业务角色是针对业务过程的抽象，而权限系统的角色，则是对管理过程的抽象。两种之间存在一定的相关性，多数情况下业务角色是可以直接对应为系统的权限角色。

2、行为与资源

用户在系统上的行为，可归纳为两类：

• 数据权限：可以查看、操作的数据范围，比如部经理可以查看整个部门的业务数据，而员工只可以查看个人的数据

• 功能权限：对系统资源（页面、菜单、按钮等）的查看、操作权限，比如某个菜单的可见性

3、关系管理

考虑的是整个组织的管理架构，是一对一还是一对多关系，是否有层级划分，是否有继承关系等。

从这三个关键词中，我们就能理解整个权限管理，解决的就是某个用户在访问系统时，可以查看什么内容，执行什么操作，得到什么结果。

也就是权限控制系统，管理的是用户行为的集合，也就是建立一套用户使用资源的规则。

这个集合来自于产品的“用户画像”，用户拥有的系统资源即可通过标签系统来进行分类管理。

在实际应用中，特别是平台型产品，权限的管理非常严格，同时也非常复杂。比如一个O2O平台有1000个门店就很难通过创建1000个用户分别来分配权限的方式进行管理和维护。

必须要有一个高效的模型解决这种复杂的业务，这个模型就是RBAC。

02

RBAC设计实践

RBAC的思想，即用角色来解耦权限和用户的关系，其目的是解决日益增长的业务所带来的快速增长的用户和权限数量。

传统（早期）的直接为用户配置权限的设计模型，由于其耦合性太高，必然导致维护性和扩展性随业务增长来极速降低，无法支持大型业务平台的运转。

在RBAC模型中，一个用户可以有多个角色，一个角色可以有多个权限，通过将角色和权限分离开来提高设计的可扩展性，通常一个用户有多个角色，一个角色也会属于多个用户（多对多），一个角色有多个权限，一个权限也会属于多个角色（多对多）。

如下图所示：

用户和角色、权限之间，是松散的一对一、一对多甚至多对对的关系，而且这个关系是物理结构上的上下层级关系，带来的好处就是降低平台的耦合性，极大的提高了系统的可操作性和易维护性，数据的安全性也非常具有保障，极大的降低了管理的开销。

回到上文我们设计的用户角色，不管是坐席，门店还是工程师，都可以依据其业务范围和标签属性，就可以轻松的实现对权限的指派和回收。

RBAC认为，权限授权实际上是Who、What、How的问题。who、what、how构成了访问权限三元组，权限的管理用一句话来表达就是：Who （用户） 对 What (资源) 进行 How （行为）的操作 。

Who：权限的拥用者或主体，也就是用户实体。

What：权限针对的对象或资源，可以直接理解为产品界面上的菜单、按钮等

How：具体的权限，查看、操作资源和数据的具体操作。

这个过程可以分解为两个步骤：

我们只需要通过给角色授权，分配每个角色可以查看、操作的功能和数据范围，然后将附有权利的角色施加到某个用户账号，就使得该用户获取了相应系统权限了。

通过“角色”这一层抽象的中间身份，整个系统就变得更为灵活：角色的权限可以随时调整或者被系统回收，每个用户账号的操作权限可以随业务场景的不同而发生改变。

比如，一个工程师登录工程师的界面，则拥有工程师的权限，登录到门店系统，则拥有该门店授权的操作范围。

下图即为一个完整的用户授权实例：

这种设计下，任意一个账号，都可以根据实际业务需要，随时调整权限范围，对大型平台产品而言，这种灵活性非常重要(RBAC模型还可以进一步扩展，比如用户组、角色互斥等)。

从上图，我们也可以发现权限管理必须具备的两项基本原则。

1、职责分离：不同的角色完成不同的业务分工，通过分配不同的角色实现责任的互相约束实现对组织业务和数据的安全管理

2、最小特权：系统可以限制分配给角色的权限多数、大小，为任意账号分配权限，只要不超过该用户完成任务的基本需要即可

也正是因为RBAC的特性，我们在做产品设计时，更应该把精力集中于“用户实体”的实际业务流转过程，关注其行为背后的动机和逻辑，才能够设计一个高效的后台系统。

但，RBAC有一个“缺陷”——没有提供操作顺序控制机制，无法进行严格的操作次序控制，没有办法要求用户先做什么，后做什么，必须借助外部机制来进行控制。

当然，对于权限管理而言，既要充分考虑到系统的灵活性，也要考虑实际的应用程度和研发成本的投入，越是灵活的系统，也就必然带来更多的成本投入，其结果是带来管理开销的节约。

所有优秀的设计，都基于对业务、规则的深刻理解。

越早进行系统的考虑，成本越低，效果也越好。

• 
  

<本文完>

———— /  END  / ————

题图来自 Pixabay

杜松的产品笔记，长按关注