数据安全之权限设计

权限管理是数据产品必备的要素，也是数据安全的一道重要屏障。尤其是对于数据可视化决策分析等基于数据要素加工形成的数据产品，没有权限控制，就无法让业务使用。

在数据产品权限的设计逻辑中，RBAC的原则是一个典型的权限管理的方法论，来源于B端后台工具产品，即：Role-Based Access Control)，基于角色的访问控制。

一、数据产品权限管控的需求

数据产品除了页面、功能权限外，还要多一层数据的权限，权限粒度经常会到指标和维度，比如针对销售人员设计的销售业绩统计报表，系统层面会把不同销售的数据在一个页面内展示，通过权限管理来控制能看到负责区域或者商家的数据，这个时候，对于同一个交易额的指标，就要控制到省份/城市，或者销售人员维度。同样，不同用户群体能够看到的指标可能也是不一样的，比如管理层要看到能够衡量业务整体表现情况的流量、订单、成本、服务等各个视角的指标，而某一具体的业务人员，如客服，原则上只应看到服务相关的指标。

权限设计要求

足够精细化，可以满足不同岗位、不同人员查看自己责任范围内数据

权限调整方便，组织架构调整是非常频繁的事情，架构调整权限如何快速随之变动（自动或者手动批量）

二、权限设计原则

1.传统权限管理方法

传统权限管理的做法是给用户赋权，即每个用户绑定对应的页面、功能按钮和数据的权限，这种方法的主要的问题是维护繁琐，人员组织变动，需要重新绑定资源，如果几百个人，光加权限就要搞个一天。

2.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可以层次化，以满足不同层级权限控制的要求

3.RBAC原则优缺点

RBAC的优点：

权限调整只需对角色调整，可以快速进行批量的权限操作

支持部门与角色绑定，新人入职、离职转岗，权限动态更新，无需手动操作

资源、平台管理，实现资源的配置化管理，新上线平台或新增资源时，只需平台内绑定注册，无需单独开发权限模块，节省开发人力

RBAC的缺点：

资源绑定需要管理员介入，业务权限划分要求粒度更细时，角色数量暴增，管理和维护成本高

单个用户的权限灵活度低，只能针对一个角色下的一类用户操作，想单独操作时，需要专门创建一个角色

对于UGC内容多的场景，适用度低，因为资源由用户生产，权限管控在平台侧就非常不便

三、数据产品权限设计思路

基于RBAC原则设计的权限管理，主要会包括用户管理、角色管理、资源管理、平台管理等主要功能模块：

用户管理：包括用户列表和部门列表，提供用户查询和权限操作功能，一般是从企业内部OA拉取人员信息，同时支持部门调整、角色绑定、权限禁用(黑名单)等操作

角色管理：角色增删改查列表，可以对角色进行资源绑定、用户管理

资源管理：分为页面资源、按钮资源、数据资源、指标维度资源等

平台管理：数据中台部门有多个平台，平台权限统一管理，减少各个系统独立开发权限管理模块，提高复用性。同时，也可以针对新入职或离职人员进行多个平台权限的批量开通和移交。

如何自动化处理数据权限，减少手动维护成本？

对于负责部门、负责商品等数据维度权限管理，如果每次都需要手动建立部门角色，用户绑定部门，管理员工作量还是很大的，所以怎样既实现系统自动化处理的便捷性，同时支持管理员手动配置的灵活性呢？

常用的做法是基于维度表维护人和部门、区域或商品等常见维度的关系，用户访问时，判断是否符合对应的关系。以部门权限为例，可以先由系统自动基于部门信息创建部门角色，并赋予对应部门的数据权限。用户基于SSO登录后，获取到部门信息与角色进行匹配，能匹配上则可以直接查看相应功能，无需联系管理员或者提工单申请权限，就可以做到不需要管理员手动绑定用户／部门与角色关系了。