实施有效的数据授权机制以保护您在生成式 AI 应用中使用的数据
确保生成式 AI 应用中的数据安全：有效的数据授权机制实施 第一部分
主要重点
数据安全和数据授权在商业工作负载架构中至关重要，特别在生成式 AI 技术发展的背景下。使用敏感数据进行细调时，必须注意数据存取的安全性与授权机制。确保仅授权的用户能够访问数据至关重要，以避免未经授权的数据访问。这是两部分系列博文的第一部分。查看第二部分。
数据安全和数据授权区别于用户授权是商业工作负载架构的重要组成部分。随著人工智能AI技术的演进，其重要性已增强，生成式 AI 则引入了利用内部数据源与大型语言模型LLMs和多模态基础模型FMs相结合的新机会，以增强模型输出。在本博文中，我们将详细探讨生成式 AI 工作负载中的数据安全和授权。我们将逐步分析使用敏感数据作为 FMs 的微调材料时所面临的风险，并如何与生成式 AI 工作负载的工具例如检索增强生成RAG，AI 机器人结合。敏感数据可能包括第一方数据客户、病人、供应商、员工、知识产权IP、个人可识别信息PII或个人健康信息PHI。我们还将讨论如何在生成式 AI 应用和 Amazon Bedrock Agents 中实施数据授权机制。
生成式 AI 的数据风险
大多数传统 AI 解决方案如机器学习和 深度学习使用企业内部的标记数据来建立模型。生成式 AI 引入了新方式来使用企业内现有数据，并结合内部和公共数据，以及来自数据库、对象存储、数据仓库及其他数据源的半结构化或非结构化数据。
例如，一家软件公司可以利用生成式 AI 通过自然语言简化日志的理解。为了实现这个系统，公司创建了一个 RAG 管道 来分析日志，并允许事件响应人员查询数据。公司还创建另一个系统，使用基于代理的生成式 AI 应用将自然语言查询转换为 API 调用，以搜索客户警报，聚合多个数据集，帮助分析师识别感兴趣的日志条目。系统设计者如何确保仅授权的主体如人类用户或应用程序可以访问数据？通常，当用户访问数据服务时，各种授权机制将验证用户是否有权访问该数据。然而，使用 LLM 和生成式 AI 时，您应考虑数据访问的问题。让我们看一下三个不同的重点领域。
输出稳定性
由于非确定性，LLM 的输出不会随时间变得可预测和重复，并且取决于各种因素。例如，您是否从一个模型版本切换到另一个？您是否将温度设置接近 1，以偏向于更具创造性的输出？您是否在当前会话中提出额外问题，这可能影响 LLM 的响应？这些实施考量十分重要，并导致模型的输出在不同请求之间变化。与传统机器学习相比，生成式 AI 输出可以是生成文本、图像、视频、音频或其他不遵循特定架构的内容，这可能对希望在 LLM 的训练和微调中使用敏感数据的组织造成挑战。这就是为什么必须有明确的授权流程来管理生成式 AI 应用中数据的访问和使用，包括 LLM 本身。
我们来看看一个例子。下图显示了用户在使用 LLM 的工具或函数时的请求流。
图 1：授权发出请求的用户。不要依赖 LLM 的数据来做授权决策。
假设 LLM 在查询文本模型步骤的输出请求生成式 AI 应用提供来自工具或函数调用的附加数据。在调用工具，搭配模型输入参数步骤中，生成式 AI 应用使用 LLM 的信息来检索所需的附加数据。如果不实施适当的数据验证，而是使用 LLM 的输出来做工具或函数的授权决策，这可能使威胁行为者或未经授权的用户能够对其他系统造成改变或获得未经授权的数据访问。从工具或函数返回的数据将被作为附加数据在“用工具数据增强用户查询”步骤中作为提示的一部分传递。
安全行业已经看到威胁行为者试图使用先进的提示注入技术来绕过敏感数据检测详情请参见此 arXiv 论文。即使已实施敏感数据检测，威胁行为者也可能要求 LLM 提供敏感数据，但要求以其他语言或反向字母的形式回答，或使用其他检测工具不会捕获的机制。
这两个示例场景的后果来自于 LLM 在完成任务时使用数据的不可预测性，并可能包含 RAG 和工具推断中的敏感数据，即使已实施敏感数据保护。若未建立正确的数据安全性和数据授权机制，组织可能面临允许未经授权访问部分 LLM 实施的敏感信息的风险。
授权
与基于角色或身份的访问数据来源不同，当数据通过训练或微调成为 LLM 的一部分，或作为提示发送至 LLM 时，主体人类用户或应用程序将访问 LLM 或包含数据的提示回到。在之前的日志分析例子中，假设用于培训用于警报关联的 LLM 的内部数据集，这样的 LLM 如何知道主体例如与生成式 AI 应用交互的用户是否被允许访问数据集中某些特定数据？如果使用 RAG 为 LLM 请求提供附加上下文，LLM 又如何知道纳入提示的 RAG 数据是否获得授权可以在响应中提供给主体？
高级提示和护栏是用来过滤和模式匹配的，但并不是授权机制。LLMs 并不具备在推断过程中决定哪些主体将访问数据的能力，这意味著要么不做数据授权决策，要么必须由其他系统做出。若无法将这些能力作为推断的一部分，则授权决策需在生成式 AI 应用的其他部分中进行。例如，图 2 显示在与数据授权一起实施 RAG 时的数据流。 在 RAG 实现中，授权决策在生成式 AI 应用本身层面完成，而不是在 LLM 中。该应用向向量数据库传递额外的身份控制，以在 API 调用过程中从数据库中筛选结果。在这样做的过程中，应用提供的 key/value 的信息显示了用户在提示中被允许使用的内容，并且 key/value 信息通过安全的旁路通道保持独立于用户提示：元数据筛选。
图 2：在请求时授权对向量数据库的数据访问，而不是对数据从 LLM 发出的请求。
混淆代表问题
与任何工作负载一样，数据的访问只应授予经授权的主体。例如，当主体请求访问某个工作负载或数据来源时，主体与持有数据的资源之间需要一种信任关系。这一信任关系验证主体是否拥有存取数据的正确授权。组织需要在生成式 AI 应用实施上小心，以避免实现过程中出现 混淆代表问题。混淆代表问题发生在未持有执行操作或获得数据访问权的实体通过更高的特权实体获得访问权更多信息，请参见 混淆代表问题。
这一问题如何影响生成式 AI 应用？回到我们之前的例子，假设某主体无权访问内部数据源并被数据库或 Amazon Simple Storage Service (Amazon S3) 桶阻挡。然而，如果为同一主体授权使用生成式 AI 应用，那么生成式 AI 应用具备访问数据的授权，会导致该主体获得敏感数据的访问权。这一场景如图 3 所示。为了帮助避免此问题，确保使用正确的授权构造在提供数据给 LLM 的过程中是很重要的。
苹果加速器ios图 3：对直接访问 S3 桶的用户拒绝访问，但授权用户通过使用 LLM 访问 S3 桶中的数据。
随著对生成式 AI 使用的法律和监管要求不断增加，任何采用生成式 AI 的人都必须理解这三个领域。了解这些风险是构建安全的生成式 AI 应用的第一步，这些应用涉及公共和私有数据源。
您需要做什么
这对于想要保护敏感数据的生成式 AI 采用者意味著什么？是否应该停止使用第一方数据、知识产权IP和作为生成式 AI 应用一部分的敏感信息？不必这么做，但您应该了解这些风险并相应地加以缓解。在模型调谐或 RAG 数据库填充的数据选择方面或根据预期的变更频率的以这两者的某种组合，最终取决于生成式 AI 应用的业务需求。新的生成式 AI 应用的很多价值来自于结合公共和私有数据源来为客户提供额外价值。
这意味著您需要在架构中实施适当的数据安全和授权机制，并了解在每个步骤中应如何设置这些控制措施。在您的 AI 实现上，应遵循授权原则的基本规则：仅有授权的主体才能访问的数据应作为推断的一部分，或成为 LLM 训练和微调的数据集的一部分。如果敏感数据作为推断的一部分被传递RAG，则输出应限于参与会话的主体，生成式 AI 应用应该使用安全的旁路通道传递有关主体的附加信息。相比之下，如果敏感数据是 LLM 内部训练或微调数据的一部分，任何可以调用模型的用户都可以访问这些敏感数据，生成式 AI 应用应该限制对经授权用户的调用。
然而，在讨论如何与生成式 AI 应用实施适当的授权机制之前，我们首先需要讨论另一个主题：数据治理。使用结构化和非结构化数据作为生成式 AI 应用的一部分，您必须了解数据源中存在的数据，然后才能实施所选的数据授权机制。例如，如果您在生成式 AI 应用中实施 RAG 并使用内部日志、文档和其他非结构化数据，您知道数据源中存在什么数据，以及每个主体应该对哪些数据拥有访问权吗？如果没有，请专注于回答这些问题，然后再使用这些数据作为您生成式 AI 应用的一部分。您无法对尚未分类的数据进行适当的访问授权。组织需要实施合适的数据策展流程，以获取、标记、清理、处理和交互将成为生成式 AI 工作负载一部分的数据。为帮助您完成此任务，AWS 提供了多项资源和建议，作为我们的 AWS Cloud Adoption Framework for Artificial Intelligence Machine Learning and Generative AI 白皮书的一部分。
现在，我们来看一下如何使用 Amazon Bedrock Agents 实施强有力的授权。
使用 Amazon Bedrock Agents 实施强有力的授权
当生成式 AI 系统必须与实时数据或上下文专有和敏感数据交互时，或当希望生成式 AI 系统能够代用户采取行动时，可以考虑使用基于代理的架构模式。基于代理的架构为 LLM 提供了决定采取何种行动、请求何种数据或发出何种 API 调用的自主权。然后，明确定义 LLM 的自主范围是很重要的，以免提供过多的自主性详情参见 OWASP LLM08，使 LLM 决定影响系统安全或泄漏敏感信息的事宜。特别是在生成式 AI 工作负载通过代理交互式 API 时，仔细考虑您提供给 LLM 的自主权量非常重要，因为这些 API 根据 LLM 生成的参数可能会采取任意行动。
决定要为 LLM 提供多少自主权时，可以采用的简单模型是仅限于提供终端用户有权访问的数据作为 LLM 的输入。对于基于代理的架构，当代理控制区段的商业敏感信息访问时，应为该代理提供可信身份的来源，以便在检索数据之前可以进行授权检查。代理应该过滤掉终端用户无权访问的数据域，仅将终端用户有权访问的数据
