📚 Безопасность RAG-систем: угрозы и защита

Безопасность RAG (Retrieval-Augmented Generation, генерация с дополнением из внешних источников) — это защита всего конвейера «корпус → эмбеддинги → векторное хранилище → генератор» от отравления данных, косвенных инъекций через документы и утечки информации при извлечении. RAG стал стандартом для корпоративных LLM-ассистентов, но он же расширяет поверхность атаки: теперь скомпрометировать систему можно, не трогая саму модель, — достаточно «заминировать» базу знаний. В OWASP Top 10 для LLM 2025 этим рискам посвящены сразу несколько категорий, включая новую LLM08 (Vector and Embedding Weaknesses). Ниже — разбор угроз и того, как их закрывает платформа SYNTREX.

Часть серии: OWASP LLM Top 10 · Prompt Injection · Джейлбрейки LLM.

Архитектура RAG и её поверхности атаки

RAG-система состоит из четырёх компонентов, и каждый — потенциальная точка входа:

Компонент	Функция	Поверхность атаки
Корпус / база знаний	Хранит исходные документы	Отравление данных (poisoning)
Модель эмбеддингов	Превращает текст в векторы	Инверсия, извлечение исходного текста
Векторное хранилище	Поиск по сходству	Межтенантная утечка, неавторизованный доступ
Генератор (LLM)	Формирует ответ по контексту	Косвенная инъекция через извлечённый контент

Главная мысль: в RAG доверие к ответу не выше доверия к корпусу. Если в базу попал заражённый документ или нарушен контроль доступа к векторам, страдает вся система — независимо от того, насколько «безопасна» сама модель.

Отравление базы знаний (Data Poisoning) — OWASP LLM04

Атакующий внедряет в корпус вредоносные документы, которые с высокой вероятностью будут извлечены и повлияют на ответ. В отличие от отравления обучающих данных модели, отравление RAG-корпуса требует кратно меньших ресурсов: исследование PoisonedRAG (Zou et al., USENIX Security 2025) показало 90% успеха атаки при внедрении всего 5 вредоносных текстов на целевой вопрос в базе из миллионов документов. Атака работает и в black-box, и в white-box сценариях, а существующие защиты авторы признают недостаточными.

Сюда же относится манипуляция ранжированием (re-ranker): отравленные пары «текст + триггер-запрос» (PR-Attack) или универсальная коррупция малым набором состязательных текстов (UniC-RAG) заставляют систему предпочитать контент атакующего.

Защита: приём документов только из аутентифицированных whitelisted-репозиториев; адверсариальное сканирование на скрытые инструкции до индексирования; провенанс через OWASP CycloneDX / ML-BOM; WORM-хранилище с версионированием; регулярная ревалидация индекса.

Косвенная инъекция через документы — OWASP LLM01

Это косвенная prompt injection, доставленная через извлекаемый документ. Атакующий прячет инструкции в PDF (белый текст на белом фоне), веб-странице или письме, которое RAG подтянет в контекст; модель не отличает «свои» инструкции от встроенных в чужой контент. OWASP описывает сценарий «Hidden Text Injection», а исследование PoisonedRAG подтверждает: 5 специально сконструированных документов дают ~90% успеха.

Защита: сканировать извлечённый контент на инструкции до подачи в модель; нормализовать Unicode (снимать невидимые символы и белый-на-белом текст); разделять системные инструкции и контент в шаблоне промпта; наименьшие привилегии на инструменты агента (см. также «летучую тройку»).

Слабости векторов и эмбеддингов — OWASP LLM08

Новая категория 2025 года, специфичная именно для RAG. Включает несколько подрисков:

Межтенантная утечка (Cross-Context Leakage)

В мультитенантной среде с общим векторным хранилищем эмбеддинги одной группы пользователей могут быть извлечены в ответ на запрос другой — утекает коммерческая тайна. Типичная первопричина — отсутствие фильтрации по tenant_id до ранжирования по сходству. По данным отраслевых разборов, при нулевой технической сложности такая утечка воспроизводилась в большинстве тестовых запросов.

Инверсия эмбеддингов (Embedding Inversion)

