加强 LLM 应用安全性的最佳实践

这篇文章最初发表在 NVIDIA 技术博客上。

大型语言模型 (LLM) 为几乎所有处理文本的应用程序提供了各种强大的增强功能。同时，它们也引入了新的风险，包括：

**提示注入：**这可能允许攻击者控制 LLM 或启用了 LLM 的应用程序的输出。
**信息泄露：**当用于训练 LLM 或在运行时使用的私有数据可以被攻击者推理或提取时，信息泄露便会发生。
**LLM 可靠性：**其中一种威胁是，当 LLM 偶尔会产生错误信息时。

本文将详细介绍这些安全漏洞，并概述设计或评估支持 LLM 的安全应用程序的最佳实践。

提示注入

提示注入是最常见和众所周知的 LLM 攻击。它使攻击者能够控制 LLM 的输出，从而可能影响连接到 LLM 的下游查询和插件的行为。这可能会给未来用户带来额外的下游后果或响应。提示注入攻击可以是直接的，也可以是间接的。

直接提示注入

在直接提示注入攻击的情况下，攻击者会直接与 LLM 交互，试图让 LLM 产生特定的响应。图 1 显示了直接提示注入导致远程代码执行的示例。有关直接提示注入的更多详细信息，请参阅保护 LLM 系统免受提示注入。

图 1.直接提示注入攻击示例，在此示例中，由 LLM 驱动的应用程序用于执行攻击者代码

间接提示注入

间接提示注入依赖于 LLM 对其在构建系统查询时使用的外部数据源的访问权限。攻击者可以向这些外部数据源插入恶意内容，LLM 会从中提取数据并将其插入到提示中，从而生成攻击者所期望的响应。有关间接提示注入的更多信息，请参阅缓解针对 LLM 应用程序的存储提示注入攻击。

信任边界

通过直接和间接提示注入，一旦攻击者能够成功将其输入引入 LLM 上下文，它们就会对 LLM 的输出产生重大影响(如果不是直接控制)。由于 LLM 可能使用的外部来源可能很难控制，而且 LLM 用户本身可能是恶意的，因此必须将任何 LLM 响应视为潜在的不可信任。

必须在这些响应与处理这些响应的任何响应之间建立信任边界。下文列出了实现这种分离的一些实际步骤。

**对插件进行参数化：**严格限制给定插件可以执行的操作数量。例如，用于操作用户电子邮件的插件可能需要消息 ID 和特定操作（例如"回复"或"转发"），或者仅接受插入到电子邮件正文中的自由格式文本。

**在使用插件前清理输入。**例如，可能会在插入之前强制从电子邮件正文文本中删除任何 HTML 元素。或者，在执行电子邮件转发操作时，可能会要求收件人必须存在于用户的通讯录中。

请求用户明确的授权 **当插件在敏感系统上运行时，**任何此类操作都应导致系统立即重新请求用户明确授权以执行操作，并提供即将执行操作的摘要。

在依次调用多个插件时，需要获得用户的特定授权。这种模式（允许将一个插件的输出作为另一个插件的输入）可能迅速导致意外甚至危险的行为。允许用户检查和验证正在调用的插件以及它们将采取的行动，有助于缓解此问题。

**仔细管理插件授权：**将任何服务账户与 LLM 服务账户分开。如果插件的操作需要用户授权，则应使用 OAuth2 等安全方法将该授权委托给插件。

信息泄露

来自支持 LLM 和 LLM 的应用的信息泄露会产生机密性风险。如果 LLM 是根据隐私数据进行训练或自定义的，熟练的攻击者可以执行模型反演或训练数据提取攻击，以访问应用开发者认为隐私的数据。

记录提示和完成操作可能会意外地跨权限边界泄露数据，因为这违反了基于服务端角色的静态数据访问控制。如果为 LLM 本身提供了信息访问权限或存储日志，则通常会诱导其泄露这些数据。

来自 LLM 本身的泄露

LLM 本身可以通过多种方式向攻击者泄露信息。借助提示提取攻击，攻击者可以使用提示注入技术诱使 LLM 泄露其提示模板中包含的信息，例如模型说明、模型角色信息，甚至是密码等机密信息。

通过模型反演攻击，攻击者可以恢复一些用于训练模型的数据。具体来说，这些记录可能是随机恢复的，或者攻击者可能会有意将搜索结果偏向他们怀疑可能存在的特定记录。例如，他们可能能够提取用于训练 LLM 的个人身份信息 (PII) 示例。想要了解更多详情，请参阅有记忆的算法：模型反演攻击和数据保护法。

最后，训练数据成员资格推理攻击使攻击者能够确定他们已经知道的特定信息是否可能包含在模型的训练数据中。例如，他们可能能够确定他们的 PII 是否用于训练 LLM.

幸运的是，这些攻击的缓解相对简单。

为避免提示提取攻击的风险，请勿共享当前 LLM 用户无权在系统提示模板中看到的任何信息。这可能包括从检索增强一代 (RAG) 架构中检索的信息。假设提示模板中包含的任何内容对有足够动机的攻击者可见。特别是，密码、访问令牌或 API 密钥永远不应放在提示中，或可直接由 LLM 访问的任何其他位置。严格隔离信息是最好的防御方法。

