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

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

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

Вместе с тем RLS — один из самых «дорогих» механизмов с точки зрения производительности и один из самых сложных в настройке. Неправильно написанный шаблон ограничения способен замедлить работу всей базы в разы, а ошибка в логике условия — либо закрыть пользователю нужные данные, либо, что хуже, открыть лишние. Поэтому внедрять RLS нужно с пониманием его внутреннего устройства и обязательной проверкой результата.

Что такое RLS и где он применяется

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

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

Как RLS работает внутри платформы

Технически RLS реализован через текст ограничения доступа, который разработчик указывает в роли для конкретного права (чтение, добавление, изменение, удаление) на конкретный объект. Этот текст пишется на специальном диалекте языка запросов и содержит условие отбора. Например, ограничение на справочник контрагентов может выглядеть как условие, что реквизит «ОсновнойМенеджер» записи равен текущему пользователю.

Когда пользователь открывает список документов или выполняется программный запрос, платформа берёт текст ограничения из всех назначенных пользователю ролей и подставляет его в итоговый SQL-запрос в виде дополнительного условия WHERE и соединений с вспомогательными таблицами. Если ролей несколько, их ограничения объединяются по принципу «ИЛИ»: запись доступна, если она разрешена хотя бы одной из ролей. Внутри одной роли по разным полям условия объединяются по «И».

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

Где настраивается RLS в типовых и самописных конфигурациях

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

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

1. 1
   Включите в настройках программы ограничение доступа на уровне записей (функциональная опция в разделе администрирования прав).
2. 2
   Создайте профиль группы доступа и назначьте ему необходимые роли.
3. 3
   Заполните разрешённые значения в профиле: организации, склады, подразделения или другие виды доступа.
4. 4
   Добавьте пользователей в группу доступа с этим профилем.
5. 5
   Проверьте результат, войдя под тестовым пользователем: списки и отчёты должны показывать только разрешённые записи.

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

Каждое ограничение добавляет в запрос соединения и условия, что увеличивает нагрузку на СУБД. Особенно тяжёлыми становятся запросы, где ограничение применяется к большим таблицам движений документов: итоговый SQL может содержать десятки соединений, и время выполнения вырастает в разы. Характерный симптом — база «летает» под полными правами и заметно тормозит под обычными пользователями.

Снизить нагрузку помогают несколько приёмов. Во-первых, использовать простые условия по индексированным полям, избегая вложенных подзапросов и функций в тексте ограничения. Во-вторых, объединять роли так, чтобы у пользователя не было десятка дублирующих ограничений. В-третьих, в типовых конфигурациях применять группы доступа значений и не назначать ограничения на объекты, где они не нужны. При серьёзных проблемах полезно снять технологический журнал или план запроса на СУБД и посмотреть, какой именно текст добавляет RLS.

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

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

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

Контрольные точки

Как проверить результат

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

Норма

Видны только записи разрешённых организаций или подразделений

Тревожный признак

Видны все записи или список вообще пуст

Отчёт по тем же данным

Норма

Суммы в отчёте меньше, чем под администратором, и соответствуют разрешённым записям

Тревожный признак

Суммы совпадают с полными правами — RLS не применён

Открытие чужого документа по ссылке

Норма

Объект не найден или недоступен

Тревожный признак

Документ открывается и читается

Типичные ошибки при настройке и эксплуатации

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

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

Ограничения механизма и альтернативы

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

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

Сравнение вариантов разграничения

RLS в одной базе

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

Отдельные базы с обменом

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

Только права на объекты без RLS

Подходит, когда достаточно разделить доступ по функциям (кто-то не видит зарплату, кто-то — закупки). Не защищает от доступа к чужим записям внутри разрешённого объекта.

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

Почему пользователь с настроенным профилем видит пустые списки?

Чаще всего не заполнены разрешённые значения в профиле группы доступа или не установлены параметры сеанса. Проверьте, что в профиле указаны конкретные организации или подразделения, пользователь входит в группу доступа, а функциональная опция ограничения включена.

Действует ли RLS в отчётах и динамических списках?

Да, ограничение применяется ко всем обращениям к данным, включая отчёты на СКД, динамические списки и программные запросы. Если отчёт показывает полные данные, значит для соответствующего объекта ограничение не настроено или пользователь работает с ролью без RLS.

Почему база тормозит только под обычными пользователями?

Типичный признак тяжёлого RLS: платформа добавляет в запросы соединения и условия, которых нет под полными правами. Нужно проанализировать план запроса на СУБД и упростить шаблон ограничения — убрать подзапросы, использовать индексированные поля, сократить число ролей с дублирующими ограничениями.

Можно ли обойти RLS программно?

Код, выполняемый в привилегированном режиме (УстановитьПривилегированныйРежим), игнорирует RLS. Поэтому доступ пользователей к запуску внешних обработок и к функциям, работающим в привилегированном режиме, должен контролироваться отдельно.

Что будет с настройками RLS при обновлении типовой конфигурации?

Настройки профилей групп доступа хранятся в данных и при обновлении сохраняются. А вот прямые изменения в типовых ролях и шаблонах ограничений могут быть перезаписаны обновлением, поэтому доработки оформляют через расширения или отдельные роли.

Обязательно ли использовать RLS для разделения по организациям?

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