3. 访问控制模型：从 DAC 到 ABAC 的演进之路

访问控制模型，说白了就是回答三个问题：谁？能干什么？在什么条件下？我做了十几年安全架构，见过太多因为模型选错而翻车的案例。今天咱们把这四种模型掰开揉碎了讲清楚。

3.1 自主访问控制（DAC）—— 最原始，也最危险

DAC 的核心思想是：资源的所有者说了算。你创建了一个文件，你就可以决定谁能读、谁能写。Unix 的 rwx 权限就是典型代表。

我记得刚入行时，在一家创业公司做运维。同事为了省事，把公司财务目录设成了 777。嗯，结果可想而知——实习生误删了季度报表。这就是 DAC 的典型问题：权限太分散，缺乏全局管控。

DAC 的优缺点很明显：

• 优点：实现简单，用户理解成本低，适合个人设备或小团队
• 缺点：无法集中管控，权限容易扩散，存在木马程序利用用户权限的风险

3.2 强制访问控制（MAC）—— 安全至上，但灵活度为零

MAC 走的是另一个极端。系统给每个主体（用户/进程）和客体（文件/资源）都打上安全标签，比如「绝密」「机密」「公开」。访问规则由系统强制实施，用户无权更改。

你想想看，军队和政府机构为什么偏爱 MAC？因为泄密的代价太高了。我参与过的一个国防项目，所有文档都按 MAC 模型管理。一个「机密」级别的工程师，永远看不到「绝密」的内容，哪怕他的领导授权也不行。

MAC 的典型应用场景：

• 多级安全系统（MLS）
• 军事指挥控制系统
• 涉密文档管理系统

3.3 基于角色的访问控制（RBAC）—— 企业级的事实标准

RBAC 是目前最主流的模型。它引入了「角色」这个中间层，把权限分配给角色，再把角色分配给用户。用户不再直接和权限打交道。

为什么 RBAC 这么流行？说白了，它更符合企业的组织架构。财务经理、开发工程师、运维主管——这些角色天然存在。你只需要定义好每个角色能做什么，然后把人塞进去就行。

我建议你在设计 RBAC 时，遵循最小权限原则：

1. 先梳理业务岗位，抽象出角色
2. 每个角色只分配完成工作所需的最小权限集
3. 角色之间尽量互斥（比如出纳和会计不能是同一个人）

但 RBAC 也有短板。当角色数量膨胀到几百个时，管理成本会急剧上升。我见过一个电商平台，光运营角色就定义了 80 多个，最后连安全团队自己都搞不清每个角色能干什么。

3.4 基于属性的访问控制（ABAC）—— 未来的方向

ABAC 是更灵活的模型。它不再依赖固定的角色，而是根据一组「属性」来动态判断是否放行。这些属性可以是：

• 主体属性：用户部门、职级、安全等级
• 客体属性：文件密级、创建时间、所属项目
• 环境属性：访问时间、IP 地址、设备类型
• 操作属性：读取、写入、删除、导出

举个例子：一条 ABAC 策略可以写成「允许研发部门的高级工程师在工作时间从公司内网读取非绝密的代码仓库」。你看，这比 RBAC 的「开发人员可以读取代码仓库」精确得多。

四种模型的对比：

维度	DAC	MAC	RBAC	ABAC
控制粒度	用户级	标签级	角色级	属性级
灵活性	高	低	中	高
管理成本	低	高	中	高
安全性	低	高	中	高
适用场景	个人设备	军事/政府	企业通用	复杂业务

3.5 模型选型：我的决策框架

每次做架构评审，我都会问团队三个问题：

1. 你的用户规模有多大？ 少于 100 人，DAC 够用；100-10000 人，RBAC 是首选；超过 10000 人且业务复杂，考虑 ABAC。
2. 合规要求有多严？ 涉及国家秘密或金融监管，MAC 或 ABAC 是必选项。
3. 权限变更频率如何？ 如果每周都有新业务上线，ABAC 的动态策略能省很多事。

3.6 知识体系总览

下面这张图帮你理清四种模型的核心逻辑和演进关系：

3.7 混合架构：现实中的最佳实践

在实际项目中，我很少只用单一模型。大多数企业最终会走向混合架构：

• 基础权限：用 RBAC 管理 80% 的通用场景，比如员工访问内部系统
• 敏感操作：用 ABAC 叠加动态策略，比如「只有风控总监在工作时间才能审批百万级交易」
• 审计追溯：用 MAC 的思路对关键数据打标签，确保日志不可篡改