准备 LLM 安全手册：威胁建模、红队测试和恢复

随着大型语言模型 (LLM) 深入整合到生产系统中，安全性不再只是理论问题，而是运营的必要。现代 LLM 不再是独立模型。它们作为与企业数据、外部工具、API 及甚至业务关键工作流的接口。

这也意味着它们引入了一种全新的安全风险，包括提示注入、数据泄露、模型操控和不安全工具执行。

LLM 安全手册本质上是一个结构化框架，用于回答一个基本问题：

这个系统如何被攻击，我们如何确保即使出现问题也能保持安全？

LLM 安全手册涵盖的内容

一份全面的安全手册不是一个单一的文档，而是将开发中的安全规划与部署后持续保护相结合的流程集合。

典型手册包括：

• 威胁建模（识别可能出错的地方）
• 红队测试（测试系统如何被利用）
• 缓解策略（减少或防止漏洞）
• 恢复程序（在事件后有效响应）

与其仅关注模型精度，目标是确保 在对抗条件下的稳健行为。

第一步：LLM 系统的威胁建模

威胁建模是任何 LLM 安全策略的基础。目标是在系统达到生产阶段之前识别潜在漏洞。

与传统软件不同，LLM 应用通过自然语言进行交互，攻击面显著扩大且不可预测。

常见威胁类别

• 提示注入（直接或间接）
• 通过提示、上下文或连接工具进行的数据外泄
• 恶意工具或 API 执行
• 造成现实后果的幻觉
• 绕过安全机制的越狱尝试

威胁模型概述

关键见解很简单：

在 LLM 系统中，输入不仅仅是数据，它们也是指令。

第二步：红队测试 LLM 应用

红队测试涉及故意尝试在攻击者之前破坏 LLM 系统。

这个过程特别重要，因为许多故障仅在经过精心设计的提示或复杂的多步骤交互中显现出来。

红队测试通常测试的内容

• 对越狱尝试的抵抗
• 工具滥用场景
• 隐藏指令冲突
• 多轮提示操控
• 检索增强的提示注入攻击

典型红队测试工作流程

一个有用的心态是：

如果用户可以想象一种攻击，最终会有人尝试。

第三步：缓解策略

一旦发现漏洞，下一步是构建多层防御。

没有单一的安全机制能够保护 LLM 应用。有效的安全来自重叠的保护措施。

常见的缓解技术包括：

• 提示清理和过滤
• 对外部工具实施严格许可控制
• 检索过滤和基础验证
• 输出验证层
• 隔离系统提示
• 速率限制和异常检测

指导原则是 模型绝不能成为关键行动的唯一决策者。

第四步：恢复和事件响应

即使是设计良好的 AI 系统也可能以不可预测的方式失败。

这就是为什么事件恢复应在部署前规划，而不是在事件发生后进行。

恢复程序通常关注：

• 隔离被损坏的组件
• 回滚不安全的提示或配置
• 暂时停用易受攻击的工具
• 回放日志以重建攻击路径
• 更新安全规则和过滤机制

事件响应结构

在安全事件中，速度往往比完美更重要。与 LLM 相关的故障可能会迅速升级，因为它们直接影响实时用户交互。

构建完整的 LLM 安全生命周期

成熟的组织将安全视为一个持续的过程，而不是一次性的检查清单。

典型生命周期遵循一个连续循环：

设计 → 测试 → 攻击 → 修复 → 监控 → 重复

这个持续的循环使安全实践能随着 LLM 生态系统中新攻击技术的出现而不断演进。

生命周期概述

最后总结

LLM 安全并不是消除所有可能的风险，这对通过自然语言进行交互的系统来说并不现实。

相反，目标是：

• 了解系统可能如何受到攻击。
• 不断模拟现实的攻击场景。
• 构建分层防御，以最小化成功攻击的影响。
• 在发生故障时迅速而安全地恢复。

一份设计良好的安全手册不仅仅保护语言模型, 它保护着周围的整个生态系统。