访问控制基础
每次有人问我「访问控制到底管什么」，我都会用一句话回他：谁，能对什么，做什么。
这是整个安全体系的基石。你想想看，不管系统多复杂，最终要回答的就是这三个问题——主体是谁？客体是哪份资源？允许的操作是什么？
我刚开始做后端的时候，觉得权限不就加个 if 判断嘛，后来被线上事故教育了……嗯，从那以后我再也不敢小看访问控制的设计了。
什么是访问控制
访问控制，说白了就是一套规则引擎。它决定了一个用户（进程、服务）能不能读写某个文件、调用某个 API、进入某个房间。
核心三要素：
- 主体（Subject）——请求动作的发起方。用户、进程、API 客户端都算。
- 客体（Object）——被访问的资源。文件、数据库记录、微服务接口、甚至物理门禁。
- 操作（Operation）——对客体执行的动作。读、写、执行、删除、审批。
记住这个三角关系：主体 → 操作 → 客体。所有访问控制模型都是在这个基础上加了一层策略引擎。
我见过很多团队一开始只做简单的白名单，后来业务膨胀，权限矩阵直接变成意大利面条。所以，先理解模型，再写代码——这个顺序不能反。
自主访问控制（DAC）
DAC 的全称是 Discretionary Access Control。关键词是「自主」——资源的拥有者可以自己决定谁可以访问它。
最典型的例子就是 Linux 文件权限：rwx rwx rwx。文件所有者可以用 chmod 随便改权限，甚至直接给所有人 777。
我踩过的坑：有一次上线前做了个临时脚本，顺手 chmod 777，结果被扫描工具扫出来告警。虽然没出事，但被安全部门约谈了一下午。从此我养成习惯——生产环境禁止 777，能用 755 绝不用 777。
DAC 的优缺点
| 优点 | 缺点 |
|---|---|
| 灵活，用户可自由授权 | 权限容易失控，用户可能不小心把敏感数据暴露给所有人 |
| 实现简单，操作系统原生支持 | 无法做到集中管控，审计困难 |
| 适合个人环境或小团队 | 大型组织里几乎不可控，合规性差 |
⚠️ 我曾经在一个金融项目里看到有人用 DAC 管理生产数据库的读取权限，结果是某个运维手滑，把整个库的读权限给了匿名用户。这不是 DAC 的错，而是在需要强制策略的场景下选了错误的模型。
强制访问控制（MAC）
MAC 和 DAC 正好相反——所有策略由系统强制实施，普通用户无权改变。每个主体和客体都有一个安全标签（比如绝密、机密、公开），系统根据标签关系决定是否允许访问。
最典型的 MAC 实现是 SELinux 和 AppArmor。我记得第一次配 SELinux 的时候，被那些策略文件搞到头秃——明明 root 用户都会 Permission denied。后来才明白，MAC 是即使你是 root，也不能绕过。
MAC 的核心规则
- 向下读，向上写（Bell-LaPadula 模型）：低级别人能读低级别，不能读高级别；但可以写高级别——防止信息从高向低泄露。
- 向上读，向下写（Biba 模型）：用于完整性保护，防止低完整性数据污染高完整性数据。
在实际项目中，MAC 常见于政府、军事、金融等要求高安全的环境。我曾在某个合规要求特别严的客户那里，被迫给每个容器打上 security_context 标签，当时心里直呼「杀鸡用牛刀」——但客户满意就行。
💡 如果你不是做 OS 层级的安全加固，尽量不要碰 MAC。配置成本极高，运维排障时可能会怀疑人生。但如果你对「即使系统被攻破，数据依然安全」有硬性要求，那 MAC 是不可替代的。
基于角色的访问控制（RBAC）
RBAC 是我在实战中使用频率最高的模型。它引入了一个中间层——角色。用户不再直接和权限关联，而是通过角色间接获得权限。
举个例子：
- 用户 A 是「管理员」角色 → 这个角色有「所有权限」
- 用户 B 是「只读用户」角色 → 这个角色只有「读权限」
你想想看，如果一个公司有 1000 个员工，每个人直接配权限，维护起来就是噩梦。但用 RBAC，你只需要定义 10 个角色，然后把员工塞进角色里——管理成本瞬间降低。
RBAC 的三个核心原则
- 角色继承：高级角色可以继承低级角色的权限。
- 最小权限：一个角色只赋予完成工作所需的最小权限。
- 职责分离：比如「出纳」和「会计」不能由同一个人担任，角色的组合不能导致欺诈。
三种模型对比速查
| 模型 | 谁控制策略 | 典型场景 | 我遇到的教训 |
|---|---|---|---|
| DAC | 资源所有者 | 个人电脑、小团队、文件共享 | 777 害人不浅，审计困难 |
| MAC | 系统/安全管理员 | 高安全环境、多级安全系统 | 配置复杂，排障玄学 |
| RBAC | 角色管理员 | 企业内部系统、SaaS平台 | 角色爆炸，需要定期清理 |
知识体系总览
下面这张图帮你把三种模型的关系串起来。我把核心要素放在一起对比——主体、客体、策略来源、以及最常见的应用场景。
💡 从图里你能看出来，三种模型本质上都是在「主体→操作→客体」这条链上插了一个策略判断层。区别只在谁制定策略、策略能多灵活。我在做架构选型时，一般先问两个问题：
- 场景对合规有强要求吗？→ 考虑 MAC
- 用户量大、角色多吗？→ 用 RBAC
- 只是个人工具或临时项目？→ DAC 够用
好了，这一章我们把三个经典模型捋了一遍。说实话，这三者并不是互斥的——很多现代系统会混合使用（比如 Kubernetes 用 RBAC 管理用户，底层文件系统用 DAC，Pod 安全策略又隐含 MAC 的概念）。关键是你要理解每一种的设计意图和适用边界。
我习惯在项目初期就画一张类似的对比图，拉着团队过一遍——比写十页文档有效多了。下次遇到权限相关的设计，先想清楚你要的是 DAC 的灵活，还是 MAC 的强控，或者 RBAC 的易管理。选对了模型，后面至少少踩一半坑。