后台产品的基石:权限管理体系设计

产品小白专属,10周线上特训,测、练、实战,22位导师全程带班,11项求职服务,保障就业!了解详情

文章作者主要讲解了一些关于后台产品权限设计体系,来文中看看~

什么是后台产品?

简而言之,我们日常使用的互联网应用,有一些需要做数据/信息的呈现,管理维护这些数据/信息的产品,就是后台产品。

举个例子:在音乐app中有很多的歌曲、专辑、歌手等的内容,这些内容都需要在曲库后台中进行上传、信息关联等操作,这里的曲库后台就是一个后台产品。

后台产品为什么要做权限管理?

后台产品中有大量的数据,需要较多的人员来对这些数据进行管理,不同人分别负责管理自己的数据。且不同的人,在整个数据管理流程中,需要进行的操作不同。那么此时,我们就需要对这些人员的权限进行不同的定义,具体人员可以看什么,不可以看什么,从而确保数据的稳定性,降低数据泄露的风险。

同样用曲库后台举例子,有的人负责维护华语音乐,有的人负责英语音乐,那么负责话语音乐的人,不可以操作英语音乐的数据。在负责华语音乐的人中,有的人负责上传歌曲源,有的人负责整理音乐,打包成歌单呈现给用户,那么负责上传歌曲源的人,不可以去进行歌单的编辑。

权限管理的基础:组织结构

人员层级的划分是做权限管理的基础,几乎稍有规模的公司,都会有人员管理层级的划分,我们称之为组织结构,在组织结构中,明确指定人员的汇报关系、负责的业务模块、人员的岗位等等。

组织结构的一个简单示意图如下,节点用于对业务模块、工作范畴进行划分。在一个业务模块内,不同职能的人员,用岗位来进行区分,例如研发进行功能的开发,QA进行功能的验证测试。

权限管理体系如何搭建

权限管理体系可以划分为三个层级:功能权限、数据权限、按钮/字段权限。

  • 功能权限:定义人员是否可以访问某个页面。例如曲库后台,曲库资源的管理人员,可以访问曲库资源的管理页面,不可以访问歌单资源的管理页面。
  • 数据权限:定义人员在页面中,可查看的数据的范围。例如曲库后台,曲库资源的管理人员中,华语音乐管理员可查看华语音乐,不可查看英语音乐。
  • 按钮/字段权限:定义人员针对查看到的数据,可以进行的操作,或可查看的字段。例如曲库后台有歌曲的上传和删除的操作,曲库资源的管理人员中,上传资源的人员只能看到上传按钮,不可查看歌曲的删除按钮。只可查看歌曲的基础信息,不可查看歌曲的定价信息。

从上图和上面的描述举例中,可以看出来,这三层权限控制是逐渐递进的关系,从最基本页面访问,到具体数据信息操作,对于权限的粒度管理越来越细致。

那么基于这个理论基础,在设计上如何实现呢?

  • 功能权限:页面是具体功能的一个实现,而功能的使用与人员的职能相关,结合我们前面讲的组织结构可以得出,功能权限与岗位密切相关。因此我们做权限配置时,可以考虑将岗位与页面权限绑定,这样在岗位人员更替的过程中,只要岗位职能不变,那么我们对岗位和页面权限的绑定就是无需变更的。例如编辑人员拥有曲库编辑页的权限,运营人员拥有歌单编辑页的权限。
  • 数据权限:同岗位的人员负责不同范围的数据,那我们可以通过定义人员可查看自己负责标签范畴内的数据来实现数据权限的管控。如果数据量特别大,同岗位的人员也需拆分给不同的管理人员来管理,甚至管理人员还是多层级的,那么此时就需要借助组织节点一起定义数据权限,最末级节点人员查看自己标签范畴内的数据,上级节点的人员查看自己下级节点人员的数据汇总。
  • 按钮/字段权限:按钮/字段权限本质上还是对一个功能的控制,只是这个功能内嵌于页面内,比页面的颗粒度更细,所以按钮/字段权限可以和功能权限一样,与岗位绑定。

权限管理体系的丰富拓展

上述的三层权限体系可以满足我们基础的权限控制的需求了,但是在一些特殊的情况下,有一些上述体系不能满足需求的情况,该怎么去拓展这个权限控制体系呢?

以下列举了一些:

场景一:同岗位的员工,进一步进行了工作模块的划分,希望他们可以拥有不同的功能权限

对于岗位通用的权限,我们可以用岗位与权限绑定来配置。若同岗位员工的工作模块不同,有一些权限不可直接赋予岗位,而是与具体人员关联时,可以抽象出一层虚拟角色,这些角色集成一个工作模块的特殊权限,然后将角色直接赋予具体的人员。

这样可以用虚拟角色来进行权限的规范管理,同时又能满足同岗位人员需要配置特殊权限的情况。

场景二:某些员工临时支援他人工作,需要临时拥有一些功能和数据权限,但是组织结构不可调整

组织结构中的岗位和节点上下级关系,定义好了人员的全部权限。当对象的组织岗位关系不可调整,但是需要添加对象的各项权限时,我们可以通过加成权限来实现。加成权限就是指人员拥有自身所在组织岗位的权限,同时还可以拥有特殊配置的权限。

这个特殊配置的权限怎么配呢?

