1. Главная
  2. Docs
  3. Глоссарий
  4. Разграничение доступа

Разграничение доступа

7

Разграничение доступа в системе, отвечающей по документам, — это фильтрация на этапе поиска: пользователь получает ответ только по тем материалам, которые ему разрешено видеть.

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

Почему это нельзя решить промптом

Инструкция «не показывай сотрудникам отдела продаж кадровые документы» не работает: если фрагмент попал в контекст, модель уже его прочитала и способна пересказать содержание, даже отказавшись цитировать. Давление формулировкой — от джейлбрейка до простого «перескажи своими словами» — снимает и остатки дисциплины.

Единственный надёжный способ — не допустить фрагмент в контекст. Фильтр применяется на поиске, до передачи модели.

Фильтрация во время поиска, а не после

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

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

Побочный эффект жёсткой фильтрации: для пользователя с узкими правами система чаще отвечает «не нашлось». Это не дефект, а честное поведение, но его надо объяснить заказчику заранее.

Уровень разграничения: документ, раздел, строка

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

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

Строка или запись. Для справочников и баз: права на уровне записи или даже поля — в HR-справнике ФИО видны всем, оклад — узкому кругу. Источник прав — те же правила уровня строк, что действуют в исходной базе; дублировать их вручную нельзя.

Уровень выбирают по самому чувствительному материалу из тех, что попадут в систему: он определит архитектуру, и добавить более тонкую гранулярность после запуска дороже, чем заложить сразу.

Как устроить

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

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

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

Агентные системы и сервисные учётки

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

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

Что проверить

Завести тестовых пользователей с разными правами и набор вопросов, ответы на которые лежат в закрытых для них документах. Правильное поведение — «не нашлось», а не пересказ.

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

Проверить журналы: не пишется ли туда содержимое фрагментов, доступное затем всем, у кого есть доступ к логам.

Проверить, что происходит после увольнения или смены роли: остаётся ли доступ.

Типовые схемы

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

По уровням. Общедоступное, для сотрудников, для руководителей. Легко объяснить и легко поддерживать, но плохо описывает случаи вроде «только участники проекта».

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

Что происходит при изменении прав

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

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

Отдельно стоит продумать увольнение: доступ должен исчезать вместе с учётной записью, а не ждать следующей переиндексации.

Чем платим за разграничение

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

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

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

Частые вопросы

Можно ли ограничить доступ инструкцией модели?

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

Почему важно фильтровать во время поиска, а не после?

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

Откуда брать права доступа?

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

Нужно ли разграничение, если системой пользуются только сотрудники?

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

Как выбрать уровень: документ или фрагмент?

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

Как часто сверять права в индексе с источником?

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

Что почитать по теме