Оценка безопасности RAG: как тестировать выборку, индекс и ответы модели

Возьмём выдуманную, но правдоподобную ситуацию. Юридическая фирма запускает внутреннего ассистента: он отвечает на вопросы сотрудников по базе договоров, регламентов и служебных записок и к каждому ответу прикладывает ссылки на источники. Пилот проходит гладко, юристы довольны точностью. Через месяц младший сотрудник спрашивает, как в фирме считаются бонусы, и получает вежливый, хорошо оформленный ответ с цитатой из закрытой записки партнёров о распределении прибыли.

Никто ничего не взламывал. Права на папку с запиской проверялись один раз, когда документ загружали в индекс. Позже сотрудника перевели в другую группу, исходные права поменялись, а ретривер в момент запроса права не сверял. Ассистент просто нашёл самый релевантный фрагмент и честно на него сослался.

Это иллюстрация, а не описание реального инцидента, но механизм в ней вполне реален для любой системы генерации с дополненной выборкой (retrieval-augmented generation, RAG). Такой продукт часто проверяют как «чат с моделью»: прогоняют опасные промпты, смотрят на отказы и считают работу сделанной. Между тем значительная часть риска живёт в потоке данных вокруг модели: кто пишет в индексируемые источники, как фильтруется выдача, где оседают ответы и что происходит с удалёнными документами. Ниже — как устроена оценка безопасности RAG, какие границы доверия в ней проверяются, как собирать доказательства и как выбрать глубину работ.

Что входит в оценку безопасности RAG

Оценка безопасности RAG — это санкционированная, структурированная проверка всего конвейера, а не только интерфейса чата. Система загружает документы, превращает их в пригодные для поиска представления — эмбеддинги в векторных схемах или другие формы при лексической и гибридной выборке, под каждый вопрос извлекает релевантные фрагменты, собирает из них промпт и возвращает ответ модели. Цель обычная: найти слабые места, убедиться, что защита работает как задумано, и выдать находки, которые можно исправить. Отличается поверхность атаки: недоверенный контент попадает в инструкции модели, а её ответ уходит на веб-страницы, в API и иногда в инструменты.

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

Исключать компоненты из охвата можно, но это должно быть осознанное и задокументированное решение. Если внешний поставщик обслуживает поисковое или векторное хранилище и оно не входит в работы, отчёт должен прямо сказать, что изоляция данных в нём не проверялась.

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

Методика: жизненный цикл, веб-слой и проверяемые требования

Рамку для планирования даёт NIST SP 800-115, Technical Guide to Information Security Testing and Assessment, опубликованный в сентябре 2008 года на смену SP 800-42. Он помогает планировать и проводить технические тесты, анализировать находки и вырабатывать стратегии устранения, разбирает техники с их преимуществами и ограничениями и прямо оговаривает, что не является исчерпывающей программой тестирования. Формально оценка по нему делится на фазы планирования, выполнения и пост-выполнения, куда входят анализ и рекомендации. Практический цикл «найти, исправить, перепроверить» — уже рабочая логика проекта, а не формулировка стандарта. Возраст документа не мешает: дисциплина планирования и согласования правил работ применима и к архитектурам, которых в 2008 году не было.

Для веб- и API-слоя RAG-продукта разумно зафиксировать методическую базу, например OWASP Web Security Testing Guide версии 4.2, а в качестве проверяемых требований — OWASP ASVS 5.0.0. Важно именно «выбрать и зафиксировать»: редакции меняются, и отчёт должен говорить, по какой из них велась проверка.

Поверх этой базы специалист формулирует цели, специфичные для RAG: авторизацию при выборке, сдерживание влияния извлечённого текста, обработку вывода и свежесть индекса. Для разговора с руководством результаты удобно переводить на язык NIST CSF 2.0, чтобы риски RAG можно было сравнивать с остальными рисками организации.

Ещё один полезный словарь — редакция OWASP Top 10 for LLM Applications 2026 года, выпущенная в августе 2026-го. Для RAG в ней ближе всего слабости векторных представлений и эмбеддингов, раскрытие скрытого контекста, промпт-инъекция и некорректная обработка вывода. Это перечень рисков для обсуждения охвата, а не сертификационная схема. Как строить проверку по нему, мы разбирали в статье про оценку по OWASP LLM Top 10.

