当前位置:首页 > 运营 > 正文

数据权限管理设计(数据型产品的权限管理想要做好不容易)

角色权限管理类似于一个系统的基础设施建设,重要程度虽不及其他核心功能,但却是必不可少的其中一环,而且随着产品内容和逻辑的增多,角色权限处理发挥的价值会日渐体现出来。本文将以我做过的一个角色权限设计为例,浅析其中的逻辑,供大家参考。

由于公司有统一的域库存储用户信息,包括入职离职人员的信息更新,因此我们此处的用户管理是在已有用户群(并且可实时同步数据)的基础上进行角色权限的把控。此模块架构如下:

数据权限管理设计(数据型产品的权限管理想要做好不容易)  第1张

整个模块为用户管理,下分三块分别是:

部门组织架构所有部门人员信息的在线展示以及对应的人员列表,此处同步公司域库数据,附加了当前在线状态的显示角色权限管理此处分为角色组的建立以及对应权限的把控,角色组以及所属成员按需创建和添加,建完之后对应做权限的控制,包含功能权限、资源权限、数据权限、集成系统的访问权限。权限申请管理此处是针对权限管控后,用户对无权限资源进行的权限申请处理以及对应的权限赋予操作(权限批复结果会自动生成消息通知,与公告消息相通)

上述组织架构和权限申请部分基本很容易理解,逻辑相对复杂一些的当属角色权限管理这部分,先看一张关系图:

数据权限管理设计(数据型产品的权限管理想要做好不容易)  第2张

做好权限管理有以下几个重点:

人员组成要灵活

这部分的人员组成不一定是按照岗位角色来的,有可能是跨部门跨岗位形成的自定义角色组,因此不能直接套用之前的岗位角色,需要可以创建新的角色组,当然角色组多了还可以给角色组分大类,以便更清晰一些

权限覆盖要全面

权限常规来说可以分为功能权限、数据权限、资源权限,当然根据产品不同也可能有更多的权限分类。大到每个顶部导航模块,小到页面上每个功能按钮,都属于权限的范围。与此同时资源内容的全量呈现还是部分呈现就涉及到资源权限的管控;有的数据我能访问,你不能访问,这种权限的区分把控在于数据权限的设置。

在上述案例中,我们的数据权限采取的是黑名单制,顾名思义就是我选择谁不能看到哪些数据,默认情况下是所有人可以看到所有数据,这个可以根据具体情况进行正反向设计。比如大部分都是可看的,不可看的是少数,那么就用黑名单方便一些;如果大部分都是不公开的,只有少数是公开的,那么白名单会更方便一些,因情况而异。

权限把控要灵活

正常来说角色权限管理对于一个需要此方面把控的产品来说就像空气一样不可或缺,虽然我们不常注意它的存在,但是用的时候一定要确保其规范、安全、可靠。

之前我们在做的过程中有过这样的一次经历,一般被赋予了某个角色的人员具有把私有表转为公共可见表的权限,而对应的删除操作,当时开发则做成了谁建的表谁删除,其余人即使有同样权限也不能进行删除这样的模式。

在一次不经意操作中我们发现共同拥有这个权限的人删除不了别人建的公共表,我跑去告诉同事说这张表是他建的,需要他删除,然后我就去了洗手间,但顿时感觉这样的逻辑存在问题,假使十个人建了十张表然后都转为公共表了,那么如果这十个人离职了,这些表还非这些账号不能进行删除操作了吗(不包含开发同事从数据库删除的情况,因为我们设计产品的最终目的就是减少进行数据库的操作,最大化方便使用并且逻辑合理)

因此意识到这一问题后,我们小组立即进行了讨论并且及时做了更新。虽然这样也存在不是表的主人删除他人表的可能性,但通常来说,第一,这样的情况相对较少;第二,对应的解决方案是可以通过把删除表的功能只赋予一个最高管理员,其余角色不能随意操作,这样来管控。总之要保证权限把控的灵活性,这是第一原则。

实际情况其实更复杂一点,因为我们还涉及私有表可删除(所有人都有的功能)、可移动到公共表(部分被赋予权限的人员具有的功能,无权限人员不显示此操作按钮);公有表的查看(所有人都具有的功能)、公有表的删除(部分被赋予权限的人员具有的功能,无权限人员不显示此操作按钮)等,那天本来约了人,但为了调这个并和开发讲清楚,赴约都临时取消了(捂脸)。

权限申请要智能

权限申请其实和之前的权限把控是对应的,有的权限是把控之后,相应用户看不见被屏蔽的痕迹,也没有申请入口,而有的可以做成暂无权限的提示,同时提供申请入口。

在上述案例中,我们在部分屏蔽场景中提供了权限申请的入口,当用户点击申请后,会自动在后台接收一条权限申请的消息,上面显示申请人基本信息、申请源、申请时间以及批复操作(通过/拒绝),具体的申请处理流程如下图:

数据权限管理设计(数据型产品的权限管理想要做好不容易)  第3张

在这块令我比较欣慰的一点是我们的技术同事把权限开通做的相对智能化了一些,即在通过权限申请的时候,相继会产生2条动作,一个是在上述的角色权限模块自动开申请用户开通相应权限(包含功能权限、数据权限和资源权限),另一个则是在开通流程走完之后把申请反馈通知发送到该用户的消息账户,这两个任务完成后,即权限申请“通过”,整个流程基本在1秒内完成。当然即使开放后的权限未来也有可能被收回,所以这块的灵活性是毋庸置疑的。

正如开头所说,角色权限管理并不出众,但属于必不可少的基础设施建设,若同一公司内很多产品都涉及这块,其实是可以封装成一个相对通用的产品方案,以免重复造轮子。

以上是我对之前做过的角色权限管理的理解,当然根据产品各异,繁简程度不同,角色权限管理也是可大可小,希望能给大家提供一些思路,也希望在今后工作中能不断精进。

一起加油!

取消
扫码支持 支付码