3、访问控制模型：RBAC、ABAC、MAC、DAC

访问控制模型，说白了就是「谁在什么条件下能碰什么数据」的一套规则。我这些年做数据湖项目，见过太多因为模型选错导致权限炸裂的案例。今天咱们把这四种模型掰开揉碎讲清楚。

3.1 自主访问控制（DAC）

DAC 是最古老也最直观的模型。数据的所有者自己决定谁能访问。就像你买了套房，钥匙想给谁就给谁。

在文件系统里很常见——Linux 的 chmod、Windows 的 NTFS 权限，都是 DAC 的体现。我记得刚入行时，公司用 NFS 共享数据，每个部门自己设权限，结果乱成一锅粥。

优点：灵活、简单、用户自主权高。

缺点：权限分散、难以审计、容易泄露。

3.2 强制访问控制（MAC）

MAC 走的是另一个极端——系统说了算，用户没得选。每个主体（用户/进程）和客体（数据/文件）都有安全标签，系统根据预定义规则决定是否放行。

典型的例子是 SELinux 和军事系统的多级安全（MLS）。标签分等级：绝密、机密、秘密、公开。用户只能读比自己等级低的数据，写只能往同级或更高级写。

操作	主体等级	客体等级	结果
读	机密	秘密	✅ 允许（向下读）
读	机密	绝密	❌ 拒绝（向上读）
写	机密	秘密	❌ 拒绝（向下写）
写	机密	绝密	✅ 允许（向上写）

MAC 安全，但太死板。数据湖场景下，我很少见到纯 MAC 的落地。除非是政府、军工这类对数据流向有严格管控的行业。

3.3 基于角色的访问控制（RBAC）

RBAC 是目前企业里最主流的模型。核心思路是：用户不直接关联权限，而是通过「角色」这个中间层来间接获得权限。

你想想看，一个数据湖里可能有几百个用户，如果每个人单独配权限，运维人员会疯掉。RBAC 把权限抽象成角色——比如「数据工程师」「数据分析师」「数据科学家」——然后把人塞进角色里。

# 伪代码示例：RBAC 权限判断
user = get_user("张三")
roles = user.get_roles()  # ["data_engineer", "lake_admin"]
for role in roles:
    permissions = role.get_permissions()
    if "s3://data-lake/raw/*" in permissions:
        return True
return False

RBAC 的三个核心原则：

• 角色继承：高级角色包含低级角色的权限
• 最小权限：角色只给完成工作所需的最小权限集
• 职责分离：敏感操作需要多个角色共同完成

RBAC 的缺点也很明显——角色爆炸。当业务复杂到一定程度，角色数量会失控。我在一个电商客户那里见过 200 多个角色，连管理员都搞不清每个角色到底能干啥。

3.4 基于属性的访问控制（ABAC）

ABAC 是解决 RBAC 角色爆炸的利器。它不再依赖固定的角色，而是根据一组「属性」动态计算权限。

属性分四类：

• 主体属性：用户部门、职级、地理位置、认证方式
• 客体属性：数据敏感等级、数据域、创建时间、存储位置
• 环境属性：访问时间、网络 IP、设备类型、风险等级
• 操作属性：读、写、删除、导出、共享

# ABAC 策略示例（类 AWS IAM Policy 语法）
{
  "Effect": "Allow",
  "Action": ["s3:GetObject"],
  "Resource": "arn:aws:s3:::data-lake/",
  "Condition": {
    "StringEquals": {
      "aws:PrincipalTag/Department": "Finance",
      "s3:ExistingObjectTag/DataClass": "Confidential"
    },
    "IpAddress": {
      "aws:SourceIp": "10.0.0.0/8"
    },
    "DateGreaterThan": {
      "aws:CurrentTime": "2024-01-01T00:00:00Z"
    }
  }
}

ABAC 的威力在于「细粒度」和「动态性」。同样是财务部的员工，在办公室内网能看机密数据，连了 VPN 就只能看公开数据——策略不用改，属性变了权限自动变。

3.5 四种模型对比

维度	DAC	MAC	RBAC	ABAC
控制粒度	粗	中	中	细
灵活性	高	低	中	高
管理成本	低	高	中	高
安全性	低	高	中	高
适用场景	个人文件、沙箱	军工、政府	企业通用	多云、微服务
数据湖适配度	⭐	⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐

3.6 模型选择与混搭策略

实际项目中，我很少只用一种模型。数据湖的权限设计，通常是 RBAC + ABAC 的组合拳。

我的推荐架构：

• 基础层：RBAC 定义大权限边界（谁可以进哪个数据域）
• 精细层：ABAC 做行级/列级控制（什么条件下能看哪些字段）
• 兜底层：MAC 做数据流出管控（防止高敏数据被导出到低安全域）
• 沙箱层：DAC 给数据科学家做探索用（但严格审计）

3.7 落地建议

最后，给几个我在实战中总结的落地建议：

1. 先做 RBAC，再上 ABAC。 别一上来就搞 ABAC，属性定义和策略编写的工作量远超想象。
2. 角色数量控制在 20 个以内。 超过这个数，说明你的角色设计有问题，该考虑 ABAC 了。
3. ABAC 属性要标准化。 部门、数据分类、环境标签这些属性，必须在全公司统一，否则策略会自相矛盾。
4. 定期做权限审计。 我见过太多「僵尸权限」——人走了、角色变了，但权限还在。每季度跑一次权限清单，清理无效策略。
5. 测试环境先验证。 权限策略改动了，先在测试湖跑一遍，别直接上生产。我曾经因为一条 ABAC 策略写错条件，导致整个财务部门三天没法看报表。