当前位置:首页 > 抖音教程 > 抖音资讯 > 本文内容

【干货】BAT资深产品和你聊聊数据权限管理

发布时间:2022-09-10 10:50:01源自:https://www.it-th.com作者 :it谈话网阅读(363)

初次见面,我是在探索路上不断为大家排(踩)雷(坑)的Snowki。



相信米拉桑看过很多文章数据采集、数据预处理、数据存储,再到数据分析及应用,比如用户画像个性推荐等等。大家围绕数据思考总结这么多攻城宝典,无疑在传达着一个信号:数据越来越值钱。


是的,数据作为互联网重磅资源,对于一些数据公司更是核心竞争力。值钱的东西在爸妈那个年代会用保险柜锁着,那当今值钱的数据更加不可能裸奔。所以,今天这篇文章,就是从0到1来了解数据权限管理的知识体系及应用。


产品经理Snowki新入职某电商互联网公司,接手负责数据系统的管理,领导对Snowki说:“这些数据敏感。” 并配上一个“你懂的”的表情。所以每次有同事要数据或开通数据权限,特别是人多的时候,Snowki总是焦头烂额,她得先判断来者用途,再一个个相关数据,逐个表勾选导出给人设置权限。



1、是否有必要对数据做权限管理呢?大家不都是自己人吗?


2、这样的权限管理是对的吗?感觉只是多了个负责开权限的打工人在中间层持续搬砖。


3、一个个勾选数据表来开权限真的要命,是否有更高效的办法将数据模块化管理起来


4、针对同样的数据权限需求,有没有哆啦A梦的圆手可以帮忙ctrl&c+v一下,真的不想牺牲重复劳动。


于是,Snowki为了把自己从繁琐重复的权限搬运工诅咒中解放出来决定重新审视和优化这个数据系统的权限管理,踏上自救之路

一、什么是权限管理?

首先,我们需要理解什么是权限管理。


权限管理一般作为数据系统的重要组成部分,通过控制账号的可支配能力,防止因用户操作不当导致的数据泄露、数据篡改等问题,同时,对敏感数据按查看角色进行隔离,避免不相关的人看到应该了解的数据,达到风险管控的效果


们最常听说的一些权限管理,由浅入深分别是:账号管理、菜单管理、页面管理、角色管理(RBAC权限设计模型),后面我们会详细铺开。

开篇时已经提及,数据是互联网时代下可变现的产物,竞争对手可以根据你的数据做出应对策略市场产生恶性竞争等。如果不做权限管理,做个设想,数据系统里面很重要营收数据和画像分析,没有任何门槛把控,公司所有人都可以查看&导出,互联网又是人才流动性居高的行业,不排除有误删库、恶意篡改、将数据卖给竞争对手等行为。于是弹指一挥间,公司数据护城河就这么没了。



所以,既然我们费劲劳苦将数据挖掘、搬运并加工可视,为何不为其安全着想,套上爱的枷锁。

在设计数据的权限管理之前,我们先来了解几个关键组成元素


一般由公司发放员工,员工需要有相应的账号才能登陆数据系统,相当于标识员工的唯一令牌,去控制该账号拥有的权限能力及操作范围。


涉及最多的是数据权限、操作权限、页面权限。


对数据进行控制、隔离,保证敏感数据的安全,让数据相关者看到合适的数据,将数据不相关者杜绝在外。

可根据业务部门、业务场景或业务职能进行数据权限区分,比如A区销售能看B区销售的数据,客服不能看到给销售看的销量指标等等。


操作大多分为写(增删改)和读(查看),操作权限可控制用户是否可读写的能力,例如用户A的操作权限是可读,则他只能查看数据,不可编辑数据,一般通过页面某些按钮做控制,既用户A无法点击或看不见「编辑」按钮。


简而言之,就是用户能进入的菜单范围,通过菜单权限可以控制用户的菜单显示,例如,不希望用户A看到库存数据,则用户A登录数据系统后,菜单栏上不会有库存数据页面的入口


