2023年应用层数据安全管控实践-权限模型篇

应用层数据安全管控实践—权限模型篇一、权限模型迭代概览

权限的本质其实是人与人之间信任关系的建立和打散，权限管控的核心是声明人和权限的关系。纵观行业进展，权限管控模型先后经受了以ACL模型为代表的1.0时代和以RBAC模型为代表的2.0时代，现在正式迈入以TRFAC模型为代表的3.0代。

图表1：基础权限模型示意图

【基础权限模型介绍】解释：

[1]ACL模型：即AccessControlList，访问掌握列表，用户与权限直接关联，直接维护列表中用户与资源的关系从而达到权限管控的目的。

[2]RBAC模型：即Role-BasedAccessControl，基于角色的访问掌握，RBAC模型则是角色与权限进行关联，用户成为相应的角色而获得对应的权限。

[3]TRFAC模型：即target-resource-factor-actControl，基于“对象-资源-条件-行为”的权限掌握，TRFAC模型描述了“XX对象（人/应用/组织/角色等）对XX资源（页面/菜单/按钮/数据等）在XX条件/因素（城市=北京等）下拥有XX行为类型（增删改查等）的权限”。

二、权限模型在产品设计中的应用

图表2：基于权限模型设计的XX权限产品DEMO

三、TRFAC模型实践

数据产品自然 存在人和资源之间的简单关系，传统权限模型，无论是ACL模型还是RBAC模型，都不能很好地声明人和权限的关系。以下就以两个典型案例的解决方案，来阐述TRFAC模型的应用实践。

[案例1]

某业务团队需要实现报表权限掌握（维度权限）需求。业务规律并不简单，但是人和资源的权限关系比较细，传统ACL模型和RBAC模型均不能满意，因此，我们采纳TRFAC模型来实现。

首先，鉴权主体是人，资源为报表；然后，行级别权限掌握，可以理解为在正常资源关系中，新增了“维度值”附属条件，比如，当报表资源满意“城市=北京”的条件时，用户XX拥有对该报表的权限。所以我们实现路径如下：

图表3：行级别权限实现规律图

图表4：行级别权限鉴权流程示意图

思索：为什么不把报表中每一行数据都当作是资源注册到权限中心，这样行级别权限其实只是一次更细粒度的资源鉴权，为什么要把维度值当作是条件呢？

[案例2]

某某智能数仓平台（其实就是指标/维度生产维护服务平台），需要权限中心关心实现功能和数据权限掌握。系统简易架构图如下：

图表5：XX智能数仓平台系统架构图

该智能数仓平台兼具功能和数据权限管控需求，其中功能权限包括业务线/业务域/业务过程的管理和维护，修饰词的管理和维护，指标/维度的录入和管理维护；数据权限包括“指标+维度”的数据探查权限，底层库表的数据读取权限，详细组织形式如下图所示：

图表6：XX智能数仓平台功能权限管理体系设计

图表7：XX智能数仓平台角色管控体系

在业务规律上比较简单，既有功能权限，又有数据权限，同时资源之间还有归属和继承关系，同时还有较为丰富的角色体系，这时候单纯用ACL或者RBAC模型都无法全部满意需求，因此我们采纳TRFAC模型来实现：

图表8：角色-权限实现规律图

案例2小结

业务线、业务域、业务过程在TRFAC模型看来都是“资源”：平台超管角色对业务线拥有管理维护权限，业务线管理员对业务域拥有管理维护权限，业务域管理员对业务过程拥有管理维护权限指标/维度的探查权限属于数据权限，既能以角色-权限的方式来管控，也能以人-资源-权限的方式管控资源需要依附对象，也就是触发鉴权动作的对象以系统为依附对象，即进入系统时对全部资源都触发一遍鉴权询问。优点是业务规律简洁，不用设计简单的权限关系；缺点是鉴权响应速度和性能较差以菜单/模块/页面为依附对象，即进入相应模块或者页面时触发鉴权询问。优点是无论是权限关系简单度还是鉴权速度和性能都比较均衡；缺点是简单或者细粒度