← На главную

При настройке прав доступа на уровне записей (Record Level Security, RLS) разработчики и администраторы часто сталкиваются с неожиданным поведением: пользователю назначена роль с ограничением доступа к справочнику, но он продолжает видеть абсолютно все элементы. Разберем по шагам, почему так происходит, как платформа 1С:Предприятие объединяет условия доступа и как грамотно выстроить систему ролей.

Принцип объединения прав и условий RLS на уровне платформы

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

Рассмотрим, что происходит с условиями RLS при назначении двух ролей на один и тот же объект:

1. Объединение через логическое ИЛИ: Условия ограничения доступа из всех назначенных пользователю ролей объединяются оператором ИЛИ. Итоговый SQL-запрос к СУБД содержит конструкцию вида УсловиеРоли1 ИЛИ УсловиеРоли2.
2. Роль без ограничения дает ИСТИНА: Если одна из ролей предоставляет доступ на чтение объекта без RLS (то есть условие доступа эквивалентно ИСТИНА), то итоговое логическое выражение всегда принимает значение ИСТИНА (УсловиеRLS ИЛИ ИСТИНА = ИСТИНА). В результате ограничение RLS полностью нивелируется, и пользователь получает доступ ко всем данным.

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

Ограничение по полям и поведение в привилегированном режиме

Разберем дополнительные особенности платформенного RLS, которые важно учитывать при проектировании:

1. Ограничение на уровне отдельных полей: В 1С можно настроить RLS не только на чтение всей записи, но и на отдельные реквизиты. В этом случае пользователь видит сам объект в списке, но запрещенные реквизиты возвращаются как NULL (или пустые значения в формах).
2. Привилегированный режим: Любой программный код, выполняемый внутри привилегированного общего модуля или в блоке УстановитьПривилегированныйРежим(Истина), полностью игнорирует RLS. Это позволяет выполнять регламентные процедуры и системные алгоритмы без ошибок прав доступа.

Архитектура ролей: атомарный подход против монолитного

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

В стандартах разработки 1С рекомендуется придерживаться атомарного (гранулярного) подхода:

1. Разделение чтения и изменения: Для каждого ключевого объекта метаданных создаются отдельные атомарные роли, например ЧтениеНоменклатуры и ИзменениеНоменклатуры.
2. Изоляция ролей с RLS: Роли, содержащие шаблоны ограничений (например, ЧтениеНоменклатурыСОграничением), должны существовать отдельно от базовых ролей с полным доступом. Пользователю назначается либо роль с RLS, либо роль с полным доступом, но ни в коем случае не обе одновременно.
3. Составные профили групп доступа: Пользователям назначаются не роли напрямую, а профили и группы доступа, которые комбинируют нужные атомарные роли в единый функциональный набор (например, «Менеджер по продажам», «Кладовщик»).

Реализация ограничений в типовых конфигурациях (БСП)

В типовых решениях («1С:ERP», «1С:Управление торговлей», «1С:Комплексная автоматизация» и др.) управление доступом реализовано через подсистему БСП «Управление доступом». Разберем, как устроена логика в них:

1. Ограничения по одному виду доступа: Если пользователю назначено несколько групп доступа с ограничениями по одному виду (например, по «Видам номенклатуры»), они объединяются по правилу ИЛИ (доступ расширяется).
2. Ограничения по разным видам доступа: Если заданы ограничения по разным видам (например, по «Организациям» и «Подразделениям»), они объединяются по правилу И (доступ сужается до пересечения условий).
3. Производительный RLS: Для оптимизации быстродействия БСП использует предварительный расчет прав. При записи объектов рассчитываются специальные «ключи доступа», которые записываются в регистры сведений. Проверка RLS сводится к быстрому соединению с таблицей ключей, что исключает тяжелые вычисления на стороне СУБД при каждом открытии списков.

Альтернативные способы разграничения доступа

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

1. Программный контроль в подписках на события: Проверка прав в обработчике ПередЗаписью объекта. Позволяет разрешить чтение всех данных, но запретить запись объектов по определенным критериям.
2. Функциональные опции: Используются для скрытия лишних реквизитов, команд и документов из пользовательского интерфейса.
3. Фиксированные отборы в динамических списках: Наложение фильтра на уровне формы (например, в процедуре ПриСозданииНаСервере формы списка) для отображения только актуальных пользователю данных без накладных расходов на RLS.