一、什么是 RBAC 模型？

市面上有很多权限系统的设计都会告诉大家 RBAC 的这个模型，无非是说把权限系统抽象出来三个实体：用户、角色、资源（权限的抽象），三个实体的关系如下图：

也就是说，角色实际上是人和资源的一个中间桥梁，人通过拥有某个角色而获得这个角色下面所有的权限。如下图：

1. RBAC 模型的优点是什么？

核心优点无非是当用户的工作内容发生异动时，只需要将用户所关联的角色解绑就可以，而不用把用户身上的权限一个一个的删除掉。

比如当上面的财务总监李总被降职为普通员工时，只需要把他和「财务」这个角色的关系去掉即可，而不需要去将他原来所有的权限一个一个去掉。

2. 只有 RBAC 够用吗？

实际上，仅仅只有 RBAC 模型，只能够满足一些很小型企业的诉求，大型企业实际上仅有 RBAC 是完全不够用的。

如果仅有 RBAC 模型，在大型企业的复杂人员架构和职能里，就会出现「角色」的膨胀，可能会出现成百上千个角色，这是非常难以管理的。

那要如何规范管理权限呢？

实际上我们并不是说 RBAC 不行，RBAC 只是一个基础，在这个基础之上，我们还应当有一些其他能力，帮助 RBAC 去更好地管控权限。

3. 场景有哪些？

我们在企业内部做授权时，经常发现很多的授权都是按照用户的部门或者岗位来授权的。特别是岗位，比如财务经理就有 XXX 权限，采购经理就有 XXX 权限。于是乎我们很顺其自然地就想到是否给岗位做一个角色呢？

在 RBAC 上再抽象一下，所谓的角色，我们可以理解为它既是用户的集合，也是权限的集合。那么如果仅从用户的集合来看，能否再抽象得通用一些，不如我们就叫他「用户集合」吧？

那么，用户的集合，在企业内部通常会有哪些呢？相信你很快就会想到「部门」「岗位」「城市」「职级」等等。详细点说：

OK，当你抽象为用户集合的时候，你会发现这种用户集合比原来的角色更好用。原因是它可以和企业的 HR 系统联动，当一个用户被调整到另一个部门时，他的用户集合也会自动被调整，当一个用户的岗位被调整时，他的用户集合也会被调整，从而实现与 HR 系统的打通，并且可以减少很多权限的维护成本。

我们姑且叫这种授权方式为「用户集合授权」吧。

除此之外，在大型企业里，我们通常还会有一些比较复杂的场景。比如我们要求岗位是产品经理且职级是 P8 的人才能够拥有某些权限。

这种场景没有办法按照上面的方式来做用户集合，比如你不能说职级 P8 的人都拥有某些权限，岗位是产品经理的人都拥有某些权限，这两种「用户集合授权」都不能满足这个场景。

我们还可以建立一个动态的、按照规则的用户集合，这个用户集合的人是要满足某些规则才能够被加进来的。

于是乎，我们发现这个可以定义规则的动态的用户集合，它非常地健壮，当某个人因工作内容发生异动时，他马上会被调整出这个用户集合。也能够很好地减少授权工作，让授权跟随 HR 系统地变更。

我们叫这种授权方式为「动态用户集合授权」吧！

最后的两种场景通常是用来兜底的。

比如我们经常会有一些系统管理员，这个系统管理员跟这个人的属性没有关系，我们不可能有一个岗位叫做系统管理员，也不会有一个部门叫做系统管理员，于是我们这时候只能老老实实去建一个角色叫做「系统管理员」了。我们就叫这种授权为「角色授权」吧。

我们也经常会遇到一些人他需要临时开通某些权限，但这个权限在正常的情况下他不应该拥有，那么此时我们可以通过走审批流给这个人授权，但请记住，审批流一定要和权限系统打通，确保审批流通过后，自动地在权限系统给这个人授权。同时，还要记得这种临时授权一定要有权限期限，到期自动收回！我们就叫这种授权为「临时授权」吧。

二、总结

上文虽然比较零散，但实际上我是按照从通用 -> 特殊的场景顺序来介绍的，总共介绍了 4 种场景，下面给你总结一下这四种情况。

事实上大家会看到，上面这些方法都只是为了让授权更加简便而已，本质上还是 RBAC 的模型。原因是当组织大了以后，授权这件事是很繁琐的，如果不把授权做得更「自动化」一些，那么权限系统的管理员可能会累死掉。

实践中，我们强烈推荐多使用「用户集合授权」，甚至要求 HR 部门配合我们都是应该的，因为我始终认为 HR 和 HR 系统都应该为业务服务。尽可能少的使用「角色授权」，除非你真的没有办法了。

上面这些方式并不一定适合你的公司，如果你有一些关于权限系统好的实践方式或者对我的批评指导，可以在评论留言，一起讨论。

本文由 @产品经理日常思考 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议