权限管理，就是解决 “Who对What(Which)进行How的操作” 问题。
<让产品从0到1> 第 13 辑
文 | 杜松，公众号 | 产品微言
前文我们讨论了 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有一个“缺陷”——没有提供操作顺序控制机制，无法进行严格的操作次序控制，没有办法要求用户先做什么，后做什么，必须借助外部机制来进行控制。
当然，对于权限管理而言，既要充分考虑到系统的灵活性，也要考虑实际的应用程度和研发成本的投入，越是灵活的系统，也就必然带来更多的成本投入，其结果是带来管理开销的节约。
所有优秀的设计，都基于对业务、规则的深刻理解。
越早进行系统的考虑，成本越低，效果也越好。
<本文完>
关注公众号：产品微言，回复“从0到1”，即可下载 本系列 完整 PPT
248
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
