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

**作者：Echo_Wish**

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

我见过不少公司，数据平台已经上百TB了，Hive、Spark、Flink、ClickHouse、Lakehouse全都上了，结果权限体系还停留在Excel表格管理阶段。

张三离职了权限没收回；

李四调岗了还能看原来的数据；

外包人员居然能访问核心经营数据；

更离谱的是，有些企业数据库账号直接共用。

很多数据泄露事件，并不是黑客有多厉害，而是权限设计从一开始就有问题。

今天我们就聊聊数据平台权限控制领域最经典的两种模型：

* RBAC（Role-Based Access Control）
* ABAC（Attribute-Based Access Control）

它们到底有什么区别？

为什么越来越多的大厂开始从RBAC走向ABAC？

又该如何在大数据平台中真正落地？

---

# 先说个真实场景

假设你们公司有这样几个部门：

* 财务部
* 研发部
* 运营部
* 市场部

数据平台中有以下数据：

```text
订单数据
用户数据
员工薪资
运营报表
研发日志
```

传统做法通常是：

```text
给张三开订单权限
给李四开薪资权限
给王五开报表权限
```

人数少的时候没问题。

当企业发展到：

```text
500人
2000人
10000人
```

以后会发生什么？

权限爆炸。

管理员每天干的事情变成：

```text
开权限
删权限
查权限
补权限
改权限
```

根本停不下来。

于是RBAC诞生了。

---

# RBAC：角色决定权限

RBAC全称：

**Role-Based Access Control**

基于角色的访问控制。

核心思想特别简单：

```text
用户 -> 角色 -> 权限
```

而不是：

```text
用户 -> 权限
```

例如：

```text
角色：
    财务经理
    财务专员
    数据分析师
    运维工程师

权限：
    查看订单
    查看薪资
    查看报表
```

关系如下：

```text
张三 -> 数据分析师

数据分析师：
    查看订单
    查看运营报表
```

---

# 用代码实现一个简单RBAC

```python
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"
    )
)
```

输出：

```python
True
False
```

逻辑非常清晰。

---

# RBAC为什么受欢迎

原因就两个字：

**简单。**

例如企业有1000个员工。

实际上可能只有：

```text
10个角色
```

管理员只需要维护角色。

新员工来了：

```text
赋予角色
```

员工离职：

```text
移除角色
```

结束。

运维成本极低。

---

# 但RBAC有一个致命问题

现实世界远比角色复杂。

举个例子。

公司有：

```text
华东销售经理
华南销售经理
华北销售经理
```

要求：

```text
只能看自己区域数据
```

怎么办？

RBAC通常这样做：

```text
销售经理_华东
销售经理_华南
销售经理_华北
```

继续增加：

```text
销售经理_华东_一级
销售经理_华东_二级
销售经理_华东_三级
```

再增加：

```text
白班
夜班
临时工
外包
```

很快就变成：

```text
几百个角色
```

这就是著名的：

**Role Explosion（角色爆炸）**

很多企业做到后期，角色数量比员工还多。

这时候RBAC开始失控。

---

# ABAC登场

ABAC全称：

**Attribute-Based Access Control**

基于属性的访问控制。

核心思想：

```text
用户属性
+
资源属性
+
环境属性
=
是否允许访问
```

不再依赖角色。

---

# 什么叫属性

用户属性：

```json
{
  "department":"sales",
  "region":"east",
  "level":"manager"
}
```

资源属性：

```json
{
  "table":"order",
  "region":"east"
}
```

环境属性：

```json
{
  "time":"09:00",
  "ip":"10.1.1.1"
}
```

策略：

```text
销售经理
只能访问
自己区域订单
```

系统自动计算。

---

# 一个简单ABAC实现

```python
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
    )
)
```

输出：

```python
True
```

---

# ABAC为什么越来越火

因为大数据平台越来越复杂。

以前权限控制的是：

```text
库
表
字段
```

现在控制的是：

```text
行权限
列权限
数据标签
敏感等级
数据血缘
```

例如：

```text
普通员工
只能看到手机号后4位

主管
看到完整手机号

运营
只能看自己区域用户
```

这种需求RBAC几乎无法优雅解决。

ABAC却非常适合。

---

# 大数据平台中的典型落地方案

很多企业会采用：

```text
RBAC + ABAC
```

混合模式。

而不是二选一。

架构通常如下：

```text
用户
 ↓
RBAC角色校验
 ↓
ABAC策略校验
 ↓
数据访问
```

例如：

```text
角色：
    数据分析师

RBAC负责：
    是否允许访问订单表

ABAC负责：
    是否允许查看华东区域数据
```

这样就把：

```text
粗粒度控制
+
细粒度控制
```

结合起来。

---

# Spark中的数据过滤

假设用户访问：

```sql
select * from order_info
```

系统自动改写SQL：

```sql
select *
from order_info
where region='east'
```

对应实现：

```python
def rewrite_sql(user_region):

    sql = f"""
    SELECT *
    FROM order_info
    WHERE region='{user_region}'
    """

    return sql
```

这就是很多数据平台常见的：

```text
Row Level Security
行级权限
```

---

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

例如手机号。

数据库原始数据：

```text
13812345678
```

普通员工看到：

```text
138****5678
```

管理员看到：

```text
13812345678
```

实现示例：

```python
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

原因很简单。

它天然支持：

```text
RBAC
ABAC
数据脱敏
审计日志
策略中心
```

并且能够统一管理：

```text
Hive
HBase
Kafka
Spark
Trino
Presto
```

对于大型数据平台来说，几乎已经成为标配。

---

# 我的一个观点：未来权限管理拼的不是角色，而是标签

过去企业管理权限：

```text
人 -> 角色 -> 权限
```

未来越来越像：

```text
人标签
+
数据标签
+
环境标签
+
风险标签
```

例如：

```text
员工等级=L3

数据等级=敏感

访问地点=公司内网

时间=工作时间
```

满足条件：

```text
允许访问
```

否则：

```text
拒绝访问
```

这种模式更符合零信任架构的发展方向。

---

# 写在最后

很多团队建设数据平台时，总把精力放在：

```text
计算快不快
存储省不省
查询稳不稳
```

却忽略了最关键的问题：

```text
谁能看数据？
谁不该看数据？
看到了以后能不能追溯？
```

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

RBAC解决的是：

```text
你是谁
```

ABAC解决的是：

```text
你在什么情况下可以访问什么数据
```

前者让权限管理变得简单，后者让权限管理变得智能。

对于今天的大数据平台而言，最合理的选择已经不是RBAC还是ABAC，而是：

**用RBAC构建骨架，用ABAC填充血肉。**

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


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

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

大数据

安全

架构设计

数据平台权限管理是保障数据安全的核心，RBAC和ABAC是两种主流权限控制模型。RBAC基于角色分配权限，适合简单场景但易出现角色爆炸；ABAC基于属性动态控制，支持细粒度权限管理。企业应采用RBAC+ABAC混合模式，结合Apache Ranger等工具实现行级权限、数据脱敏，构建安全可控的大数据平台。

数据脱敏

数据分析

数据泄露

数据库

零信任

Spark 

Hive

2026年中大促 | AI 领航 智绘未来

bigdata-class

腾讯云BI新客户首次购买9.9元起！


tchousec

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

权限全靠管理员拍脑袋？聊聊数据平台里的ABAC和RBAC到底该怎么落地-腾讯云开发者社区-腾讯云

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

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