Модель угроз: кто на самом деле пишет в контекст модели

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

Поэтому первая практическая задача — карта источников: кто может в них писать, как быстро изменения попадают в индекс и сохраняются ли исходные права. Именно здесь может выясниться, что «внутренняя база знаний» наполовину состоит из выгрузок тикетов, текст которых пишут внешние пользователи.

Для определения охвата удобно мыслить несколькими категориями угроз; это аналитическая модель, а не рейтинг распространённости. Косвенная промпт-инъекция — инструкции в извлечённых документах пытаются переопределить поведение системы. Обход авторизации при выборке — фрагменты достаются пользователям без прав на исходник. Отравление корпуса — подброшенный контент выигрывает выборку. Утечка чувствительных данных — секреты и персональные данные попадают в ответы, цитаты, журналы или кэши. Небезопасная обработка вывода — ответ отображается как HTML или уходит в команды без кодирования. Избыточные полномочия — инструменты запускаются по выводу модели без проверки прав.

Многие из этих угроз — старые уязвимости в новой форме: небезопасная обработка вывода оказывается межсайтовым скриптингом или инъекцией, обход авторизации при выборке — проблемой контроля доступа. Таблица ниже показывает, где проходят основные границы.

Авторизация при выборке и изоляция тенантов

Для систем, где документы разграничены по правам, это, как правило, центральная проверка: применяются ли права в момент запроса, а не только при загрузке? Ответ неочевиден даже самой команде, потому что права проходят через несколько слоёв: источник, коннектор, метаданные индекса, фильтр ретривера.

Методика строится на нескольких санкционированных учётных записях с разными правами и явно помеченных документах-маркерах в тестовом тенанте. Маркер содержит уникальную строку, которую нельзя получить иначе, чем из него самого. От имени каждой роли тестировщик задаёт вопросы, на которые маркер был бы идеальным ответом, и смотрит не только на текст, но и на цитаты, фрагменты, заголовки, пути к файлам, имена авторов и число результатов. Утечка через метаданные может быть столь же значимой, как утечка текста. Запрос повторяют в зафиксированных условиях: одна подтверждённая утечка доказывает возможность пути, но не его частоту, а один чистый запуск не доказывает эффективность контроля.

Где стоит фильтр и почему это важно

Фильтр прав можно применить до выборки, ограничив поиск доступными документами, или после неё, отбросив лишнее из найденного. Широкая выборка кандидатов с полной фильтрацией до сборки промпта и до формирования любых видимых пользователю метаданных сама по себе не является ошибкой авторизации. Ошибка возникает, когда фильтра нет или он срабатывает слишком поздно: тогда заголовки и счётчики закрытых документов могут просочиться наружу, а фрагменты — попасть в промпт или ответ. Даже корректный фильтр после первичной выборки может позволить недоступным кандидатам вытеснить доступные, поэтому отдельно проверяют качество выдачи и возможность отказа в обслуживании. Отдельная проблема — снимок прав, сделанный при индексации: права в источнике меняются, а индекс живёт по устаревшим правилам. Именно это показано в сценарии из начала статьи.

1. Документ закрыт в источникеПартнёр ограничивает доступ к записке, но снимок прав в метаданных индекса остаётся прежним
2. Запрос от другой ролиСотрудник задаёт вопрос, на который закрытый фрагмент является самым релевантным ответом
3. Выборка без сверки правРетривер опирается на устаревшие метаданные и возвращает фрагмент в первых результатах
4. Сборка промпта и ответФрагмент попадает в контекст, модель пересказывает его и прикладывает ссылку на источник
5. Кэш закрепляет утечкуОтвет сохраняется в кэше по тексту вопроса и выдаётся следующим пользователям

Мультитенантность

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

Если в вашей системе уже есть разграничение прав или несколько клиентов в одном индексе, с Pentest.red можно заранее обсудить состав тестовых ролей, тестовый тенант, набор документов-маркеров и то, какие доказательства понадобятся команде для исправления. Удобная отправная точка — описание охвата пентеста.