为了降低从模型中提取敏感训练数据的风险，最好的方法是不在其上进行训练。给定足够的查询，LLM 不可避免地会最终将敏感数据的某些元素纳入其响应中。如果模型必须能够使用或回答有关敏感信息的问题，RAG 架构可能是一种更安全的方法。

在这种架构中，LLM 不在敏感文档上进行训练，而是获得了对文档存储的访问权限，该存储能够 1) 识别相关敏感文档并将其返回至 LLM 以协助生成，以及 2) 验证当前用户访问这些文档的授权。

虽然这避免了针对敏感数据训练 LLM 以产生可接受的结果，但它确实在传递授权和跟踪文档权限方面给应用程序带来了额外的复杂性。必须小心处理这一点，以防止其他机密性违规事件。

如果敏感数据已经训练到模型中，则仍然可以通过速率限制查询在一定程度上降低风险，而不是向用户提供有关 LLM 完成概率的详细信息，以及在应用程序中添加日志记录和警报。

如果将查询预算限制在与启用 LLM 的应用程序的功能一致的最低限度，并且不向最终用户提供任何详细的概率信息，则执行反演和推理攻击会变得极其困难和耗时。

与 AI 红队评估数据泄露可能有助于量化风险、为特定应用程序设置适当的速率限制，以及识别用户会话中可能表示尝试提取应提醒的训练数据的查询或查询模式。

应用程序相关的泄漏

除了特定于 LLM 的攻击之外，LLM 的新颖性还可能在构建支持 LLM 的应用程序时导致更基本的错误。记录提示和响应通常会导致服务端信息泄露。或者是未接受适当教育的用户将专有或敏感信息引入应用程序，或者 LLM 根据敏感信息提供响应，而这些信息在没有适当访问控制的情况下记录。

在图 2 中，用户向 RAG 系统发出请求，该系统请求授权用户单独查看文档，以便完成请求。遗憾的是，请求和响应(包含与特权文档相关的信息)登录在具有不同访问级别的系统中，从而泄露信息。

图 2.通过日志记录泄露数据的示例

如果使用 RAG 来改进 LLM 响应，则必须跟踪用户对检索文档的授权，以及回复的记录位置。LLM 应只能访问当前用户有权访问的文档。填写的内容(根据设计，这些填写内容包含这些受访问控制文档中包含的部分信息)应以这样的方式进行记录，以便未经授权的用户无法看到敏感文档的摘要。

因此，在 LLM 上下文之外执行身份验证和授权机制极为重要。如果依赖传输用户上下文作为提示的一部分，技能足够熟练的攻击者可以使用提示注入来模拟其他用户。

最后，应仔细检查任何插件的行为，以确保它们不会保持任何可能导致跨用户信息泄露的状态。例如，如果搜索插件恰好用于缓存查询，则其返回信息的速度可能会允许攻击者推断应用程序查询的其他用户最常见的主题。

LLM 可靠性

尽管 LLM 代的可靠性和准确性有了显著提高，但它们仍然会受到一定程度的随机误差的影响。如何从一组可能的后续词中随机采样词增加了 LLM 的"创造力"，同时也增加了产生错误结果的可能性。

这可能会影响用户(可能会对不准确的信息采取行动)和下游进程、插件或其他计算(可能会失败或根据不准确的输入产生额外的不准确结果)(图 3)。

图 3.LLM 无法完成任务并正确回答相关问题的示例

在设计下游进程和插件时，必须考虑到 LLM 错误的可能性。与提示注入一样，预先进行良好的安全设计，包括插件参数化、输入清理、可靠的错误处理，以及确保在执行敏感操作时明确请求用户授权。所有这些方法都有助于降低与 LLM 相关的风险。

此外，请确保任何 LLM 编排层都可以提前终止，并在请求或 LLM 生成无效时通知用户。这有助于避免在调用插件序列时出现复合错误。跨 LLM 和插件调用的复合错误是为这些系统构建利用向量的最常见方式。此处应使用识别错误数据时失败封闭的标准做法。

围绕为应用程序提供支持的 LLM 的范围、可靠性和适用性对用户进行教育非常重要。请注意，支持 LLM 的应用程序旨在补充而不是取代他们的技能、知识和创造力。使用任何结果(无论是否由 LLM 衍生)的最终责任在于用户。

结束语

LLM 可以为用户和部署 LLM 的组织提供重要价值。但是，与任何新技术一样，新的安全风险也随之出现。提示注入技术是众所周知的，任何应用程序(包括 LLM)的设计都应考虑到该风险。

不太熟悉的安全风险包括 LLM 可能造成的各种形式的信息泄漏，这需要仔细追踪数据流和管理授权。从用户可靠性的角度和应用程序的角度来看，LLM 偶尔不可靠的性质也必须考虑在内。

让您的应用程序能够可靠地应对自然和恶意错误，可以提高其安全性。通过考虑本文中概述的风险，并应用所述的缓解策略和最佳实践，您可以降低面临这些风险的风险，并帮助确保成功部署。

想要深入了解如何攻击和维护机器学习模型的相关信息，请参阅 NVIDIA 在 "黑帽欧洲 2023 (Black Hat Europe 2023)" 的内容。

阅读原文