Безопасность RAG: как защитить данные и снизить риск утечек

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

Содержание

Почему у RAG особый профиль риска

RAG, или Retrieval-Augmented Generation, — это подход, при котором языковая модель отвечает не только на основе своих параметров, но и на основе найденных во внешней базе знаний документов. Система одновременно работает с двумя слоями данных: пользовательским запросом и источниками, подключёнными к индексу — корпоративными документами, базами знаний, внутренними сервисами.

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

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

Где именно возникают утечки в RAG-системе

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

Если документ загружается без корректных метаданных доступа, система может считать его доступным всем. Если фильтрация по правам выполняется не в момент retrieval, а уже после, часть закрытых данных успевает попасть во внутренние логики и сервисы.

Отдельный риск связан с журналами и системой наблюдаемости. В логи могут уходить исходные запросы, найденные фрагменты, системные подсказки, ответы модели, служебные токены. При использовании внешних платформ логирования или APM-систем такие данные выходят за пределы основного контура безопасности.

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

Какие угрозы для RAG считаются основными

Для RAG особенно опасны промпт-инъекции, ошибки разграничения доступа, избыточная передача контекста, атаки на векторные хранилища и утечки через вспомогательные сервисы. Эти угрозы затрагивают не только модель, но и весь слой данных вокруг неё.

Промпт-инъекции и обход ограничений

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

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

Ошибки авторизации на уровне документов

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

Особенно уязвимы схемы, где контроль доступа реализован только в интерфейсе: UI скрывает лишнее, но сервер уже отдал конфиденциальные документы или чанки в retrieval-слой. Надёжная модель требует серверной авторизации и фильтрации результатов поиска по атрибутам доступа и контексту запроса.

Утечка через контекст и ответы модели

Даже корректно найденный документ может содержать лишние поля: персональные данные, коммерческие тайны, служебные комментарии, технические идентификаторы. Если весь фрагмент без отбора уходит в модель, риск раскрытия существенно возрастает.

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

Риски векторных хранилищ и метаданных

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

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

Какие меры защиты обязательны в рабочем RAG-контуре

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

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

Проверяйте права до поиска. Фильтрация по ролям и атрибутам доступа должна работать на этапе retrieval, чтобы закрытые документы и чанки не попадали ни в контекст, ни в логи.
Ограничивайте объём контекста. Передавайте в модель только релевантные фрагменты, а не целые документы и не чрезмерное количество чанков.
Разделяйте хранилища. Исходные документы, эмбеддинги, индексы и журналы запросов лучше держать в отдельных контурах с различными политиками доступа.
Шифруйте данные в канале передачи и в хранилищах, включая векторные базы, индексы и бэкапы.
Сокращайте логирование. В журналах должны храниться идентификаторы и служебные атрибуты, а не полный текст чувствительных данных.
Контролируйте внешние API. Перед отправкой данных во внешнюю модель или сервис нужно явно понимать, какие поля и в каком объёме покидают ваш контур.
Не используйте рабочие данные для дообучения без отдельного решения. Включайте в контракты запрет на использование конфиденциальных документов в качестве обучающей выборки и при необходимости применяйте обезличивание.

Как выстроить безопасную архитектуру RAG

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

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

Если используется внешняя LLM или векторное хранилище, маршрут данных до провайдера и обратно должен быть явно описан. Важно понимать, уходят ли во внешний сервис полные документы, короткие выдержки, метаданные, идентификаторы пользователей, токены доступа и содержимое диагностических логов.

Слой	Что защищать	Базовая мера
Загрузка данных	исходные документы, классы чувствительности и метаданные доступа	классификация данных, DLP-проверки и маркировка прав доступа перед индексацией
Хранилище	эмбеддинги, документы, индексы, бэкапы	изоляция окружений, шифрование, разделение ролей и ограничение сетевого доступа
Поиск	результаты retrieval и список релевантных чанков	серверная фильтрация по атрибутам доступа и контексту запроса
Генерация	контекст и ответ модели	ограничение объёма контекста, защита от промпт-инъекций и проверка вывода
Наблюдаемость	логи, трассировки, метрики, отладочная информация	редакция чувствительных данных, шифрование журналов, контроль сроков хранения и доступа

Как настроить контроль доступа в RAG

Контроль доступа в RAG должен применяться одновременно к пользователю, документу и фрагменту (чанку), а также учитывать контекст запроса. Проверки только по роли пользователя чаще всего недостаточно для реальных корпоративных сценариев.

