Day37-08｜18.2.4 Clark-Wilson 模型：用合法事务、职责分离和审计保护商业完整性

对应教材：第 18 章 安全架构设计理论与实践——18.2.4 Clark-Wilson 模型
学习定位：理解 Clark-Wilson 模型面向商业和事务系统的完整性思想，掌握约束数据项、非约束数据项、完整性验证过程、转换过程、职责分离和审计机制，并能在财务、订单、配置发布和审批流程案例中应用。

一、为什么 Biba 还不够

Biba 模型通过完整性级别和读写方向限制低可信主体污染高可信对象，能够表达“谁不能写什么”。但是，商业系统中的完整性问题往往不只是主体和客体等级关系，还包括：

1. 数据必须通过什么业务流程才能改变？
2. 哪些字段必须同时满足总账、库存和支付约束？
3. 谁可以发起交易，谁可以审批，谁可以执行？
4. 操作是否必须由可信程序完成，而不能直接修改数据库？
5. 如何证明每次变化都来自合法事务，并且能够追溯？

例如，财务人员可以拥有较高权限，但不能直接把某个账户余额改成任意数值；正确的方式是通过经过验证的存款、取款、转账和冲正事务改变余额，并保证事务前后满足业务约束。Clark-Wilson 模型正是针对这类商业完整性问题提出的模型。

它的核心思想是：

让数据只能通过经过认证的转换过程改变，并通过职责分离和审计保证转换过程被正确使用。

简化表达为：

用户不能直接修改关键数据 → 用户只能调用合法事务 → 事务必须验证约束 → 操作必须留痕并可审计

二、Clark-Wilson 模型的基本概念

2.1 约束数据项 CDIs

约束数据项（Constrained Data Items，CDIs）是必须保持完整性、不能被任意直接修改的数据。例如账户余额、订单状态、库存数量、生产配置、员工薪酬和审计记录。

CDI 的变化必须通过经过验证的转换过程完成，不能允许普通用户或数据库工具直接写入。即使管理员在数据库层面拥有权限，业务架构也应通过存储过程、服务接口、审批平台或可信事务处理程序控制变化。

2.2 非约束数据项 UDIs

非约束数据项（Unconstrained Data Items，UDIs）是尚未经过验证或不需要直接纳入高完整性控制的数据，例如用户输入、外部文件、传感器上报、导入数据和草稿内容。

UDI 不能直接成为 CDI。它必须经过完整性验证、格式检查、业务规则校验、身份验证和必要审批，才能通过转换过程生成或修改 CDI。

2.3 转换过程 TP

转换过程（Transformation Procedures，TPs）是改变 CDI 或将 UDI 转化为 CDI 的可信程序。典型 TP 包括创建订单、支付、退款、入库、出库、转账、审批、配置发布和数据导入。

TP 不只是一个普通函数，而是经过定义、实现、测试、授权和审计的受控过程。它必须保证输入、前置条件、业务规则、状态变化和输出符合完整性要求。

2.4 完整性验证过程 IVP

完整性验证过程（Integrity Verification Procedures，IVPs）用于检查系统中的 CDI 是否处于合法状态，或检查系统是否满足预设完整性约束。IVP 可以是定期对账、库存盘点、余额核对、配置基线比较、哈希校验和异常数据检查。

IVP 的作用不是改变数据，而是发现违反约束、非法修改、状态不一致和审计缺失。发现异常后，应进入隔离、人工复核、冲正或恢复流程。

2.5 用户与授权关系

用户可以执行哪些 TP、在什么条件下执行、是否需要审批和职责分离，都需要通过授权关系控制。用户不能直接获得对 CDI 的任意读写权限，而应获得调用特定 TP 的权限。

三、模型的核心规则

3.1 所有 CDI 必须保持有效状态

系统必须定义 CDI 的合法状态和完整性约束。例如：账户余额不能出现不允许的负数；订单支付完成后不能回到未支付；库存不能低于安全业务规则允许的范围；生产配置必须有版本、签名和审批信息。

3.2 所有 CDI 只能由合法 TP 修改

