权限全靠管理员拍脑袋？聊聊数据平台里的ABAC和RBAC到底该怎么落地
作者：Echo_Wish
很多企业在建设大数据平台的时候，最容易忽略的一个问题，不是计算性能，也不是存储成本，而是——权限管理。
我见过不少公司，数据平台已经上百TB了，Hive、Spark、Flink、ClickHouse、Lakehouse全都上了，结果权限体系还停留在Excel表格管理阶段。
张三离职了权限没收回；
李四调岗了还能看原来的数据；
外包人员居然能访问核心经营数据；
更离谱的是，有些企业数据库账号直接共用。
很多数据泄露事件，并不是黑客有多厉害，而是权限设计从一开始就有问题。
今天我们就聊聊数据平台权限控制领域最经典的两种模型：
- RBAC（Role-Based Access Control）
- ABAC（Attribute-Based Access Control）
它们到底有什么区别？
为什么越来越多的大厂开始从RBAC走向ABAC？
又该如何在大数据平台中真正落地？
先说个真实场景
假设你们公司有这样几个部门：
- 财务部
- 研发部
- 运营部
- 市场部
数据平台中有以下数据：
订单数据
用户数据
员工薪资
运营报表
研发日志
传统做法通常是：
给张三开订单权限
给李四开薪资权限
给王五开报表权限
人数少的时候没问题。
当企业发展到：
500人
2000人
10000人
以后会发生什么？
权限爆炸。
管理员每天干的事情变成：
开权限
删权限
查权限
补权限
改权限
根本停不下来。
于是RBAC诞生了。
RBAC：角色决定权限
RBAC全称：
Role-Based Access Control
基于角色的访问控制。
核心思想特别简单：
用户 -> 角色 -> 权限
而不是：
用户 -> 权限
例如：
角色：
财务经理
财务专员
数据分析师
运维工程师
权限：
查看订单
查看薪资
查看报表
关系如下：
张三 -> 数据分析师
数据分析师：
查看订单
查看运营报表
用代码实现一个简单RBAC
class RBAC:
def __init__(self):
self.roles = {
"analyst": ["read_order", "read_report"],
"finance": ["read_salary", "read_order"],
"admin": ["*"]
}
def has_permission(self, role, permission):
perms = self.roles.get(role, [])
return "*" in perms or permission in perms
rbac = RBAC()
print(
rbac.has_permission(
"analyst",
"read_order"
)
)
print(
rbac.has_permission(
"analyst",
"read_salary"
)
)
输出：
True
False
逻辑非常清晰。
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实现
def check_permission(user, resource):
if (
user["department"] == "sales"
and
user["region"] == resource["region"]
):
return True
return False
user = {
"department": "sales",
"region": "east"
}
resource = {
"table": "order",
"region": "east"
}
print(
check_permission(
user,
resource
)
)
输出：
True
ABAC为什么越来越火
因为大数据平台越来越复杂。
以前权限控制的是：
库
表
字段
现在控制的是：
行权限
列权限
数据标签
敏感等级
数据血缘
例如：
普通员工
只能看到手机号后4位
主管
看到完整手机号
运营
只能看自己区域用户
这种需求RBAC几乎无法优雅解决。
ABAC却非常适合。
大数据平台中的典型落地方案
很多企业会采用：
RBAC + ABAC
混合模式。
而不是二选一。
架构通常如下：
用户
↓
RBAC角色校验
↓
ABAC策略校验
↓
数据访问
例如：
角色：
数据分析师
RBAC负责：
是否允许访问订单表
ABAC负责：
是否允许查看华东区域数据
这样就把：
粗粒度控制
+
细粒度控制
结合起来。
Spark中的数据过滤
假设用户访问：
select * from order_info
系统自动改写SQL：
select *
from order_info
where region='east'
对应实现：
def rewrite_sql(user_region):
sql = f"""
SELECT *
FROM order_info
WHERE region='{user_region}'
"""
return sql
这就是很多数据平台常见的：
Row Level Security
行级权限
字段脱敏也是ABAC的重要应用
例如手机号。
数据库原始数据：
13812345678
普通员工看到：
138****5678
管理员看到：
13812345678
实现示例：
def mask_phone(phone):
return (
phone[:3]
+ "****"
+ phone[-4:]
)
role = "user"
if role == "user":
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填充血肉。
只有这样，数据才能真正做到“可用、可控、可追溯”，而不是成为企业数字化道路上的定时炸弹。
