2、数据湖访问控制模型：RBAC、ABAC 与策略引擎

聊权限控制，我见过太多团队一上来就撸代码写死权限逻辑。结果呢？业务一扩张，权限代码改得比业务代码还勤快。说白了，数据湖的访问控制不是写死规则，而是设计一套可演进的模型。

这一章，我们聚焦三个核心概念：RBAC、ABAC，以及把它们串起来的策略引擎与策略决策点。嗯，这是整个权限体系的骨架。

2.1 RBAC：基于角色的访问控制

RBAC 是最经典、最普及的模型。它的核心思想很简单：用户不直接拥有权限，权限挂载在角色上，用户通过扮演角色获得权限。

我在项目中遇到过一家金融客户，数据湖里有上千个用户。如果给每个人单独配权限，那简直是灾难。RBAC 帮他们抽象出「数据分析师」「数据工程师」「风控审核员」等角色，权限管理瞬间清晰了。

RBAC 的核心要素

要素 说明 我的一点经验
用户（User） 访问数据的主体，可以是人、服务账号 别忘了服务账号，它经常被忽略
角色（Role） 权限的集合，如「只读角色」「管理员」 角色粒度要适中，太细等于没抽象
权限（Permission） 对某个资源的具体操作，如 SELECT、INSERT 尽量用动词+资源命名，别用数字代号
会话（Session） 用户激活角色的临时上下文 一个用户可以同时激活多个角色

RBAC 的三种层级

  • 扁平 RBAC：用户 ↔ 角色 ↔ 权限。最简单，适合小团队。
  • 层级 RBAC：角色可以继承。比如「高级工程师」继承「工程师」的所有权限，再加一些特殊权限。
  • 约束 RBAC：加入职责分离（SoD）。比如一个人不能同时拥有「审批角色」和「执行角色」。
我曾经踩过的坑：角色继承层级太深，导致权限爆炸。一个用户通过三层继承拿到了「删除表」的权限，排查了整整两天。建议层级控制在 3 层以内。

2.2 ABAC：基于属性的访问控制

RBAC 有个硬伤：它只能基于「你是谁」做判断。但现实场景复杂得多——你什么时间访问？从哪个 IP 来？数据属于哪个部门？

ABAC 就是来解决这个问题的。它不再依赖固定的角色，而是根据一组属性动态计算决策。

ABAC 的四类属性

属性类型 示例 为什么重要
主体属性 用户部门、职级、安全等级 判断「谁」在请求
资源属性 数据表名、敏感度标签、创建时间 判断「什么」被请求
环境属性 访问时间、网络位置、设备类型 判断「何时何地」请求
操作属性 SELECT、ALTER、EXPORT 判断「怎么做」

你想想看，一个典型的 ABAC 策略长什么样？

策略示例：
允许 主体.部门 = "风控" 
  且 资源.敏感度 = "低" 
  且 环境.时间 在 "09:00-18:00" 
  且 操作 = "SELECT" 
则 允许访问

我个人习惯把 ABAC 策略写成 JSON 或 YAML 文件，方便版本管理和审计。

我的建议：不要一上来就全上 ABAC。它灵活，但性能开销大。我通常的做法是：核心权限用 RBAC 兜底，细粒度控制用 ABAC 补充。两者结合，既稳又活。

2.3 策略引擎与策略决策点（PDP/PEP）

模型再好，没有执行引擎也是白搭。这里引入两个关键组件：策略决策点（PDP）和策略执行点（PEP）。

架构拆解

  • PEP（Policy Enforcement Point）：拦截请求，向 PDP 询问「这个请求允许吗？」，然后根据回复放行或拒绝。
  • PDP（Policy Decision Point）：接收 PEP 的请求，加载策略，计算属性，返回 Allow/Deny。
  • PAP（Policy Administration Point）：管理策略的界面或 API，供管理员配置。
  • PIP（Policy Information Point）：提供属性数据，比如从 LDAP 拉取用户部门，从数据目录拉取敏感度标签。

下面这张图展示了它们之间的协作关系：

策略引擎架构图 策略引擎核心组件协作流程 用户/应用 PEP 执行点 PDP 决策点 PAP 管理点 PIP 信息点 策略库 属性源 请求 决策请求 Allow/Deny 加载策略 获取属性 说明： PEP 拦截请求 → 向 PDP 发起决策 → PDP 从 PAP 加载策略、从 PIP 获取属性 → 返回 Allow/Deny → PEP 执行结果。

决策流程示例

假设一个数据分析师要查询「用户支付表」：

  1. PEP 拦截：SQL 到达数据湖网关，PEP 捕获请求。
  2. PEP 向 PDP 询问：发送主体、资源、操作、环境上下文。
  3. PDP 收集属性：从 PIP 获取用户部门（风控部）、资源标签（敏感）、当前时间（14:30）。
  4. PDP 匹配策略：命中一条策略——「风控部成员可在工作时间 SELECT 敏感数据」。
  5. PDP 返回 Allow：PEP 放行查询。

关键点：PDP 和 PEP 的分离，让策略逻辑与执行逻辑解耦。你可以换 PDP 的实现（比如从自研切到 Open Policy Agent），PEP 几乎不用改。

2.4 模型选型建议

到底用 RBAC 还是 ABAC？我个人的经验是：

场景 推荐模型 理由
团队规模小，角色固定 RBAC 简单，维护成本低
需要细粒度控制（如行级、列级） ABAC 属性组合灵活，无需预定义角色
合规要求严格（如 GDPR、SOX） ABAC + RBAC RBAC 兜底基础权限，ABAC 处理上下文敏感规则
数据湖跨部门共享 ABAC 不同部门属性不同，策略可复用
一个小技巧：如果你刚开始搭建数据湖权限，先跑通 RBAC。等业务提出「为什么张三能看 A 部门数据但不能看 B 部门数据」这类问题时，再引入 ABAC 属性。别过度设计。

好了，这一章的内容就到这里。RBAC 和 ABAC 不是二选一，而是互补的。策略引擎把模型落地成可执行的规则，PDP/PEP 保证规则被正确执行。理解这些，你就能设计出既安全又灵活的数据湖权限体系。

← 上一章 📖 返回目录 下一章 →