百木园
一、什么是 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 系统都应该为业务服务。尽可能少的使用「角色授权」，除非你真的没有办法了。
上面这些方式并不一定适合你的公司，如果你有一些关于权限系统好的实践方式或者对我的批评指导，可以在评论留言，一起讨论。
给作者点赞，鼓励TA抓紧创作！
来源：https://www.woshipm.com/pd/5513836.html
本站部分图文来源于网络，如有侵权请联系删除。