На практике комбинируют RBAC, где доступ задаётся через роли, и ABAC, где решение зависит от набора атрибутов: владельца документа, подразделения, проекта, уровня чувствительности, географии, срока действия, статуса документа. Для RAG модель на основе атрибутов обычно точнее, потому что данные и пользователи плохо укладываются в несколько жёстких ролей.

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

Как уменьшить риск утечки через промпты и ответы модели

Полностью исключить промпт-инъекции нельзя, но риск можно существенно снизить. Для этого нужно ограничить влияние пользовательского запроса на правила доступа и проверять как входные данные, так и вывод модели.

Базовый принцип: модель не должна сама решать, кому что показывать. Она должна получать уже отфильтрованный контекст, сформированный с учётом политик доступа. Тогда даже агрессивные или специально сформированные запросы не дадут доступ к документам вне установленной политики.

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

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

Как работать с логами, трассировкой и мониторингом

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

Безопасная схема логирования обычно сводится к фиксации факта обращения, идентификатора пользователя или сервиса, идентификаторов документов и чанков, технического статуса и времени операции. Тексты запросов и фрагменты документов лучше не сохранять или хранить в отдельном сильно ограниченном контуре с шифрованием, жёсткими правами доступа и понятным сроком хранения.

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

Пошаговый план внедрения безопасного RAG

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

Опишите источники данных: какие типы документов индексируются, кто их загружает, каков уровень чувствительности и сроки актуальности.
Добавьте метаданные доступа: владелец, роль, группа, проект, уровень и тип чувствительности, срок действия, область применения.
Проверьте retrieval-слой: поиск должен учитывать политику доступа до передачи результатов дальше, включая фильтрацию по атрибутам и контексту запроса.
Ограничьте контекст: уменьшите число документов и длину фрагментов, которые передаются в модель, и избегайте попадания в контекст необязательных чувствительных полей.
Настройте безопасные логи: уберите из журналов полный текст документов и запросов там, где это не критично, включите шифрование и определите сроки хранения.
Пересмотрите внешние интеграции: API моделей, векторные SaaS-сервисы, трассинг, аналитика, кэш, очереди сообщений, системы A/B‑тестирования.
Проведите проверку сценариев утечки: попытки обхода ролей, промпт-инъекции, массовые запросы, утечки через перефразирование, повторное извлечение чувствительных фрагментов.
Организуйте регулярное тестирование: автоматические проверки, DLP-правила, secret scanning, ревизию конфигураций доступа и сценариев эксплуатации.

Какие ошибки встречаются чаще всего

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

Фильтрация только в интерфейсе. Пользователь не видит лишнее на экране, но сервер и внешние сервисы уже получили закрытые документы или чанки.
Отсутствие метаданных доступа. Векторный поиск работает, а политика безопасности не может применяться на уровне документов и фрагментов.
Слишком широкий контекст. В модель передаются целые документы или большой пул чанков, что увеличивает вероятность случайного раскрытия данных.
Полные логи запросов и ответов. Служебная инфраструктура аккумулирует чувствительные данные без отдельного контроля и регламента хранения.
Слепое доверие внешней LLM. Данные отправляются наружу без анализа маршрута, условий обработки, сроков хранения и режима обучения моделей провайдера.
Отсутствие отдельной политики для эмбеддингов. Векторная база считается «обезличенной», хотя эмбеддинги могут использоваться для восстановления исходного текста.

Когда особенно нужна изоляция и локальное размещение

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

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

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

Короткие ответы на частые вопросы

Можно ли доверить контроль доступа самой модели

Нет. Контроль доступа должен работать до модели и независимо от неё. LLM получает только уже отфильтрованный контекст и не решает, какие документы разрешено показывать пользователю.

Достаточно ли скрыть чувствительные поля в интерфейсе

Недостаточно. Если закрытые данные уже попали в retrieval, контекст, векторную базу или логи, риск утечки сохраняется независимо от того, отображаются ли они на экране.

Нужно ли шифровать векторную базу

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

Помогает ли сокращение контекста

Да. Чем меньше и точнее подобраны фрагменты, которые получает модель, тем ниже вероятность случайного раскрытия лишних данных и тем проще внедрять автоматические проверки ответа.

Можно ли использовать RAG с публичными моделями

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

Что проверить перед запуском RAG в рабочую среду

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

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

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