Day37-09|18.2.5 Chinese Wall 模型:用动态访问规则防止利益冲突
Day37-09|18.2.5 Chinese Wall 模型:用动态访问规则防止利益冲突
对应教材:第 18 章 安全架构设计理论与实践——18.2.5 Chinese Wall 模型
学习定位:理解 Chinese Wall 模型的设计背景、公司数据集、利益冲突类、动态访问规则和历史访问约束,掌握它与强制分级模型的区别,并能够在金融、咨询、审计和多租户服务场景中完成利益冲突隔离设计。
一、为什么需要 Chinese Wall 模型
有些安全问题不是“谁的密级更高”或“数据是否完整”,而是同一个主体不能同时为存在竞争关系的多个客户或组织提供服务。例如,咨询公司的顾问可以服务客户甲,也可以服务客户乙,但如果甲乙是直接竞争对手,顾问在接触甲的商业机密后,就不应再访问乙的同类敏感资料;证券分析师访问某家公司的内幕或未公开信息后,不能继续为其竞争对手提供可能产生利益冲突的研究服务。
这种场景的关键约束是:主体最初访问哪个数据集,会影响其后续能够访问哪些数据集。访问控制不是静态角色表,而是随着历史访问行为动态变化,因此传统的固定权限模型不足以表达。
Chinese Wall 模型的基本思想是:
主体可以访问不同公司或组织的数据,但一旦访问了某个冲突类中的一个公司的敏感数据,就不能再访问同一冲突类中其他竞争公司的数据。
它保护的不是单纯的机密性,而是机密性、利益冲突、职业操守和信息隔离的结合。
二、模型中的基本概念
2.1 主体
主体可以是员工、顾问、审计师、律师、分析师、服务账号或自动化程序。主体的访问历史会影响后续授权决策,因此系统必须能够识别主体的唯一身份,并记录其访问过的数据集。
2.2 公司数据集
公司数据集是某个公司或组织相关的一组数据,例如客户资料、交易信息、研发方案、审计底稿、合同和商业计划。一个公司数据集内部可以包含多个文件、数据库、接口和应用,但在利益冲突策略上作为一个整体处理。
2.3 冲突类
冲突类是一组相互竞争或存在利益冲突的公司数据集集合。例如,汽车制造商甲、乙、丙可以属于同一个汽车行业冲突类;银行 A、B、C 可以属于同一个金融客户冲突类;不同政党或竞争供应商也可以建立冲突类。
一个组织可能存在多个冲突类。某主体访问甲公司的汽车数据后,不能访问同一汽车冲突类中的乙公司数据,但仍可能访问金融冲突类中的某家银行数据,前提是没有其他策略禁止。
2.4 访问历史
访问历史记录主体过去访问过哪些公司数据集、何时访问、通过什么方式访问以及是否下载或修改。模型通常关心的是“主体已经访问过的冲突类成员”,因此访问历史必须可靠、不可被主体自行清除或篡改。
三、Chinese Wall 的访问规则
3.1 初始访问
主体对某个冲突类中的任何公司进行第一次访问时,只要满足普通身份、角色和业务授权,就可以选择一个公司数据集。选择之后,该冲突类的访问范围会被锁定。
例如,顾问第一次访问汽车公司甲的数据,系统记录其已选择汽车冲突类中的甲。之后,顾问不能再访问汽车公司乙或丙的数据,但仍可访问已经授权的甲数据。
3.2 后续访问
后续访问必须满足:目标公司与主体已经访问过的公司属于不同冲突类,或者目标公司就是主体已经选择的同一公司数据集。换言之,同一冲突类中可以持续访问同一公司,但不能跨公司访问。
3.3 访问许可的变化
访问权限会随着历史访问动态收紧,而不是静态增加。主体最初可选的范围最大,作出选择后,冲突类中的可选集合减少。这种权限变化应向用户明确展示,避免用户以为原本可以访问的对象始终可访问。
3.4 管理员与例外
管理员不能简单绕过 Chinese Wall 规则,否则管理员自身会成为信息冲突通道。确需例外时,应采用独立审批、临时授权、数据脱敏、双人操作和完整审计,并明确例外是否会改变主体后续访问历史。
四、访问决策算法
可以用以下逻辑描述 Chinese Wall 的访问判断:
- 识别主体和目标公司数据集。
- 查找目标数据集所属冲突类。
- 查询主体在该冲突类中的历史访问记录。
- 若主体尚未访问该冲突类,且普通业务授权通过,则允许首次选择。
- 若主体已访问过同一公司数据集,则允许继续访问,但仍需满足普通权限。
- 若主体已访问过同一冲突类中的其他公司,则拒绝或转入审批、脱敏或隔离流程。
- 记录访问决策、主体、公司、冲突类、历史状态和结果。
伪代码可表达为:
允许访问 = 普通授权通过 且(目标冲突类未选择 或 目标公司已选择)
这只是模型的核心逻辑,生产系统还要增加时间、地点、设备、操作类型、数据敏感度、项目状态、客户合同和应急权限等条件。
五、动态权限与历史状态管理
5.1 访问历史的可靠性
如果主体能够删除或修改访问历史,就可以先访问甲,再清除记录后访问乙,模型将失效。因此访问历史应由独立策略服务或审计平台维护,主体只能查询与自己相关的状态,不能直接修改。
5.2 缓存与会话
主体在一次会话中选择某个公司后,权限状态可以缓存以减少查询,但缓存必须有版本、有效期和撤销机制。若发生客户冲突变更、项目结束或安全事件,系统要能够立即撤销缓存授权。
5.3 多设备和多渠道
主体可能通过 Web、移动端、API、批处理和数据导出访问同一数据。访问历史必须以统一主体身份关联,不应因为换设备或换接口就重新获得可选范围。
5.4 团队与代理访问
团队共享账号会破坏个体访问历史和责任追踪。应使用个人身份和服务代理映射,记录实际操作者。自动化程序访问多个客户数据时,也要按照服务任务、租户和冲突类设置隔离,不能因为是机器账号就绕过规则。
六、与其他访问控制模型的区别
6.1 与 Bell-LaPadula 的区别
Bell-LaPadula 根据主体和客体的安全级别与范畴控制机密性,规则相对静态;Chinese Wall 根据主体的访问历史动态调整权限,核心是避免冲突类中的交叉访问。前者回答“密级是否允许”,后者回答“主体已经服务了谁,是否还能服务竞争对象”。
6.2 与 Biba 的区别
Biba 保护完整性,防止低可信信息污染高可信对象;Chinese Wall 保护利益冲突和信息隔离。主体可能拥有足够完整性和密级,但仍因利益冲突不能访问某个客户数据集。
6.3 与 RBAC 的关系
RBAC 根据角色授权,适合表达岗位、职责和固定权限;Chinese Wall 需要在角色基础上增加访问历史和冲突类策略。实际系统通常组合使用:先通过 RBAC 判断主体是否属于客户项目,再通过 Chinese Wall 判断其是否已经选择了竞争客户。
6.4 与 ABAC 的关系
ABAC 可以根据主体、资源、环境和历史属性做动态决策,适合实现 Chinese Wall。冲突类、已访问公司、项目状态和数据敏感度可以作为属性输入,但策略引擎必须能够可靠维护历史状态。
七、适用场景
7.1 金融机构
投行、证券、基金和研究机构可能同时服务竞争公司。分析师、投行团队和交易人员需要防止内幕信息和客户机密在竞争客户之间流动。
7.2 咨询、审计与法律服务
顾问、审计师和律师通常为多个客户工作,客户之间可能存在竞争、诉讼或交易关系。系统需要按项目、客户、冲突类和人员访问历史进行隔离。
7.3 外包和供应链
同一家服务商可能维护多个竞争企业的系统。远程运维、工单、日志、配置和备件资料都应限制跨客户访问。
7.4 多租户平台
云平台、数据分析平台、广告平台和 SaaS 系统需要防止租户数据交叉。虽然多租户隔离通常使用租户 ID、RBAC、网络和数据库隔离,但对于同一运营人员或算法服务同时处理竞争客户,还可以引入 Chinese Wall 思想。
八、模型实现的架构组成
8.1 冲突类目录
维护客户、公司、项目与冲突类的关系,支持版本、审批和生效时间。冲突类变化可能影响当前会话和历史授权,需要有发布与回滚机制。
8.2 策略决策点
策略决策点接收主体、目标资源、操作、冲突类、历史访问和环境信息,返回允许、拒绝、脱敏、审批或只读等决策。
8.3 策略执行点
执行点可以位于 API 网关、数据库代理、文档平台、跳板机、微服务网格和数据导出服务。必须覆盖下载、打印、复制、批处理和 API 等旁路路径。
8.4 历史状态存储
历史状态存储需要高可用、不可篡改和可查询,记录主体访问过的公司、冲突类、时间、项目、设备和操作范围。它既是授权决策依据,也是审计证据。
8.5 审计与解释
被拒绝的访问要能够解释原因,例如“你已访问冲突类 C 中的公司甲,当前请求公司乙与其冲突”。解释有助于减少业务误解和支持审计。日志不能只记录“拒绝”,还应记录策略版本和历史状态摘要。
九、数据导出与脱敏例外
现实中,主体可能需要跨冲突类提供汇总分析。可以设计受控例外:
- 只允许经过脱敏、聚合和最小化的数据。
- 禁止导出原始客户标识、交易明细和商业机密。
- 由独立团队或系统执行脱敏,原始主体不能直接决定结果。
- 例外必须经过审批、设置有效期和用途限制。
- 导出结果重新标记所属数据域,并保留来源和处理链。
- 监控批量查询、重识别风险和异常组合。
脱敏并不等于绝对匿名。多个统计结果组合后可能重新识别客户,因此要结合数据最小化、查询频率、结果粒度和隐私风险控制。
十、案例分析:咨询公司客户数据平台
某咨询公司同时为汽车企业甲、汽车企业乙和银行丙提供服务。顾问团队需要访问项目文档、数据分析平台和工单系统;同一个顾问可能在不同时间加入不同项目。企业要求顾问不能同时访问同一行业竞争客户的原始资料,但可以访问经过批准的通用方法论和脱敏行业统计。
第一,建立冲突类。将汽车甲和汽车乙放入汽车行业冲突类,将银行丙放入金融冲突类;根据客户合同和项目关系维护冲突类目录,设置生效、变更和解除流程。
第二,统一主体身份。顾问、项目经理、数据工程师和服务账号使用个人或可追责身份,禁止项目共享账号;同一顾问的 Web、API、移动和批处理访问关联到同一主体。
第三,实施动态访问。顾问第一次访问汽车甲项目后,系统记录其已选择汽车冲突类中的甲;后续可以继续访问甲,但拒绝汽车乙的原始数据。银行丙属于不同冲突类,在业务角色和项目权限允许时可以访问。
第四,隔离执行点。文档平台、数据分析平台、工单系统、下载服务和 API 网关都调用统一策略服务,不能只在门户页面判断。导出、打印、复制和离线缓存需要继承冲突策略。
第五,提供受控共享。通用方法论放在独立知识库,行业统计由数据团队脱敏和聚合,顾问只访问经过审批的结果,不能从原始数据自行拼接跨客户报表。
第六,处理人员变更和项目结束。顾问离开项目时撤销项目权限,但历史访问记录仍然保留;客户冲突关系变化时重新评估已有会话、缓存和导出任务;安全事件发生时立即冻结相关主体和数据导出。
十一、模型的优点
- 能够表达静态角色模型难以描述的利益冲突。
- 访问规则随主体历史动态变化,适合多客户服务组织。
- 可以与 RBAC、ABAC、租户隔离和审计组合使用。
- 直接对应合规、职业操守和客户保密要求。
- 通过冲突类归纳规则,避免为每一对竞争公司写大量规则。
十二、模型的局限
- 必须可靠维护访问历史,状态管理复杂。
- 首次访问选择可能造成后续业务受限,需要清晰提示和流程支持。
- 团队协作、代理账号和自动化任务会增加主体归属难度。
- 冲突类关系变化、客户合并和项目结束需要动态更新。
- 只限制访问不一定能阻止拍照、手工抄录或外部通信,需要终端和行为控制。
- 过度严格会影响跨客户知识复用,脱敏和审批流程必须合理设计。
十三、今日必背清单
- Chinese Wall 模型主要防止利益冲突和竞争客户之间的信息交叉。
- 核心概念包括主体、公司数据集、冲突类和访问历史。
- 主体首次访问冲突类中的某公司后,通常不能访问同冲突类其他公司。
- 同一冲突类中可以继续访问已选择的公司,但不能跨公司访问竞争数据。
- 访问历史必须统一、可靠、不可由主体删除或篡改。
- 模型通常与 RBAC、ABAC、租户隔离、脱敏和审计组合使用。
- 数据导出、打印、复制、API 和批处理等旁路路径必须纳入策略。
- 冲突类变化、项目结束和人员变更需要重新评估会话和权限。
十四、课后练习
练习一:单项选择
Chinese Wall 模型主要解决的问题是( )。
A. 保护数据不被低完整性主体修改
B. 防止不同密级信息向下泄露
C. 防止主体同时访问存在利益冲突的多个客户数据集
D. 提高网络链路吞吐量
练习二:判断题
主体访问了冲突类中的公司甲后,仍然可以访问同一冲突类中公司乙的原始数据,只要主体角色权限足够。( )
练习三:简答题
请说明 Chinese Wall 模型为什么属于动态访问控制,并指出实现它需要维护哪些关键状态。
练习四:案例题
某审计公司同时服务存在竞争关系的企业甲和企业乙。审计人员使用统一账号访问项目资料,平台只有按角色授权,没有访问历史控制。请提出改进方案。
十五、参考答案
练习一答案
答案:C。
解析:Chinese Wall 模型关注利益冲突和主体访问历史,防止主体在同一冲突类中访问多个竞争客户的数据。
练习二答案
答案:错误。
解析:模型会根据主体在冲突类中的历史访问记录动态收紧权限。访问甲后,通常不能再访问同一冲突类的乙原始数据,除非经过明确的例外、脱敏和审批机制。
练习三答案
参考答案:它是动态模型,因为主体第一次选择某个公司数据集后,其后续可访问范围会发生变化,授权决策依赖历史而不是只依赖静态角色。需要维护主体身份、目标公司、公司所属冲突类、主体已经访问的公司和冲突类、访问时间、项目、操作范围、会话缓存、例外授权、数据导出和策略版本等状态。
练习四答案
参考答案:首先取消共享账号,为每名审计人员建立可追责身份,统一关联 Web、API、下载和移动访问;建立企业客户、数据集和冲突类目录,将甲乙放入同一冲突类;顾问首次访问甲后,策略服务记录选择状态,后续拒绝乙的原始数据访问。
权限判断采用 RBAC 或 ABAC 先确认人员是否属于项目,再由 Chinese Wall 策略检查冲突历史;策略执行覆盖文档平台、数据库代理、API、下载、打印和批处理;访问历史由独立安全服务维护,不允许用户修改,日志记录策略版本和拒绝原因;确需跨客户共享时,只能访问经过脱敏和审批的通用统计,并设置有效期、导出限制和审计。人员离开项目、客户关系变化或发现异常时,立即撤销会话和临时授权。
十六、今日复盘
请设想自己是一名同时服务两家竞争企业的顾问:第一次访问哪一家会影响什么?系统如何告诉你后续限制?如果老板要求提供跨客户汇总数据,如何通过脱敏、审批和独立处理实现?能回答这三个问题,就掌握了 Chinese Wall 模型的核心。
下一篇进入 18.3.1「安全技术体系架构」,从访问控制模型转向企业安全技术体系的整体规划。