← На главную
При необходимости ограничить доступ пользователей к документам (например, показывать только документы, где пользователь указан ответственным) часто возникает желание реализовать логику через расширение конфигурации, сохранив типовую базу на полной поддержке. Разберем ключевые технические нюансы, поведение платформы при обновлениях и ограничения механизма RLS (Row-Level Security).
Поведение расширений при обновлении основной конфигурации
Если для настройки RLS в расширение заимствуются объекты метаданных (документы, их реквизиты или роли), важно учитывать последствия последующих обновлений релиза:
- Удаление или переименование объектов: если типовой документ или реквизит в новой версии конфигурации удаляется, переименовывается (например, в
УдалитьИмяДокумента) или меняет тип, расширение перестает проходить проверку соответствия метаданных.
- Отказ в подключении: при возникновении критической ошибки валидации расширение не применится к сеансу. В зависимости от настроек запуска и режима совместимости система либо заблокирует вход пользователя с сообщением об ошибке подключения расширения, либо запустит сеанс без него. В последнем случае пользователь получит полные права без ограничений RLS.
Аддитивность прав доступа в 1С и добавление отдельной роли
Попытка решить задачу простым добавлением новой роли (как в расширении, так и в основной конфигурации) с условием RLS «только свои» сталкивается с базовым принципом платформы: права доступа объединяются по логическому правилу «ИЛИ».
Проанализируем механику работы прав:
- Если у пользователя назначены типовые роли (например, профиль кадровика или расчетчика), дающие безусловное право на «Чтение» или «Изменение» документа, то добавление еще одной роли с RLS-ограничением не скроет чужие документы.
- Чтобы ограничение сработало, необходимо либо исключить из профилей пользователя все типовые роли, содержащие полные права на данный объект, либо модифицировать сами исходные роли, включив в них условия ограничения.
Ограничение доступа на уровне регистров и виртуальных таблиц
Ограничение прав исключительно на уровне документов не обеспечивает полной изоляции данных. Рассмотрим причины:
- Независимость прав на регистры: движения документов записываются в регистры накопления, сведений и расчета. Если права ограничены только на документ, пользователь все равно сможет увидеть данные через отчеты и списки, построенные на базе регистров.
- Отсутствие регистратора в виртуальных таблицах: в виртуальных таблицах остатков и срезов измерений поле
Регистратор отсутствует. Выполнить фильтрацию таких выборок по автору первичного документа невозможно без добавления реквизита или измерения Ответственный непосредственно в структуру регистра.
Архитектурно правильные способы решения задачи
В типовых конфигурациях на базе Библиотеки стандартных подсистем (БСП), таких как 1С:ЗУП, рекомендуется использовать следующие подходы:
- Встраивание в подсистему «Управление доступом» БСП: вместо ручной правки условий RLS в каждой роли добавляется новый вид доступа (например, «Пользователи» или «Физические лица») через переопределяемые модули (
УправлениеДоступомПереопределяемый). В расширении можно перехватить методы заполнения доступа к объектам, используя механизмы производительного RLS БСП.
- Фильтрация на уровне узлов РИБ: если задача стоит ограничить доступ в периферийных базах распределенной информационной базы, разделение данных эффективнее реализовать на этапе обмена. Настройка правил фильтрации в плане обмена позволяет вовсе не передавать «чужие» документы в конкретный узел, что снимает необходимость настройки сложного RLS на стороне узла.