2、RBAC与传统访问控制对比：DAC、MAC、RBAC的优缺点及适用场景
做权限模型选型，很多团队上来就套RBAC，觉得它最流行。但真相是——没有万能模型，只有合适的模型。我自己第一次做企业级权限系统时，就踩过「模型选错」的坑。后来复盘才明白，先理解DAC、MAC、RBAC的本质差异，比直接画角色树重要得多。
核心观点：三种模型对应三种不同的安全哲学。DAC交权给用户，MAC交权给系统，RBAC交权给角色。选哪个，取决于你愿意把「谁可以做什么」的决定权放在哪一层。
2.1 自主访问控制（DAC）
DAC的全称是Discretionary Access Control，翻译过来就是「资源主人说了算」。什么意思？每个文件的创建者可以自主决定谁有权限读、写、执行。
我记得最早接触DAC是在Linux文件系统上。一个普通用户创建了一个文件，chmod 777就把所有权限敞开了。这种模型在早期Unix时代很常见，因为它简单、灵活。
优点：用户直接控制，方便共享；实现成本低；适合团队内部非敏感信息交换。
缺点：权限容易扩散——一个同事离职，他的文件也许永远没人关闭。我在项目中遇到过，一个部门经理嫌申请流程慢，直接把自己文件夹的写权限给了全公司，结果某天被误删了一整版报表。这就是DAC的典型「好心办坏事」。
适用场景：个人桌面环境、非结构化团队协作、低安全等级的临时项目。
| 维度 | DAC特点 |
|---|---|
| 决策权归属 | 资源创建者（用户） |
| 灵活性 | 高（用户可随意授权） |
| 安全性 | 低（难以控制权限扩散） |
| 管理成本 | 低（不依赖集中管理） |
| 典型代表 | Linux rwx、Windows NTFS ACL |
避坑提醒：千万不要用DAC管理核心业务系统的访问权。你想想看，每个用户都能给别人授权，权限图很快就会变成一团乱麻，审计时根本说不清楚「这个权限是谁给的、为什么给」。
2.2 强制访问控制（MAC）
MAC走的是另一个极端——权力交给系统，用户自己不能改。系统根据安全标签（比如机密、秘密、绝密）和预设规则，自动决定谁可以访问什么。
我第一次接触MAC是在做军工项目审计的时候。那个系统里每个用户有个「安全级别」，每个文档也有一个。系统直接拒绝低级用户访问高级文档，管理员都没法强行放行。说实话，当时我被这种「硬核」方式震住了——安全性确实强，但灵活性也几乎为零。
优点：安全性极高，权限不可绕过；适合高密级场景；审计路径清晰，因为所有决定都由系统规则驱动，不存在人为放水。
缺点：太僵化了。我曾经帮一个客户做MAC改造，他们发现同一个部门里，经理和员工需要访问相同级别的文件，但经理有时还得审批更高级的文件。MAC标签改了又改，最终搞出十几个级别，管理成本飙升。说白了，MAC适合「信息密级分得很清晰」的组织，但现实世界往往是灰度的。
适用场景：军事、政府、涉密研发、金融核心交易数据（需要严格的分级保护）。
| 维度 | MAC特点 |
|---|---|
| 决策权归属 | 系统（基于安全标签） |
| 灵活性 | 极低（用户无权调整） |
| 安全性 | 极高（强制策略不可绕过） |
| 管理成本 | 高（标签定义 + 策略维护） |
| 典型代表 | SELinux、Trusted Solaris、MLS系统 |
2.3 基于角色的访问控制（RBAC）
RBAC是我日常打交道最多的模型。它的思路很简单：把权限打包成角色，把人分配进角色里。你不需要给每个人单独授权，只需要定义好「财务专员角色」「财务经理角色」……然后谁做这岗位，就挂上对应角色。
我做过一个大型ERP系统的权限审计，系统里大概有200个微服务、3000多个API。如果用DAC，每个用户一条ACL，几百人就得几千条规则，乱到没法审计。换成RBAC后，我只定义了12个核心角色，所有权限全收敛了，审计报告一下子清晰起来。
优点：权限与岗位挂钩，支持「职责分离」（比如一个人不能同时拥有订单创建和订单审批角色）；适合中大型组织；审计方便，能把「谁有什么角色」查清楚。
缺点：角色设计是门艺术。如果你把业务场景分得太细，角色数量会爆增——我见过一个客户，角色表里有800多个角色，比用户数还多，这就失去了RBAC的意义。另一个问题是「角色爆炸」和「权限继承层级混乱」，要预先花不少精力设计角色继承树。
适用场景：企业管理系统、SaaS后台、云平台IAM、金融、医疗等对审计有需求的场景。
| 维度 | RBAC特点 |
|---|---|
| 决策权归属 | 角色（管理员定义角色权限） |
| 灵活性 | 中等（角色可调整，用户角色可变更） |
| 安全性 | 较高（支持细粒度控制 + 职责分离） |
| 管理成本 | 中高（角色设计投入大，但后期维护相对稳定） |
| 典型代表 | RBAC0~RBAC3、NIST RBAC标准、AWS IAM、Kubernetes RBAC |
2.4 三种模型的核心思想对比
我画了一张对比图，把三种模型的「控制哲学」串起来。你一眼就能看出它们的根源差异。
从图上你能直观感受到：DAC是用户自己在门口贴告示「谁可以进」；MAC是系统在门口装了个铁门，只认特定通行证；RBAC则是给每个人发一张岗位卡，凭卡找对应权限。
2.5 快速选型参考
实际上，很多系统是混合使用的。比如Linux容器底层用MAC（SELinux），上层用RBAC。但作为审计人员，我建议你先明确核心诉求：
- 如果你最怕的是权限失控 → 优先MAC或严格RBAC
- 如果你最怕的是管理负担 → 优先RBAC，把角色控制在50个以内
- 如果你团队小、变数大 → DAC反而最省事，但必须定期清理
我的经验：做权限审计时，我常常先看模型选型对不对味。如果一个普通电商项目用了MAC，多半是过度设计，审计员会看到大量「权限绕行」的补丁。反之，军工系统用了DAC，审计报告能写出一部短篇小说。选对了模型，后面至少省一半审计精力。
最后总结一句——别再问我「哪个模型最好」。没有最好，只有「你的场景最适合」。你想想看，一个财务系统和一台个人笔记，安全需求能一样吗？