4. 强制访问控制模型:MAC模型原理、Bell-LaPadula模型、Biba模型、优缺点分析

强制访问控制(Mandatory Access Control, MAC)是一种由系统强制实施、用户无法自行修改的访问控制策略。与自主访问控制(DAC)不同,MAC 中主体(用户/进程)和客体(文件/资源)都被分配了固定的安全属性,所有访问决策由系统根据预定义的安全策略自动裁决,用户无权转让或修改权限。MAC 模型在工程分析平台中常用于保护高敏感度的设计数据、仿真结果和知识产权。

4.1 MAC模型核心原理

MAC 模型的核心思想是“系统主导,用户服从”。其基本原理包含以下三个关键要素:

  • 安全标签(Security Label):每个主体和客体都被分配一个不可篡改的安全标签,通常包含密级(如:公开、内部、机密、绝密)和范畴(如:项目A、部门B)。
  • 策略规则(Policy Rules):系统预定义访问规则,如“禁止上读”或“禁止下写”,所有访问请求必须通过规则校验。
  • 引用监视器(Reference Monitor):系统内核中的安全核心组件,负责拦截所有访问请求并依据策略规则进行裁决。
工程分析平台场景提示: 在工程分析平台中,MAC 模型常用于隔离不同客户的项目数据。例如,为“项目X”的仿真结果打上“机密-项目X”标签,只有同样具有“机密-项目X”标签的用户进程才能读取,有效防止跨项目数据泄露。
MAC模型核心架构:引用监视器与安全标签 主体 (Subject) 用户 / 进程 安全标签: 机密-项目A 引用监视器 策略裁决引擎 规则: 禁止上读 / 禁止下写 客体 (Object) 文件 / 数据库 安全标签: 机密-项目A 安全策略库 BLP / Biba / 自定义规则 审计日志 记录所有裁决结果

4.2 Bell-LaPadula模型(BLP模型)

Bell-LaPadula(BLP)模型是历史上最早、最经典的 MAC 模型之一,由 David Bell 和 Leonard LaPadula 于 1973 年提出,主要应用于军事和政府机密系统,强调保密性(Confidentiality)。

4.2.1 核心规则

BLP 模型基于安全标签的偏序关系(如:公开 < 内部 < 机密 < 绝密),定义了以下两条核心规则:

规则名称 规则描述 通俗理解
简单安全规则(SS-Property) 主体只能读取安全级别 不高于 其自身级别的客体。 “不能上读”:低级别用户不能读取高级别文件。
星号安全规则(*-Property) 主体只能写入安全级别 不低于 其自身级别的客体。 “不能下写”:高级别用户不能将数据写入低级别文件。
工程实践要点: BLP 模型通过“禁止上读”和“禁止下写”的组合,有效防止了高密级信息向低密级区域流动,从而保护了数据的保密性。在工程分析平台中,可用于保护核心算法和未公开的仿真模型。
Bell-LaPadula模型:保密性规则示意 高安全级别(绝密) 高级别主体 高级别客体 允许读 (SS-Property) 低安全级别(公开) 低级别主体 低级别客体 禁止上读 (SS-Property) 禁止下写 (*-Property)

4.3 Biba模型

Biba 模型由 Kenneth J. Biba 于 1977 年提出,与 BLP 模型形成互补,主要关注完整性(Integrity)。Biba 模型的核心目标是防止低完整性级别的数据污染高完整性级别的数据。

4.3.1 核心规则

Biba 模型同样基于安全标签的偏序关系,但其规则方向与 BLP 相反:

规则名称 规则描述 通俗理解
简单完整性规则(SI-Property) 主体只能读取安全级别 不低于 其自身级别的客体。 “不能下读”:高完整性主体不能读取低完整性数据。
星号完整性规则(*-Property) 主体只能写入安全级别 不高于 其自身级别的客体。 “不能上写”:低完整性主体不能写入高完整性区域。
模型冲突警示: BLP 和 Biba 模型在规则上是互逆的。在实际工程中,无法同时完整实现两个模型,必须根据业务目标(保密性优先 vs 完整性优先)进行取舍或采用折中方案。在工程分析平台中,若需同时保护仿真数据的保密性和完整性,通常建议采用“BLP 为主 + 局部 Biba 约束”的混合策略。

4.4 优缺点分析

MAC 模型(包括 BLP 和 Biba)在工程分析平台中的适用性需要结合具体场景评估。以下从多个维度进行对比分析:

维度 优势 劣势
安全性 系统级强制策略,用户无法绕过,有效防止特洛伊木马和数据泄露。 策略过于刚性,可能阻碍正常业务流程,导致“过度保护”。
管理成本 安全标签统一管理,策略集中配置,便于审计和合规。 初始标签定义和分类工作量大,维护成本高,灵活性差。
适用场景 军事、政府、金融、高保密研发等对数据分级要求严格的领域。 不适合需要频繁动态授权或细粒度协作的敏捷开发环境。
用户体验 用户无需关心权限分配,系统自动处理,降低误操作风险。 用户可能因标签不匹配而无法完成正常操作,体验受限。
工程分析平台适配性 适合保护核心算法库、未公开仿真模型、客户敏感数据。 多项目协作时,标签冲突和跨项目数据共享需要额外机制。

4.5 工程分析平台中的选型建议

在工程分析平台中,MAC 模型的选型应遵循以下原则:

  1. 明确安全目标:若平台主要保护设计图纸和仿真结果的保密性,优先考虑 BLP 模型;若更关注数据不被篡改(如实验记录、审批流程),则优先考虑 Biba 模型。
  2. 标签粒度设计:安全标签不宜过细,建议按“项目-密级”两级结构设计,避免标签爆炸导致管理失控。
  3. 混合策略实施:在核心数据区域实施 MAC,在协作区域(如共享文档库)保留 DAC 或 RBAC 的灵活性。
  4. 审计与回溯:MAC 模型必须配合完整的审计日志系统,记录所有被拒绝的访问请求,用于安全事件溯源。
最佳实践: 在工程分析平台中,推荐采用“MAC 保护核心资产 + RBAC 管理日常操作”的混合架构。例如,将核心仿真模型库设置为“绝密-项目A”标签,仅允许通过 BLP 规则验证的特定进程访问;而项目内部的日常协作则使用 RBAC 进行角色授权,兼顾安全与效率。