权限管理几乎是每个B端产品都会涉及的功能模块，大数据时，除了让数据高效地支撑业务分析、创新应用外，数据安全管理也是重中之重，数据给业务带来再多的价值可能都抵不过一次数据安全事故，“删库跑路”的新闻时不时在互联网行业爆出，那么，作为数据产品经理，如何设计数据产品的权限控制模块，来保证数据安全呢。
一、数据产品权限管控的需求
数据产品除了页面、功能权限外，还要多一层数据的权限，权限粒度经常会到指标和维度，比如针对销售人员设计的销售业绩统计报表，系统层面会把不同销售的数据在一个页面内展示，通过权限管理来控制能看到负责区域或者商家的数据，这个时候，对于同一个交易额的指标，就要控制到省份/城市，或者销售人员维度。同样，不同用户群体能够看到的指标可能也是不一样的，比如管理层要看到能够衡量业务整体表现情况的流量、订单、成本、服务等各个视角的指标，而某一具体的业务人员，如客服，原则上只应看到服务相关的指标。
1、数据产品资源分类
数据产品上的资源按照来源划分，可以分为平台生产内容（PGC）和用户生产内容（UGC），两种类型的资源特点以及对权限管控的诉求有所差异：
PGC：数据部门(平台侧)将内容生产好后，提供给业务查询或使用，如数据可视化平台，业务提交需求后，数据产品承接，转化成产品方案后，业务按需查看，资源特点：
- 内容数量可控，按照业务主题划分，菜单层级、页面内容清晰，数量可控
- 内容和用户匹配规则可枚举：比如经营分析报表目标是公司高管和管理层，流量分析以产品运营为主
- 权限管理集中在平台侧统一分配和管控用户权限
UGC：用户基于数据部门提供平台或工具，生产出自己需要的数据内容，如创建自定义的Dashboard，创建数据表、新增ETL清洗任务，或基于标签圈选人群，资源特点：
- 数据内容由业务自由生产，内容数据量不可控
- 内容和用户匹配规则不可枚举，例如产品张三创建了一个App流量转化漏斗的看板，销售李四申请权限后可以查看，运营王小二也可以申请
- 权限管理平台侧难以把控，因为数据产品小旭并不知道张三创建的报表应不应给李四开通
- 同一部门生产的内容要做到上级可见，或部门内共享（工作备份、异常处理等）
2、数据产品权限管控需求
对于PGC内容，权限统一收口平台侧，权限开通和移除要尽量简单快捷，否则对于公司人数较多的，数据产品经理每天要花在权限开通上的时间就很多了。而对于UGC内容，权限的管控一般到部门层级，因此平台侧要提供权限自助申请和审批后一键开通的能力。总体来说，数据产品权限管控需求如下：
- 平台权限:对于有页面、数据权限管控的，一般默认开通平台使用权限，只可以看到自己有权限的即可，需要申请管理权限，单独申请，遇到过一个BI产品，设计权限的时候用户需要先找产品经理开通一下平台使用权限才可以创建看板，产品经理还抱怨说每天开权限花很多时间，后来跟他讲，资源权限隔离做好了，普通用户的平台使用权限是完全没有必须控制的
- 页面权限:不同产品对应的菜单和页面权限，如各种类型的数据可视化报表、DMP平台的创建人群和创建场景的权限等
- 操作权限：页面内容的增、删、改、查、下载导出等权限控制
- 数据权限：数据表、指标、维度(行、列)等更细粒度的资源权限
- 权限配置：可以按照某一类用户批量开通和管理权限，最好是入职后自动绑定，不需要人肉开通
- 跨部门权限：测试和产品/开发不是一个部门，但需要看到对应应用或资源的权限进行测试
- 权限申请和审批流程:UGC 内容要有完整的用户申请、权限审批、资源绑定的全流程，避免人肉处理
二、权限设计原则
1、RBAC原则
权限设计最常用的是RBAC原则，即：Role-Based Access Control)，基于角色的访问控制。基本思想是通过角色来管控权限，角色绑定资源，用户授权角色，用户不可以直接和资源绑定，没有角色的用户无法访问平台的资源。RBAC对访问权限的授权由管理员统一管理，管理员根据用户在组织内所处的角色作出访问授权与控制，授权规定是强加给用户的，用户不能自主地将访问权限传给他人，这是一种非自主型集中式访问控制方式。
在RBAC模型中，Who对What(Which)进行How的操作：
- Who：权限拥有的主体，如User、Group、Role、Actor
- What：权限针对的对象或资源（Resource、Class）。
- How：具体的权限，页面查看、编辑、删除等操作
- Role：角色，用户权限的载体，目的建立User与Resource的映射关系，减少千人千面的人与资源的强耦合关系
- Group：用户组，权限分配的单位与载体。权限不考虑分配给特定的用户而给组。组可以包括组(以实现权限的继承)，也可以包含用户，组内用户继承组的权限。User与Group是多对多的关系。Group可以层次化，以满足不同层级权限控制的要求
基于RBAC原则设计的权限管理，主要会包括用户管理、角色管理、资源管理、平台管理等主要功能模块：
- 用户管理：包括用户列表和部门列表，提供用户查询和权限操作功能，一般是从企业内部OA拉取人员信息，同时支持部门调整、角色绑定、权限禁用(黑名单)等操作
- 角色管理：角色增删改查列表，可以对角色进行资源绑定、用户管理
- 资源管理：分为页面资源、按钮资源、数据资源、指标维度资源等
- 平台管理：数据中台部门有多个平台，平台权限统一管理，减少各个系统独立开发权限管理模块，提高复用性。同时，也可以针对新入职或离职人员进行多个平台权限的批量开通和移交。
2、RBAC原则优缺点
RBAC的优点：
- 权限调整只需对角色调整，可以快速进行批量的权限操作
- 支持部门与角色绑定，新人入职、离职转岗，权限动态更新，无需手动操作
- 资源、平台管理，实现资源的配置化管理，新上线平台或新增资源时，只需平台内绑定注册，无需单独开发权限模块，节省开发人力
RBAC的缺点：
- 资源绑定需要管理员介入，业务权限划分要求粒度更细时，角色数量暴增，管理和维护成本高
- 单个用户的权限灵活度低，只能针对一个角色下的一类用户操作，想单独操作时，需要专门创建一个角色
- 对于UGC内容多的场景，适用度低，因为资源由用户生产，权限管控在平台侧就非常不便
三、数据产品权限设计思路
结合数据产品PGC和UGC内容对权限管控的需求，以及RBAC权限设计原则的优缺点，在RBAC原则下，融入UGC内容的权限管理，就可以解决问题了。也就是既要保留RBAC的灵活性，也要兼容UGC的千人千面。具体权限逻辑如下：
RBAC原则为基础：
基于RBAC设计功能权限，以精准营销平台为例，设定：普通用户、部门管理员、QA测试人员、数据开发、标签管理员、系统管理员等几个角色：
- 普通用户：可以使用标签进行人群圈选和场景创建，只可以看到本人或本部门创建的场景和效果数据，可以看到本部门的主要原因是，同一部门不同用户间工作可能有重合性，或者交叉Review人员互备等，做的灵活一些，不同平台可以设置普通用户的权限可见逻辑，是仅个人及上级可见，还是部门内可见，非部门负责人进入系统后可默认绑定该角色
- 部门管理员：基于企业内部OA系统，获取管理条线的人员信息，职能为管理或代理管理的，可开通部门管理员角色，人和部门的关系基于OA架构映射，部门管理员可见本部门全部用户生产的内容。
- QA测试人员，可以对所承接测试工作的部门的业务场景进行编辑和操作，需要绑定部门
- 数据开发：标签数据源接入、数据生产加工
- 标签管理员：负责标签需求审核、标签创建、标签审核，减少标签重复生产，避免爆炸式增长
- 系统管理员：平台产品或开发，可以使用所有功能，管理用户权限
数据资源权限为补充：
平台功能权限和部门权限共享等默认逻辑以RBAC的方式在统一权限管理平台实现外，对于UGC的数据内容以用户为单位进行资源绑定，如数据资产平台申请库表权限、数据开通平台申请ETL开发任务权限，基于工单流程，用户发起申请，审批节点审批通过后，将对应的资源和用户建立绑定关系，平台内可查看用户个人权限，进行权限管理，离职移交或释放。
四、总结
数据产品因为涉及非常细粒度的数据权限，因此在权限设计过程要建立清晰的管控主线，否则多种资源管控逻辑交织在一起，系统实现和维护成本会非常高，剪不断，理还乱！本文主要介绍了权限管理相对通用的原则，每个产品有自身的差异化特点，具体情况大家可以结合实际情况进行设计。
