数据产品权限设计逻辑

 

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

在数据产品权限的设计逻辑中，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可以层次化，以满足不同层级权限控制的要求

 

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

 

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

 

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

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

 

 

 

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

 

来源（公众号）：数据干饭人