讯享网

 <p><blockquote id="10H259S8">编辑导语：一般市面上的权限设计，都会告诉大家RBAC模型，即把权限系统抽象出来三个实体：用户、角色、资源，这三个实体之间的关系。那么，只有RBAC 模型够用吗？RBAC 模型的使用场景有哪些？一起来看一下吧。</blockquote></p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2022%2F0705%2F032c14faj00reizc000p000bog.jpg&thumbnail=660x&quality=80&type=jpg"/><br/></p><p>一、什么是 RBAC 模型？</p><p id="10H259R3">市面上有很多权限系统的设计都会告诉大家 RBAC 的这个模型，无非是说把权限系统抽象出来三个实体：用户、角色、资源（权限的抽象），三个实体的关系如下图：</p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2022%2F0705%2Fd3a585c6j00reic000wa005ag.jpg&thumbnail=660x&quality=80&type=jpg"/><br/></p><p id="10H259R5">也就是说，角色实际上是人和资源的一个中间桥梁，人通过拥有某个角色而获得这个角色下面所有的权限。如下图：</p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2022%2F0705%2Fe41d0528j00reikc000xs00v4g.jpg&thumbnail=660x&quality=80&type=jpg"/><br/></p><p>1. RBAC 模型的优点是什么？</p><p id="10H259R7">核心优点无非是当用户的工作内容发生异动时，只需要将用户所关联的角色解绑就可以，而不用把用户身上的权限一个一个的删除掉。</p><p id="10H259R8">比如当上面的财务总监李总被降职为普通员工时，只需要把他和「财务」这个角色的关系去掉即可，而不需要去将他原来所有的权限一个一个去掉。</p><p>2. 只有 RBAC 够用吗？</p><p id="10H259R9">实际上，仅仅只有 RBAC 模型，只能够满足一些很小型企业的诉求，大型企业实际上仅有 RBAC 是完全不够用的。</p><p id="10H259RA">如果仅有 RBAC 模型，在大型企业的复杂人员架构和职能里，就会出现「角色」的膨胀，可能会出现成百上千个角色，这是非常难以管理的。</p><p id="10H259RB">那要如何规范管理权限呢？</p><p id="10H259RC">实际上我们并不是说 RBAC 不行，RBAC 只是一个基础，在这个基础之上，我们还应当有一些其他能力，帮助 RBAC 去更好地管控权限。</p><p>3. 场景有哪些？</p><p id="10H259RD">我们在企业内部做授权时，经常发现很多的授权都是按照用户的部门或者岗位来授权的。特别是岗位，比如财务经理就有 XXX 权限，采购经理就有 XXX 权限。于是乎我们很顺其自然地就想到是否给岗位做一个角色呢？</p><p id="10H259RE">在 RBAC 上再抽象一下，所谓的角色，我们可以理解为它既是用户的集合，也是权限的集合。那么如果仅从用户的集合来看，能否再抽象得通用一些，不如我们就叫他「用户集合」吧？</p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2022%2F0705%2F274a5575j00reinc001vo00b2g.jpg&thumbnail=660x&quality=80&type=jpg"/><br/></p><p id="10H259RG">那么，用户的集合，在企业内部通常会有哪些呢？相信你很快就会想到「部门」「岗位」「城市」「职级」等等。详细点说：</p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2022%2F0705%2Fe4a5a1a3j00reioc000sc00bag.jpg&thumbnail=660x&quality=80&type=jpg"/><br/></p><p id="10H259RI">OK，当你抽象为用户集合的时候，你会发现这种用户集合比原来的角色更好用。原因是它可以和企业的 HR 系统联动，当一个用户被调整到另一个部门时，他的用户集合也会自动被调整，当一个用户的岗位被调整时，他的用户集合也会被调整，从而实现与 HR 系统的打通，并且可以减少很多权限的维护成本。</p><p id="10H259RJ">我们姑且叫这种授权方式为「用户集合授权」吧。</p><p id="10H259RK">除此之外，在大型企业里，我们通常还会有一些比较复杂的场景。比如我们要求岗位是产品经理且职级是 P8 的人才能够拥有某些权限。</p><p id="10H259RL">这种场景没有办法按照上面的方式来做用户集合，比如你不能说职级 P8 的人都拥有某些权限，岗位是产品经理的人都拥有某些权限，这两种「用户集合授权」都不能满足这个场景。</p><p id="10H259RM">我们还可以建立一个动态的、按照规则的用户集合，这个用户集合的人是要满足某些规则才能够被加进来的。</p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2022%2F0705%2F51cbaec1j00reisc000vq004mg.jpg&thumbnail=660x&quality=80&type=jpg"/><br/></p><p id="10H259RO">于是乎，我们发现这个可以定义规则的动态的用户集合，它非常地健壮，当某个人因工作内容发生异动时，他马上会被调整出这个用户集合。也能够很好地减少授权工作，让授权跟随 HR 系统地变更。</p><p id="10H259RP">我们叫这种授权方式为「动态用户集合授权」吧！</p><p id="10H259RQ">最后的两种场景通常是用来兜底的。</p><p id="10H259RR">比如我们经常会有一些系统管理员，这个系统管理员跟这个人的属性没有关系，我们不可能有一个岗位叫做系统管理员，也不会有一个部门叫做系统管理员，于是我们这时候只能老老实实去建一个角色叫做「系统管理员」了。我们就叫这种授权为「角色授权」吧。</p><p id="10H259RS">我们也经常会遇到一些人他需要临时开通某些权限，但这个权限在正常的情况下他不应该拥有，那么此时我们可以通过走审批流给这个人授权，但请记住，审批流一定要和权限系统打通，确保审批流通过后，自动地在权限系统给这个人授权。同时，还要记得这种临时授权一定要有权限期限，到期自动收回！我们就叫这种授权为「临时授权」吧。</p><p>二、总结</p><p id="10H259RT">上文虽然比较零散，但实际上我是按照从通用 -&gt; 特殊的场景顺序来介绍的，总共介绍了 4 种场景，下面给你总结一下这四种情况。</p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2022%2F0705%2F0894c753j00reicc0014200gcg.jpg&thumbnail=660x&quality=80&type=jpg"/><br/></p><p id="10H259RV">事实上大家会看到，上面这些方法都只是为了让授权更加简便而已，本质上还是 RBAC 的模型。原因是当组织大了以后，授权这件事是很繁琐的，如果不把授权做得更「自动化」一些，那么权限系统的管理员可能会累死掉。</p><p id="10H259S0">实践中，我们强烈推荐多使用「用户集合授权」，甚至要求 HR 部门配合我们都是应该的，因为我始终认为 HR 和 HR 系统都应该为业务服务。尽可能少的使用「角色授权」，除非你真的没有办法了。</p><p id="10H259S1">上面这些方式并不一定适合你的公司，如果你有一些关于权限系统好的实践方式或者对我的批评指导，可以在评论留言，一起讨论。</p><p id="10H259S2">本文由 @产品经理日常思考 原创发布于人人都是产品经理，未经许可，禁止转载</p><p id="10H259S3">题图来自 Unsplash，基于 CC0 协议</p>