Day37-07｜18.2.3 Biba 模型：面向完整性的可信信息流控制

对应教材：第 18 章 安全架构设计理论与实践——18.2.3 Biba 模型
学习定位：理解 Biba 模型保护信息完整性的目标，掌握完整性等级、主体与客体、简单完整性性质、* 完整性性质和调用性质，并能够与 Bell-LaPadula 模型对比，分析交易、配置、软件供应链和数据处理场景。

一、Biba 模型解决什么问题

Bell-LaPadula 模型主要防止敏感信息向低密级环境泄露，关注的是机密性；Biba 模型则主要防止低可信或低完整性信息污染高完整性对象，关注的是完整性。

在很多系统中，数据不一定属于不同的保密等级，但可信程度不同。例如，经过审批的生产配置、经过校验的财务账务、签名的软件包和经过认证的传感器数据具有较高完整性；用户提交的未验证输入、外部抓取数据、未经审核的脚本和异常设备上报数据具有较低完整性。如果低可信数据可以直接修改高可信对象，系统就可能执行错误配置、产生错误交易或运行恶意代码。

Biba 模型的基本安全直觉是：

高完整性主体不能读取低完整性数据；低完整性主体不能修改高完整性数据。

常用记忆方式是：

不向下读，不向上写。

它与 Bell-LaPadula 的方向相反，但两者保护目标不同：Bell-LaPadula 保护机密性，Biba 保护完整性。

二、完整性的含义

2.1 数据完整性

数据完整性要求数据准确、完整、一致、未被未经授权地修改。交易金额、库存数量、客户身份、配置参数和审计日志都需要完整性保护。

2.2 来源完整性

来源完整性关注数据是否来自可信主体和可信设备。传感器、第三方接口、供应商文件和外部消息必须经过身份验证、签名校验、格式检查和来源追踪。

2.3 过程完整性

过程完整性要求数据只能通过合法、受控和可审计的程序变化。例如，财务账务不能被数据库管理员直接修改，生产配置不能绕过测试与审批直接发布。

2.4 系统与配置完整性

操作系统、容器镜像、应用代码、网络策略、证书和密钥都属于完整性对象。未经批准的配置变化、软件包替换和镜像篡改可能造成系统行为偏离设计。

完整性不是简单的“数据没丢”。数据即使没有丢失，如果被错误主体修改、被非法流程生成或来源不可验证，也可能不具备可信完整性。

三、Biba 模型的基本元素

3.1 主体与客体

主体是执行读取、写入、调用或修改操作的用户、进程、服务、设备和管理员；客体是文件、数据库、配置、程序、消息、日志、镜像、设备状态和接口资源。

主体和客体都具有完整性级别或标签。完整性级别表示可信程度，通常可以从低到高排列：未验证、普通、已验证、关键或可信根。不同组织可以按照业务和风险定义自己的级别，不一定使用统一名称。

3.2 完整性等级

完整性等级描述主体或客体的可信程度。高完整性对象一般只能由高可信流程维护，低完整性数据不能未经验证地进入高完整性区域。

完整性等级不一定与机密级别相同。一个数据可能保密性高但来源未验证，也可能公开但经过权威发布、具有高完整性。因此实际系统可能需要同时维护机密性标签和完整性标签。

3.3 完整性标签与支配关系

可以将完整性标签表示为：

标签 = (完整性级别，可信域或来源集合)

主体只有在完整性级别和可信域满足策略时，才能读取或写入对象。来源集合可以描述供应商、设备组、项目、审核域或数据处理链。

四、Biba 模型的安全性质

4.1 简单完整性性质

简单完整性性质也称 No Read Down，要求主体不能读取完整性级别低于自身的客体：

主体完整性级别 ≤ 客体完整性级别

这里使用“低级别数值”还是“高级别数值”取决于定义方式，因此答题时最好使用文字说明：高完整性主体不能读取低完整性数据。

例如，生产发布进程不能直接读取未验证的外部脚本或未经清洗的输入；高可信配置管理服务不能把低可信来源当作可信配置直接处理。若确实需要使用低可信数据，必须经过验证、清洗、转换或可信中介。

4.2 * 完整性性质

“*”完整性性质也称 No Write Up，要求主体不能写入完整性级别高于自身的客体：

主体完整性级别 ≥ 客体完整性级别

用文字表达就是：低完整性主体不能修改高完整性对象。这样可以防止普通用户、未经认证的设备、低可信脚本或外部接口直接污染关键配置、账务和生产数据。

4.3 调用性质

调用性质限制低完整性主体调用高完整性主体，防止低可信主体借助高可信服务完成越权修改。只有当调用者完整性级别不低于被调用主体，或者经过可信授权和验证时，调用才允许发生。

例如，一个外部文件处理服务不能直接调用生产配置发布服务；低可信 API 不能直接调用拥有数据库写权限的高可信后台服务。需要通过校验、队列、审批和最小权限的可信中介完成跨级操作。

4.4 规则对比

五、可信中介与完整性提升

