强制访问控制（MAC）：从原理到实战

聊到强制访问控制，我得先坦白一件事——刚入行那会儿，我觉得这玩意儿就是给政府用的，跟我做企业应用没啥关系。直到有一次给某涉密单位做安全审计，才发现自己太天真了。MAC 这东西，说白了就是「系统说了算，用户别想改」。你想想看，在军事或政府场景里，一个士兵能随便把自己的机密文件改成公开吗？当然不行。这就是 MAC 的核心思想。

MAC 的基本原理

强制访问控制，英文叫 Mandatory Access Control，简称 MAC。它跟自主访问控制（DAC）最大的区别在于：权限不由资源所有者决定，而是由系统全局策略统一管控。

我习惯用一个比喻来解释：DAC 就像你家的房门，你可以决定谁进来；MAC 则像银行金库，你连门把手都摸不到，系统会判断你有没有资格进去。

MAC 的两个核心要素：

• 主体（Subject）：用户、进程等主动实体
• 客体（Object）：文件、数据库记录等被动实体

每个主体和客体都被打上了安全标签（Security Label），系统根据这些标签来决定访问是否允许。嗯，这里要注意：标签一旦设定，普通用户无权修改。

Bell-LaPadula 模型：机密性守护神

说到 MAC，绕不开 Bell-LaPadula 模型（简称 BLP）。这是 70 年代美国军方搞出来的东西，目标就一个——防止信息从高密级流向低密级。

BLP 模型有两个核心规则：

• 简单安全规则（Simple Security Property）：主体只能读取安全级别 ≤ 自身级别的客体。说白了，上校不能看将军的文件。
• 星号规则（*-Property）：主体只能写入安全级别 ≥ 自身级别的客体。这意味着，上校不能把自己的文件写到公开区域。

我当年第一次看到这个模型时，觉得「只能向上写」很奇怪。后来在项目中才明白——这是为了防止高密级信息被「写」到低密级区域，从而泄露出去。你想想看，如果允许向下写，一个恶意程序就能把机密数据悄悄写到公开文件里。

规则	含义	通俗解释
简单安全规则	读操作：主体级别 ≥ 客体级别	只能读比自己级别低或同级的内容
星号规则	写操作：主体级别 ≤ 客体级别	只能写比自己级别高或同级的内容

Biba 模型：完整性守护者

BLP 管的是机密性，那完整性谁来管？Biba 模型就是干这个的。它跟 BLP 正好相反——防止低完整性数据污染高完整性数据。

Biba 也有两个核心规则：

• 简单完整性规则：主体只能读取完整性级别 ≥ 自身级别的客体。说白了，不能拿不可信的数据来用。
• 星号完整性规则：主体只能写入完整性级别 ≤ 自身级别的客体。这意味着，高完整性的进程不能把数据写进低完整性的文件。

我个人的经验是：Biba 在工业控制系统里特别有用。比如一个 PLC（可编程逻辑控制器）的控制程序，绝对不能从不可信的来源读取参数——否则整个生产线都可能出问题。

MAC 在军事/政府场景的应用

好了，理论讲完了，咱们看看实战。我在参与某政府单位的安全体系设计时，遇到过典型的 MAC 应用场景。

军事和政府系统通常采用多级安全（MLS）架构。常见的分级：

• 公开（Unclassified）
• 内部（Internal）
• 机密（Confidential）
• 秘密（Secret）
• 绝密（Top Secret）

每个文档、每个用户都被分配一个级别。系统强制保证：

1. 低级别用户无法访问高级别文档
2. 高级别用户不能把文档降级保存
3. 进程不能跨级别传递数据

举个例子：某政府办公系统里，一个「秘密」级别的用户登录后，系统会自动过滤掉所有「绝密」和「机密」级别的文档。他只能看到「秘密」及以下的内容。同时，他创建的文档自动标记为「秘密」，无法手动降级为「内部」。

我曾经踩过一个坑：在配置 SELinux（一个实现了 MAC 的 Linux 安全模块）时，忘了给某个服务进程设置正确的安全上下文。结果服务启动后，无法读取自己的配置文件——因为配置文件的标签比进程高。排查了半天才发现问题。嗯，从那以后，我每次配置 MAC 策略都会先画一张标签映射表。

MAC 的优缺点

说了这么多，咱们客观评价一下 MAC。

优势	劣势
安全性高：策略全局统一，用户无法绕过	灵活性差：用户不能自主授权
适合高安全场景：军事、政府、金融核心	管理成本高：标签维护复杂
防止内部泄露：即使合法用户也无法违规操作	用户体验差：操作受限，容易误判
与操作系统深度集成：如 SELinux、AppArmor	配置难度大：需要专业安全人员维护