威胁建模：识别AI部署管道中的威胁源

核心原理：AI部署管道为何成为攻击面

传统软件安全关注的是代码漏洞、配置错误与网络暴露，而AI部署管道引入了一类全新的攻击面：模型本身及其生命周期中的每一个环节。模型不是静态的二进制文件，它由数据训练而来，以权重文件形式存储，在推理时通过输入输出对外暴露行为。攻击者不需要直接攻破服务器，只要污染数据、窃取权重、或构造恶意输入，就能达到破坏、盗取或操控模型的目的。

威胁建模的核心任务是：在攻击者视角下，系统性地枚举“谁、通过什么路径、能对什么资产造成什么影响”。对于AI部署管道，我们需要将管道拆解为可分析的分层结构，识别每一层中可被利用的入口点、信任边界与资产价值。

关键认知：AI部署管道的威胁源与传统IT系统有本质差异——攻击者攻击的不是“代码逻辑”，而是“数据分布”和“模型行为”。即使代码零漏洞，模型仍可能被投毒、窃取或欺骗。

威胁源分类与攻击路径分析

根据上述管道分层，我们可以将威胁源归纳为四大类，每一类都有其独特的攻击目标、前置条件与影响范围。

威胁类别	攻击目标	典型攻击路径	影响后果
数据投毒	训练数据集、标注系统	污染数据源 → 影响模型学习 → 植入后门或降低准确率	模型行为异常、特定输入触发错误输出
模型窃取	模型权重、推理API	大量查询API → 训练替代模型 → 提取决策边界	知识产权损失、商业价值被复制
对抗攻击	推理阶段输入	构造微小扰动 → 输入模型 → 诱导错误分类	安全系统失效、错误决策
供应链攻击	预训练模型、依赖库	篡改开源权重 → 开发者下载使用 → 后门生效	从源头植入恶意行为

方法流程：从资产识别到风险评定的四步法

威胁建模不是一次性的头脑风暴，而是一个可重复的结构化流程。推荐采用以下四步法，每一步都产出可追踪的文档记录。

资产盘点（Asset Inventory）：列出管道中所有有价值且可能被攻击者觊觎的资产。包括：原始数据集、标注数据、模型权重文件、训练超参数、推理API、模型版本管理库、监控日志等。对每项资产标注其机密性、完整性和可用性等级。
信任边界划分（Trust Boundary Mapping）：在管道图中标出数据从外部进入内部系统的每一个“跨越点”。例如：数据从公网爬虫进入存储桶、用户上传文件进入预处理服务、外部请求进入推理API。每个信任边界都是潜在的威胁入口。
威胁枚举（Threat Enumeration）：针对每个信任边界，使用STRIDE模型（Spoofing欺骗、Tampering篡改、Repudiation抵赖、Information Disclosure信息泄露、Denial of Service拒绝服务、Elevation of Privilege权限提升）逐一提问：“这里是否可能发生X攻击？”记录所有“是”的场景。
风险评定与优先级排序（Risk Assessment）：对每个已识别的威胁，评估其发生可能性（攻击成本、所需先验知识、现有防护强度）和潜在影响（业务损失、安全危害、合规风险）。使用简单的“高/中/低”三档矩阵，优先处理“高可能性+高影响”的威胁。

实战提示：在威胁枚举阶段，不要只关注“攻击者如何进来”，还要关注“内部人员或自动化流程可能如何误操作”。例如：数据工程师误将包含个人身份信息的数据集上传到公开仓库，这属于“信息泄露”威胁，且发生概率不低。

典型案例：一次完整的模型窃取攻击复盘

某金融科技公司部署了一个用于信用卡欺诈检测的深度学习模型，通过REST API对外提供实时评分服务。攻击者没有尝试攻破服务器，而是采取了以下步骤：

# 攻击者视角：利用API进行模型窃取
1. 收集目标API的输入输出格式（通过公开文档或少量试探）
2. 构造合成查询集：使用随机特征向量 + 边界采样策略
3. 批量发送查询请求（约10万次），记录每次的评分结果
4. 使用这些(输入, 输出)对训练一个本地替代模型（如梯度提升树）
5. 验证替代模型与目标模型的输出一致性（误差 < 0.01）
6. 将替代模型用于后续对抗样本生成或直接转售

这次攻击之所以成功，是因为该公司没有对API实施任何查询频率限制、输出精度截断或异常模式检测。攻击者仅花费了约200元人民币的API调用费用，就复制了一个商业价值数十万元的模型。

常见误区与复盘

误区一：认为“模型部署在内网就安全”
内网不等于可信。2023年某大型企业的内部AI平台被内部员工通过调试接口导出模型权重，原因是调试模式未在生产环境关闭。内网攻击者的成本远低于外部攻击者，且更容易接触敏感资产。

误区二：只关注对抗攻击，忽略数据投毒
对抗攻击需要攻击者实时构造输入，而数据投毒是一次性、长期生效的攻击。一个被投毒的训练数据集可能在模型上线后数月内持续产生错误输出，且难以追溯根因。威胁建模时，数据投毒的优先级应高于对抗攻击。

误区三：威胁建模文档“写完即弃”
威胁建模不是交付物，而是持续过程。模型每更新一版、管道每增加一个组件、第三方依赖每升级一次，都需要重新审视威胁模型。建议将威胁建模纳入CI/CD流程，在模型发布前自动触发威胁评估检查。

威胁建模输出模板

以下是一个可复用的威胁建模记录表，建议在每次评估时逐项填写：

威胁ID: TH-2024-001
资产: 生产环境推理API (model:v3.2)
信任边界: 公网 → API网关
威胁类型: 模型窃取 (Information Disclosure)
攻击路径: 批量查询 → 替代模型训练
可能性: 高 (无频率限制, 输出精度完整)
影响: 高 (模型知识产权损失)
现有防护: 无
建议措施: 1. 添加API调用频率限制 (每IP 100次/分钟)
          2. 输出结果四舍五入至小数点后2位
          3. 部署异常查询模式检测 (如信息熵突变)
状态: 待修复
负责人: [填写]
截止日期: [填写]

威胁建模的核心价值不在于生成一份完美的报告，而在于让团队形成一种“攻击者思维”——在攻击发生之前，就已经知道最脆弱的环节在哪里，并提前布防。将上述四步法嵌入到AI部署管道的每一次迭代中，才能让安全防护跟上模型更新的速度。