现实业务经常需要使用低完整性数据，例如外部订单、客户输入、传感器数据和第三方文件。完全拒绝会影响业务，因此通常需要可信中介完成完整性提升。

5.1 验证

验证来源、签名、证书、时间戳、格式、完整性校验和业务上下文，确认数据确实来自预期主体且未被篡改。

5.2 清洗

去除脚本、危险字段、异常编码、越界数值和不符合格式的内容，避免将恶意或污染数据直接传给高完整性系统。

5.3 转换

将外部格式转换为内部标准格式，统一单位、编码、时间、标识和数据类型。转换程序本身应经过审计、测试和签名。

5.4 审批

对高风险数据或配置变化进行人工或多方审批，保留原始数据、转换结果、审批人和版本关系，形成可追溯链。

5.5 重新标记

只有可信流程完成验证、清洗和转换后，才可以提高数据的完整性标签。标签提升不能由普通用户直接完成，必须由受保护的可信组件执行。

六、Biba 与数据库和交易系统

6.1 交易完整性

交易系统需要保证金额、账户、库存和状态变化通过合法事务完成。用户输入属于低或普通完整性，经过业务规则校验、风控、授权和事务提交后，才可以写入高完整性账务对象。

6.2 数据库权限

数据库管理员拥有技术权限不代表业务上可以直接修改核心账务。可以将生产账务标记为高完整性对象，只允许特定存储过程、交易服务或经过审批的修复流程修改，禁止普通 SQL 工具直接写入。

6.3 消息与事件

消息队列中的外部事件也可能污染下游系统。生产系统应验证消息来源、签名、顺序、幂等号、时间窗口和业务状态，异常消息进入隔离队列，由可信消费者和人工流程处理。

七、Biba 与软件供应链

软件包、容器镜像、配置模板和部署脚本的完整性直接影响运行环境。来源不明的镜像不应直接进入生产集群，低完整性开发分支也不应直接覆盖生产配置。

可以建立如下供应链状态：

外部来源 → 未验证 → 自动扫描 → 签名校验 → 人工或自动审核 → 已批准 → 灰度 → 生产可信

每次状态提升都应有证据，包括来源、哈希、签名、扫描结果、审批、测试、发布版本和回滚版本。生产环境只接受已批准、可追溯和可回退的制品。

八、Biba 与网络和微服务

8.1 服务完整性

微服务之间的调用不应仅根据网络可达性判断可信。服务应具有身份、版本、来源和完整性状态，调用权限根据服务角色、数据对象和操作类型判断。

低完整性服务不能直接调用高完整性账务服务或配置服务。若必须调用，应通过 API 网关、消息队列、校验服务或审批服务完成受控转换。

8.2 网络区域

网络可以划分外部接入区、开发区、测试区、生产区和管理区，并为不同区域设置完整性信任级别。高完整性生产区域禁止低可信路径直接写入，区域之间的通信通过经过认证和审计的中介。

8.3 设备与终端

终端健康状态、固件签名、可信启动和补丁状态可以作为完整性标签来源。未通过健康检查的终端只能进入隔离区，不能直接访问高完整性生产系统。

九、Biba 的优点

9.1 明确保护目标

Biba 清楚表达了完整性与机密性的区别，能够帮助架构师识别“数据没泄露但被篡改”这一类风险。

9.2 约束污染路径

通过限制低可信主体向高完整性对象写入，减少错误数据、恶意配置和未经验证代码的传播。

9.3 适合高可信处理链

软件发布、财务交易、生产控制、审计日志和供应链制品都可以通过完整性级别和状态提升过程进行治理。

9.4 支持分层验证

系统可以把验证、清洗、审批和发布设计为逐级提升完整性的流程，便于审计和追责。

十、Biba 的局限

10.1 主要关注完整性

Biba 不能单独解决保密性、可用性、隐私、业务权限和不可否认性，需要与其他模型、加密、身份和恢复机制组合。

10.2 过于静态

现代系统中的可信程度可能随时间、设备状态、来源、上下文和行为变化。静态完整性级别无法充分表达动态风险，需要结合风险自适应控制。

10.3 业务灵活性下降

严格禁止低完整性数据进入高完整性环境，可能阻断正常业务。实际系统必须设计可信中介、审批、清洗和状态提升机制，但中介本身又成为高价值组件。

10.4 完整性评价困难

数据的“可信”需要来源、流程、验证和历史证据支持，难以仅凭一个标签确定。若标签被错误设置或审计链断裂，模型可能产生错误的安全判断。

十一、Bell-LaPadula 与 Biba 对比

两种模型可以同时使用。例如，某交易系统要求客户敏感信息不能泄露，同时要求未经验证的外部订单不能修改账务。可以用 Bell-LaPadula 约束机密数据访问，用 Biba 约束订单、交易和配置的可信流动。

十二、案例分析：生产配置发布平台

某制造企业将设备配置集中存放在平台中，工程师可以提交配置，测试团队验证，运维团队发布到生产设备。历史上有人直接从个人电脑把配置上传到生产，导致参数错误和停机。

