Как вы шифруете данные для RAG (конфиденциальность)?

Краткий тезис

Шифрование данных в RAG‑системе — это многоуровневая защита на всех этапах жизненного цикла данных: при хранении (at rest), при передаче (in transit) и во время обработки (in use). Самый сложный этап — шифрование «в использовании», где применяются confidential computing (TEE) или локальная модель. Главный принцип: чувствительные данные (PII) должны удаляться до индексации, чтобы они вообще не попали в embeddings и векторную БД.

1. Модель угроз и базовые понятия

Конфиденциальность в RAG означает, что ни одна третья сторона не должна получить доступ к содержимому документов пользователя, даже если она имеет физический или административный доступ к инфраструктуре. Угрозы делятся на три категории:

• Утечка на стороне провайдера (облачной векторной БД, API LLM).
• Перехват в сети (атака man‑in‑the‑middle).
• Утечка через embeddings (восстановление исходного текста из векторного представления).

Для каждой категории используются соответствующие механизмы.

Термин PII (Personally Identifiable Information) — персонально идентифицируемая информация (имя, email, телефон, SSN и т.д.).

2. Шифрование при хранении (Data at Rest)

Векторные базы данных

Большинство managed‑векторных БД (Pinecone, Qdrant Cloud, Weaviate Cloud) предоставляют встроенное шифрование at rest. Обычно это AES‑256 для дисковых файлов и автоматическое управление ключами (CMK — Customer Managed Key).

Если используется self‑hosted версия (например, Qdrant в Docker), необходимо явно настроить шифрование диска (LUKS, dm‑crypt) и шифрование файлов чанков.

Оперативное хранение документов (объектное хранилище / файлы)

Исходные документы (PDF, текст) хранятся в защищённом бакете. S3/GCS/Azure Blob поддерживают серверное шифрование (SSE‑S3, SSE‑KMS). Рекомендуется client‑side encryption — документы шифруются на стороне отправителя до загрузки.

# Пример client‑side encryption с помощью библиотеки cryptography
from cryptography.fernet import Fernet

key = Fernet.generate_key()
cipher = Fernet(key)

with open("document.pdf", "rb") as f:
    encrypted = cipher.encrypt(f.read())

# Отправляем encrypted в S3, ключ храним в Vault/AWS Secrets Manager

3. Шифрование при передаче (Data in Transit)

Все API‑вызовы (к векторной БД, LLM, эмбеддеру) должны использовать TLS 1.3 (или как минимум 1.2). Это защищает от перехвата эмбеддингов, контекста и запросов пользователя.

Рекомендации

• Включить mTLS (взаимная аутентификация) между микросервисами внутри кластера.
• Использовать VPN / WireGuard для связи между компонентами в разных облаках.
• Отключить старые версии TLS и шифры (например, TLS 1.0/1.1, RC4).

Термин mTLS — mutual TLS, когда обе стороны (клиент и сервер) предъявляют сертификаты. Это предотвращает атаки «человек посередине» даже внутри периметра безопасности.

4. Шифрование при обработке (Data in Use) — самая сложная часть

Данные расшифровываются в оперативной памяти во время выполнения пайплайна: генерация эмбеддингов, индексация, поиск, инференс LLM. Атакующий с доступом к хосту может вычитать память (DMA, cold boot, core dump).

4.1 Confidential Computing (TEE)

Trusted Execution Environment — аппаратно изолированная «анклав» внутри CPU, где данные обрабатываются в зашифрованном виде. Даже операционная система не имеет доступа к содержимому.

• Intel SGX / TDX — доступны в Azure (DCsv3) и bare metal серверах.
• AMD SEV / SEV‑SNP — часто в AWS (EC2 m6a.metal с SEV‑SNP) и GCP (N2D с AMD).
• AWS Nitro Enclaves — изолированная среда без сохранения состояния.

Применение в RAG

• LLM работает в enclave, ключи шифрования загружаются только внутрь анклава.
• Эмбеддинги генерируются внутри того же анклава и записываются в зашифрованную БД.
• Векторная БД (например, Qdrant) тоже можно запустить в enclave или рядом с разделяемыми ключами.

Недостатки: накладные расходы (~5–15% производительности), ограниченный объём защищённой памяти.

4.2 Self‑hosted модель в изолированном кластере

Альтернатива TEE — полностью контролируемая инфраструктура без сторонних API. Модель (LLM и эмбер) разворачивается на собственных GPU‑серверах, всё общение внутри VPN, доступ к модели только по mTLS. В этом случае данные in use защищаются административными мерами (SELinux, AppArmor, запрет core dumps, no‑exec стеки).

