大模型安全之十七：RAG 系统中的数据安全与治理

引言：构建可信赖的 AI

随着企业级 AI 的快速落地，检索增强生成（RAG）已成为最广泛采用的架构模式之一。它让模型无需重新训练即可生成上下文感知的答案，但同时也引入了一条复杂且常被低估的数据流------跨越多个信任边界，每个环节都有独特的安全隐患。本文将系统性地梳理 RAG 系统中的数据安全与治理要点，并附上可直接落地的 RAG 数据安全清单 与 ACL 映射示例。

一、理解 RAG 数据流：治理的起点

在 RAG 系统中，数据从源头到最终响应，经历了一条完整的生命周期：

源仓库：内部文档、数据库、Wiki、外部 API、云存储等。
预处理与索引：文本被清洗、分块，并转换为向量表示（Embeddings），存入 Pinecone、Weaviate、Qdrant 等向量数据库。
检索：用户查询经过编排层，在向量库中进行语义搜索，取回最相关的结果。
生成：模型结合检索内容与自身知识生成答案。
审计：输出阶段需进行响应过滤与日志记录。

关键洞察：数据一旦离开源仓库，治理便已开始。每个提取、转换、索引步骤都必须保持机密性并符合数据管理政策。

二、数据级访问控制：ACL、ABAC、过滤与标记

仅保护模型本身远远不够，必须保护模型检索和使用的数据。RAG 系统中的访问控制是动态的、实时的。

机制	作用	特点
ACL（访问控制列表）	显式定义谁可以访问哪条数据	静态、精确，需贯穿到检索层
ABAC（基于属性的访问控制）	根据用户、文档、上下文的属性动态决策	细粒度、上下文感知
索引时过滤	数据入库时即应用访问限制	性能好，但灵活性差
查询时过滤	检索时动态评估用户身份与文档元数据	灵活、适应企业权限变化
文档标记	为每条记录嵌入结构化元数据（敏感度、部门、合规等级）	安全检索的基石

核心原则 ：AI 不仅要回答正确，更要在信任、政策与合规的边界内恰当地回答。

三、数据保护三件套：加密、匿名化、令牌化

技术	作用	应用场景
加密	将明文转为密文，只有密钥可解	静态加密（数据库、向量库）+ 传输加密（TLS）
匿名化	移除 PII，无法追溯至个人	索引文档或日志前处理
令牌化	用唯一令牌替换敏感值，原值存于保险库	需保留数据关系但不想暴露真实值

三者结合构成纵深防御 ：加密保证机密性，匿名化保护隐私，令牌化维持可用性。它们不仅是技术工具，更是信任机制------向用户、监管者和合作伙伴证明你负责任地处理信息。

3.1、加密（Encryption）

实际例子

场景：RAG 系统的向量数据库中存储了企业机密文档的嵌入向量。如果数据库被拖库，攻击者可能逆向推断出原文。因此需要对静态数据（数据库中的嵌入或原文）进行加密，同时传输时使用 TLS。

例子：使用 AES-256-GCM 对一段包含客户合同信息的文本进行静态加密，只有持有密钥的服务才能解密。

示例代码 （Python，使用 cryptography 库）

python 复制代码

# pip install cryptography
import os
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

def encrypt_at_rest(plaintext: str, key: bytes) -> bytes:
    """AES-256-GCM 加密，返回 nonce + ciphertext"""
    aesgcm = AESGCM(key)
    nonce = os.urandom(12)  # 96-bit nonce
    ciphertext = aesgcm.encrypt(nonce, plaintext.encode("utf-8"), None)
    return nonce + ciphertext

def decrypt_at_rest(blob: bytes, key: bytes) -> str:
    """解密"""
    aesgcm = AESGCM(key)
    nonce, ciphertext = blob[:12], blob[12:]
    return aesgcm.decrypt(nonce, ciphertext, None).decode("utf-8")

if __name__ == "__main__":
    # 实际中密钥应由 KMS（如 AWS KMS / HashiCorp Vault）管理
    key = AESGCM.generate_key(bit_length=256)

    sensitive_doc = "客户合同：ACME 公司，2024 年采购金额 120 万美元。"
    encrypted = encrypt_at_rest(sensitive_doc, key)
    print("密文 (hex):", encrypted.hex())

    decrypted = decrypt_at_rest(encrypted, key)
    print("解密后:", decrypted)
    assert decrypted == sensitive_doc

RAG 场景应用：向量库落盘时对 embedding blob 加密；调用嵌入模型 API 时强制 HTTPS/TLS 1.3。

3.2、匿名化（Anonymization）

实际例子

场景：在将客服工单、用户反馈索引进 RAG 之前，需要移除姓名、电话、邮箱、身份证号等 PII，使数据无法追溯到个人，同时保留语义供模型检索。

