确保 RAG 数据摄取管道的安全性：过滤机制

重要要点

RAG 应用程式透过整合外部数据来增强大型语言模型的回应，但此过程可能引发安全风险。外部数据的摄取可能导致的安全风险包括 prompt 注入攻击。需要在数据摄取阶段实施安全措施，以确保 RAG 系统的安全。本文将探讨 RAG 数据摄取管道中的潜在安全风险，并提供相应的缓解步骤及架构模式。

RAG 数据摄取流程的安全概述

在讨论如何减轻摄取管道中的风险之前，首先来看看 RAG 工作流程的基本结构，以及在保护 RAG 应用时需要考虑的方面。假设您正在使用 Amazon Bedrock 知识库 来建立 RAG 应用。Amazon Bedrock 知识库提供一系列内建的 安全控制措施，可用于数据保护、存取控制、网络安全、日志记录和监控，以及输入/输出验证等方面，以减轻许多的安全风险。

在利用 Amazon Bedrock 知识库的 RAG 工作流程中，主要涉及以下环境：

由 Amazon Bedrock 服务团队管理的 Amazon Bedrock 服务帐户。用来储存 RAG 数据的 AWS 帐户如果您使用 AWS 服务作为向量存储。根据您选择的向量数据库，还可能包括外部环境。如果您选择 Pinecone 或 Redis Enterprise Cloud 作为向量数据库，则需要使用 AWS 以外的环境。

以下是 RAG 数据摄取流程的一个简要流程图：

在这一工作流程中，摄取请求通过调用 StartIngestionJob Bedrock API 开始。具体步骤包括：

如果请求拥有正确的 IAM 权限，则会发送至 Bedrock API 端点。请求会被传递至知识库服务组件。与请求相关的元数据会存储在 Amazon DynamoDB 数据库中，该数据库仅用于列举和表征数据源及其同步状态。接著，会从 Amazon S3 中提取客户提供的数据，并使用客户管理的 KMS 密钥进行解密如果数据经过加密。数据被读取后，将发送内部请求来调用所选择的嵌入模型。Amazon Bedrock中的嵌入模型将创建嵌入，并将其发送至选择的向量存储。如果需要访问向量存储的凭证或密钥，则可以存储在 AWS Secrets Manager 中自动检索并使用。正在进行的摄取作业的检查点将临时存储于一个加密的 S3 存储桶中，以便稍后恢复工作。ingestion DynamoDB 表将存储用于同步向量存储所需的信息。

在数据静态加密方面：

环境加密客户 AWS 帐户使用客户管理的 KMS 密钥加密外部环境Redis Enterprise Cloud 和 Pinecone 拥有各自的加密功能Amazon Bedrock 服务帐户S3 存储桶可使用客户管理 KMS 密钥，但 DynamoDB 表只能使用 AWS 拥有的密钥加密

在 RAG 数据摄取工作流程中，数据在传输过程中也是加密的。Amazon Bedrock 知识库在与第三方向量存储通信时使用 TLS 加密，当供应商支持时则会使用该加密技术。

RAG 数据摄取管道的安全风险与摄取过程过滤的必要性

RAG 应用天然依赖于基础模型，这引入了额外的安全考量，超出了传统的应用程序保护。基础模型可分析复杂的语言模式并根据输入上下文提供回应，可能受到 jailbreak、数据中毒和反转等恶意事件的影响。一些特定于 LLM 的风险已在 OWASP LLM 应用程序十项风险 和 MITRE ATLAS 文件中进行了映射。

对于 RAG 摄取管道，特别相关的风险之一是 prompt 注入。在 prompt 注入攻击中，威胁行为者通过以合法用户提示的形式提供恶意输入来操控生成 AI 应用程序。此类攻击有两种形式：直接和间接。

直接 prompt 注入发生在威胁行为者覆写了底层系统提示的情况下。这可能使得他们能够通过与不安全的功能和数据存储互动来探查后端系统。为了保护生成 AI 应用免受这种攻击，您可以使用 Amazon Bedrock Guardrails 来设置 LLM 的推理输出过滤。

间接 prompt 注入发生在 LLM 接受来自外部来源的输入，而这些来源可以被威胁行为者控制，例如网站或文件。在 RAG 应用的摄取管道中，威胁行为者可能会在外部内容中嵌入 prompt 注入，这可能使他们操控 LLM 能访问的其他系统，或向用户返回不同的答案。间接 prompt 注入可能并不容易被人类识别，安全问题可能来自于 LLM 基于其训练数据的回应，也可能来自 RAG 应用能够访问的知识库数据源。为了减轻这些风险，您应专注于 LLM、知识库和纳入 RAG 应用的外部内容之间的交集。

外部数据源摄取风险：间接 prompt 注入的范例

假设一个威胁行为者设计了一份文档或向网站注入了内容，旨在操控 LLM 生成不正确的回应。对于人类来说，这样的文档可能难以与合法文档区分开来。然而，该文档可能包含一个不可见的序列，当该序列用作 RAG 的引用来源时，可能会操控 LLM 生成不希望的回应。

例如，假设您有一个描述下载公司软体流程的文件。这个文件被纳入了 LLM 驱动的聊天机器人的知识库。用户询问聊天机器人正确的下载链接后，可以通过该链接下载套件。

然而，威胁行为者可以使用白色文字在白色背景上插入第二个链接。这段文字对于下载文件的用户来说是不可见的，但在资料解析时此文本对解析器是可见的。这将导致 LLM 返回隐藏的链接，使用户下载由威胁行为者在其网站托管的恶意软体，而不是预期来自合法网站的软件。