角色可理解为多个权限的集合载体。

通过将几个权限搭配构成一个角色,这种角色再设置到账号上,账号就能行使角色所承载的多个权限。

这样,方便我们对权限做标准化管理,可以根据员工部门、职位所需,匹配相关角色,提高配置权限的效率。

在对数据系统搭建权限管理时,我们会受到很多客观因素的影响,比如研发资源、上线时间、数据量级、数据重要程度、风险评估等等,导致选择权限管理的方案会不同。接下来,从搭建难度、数据管理精细度、抗风险能力等多维度,分别介绍:账号管理、菜单管理、页面管理、角色管理(RBAC权限设计模型)


这种方式是比较粗犷的,直接将账号权限分为2种,一种可以理解为超级管理员,能给别的账号开通权限另一种就是普通账号,需要管理员授权才可访问系统。既,账号管理是通过超级管理员的账号权限对数据系统进行准入管控:


如果超级管理员判断无疑,就会给普通账号开通权限,普通账号即可进入数据系统做任何操作(除了给别的账号开通权限)。


如果超级管理员判断某普通账号有风险或该员工离职了,可以对该普通账号进行权限删除或停用,这样会一刀砍掉普通账号的所有权限,无法继续登陆数据系统。


搭建难度:一星

数据管理精细度:一星

抗风险能力:一星

权限管理效率:二星

适用于:刚搭建起来的数据系统,还没太多数据内容,数据也没做细分,并且需要紧急上线,只解耦出核心部分进行一期工程开发


这种方式较账号管理来说稍微好些,将数据体系按照菜单进行模块化管理,对不同账号可进入的页面进行权限区分。既,菜单管理是通过账号的菜单权限对数据系统进行使用范围管控:


开通菜单权限的账号,可以在相关页面做各种数据操作。

没有菜单权限的账号,并不会在菜单上看到相关页面入口。


搭建难度:二星

数据管理精细度:二星

抗风险能力:二星

权限管理效率:三星

适用于:已经有一定数据体系的数据系统,数据会根据业务部门或业务场景进行聚合归类、拆分,形成一、二甚至三级菜单下的页面,页面上没有过多的操作需要做权限区分,比如编辑、删除、新增、查询按钮等。


页面管理相对前面两种方式就更为具体会在页面的数据字段和按钮做出区分,不同账号权限在相同页面可以看到不同数据内容及操作。既,页面管理是通过账号的数据权限和操作权限进行页面内容管控:


1、开通读写权限的账号,可根据页面实际可操作情况进行新增、删除、编辑数据(也有页面会根据业务实际需要,将增删改分成3种操作权限进行区分配置)。

2、开通只读权限的账号,只可查看页面数据内容,无法对页面进行操作,按钮一般置灰或者不显示。

3、开通全部数据权限的账号,可看到所有数据字段。

4、开通部分数据权限的账号,只能看到有权限的数据字段,页面会屏蔽掉不相关的数据字段。


搭建难度:四星

数据管理精细度:五星

抗风险能力:四星

权限管理效率:一星

适用于:需要支撑复杂业务的数据系统,数据繁多,业务部门、业务场景或业务职能划分较细,需要对数据进行高强度保护,有必要对页面的数据字段和操作做区分。


页面管理虽然将数据系统做了较精细的权限区分,但当页面拆解的内容越来越多时,问题就出现

1. 每次有新的账号需要使用数据系统,就要手动配置一遍这么多权限,重复劳动

2. 当有新的权限出现时,又要再做一次账号关联,工作量大。

这样的权限配置显然是很低效的。因此,引入角色管理,将权限灵活组合起来,标准化管理,杜绝低效配置权限,减轻权限管理负担。


说到角色管理,就不得不提BRAC模型(Role-Based Access  Control),我们可以通过下图帮助理解:



从图中我们获取信息有几点:


权限&角色:

多对多关联。

多个权限组合,形成一种角色。

同时,多种角色可以关联同一个权限。


角色&用户:

多对多关联。