这个配置的基础结构时,配置对象在某些系统中拥有某些节点岗位的全部权限。我们把配置对象、某些系统、某些节点岗位拆开描述如下。

  • 配置对象:这个要临时添加权限的对象,可能是员工,可能是某组织节点全部人员,甚至某岗位全部人员,因此这个配置对象可以根据需求去拓展,支持多选。
  • 某些系统:一个大的后台中可以进一步拆分系统,如果需要限制是这个加成权限只在部分系统生效,那我们可以增加生效系统的配置。
  • 某些节点岗位:这个就是配置对象具体需要什么节点岗位的权限,在某些节点岗位这一环节中配置。

场景三:某些非顶级节点的员工,需要拥有全部数据的权限;某些有问题的员工,不可拥有任何数据的权限

这个是最简单的,可以通过添加人员的白名单和黑名单来解决。白名单中的员工,默认赋予全部数据的权限。黑名单中的员工,默认不拥有任何数据的权限。

白名单和黑名单的赋予,支持给通过节点、岗位、人员来配置,操作更灵活方便。

以上是我对后台产品权限设计体系的一些分享,希望对进行后台产品设计的初级同学有一些帮助,欢迎留言一起交流。

 

作者:张三,5年互联网产品经理经验,同时主导过C端和后台多项产品设计。

本文@张三 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
4人打赏
评论
欢迎留言讨论~!
  1. 数据权限里包含字段权限,所以正确的从下而上的顺序:数据权限、功能权限,这两个里头再细分

    回复
  2. 话说这个功能、数据、按钮/字段权限的划分是否会有重复?我现在做的都是按菜单、页面(包含字段、按钮)、数据权限来,实际应用上感觉更清晰。

    回复
    1. 这个划分本质上是对权限从粗到细的的一个划分框架,每个权限都对应一个数据对象,所以没有重复

      回复
    2. “数据权限:同岗位的人员负责不同范围的数据,那我们可以通过定义人员可查看自己负责标签范畴内的数据来实现数据权限的管控。”
      请问这个节点的标签范围以什么作为区分?

      回复
    3. 节点标签范围的区分要看具体的业务场景。例如在曲库的后台管理系统中,可以用音乐的语言来作为标签,将标签作为资源添加至组织节点岗位,甚至到人员,从而达成对人员细分数据权限的管控

      回复
    4. 节点标签范围的区分要看具体的业务场景。例如在曲库的后台管理系统中,可以用音乐的语言来作为标签,将标签作为资源添加至组织节点岗位,甚至到人员,从而达成对人员细分数据权限的管控

      回复
    5. 我的理解是这个就是字段

      回复
    6. 文中我所提的字段,一般是一条数据的字段信息,例如一首歌的作曲者、专辑、歌手等等

      回复
    7. 音乐的语言和歌的作者/专辑/歌手我看来是同一个维度的字段,如果是这个产品没必要再分出一个数据权限,通过字段控制就可以了。可能是理解的角度不同,你分得清就ok

      回复
    8. 不对,数据权限还是要分出包含在字段下面,这样层级会比较清晰

      回复
    9. 目前我也在做cms配置系统管理,组织机构存在多级,涉及账号与权限管理,方便加个微信沟通下吗?我的微信1152481807

      回复
  3. 因为有这样的需求:经常会加入临时的账号,而且该账号的权限也是待定的,就比较棘手。把权限挂载在每个角色下面,又会因为有上百个角色,操作太麻烦了。

    回复
    1. 这种情况下,建议先做需求的梳理。针对经常性的临时账号和临时权限赋予,梳理一个清晰的业务流程,将临时账号统一在一起管理,同时对临时账号的权限做规范化的管理,而不是来一个账号,加一次个性化权限。权限规范化管理可以考虑把系统角色再打包,建立申请、审批、自动配置流程

      回复
    2. 如果总是有临时账号权限待定的话,那建议先梳理需求,看看历史临时账号的使用场景和需求情况,将临时账号和账号的权限规范化管理

      回复
  4. 关于后台复杂权限设计有一套RBAC的体系,可以参考。

    回复
    1. 对是的,RABC权限体系适用于功能权限和按钮/字段权限的管理,这块在场景一中略有提及,未展开😄

      回复
  5. 如果用户体系过于庞大而繁杂,那权限管理模块应该单独做出来?还是挂载在用户管理模块下,即给每个用户分配权限?

    回复
    1. 你的用户管理应该不是指OA里用户信息的管理,如果是本文中所述的用户管理,本身就是为了权限而设置,应该包含在【权限管理】里面,一般权限管理下有用户和角色管理两项就够用了,而且用户庞大的情况下就需要分开角色和用户,单纯的只设置用户并赋权限只适合用户少且人员稳定的系统

      回复
    2. 应该单独做出来,因为给用户单独配权限需要耗费人力资源。单独做出来,抽象岗位或虚拟角色可以把很多权限处理操作做成自动的

      回复
    3. 是的,我的做法是把权限与角色绑定,然后在角色下新建用户的时候就不用配权限了,但是我的项目有上百个角色(政府项目,所以有上百个部门),而且不同角色的权限要求也不同,请问怎么做优化呢?(有人建议我在角色的基础上再抽象一层,叫“角色类”,形成角色类——角色——用户的体系,然后依据每个层级的共性赋予默认权限,有点像电商类目的属性继承。这样可以吗?)

      回复
    4. 角色的设定也是一次性工作,政府的角色非常的固定,如果后续不会大幅度变动的话,将所有角色统一初始化会是一个比较简单的方法,后续也只需增加用户并将