如果您的应用程序与插件或代理相连，以便能够调用 API 或执行代码，则模型可能会被操控以运行代码、打开威胁行为者选择的网址等。

以下的图示展示了 RAG 工作流程及间接 prompt 注入攻击的发生方式：

如图所示，数据的摄取过程从右下角开始，文件 1 是合法的、未修改的文件，已储存在数据源中通常是 S3 存储桶。在摄取过程中，文档会被文档解析器解析，分割成块，转换为嵌入，然后储存在向量存储中。当用户左上角询问有关该文件的问题时，来自该文件的信息将作为上下文添加到用户提示中。然而，您可能会有恶意的文件 2，看上去对人类读者完全一样，但却包含了一个不可见的字符序列。当这一序列插入到发送至 LLM 的提示中时，将能影响环境的整体回应。

威胁行为者可能会分析 RAG 工作流程中的以下三个方面来创建并放置恶意序列：

文档解析器是设计用于读取和解释文档内容的软体。它根据预定的规则或模式分析文本并提取相关信息。通过分析文档解析器，威胁行为者可以找出如何将不可见内容注入不同文档格式。文本分割器或 chunker根据内容的主题分割文本。威胁行为者会分析文本分隔器，确定其不可见序列的正确插入位置。基于段落的分割器根据标签区分不同的段落，威胁行为者可以利用这些标签将其不可见序列放置于这些划分的块中。提示模板是用于生成特定输出或指导与 LLM 交互的预定结构。提示模板决定了从向量数据库检索的内容如何与用户的原始提示组织以形成增强提示。模板至关重要，因为它会影响基于 RAG 的应用的整体效能。如果威胁行为者了解到您应用程序中使用的提示模板，他们就可以在构建其威胁序列时考虑这一点。

潜在缓解措施

威胁行为者能通过发布包含精巧设计和恰当放置的不可见序列的文档来威胁 RAG 应用。因此，尽可能仅从可信的来源摄取数据。然而，如果您的应用程序需要使用与摄取来自不可信来源的数据，则建议在处理过程中小心以减轻间接 prompt 注入等风险。为加固您的 RAG 摄取管道，您可以使用以下缓解技术来紧密监控 RAG 摄取管道。这些可以单独实施或结合使用。

配置您的应用程序以显示其回应所依赖的源内容，让用户能够交叉验证内容与回应。这可以通过使用 Amazon Bedrock 知识库中的 引用 功能来实现。然而，这种方法并不是预防技术，而且对于复杂内容来说可能效果不佳，因为用户可能需要投入大量时间进行验证。

在 LLM、外部来源和可扩展功能例如插件、代理或下游函数之间建立信任边界。视 LLM 为不受信任的行为者，并保持最终用户对决策过程的控制。这再次回到最小特权原则，确保 LLM 只有在需要的情况下才能访问数据源，并特别小心与外部插件或 API 的连接。

持续的评估在维护 RAG 系统的准确性和可靠性中扮演了重要角色。您可以使用标记数据集包含提示和目标答案进行 RAG 应用的评估。然而，像 RAGAS 的框架提出了自动化指标，实现无参考的评估，减轻对人类标注真实答案的需求。实施 RAG 评估机制可帮助您发现模型反应中的不规则性和从知识库获取的数据。如果您希望更深入地探索如何评估 RAG 应用程序，请参考 使用 Amazon 评估增强生成应用程序的可靠性，该文提供更多相关见解及指导。

您可以对打算摄取到向量数据库中的内容进行人工监控，特别是当数据包含外部内容例如网站和文件时。将人纳入流程可以帮助抵御不太复杂的可见威胁序列。

有关减轻生成 AI 应用风险的进一步建议，请参见 OWASP LLM 十项风险的缓解措施 和 MITRE ATLAS。

架构模式 1：使用格式打破器和 Amazon Textract 作为文档过滤器

移除摄取文件中潜在威胁序列的一个潜在工作流程是使用格式打破器和 Amazon Textract。这一流程特别针对不可见的威胁向量。以下是可能的设置过程：

飞鱼加速器苹果版假设您使用 S3 槽来摄取文件。您想上传到知识库的文件最初将上传至此存储槽。上传操作将自动启动处理格式打破的工作流程。格式打破 是一个清理和保护文档的过程，通过转换文档以去除可能携带安全风险的元素，如宏、脚本、嵌入对象和其他非文本内容。摄取时的格式打破涉及将文本内容转换为 PDF 格式，然后转换为 OCR 格式。首先将文本转换为 PDF 格式。您可以使用 AWS Lambda 函数将文本转换为 PDF 格式。例如，您可以创建一个这样的函数，将 LibreOffice 中的文件渲染器和 PDF 生成器放入此 Lambda 函数中。这一步是必要的，因为 Amazon Textract 目前仅支持 PNG、JPEG、TIFF 和 PDF 格式。文件转换为 PDF 格式后，您可将其保存到 S3 槽中。这次上传到 S3 将触发工作流程中格式打破的下一步，即将 PDF 内容转换为 OCR 格式。您可以使用 Amazon Textract 处理 PDF 内容，将文本内容转换为 OCR 格式。Amazon Textract 将 PDF 渲染为图像，提取 PDF 中的文本，基本上创建该文档的纯文本版本。OCR 格式确保不可文本元素例如图像或嵌入文件