3. 数据共享与交换的威胁建模
数据共享与交换系统把原本分散在多个主体、多个信任域中的数据汇聚到一条可被调用的通道上,威胁面因此从"单点存储"扩展为"跨域流动"。威胁建模的任务,就是在设计阶段把这条通道上可能被利用的结构性弱点显式地列出来,并给出可验证的缓解措施。本章围绕 STRIDE、攻击树、数据泄露路径、内部威胁、供应链风险五条主线展开,并给出一个可复用的建模流程与典型攻击案例。
一、STRIDE:把威胁按"违反的安全属性"分类
STRIDE 是微软提出的一套威胁分类法,它的价值在于把模糊的"不安全"拆成六类可判定的属性违反:Spoofing(身份伪造,违反真实性)、Tampering(数据篡改,违反完整性)、Repudiation(抵赖,违反不可否认性)、Information Disclosure(信息泄露,违反机密性)、Denial of Service(拒绝服务,违反可用性)、Elevation of Privilege(权限提升,违反授权)。
在数据交换场景中,STRIDE 需要落到具体对象上。以"数据提供方 A 通过 API 网关向数据使用方 B 提供脱敏后的用户画像数据"为例:伪造对应 B 侧伪造调用凭证或伪造数据源身份;篡改对应中间人修改响应体中的字段值;抵赖对应 A 事后否认曾提供某版本数据;信息泄露对应脱敏规则失效导致原始手机号外泄;拒绝服务对应网关限流被绕过导致后端库被打满;权限提升对应 B 用低权限令牌访问了未授权的数据表。建模时应对每个数据流、每个信任边界逐一提问,而不是对系统整体泛泛提问。
二、攻击树:从攻击者目标反推可行路径
攻击树以攻击者最终目标为根节点,向下分解为子目标,叶节点是可执行的具体动作,节点之间用 AND(全部满足才成功)和 OR(任一满足即成功)连接。它的优势是能定量估算:给每个叶节点赋一个"可行性/成本"分值,AND 节点取乘积、OR 节点取最大值,即可得到根目标的综合难度,从而判断哪条路径最需要优先封堵。
例如根目标为"获取 A 方未脱敏的用户画像全量数据",可分解为三条 OR 分支:直接攻破 A 的数据库、窃取 A 的导出凭证、绕过脱敏服务。其中"绕过脱敏服务"又可分解为 AND 分支:发现脱敏规则未覆盖的字段 + 构造能触发该字段返回的查询。这种分解能直接暴露"脱敏规则覆盖度"这一常被忽视的薄弱点。
三、数据泄露路径与内部威胁
数据泄露路径描述数据从受控域流向非受控域的通道。在共享交换系统中,常见路径包括:API 响应体、批量导出文件、日志与审计记录、缓存与消息队列、备份介质、以及第三方分析环境。每条路径都应标注"是否经过脱敏""是否可被外部触发""留存周期"三个属性。
内部威胁的特殊性在于攻击者已持有合法凭证,STRIDE 中的伪造与权限提升往往不适用,取而代之的是"合法权限的滥用"。典型表现是:运维人员用生产库账号直接查询敏感表、数据使用方把授权数据二次转发给未授权方、开发人员把生产数据复制到测试环境。缓解手段不能只靠加密,而要靠最小权限、字段级访问控制、导出水印与行为基线告警的组合。
四、供应链风险
数据交换链路通常包含多个第三方组件:数据源系统、ETL 工具、消息中间件、API 网关、SDK、以及外部数据提供方。供应链风险的核心是"信任传递"——你信任自己的代码,但你是否信任引入的每一个依赖和每一个上游数据提供方?典型风险包括:SDK 被植入后门、上游提供方数据本身被污染(数据投毒)、中间件版本存在已知漏洞、以及上游方合规资质失效导致数据来源不合法。
五、典型攻击案例与建模流程
一个具有代表性的案例是某数据交换平台因 API 未做对象级授权校验,导致使用方通过修改请求中的资源 ID 越权访问其他机构的数据(即 IDOR 类漏洞)。用 STRIDE 归类属于权限提升,用攻击树表示是一条 OR 分支,用泄露路径表示是"API 响应体"这条通道,用内部威胁视角看则是"合法凭证 + 越权参数"的组合。这说明五条主线并非彼此独立,而是从不同角度描述同一组风险。
可复用的建模流程为:先画数据流图并标出信任边界,再对每个跨边界数据流套用 STRIDE 提问,对高风险项展开攻击树,最后把叶节点映射到具体缓解措施并指定验证方式。下表给出一个建模记录示例(参数为教学假设值)。
| 数据流 | STRIDE 类别 | 攻击树叶节点 | 缓解措施 | 验证方式 |
|---|---|---|---|---|
| B→网关 查询请求 | 权限提升 | 篡改资源 ID 越权 | 对象级授权校验 | 用他人 ID 请求应返回 403 |
| 网关→A 数据服务 | 信息泄露 | 脱敏规则未覆盖字段 | 字段白名单 + 规则回归测试 | 全字段扫描无原始值 |
| A→B 批量导出 | 抵赖 | 否认导出行为 | 导出日志 + 数字签名 | 日志可追溯到具体账号 |
| 第三方 SDK | 篡改 | 依赖包被替换 | 依赖锁定 + 哈希校验 | 构建时校验哈希一致 |
把上述内容落到工程实践,建议在需求评审阶段就产出一份威胁建模记录,字段至少包含:数据流标识、信任边界、STRIDE 类别、攻击树叶节点、缓解措施、验证方式、责任人。这份记录应随版本迭代更新,并在每次数据共享范围变更时重新评审。威胁建模的产出不是一份文档,而是一组可被测试用例覆盖的约束条件——只有当每条缓解措施都能对应到一条可执行的验证用例时,建模才真正闭环。