一种角色可以赋给多个用户。

同时,一个用户可以关联多种角色,从而行使角色承载的权限。


用户组:

当用户量较大时,新增一个角色需要为多个用户关联,就要为大量用户逐个分配角色,工作量大且重复低效。

这时引入用户组的概念,将业务部门、场景或职能相同的用户打包为一个组,便极大解放双手。


例如,美妆商品运营组由于组织结构调整开始接管母婴商品,那母婴的运营数据角色可直接关联上美妆商品运营组,一键就能为该组下所有账号新增角色,完成权限调整。



* 同理还有权限组的概念,但是笔者认为并没有必要,实际工作中也少见,因此不做补充介绍。


模型约束条件

图中未展示文字补充如下几个常见限制


角色互斥:

角色A和角色B不能同时赋给一个用户。


数量限制:

一个角色最多只能赋给N个用户账号,或者一个用户账号最多只能挂N个角色。


黑白名单:

某些角色,黑名单无法添加,白名单才可以添加,用以满足业务的特殊限制要求


模型亮点:

将用户和权限解耦,通过角色作为中间载体,角色不会因为用户账号被删除受到影响,仍然可以将该角色赋给下一个新用户,为权限管理提供更多的灵活性和稳定性。


搭建难度:四星

数据管理精细度:四星

抗风险能力:四星

权限管理效能:五星


适用于:数据量级大、体系较完善、需要高强度保护的数据系统,业务部门、业务场景或业务职能划分较细,公司用户量大且流动率较高,需要经常调整账号权限。


我们可以结合这几种权限管理方式的搭建难度、抗风险能力、适用情况等各方面评估,判断当前的数据系统采用哪种更合适。很多时候,根据数据系统的逐渐发展,这几种权限管理呈进阶迭代的关系。

回到本文一开始的问题场景,用我们目前学到的这些“套路”来为Snowki排忧解难吧。



首先,Snowki需要根据业务抽象出多个角色,再梳理各角色对应不同的数据权限、操作权限等。例如在电商场景下,最常见的几个角色有:采销、品类经理、库存管理员、拣货员、销售、客服、运营、产品、研发。(一般还会结合电商经营的商品品类做角色拆分,本文旨在举例,暂不做到这么细)


当Snowki梳理出大概的核心角色后,需要在数据系统的权限设置下,设计一个功能页面——角色管理,用于创建角色和维护角色,如下图:



创建角色,实际就是将权限根据业务需求集合起来。在角色管理页点击『新增角色』,对角色、描述各类权限做配置,如下图:



数据权限的设置,可将数据字段根据角色做出区分。点击『设置数据权限』,展示该页面的数据字段,以及对应该角色是否不可见、可读、读写,如下图:



当Snowki创建核心角色后,需要在数据系统的权限设置下,搭建另一个功能页面——账号管理,用于给账号关联上角色,为账号设置权限。这样,再有新用户需要配置权限时,她只用根据该用户所属业务部门、职能等,给账号一键关联上创建好的角色,这样账号即可使用角色配置好的权限集合:



并非核心搭建内容,就不做过多展开。但如果咱们想更加完善权限管理,使它具有便捷性和易拓展性,可以考虑增加这些助攻选手。比如用户组管理,功能是根据部门将一些用户设置为一个组,当对用户组添加新的角色或权限时,该用户组下所有账号都会同步调整。


长呼一口气~ 数据系统的权限既然Snowki已经搭建好了,以后数据安全性和管理效率定会明显up! 接下来就苦等研发排期吧。


本文围绕数据系统,从权限管理知识体系出发,讲了数据权限、操作权限,还有菜单管理、角色管理等几个权限管理方法,再结合场景案例巩固理解,希望能带读者一些关于数据权限管理的思考。


-END-



欢迎分享转载→ 【干货】BAT资深产品和你聊聊数据权限管理

用户评论

精品推荐

© 2013-2028 - it谈话网 版权所有 收藏本站 - 网站地图 - 关于本站 - 网站公告 - 合作申请