第一，定义完整性级别。个人电脑和外部文件属于低完整性，开发配置属于普通完整性，测试通过的配置属于较高完整性，已审批并签名的生产配置属于高完整性。

第二，设置状态和转移。配置经历提交、扫描、语法检查、仿真测试、人工审核、签名、灰度和生产发布。未经测试和签名的配置不能进入生产发布队列。

第三，限制写入。工程师只能写入开发区，测试服务只能写入测试结果，运维发布服务只能读取已批准制品并写入生产设备。低完整性账号不能直接修改生产配置或调用高权限发布接口。

第四，保护发布服务。发布服务本身采用高完整性运行环境，只有经过认证的自动化流程和授权管理员才能调用；发布前校验哈希、签名、版本、目标设备和审批单；发布后保存设备确认和回滚版本。

第五，隔离异常。扫描失败、设备回报异常或发布结果不一致时，制品进入隔离状态，禁止继续传播；系统自动告警并保留原始文件、检测结果、操作人和时间线。

第六，验证恢复。演练生产设备配置回滚、平台故障、签名服务不可用和批量发布中断，确认设备仍能使用最后一个可信配置安全运行。

十三、常见失分点

1. 将 Biba 的读写方向与 Bell-LaPadula 混淆。
2. 只记“不向下读、不向上写”，不解释完整性含义。
3. 只关注数据库，不考虑代码、镜像、配置、消息和设备状态。
4. 忽略可信中介、标签提升和审计链。
5. 把技术管理员权限等同于高完整性主体权限。
6. 未说明完整性模型与身份、业务流程、密码和恢复的结合。

十四、今日必背清单

1. Biba 模型主要保护信息和系统的完整性。
2. 完整性关注数据是否可信、准确、未被非法修改且来源可验证。
3. 简单完整性性质：高完整性主体不能读取低完整性客体，即不向下读。
4. • 完整性性质：低完整性主体不能写入高完整性客体，即不向上写。
5. 调用性质限制低完整性主体直接调用高完整性主体。
6. 低可信数据进入高可信区域需要验证、清洗、转换、审批和重新标记。
7. Biba 适合交易、配置、软件供应链、日志和生产控制场景。
8. Biba 主要保护完整性，不能替代机密性、可用性和业务授权控制。

十五、课后练习

练习一：单项选择

Biba 模型的“*”完整性性质主要要求（ ）。

A. 高完整性主体不能读取低完整性客体
B. 低完整性主体不能写入高完整性客体
C. 低密级主体不能读取高密级客体
D. 所有主体必须使用相同密码

练习二：判断题

一个低完整性服务只要拥有管理员账号，就可以直接修改高完整性生产数据。（ ）

练习三：简答题

请说明 Biba 模型与 Bell-LaPadula 模型在保护目标和读写规则上的主要区别。

练习四：案例题

某软件发布平台允许开发人员上传脚本，发布服务会自动将脚本部署到生产环境。请使用 Biba 模型分析风险，并设计一条完整性提升流程。

十六、参考答案

练习一答案

答案：B。

解析：Biba 的 * 完整性性质是 No Write Up，低完整性主体不能写入高完整性客体，以防止低可信数据污染高可信对象。

练习二答案

答案：错误。

解析：技术账号权限大不代表完整性高。低可信服务即使拥有管理员凭据，也不应直接修改高完整性对象，需要经过可信身份、制品验证、审批、签名和受控发布流程。

练习三答案

参考答案：Bell-LaPadula 主要保护机密性，限制高密级信息向低密级环境流动，常记为不向上读、不向下写；Biba 主要保护完整性，限制低可信信息污染高可信对象，常记为不向下读、不向上写。前者关注信息是否泄露，后者关注信息和处理过程是否可信、准确、未被非法修改。两者可以组合使用。

练习四答案

参考答案：开发人员上传脚本属于低或普通完整性，发布服务和生产环境属于高完整性。若自动部署没有验证和审批，恶意或错误脚本可以直接写入生产，违反 Biba 的不向上写原则，并可能通过高权限发布服务越权。

完整性提升流程应为：上传到隔离区；检查来源、账号和文件哈希；进行静态扫描、依赖漏洞扫描和恶意代码检测；在测试环境执行单元、集成和仿真测试；生成签名制品和版本；由责任人审批；发布服务只接受签名且已批准的制品；先灰度部署并观察；验证成功后扩大范围；异常时隔离、停止扩散并回滚到上一个可信版本。整个过程保留提交人、审批人、扫描结果、签名、部署目标、日志和回滚证据。

十七、今日复盘

请观察一个你熟悉的系统，找出三种“低完整性信息可能污染高完整性对象”的路径，例如外部接口写数据库、未验证镜像进入生产、普通账号修改配置或传感器数据直接触发控制。为每条路径设计验证、清洗、审批、签名和回滚措施。

下一篇进入 18.2.4「Clark-Wilson 模型」，进一步学习如何通过合法事务和职责分离保护商业系统的数据完整性。