Как настроить RLS в 1С: ограничение доступа на уровне записей

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

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

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

Что такое RLS и когда он действительно нужен

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

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

Подготовка: роли, параметры сеанса и данные для отбора

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

Параметры сеанса создаются в ветке «Общие → Параметры сеанса» конфигуратора. Их значения обычно заполняются в модуле сеанса в обработчике УстановкаПараметровСеанса при входе пользователя. Например, параметр ТекущийПользователь позволяет шаблону RLS ссылаться на того, кто выполняет запрос.

// Модуль сеанса
Процедура УстановкаПараметровСеанса(ТребуемыеПараметры)
Если ТребуемыеПараметры = Неопределено
Или ТребуемыеПараметры.Найти("ТекущийПользователь") <> Неопределено Тогда
ПараметрыСеанса.ТекущийПользователь =
ПользователиИнформационнойБазы.ТекущийПользователь().Имя;
КонецЕсли;
КонецПроцедуры

В типовых конфигурациях (УТ, ERP, Бухгалтерия) механизм уже встроен: есть предопределённые роли с ограничениями, группы доступа и настройка через интерфейс без правки конфигуратора. Сначала проверьте типовые возможности — часто достаточно включить функциональную опцию и настроить группы доступа.

Как задать ограничение доступа в роли

Откройте нужную роль (или создайте новую через «Общие → Роли»), найдите объект метаданных, например справочник «Контрагенты», и перейдите на закладку «Ограничение доступа». Для каждого права (Чтение, Добавление, Изменение, Удаление) ограничение задаётся отдельно — это позволяет, к примеру, разрешить чтение всех записей, но изменение только своих.

В поле ограничения пишется условие на языке запросов 1С. Простейший вариант — сравнение реквизита объекта с параметром сеанса:

Контрагенты ГДЕ Контрагенты.Ответственный = &ТекущийПользователь

Для права «Чтение» условие должно вернуть истину для разрешённых записей. Если условие не задано для какого-то права, действует общее право роли без ограничения по записям. Если роль даёт право, но ограничение написано с ошибкой, пользователь либо не увидит ничего, либо получит ошибку при обращении к объекту.

1. 1
   Создайте параметр сеанса и заполните его в модуле сеанса
2. 2
   Откройте роль и выберите объект метаданных
3. 3
   На закладке «Ограничение доступа» задайте условие для прав Чтение/Изменение
4. 4
   Назначьте роль тестовому пользователю
5. 5
   Войдите под тестовым пользователем и проверьте списки, документы и отчёты
6. 6
   Проверьте производительность запросов на реальном объёме данных

Шаблоны ограничений и сложные условия

Когда одно и то же условие используется для многих объектов, его выносят в шаблон: «Общие → Шаблоны ограничений доступа». В тексте ограничения на шаблон ссылаются через конструкцию #Шаблон("ИмяШаблона"). Это избавляет от дублирования и упрощает сопровождение: правка в одном месте меняет поведение всех объектов, использующих шаблон.

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

#Шаблон("ПоОрганизациям")
// В шаблоне:
#ТекущаяТаблица ГДЕ #ТекущаяТаблица.Организация В
(ВЫБРАТЬ Т.Организация ИЗ РегистрСведений.ДоступныеОрганизации КАК Т
ГДЕ Т.Пользователь = &ТекущийПользователь)

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

Проверка результата и типичные ошибки

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

Частая ошибка — ограничение задано только для права «Чтение», а для «Изменение» забыто. Пользователь не увидит чужую запись в списке, но сможет изменить её программно или по ссылке. Вторая типичная проблема — параметр сеанса не установлен: тогда условие сравнивает реквизит с пустым значением, и пользователь не видит ничего. Третья — тяжёлые соединения в шаблоне, из-за которых динамические списки начинают заметно тормозить на больших таблицах.

Производительность и границы механизма

Каждое обращение к ограниченной таблице выполняется с дополнительным условием, поэтому поля, участвующие в ограничениях, должны быть индексированы. Избегайте в шаблонах вложенных запросов к большим таблицам без отборов и соединений по неиндексированным полям. Если список стал открываться заметно медленнее после включения RLS — анализируйте план запроса в консоли СУБД или через технологический журнал.

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

FAQ