1. 权限模型基础：从 DAC 到 MAC 再到 RBAC
权限模型这东西，说白了就是「谁能在什么条件下对什么东西做什么事」。我早年刚接触安全设计时，觉得权限不就是个开关嘛——能访问或不能访问。后来被现实狠狠教育了几次，才明白这里面的门道有多深。
今天咱们就把权限模型的演进史捋一遍。从最早的 DAC，到强控的 MAC，再到如今最主流的 RBAC。每个模型都有它的诞生背景和适用场景，理解了这些，你才能在设计系统时选对路子。
1.1 DAC：自主访问控制
DAC 全称 Discretionary Access Control，中文叫「自主访问控制」。它是权限模型里最古老、也最直观的一种。
核心思想：资源的所有者说了算。
你创建了一个文件，你就是它的主人。你可以决定谁能读、谁能写、谁能执行。Linux 文件系统就是典型的 DAC——chmod 755、chown 这些命令，本质上都是在做 DAC 的权限分配。
DAC 的关键特征：
- 权限由资源所有者自主管理
- 权限可以传递（比如 A 授权给 B，B 再授权给 C）
- 实现简单，性能开销小
我在项目中遇到过一个问题：某内部系统用了 DAC 模型，结果一个部门主管把自己的文件夹权限「共享」给了全公司。你想想看，这本来只是部门内部的项目文档，一夜之间所有人都能看了。这就是 DAC 最大的隐患——权限传播不可控。
避坑指南：我曾经接手过一个遗留系统，里面 DAC 权限链长达 7 层。A 授权给 B，B 授权给 C……最后根本查不清谁到底有什么权限。如果你要用 DAC，务必加上「权限传播深度限制」和「授权审计日志」。
1.2 MAC：强制访问控制
MAC 全称 Mandatory Access Control，中文叫「强制访问控制」。它和 DAC 完全是两个极端。
核心思想：系统说了算，用户没得选。
在 MAC 模型里，每个主体（用户、进程）和每个客体（文件、资源）都被打上了安全标签。系统根据预设的规则来判断是否允许访问。用户？用户没有修改权限的资格。
最经典的 MAC 实现是 SELinux 和 AppArmor。嗯，这里要注意——很多 Linux 管理员觉得 SELinux 烦人，直接关了。但如果你做的是金融系统或政务系统，MAC 几乎是强制要求。
| 对比维度 | DAC | MAC |
|---|---|---|
| 权限决策者 | 资源所有者 | 系统策略 |
| 灵活性 | 高 | 低 |
| 安全性 | 低（易被绕过） | 高（强制执行） |
| 管理成本 | 低 | 高 |
| 典型场景 | 个人电脑、小团队 | 军事、政府、金融核心 |
为什么会这样？因为 MAC 的设计初衷就是「防内鬼」。假设一个恶意软件拿到了你的用户权限，在 DAC 下它可以为所欲为。但在 MAC 下，即使它拿到了你的身份，系统策略依然会阻止它访问机密文件。
个人经验：我建议在容器化环境中至少开启 AppArmor 或 seccomp。Docker 默认的安全配置其实很松，加上 MAC 层保护后，即使容器被攻破，攻击者也很难逃逸到宿主机。
1.3 RBAC：基于角色的访问控制
RBAC 全称 Role-Based Access Control，中文叫「基于角色的访问控制」。它是我个人最常用的模型，也是目前企业级系统的标配。
核心思想：权限不直接给用户，而是给角色。用户通过扮演角色来获得权限。
你想想看，一个公司有成百上千员工，如果每个人单独配权限，那 IT 部门得累死。RBAC 的做法是：先定义好「管理员」「审计员」「普通用户」这些角色，然后把权限挂到角色上。新员工入职，直接分配一个角色就完事了。
RBAC 的三个基本规则：
- 角色分配：用户只有被分配了角色，才能获得权限
- 角色授权：角色只有被授予了权限，用户才能执行操作
- 权限互斥：某些角色不能同时分配给同一个人（比如出纳和会计）
# 一个简化的 RBAC 数据模型示例
# 用户表
users: { id, name, department }
# 角色表
roles: { id, name, description }
# 权限表
permissions: { id, resource, action }
# 用户-角色关联
user_roles: { user_id, role_id }
# 角色-权限关联
role_permissions: { role_id, permission_id }
我在项目中遇到过最典型的 RBAC 坑是「角色爆炸」。一开始只定义了 3 个角色，半年后变成了 47 个。为什么会这样？因为业务方不断提新需求：「这个报表 A 组能看，B 组不能看」「这个按钮只有经理能点，主管不行」……
避坑指南：我曾经在一个电商平台项目里，因为角色粒度太细，最后搞出了 200 多个角色。后来我们引入了「角色继承」和「属性条件」才把数量降下来。记住：RBAC 的角色数量建议控制在 20 个以内，超过这个数就该考虑升级到 ABAC 了。
1.4 三种模型的演进逻辑
从 DAC 到 MAC 再到 RBAC，不是简单的「新模型取代旧模型」，而是不同安全需求催生了不同的解决方案。
我个人习惯这样选型：
- 个人工具或原型系统 → DAC 就够了，别过度设计
- 合规要求高的系统（金融、医疗、政务）→ 必须上 MAC 或至少 MAC + RBAC 混合
- 企业级业务系统 → RBAC 是首选，灵活性和安全性平衡得最好
一个小建议：别死磕单一模型。我在实际项目中经常用「RBAC + 属性约束」的混合方案。比如：角色决定「能做什么」，但加上「部门属性」「时间属性」「IP 属性」等条件做二次过滤。这样既保留了 RBAC 的易管理性，又弥补了它「粒度不够细」的短板。
1.5 本章小结
权限模型没有银弹。DAC 灵活但危险，MAC 安全但僵化，RBAC 平衡但容易角色膨胀。理解它们的核心差异和适用场景，比死记硬背概念重要得多。