Косвенная инъекция и отравление корпуса

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

Результат таких тестов редко бывает бинарным: модель может проигнорировать одну формулировку и выполнить другую. Один подтверждённый «пробив» доказывает, что результат возможен в зафиксированных условиях, но не показывает его частоту. Приоритет всё равно определяется последствиями. Исказить формулировку ответа — одна степень риска; вызвать инструмент от имени пользователя или вывести данные из соседнего фрагмента — совсем другая.

Отравление корпуса проверяется с другой стороны: может ли автор с правом записи в источник добиться, чтобы его документ выигрывал выборку по важным запросам? Условный пример: на общем диске появляется документ, перенасыщенный словами «реквизиты для оплаты поставщику», и ассистент отвечает по нему, а не по регламенту. Проверяют права записи, видимость происхождения фрагмента и то, различает ли система источники разного доверия.

Защита здесь строится архитектурой, а не одним фильтром: извлечённый текст считается данными, источники разного доверия разделяются и помечаются, происхождение фрагмента видно пользователю. Изменение системного промпта снижает успех известных формулировок, но не устраняет класс риска.

Вывод модели, кэш и транспорт

Обработка вывода

Ответ модели — недоверенные данные для любого принимающего компонента. Отображённый как активный HTML без обработки под конкретный контекст, он может привести к межсайтовому скриптингу. Переданный в SQL, оболочку или API, он опасен, когда получатель интерпретирует его как синтаксис либо доверяет выбранной моделью операции без серверной валидации и авторизации; сам по себе вызов API ещё не является инъекцией. В ASVS 5.0.0, например, есть требование из раздела о предотвращении инъекций: защита от инъекции команд ОС за счёт параметризованных вызовов или контекстного кодирования вывода командной строки. Для RAG оно уместно везде, где ответ или фрагмент может дойти до интерпретатора. Предпочтителен специализированный безопасный API без оболочки; если запуск процесса неизбежен, фиксируют программу и опции и разрешают только допустимые аргументы, поскольку отдельный элемент argv сам по себе не устраняет инъекцию аргументов.

Отдельно стоит проверить отрисовку Markdown: если клиент сам загружает изображения по ссылкам из ответа, адрес картинки может унести фрагменты контекста. Помогает Content Security Policy — по описанию MDN, заголовок ответа, задающий, какие ресурсы может загружать клиент, и помогающий выявлять и смягчать межсайтовый скриптинг и инъекцию данных. Когда модель ещё и действует, полномочия инструментов становятся отдельной темой — см. статью про тестирование избыточных полномочий агентов.

Сессии, CORS и кэширование

HTTP на уровне протокола не хранит состояние между запросами, но cookie и серверные сессии — обычный и корректный способ его добавить. Когда ответы содержат данные конкретного пользователя, ключи кэша и заголовки ответа должны исключать межпользовательскую утечку; общий кэш допустим для одинаковых публичных данных при одинаковых условиях авторизации. CORS ограничивает чтение ответа браузерным скриптом с другого источника, но не заменяет аутентификацию или авторизацию API. Сессионные токены защищают, а серверные проверки доступа выполняют для каждого эндпоинта. Для SSE их тестируют вместе с CORS. WebSocket не использует CORS как механизм доступа: аутентификацию и авторизацию проверяют при и после обновления соединения, а заголовок Origin оценивают отдельно.

Особого внимания заслуживает кэш ответов на уровне приложения: если ключом служит только текст вопроса, а ответ зависит от прав пользователя или тенанта, кэш может выдать разрешённый ответ неавторизованному получателю. Общий результат допустим лишь для намеренно публичных или одинаково разрешённых данных, если ключ учитывает все значимые условия безопасности. Эти проверки опираются на WSTG, а приёмы проверки самого API описаны в материале про оценку безопасности REST API.

Загрузка, удаление и свежесть индекса

