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

Источник: https://modelium.tech/zhurnal/korporativnyy-poisk-prava-dostupa/

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

**Источники просмотрены 26 сентября 2026 года.** Это проект проверки, не готовая защищённая система. Частотность запроса не измерялась. Тестовые роли и файлы ниже вымышлены; права на реальные документы определяет владелец источника данных.

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

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

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

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

Для первого небольшого пилота используйте [локальный runtime Ollama](/zapusk/ollama/) как кандидат для текстовой модели, [Open WebUI](/zhurnal/open-webui/) как интерфейс и раздельные Private Knowledge Bases для наборов с **одинаковой** политикой доступа. В настройке Open WebUI можно привязать базу к модели; при Native function calling содержимое прикреплённой базы не вставляется само собой — модель должна вызвать встроенные knowledge tools. Focused Retrieval достаёт фрагменты, Full Context может передать весь документ, поэтому тестируйте оба режима отдельно и не прикрепляйте широкую базу ради удобства [s2](#src-s2). Проверяйте именно выбранный локальный embedding/extraction/model provider: Open WebUI прямо указывает, что место обработки документа зависит от этих поставщиков [s2](#src-s2). Одна локальная текстовая модель не доказывает локальность всего конвейера; [сетевую проверку](/zhurnal/proverka-offline-kontura-ii/) проведите до работы с внутренними файлами.

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

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

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

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

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

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

- **До запроса** создайте три *синтетических* файла с уникальными маркерами, две обычные учётные записи и матрицу разрешений: общий файл — обеим, `sales-private` — только A, `finance-private` — только B. Запишите ожидаемые разрешённые `document_id`. Не загружайте клиентские документы для первого прогона.

- **После индексации** задайте одинаковые точные и смысловые вопросы под A и B. Сохраните не только финальный ответ с цитатами, но и отладочную выдачу retrieval: `document_id`, роль, применённый фильтр, время и версия ACL. Ни одного запрещённого ID не должно быть в подборке, Full Context или доступном пользователю прямом чтении файла. OWASP указывает именно на риск утечки при пересечении наборов с разными правами [s8](#src-s8).

- **Проверьте отзыв и отказ**: удалите грант роли A, дождитесь предусмотренного вашей системой обновления ACL, повторите старый вопрос в новом и существующем диалогах, прямое обращение по ID и поиск по точному маркеру. Отдельно проверьте неизвестную роль и файл без ACL: ожидаемый результат — пустая выдача, а не автоматическое разрешение. Срок обновления прав надо задать в протоколе вашей системы; у этой статьи нет измеренного SLA.

- **Сверьте обоснованность** разрешённых ответов с оригиналом и проверьте, что модель не придумала источник. Пустая выдача должна вести к честному «нет доступного подтверждения», а не к догадке. Для протокола качества используйте [проверку RAG по вопросам и цитатам](/zhurnal/ocenka-kachestva-rag/). Разграничение доступа и качество ответа — два отдельных условия успеха.

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

**Следующий шаг:** [составьте набор вопросов и протокол проверки RAG](/zhurnal/ocenka-kachestva-rag/) для трёх синтетических файлов. Не подключайте реальные корпоративные документы, пока запрещённый `document_id` не исключён из retrieval под каждой ролью и после отзыва гранта.

## Источники

1. [Open WebUI — Groups and Resource Access (RBAC)](https://docs.openwebui.com/features/authentication-access/rbac/groups.md) — получено 2026-09-26
2. [Open WebUI — Knowledge Bases and Document Chat](https://docs.openwebui.com/features/workspace/knowledge.md) — получено 2026-09-26
3. [Open WebUI — Tools and Native Features](https://docs.openwebui.com/features/extensibility/plugin/tools.md) — получено 2026-09-26
4. [Open WebUI — Hardening](https://docs.openwebui.com/getting-started/advanced-topics/hardening.md) — получено 2026-09-26
5. [Qdrant — Multitenancy](https://qdrant.tech/documentation/manage-data/multitenancy/) — получено 2026-09-26
6. [Qdrant — Security](https://qdrant.tech/documentation/security/) — получено 2026-09-26
7. [Qdrant — Filtering](https://qdrant.tech/documentation/concepts/filtering/) — получено 2026-09-26
8. [OWASP LLM08 — Vector and Embedding Weaknesses](https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/) — получено 2026-09-26