4.3 Шифрование в памяти на уровне приложения

Можно зашифровать sensitive‑поля перед передачей в LLM. Например, если в контексте RAG есть PII (номера счетов), на этапе retrieval зашифровать их прозрачным шифрованием (форматированное шифрование, FPE), а модель вызовет только зашифрованный текст. После ответа — расшифровка на стороне клиента. Это требует специальных форматов (например, FF1 из NIST SP 800‑38G).

Термин FPE (Format‑Preserving Encryption) — шифрование, сохраняющее длину и тип данных. Позволяет подменять PII на валидные, но зашифрованные значения, не ломая структуру контекста.

5. Техники предотвращения утечки через embeddings

Даже при идеальном шифровании сами эмбеддинги могут нести конфиденциальную информацию. Исследования показывают, что по вектору можно частично восстановить исходный текст (атака inversion). Поэтому:

• Удаляйте PII до индексации — используйте NER‑модели (spaCy, Presidio) для детекции и замены PII на placeholder’ы.
• Дифференциальная приватность (DP) — добавьте шум к эмбеддингам с контролируемым бюджетом ε. Это снижает точность, но защищает от прямого восстановления.
• Chunk‑level encryption — каждый чанк дополнительно шифруется на клиенте, индекс хранит хеш от открытого текста, а вектор — только для поиска похожих чанков (требует homomorphic encryption на этапе поиска, пока непрактично).

# Пример удаления PII перед индексацией с помощью Presidio
from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine

analyzer = AnalyzerEngine()
anonymizer = AnonymizerEngine()

text = "Мой email user@example.com, паспорт 1234 567890"
results = analyzer.analyze(text=text, language='ru')
anonymized = anonymizer.anonymize(text=text, analyzer_results=results)
print(anonymized.text)  # -> "Мой email <EMAIL_ADDRESS>, паспорт <US_PASSPORT>"

6. Выбор между managed и self‑hosted: таблица компромиссов

Основной совет: «Лучший способ — не загружать чувствительные данные в неконтролируемые API». Если данные критически важны (GDPR, HIPAA, SOC2), выбирайте self‑hosted или облачные TEE‑инстансы.

7. Практические шаги по внедрению шифрования в RAG

1. Аудит данных классифицируйте все источники на три уровня: public, internal, confidential.
2. Удаление PII на этапе загрузки (автоматически NER‑пайп).
3. Client‑side encryption для исходных документов.
4. TLS 1.3 + mTLS для всех внутренних сервисов.
5. Шифрование at rest в векторной БД (CMK).
6. Для confidential данных TEE анклавы (Azure SGX / AWS Nitro Enclaves) + шифрование эмбеддингов на стороне клиента.
7. Регулярное логирование и аудит кто, когда и к каким данным обращался.

8. Compliance и стандарты

• GDPR данные европейских резидентов должны обрабатываться в ЕС (data residency). Шифрование не отменяет требования privacy by design.
• HIPAA требуется шифрование PHI (protected health information) at rest и in transit. In use — обязательно (TEE или BAA с провайдером).
• SOC2 обязательный аудит контроля доступа и шифрования.

Пет-проект для закрепления

Задача: построить RAG‑систему для обработки конфиденциальных документов (например, выписки с личными данными) с гарантией, что PII не утекут в LLM.

Инструменты: Python, Presidio, Qdrant (self‑hosted с шифрованием диска), sentence‑transformers, vLLM с локальной моделью (Llama 3.1 8B).

Шаги:

1. Напишите ETL‑пайп, который загружает PDF, извлекает текст, детектирует PII через Presidio и заменяет на плейсхолдеры.
2. Создайте эмбеддинги очищенного текста и сохраните в Qdrant (включив шифрование at rest через файловую систему).
3. Реализуйте сервис retrieval на FastAPI с mTLS.
4. Запустите LLM в Docker с ограничениями (no‑new‑privileges, readonly rootfs).
5. Протестируйте атаку: попробуйте восстановить исходный текст из эмбеддингов (простейший Nearest Neighbor attack). Убедитесь, что восстановленное — это обезличенные данные.

Ожидаемый результат: Рабочий RAG, в котором ни один запрос не содержит PII в контексте, а исходные документы хранятся в зашифрованном виде. Вы сможете продемонстрировать, что инспекция логов и dump памяти не раскроют персональных данных.

Связь с другими вопросами

Навигация

• Предыдущий: 67
• Следующий: 69
• Индекс: 00. Индекс разборов