数据运营：BAT资深产品和你聊聊数据权限管理5869次阅读

初次见面，我是在探索路上不断为大家排（踩）雷（坑）的Snowki。

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

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

问题场景：

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

问题引发思考：

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

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

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

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

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

一、什么是权限管理？

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

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

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

二、为什么数据系统需要权限管理？

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

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

三、如何设计数据的权限管理？

1、几个关键元素

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

账号：

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

权限：

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

数据权限：

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

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

操作权限：

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

菜单权限：

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

角色：

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

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

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

2、最常见的权限管理

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

//账号管理//

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

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

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

• 搭建难度：一星

• 数据管理精细度：一星

• 抗风险能力：一星

• 权限管理效率：二星

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

//菜单管理//

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

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

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

• 搭建难度：二星

• 数据管理精细度：二星

• 抗风险能力：二星

• 权限管理效率：三星

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

//页面管理//

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

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

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

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

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

• 搭建难度：四星

• 数据管理精细度：五星

• 抗风险能力：四星

• 权限管理效率：一星

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

//角色管理//

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

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

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

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

说到角色管理，就不得不提BRAC模型（Role-Based Access  Control），我们可以通过下图帮助理解：

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

权限&角色：

多对多关联。

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

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

角色&用户：

多对多关联。

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

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

用户组：

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

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

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

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

模型约束条件：

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

角色互斥：

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

数量限制：

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

黑白名单：

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

模型亮点：

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

• 搭建难度：四星

• 数据管理精细度：四星

• 抗风险能力：四星

• 权限管理效能：五星

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

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

四、实战案例

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

1、梳理角色

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

2、角色管理

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

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

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

3、账号管理

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

4、助攻：权限列表、用户组管理、黑白名单等

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

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

五、总结

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