Конвейер загрузки — полноценная часть поверхности атаки. Парсеры PDF, офисных форматов, HTML и архивов обрабатывают недоверенные файлы: проверяется работа с повреждёнными файлами, обход каталогов при распаковке, извлечение скрытого текста, который не видит пользователь, но видит индекс. Учётные данные коннекторов — сервисные, и вопрос к ним не про MFA, а про область действия, хранение, ротацию и избыточность прав. Отдельно выясняют, кто может писать в индекс в обход источников.

Проверку, которую легко упустить из виду, — распространение удалений — стоит выделить отдельно. Документ, удалённый или закрытый в источнике, должен исчезнуть из ответов в пределах срока, который команда определила и записала. Тест: отозвать доступ к маркеру, выждать согласованное время и повторить запросы от разных ролей, проверяя также кэши ответов и эмбеддингов, производные сводки и копии индекса. Без заданного срока проверка теряет смысл: «когда-нибудь удалится» нельзя ни принять, ни опровергнуть.

Почему классический прикладной слой нельзя пропускать

Компоненты вокруг модели — обычное ПО: веб-интерфейсы, API, коннекторы, парсеры, консоли администрирования. MITRE характеризует слабости из перечня CWE Top 25 редакции 2025 года как часто легко обнаруживаемые и эксплуатируемые, способные вести к захвату системы, краже данных или нарушению работы, а инъекцию команд отмечает как особенно привлекательную для противника. При этом CWE описывает класс слабости, а не вероятность эксплуатации конкретной уязвимости.

Предупреждения CISA в рамках инициативы Secure by Design об устранении межсайтового скриптинга, инъекции команд ОС и обхода каталогов показывают, что одни и те же классы слабостей возникают снова и снова. Если оценка смотрит только на поведение модели, они остаются непроверенными, а ответ модели и извлечённый контент как раз открывают новые пути к старым интерпретаторам.

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

Компромиссы: доступ, недетерминированность и среда

Тестирование только через интерфейс чата воспроизводит взгляд внешнего пользователя, но тогда трудно понять, где возник сбой авторизации: в индексе, в фильтре прав или при сборке промпта. Доступ к схемам архитектуры и индекса и к логике сопоставления прав сокращает работу и повышает уверенность в выводах, что перекликается с акцентом NIST SP 800-115 на ограничениях каждой техники. Цена — больше подготовки со стороны заказчика.

Ответы модели меняются от запуска к запуску, поэтому единичный успешный или неуспешный тест может не обобщаться. Ключевые тесты нужно повторять, фиксируя версию модели, параметры генерации, конфигурацию ретривера и извлечённые фрагменты. Результат описывается как поведение, наблюдавшееся в заданных условиях, а не как гарантия.

Тестирование в продуктиве даёт реализм, но рискует загрязнить рабочий индекс или раскрыть реальные данные. Стенд с синтетическими или одобренными данными безопаснее, но его результаты нельзя без оговорок переносить на продуктив: синхронизация прав, источники и кэши там могут отличаться. Разумный компромисс — основная работа на стенде и ограниченное подтверждение ключевых находок в продуктиве по согласованным правилам. Любой тест, пишущий в индекс, требует документированного разрешения каждой стороны, уполномоченной согласовать работы для затронутых активов и сред, а также плана очистки.

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

Доказательства, повторная проверка и эксплуатация

Находки стоит привязывать к стабильным идентификаторам требований с указанием версии. ASVS рекомендует формат v{версия}-{глава}.{раздел}.{требование}, например v5.0.0-1.2.5, поскольку нумерация между версиями меняется. Привязку к ASVS или CWE имеет смысл делать только там, где требование действительно описывает найденную проблему; сама привязка не доказывает соответствие стандарту. Специфичные для RAG находки, для которых в ASVS нет подходящего требования, можно вести во внутреннем каталоге с тем же правилом версионирования.

Журналирование должно позволять восстановить, какие документы были извлечены для какого пользователя и какие инструменты вызывались, не превращаясь во вторую копию чувствительного корпуса: секреты маскируются, содержимое фрагментов минимизируется, доступ к журналам ограничивается, сроки хранения задаются осознанно. Руководство CISA Secure by Design говорит, что продукты должны быть безопасны по умолчанию, а многофакторная аутентификация, журналирование и единый вход — предоставляться без доплаты. При этом MFA относится к людям; для связей между сервисами конвейера нужны сервисные идентичности, короткоживущие токены и узкие области доступа.

