权限模型发展史：DAC、MAC、RBAC、ABAC概览

做接口安全这么多年，我发现有个问题几乎每个团队都会问："到底该选哪种权限模型？"说实话，没有万能答案。但理解这些模型是怎么演变过来的，你就能做出更适合自己的选择。

你想想看，权限这件事从计算机诞生那天就存在了。最早的系统压根儿没什么权限概念，谁登录了就能干所有事。后来人们发现这样不行——太危险了。于是各种权限模型陆续登场。嗯，咱们今天就把这四种主流模型捋一遍。

1. DAC – 自主访问控制

DAC 是出场最早的模型。它的核心思想很简单：资源所有者说了算。谁创建了文件，谁就有权决定谁能访问它。典型的例子就是 Linux 的文件权限——chmod 755 这种，owner 可以随意给其他人开权限。

我在早期的一个项目中就吃过 DAC 的亏。当时团队用 DAC 管理 API 的访问权限，每个微服务各自维护自己的权限列表。结果呢？权限分散得一塌糊涂，根本理不清谁给了谁什么权限。最后我们不得不花两周时间重构整个权限体系。

• 优点：灵活、实现简单、适合小规模场景
• 缺点：权限分散、难以审计、容易越权
• 典型场景：个人文件管理、小型团队协作

2. MAC – 强制访问控制

MAC 走的是另一个极端——系统说了算。用户不能随便给别人授权，所有访问都由系统根据安全标签来强制决定。你想想看，军队里的文件分级就是典型的 MAC 模型：绝密、机密、秘密、普通，每个级别的人只能看对应级别的文件。

我在一个银行项目中见过 MAC 的实际应用。他们的数据按照敏感度打了标签，普通员工连数据库表都看不到，只有特定角色的审批通过后才能访问。安全是安全了，但灵活性确实差了点。

• 优点：安全性高、管控严格、适合分级管理
• 缺点：灵活性差、配置复杂、维护成本高
• 典型场景：军事系统、政府机密系统、金融核心数据

3. RBAC – 基于角色的访问控制

RBAC 是我个人最喜欢的模型。它的思路很巧妙：不直接把权限给用户，而是通过"角色"来间接关联。说白了，你先定义好角色——比如"管理员"、"运营"、"客服"——然后把权限挂到角色上，最后把用户放进角色里就行了。

我做过一个电商后台项目，就是用的 RBAC。整个系统 200 多个接口，50 多名员工。我们用 RBAC 分了 8 个角色，权限管理一下子清晰了。新员工入职，只需要给他分配一个角色，完事。比起 DAC 那种每人一套权限的方式，简直舒服太多。

• 优点：管理简单、易于扩展、审计方便、适合中大型系统
• 缺点：角色爆炸时也头疼、细粒度控制不够灵活
• 典型场景：企业管理系统、SaaS 平台、API 权限管控

4. ABAC – 基于属性的访问控制

ABAC 是这几年火起来的新思路。它不看角色，也不看所有者，而是看属性——用户的属性、资源的属性、环境的属性。把这些属性组合起来，动态决定能不能访问。举个例子："允许销售部门的员工在工作时间访问客户订单数据"——这就是 ABAC 的策略。

我曾见过一个团队把 ABAC 玩得特别溜。他们的 API 网关集成了 ABAC 引擎，每次请求来的时候，引擎会根据当前时间、用户部门、资源类型、IP 地址等多个维度做决策。灵活性确实强，但说实话，策略多了以后，维护起来也是真头疼。

// ABAC 策略示例（伪代码）
策略名: "允许销售访问客户订单"
条件:
  用户.部门 == "销售"
  且 资源.类型 == "订单"
  且 环境.时间 在 09:00 ~ 18:00
  且 请求.IP 属于 公司内网
动作: 允许

• 优点：高度灵活、细粒度控制、支持动态场景
• 缺点：策略复杂、性能开销大、调试困难
• 典型场景：云平台权限、物联网系统、大型分布式架构

5. 四种模型对比

我把它们放在一起做了个对比，方便你快速参考。

6. 我的选择建议

做了这么多年权限设计，我个人有个习惯：从 RBAC 起步，按需演进。大多数业务系统用 RBAC 就够了，别一上来就上 ABAC，那玩意儿是真的不好驾驭。

如果你正在设计一个接口安全体系，我建议你这么做：

1. 先画角色——把业务角色梳理清楚，别漏
2. 再定权限——每个角色需要哪些接口权限
3. 留好扩展点——未来要升级到 ABAC 也能平滑过渡
4. 做好审计——不管用哪种模型，日志一定要全

看到这张图你就能明白，这四种模型不是相互替代的关系，而是不同阶段、不同场景下的最优解。DAC 和 MAC 是早期探索，RBAC 是工业化的产物，ABAC 则是面向未来的灵活方案。