RAG с правами доступа: как не показать сотруднику документ, которого он не должен видеть
Корпоративные системы на базе технологий Retrieval-Augmented Generation (RAG) позволяют сотрудникам быстро находить ответы в внутренних документах. Однако стандартный подход к поиску создает риски избыточного раскрытия информации, когда система отдает доступ к конфиденциальным данным всем пользователям, имеющим технический доступ к базе. В этой статье рассмотрен практический подход к решению проблемы контроля доступа на уровне ролей, реализуемый через изоляцию данных в векторных хранилищах.
# RAG с правами доступа: как не показать сотруднику документ, которого он не должен видеть
Семантический поиск и большие языковые модели революционизировали работу с корпоративными знаниями. Сотрудники получают мгновенные ответы на вопросы о регламентах, тарифах и процедурах. Но существует серьезная уязвимость: если файл с тайной тарифной сеткой лежит в той же базе данных, что и открытый регламент, ассистент может ответить на вопрос о зарплатах и приложить ссылку на скачивание документа.
Проблема заключается в том, что языковые модели нельзя «запретить» говорить. Если запрещенный контент попал в контекстное окно, модель сгенерирует на его основе ответ. Безопасен только тот документ, который физически не был извлечен поисковой системой для передачи в модель.
Архитектура изоляции данных
Технология RAG (Retrieval-Augmented Generation) работает по принципу векторного поиска. Документы разбиваются на фрагменты, каждый из которых превращается в набор чисел — эмбеддинг. Когда приходит запрос, система ищет в векторной базе наиболее похожие фрагменты и передает их модели для генерации ответа.
Обычно векторная база данных хранит все документы организации в едином пространстве. Для реализации контроля доступа авторитарные подходы в разработке предлагают физическую или логическую изоляцию данных. Один из наиболее понятных методов — разделение данных на коллекции (папки) в зависимости от роли сотрудника.
В описанной системе каждое подразделение (например, поддержка или руководство) имеет свою собственную коллекцию векторных индексов. Когда администратор создает индекс для роли «менеджмент», система обходит только файлы, предназначенные для этой группы. Файлы из папки «поддержка» в этот момент не читаются и не векторизируются. Таким образом, в момент запроса от сотрудника службы поддержки к базе данных «менеджмента» физически не существует ни одного файла, который он мог бы найти.
Механизм работы системы
Процесс взаимодействия пользователя с системой включает несколько строгих шагов, обеспечивающих безопасность:
1. Авторизация: При входе пользователь получает токен, содержащий его уникальный идентификатор и роль. Этот токен служит неизменяемым маркером доступа. 2. Определение коллекции: Сервер сверяет роль пользователя с конфигурацией. Если у сотрудника роль «поддержка», сервер формирует запрос исключительно к коллекций support. Данные для других ролей для этого запроса не существуют. 3. Поиск: Инструмент агентного поиска ищет эмбеддинги только внутри разрешенной коллекции. Даже если в модели есть запросы о «зарплатах», в контексте текущего пользователя таких данных нет. 4. Генерация ответа: Модель создает ответ на основе найденных, отфильтрованных фрагментов.
Этот подход позволяет реализовать принцип «нулевого знания» (zero-knowledge) для модели относительно неавторизованных данных. Она просто не видит их.
Безопасность каналов передачи данных
Несмотря на надежный поиск, существует еще одна точка выхода для утечки информации — кнопка скачивания файлов в интерфейсе источника. Если ссылка на документ формируется статически (например, /files/salary-bands.pdf), любой пользователь, обладающий правами на чтение веб-сервера или умеющий подобрать правильный URL, может скачать файл, минуя логику RAG.
Для защиты этого канала применяется строгая аутентификация и валидация путей:
* Проверка токена: Запрос к эндпоинту скачивания требует валидацию того же JWT-токена, что и чат. Без токена доступ запрещен. * Изоляция по коллекциям: Сервер пересчитывает права пользователя заново. Даже если атакующий попытается угадать путь к файлу «менеджмента», сервер определит, что данная роль не имеет доступа к этой коллекции, и вернет ошибку 404. * Экранирование путей: Имена файлов и запросы к путям проверяются на наличие попыток выхода за корень (..) или использования абсолютных путей. Любая попытка обойти проверку отклоняется.
Возвращение кода 404 (Not Found) вместо 403 (Forbidden) также является важным элементом безопасности. Ответ 403 мог бы подсказать злоумышленнику, что файл действительно существует, но доступ к нему закрыт. 404 скрывает факт наличия ресурса, делая атаку методом перебора неэффективной.
Сопоставимость и масштабируемость
Использование папок и коллекций обладает рядом преимуществ для большинства предприятий. Границы доступа интуитивно понятны для руководителей, так как они совпадают с привычной иерархией файлового менеджера (папки в Google Drive или SharePoint). Владельцы бизнеса могут управлять правами, просто перетаскивая файлы в нужные каталоги, а не настраивая сложные правила на уровне кода.
Однако у этого подхода есть ограничения. Документ, который необходим трем разным ролям, должен физически существовать в трех разных папках. Это создает избыточность данных и требует поддержания консистентности копий при редактировании. Кроме того, в крупных организациях с тысячами пересекающихся групп и сложных ролевых матриц жесткое разделение папок может быть слишком ригидным. В таких случаях могут потребоваться более гибкие методы, такие как фильтрация по метаданным внутри единого индекса или использование систем управления доступом на основе отношений (RBAC) с проверкой прав в момент запроса.
Заключение
RAG-ассистенты заслуживают доверия лишь постольку, поскольку защищены слабое место в их архитектуре. Выбор модели разграничения доступа должен базироваться на простоте объяснения и надежности реализации. Ключевой принцип, который необходимо внедрить: данные должны фильтроваться и изолироваться еще до того, как они попадут в контекст языковой модели. Более того, эта проверка должна повторяться на каждом этапе, через который данные покидают систему — будь то фрагмент ответа в чате или ссылка на скачивание исходного файла.
Реализация через изоляцию коллекций по ролям доказала свою эффективность как баланс между безопасностью и простотой управления. Она позволяет превратить RAG из инструмента, способного стать вектором утечки, в надежный канал передачи только той информации, которую сотрудник имеет право знать.