直接通过 SQL、脚本、运维工具或外部接口修改 CDI 会绕过业务约束。即使技术上可以修改，架构上也应禁止或严格限制，避免数据处于不可追溯和不可验证状态。

3.3 所有 TP 必须验证输入和约束

TP 需要检查用户权限、业务状态、数据范围、金额、时间、幂等号、关联对象和审批状态。输入通过后，TP 还要保证事务原子性、一致性和失败回滚。

3.4 用户只能执行已授权 TP

授权不是对表的直接写权限，而是对事务和流程的权限。例如，客服可以提交退款申请，但不能直接执行大额退款；财务可以审核退款，但不能审核自己提交的申请。

3.5 职责分离

关键操作应由不同角色完成，避免一个主体同时申请、批准和执行。例如，开发者不能直接批准自己的生产发布；采购人员不能既创建供应商又审批付款；操作员不能同时修改配置和审核变更。

3.6 操作必须可审计

每次 TP 执行都要记录主体、时间、来源、输入、输出、对象、结果、审批关系和异常信息。审计记录本身通常也是高完整性对象，不能由普通用户删除或修改。

四、约束数据项与转换过程的关系

可以将 Clark-Wilson 的典型处理链表示为：

外部输入 UDI → 预处理与校验 → 可信转换 TP → 约束数据项 CDI → 完整性验证 IVP → 审计与对账

例如，客户提交充值请求属于 UDI；系统验证客户身份、金额、幂等号和支付结果；充值 TP 更新账户余额和交易记录；事务提交后，IVP 检查余额变化是否等于交易变化、总账是否平衡；审计系统保存完整过程。

如果外部输入绕过 TP 直接写入 CDI，模型的核心保护就被破坏。因此架构设计要控制数据库账号、接口、批处理、管理员工具、缓存回写和数据导入等所有可能修改 CDI 的路径。

五、完整性验证过程 IVP

5.1 事前验证

在 TP 执行前验证用户、资源、金额、状态、权限和业务约束。例如检查库存是否足够、订单是否已取消、审批是否完成、配置目标是否匹配。

5.2 事中验证

在事务处理过程中保证原子性、并发控制和一致性。使用锁、版本号、乐观并发、幂等和事务日志，避免重复执行、覆盖更新和部分成功。

5.3 事后验证

事务完成后检查结果是否满足全局约束。例如总账借贷是否平衡、订单和库存是否一致、配置是否在目标设备生效、日志和审批记录是否完整。

5.4 周期性验证

定期进行对账、基线检查、哈希校验、库存盘点、权限复核和异常数据扫描。周期性 IVP 可以发现长期积累的错误和绕过控制的操作。

六、职责分离设计

6.1 静态职责分离

静态职责分离在角色层面禁止冲突组合。例如同一账号不能同时拥有申请和审批权限，同一团队不能同时开发和生产发布。

6.2 动态职责分离

动态职责分离根据具体事务和时间判断，例如同一人可以在一个项目中担任开发者，在另一个项目中担任审批者，但不能对同一变更同时承担两种角色。

6.3 四眼原则

高风险操作要求至少两名不同主体确认。例如生产配置变更、密钥轮换、数据库修复、资金支付和安全策略大范围发布。四眼原则要落实到系统流程和权限，不是只依靠口头规定。

6.4 应急账号

应急账号可以在正常流程不可用时使用，但必须设置短期有效、双人审批、操作录像、全量审计和事后复核。应急不能成为绕过职责分离的永久通道。

七、Clark-Wilson 与数据库事务

7.1 事务完整性

TP 通常对应业务事务。事务必须具备原子性、一致性、隔离性和持久性，但数据库 ACID 并不等同于 Clark-Wilson 完整性。ACID 解决数据库执行一致性，Clark-Wilson 还要求合法程序、职责分离、用户授权和审计。

7.2 存储过程与服务接口

可以通过存储过程限制数据库更新，也可以通过领域服务或应用服务实现 TP。选择哪种方式取决于系统架构、扩展、审计和团队能力。关键是让所有 CDI 变化都经过可信且可验证的路径，不能因采用微服务就默认完整性已经解决。

