Корпоративный RAG-поиск: как разграничить доступ к документам

Почему вход сотрудника в чат не защищает каждый документ?

Нужны две независимые границы: кто вошёл и какие ресурсы интерфейса ему доступны, затем какие конкретные документы и фрагменты допускается отдать на запрос. Open WebUI позволяет назначать Private Knowledge Bases отдельным пользователям и группам с правами чтения или записи; членства в группах объединяются, явного правила deny нет s1. Это контроль ресурса Knowledge Base. Он не заменяет документную ACL исходной ERP, файлового сервера или хранилища, особенно если в одну базу загрузили документы с разными владельцами. Последнее — архитектурный вывод, а не обещание встроенного механизма Open WebUI: OWASP отдельно предупреждает об утечках через retrieval при смешении уровней доступа s8.

Представьте вымышленные файлы handbook-public.txt, sales-private.txt и finance-private.txt. Роль A видит общий документ и продажи, роль B — общий документ и финансы. При поиске A фрагмент finance-private.txt не должен попадать даже во внутренний список кандидатов, возвращённых приложению для генерации; отказ самой модели пересказать его после получения не засчитывается как контроль доступа. После снятия роли A с продаж повторный запрос не должен возвращать sales-private.txt из старой подборки, отдельного чата, цитаты или кеша. Это критерии будущего теста, а не утверждение о свойствах конкретного продукта.

Как выбрать стек под разные уровни секретности?

Для первого небольшого пилота используйте локальный runtime Ollama как кандидат для текстовой модели, Open WebUI как интерфейс и раздельные Private Knowledge Bases для наборов с одинаковой политикой доступа. В настройке Open WebUI можно привязать базу к модели; при Native function calling содержимое прикреплённой базы не вставляется само собой — модель должна вызвать встроенные knowledge tools. Focused Retrieval достаёт фрагменты, Full Context может передать весь документ, поэтому тестируйте оба режима отдельно и не прикрепляйте широкую базу ради удобства s2. Проверяйте именно выбранный локальный embedding/extraction/model provider: Open WebUI прямо указывает, что место обработки документа зависит от этих поставщиков s2. Одна локальная текстовая модель не доказывает локальность всего конвейера; сетевую проверку проведите до работы с внутренними файлами.

Если требования к доступу различаются между файлами одной базы, схема «пользователь вошёл в интерфейс, значит доступ есть ко всему» неприемлема. Есть два проектных пути: разделить документы на базы/коллекции по одинаковой политике и дать только нужные гранты либо поставить доверенный retrieval-сервис, который перед каждым поиском вычисляет разрешённые document_id по ACL источника и применяет серверный фильтр до передачи фрагментов модели. Это варианты архитектуры пилота, не заявление о том, что Open WebUI автоматически синхронизирует права файловой системы с Qdrant. При необходимости Qdrant поддерживает payload-фильтр с must (AND) и индексацию полей; group_id с is_tenant: true помогает организации/размещению данных, но сама метка не удостоверяет личность и не отменяет проверку доступа s5s7. Для документа, у которого отсутствует проверенная метка/ACL, правило проекта — не включать его в выдачу.

Самостоятельно развёрнутый Qdrant требует отдельной сетевой защиты: по документации доступный сетевой интерфейс без настроенной аутентификации принимает запросы; поставщик рекомендует API key, приватную привязку и TLS s6. Ключ администратора в клиентском браузере разрушил бы границу доступа. Даже грант Qdrant на чтение коллекции не равен разрешению видеть каждый файл внутри коллекции — проверку документа реализует и тестирует приложение. Если компания не может обеспечить эту границу и журнал изменений ACL, остановитесь на раздельных хранилищах с простой и проверяемой схемой прав.

Какие данные нужны до индексации?

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

Отдельно опишите, кто может загружать файлы, делиться базами и создавать инструменты. Open WebUI показывает эффективный доступ пользователя и группы через Preview Access; владелец ресурса сохраняет доступ, а администратор по умолчанию может обойти проверку для части объектов при включённом BYPASS_ADMIN_ACCESS_CONTROL s1. Поэтому тест только двух обычных ролей не покрывает учётные записи администраторов и владельцев. Право создавать/import Workspace Tools выдавайте только доверенным администраторам: это выполнение Python-кода на сервере по документации продукта s3. Экспозиция приложения и параметры входа — отдельная зона ответственности эксплуатирующей организации, что подчёркивает руководство по hardening s4. Гайд по LDAP/SSO помогает настроить вход и группы, но не заменяет эту проверку документных прав.

Как провести проверку под двумя ролями и после отзыва прав?

1. До запроса создайте три синтетических файла с уникальными маркерами, две обычные учётные записи и матрицу разрешений: общий файл — обеим, sales-private — только A, finance-private — только B. Запишите ожидаемые разрешённые document_id. Не загружайте клиентские документы для первого прогона.
2. После индексации задайте одинаковые точные и смысловые вопросы под A и B. Сохраните не только финальный ответ с цитатами, но и отладочную выдачу retrieval: document_id, роль, применённый фильтр, время и версия ACL. Ни одного запрещённого ID не должно быть в подборке, Full Context или доступном пользователю прямом чтении файла. OWASP указывает именно на риск утечки при пересечении наборов с разными правами s8.
3. Проверьте отзыв и отказ: удалите грант роли A, дождитесь предусмотренного вашей системой обновления ACL, повторите старый вопрос в новом и существующем диалогах, прямое обращение по ID и поиск по точному маркеру. Отдельно проверьте неизвестную роль и файл без ACL: ожидаемый результат — пустая выдача, а не автоматическое разрешение. Срок обновления прав надо задать в протоколе вашей системы; у этой статьи нет измеренного SLA.
4. Сверьте обоснованность разрешённых ответов с оригиналом и проверьте, что модель не придумала источник. Пустая выдача должна вести к честному «нет доступного подтверждения», а не к догадке. Для протокола качества используйте проверку RAG по вопросам и цитатам. Разграничение доступа и качество ответа — два отдельных условия успеха.

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

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