windows系统采用了那种访问控制模型_应用层数据安全管控实践—权限模型篇

[前言] 本文是应用层数据安全管控系列课程的第一篇，旨在介绍权限模型的迭代历程和应用实践

1.权限模型迭代概览

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

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

【基础权限模型介绍】注释

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

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

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

2.权限模型在产品设计中的应用

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

3. TRFAC模型实践

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

[ 案例1 ]

某业务团队需要实现报表权限控制(维度权限)需求。业务逻辑并不复杂，但是人和资源的权限关系比较细，传统ACL模型和RBAC模型均不能满足，因此，我们采用TRFAC模型来实现：首先，鉴权主体是人，资源为报表；然后，行级别权限控制，可以理解为在正常资源关系中，新增了“维度值”附属条件，比如，当报表资源满足“城市=北京”的条件时，用户XX拥有对该报表的权限。所以我们实现路径如下：

图表3：行级别权限实现逻辑图

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

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

[ 案例2 ]

某某智能数仓平台(其实就是指标/维度生产维护服务平台)，需要权限中心帮助实现功能和数据权限控制。系统简易架构图如下：

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

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

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

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

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

图表8：角色-权限实现逻辑图

案例2小结：

1. 业务线、业务域、业务过程在TRFAC模型看来都是“资源”：平台超管角色对业务线拥有管理维护权限，业务线管理员对业务域拥有管理维护权限，业务域管理员对业务过程拥有管理维护权限
2. 指标/维度的探查权限属于数据权限，既能以角色-权限的方式来管控，也能以人-资源-权限的方式管控
3. 资源需要依附对象，也就是触发鉴权动作的对象：
4. 以系统为依附对象，即进入系统时对所有资源都触发一遍鉴权询问。优点是业务逻辑简单，不用设计复杂的权限关系；缺点是鉴权响应速度和性能较差
5. 以菜单/模块/页面为依附对象，即进入相应模块或者页面时触发鉴权询问。优点是无论是权限关系复杂度还是鉴权速度和性能都比较均衡；缺点是复杂或者细粒度业务需求满足不了
6. 以具体的触发按钮为依附对象，即点击XX按钮时触发鉴权询问。优点是自由度和灵活性高，复杂业务需求容易满足，且性能优异；缺点是管理维护成本高，不通用，迭代更新成本高

一个数据人的自留地是一个助力数据人成长的大家庭，帮助对数据感兴趣的伙伴们明确学习方向、精准提升技能。

关注我，带你探索数据的神奇奥秘