例子：使用正则 + Presidio（微软开源 PII 检测工具）对一段客服对话进行匿名化。

示例代码 （Python，使用 presidio-analyzer + presidio-anonymizer）

python 复制代码

# pip install presidio-analyzer presidio-anonymizer spacy
# python -m spacy download zh_core_web_sm  # 中文模型（可选）
from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine

analyzer = AnalyzerEngine()
anonymizer = AnonymizerEngine()

def anonymize_text(text: str, language: str = "en") -> str:
    # 1. 检测 PII
    results = analyzer.analyze(text=text, language=language)
    # 2. 替换为占位符
    anonymized = anonymizer.anonymize(text=text, analyzer_results=results)
    return anonymized.text

if __name__ == "__main__":
    raw = (
        "客户张伟（电话 13800138000，邮箱 zhangwei@example.com）"
        "反馈订单 #A123 的发票寄到了北京市朝阳区建国路 88 号。"
    )
    # 英文引擎对中文支持有限，这里用简单正则做演示补充
    import re
    def simple_anonymize(t: str) -> str:
        t = re.sub(r"1[3-9]\d{9}", "[PHONE]", t)
        t = re.sub(r"[\w.+-]+@[\w-]+\.[\w.]+", "[EMAIL]", t)
        t = re.sub(r"[\u4e00-\u9fa5]{2,4}(?=（)", "[NAME]", t)
        t = re.sub(r"北京市[\u4e00-\u9fa5]+", "[ADDRESS]", t)
        return t

    print("原文 :", raw)
    print("匿名化:", simple_anonymize(raw))

RAG 场景应用 ：在 索引前 对文档 chunk 做匿名化，确保向量库中不含可识别个人的信息；同时注意匿名化需不可逆，且多数据集合并后仍无法重识别。

3.3、令牌化（Tokenization）

实际例子

场景：RAG 系统需要保留客户信用卡号、患者 ID 等敏感字段的关联关系用于分析或检索，但不能暴露真实值。令牌化用随机 token 替换敏感值，原值存入安全保险库（Vault）。

例子：将信用卡号替换为 UUID token，映射关系存储在加密的 Vault 中，只有授权服务可还原。

示例代码（Python，模拟 Vault 的令牌化/去令牌化）

python 复制代码

import uuid
import hashlib
from cryptography.fernet import Fernet  # pip install cryptography

class TokenVault:
    """简易令牌保险库：token -> 加密后的原值"""
    def __init__(self):
        self._key = Fernet.generate_key()
        self._fernet = Fernet(self._key)
        self._store = {}  # 生产中应使用 KMS + 数据库

    def tokenize(self, value: str) -> str:
        token = str(uuid.uuid4())
        self._store[token] = self._fernet.encrypt(value.encode())
        return token

    def detokenize(self, token: str, authorized: bool = False) -> str:
        if not authorized:
            raise PermissionError("未授权，无法还原令牌")
        return self._fernet.decrypt(self._store[token]).decode()

if __name__ == "__main__":
    vault = TokenVault()

    card = "4111-1111-1111-1111"
    token = vault.tokenize(card)
    print("原卡号 :", card)
    print("令牌   :", token)

    # 业务系统日常只看到 token
    print("检索用 :", f"用户支付卡 {token} 存在异常交易")

    # 仅授权服务可还原
    print("授权还原:", vault.detokenize(token, authorized=True))

RAG 场景应用：向量库中只存 token，查询时若用户有权限，再通过 Vault 还原真实值；这样即使向量库泄露，也无法直接获得敏感数据。

3.4、三者对比与协同

维度	加密	匿名化	令牌化
目标	机密性	隐私	可用性 + 安全
可逆性	可逆（持密钥）	不可逆	可逆（持 Vault 权限）
数据形态	密文	脱敏文本	随机 token
典型场景	静态/传输存储	索引前清洗 PII	保留关联关系的敏感字段
RAG 应用	向量库加密、TLS	文档 chunk 脱敏	卡号/ID 替换后检索

3.5、合规提示

加密：密钥必须由 KMS/Vault 管理，避免硬编码；满足 GDPR 第 32 条、HIPAA 安全规则。
匿名化：需验证不可逆性，防止"去匿名化"攻击；GDPR 下真正匿名化的数据不再属于个人数据。
令牌化：Vault 本身是最高价值目标，需强访问控制 + 审计日志；PCI DSS 明确认可令牌化作为持卡人数据保护手段。

四、安全嵌入实践：保护知识产权与 PII

嵌入是 RAG 系统的核心，但常被误认为"无害的元数据"。事实上，嵌入向量仍编码了原文的语义，在特定条件下可能被逆向重建或推断出机密内容。

安全嵌入的五项原则：

