权限全靠管理员拍脑袋？数据平台ABAC与RBAC如何落地

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

很多企业在建设大数据平台的时候，最容易忽略的一个问题，不是计算性能，也不是存储成本，而是——权限管理。

坦白说，见过不少公司，数据平台已经上百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'。这种机制就是很多数据平台常见的“Row Level Security”，即行级权限。

字段脱敏也是ABAC的重要应用

例如手机号。数据库原始数据是13812345678，普通员工看到138****5678，管理员看到完整号码。这本质上也是属性驱动的权限控制。

Apache Ranger为什么这么受欢迎

现在很多企业级数据平台都会引入Apache Ranger。原因很简单：它天然支持RBAC、ABAC、数据脱敏、审计日志、策略中心，并且能够统一管理Hive、HBase、Kafka、Spark、Trino、Presto等组件。对于大型数据平台来说，几乎已经成为标配。

未来权限管理拼的不是角色，而是标签

过去企业管理权限是“人 → 角色 → 权限”。未来越来越像“人标签 + 数据标签 + 环境标签 + 风险标签”。

例如：员工等级=L3，数据等级=敏感，访问地点=公司内网，时间=工作时间。满足条件则允许访问，否则拒绝。这种模式更符合零信任架构的发展方向。

写在最后

很多团队建设数据平台时，总把精力放在计算快不快、存储省不省、查询稳不稳上，却忽略了最关键的问题：谁能看数据？谁不该看数据？看到了以后能不能追溯？

事实上，一个真正成熟的数据平台，最核心的能力从来不是算得快，而是管得住。

RBAC解决的是“你是谁”，ABAC解决的是“你在什么情况下可以访问什么数据”。前者让权限管理变得简单，后者让权限管理变得智能。

对于今天的大数据平台而言，最合理的选择已经不是RBAC还是ABAC，而是：用RBAC构建骨架，用ABAC填充血肉。

只有这样，数据才能真正做到“可用、可控、可追溯”，而不是成为企业数字化道路上的定时冲击波。