Как настроить разграничение прав доступа по организациям в 1С:ERP

← На главную

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

Архитектурные особенности ограничения прав по организациям

Проанализируем базовый механизм подсистемы управления доступом Библиотеки Стандартных Подсистем (БСП), используемый в конфигурациях линейки ERP:

Прямое разграничение без групп доступа: В отличие от номенклатуры, контрагентов или физических лиц, для которых создаются промежуточные справочники (например, ГруппыДоступаНоменклатуры, ГруппыДоступаКонтрагентов), доступ к организациям настраивается напрямую по элементам справочника Организации. Промежуточный справочник «Группы доступа организаций» отсутствует, так как ограничения связываются непосредственно с ссылками на сами организации.
Принцип объединения прав «ИЛИ»: Если пользователю назначено несколько профилей или групп доступа, и хотя бы в одной роли не прописано ограничение на уровне записей (или выдана общая роль с полными правами на чтение объекта), платформа предоставит доступ ко всем записям таблицы без фильтрации.
Ошибки отсутствия конструкции «РАЗРЕШЕННЫЕ»: В некоторых типовых запросах отчетов или процедур проведения разработчики могут упустить ключевое слово РАЗРЕШЕННЫЕ. В этом случае, если запрос пытается прочитать записи, недоступные текущему пользователю по правилам RLS, система аварийно завершает операцию с ошибкой «Нарушение прав доступа».

Способ 1. Создание кастомных ролей с шаблонами RLS

Если определенные типовые документы (например, ДепонированиеЗарплаты или документы выпуска) не содержат условий ограничения в поставляемых ролях, решим задачу путем создания собственных ролей на базе типовых. Разберем порядок действий по шагам:

Создадим копию типовой роли конфигурации (например, скопируем ДобавлениеИзменениеДепонированнойЗарплаты в новую роль ДобавлениеИзменениеДепонированнойЗарплатыСcustomRLS).
Откроем права на чтение и изменение нужного объекта метаданных и добавим условие ограничения доступа.
Используем стандартные шаблоны БСП, такие как #ПоЗначениям или #ДляОбъекта, скопированные из базовых ролей подсистемы управления доступом. Избегаем написания самописных условий на чистом SQL/языке запросов, чтобы не нарушать механизмы оптимизации БСП.
Включим созданную роль в пользовательский профиль групп доступа вместо типовой роли.
Зарегистрируем изменения в общем модуле УправлениеДоступомПереопределяемый в процедуре ПриЗаполненииВидовДоступа, если объекту требуется расширенное сопоставление полей.

Посмотрим на пример структуры вызова шаблона БСП для ограничения по полю организации в тексте ограничения роли:


#ПоЗначениям( "Документ.ДепонированиеЗарплаты", "Чтение", "",
"Организации", "Организация",
"", "",
"", "",
"", "",
"", "" )

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

Способ 2. Обход ошибок запросов и переход на производительный режим RLS

Если включение RLS приводит к падению регламентных отчетов или регламентных процедур из-за отсутствия директивы РАЗРЕШЕННЫЕ в коде конфигурации, рассмотрим следующие варианты обхода:

Временная выдача прав на чтение без RLS: Для вспомогательных служебных регистров и справочников можно предоставить роль с правом чтения без ограничений. Пользователь сможет сформировать отчет или провести документ, так как системный запрос не будет блокироваться, при этом документы чужих организаций останутся недоступными для изменения.
Переход на производительный режим RLS: В современных версиях ERP и БСП реализован режим производительного RLS. В этом режиме права пользователей предварительно рассчитываются в фоновом режиме и фиксируются в специализированных регистрах сведений (ключи доступа к объектам и регистрам). Это снижает нагрузку на СУБД, исключает тяжелые подзапросы «на лету» и существенно минимизирует возникновение ошибок прав доступа.
Контроль фоновых заданий: Убедимся, что регламентные задания ОбновлениеКлючейДоступа и ЗаполнениеДанныхДляОграниченияДоступа выполняются по расписанию и завершаются без ошибок. Если регламентные задания зависают, права пользователей перестают обновляться.

Способ 3. Интерфейсная фильтрация данных

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

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

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