嵌入前净化：移除或掩码 PII，排除敏感知识产权文本。
嵌入过程安全：向量化前后加密，使用安全连接；敏感内容尽量在自有环境部署嵌入模型。
存储与访问：向量数据库需静态加密、严格 ACL、ABAC 策略，并按部门/客户/项目隔离索引。
查询时安全：检索机制只搜索与用户权限对齐的嵌入，实现逻辑分段。
知识产权保护：限制导出功能、监控查询日志、定期审计嵌入索引访问。

嵌入是现代 AI 的"隐形 backbone"，保护它们就是保护你的知识、用户与竞争优势。

五、治理、AI 安全态势管理与防火墙的闭环

有效的数据治理不是静态文档，而是与 AI 安全态势管理（SPM）和 AI 防火墙深度交织的持续循环：

治理定义规则：数据分类、所有权、保留政策、合规要求。
SPM 管理"在哪里"和"如何"：持续监控模型、数据集、连接器与 API，将政策转化为可度量、可执行的控制。
防火墙执行"何时"和"谁"：在运行时检查提示、响应与 API 调用，实时允许、脱敏或阻止数据交换。

闭环价值：每个事件从数据摄取到模型查询都可追溯，与防火墙动作关联，并映射回原始治理政策------这正是欧盟 AI 法案、ISO/IEC 23894 等框架所要求的可审计性。

六、真实世界厂商实践

平台	定位	治理与安全亮点
Pinecone	向量数据库	按项目/租户/部门隔离索引，独立权限与加密密钥；支持区域特定部署，满足 GDPR 数据驻留
Weaviate	开源向量数据库	元数据驱动治理，支持 ABAC；开源可审计、可定制
Qdrant	开源向量搜索引擎	细粒度访问规则、加密、用户认证、网络隔离；可控多租户
Databricks Unity Catalog	统一治理层	跨 AI 与分析工作负载的数据血缘与访问策略；统一管理数据、模型、元数据

这些工具共同代表了数据基础设施与安全治理的融合------治理不再是外部附加，而是内建于架构之中。

七、RAG 数据安全清单（RAG Data Security Checklist）

以下内容提取自课程提供的 RAG 数据安全清单与 ACL 映射示例，作为可直接使用的模板。

7.1 RAG 数据安全清单

阶段	检查项	说明
数据流与可见性	是否梳理了所有源仓库？	明确数据来源、移动路径与接触者
	是否对数据进行了分类与标记？	如：机密、内部、公开
嵌入安全	嵌入前是否移除/掩码 PII？	防止隐私泄露
	嵌入是否加密存储？	静态加密
	向量库是否按部门/租户隔离？	防止跨租户数据泄露
访问控制	是否实施了 ACL？	显式权限定义
	是否支持 ABAC？	基于属性的动态决策
	过滤发生在索引时还是查询时？	权衡性能与灵活性
运行时保护	是否进行查询时过滤？	只返回用户有权访问的内容
	是否有滥用检测？	异常查询行为监控
	是否对生成后响应进行扫描？	防止 PII 或机密信息输出
治理与合规	是否集成 SPM 平台？	持续监控与风险评分
	是否部署 AI 防火墙？	实时执行治理政策
	是否使用 Unity Catalog 等目录工具？	统一策略与血缘管理
审计与追溯	是否记录所有查询与访问？	可追溯、可审计
	是否能映射回原始治理政策？	满足监管要求

7.2 示例 ACL 映射

数据仓库	角色	敏感度	允许访问	拒绝访问
HR 文档	HR 专员	高	查看、检索	工程师、市场
财务文件	财务分析师	高	查看、检索	实习生、外部
工程文件	工程师	中	查看、检索	HR、市场
客户反馈	市场分析师	中	办公时间内检索	非办公网络、外部
公开手册	所有员工	低	查看、检索	无

该映射体现了最小权限原则：针对性、可追溯、政策驱动。

八、总结与核心要点

数据流可见性是基础：不知道数据去哪，就无法保护它。
访问控制必须动态：ACL + ABAC + 过滤 + 标记 = 多层防御。
加密、匿名化、令牌化缺一不可：纵深防御保护静态与传输中的数据。
嵌入不是无害的：它们承载知识产权与 PII，需同等 rigor 保护。
治理是活的系统：治理定义规则，SPM 管理执行，防火墙实时执行。
厂商实践已验证：Pinecone、Weaviate、Qdrant、Unity Catalog 将治理内建于架构。
清单是行动蓝图：RAG 数据安全清单与 ACL 映射可直接用于你的 AI 项目。

在 AI 中，信任不只建立在准确性上，更建立在对数据机密性与完整性的保证上。构建设计即可信的 RAG 系统，才能让企业 AI 从风险实验走向可扩展、合规、可问责的核心能力。