利用 Oracle 23ai 实时应用安全（RAS）保护 RAG 应用中的向量化数据

当今，企业面临的问题不再是“是否要在业务中实施 AI”，而是“如何在环境中安全地实施 AI”。在检索增强生成（RAG）应用中，向量数据库扮演着至关重要的角色。本文将探讨如何使用 Oracle 23ai 的实时应用安全（RAS）功能，为 RAG 应用中的向量化数据提供细粒度的访问控制，确保数据安全。

RAG 应用架构中的向量数据库安全挑战

RAG（Retrieval-Augmented Generation）应用的关键组成部分之一是向量数据库。典型的 RAG 流程是将文档分割成块，转换成嵌入向量，然后存储在向量存储中。当用户提出问题时，系统会检索语义上最相关的块，并将它们传递给大型语言模型（LLM）以生成响应——这使得向量搜索成为管道的核心要素。根据用例的不同，您可能需要在某些向量化数据上强制执行严格的访问控制。

以医疗保健行业为例，假设一家医院正在开发一个 RAG 应用，以帮助患者和医生管理每天产生的大量数据。医院会对每个患者的许多文档进行向量化，并将生成的文档块存储在数据库中。这使得相似性搜索能够支持构建在存储数据之上的各种用例。例如，医生可以通过向量搜索快速找到与特定疾病症状相似的病例报告，从而辅助诊断。

然而，如何确保相似性搜索始终在特定患者或医生的上下文中进行？仅仅依靠 RAG 应用的开发人员在相似性搜索期间应用必要的过滤器，真的足够安全吗？如果部署了新版本的应用，而某些过滤器被意外遗漏了怎么办？如果我们想将向量数据库暴露给其他应用，难道每次都要重新发明轮子吗？

AI 服务通常表现得像黑盒子，难以实施一致的安全性。开发人员可能会忘记或错误地应用过滤器，尤其是在复杂的数据管道中。相似性搜索跨越多个层——从用户输入到嵌入、检索和 LLM——增加了攻击面。因此，更稳健、更安全的策略是利用 Oracle Database 23ai 的内置安全功能，并在数据库级别强制执行访问控制。

Oracle 23ai 实时应用安全（RAS）：细粒度访问控制的利器

为了应对 RAG 应用中向量化数据的安全挑战，Oracle 23ai 引入了强大的实时应用安全（RAS）功能。RAS 允许在数据库级别应用细粒度的访问控制，确保无论查询来自何处，都会自动强制执行安全上下文。

RAS 的核心优势在于其细粒度的数据访问控制能力。不同于传统的粗粒度权限管理，RAS 可以基于用户角色、时间、甚至数据内容本身，动态地控制用户对数据的访问权限。例如，我们可以设置只有特定科室的医生才能访问特定病人的病历数据，或者限制非工作时间对敏感数据的访问。

主-从策略：完美匹配文档和向量化块的数据模型

RAS 提供了一个强大的功能，与大多数用于存储文档及其向量化数据块的数据模型的构建方式完美匹配：主-从数据安全策略。通过这种策略，只有当用户也有权访问主表中的相应父行时，才授予对明细表中子行的访问权限。

在 RAG 用例中，安全性的起点通常是内容所有者（CO）实体。从那里，我们希望访问权限简单地向下传递到相关的子表。比如在医疗行业，CO 可以是病人，CV是存储文本、图片、音频、视频等各类内容的实体，CCV存储包含向量嵌入的各个内容块。由于 CV 和 CCV 实体都容易受到相似性搜索的影响，并且可能包含敏感信息，因此确保只有相关文档才能被访问非常重要，这需要基于 RAG 应用中用户的安全上下文。

具体案例：医疗保健行业的应用

以医疗保健行业为例，假设一家医院希望允许其患者访问自己的数据并询问有关其病史的问题。我们需要确保安全上下文始终严格限制在单个患者。这种访问控制应该在数据库级别强制执行，我们可以通过应用主-从策略来实现这一点。

更进一步，假设我们希望允许医生仅访问其自己患者的数据，而无法查看属于其他医生患者的数据。这也可以使用相同的方法强制执行。

技术实现：RAS 的配置与应用

为了演示如何在 RAG 环境中使用实时应用安全（RAS），文章作者创建了一个简单的数据模型，可以在 Oracle Database 23ai 中重现。

