RAG с правами доступа: как не показать сотруднику документ, которого он не должен видеть
Практический разбор корпоративного FAQ-бота
Начальник смены на складе открывает корпоративного ИИ-ассистента и спрашивает:
> "Что делать, если водитель не успел с доставкой?"
Через несколько секунд система формирует понятный ответ и прикладывает ссылку на регламент логистических операций. Документ можно открыть или скачать.
Затем сотрудник вводит другой запрос:
> "Сколько компания платит перевозчикам за километр?"
Само по себе ничто не мешает ему задать этот вопрос. Критически важно другое: как поведёт себя система. Если тарифная таблица хранится в том же информационном контуре, что и общедоступный регламент, ассистент может найти соответствующий фрагмент, сформировать точный ответ и выдать ссылку на закрытый файл.
Именно здесь заканчивается задача семантического поиска и начинается задача информационной безопасности. Недостаточно научить модель находить релевантные сведения. Нужно гарантировать, что она использует только те данные, к которым конкретный пользователь имеет право доступа.
Что такое RAG и зачем он нужен
Большая языковая модель хорошо знает общие сведения, но обычно ничего не знает о внутренних процессах компании. Она не видела корпоративные инструкции, шаблоны договоров, отчёты об инцидентах и актуальные правила работы подразделений.
RAG, или Retrieval-Augmented Generation, решает эту проблему за счёт поиска по внутренним документам. Перед генерацией ответа система:
1. получает вопрос пользователя;
2. ищет наиболее подходящие фрагменты в корпоративной базе;
3. передаёт найденный контекст языковой модели;
4. формирует ответ на его основе;
5. при необходимости показывает источники.
Документы предварительно разбиваются на небольшие части - чанки. Для каждого фрагмента создаётся эмбеддинг: числовое представление смысла текста. Эти векторы сохраняются в базе данных. Когда пользователь задаёт вопрос, система превращает его в аналогичный вектор и находит близкие по смыслу фрагменты.
Поэтому запрос "водитель опоздал" способен найти раздел "Обработка прибытий не вовремя", даже если формулировки в вопросе и документе заметно различаются.
RAG применяют в логистике, банках, страховых компаниях, медицине, юридических фирмах, онлайн-образовании, HR и технической поддержке. Везде, где сотрудники регулярно ищут ответы в большом массиве PDF-файлов, инструкций и внутренних баз знаний, такой подход способен существенно ускорить работу.
Однако почти во всех этих сферах документы имеют разный уровень конфиденциальности. Помощнику юриста нельзя показывать материалы другой команды. Оператору поддержки нужны правила возврата, но не партнёрские комиссии. Сотруднику службы безопасности необходимы инструкции по закреплённым объектам, а отчёты о чужих уязвимостях должны оставаться закрытыми.
Почему обычный RAG может привести к утечке
Без дополнительной проверки RAG-система рассматривает документы прежде всего как набор смысловых фрагментов. Если закрытый файл похож на вопрос пользователя, поисковый механизм найдёт его независимо от должности и полномочий сотрудника.
Особенность проблемы в том, что границы доступа не всегда совпадают с границами файлов. Один справочник может быть предназначен для всех работников, но содержать отдельную главу о дисциплинарных мерах, зарплатных диапазонах или внутренних расследованиях. В итоге один документ рассчитан сразу на несколько аудиторий.
Нельзя считать защитой тот факт, что пользователь не знает точного названия файла. Семантический поиск как раз создан для того, чтобы находить нужный материал по косвенной формулировке.
Опасность усиливается тем, что ассистент не просто показывает найденный документ. Он пересказывает его простым языком, извлекает конкретные цифры и может приложить ссылку на исходный файл. Таким образом, сложная корпоративная система превращается в удобный интерфейс для поиска данных, к которым сотрудник не должен иметь доступа.
Схожая проблема получила название oversharing - избыточное предоставление доступа. ИИ в таком случае не обязательно создаёт новую уязвимость. Он делает старые ошибки в настройках разрешений быстрыми и заметными. То, что раньше требовало знания структуры папок и ручного просмотра, теперь обнаруживается одним естественным вопросом.
Базовый подход: разделение данных по ролям
Один из наиболее понятных вариантов защиты - организовать документы по ролям, подразделениям или уровням допуска. Например:
- `/public` - материалы, доступные всем сотрудникам;
- `/warehouse` - инструкции для складской логистики;
- `/finance` - финансовые документы;
- `/hr` - кадровая информация;
- `/security` - материалы службы безопасности;
- `/management` - документы для руководителей.
При загрузке файла в индекс система сохраняет не только его текст и эмбеддинг, но и метаданные:
- идентификатор документа;
- подразделение;
- роль или группа доступа;
- уровень конфиденциальности;
- срок действия разрешения;
- источник и версию файла.
Во время обработки запроса сервис сначала определяет пользователя и его права, а затем добавляет фильтр к поиску. В упрощённом виде логика выглядит так:
```text
найти фрагменты,
где смысл похож на вопрос
и metadata.access_group входит в группы пользователя
```
Если сотрудник склада спрашивает о тарифах перевозчиков, поиск должен выполняться только по разрешённым ему наборам данных. Закрытая финансовая таблица не должна попасть в список кандидатов.
Почему фильтрация после поиска ненадёжна
Нельзя сначала найти фрагменты по всей базе, передать их модели, а затем попытаться убрать запрещённые материалы. К этому моменту закрытый текст уже может оказаться в контексте языковой модели.
Даже если итоговый ответ не содержит прямой цитаты, модель способна:
- пересказать запрещённую информацию;
- вывести отдельные числа;
- сделать вывод на основе нескольких закрытых фрагментов;
- раскрыть название документа;
- упомянуть существование конфиденциального отчёта.
Поэтому контроль доступа должен работать до передачи данных в LLM. Правильный порядок выглядит так:
1. аутентифицировать пользователя;
2. определить его роли и разрешения;
3. сформировать поисковый фильтр;
4. выполнить поиск только среди разрешённых фрагментов;
5. передать результат модели;
6. повторно проверить ответ и ссылки перед выдачей.
Последняя проверка полезна как дополнительный барьер, но не должна заменять фильтрацию на этапе retrieval.
Чанк и документ: разные уровни разрешений
Если права назначены только на уровне файла, возникает проблема с документами, в которых смешаны открытые и закрытые сведения. Есть несколько вариантов решения.
Первый - разделять материал на отдельные документы. Общую инструкцию публикуют отдельно, а закрытую главу выносят в файл с другим уровнем доступа. Это самый простой для сопровождения вариант.
Второй - назначать метаданные каждому чанку. Тогда один файл может содержать фрагменты с разными правилами доступа. Такой подход гибче, но требует аккуратной обработки заголовков, таблиц и перекрёстных ссылок.
Третий - заранее удалять или маскировать конфиденциальные части перед индексацией. Метод снижает риск, но усложняет обновление материалов: при изменении исходного документа нужно корректно сформировать новую безопасную копию.
На практике часто используют комбинацию подходов: критичные разделы выносят в отдельные документы, а для остальных материалов применяют разрешения на уровне фрагментов.
Ссылка и кнопка "Скачать" - отдельный канал утечки
Даже если генерация ответа защищена, интерфейс может случайно открыть закрытый файл. Например, система корректно скрывает содержимое документа, но показывает кнопку "Скачать" с прямым URL.
Проблемы возникают, когда:
- ссылка формируется без повторной проверки прав;
- используются постоянные URL;
- файл доступен по угадываемому адресу;
- временная ссылка живёт слишком долго;
- права проверяются только на странице предпросмотра;
- API скачивания не знает, кто именно делает запрос.
Каждое действие должно проверять полномочия пользователя заново: просмотр, скачивание, экспорт, цитирование, открытие страницы источника и получение метаданных.
Для файлового доступа лучше применять короткоживущие подписанные ссылки, выдаваемые только после серверной проверки. Нельзя полагаться на скрытие кнопки в интерфейсе: клиентский код не является механизмом безопасности.
Другие модели изоляции
Разделение по папкам удобно для первого внедрения, но подходит не всем системам.
Можно создать отдельный индекс для каждого подразделения или уровня допуска. Тогда документы физически разделены, а запрос пользователя направляется только в разрешённый индекс. Такой вариант уменьшает риск случайного смешения данных, но усложняет обновление, мониторинг и управление большим числом индексов.
Другой путь - единый индекс с обязательными ACL-фильтрами. Он экономичнее и удобнее при масштабировании, однако требует строгой дисциплины в работе с метаданными. Ошибка при загрузке одного файла может привести к неправильной классификации сразу большого числа чанков.
Для наиболее чувствительной информации применяют физическую изоляцию: отдельные базы, проекты, ключи шифрования и сервисные аккаунты. Это дороже, зато снижает последствия ошибки в прикладной логике.
Как проверять защищённость RAG-системы
Тестирование должно включать не только обычные вопросы, но и попытки обойти ограничения. Для каждой роли формируют набор проверок:
- прямой запрос закрытого показателя;
- вопрос без ключевых слов из названия документа;
- просьба сравнить разрешённые и запрещённые данные;
- запрос на краткое резюме закрытого файла;
- попытка получить ссылку или экспорт;
- обращение к старой версии документа;
- запрос через другой язык или намеренно расплывчатую формулировку.
Нужно проверять не только текст ответа, но и весь технический результат: найденные чанки, идентификаторы документов, источники, журналы событий и сетевые запросы.
Полезно проводить негативные тесты автоматически при каждом изменении схемы прав, поискового сервиса или промпта. Контроль доступа нельзя считать разово реализованной функцией: роли, документы и бизнес-процессы постоянно меняются.
Что должно попасть в журнал аудита
Для расследования инцидентов необходимо фиксировать:
- идентификатор пользователя;
- его роль и группы на момент запроса;
- текст запроса;
- применённый фильтр доступа;
- список найденных фрагментов;
- документы, использованные моделью;
- показанные источники;
- операции просмотра, скачивания и экспорта;
- версию индекса и политики доступа.
При этом журналы сами могут содержать конфиденциальные сведения. Их следует защищать, ограничивать по сроку хранения и разделять права на просмотр технических событий и содержимого запросов.
Итоговая архитектура безопасного RAG
Надёжная система строится не вокруг одного промпта с инструкцией "не показывай секретные данные". Безопасность должна обеспечиваться несколькими независимыми слоями:
1. корректная аутентификация пользователя;
2. централизованное управление ролями и группами;
3. привязка прав к документам и чанкам;
4. фильтрация до векторного поиска или непосредственно в нём;
5. проверка источников и ссылок;
6. повторная авторизация при скачивании;
7. защита журналов и мониторинг подозрительных запросов;
8. регулярное тестирование сценариев обхода.
Главный принцип прост: модель не должна получать данные, которые пользователю запрещено видеть. Если закрытый фрагмент уже попал в контекст, рассчитывать только на послушание языковой модели поздно.
RAG действительно помогает быстро находить ответы в корпоративных документах. Но без сегрегации данных он превращает накопленные ошибки в правах доступа в удобный поисковик по конфиденциальной информации. Поэтому контроль разрешений нужно проектировать одновременно с индексированием, поиском и интерфейсом, а не добавлять после запуска.