系统权限设计思路方法总结.pdf

系系统统权权限限设设计计思思路路⽅⽅法法总总结结

⼏乎所有的管理后台都会涉及到权限的设计，权限控制是管理后台的要功能，可以有效的提⾼系统的安全性，减少误操作、数据泄漏等风险

的发⽣。但是，很多产品经理会对权限功能有⼀点害怕的⼼理，⼀⽅⾯是由于能参考的实例较少，权限管理算是⼀个“系统级”的基础功能，⼀般

系统中只有管理员可以操作，不像其他功能可以通过去其他系统中试⽤体验，另⼀⽅⾯，对于权限功能普通⽤户⽆法操作使⽤，所以存在感较低，

做好了也不会出彩，可没做好就会导致整个流程不通、产品崩溃。

⼀RBAC模型

⽬前，接受度较⾼的功能权限模型是RBAC（Role-BasedAccessControl）模型。在RBAC中，权限与⾓⾊相关联，⽤户通过成为适当⾓

⾊的成员⽽得到这些⾓⾊的权限。这就极⼤地简化了权限的管理。在⼀个组织中，⾓⾊是为了完成各种⼯作⽽创造，⽤户则依据它的责任和资格来

被指派相应的⾓⾊，⽤户可以很容易地从⼀个⾓⾊被指派到另⼀个⾓⾊。⾓⾊可依新的需求和系统的合并⽽赋予新的权限，⽽权限也可根据需要⽽

从某⾓⾊中回收。

1.⾓⾊的作⽤

如果没有⾓⾊的概念，直接⽤户对应权限，虽然会更加灵活，但是后台的数据表设计会变得复杂，操作成本也会很⾼，同时容错能⼒也会变得很

差。

⽽引⼊“⾓⾊”概念后，⽤户与⾓⾊可为多对⼀或多对多的关系，当⼀个⽤户的⾓⾊为多对多时，当前⽤户的权限是多个⾓⾊的并集。此时只需要

为⾓⾊赋予权限，能够⼤⼤减轻管理负担，同时将⽤户与权限解耦，提供更⼤的灵活性，同时整个设计的容错能⼒也提⾼了很多。

2.引⼊⽤户组

⼀些⼤型的平台上，如果⽤户数量较⼤，新增⾓⾊时，需要为⼤量⽤户分配新的⾓⾊，⼯作量巨⼤，此时可以引⼊⽤户组的概念，将这些⽤户拉

到同⼀个⽤户组中，然后对整个⽤户组进⾏⾓⾊的指定，这就⼤⼤减少了⾓⾊分配的⼯作量。

同理如果权限较多时也会存在⼀样的问题，对⾓⾊进⾏权限设置时也需要⼤量的操作，此时可以考虑引⼊权限组的概念，将关联性较强的权限⼤包

成组赋予⾓⾊，从⽽减少赋值时的⼯作量，现实中权限组的使⽤相对较少，因为系统中的权限⼀般来讲是有限的。需要注意的是即使有⽤户组或权

限组的存在，也可以允许⽤户或权限与⾓⾊直接关联，这个可以视具体业务情况⽽定。

下图所⽰为mac系统中运⾏添加⽤户组，并以⽤户组为单位配置权限。

3.⾓⾊继承的RBAC模型

在⼀个业务场景中，如果⾓⾊需区分：设计主管、设计组长、设计成员，并且管理⽅式为向下兼容时，则需使⽤⾓⾊继承的RBAC模型。上层⾓⾊

继承下层⾓⾊的全部权限，且可额外赋予权限。

此时除了对⾓⾊进⾏定义，还需要管理⾓⾊间的关系，通过关系来体现⾓⾊的层级关系，从⽽达到继承权限的效果。⾓⾊的继承关系主要有两种：

树形图和有向⽆环图。

继承关系常常来源于公司团队的组织结构，此时常将⾓⾊与组织结构进⾏关联达到继承⾓⾊模型的效果。如下图所⽰的赵同学，其⾓⾊是“三级团

队负责⼈”，与其并列的⼩组中有多个“三级团队负责⼈”的⾓⾊，但依附于左侧的组织结构树，各级负责⼈仅有查看和操作⾃⼰下属⼦节点的权

限。

4.限制的RBAC模型

在⼀个产品或系统中，部分⾓⾊可能是需要隔离的、不允许被同时赋予⼀个⼈的。跟⼤家熟知的“不能既是‘运动员’⼜是‘裁判员’”⼀个道

理。

因此，对于众多⾓⾊中的⼀组，只能是单选的关系，但多组⾓⾊之间可以共同存在。如下图中，⼀个⽤户可以既为设计师⼜为管理员，但在设计师

⾓⾊组中仅能被赋予⼀个⾓⾊，在管理员⾓⾊组中也仅能被赋予⼀个⾓⾊。

此外，限制还有可能是数量上的，⽐如⼀个产品组中必须有且只有⼀个管理员，不允许删除或再分配管理员⾓⾊，仅允许将负责⼈⾓⾊变更。

限制的模型不仅仅对分配过程产⽣影响，有时即使拥有了多种⾓⾊，因为不同的⾓⾊对同⼀个功能的使⽤⽅式或数据会产⽣冲突，所以使⽤时也需

要进⾏限制。如下图所⽰为同⼀时间仅允许以⼀个⾝份登录。

根据不同的业务需求，限制的形式很多。需要注意的是不能仅依赖后端限制，⽽是要在前端展⽰清晰的规则和恰当的限制，避免⽤户出错和沮丧。

三、权限的拆分与设计

通过RBAC模型已经能够很好的搭建起⽤户、⾓⾊与权限之间的关系了。但具体是什么样的关系，以及“权限”这个抽象的概念具体如何规划？

这些都需要分析清楚才能进⼀步设计出完善的权限系统。

⾸先需要知道，⼀般产品的权限由页⾯、操作和数据构成。页⾯与操作相互关联，必须拥有页⾯权限，才能分配该页⾯下对应的操作权限。数据可

被增删改查。

整体关系如下图所⽰