强制访问控制（MAC）原理与多级安全
聊到强制访问控制，很多人第一反应就是“政府、军队才用的东西”。其实没那么玄乎。说白了，MAC 的核心就一句话：权限不由你说了算，系统说了算。
我在做金融合规项目时遇到过这么个场景：某银行的核心交易系统，运维人员居然能自己修改数据库访问权限。审计一查，直接亮红灯。后来我们把 DAC 换成 MAC，所有标签由安全管理员统一配置，运维只能操作自己敏感层级以内的数据。嗯，这才符合等保三级的要求。
你想想看，在 DAC 模式下，文件所有者想给谁读就给谁读——这就像你家大门钥匙自己复制。但 MAC 不一样，每个人进门必须刷身份证，系统自动判断你够不够级别。这个判断依据，就是今天要讲的核心：多级安全（MLS）。
1. MAC 与 DAC 的本质区别
我用一个对比表格帮你快速理清思路：
| 特性 | DAC（自主访问控制） | MAC（强制访问控制） |
|---|---|---|
| 权限决策者 | 资源所有者（用户） | 系统（安全策略） |
| 标签机制 | 无，直接授权 | 主体/客体绑定安全标签 |
| 灵活性 | 高，用户可传递权限 | 低，策略统一不可绕过 |
| 安全强度 | 中，易被钓鱼利用 | 高，对抗内部威胁 |
| 典型场景 | 个人文件共享、OA系统 | 军事系统、金融核心、政务平台 |
从表里你能看出：MAC 的“强制”二字，体现在管理员制定的规则比用户权限高。用户就算是大领导，也没法把自己文件的密级降下来分享给低级别的人——系统会直接拦截。
2. 多级安全模型：Bell-LaPadula（BLP）
谈到 MAC 就绕不开 Bell-LaPadula 模型。这是 70 年代美国军方搞出来的东西，专门用来防止信息从高密级向低密级泄露。核心规则就两条：向上读、向下写。
别着急，我用一张图把它讲清楚：
看到这个“向上读、向下写”了吗？我刚开始学的时候总搞反。记住：读的方向是从低到高，写的方向是从高到低。为什么这样设计？因为读高密级文件属于“知情”，只要你的级别够高就行；但写入操作如果允许低密级主体写高密级客体，就可能把病毒塞进绝密文档——系统必须防住这种事。
允许读：主体安全级 ≥ 客体安全级 且 主体范畴 ⊆ 客体范畴
允许写：主体安全级 ≤ 客体安全级 且 主体范畴 ⊇ 客体范畴
其实不光有密级（Classification），还有范畴（Category）。密级是高低，范畴是部门。比如“绝密-工程部”与“秘密-财务部”，即使你的密级高，如果范畴不匹配，依然无法访问。我遇到过客户只配了密级忘了配范畴，结果高密级人员连自己项目文件都打不开——这就是“只知其一，不知其二”。
3. Biba 完整性模型
BLP 管的是保密性，完整性怎么办？这就得请出 Biba 模型了。Biba 与 BLP 正好相反：向下读、向上写。
| 特性 | Bell-LaPadula（保密性） | Biba（完整性） |
|---|---|---|
| 核心原则 | 上读下写 | 下读上写 |
| 防什么 | 信息泄露 | 信息篡改 |
| 写方向 | 只能写同/低密级 | 只能写同/高密级 |
| 读方向 | 只能读同/高密级 | 只能读同/低密级 |
| 适用场景 | 机密文档流转 | 生产系统数据完整性 |
这里有个关键点：实际项目中常常把 MAC 策略拆成“机密性 MAC”和“完整性 MAC”两条线。比如银行核心交易系统，既要防泄密（BLP），又要防止数据被低完整性程序污染（Biba）。两条线可以在不同层次叠加，但别混在一起配——我曾经在同一个安全标签上同时启用 BLP 和 Biba，结果配成了“既不能读也不能写”的死锁。那叫一个惨。
4. 实际部署中的坑
1. 标签变更后未刷新缓存：SELinux 策略改完必须 restorecon 或触发重新标记，否则系统还在用旧标签，你以为防住了其实没防住。
2. 范畴设计过于复杂：某甲方把范畴细到了科室+项目+年份，结果一个有十几年运维经验的老工程师要填 30 多个范畴，最后走审批流程走了两周。建议范畴不超过 10 个。
3. 忘记给系统进程打标签：系统服务（如 sshd）如果没有 MLS 标签，会落到最低密级，结果连高密级文件日志都打不开，业务直接瘫痪。
记得有一次，我帮一个政务云做 MAC 加固。负责的领导问：“我们所有服务器用了 SELinux 是不是就安全了？”我告诉他：SELinux 只是实现 MAC 的一种机制，真正起作用的是你配的安全策略——标签、规则、默认 deny 原则。否则默认 permissive 模式开了，等于没开。
5. 多级安全归纳总结
收拢一下今天的内容：
- MAC 的核心是系统决策，不依赖用户自主操作。
- 多级安全（MLS）用标签+规则实现信息流控制。
- Bell-LaPadula 管保密，上读下写；Biba 管完整，下读上写。
- 实际落地必须同时考虑密级、范畴、进程标签和刷新机制。
我每次设计 MAC 策略之前，一定会先把业务的数据流图画出来——哪些数据要保密，哪些数据要完整，哪些是主体、哪些是客体。然后才去配标签，配完后必须做一次“端点穿透测试”：让不同级别的主体尝试读写越界，看系统是否真正拦截。这个测试我建议你也做，别怕麻烦。
好了，课后你可以把自己公司的某个系统拿出来，试着画一份 MLS 标签矩阵。看看如果按照 BLP 模型，哪些访问应该被禁止，哪些应该被允许。你会发现，很多你以前觉得“理所当然”的权限，其实都是 MAC 漏洞。