7.3 批处理和数据导入

批处理和导入是常见的完整性薄弱点。文件导入应经过来源认证、格式检查、重复检测、字段约束、审批、试运行和差异报告；大批量修复要有备份、限量、分批和回滚。

八、Clark-Wilson 与审计

8.1 审计记录的内容

审计记录至少应包括用户、角色、时间、来源、事务类型、目标对象、输入摘要、结果、审批人、版本和异常信息。对敏感数据不应把原文直接写入普通日志，应使用脱敏、摘要或受控关联。

8.2 审计记录的保护

日志和审计记录需要防篡改、防删除和防未授权读取。可以使用集中日志、追加写存储、数字签名、哈希链、不可变对象存储和独立安全域。审计管理员不应同时拥有删除生产审计的权限。

8.3 审计的可用性

日志系统故障时，关键事务是否允许继续执行需要根据业务和风险决定。可采用本地缓冲、可靠消息、同步关键审计、暂存后补传或高风险操作暂停等方式，确保“业务连续”和“审计完整”之间有明确策略。

九、Clark-Wilson 与 Biba 的区别

两者可以组合使用：Biba 控制不同可信级别的数据流，Clark-Wilson 控制高价值数据只能经由合法事务变化。比如外部订单先作为低完整性 UDI，经过验证后由 TP 更新 CDI，整个过程还需要遵循 Biba 的信息流规则。

十、模型的优点

10.1 更符合商业系统

商业系统的完整性通常依赖业务规则和事务，而不是单纯的密级层次。Clark-Wilson 可以表达转账、审批、库存和发布等真实流程。

10.2 强调程序化控制

它限制直接写数据，要求通过受控 TP 修改 CDI，能够降低数据库越权、脚本误操作和绕过业务流程的风险。

10.3 支持职责分离

模型将“谁能操作什么”和“谁可以与谁共同完成高风险操作”纳入安全设计，适合审计和合规要求高的组织。

10.4 便于追踪与审计

每次变化有事务、主体、审批、结果和验证记录，可以帮助定位问题、恢复数据和追究责任。

十一、模型的局限

11.1 设计和维护成本高

需要定义大量 CDI、UDI、TP、IVP、角色和职责关系，业务变化时模型和授权都要同步更新。

11.2 对开放和实时场景适配困难

传感器、事件流和实时系统可能持续产生大量数据，逐项审批和事务验证不一定可行，需要设计批量可信处理和自动化验证。

11.3 可信程序本身可能有缺陷

如果 TP 存在漏洞、逻辑错误或被替换，模型仍可能允许错误数据进入 CDI。因此 TP 需要安全开发、代码审查、签名、测试、运行时监控和版本回滚。

11.4 难以完全覆盖组织行为

职责分离需要人员和组织配合，账号共享、代审批、应急绕过和管理层特权可能破坏模型，需要治理、审计和培训共同支撑。

十二、案例分析：银行转账系统

某银行核心账务系统包含账户余额、交易流水、客户信息和对账结果。柜员可以发起转账，主管审批大额交易，核心交易服务执行扣账和入账，审计部门查看完整记录。历史上曾发生柜员直接修改余额和批处理重复执行问题。

第一，定义数据项。账户余额、交易流水、对账结果和客户核心信息是 CDI；柜员录入、外部支付回执、批量文件和客户输入是 UDI；转账、冲正、退款、入账和对账是 TP 或 IVP。

第二，限制修改路径。柜员只能提交转账申请，不能直接修改余额；主管只能审批符合权限范围的申请，不能改变交易金额；核心交易服务通过经过测试和授权的 TP 更新账户和流水；数据库管理员没有普通直接修改 CDI 的权限。

第三，实施职责分离。普通金额可以由柜员发起并自动校验，大额交易必须由不同主管审批；开发、运维和审计角色分离；应急修复需要双人审批和事后复核。

第四，保证事务一致性。使用交易唯一号保证幂等，账户扣减和入账要在事务或可靠补偿机制中保持一致；批处理文件记录批次、行号和处理状态，重复提交时不能再次扣账。