Типовые меры устранения, которые мы рекомендуем рассмотреть: авторизация внутри ретривера, извлечённый текст как данные, кодирование вывода под контекст отображения, минимальные привилегии инструментов и подтверждение человеком для действий с высоким влиянием. Выводы повторной проверки относятся только к проверенным сценариям и условиям; как сделать её доказуемой, мы описывали в статье про проверку устранения уязвимостей после пентеста.

Глубина проверки: от пилота до агента

Глубина оценки должна соответствовать экспозиции и возможному ущербу. Градация ниже — наша практическая модель, а не схема из стандарта; она опирается на четыре вопроса: какие данные индексируются, кто отправляет запросы, кто создаёт индексируемый контент и что модель может делать помимо ответов.

Внутренний пилот

Публичные или малочувствительные документы, внутренние пользователи, никаких инструментов. Начните с ревью архитектуры, целевого тестирования веб/API и обработки вывода. Если недоверенные авторы могут влиять на корпус или ответ существенно влияет на решение, добавьте проверку косвенных промпт-инъекций: метки «внутренний» и «без инструментов» сами по себе не делают этот путь малорисковым.

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

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

Клиентские и мультитенантные системы

Если ассистентом пользуются клиенты, в индексе живут данные разных организаций или система индексирует внешний контент, нужна полная оценка: устойчивость к косвенным инъекциям, изоляция тенантов и кэширование, поведение браузера между источниками отдельно от серверной авторизации API, плюс автоматизация регрессионных тестов.

Системы, действующие через инструменты

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

Повторять оценку стоит при подключении нового источника, добавлении инструмента, смене поставщика модели или эмбеддингов, изменении модели прав и крупном обновлении интерфейса. Между оценками работают регрессионные тесты.

Как выбрать исполнителя для тестирования RAG

Руководство CISA Secure by Demand адресовано заказчикам ПО и рассчитано на переговоры с поставщиками при закупке. Его вопросы полезно задавать поставщикам RAG-продуктов, но независимую оценку вашей интеграции этот разговор не заменяет.

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

Осторожно относитесь к утверждениям, которые нельзя проверить: проприетарным оценкам риска без опубликованной методики, обещаниям «невзламываемости», статистике распространённости без данных. В рассмотренных нами стандартах сертификация именно для тестирования RAG не описана, поэтому уточняйте, что на самом деле покрывает заявленная квалификация. Пентест — это срез на момент проверки, а не сертификация или заключение о соответствии. Его отчёт может быть одним из источников доказательств для более широкой оценки соответствия, у которой отдельно определяются охват и квалифицированная принимающая сторона.

Если вы готовите такую закупку, с командой Pentest.red можно обсудить архитектуру вашей RAG-системы, состав компонентов в охвате, требования к стенду и форму доказательств в отчёте. Общий порядок работ описан на странице услуг по тестированию на проникновение, а исходные данные для обсуждения удобно собрать через форму описания охвата.

Итог

Оценку безопасности RAG стоит определять как проверку приложения с глубиной, зависящей от архитектуры, там, где недоверенный контент встречается с инструкциями модели: жизненный цикл даёт NIST SP 800-115, методику веб-слоя — WSTG, требования — ASVS в зафиксированной версии, приоритизацию прикладных слабостей — классы CWE, язык для руководства — NIST CSF 2.0.

В практической модели этой статьи приоритеты для RAG таковы: авторизация при выборке вместе со свежестью индекса, сдерживание инструкций в извлечённом контенте и безопасная обработка вывода. Любой результат — срез на момент проверки, который стоит подкреплять регрессионными тестами. Выбирайте исполнителей с прозрачной методикой, дисциплиной разрешений и версионированной отчётностью и тестируйте только с документированного разрешения каждой стороны, уполномоченной согласовать работы для затронутых активов и сред.