权限全靠管理员拍脑袋？聊聊数据平台里的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填充血肉。

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