三种权限模型，谁才是你的菜？
做接口权限设计这行，绕不开三个老祖宗级别的模型：DAC、MAC 和 RBAC。说白了，它们就是给谁看、给谁写、给谁删的三种不同思路。
我刚开始接触时，总觉得用 RBAC 就够了，其他两个是历史产物。后来在金融项目里吃过亏，才发现每个模型都有自己的阵地。今天咱们就摊开对比一下。
自主访问控制（DAC）——灵活但容易失控
DAC 的全称是 Discretionary Access Control。核心思想就一句话：资源的主人说了算。
你创建了一个文件，你就可以决定谁能读谁能写。Linux 文件权限里的 rwx 其实就带点 DAC 的影子——文件所有者可以用 chmod 改权限。Windows 里的共享文件夹设置也是 DAC 的产物。
好处呢？灵活。部门里小范围共享，直接右键分享就行，不用找管理员。坏处也明显：权限容易失控。我记得在早期做内部 CMS 时，大家随手给同事开编辑权限，最后整个后台谁都能改——安全隐患非常大。而且 DAC 没有强制策略，用户一旦中木马，恶意程序可以顺着用户的权限去感染整个系统。
强制访问控制（MAC）——安全第一，灵活靠边
MAC 的全称是 Mandatory Access Control。它跟 DAC 完全相反：你说了不算，系统说了算。
所有主体（用户、进程）和客体（文件、接口）都被打上安全标签，比如"绝密""机密""公开"。系统根据预定义的规则（比如 Bell–LaPadula 模型）来判断能不能访问。常见的 SELinux、AppArmor 就是 MAC 在操作系统层面的实现。
用 MAC 的好处是：安全级别极高。即使你作为管理员误操作，只要安全策略没变，机密数据流不出去。坏处呢？配置僵化，维护成本高。我在给军工项目做审计时，他们全机房用的 MAC，每次加一个新角色，要写一大堆策略文件，改起来比写业务代码还痛苦。
为什么有的场景必须用 MAC？因为合规。像金融交易系统、政府涉密系统，法规要求你不能让用户随意改权限等级。这时候 DAC 就不被允许了。
基于角色的访问控制（RBAC）——工业界的万金油
RBAC 的全称是 Role-Based Access Control。它引入了一个中间层：角色。用户不直接分配权限，而是先分配给角色，角色再关联权限。
你想想看，一个公司的组织架构里，有"财务经理""开发工程师""运维主管"这些角色。每个角色做什么是相对固定的。RBAC 正好匹配这种现实场景。
RBAC 的三个核心关系：
- 用户-角色分配： 一个用户可以拥有多个角色。
- 角色-权限分配： 一个角色可以拥有多个权限。
- 角色层次： 角色可以继承（比如管理员继承用户角色）。
我最喜欢的 RBAC 特性是 最小权限原则 特别好落地。给每个角色只配它需要的最小权限集。开发工程师的角色只包含读代码库、写自己模块的权限，不能碰生产数据库。这样即使某人的账号被偷，损失也能控制住。
缺点也不是没有。角色多了会膨胀——我见过一个系统里有两百多个角色，维护起来像在猜谜。而且 RBAC 没有细粒度约束能力，比如"只能操作自己创建的订单"这种动态的权限，RBAC 本身做不到，需要配合属性或策略引擎。
三者的关键差异
| 维度 | DAC | MAC | RBAC |
|---|---|---|---|
| 决策主体 | 资源所有者 | 系统安全策略 | 角色 |
| 灵活性 | 高（可随意授权） | 低（强制绑定标签） | 中（通过角色调整） |
| 安全性 | 低（容易人为泄露） | 高（符合合规要求） | 高（分离职责） |
| 管理成本 | 低（分散管理） | 高（集中策略配置） | 中（角色维护 & 审计） |
| 典型场景 | 个人文件共享、家庭场景 | 军方、政府、金融核心交易 | 企业级 Web 应用、API 管理系统 |
嗯，这里要注意，很多系统实际上是混合使用的。比如操作系统层面用 MAC 保护内核，应用层面用 RBAC 管理用户权限。
一张图理清三种模型的关系
核心结论：
- 如果你在做一个 多人协作但有信任基础 的小项目，DAC 起步快。
- 如果你的客户是 银行、政府、医疗，别犹豫，上 MAC 或至少用 MAC 风格的多级安全模型。
- 如果你做的是 标准的 Web 应用、SaaS 平台，RBAC 是最稳妥的选择——我自己的微服务网关项目就全用的 RBAC，配合 JWT 做角色声明，线上跑了三年没出过权限事故。
嗯，关于三种权限模型的对比就聊到这里。实际做接口加密设计时，选对模型只是第一步，后续的细粒度控制、策略下沉还得靠别的机制。但模型好比骨架，骨架对了后面长肉才不会歪。