2. 访问控制模型基础：DAC、MAC、RBAC、ABAC 模型对比与选型
聊到访问审批，绕不开一个基础问题——你到底用什么模型来控制权限？
我见过不少团队，一上来就拍脑袋说「我们用 RBAC」。结果业务一复杂，角色堆了几百个，维护成本比写代码还高。说白了，选模型就像选工具——拧螺丝用扳手，敲钉子用锤子，用对了事半功倍。
这一章，我把四种主流模型掰开揉碎讲清楚。你听完就能判断：你的场景，该用哪个。
2.1 DAC：自主访问控制
DAC 的全称是 Discretionary Access Control。翻译成人话就是——谁创建的资源，谁说了算。
你想想看，Linux 文件系统就是典型。你创建了一个文件，你可以决定谁能读、谁能写。这就是「自主」的含义：资源所有者拥有完全的授权权。
核心特征：
- 资源所有者可自行授权
- 权限可传递（比如 A 授权给 B，B 可以再授权给 C）
- 粒度通常较粗（读、写、执行）
⚠ 我曾经踩过的坑： 某次内部文档系统用了纯 DAC 模型。员工 A 把一份机密文档授权给了 B，B 又转授权给了 C……最后权限链完全失控。审计时发现 30% 的文档被不该看到的人访问了。
DAC 的问题就在于——权限扩散不可控。 你没法保证每个所有者都按安全策略行事。
2.2 MAC：强制访问控制
MAC 和 DAC 正好相反。它不讲「人情」，只认标签。
系统给每个主体（用户、进程）和客体（文件、数据库）打上安全标签。比如「绝密」「机密」「内部」「公开」。只有标签匹配，才能访问。谁说了算？系统管理员，不是资源所有者。
| 特性 | DAC | MAC |
|---|---|---|
| 授权主体 | 资源所有者 | 系统管理员 |
| 灵活性 | 高 | 低 |
| 安全性 | 低（易扩散） | 高（强制策略） |
| 典型场景 | 个人文件、共享文档 | 军事、政府、金融核心系统 |
我在做政府项目时用过 MAC。说实话，配置起来很痛苦——每个文件都要打标签，用户升级权限要走流程。但好处是：一旦配好，基本不用担心权限泄露。 因为用户自己改不了。
💡 我的建议： 除非你的业务有严格的合规要求（比如等保三级、GDPR 中的敏感数据），否则别轻易上 MAC。维护成本太高，业务部门会骂娘的。
2.3 RBAC：基于角色的访问控制
RBAC 是目前最主流的模型。它的思路很简单——把权限打包成角色，再把角色分配给用户。
举个例子：你公司有「运维工程师」「安全审计员」「部门经理」这些角色。每个角色对应一组权限。新员工入职，你只需要给他分配一个角色，不用一条条配权限。
# 一个简化的 RBAC 权限配置示例
roles:
- name: "运维工程师"
permissions:
- "server:view"
- "server:restart"
- "log:read"
- name: "安全审计员"
permissions:
- "log:read"
- "log:export"
- "audit:view"
users:
- name: "张三"
role: "运维工程师"
- name: "李四"
role: "安全审计员"嗯，这里要注意——RBAC 虽然好用，但容易「角色爆炸」。我见过一个电商平台，为了适配各种业务场景，搞了 200 多个角色。最后连管理员自己都分不清「高级运营」和「资深运营」有什么区别。
RBAC 的黄金法则：
- 角色数量控制在 20 个以内
- 每个角色的权限要「内聚」——一个角色只做一类事
- 避免「万能角色」——那种什么权限都有的角色，等于没控制
2.4 ABAC：基于属性的访问控制
ABAC 是这四种模型里最灵活的。它不看你是谁，也不看你是什么角色，而是看你、资源、环境这三者的属性。
举个例子：
- 用户属性：部门=财务、职级=高级
- 资源属性：密级=机密、所属部门=财务
- 环境属性：时间=工作时间、IP=内网
策略可以写成：「允许财务部门的高级员工，在工作时间通过内网访问财务部的机密文档」。你看，这比 RBAC 精细多了。
💡 我个人的经验： ABAC 适合权限规则复杂、经常变化的场景。比如云计算平台的 IAM 策略、医疗系统的患者数据访问。但代价是——策略引擎的性能开销大，配置门槛高。 团队里得有人专门维护属性字典和策略规则。
2.5 四种模型对比总表
| 维度 | DAC | MAC | RBAC | ABAC |
|---|---|---|---|---|
| 授权粒度 | 粗 | 中 | 中 | 细 |
| 灵活性 | 高 | 低 | 中 | 高 |
| 安全性 | 低 | 高 | 中 | 高 |
| 维护成本 | 低 | 高 | 中 | 高 |
| 适用规模 | 小团队 | 高安全环境 | 中大型组织 | 复杂动态场景 |
| 典型产品 | Linux 文件系统 | SELinux、Windows 强制完整性 | Kubernetes RBAC、AWS IAM（基础版） | Google Cloud IAM、XACML 引擎 |
2.6 选型建议：到底用哪个？
这个问题没有标准答案。但我可以给你一个决策框架：
- 团队小于 20 人，权限需求简单？ → DAC 就够了。别折腾。
- 有合规要求，数据敏感度高？ → MAC 或 ABAC。别省安全成本。
- 组织架构稳定，角色清晰？ → RBAC。这是最稳妥的选择。
- 权限规则经常变，需要动态判断？ → ABAC。但要做好策略管理。
⚠ 我见过最蠢的做法： 有人把四种模型混在一起用，没有清晰的边界。结果一个请求要经过 DAC 检查、MAC 检查、RBAC 检查、ABAC 检查……性能慢不说，策略冲突时根本不知道哪个模型说了算。
我的建议： 选一个模型作为主模型，其他模型作为补充。比如核心系统用 RBAC，敏感数据用 ABAC 做二次校验。别搞「四世同堂」。
2.7 知识体系总览
下面这张图，帮你把四种模型的核心逻辑串起来。你可以把它当作本章的「思维导图」。