3. 授权模型（上）：自主访问控制（DAC）与强制访问控制（MAC）详解
聊完身份认证，接下来就是权限体系的核心——授权模型。说白了，就是「谁可以干什么」这个问题的具体落地方式。
我刚开始做数据安全那几年，见过不少团队把权限搞得特别复杂。后来发现，其实大部分场景都逃不开两种基础模型：自主访问控制（DAC）和强制访问控制（MAC）。今天咱们就把这两个模型彻底讲透。
核心观点：DAC 是「我的地盘我做主」，MAC 是「规则说了算」。理解这两者的区别，是设计权限体系的基石。
3.1 自主访问控制（DAC）—— 最直观的权限模型
DAC 的全称是 Discretionary Access Control。这里的「自主」指的是：资源的所有者可以自行决定谁有权访问自己的资源。
你想想看，Linux 文件系统就是最典型的 DAC 模型。我创建了一个文件，我可以决定给谁读、给谁写、给谁执行。这就是自主。
3.1.1 DAC 的核心特征
- 资源所有者说了算：创建者拥有最高权限，可以随意授权或撤销权限。
- 权限可传递：所有者可以把权限授予别人，被授权的人可能还能继续往下传。
- 实现简单：系统只需要维护一个访问控制列表（ACL）或权限位。
举个例子，Linux 的文件权限就是 DAC 的经典实现：
# 查看文件权限
$ ls -l important.doc
-rw-r--r-- 1 alice staff 1024 Mar 15 10:00 important.doc
# alice 可以自主修改权限
$ chmod 700 important.doc
$ chown bob important.doc这里 alice 作为文件所有者，可以随时修改权限，甚至把所有权转让给 bob。这就是「自主」的体现。
我的经验：我在做企业内部文档管理系统时，就采用了 DAC 模型。每个文档的创建者可以邀请协作者，设置只读或编辑权限。这种模式对用户来说非常直观，几乎不需要培训就能上手。
3.1.2 DAC 的优缺点
| 优点 | 缺点 |
|---|---|
| 灵活性高，用户自主性强 | 安全性依赖用户判断，容易误操作 |
| 实现简单，系统开销小 | 权限可能被恶意传递，造成信息泄露 |
| 符合直觉，用户容易理解 | 无法防止木马程序利用用户权限作恶 |
| 适合协作场景 | 大规模管理时权限容易失控 |
避坑指南：我曾经遇到过一个案例，某员工把自己的共享文件夹权限设成了「所有人可写」，结果被内部恶意脚本篡改了重要数据。DAC 虽然灵活，但一定要配合审计和默认最小权限原则使用。
3.2 强制访问控制（MAC）—— 规则高于一切
MAC 的全称是 Mandatory Access Control。和 DAC 相反，MAC 的核心思想是：权限由系统统一管理，用户不能自行改变。
为什么会需要 MAC？你想想看，在军事或政府系统中，一份「绝密」文件，能因为某个将军一时兴起就授权给一个「秘密」级别的人看吗？显然不行。这时候就需要 MAC 来强制约束。
3.2.1 MAC 的核心特征
- 系统级策略：权限规则由安全管理员统一制定，普通用户无法修改。
- 标签机制：每个主体（用户/进程）和客体（文件/资源）都有安全标签。
- 不可绕过：即使资源所有者也不能违反系统策略。
MAC 最经典的实现是 Bell-LaPadula 模型（BLP），它有两个核心规则：
- 不上读（No Read Up）：低安全级别的用户不能读取高安全级别的信息。
- 不下写（No Write Down）：高安全级别的用户不能向低安全级别写入信息。
用表格来理解更清楚：
| 用户级别 | 可读级别 | 可写级别 |
|---|---|---|
| 绝密 | 绝密、秘密、内部、公开 | 绝密 |
| 秘密 | 秘密、内部、公开 | 秘密、绝密 |
| 内部 | 内部、公开 | 内部、秘密、绝密 |
| 公开 | 公开 | 公开、内部、秘密、绝密 |
注意看，秘密级别的用户不能读绝密文件（不上读），但可以写绝密文件（因为高向低写是允许的）。这个模型主要保证的是机密性。
我的习惯：在做金融系统安全设计时，我经常把 MAC 和 DAC 结合使用。核心交易数据用 MAC 强制保护，普通办公文档用 DAC 灵活管理。这样既保证了关键资产的安全，又不影响日常协作效率。
3.3 DAC vs MAC：核心对比
这两个模型不是非此即彼的关系。在实际系统中，它们经常共存。我整理了一个对比表：
| 维度 | DAC | MAC |
|---|---|---|
| 控制主体 | 资源所有者 | 系统安全策略 |
| 灵活性 | 高 | 低 |
| 安全性 | 依赖用户判断 | 系统强制保证 |
| 实现复杂度 | 低 | 高 |
| 典型场景 | 文件系统、协作平台 | 军事、政府、金融核心系统 |
| 防木马能力 | 弱 | 强 |
| 用户感知 | 明显 | 透明 |
3.4 知识体系图：DAC 与 MAC 全景
下面这张图展示了 DAC 和 MAC 在整个授权模型中的位置和关系：
3.5 实际系统中的选择策略
那么问题来了：实际项目中到底该用 DAC 还是 MAC？
我的建议是分三步走：
- 先评估数据敏感度：如果数据泄露会造成重大损失，优先考虑 MAC。
- 再看用户规模：小团队协作用 DAC 就够了，大规模组织需要 MAC 统一管控。
- 最后考虑合规要求：等保、GDPR 等法规可能强制要求某些场景使用 MAC。
我曾经踩过的坑：有个项目一开始全用 DAC，结果审计发现普通员工能访问高管薪酬数据。后来我们引入了 MAC 标签，给薪酬数据打上「机密」标签，只有 HR 总监和财务 VP 能访问。这个改动虽然增加了管理成本，但合规问题彻底解决了。
嗯，DAC 和 MAC 就讲到这里。这两种模型是权限体系的基石，理解透了，后面讲 RBAC 和 ABAC 时你会觉得特别轻松。记住一句话：DAC 管「人」，MAC 管「规则」，两者结合才是王道。