3. 权限模型对比：DAC、MAC、RBAC、ABAC 的区别与选择

说到权限模型，很多人第一反应就是“用 RBAC 就好了”。

但真是这样吗？
我在项目里踩过不少坑。有一次，一个金融核心系统硬套 RBAC，结果角色膨胀到两百多个，维护成本爆炸。
你想想看，选错模型，后面重构的代价有多高。

这一章，我就把这四种主流模型掰开揉碎了讲清楚。
它们有什么区别？

3.1 权限模型演进史

先看一张总览图，帮你快速建立整体认知。这张图展示了四种模型的核心要素和典型决策路径。

3.2 四大模型核心区别

接下来，我把每个模型的特点说透。

3.2.1 DAC（自主访问控制）

这是最古老的模型了。资源归谁，谁说了算。
说白了，就是“我的文件我做主”。

特点

• 灵活性高：owner 可以随时授权/撤销
• 风险大：权限容易被滥用。我曾经见过一个项目，普通员工把重要文档的读权限开放给了全公司……
• 常见场景：Linux 文件系统（rwx）、Windows NTFS 共享

3.2.2 MAC（强制访问控制）

和 DAC 相反，MAC 是“系统说了算”。

系统给每个主体和客体都打上安全标签（比如：绝密、机密、公开）。
你是什么级别，就只能看什么级别的信息。不能自己改。

特点

• 安全性高：策略由中央系统强制实施
• 灵活性低：用户自己无法调整
• 常见场景：军事系统、政府涉密系统、SELinux

3.2.3 RBAC（基于角色访问控制）

这是我们课程的重点。为什么 RBAC 普及率最高？
因为它引入了一个关键概念——角色。

角色把“用户”和“权限”解耦了。
你想想看，一个公司几百号人，每人分配权限累死。但如果我们定义几个角色，比如：管理员、运营、财务……把权限配给角色，再把角色赋予用户，是不是就清晰很多？

特点

• 易于管理：角色数量远少于用户数量
• 职责分离：支持互斥角色（比如：出纳不能兼任会计）
• 常见场景：企业 ERP、CMS、SaaS 平台、SDK 权限设计

3.2.4 ABAC（基于属性访问控制）

如果说 RBAC 是“静态”的，那 ABAC 就是“动态”的。
它不依赖角色，而是依赖一堆属性。

属性有哪些？

• 主体属性：用户年龄、部门、职级
• 资源属性：文档密级、创建时间
• 环境属性：访问时间、IP 地址、设备类型

举个例子：
“允许部门经理在工作时间（9:00-18:00），从公司内网，查看本部门员工的绩效报告（非机密级）”
你看，一个判断条件里混了一堆属性。这就是 ABAC 的威力。

3.3 选型决策指南

好，四种模型都讲完了。那到底怎么选？

我建议你从下面四个维度来思考。

评估维度	DAC	MAC	RBAC	ABAC
业务复杂度	简单	简单	中等	复杂
用户规模	小（< 50人）	小/中	中/大（> 100人）	大（> 1000人）
审计需求	低	高	中/高	高
性能要求	高	高	高	中/低（有性能开销）
动态性	低	低	中	高
维护成本	低	高	中	高

3.4 个人推荐选型模型（避坑指南）

说了这么多理论，来点实际的。

1. 如果你是初创产品，快速迭代中：从 RBAC 入手，别碰 ABAC。RBAC 的模型清晰，团队理解成本低。
2. 如果你是 SDK 提供商，要适配多种客户：还是 RBAC。角色-权限的数据模型容易序列化，也方便前端做配置界面。我在设计 OpenAPI 权限时，就坚持用 RBAC 做底座。
3. 如果你在金融、银行系统：考虑混合模型。比如内核用 RBAC，在细粒度的交易授权上用 ABAC 做补充。我曾经在银行项目中，就用了“RBAC + 属性条件”的模式，既保证了基础管理的清晰，又满足了动态风控的需求。
4. 如果你真需要强制安全等级：比如涉密系统，MAC 是唯一选择。别纠结。