К содержимому
RU
Запросить доступ
Разделы документацииБиблиотека
Статус доступа
БИБЛИОТЕКА ЗАЩИТЫ ИИ

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

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

Часть серии: 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-сканирование вывода; контроль аномалий в паттернах извлечения.

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

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

Если столбцы не помещаются, прокрутите таблицу по горизонтали.

Угроза RAG (OWASP)Движки SpectornРубеж
LLM04 Data Poisoningdormant_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. Spectorn не заменяет контроль доступа к векторной БД — он дополняет его сканированием контента, обнаружением PII/секретов и хеш-связанным аудитом операций.

🛠️ Настройка политики

Файла конфигурации, который нужно развернуть, нет: политику вашего тенанта по запросу задаёт оператор платформы, включая режим проверки (блокировка или наблюдение, при котором видно, что было бы заблокировано), списки разрешений и запретов, порог блокировки и веса категорий. Для этой отрасли важнее всего движки: injection, pii, exfiltration, dormant_payload. Начните с режима наблюдения на своём трафике, посмотрите, что было бы заблокировано, и затем включите блокировку. Маскирование персональных данных в облачных контурах не включено: запрос с персональными данными блокируется или отмечается, а не переписывается.

🚨 Корреляция в вашей SIEM

Spectorn отправляет каждую находку в указанную вами SIEM как JSON-событие по HTTPS (spectorn.ai-finding.v1) с правилом, категорией, серьёзностью и verdict_id. Многошаговые правила для этой отрасли стройте там. Собственная корреляция SOC в Spectorn (GoMCP) в облачных контурах RU и Global не развёрнута.

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

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

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

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

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

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

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

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

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

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

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

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

Нет. Межтенантная изоляция, RBAC/ABAC и шифрование векторного хранилища остаются на стороне приложения и инфраструктуры RAG. Spectorn дополняет их: сканирует контент на инъекции, находит 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

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