4. 强制访问控制（MAC）：Bell-LaPadula模型、Biba模型、多级安全

4.1 为什么需要 MAC？

聊到强制访问控制，我得先提个经历。以前帮某政务系统做审计改造，发现一个怪现象：普通文员居然能访问「机密」级公文附件。一问才知道，RABC 角色配置时漏勾了「仅允许非密文件」的约束。这事其实不怪管理员，RABC 和 DAC 本质上是「用户有权改权限」，一旦人的自由度大了，泄密就是迟早的事。

MAC 的核心理念很简单：安全标签由系统强制管理，主体（用户/进程）和客体（文件/数据）各贴一个密级标签，访问与否全看标签间的数学关系。用户没法绕过，管理员也别想偷偷降级。

4.2 Bell-LaPadula 模型 —— 只上不下

这是美国军方的经典模型，也叫 BLP 模型。它管的是「机密性」—— 防止高密级信息流向低密级。

两条黄金法则：

• 简单安全属性（SS-Property）：主体只能读比自己密级低或相等的客体。说白了，「我机密级可以看机密、秘密、公开，但不能看绝密」。
• 星属性（*-Property）：主体只能写比自己密级高或相等的客体。这个反直觉 —— 为什么允许向上写？怕低密级用户把高密数据悄悄写到低密文件里。

你会发现 BLP 只控制「读」和「写」，不控制「执行」。执行指令本身不涉及数据流动，所以安全模型里一般不单独约束它。

操作	允许条件	防止什么？
读（Read）	主体密级 ≥ 客体密级	高密主体不能读低密数据？不不不，是低密主体不能读高密数据
写（Write）	主体密级 ≤ 客体密级	低密主体不能向低密客体写高密内容
执行	通常不限制	无数据流动

4.3 Biba 模型 —— 只下不上

BLP 保机密，但完整性怎么办？你会看到有些系统里数据明明是对的，经过低完整度用户一改就废了。

Biba 模型反着来 —— 管的是完整性。完整性越高的数据越可信，不允许低完整度用户往高完整度客体里写数据。

• 简单完整性属性：主体只能读比自己完整度高的客体。
• 完整性星属性：主体只能写比自己完整度低的客体。

举个例子：项目经理（高完整度）可以读代码评审报告（高完整度）和普通日报（低完整度），但写的时候只能把报告放到低完整度共享区，不能直接覆盖高完整度基线库。这在 CI/CD 流水线里非常实用。

4.4 多级安全（MLS）—— 标签的体系化

BLP 和 Biba 都是多级安全（Multi-Level Security）的具体实现。MLS 的核心是给每个主体和客体都打上安全标签，标签通常由两部分组成：

• 密级：公开 < 秘密 < 机密 < 绝密
• 范畴：比如「核武器」「常规武器」「外交」「审计」等

访问判定时系统要同时看密级和范畴。例如：一个「机密/核武器」用户能读「机密/核武器」和「秘密/核武器」文件，但不能读「绝密/核武器」，也不能读「机密/外交」—— 因为范畴不同。

MLS 的典型实现有：

• Trusted Solaris / Trusted Ubuntu （带 MLS 内核扩展）
• SEAndroid （对，你的手机里就有 MLS 的影子）
• DBMS 的行级安全（Oracle Label Security、PostgreSQL row-level security with label）

4.5 应用场景：军事/政府

你想想看，军事系统里最怕什么？不是外部黑客，而是内部人员把「机密」文件误发到「公开」打印机上。所以军事和政府会强制使用 MAC：

• 联合指挥系统：同一套系统供不同军种、不同保密等级人员使用，必须靠 MAC 隔离。
• 涉密文档管理系统：文档密级与用户密级绑定，写操作由 BLP 星属性控制。
• 审计日志系统：审计员只能读（可能涉及高密日志），不能写，也不能删除 —— 这也是为什么 MAC 常配合审计埋点一起用。
• 政府公文流转：处处长只能签发密级不超过自己权限的文件，副处长即使有权限也不能越过处长签发 —— 这就结合了 BLP 与 Biba。

4.6 核心知识图谱

4.7 实战建议

做 MAC 千万别只靠理论。我建议你在自己的系统里先做三件事：

1. 梳理所有客体的敏感度—— 给数据库表、存储桶、API 加标签字段
2. 定义用户身份标签 —— 可以用 LDAP 属性或者数据库角色
3. 写入审计日志 —— 每次访问被 MAC 拒绝时，必须记录（否则你无法排查谁在试探）