Эмбеддинги долго считали «безвозвратным» сжатием — это миф. Работа Morris et al. «Text Embeddings Reveal (Almost) As Much As Text» (EMNLP 2023) восстановила 92% токенов из 32-токенных входов и извлекала полные имена из клинических записей. Few-shot атака ALGEN (2025) достигает результата всего на ~1000 обучающих образцов и работает кросс-доменно и кросс-язычно. Вывод: если векторное хранилище скомпрометировано — хранимые векторы можно «расшифровать» обратно в текст.

Membership Inference

Атака «Is My Data in Your Retrieval Database?» (Anderson et al., 2025) определяет, присутствует ли конкретный фрагмент в RAG-базе, по характерным ответам на crafted-запросы — это уже нарушение конфиденциальности состава корпуса.

Неавторизованный доступ к чанкам

Недостаточный контроль доступа позволяет извлекать чанки с PII, проприетарной или защищённой авторским правом информацией в обход прав пользователя.

Защита: permission-aware векторная БД с фильтрацией по метаданным до поиска; тегирование контента по уровням доступа; шифрование хранилища (AES-256 at rest, TLS 1.3 in transit); приватные сетевые эндпоинты; неизменяемый лог операций извлечения.

Эксфильтрация через извлечение — OWASP LLM02

Самая болезненная для compliance ситуация: RAG-система выдаёт данные одного пользователя в ответ на запрос другого — это уже регистрируемый инцидент утечки. Сюда же относится извлечение PII, медицинских записей (PHI), API-ключей и секретов, по ошибке проиндексированных вместе с документами, а также эксфильтрация через crafted-запросы. OWASP связывает эти риски с техниками MITRE ATLAS AML.T0024 (Infer Training Data Membership / Invert ML Model).

Защита: сканировать каждый документ на PII/PHI/секреты до создания эмбеддингов; маскировать чувствительные данные на входе и в ответе; контекст-сохраняющая токенизация вместо грубого удаления; DLP-сканирование вывода; контроль аномалий в паттернах извлечения.

Как SYNTREX защищает

SYNTREX встраивается в RAG-конвейер на двух рубежах: на приёме/индексировании (что попадает в корпус) и на извлечении/выводе (что уходит пользователю). Сводная карта:

Угроза RAG (OWASP)	Движки SYNTREX	Рубеж
LLM04 Data Poisoning	`dormant_payload`, `injection`	Приём документов
LLM01 Косвенная инъекция через документы	`injection`, `output_scanner`	Извлечение → генерация
LLM08 Слабости векторов/эмбеддингов	`pii`, `exfiltration`, `output_scanner`	Приём + извлечение
LLM02 Эксфильтрация при извлечении	`pii`, `exfiltration`, `output_scanner`	Вывод

Конкретно:

injection сканирует извлечённый контент на скрытые инструкции (с нормализацией Unicode — белый-на-белом текст и невидимые символы снимаются до анализа), не давая косвенной инъекции через документ дойти до модели.
Редактирование вывода через pii, output_scanner и exfiltration ловит API-ключи и токены в корпусе до индексирования и в ответах — секреты не уходят в эмбеддинги и не утекают пользователю.
pii маскирует персональные данные на входе и в выводе (включая 16-значные номера карт), снижая риск межтенантной утечки и инверсии эмбеддингов.
exfiltration блокирует каналы вывода данных наружу (в т.ч. Markdown-эксфильтрацию).
dormant_payload выявляет спящие полезные нагрузки в документах (паттерны Phantom/CorruptRAG), активирующиеся по триггеру.

Важная честная граница: межтенантная изоляция векторного хранилища (фильтрация по tenant_id, RBAC/ABAC на слое извлечения, шифрование) реализуется на стороне приложения и инфраструктуры RAG. SYNTREX не заменяет контроль доступа к векторной БД — он дополняет его сканированием контента, маскированием PII/секретов и неизменяемым аудитом операций.

Пример конфигурации `syntrex.yaml` для RAG

YAML