1. 创建数据模型：

   • PATIENTS 表：存储患者的个人信息，例如姓名、出生日期、健康号码等。
   • DOCUMENTS 表：存储与患者相关的医疗文档，例如报告、扫描件、处方等。
   • DOC_CHUNKS 表：存储文档的向量化数据块，用于 AI 搜索和检索。该表包含文档块的文本内容和对应的向量嵌入。
   • DOCTORS 表：存储医生的信息，例如用户名、姓名、专科等。
   • DOCTOR_PATIENTS 表：存储医生与患者之间的关联关系，表明哪些医生负责哪些患者。

2. 创建用户和角色：

   • WKSP_HEALTHCAREWKS 用户：数据库模式，包含上述表格。
   • DBR_PATIENT_ROLE 角色：授予患者访问其自身数据的权限。
   • DBR_DOCTOR_ROLE 角色：授予医生访问其负责患者数据的权限。

3. 加载样本数据：

   • 向 PATIENTS 表中插入 10 个样本患者。
   • 为每个患者加载 9 到 12 个文档到 DOCUMENTS 表中。
   • 将文档分割成块，并使用预训练的嵌入模型（ALL_MINING_L12_V2）将每个块转换为向量嵌入，然后存储到 DOC_CHUNKS 表中。

4. RAS 技术设置：

   • 创建策略管理员用户（POLICY_ADMIN）： 用于管理 RAS 策略。
   • 创建安全类（HEALTH_SEC_CLASS）： 定义应用权限的范围，例如 view_patient_details（查看患者详细信息）。
   • 创建动态角色（PATIENT_DYNA_ROLE，DOCTOR_DYNA_ROLE）： 将应用角色映射到数据库层。
   • 创建访问控制列表（ACL）： 将用户或角色、数据领域和权限联系起来。例如，PATIENT_ACL 授予 PATIENT_DYNA_ROLE 对其自身数据的 select 和 view_patient_details 权限。
   • 设置命名空间（HEALTH_NS）： 用于存储自定义属性-值对，例如 PATIENT_ID 和 DOC_USERNAME，这些属性可以在安全策略中使用。
   • 创建并应用安全策略： 定义三个领域：
     • 患者访问其自身数据的策略：基于 PATIENT_ID 过滤访问。
     • 医生在工作时间内访问其负责患者数据的策略：基于 DOCTOR_ID 和时间段过滤访问。
     • 医生在非工作时间内访问其负责患者数据的策略：基于 DOCTOR_ID 过滤访问，并限制对敏感列的访问。
   • 创建技术用户（RAG_TECH_USER）： 用于管理 RAS 会话。

5. SQLcl 演示：

   • 使用 RAG_TECH_USER 帐户，创建应用会话，并设置命名空间上下文。
   • 演示患者只能访问其自身的数据。
   • 演示医生只能访问其负责患者的数据。
   • 演示医生在非工作时间内访问数据时，敏感列会被屏蔽。

目标架构：RAS 在实际应用中的部署

在实际应用中，RAS 会话通常由应用管理，应用负责创建、激活和终止 RAS 会话，并设置必要的上下文信息。可以使用 PL/SQL API（对于 Python 应用）或 Java API（对于 Java 应用）来管理 RAS 会话。

总结：细粒度数据保护，RAG 应用安全的未来

向量数据库在未来将成为许多组织的重要资产。借助 Oracle Database 23ai 融合数据库，将数据库使用扩展到 RAG 工作负载需要更深入的应用安全性。实时应用安全 (RAS) 是一种可以帮助您实现对敏感数据进行细粒度保护的解决方案。

本文演示了实时应用安全的主-从策略如何完美适应新的向量数据类型，以及大多数组织将在其数据模型中如何实现它。通过在数据库层直接强制执行访问控制，组织可以显著降低未经授权的数据暴露风险，即使多个应用和用户与敏感信息交互也是如此。

因此，对于处理敏感向量化数据的 RAG 应用，Oracle 23ai 的 RAS 提供了一种强大的安全解决方案。通过细粒度的访问控制，企业可以确保数据安全，并合规于相关法规。随着 AI 应用的不断发展，RAS 将在保护向量数据库的安全方面发挥越来越重要的作用。记住，数据安全是 AI 应用成功的关键基石，选择合适的安全方案至关重要。