第五，建立 IVP。每日执行总账与明细对账、余额和流水校验、异常交易扫描和审计完整性检查；发现不一致时冻结相关批次、进入人工复核并保留原始数据。

第六，保护审计。记录柜员、主管、设备、时间、交易金额、审批链、执行结果和冲正关系，日志写入独立安全域并防篡改。审计人员可以查看，但不能删除生产审计。

十三、常见失分点

1. 把 Clark-Wilson 只写成“角色权限模型”。
2. 不区分 CDI、UDI、TP 和 IVP。
3. 只说数据库不能直接修改，不设计合法事务和验证过程。
4. 忽略职责分离、四眼原则和应急账号。
5. 忽略批处理、重复消息、导入和审计故障。
6. 把 ACID 事务等同于完整的 Clark-Wilson 完整性。

十四、今日必背清单

1. Clark-Wilson 面向商业系统和事务完整性。
2. CDI 是受约束数据项，不能被任意直接修改。
3. UDI 是未经验证或约束较弱的输入数据。
4. TP 是改变 CDI 或转换 UDI 的可信合法事务。
5. IVP 用于验证 CDI 和系统是否保持合法完整状态。
6. 用户只能执行已授权 TP，不能直接写 CDI。
7. 职责分离、四眼原则和审计是模型的重要组成。
8. Clark-Wilson 与 ACID、Biba 可以组合，但概念和目标不同。

十五、课后练习

练习一：单项选择

在 Clark-Wilson 模型中，负责改变约束数据项的是（ ）。

A. 任意数据库管理员
B. 转换过程 TP
C. 日志查看程序
D. 普通用户直接执行 SQL

练习二：判断题

只要数据库事务满足 ACID，就已经完全满足 Clark-Wilson 模型的完整性要求。（ ）

练习三：简答题

请说明 CDI、UDI、TP 和 IVP 四个概念之间的关系。

练习四：案例题

某企业的生产配置平台允许工程师直接修改数据库中的配置表，虽然有数据库备份，但经常出现配置错误且无法确定责任人。请使用 Clark-Wilson 模型进行改造。

十六、参考答案

练习一答案

答案：B。

解析：CDI 只能由经过授权和验证的转换过程 TP 修改，不能由普通用户或任意数据库工具直接操作。

练习二答案

答案：错误。

解析：ACID 主要保证数据库事务执行的一致性和持久性，Clark-Wilson 还要求合法事务、用户授权、职责分离、完整性验证和审计。两者关注范围不同。

练习三答案

参考答案：UDI 是外部或未经充分验证的输入，不能直接成为高完整性数据；TP 是经过认证和授权的业务事务，负责验证输入、执行合法变化并产生或修改 CDI；CDI 是必须保持完整性的核心数据；IVP 用于事前、事后或周期性检查 CDI 是否满足约束。整体流程是 UDI 经过校验和 TP 转换为 CDI，IVP 再验证结果，所有过程由授权和审计支持。

练习四答案

参考答案：将配置表定义为 CDI，工程师提交的配置文件属于 UDI，配置校验、仿真、审批、签名和发布定义为 TP，基线比较、设备回报校验和配置对账定义为 IVP。工程师只能提交和查看自己权限范围内的配置，不能直接写数据库；发布服务只接受经过扫描、测试、签名和审批的配置；生产发布采用分批和灰度，异常时回滚到可信版本。

还要实施职责分离：工程师提交，测试人员验证，运维或授权发布人执行，关键变更采用双人审批；数据库账号按最小权限分离，直接修改生产 CDI 的权限被撤销；记录提交、审批、测试、签名、发布、设备确认和回滚日志；定期执行配置基线和设备状态对账，发现异常立即隔离和复核。

十七、今日复盘

请选择一个业务事务，分别指出它的 UDI、CDI、TP、IVP 和参与角色。例如订单导入中，外部订单文件是 UDI，订单和库存是 CDI，订单校验与入库是 TP，订单与库存对账是 IVP。只要能完成这五项映射，就掌握了 Clark-Wilson 的核心。

下一篇进入 18.2.5「Chinese Wall 模型」，学习面向利益冲突和动态访问隔离的安全模型。