engines:
  injection:
    action: block
    confidence_threshold: 0.6
    normalize_unicode: true       # снимаем white-on-white и zero-width до анализа
    scan_retrieved_context: true  # проверяем извлечённые чанки, не только запрос
  pii:
    action: redact
    mask_character: "*"
    scan_on_ingest: true
  exfiltration:
    action: block                 # ключи/токены и каналы утечки не уходят наружу
  dormant_payload:
    action: alert                 # спящие нагрузки Phantom/CorruptRAG

Правило корреляции SOC: отравление RAG → подозрительный ответ

YAML

rules:
  - id: RAG_POISON_TO_LEAK
    name: "RAG Poisoning → Sensitive Leak"
    description: "Спящая нагрузка из RAG-контента, за которой следует PII/секрет в ответе"
    enabled: true
    conditions:
      - sequence:
          - category: dormant_payload
          - category: pii
        within: "5m"
        same_field: "session_id"
    action:
      create_incident: true
      severity: CRITICAL
      kill_chain_stage: "impact"
      playbook: "quarantine_rag_source"
    metadata:
      mitre_atlas: ["AML.T0051", "AML.T0024"]
      owasp_llm: ["LLM01", "LLM04", "LLM08"]

Каждая операция извлечения и каждый вердикт фиксируются в Decision Logger (цепочка SHA-256 + HMAC) — это даёт неизменяемый аудит-след для расследований и регуляторов (важно для GDPR/ФЗ-152, где RAG прямо отмечен как источник риска при обработке персональных данных).

Частые вопросы (FAQ)

Что такое безопасность RAG и почему это отдельная тема?

RAG-система дополняет ответы LLM данными из внешней базы знаний, и эта база становится новой поверхностью атаки. Скомпрометировать систему можно, не трогая модель: отравить корпус, спрятать инструкции в документе или вытащить данные через нарушенный контроль доступа к векторам. Поэтому безопасность RAG выделяют отдельно от безопасности самой модели.

Что такое отравление RAG (data poisoning)?

Это внедрение в базу знаний вредоносных документов, которые система извлечёт и использует в ответе. Исследование PoisonedRAG показало, что достаточно 5 специально подготовленных документов на целевой вопрос, чтобы добиться ~90% успеха атаки даже в базе из миллионов записей — модель при этом не модифицируется.

Можно ли восстановить исходный текст из эмбеддингов?

Да. Вопреки распространённому мнению, эмбеддинги — не безвозвратное сжатие. Атаки инверсии (Morris et al., 2023) восстанавливают до 92% токенов и извлекают, например, полные имена из медицинских записей. Поэтому векторное хранилище нужно шифровать и защищать так же строго, как исходные данные.

Что такое межтенантная утечка в RAG?

Это когда в общем векторном хранилище данные одного клиента (тенанта) попадают в ответы другому. Обычная причина — поиск по сходству идёт без предварительной фильтрации по tenant_id. Защита — permission-aware векторная БД, где права проверяются до ранжирования, и логическое разделение индексов.

Как защититься от косвенной инъекции через документы в RAG?

Нужно сканировать извлечённый контент на скрытые инструкции до подачи в модель, нормализовать Unicode (убирать белый-на-белом текст и невидимые символы), разделять системные инструкции и контент в шаблоне промпта и давать агенту наименьшие привилегии. В SYNTREX за это отвечают движки injection (с scan_retrieved_context) и output_scanner.

Заменяет ли SYNTREX контроль доступа к векторной базе?

Нет. Межтенантная изоляция, RBAC/ABAC и шифрование векторного хранилища остаются на стороне приложения и инфраструктуры RAG. SYNTREX дополняет их: сканирует контент на инъекции, маскирует PII и секреты на приёме и в выводе, выявляет спящие нагрузки и ведёт неизменяемый аудит операций извлечения.

Какие стандарты регулируют безопасность RAG?

Прежде всего OWASP LLM Top 10 2025 (категории LLM01, LLM02, LLM04, LLM08), MITRE ATLAS (техники инъекции и инверсии модели) и NIST AI 100-2e2025 по состязательному ML, где явно описаны отравление RAG-базы и косвенная инъекция. Для персональных данных применимы GDPR и ФЗ-152.

Источники

Связанные руководства: OWASP LLM Top 10 · Prompt Injection · Джейлбрейки LLM