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

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

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

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

Где в архитектуре 1С срабатывает RLS

Ограничение на уровне записей применяется на этапе выполнения запроса к базе данных. Когда пользовательский код, динамический список или отчёт обращается к таблице, для которой задано ограничение, платформа подставляет в итоговый SQL-запрос дополнительное условие WHERE и, при необходимости, соединения с вспомогательными таблицами. Сам разработчик этот запрос не меняет — всё происходит внутри платформы.

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

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

Как устроены шаблоны и тексты ограничений

Текст ограничения пишется на специальном диалекте языка запросов. Простейший вариант выглядит так: #ТекущаяТаблица.Организация = &ТекущаяОрганизация. Здесь #ТекущаяТаблица — ссылка на защищаемую таблицу, а параметр &ТекущаяОрганизация обычно берётся из параметров сеанса, которые заполняются при входе пользователя в систему.

Чтобы не повторять один и тот же текст для каждого объекта, в роли создаются шаблоны ограничений. Например, шаблон «ПоОрганизации» принимает параметр — имя поля с организацией — и возвращает готовое условие. Дальше в ограничении документа «Реализация товаров» достаточно написать #ПоОрганизации("Организация"), а в регистре накопления — тот же шаблон с тем же параметром. Изменение логики прав делается в одном месте.

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

// Пример текста ограничения в роли
#ТекущаяТаблица.Ответственный = &ТекущийПользователь

// Пример обращения к шаблону
#ПоЗначениям("Организация", "", "")

Откуда берутся значения: параметры сеанса

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

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

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

Как настроить RLS для своего объекта: порядок действий

Типовая задача — ограничить доступ к документам по ответственному. Последовательность одинакова для любого объекта: сначала определяется, какое поле связывает запись с пользователем, затем создаётся параметр сеанса, потом пишется ограничение в роли.

1. 1
   Создайте параметр сеанса «ТекущийПользователь» типа «СправочникСсылка.Пользователи», если его ещё нет
2. 2
   В модуле сеанса в обработчике УстановкаПараметровСеанса задайте: ПараметрыСеанса.ТекущийПользователь = ПользователиИнформационнойБазы.ТекущийПользователь() с преобразованием в ссылку справочника
3. 3
   Откройте роль, перейдите на вкладку «Шаблоны ограничений» и создайте шаблон с условием по полю «Ответственный»
4. 4
   Для нужного документа в роли откройте ограничение доступа для права «Чтение» и укажите текст: #ТекущаяТаблица.Ответственный = &ТекущийПользователь
5. 5
   Повторите ограничение для прав «Добавление», «Изменение», «Удаление»
6. 6
   Зайдите под тестовым пользователем и проверьте, что в списке видны только его документы

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

Отдельный момент — регистры, подчинённые регистратору. Для них ограничение обычно пишется через соединение с таблицей регистратора или через поле, продублированное в регистре (например, «Организация»). Если поле в регистре отсутствует, а соединение тяжёлое, лучше добавить реквизит в регистр и заполнять его при проведении.

Влияние на производительность и как его снизить

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

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

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

Привилегированный режим и обход RLS

Единственный штатный способ выполнить код без учёта RLS — установить привилегированный режим: УстановитьПривилегированныйРежим(Истина). В этом режиме игнорируются и обычные права, и ограничения на уровне записей. Так работают, например, регламентные задания и серверные процедуры, которые должны обрабатывать данные всех пользователей.

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

Обратная ситуация тоже встречается: разработчик забывает, что код выполняется под ограниченным пользователем, и обработчик не находит нужные записи. Симптом — обработка «молча» ничего не делает или проводит документы частично. Диагностируется это запуском под полными правами: если под ними всё работает, причина почти наверняка в RLS или правах.

Как проверить, что ограничение работает правильно

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

Для глубокой диагностики полезен технологический журнал с включёнными событиями DBMSSQL: в тексте запроса видно, какое именно условие платформа добавила от RLS. Это позволяет отличить «пустое условие из-за незаполненного параметра» от «условие корректно, но данных действительно нет».

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