权限全靠管理员拍脑袋？聊聊数据平台里的ABAC和RBAC到底该怎么落地

权限全靠管理员拍脑袋聊聊数据平台里的ABAC和RBAC到底该怎么落地作者Echo_Wish很多企业在建设大数据平台的时候最容易忽略的一个问题不是计算性能也不是存储成本而是——权限管理。我见过不少公司数据平台已经上百TB了Hive、Spark、Flink、ClickHouse、Lakehouse全都上了结果权限体系还停留在Excel表格管理阶段。张三离职了权限没收回李四调岗了还能看原来的数据外包人员居然能访问核心经营数据更离谱的是有些企业数据库账号直接共用。很多数据泄露事件并不是黑客有多厉害而是权限设计从一开始就有问题。今天我们就聊聊数据平台权限控制领域最经典的两种模型RBACRole-Based Access ControlABACAttribute-Based Access Control它们到底有什么区别为什么越来越多的大厂开始从RBAC走向ABAC又该如何在大数据平台中真正落地先说个真实场景假设你们公司有这样几个部门财务部研发部运营部市场部数据平台中有以下数据订单数据 用户数据 员工薪资 运营报表 研发日志传统做法通常是给张三开订单权限 给李四开薪资权限 给王五开报表权限人数少的时候没问题。当企业发展到500人 2000人 10000人以后会发生什么权限爆炸。管理员每天干的事情变成开权限 删权限 查权限 补权限 改权限根本停不下来。于是RBAC诞生了。RBAC角色决定权限RBAC全称Role-Based Access Control基于角色的访问控制。核心思想特别简单用户 - 角色 - 权限而不是用户 - 权限例如角色 财务经理 财务专员 数据分析师 运维工程师 权限 查看订单 查看薪资 查看报表关系如下张三 - 数据分析师 数据分析师 查看订单 查看运营报表用代码实现一个简单RBACclassRBAC:def__init__(self):self.roles{analyst:[read_order,read_report],finance:[read_salary,read_order],admin:[*]}defhas_permission(self,role,permission):permsself.roles.get(role,[])return*inpermsorpermissioninperms rbacRBAC()print(rbac.has_permission(analyst,read_order))print(rbac.has_permission(analyst,read_salary))输出TrueFalse逻辑非常清晰。RBAC为什么受欢迎原因就两个字简单。例如企业有1000个员工。实际上可能只有10个角色管理员只需要维护角色。新员工来了赋予角色员工离职移除角色结束。运维成本极低。但RBAC有一个致命问题现实世界远比角色复杂。举个例子。公司有华东销售经理 华南销售经理 华北销售经理要求只能看自己区域数据怎么办RBAC通常这样做销售经理_华东 销售经理_华南 销售经理_华北继续增加销售经理_华东_一级 销售经理_华东_二级 销售经理_华东_三级再增加白班 夜班 临时工 外包很快就变成几百个角色这就是著名的Role Explosion角色爆炸很多企业做到后期角色数量比员工还多。这时候RBAC开始失控。ABAC登场ABAC全称Attribute-Based Access Control基于属性的访问控制。核心思想用户属性 资源属性 环境属性 是否允许访问不再依赖角色。什么叫属性用户属性{department:sales,region:east,level:manager}资源属性{table:order,region:east}环境属性{time:09:00,ip:10.1.1.1}策略销售经理 只能访问 自己区域订单系统自动计算。一个简单ABAC实现defcheck_permission(user,resource):if(user[department]salesanduser[region]resource[region]):returnTruereturnFalseuser{department:sales,region:east}resource{table:order,region:east}print(check_permission(user,resource))输出TrueABAC为什么越来越火因为大数据平台越来越复杂。以前权限控制的是库 表 字段现在控制的是行权限 列权限 数据标签 敏感等级 数据血缘例如普通员工 只能看到手机号后4位 主管 看到完整手机号 运营 只能看自己区域用户这种需求RBAC几乎无法优雅解决。ABAC却非常适合。大数据平台中的典型落地方案很多企业会采用RBAC ABAC混合模式。而不是二选一。架构通常如下用户 ↓ RBAC角色校验 ↓ ABAC策略校验 ↓ 数据访问例如角色 数据分析师 RBAC负责 是否允许访问订单表 ABAC负责 是否允许查看华东区域数据这样就把粗粒度控制 细粒度控制结合起来。Spark中的数据过滤假设用户访问select*fromorder_info系统自动改写SQLselect*fromorder_infowhereregioneast对应实现defrewrite_sql(user_region):sqlf SELECT * FROM order_info WHERE region{user_region} returnsql这就是很多数据平台常见的Row Level Security 行级权限字段脱敏也是ABAC的重要应用例如手机号。数据库原始数据13812345678普通员工看到138****5678管理员看到13812345678实现示例defmask_phone(phone):return(phone[:3]****phone[-4:])roleuserifroleuser:print(mask_phone(13812345678))else:print(13812345678)这实际上也是属性驱动的权限控制。Apache Ranger为什么这么受欢迎现在很多企业级数据平台都会引入Apache Ranger原因很简单。它天然支持RBAC ABAC 数据脱敏 审计日志 策略中心并且能够统一管理Hive HBase Kafka Spark Trino Presto对于大型数据平台来说几乎已经成为标配。我的一个观点未来权限管理拼的不是角色而是标签过去企业管理权限人 - 角色 - 权限未来越来越像人标签 数据标签 环境标签 风险标签例如员工等级L3 数据等级敏感 访问地点公司内网 时间工作时间满足条件允许访问否则拒绝访问这种模式更符合零信任架构的发展方向。写在最后很多团队建设数据平台时总把精力放在计算快不快 存储省不省 查询稳不稳却忽略了最关键的问题谁能看数据 谁不该看数据 看到了以后能不能追溯事实上一个真正成熟的数据平台最核心的能力从来不是算得快而是管得住。RBAC解决的是你是谁ABAC解决的是你在什么情况下可以访问什么数据前者让权限管理变得简单后者让权限管理变得智能。对于今天的大数据平台而言最合理的选择已经不是RBAC还是ABAC而是用RBAC构建骨架用ABAC填充血肉。只有这样数据才能真正做到“可用、可控、可追溯”而不是成为企业数字化道路上的定时炸弹。