权限管理是SaaS产品中最基础却最容易被忽视的“隐形骨架”。一旦设计失误，轻则引发客户操作混乱，重则导致数据泄露、信任崩塌。RBAC（基于角色的访问控制）模型之所以成为行业标准，正是因为它用“角色”这一中间层，将指数级复杂的用户-权限关系简化为可维护、可扩展的结构。对于从0到1搭建系统的产品经理而言，理解并掌握权限设计，是构建可信、可扩展产品的必修课。
我自己带过不少产品经理，结果发现很少有人做过权限管理模块的设计，或者设计过的也比较混乱。我之前觉得挺诧异的，因为权限管理应该是非常核心的模块，就算没设计过也应该懂得基本的概念。后来才想明白，实际上是很多产品经理都是负责单个模块，没有经历过从0-1的过程。权限管理模块，往往在一开始就设计好了，所以如果没有经历过从0-1的产品设计，是很难有机会负责权限管理模块的设计的。
权限管理模块一经设计，要更改是非常麻烦的，对于 SaaS 产品更是如此。想象一下，如果我们更改了租户业务系统的权限设置方式，意味着所有租户都需要重新去调整每个角色，甚至每个人的权限（我们也踩过类似的坑）。
此外，如果权限设计出现纰漏，影响客户的日常管理的话，会引发信任问题。这种在不分库分表设计的 SaaS 平台非常常见。比如，我最近用的某个 SaaS 接口服务平台，就发现某些页面刷新后居然能够看到整个平台的运行数据。同样的，如果租户间的数据没有做数据隔离，那么很可能因为权限设计问题，导致租户间能够看到彼此的数据。由于租户之间很可能是同行竞争关系，这种纰漏引发的信任度下降很难修复。
所以我们会看到，一方面权限管理是一开始就需要设计的模块，是一个非常基础的模块；另一方面，如果设计出现问题对整个租户的业务和平台的信任度都会有很大的影响。因此，权限管理是非常核心的模块，我们在设计产品时必须考虑周全。
在早期的企业信息化系统中，往往使用系统的人并不多，因此授权可以按用户账号进行。
这里我们会发现，如果有 N 个用户，M 个权限点，就意味着授权的组合会有 N 的 M 次方种。随着用户数的增加或系统的复杂性增加（权限点增加），就会导致整个授权的组合呈指数增长。这样带来的问题是：授权操作变得复杂，授权时每个用户都需要勾选一遍权限点，很繁琐。权限管控很难，每个用户具体有什么权限不清楚。
在企业管理中，我们会发现实际上大部分情况下，相同岗位、相同职级的人员的权限是相同的。对于这些相同的权限，就可以引入一个授权的中间对象，来简化去A授权管理，这个中间对象就是角色（Role），由此得到了 RBAC 授权模型。
RBAC：Role Based Access Control，基于角色的访问控制，访问控制实际上就是权限控制。
大部分情况下，用户和角色是一对一的关系，当然也存在一人兼任多岗的情况，因此实际上要支持一个用户对应多个角色。我们来举个例子，假设有100个用户，30个权限点，这100个用户可以分为10个角色。我们假设用户和角色是一对一的。授权时假设按逐个权限点勾选的方式进行，平均权限点是15个。那么没有增加角色时，需要操作100×15 = 1500 次勾选操作。增加角色后，用户勾选角色，只需要100次操作，然后角色勾选权限点变成了10×15 = 150 次勾选操作。对比之下，引入角色后的操作次数是没有角色的1/6。这还只是一方面，如果要调整人员权限，没有角色的话，就需要对所有涉及到的人员都操作一遍。引入角色后，则只需要调整角色对应的权限，角色下人员权限会跟随角色自动调整。
如果 SaaS 产品是针对某个业务领域或者垂直行业，比如 CRM，那么很多角色是可以预设的，这样可以简化租户侧的授权管理。比如在纷享销客中，就内置了 CRM 管理员、CRM 观察者、市场管理者、市场人员、销售人员和售后人员等预设角色。
预设角色推荐是在 SaaS 平台去配置，配置好之后同步给各个租户。这里需要注意的是，租户是可以对预设角色的权限进行更改的。因此，预设角色对应的权限点的数据需要做到不同租户间相互隔离。同时，不建议平台去修改预设角色的权限，因为这样再同步的话，会导致租户看到的权限和他们设置的权限不同。这种情况，会让租户认为平台操作了他们的数据。
因此，对于预设角色，虽然会简化租户的权限设置，但是需要注意两点：产品不成熟阶段（需要到 GTM 阶段）不建议设置，这个时候权限点可能会调整。当然，如果产品规划很详细也没问题。预设角色权限如果进行了调整，对新客户可以直接同步，对于老客户，建议通知客户自行处理，或者体验好一点，让他们确认是否按调整后的更新权限。这种情况，不要直接对老客户的进行调整，可能会影响客户的业务运行。
这个根据需要来确定，如果角色过多，分组还是有必要的，比如平台侧可以分为产品、开发、运营、市场、管理等等组。当然，如果是租户侧，那么建议是支持租户自己对角色进行分组，毕竟每家企业的管理模式不同 —— 作为 SaaS 平台，应该把业务规则交给客户去配置。
另一种情形是客户是全国性的集团企业，他们在全国各地有分公司。可能的情况是，每家分公司的管理模式会有差别，这种差别反映到角色上就是每家分公司需要自己管理自己的角色，以避免其他公司修改影响业务。我们就遇到过这样的情况，同样一个收费员岗位，有的分公司支持作废单据，有的需要审核由上级作废。这个时候，角色本身需要作为一个业务对象进行数据授权，来控制管理范围（即 A 分公司只能管 A 分公司的角色，B 公司只能管B 分公司的角色）。实际上，这也是一种角色分组，我们可以按组进行数据范围授权即可。
RBAC 的原型设计本身并不复杂，一个是角色的管理，另一个是角色权限的分配。同时，为了查看当前角色下的有哪些人员，会有一个角色成员管理。
角色管理原型如下，左侧按分组展示角色清单，鼠标点击某个角色时可以查看该角色权限（这里是菜单权限，数据权限后续再讲）和角色成员。鼠标停留在角色名称上时显示编辑和删除按钮。这里需要注意，如果角色下已有成员，则不能删除该角色。对于删除这类操作，如果存在依赖该条数据的关联数据，则不允许删除。编辑角色可以修改分组和角色名称。
编辑权限实际上就是允许勾选授权的菜单进行保存，我们应该支持所有菜单都不勾选，也就是将角色的权限清空。编辑权限的原型界面如下。
角色成员管理比较简单，一般是列出账号对应的人员姓名、账号、所在部门等信息，然后支持批量添加或移除成员（可以使用穿梭框组件来做交互）。这里就不再画相应的原型了。公众号消息回复“权限”可以查看在线原型。
我们在产品设计过程中，需要发现不同模块的相通之处，这样就可以提炼我们自己的产品设计模型。以 RBAC 为例，如果回顾我们之前的销售版本管理和客户授权的话，就会发现，本质上其实是一样的。销售版本就相当于是RBAC 里的角色，我们基于版本对客户进行授权，从而可以简化 SaaS 平台的客户授权操作。本质上，就是将具有共同特性的部分单独抽象出来一个新的中间业务对象，从而可以简化我们业务操作，提高效率。
本文由人人都是产品经理作者【产品海豚湾】，微信公众号：【产品海豚湾】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。