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

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

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

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

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

Когда пользователь открывает список документов, платформа формирует запрос к СУБД. Если для таблицы документа в роли пользователя задано ограничение доступа, платформа подставляет в этот запрос дополнительное условие WHERE. Пользователь получает только те строки, которые удовлетворяют условию. То же самое происходит при проведении документов, построении отчётов, работе планов обмена и регламентных заданий под пользователем.

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

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

Где настраивается: роли и ограничение доступа

Настройка выполняется в конфигураторе. Откройте роль (Общие → Роли), выберите объект метаданных в списке прав и перейдите на закладку «Ограничение доступа». Для каждого права, к которому применимо ограничение, в поле условия пишется текст на языке запросов 1С — по сути, фрагмент условия ГДЕ (WHERE).

Условие может ссылаться на поля самой таблицы и на параметры сеанса. Классический пример для документа «Реализация товаров»:

РеализацияТоваровУслуг ГДЕ
РеализацияТоваровУслуг.Организация = &ТекущаяОрганизация

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

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

Шаблоны ограничений и параметры сеанса

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

Параметры сеанса — это значения, которые платформа хранит для текущего сеанса пользователя: его организация, подразделение, склад, список доступных контрагентов. Заполняются они в обработчике УстановкаПараметровСеанса модуля сеанса при входе пользователя. Если параметр не инициализирован, платформа вызовет обработчик при первом обращении к нему.

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

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

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

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

Типовые сценарии применения

Разделение по организациям

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

Разделение по складам и подразделениям

Кладовщик работает только со своим складом: видит остатки и может оформлять движения по нему. Здесь важно ограничить не только документы, но и отчёты по остаткам — иначе пользователь увидит чужие данные через отчёт, даже если список документов для него пуст.

Персональные данные сотрудников

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

Способы ограничения доступа

Права на объект целиком

Запрещают доступ к виду документов или справочнику полностью. Просто и быстро, но не решает задачу «свои/чужие записи внутри одного объекта».

RLS

Гибкая фильтрация записей по условию. Требует аккуратной настройки и контроля производительности.

Профили групп доступа (в типовых)

Готовая надстройка над ролями и RLS: настройка через интерфейс без конфигуратора. Подходит, если возможностей типовой поставки достаточно.

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

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

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

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

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

Как отличить норму от проблемы

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

Норма

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

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

Пустой список при наличии данных или видны чужие записи

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

Норма

Сообщение о нарушении прав доступа

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

Документ открывается и доступен для изменения

Время открытия списка

Норма

Сопоставимо с режимом без RLS

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

Рост времени в разы, таймауты запросов

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

Норма

Итоги совпадают с видимым набором записей

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

Отчёт показывает данные, которых нет в списках

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

FAQ

RLS работает в файловой версии 1С?

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

Почему пользователь с RLS видит пустые списки, хотя данные есть?

Чаще всего не заполнен параметр сеанса, на который ссылается условие, либо пользователю не присвоено значение доступа (организация, склад, группа контрагентов). Проверьте обработчик УстановкаПараметровСеанса и настройки профиля группы доступа.

Можно ли настроить RLS без изменения конфигурации?

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

Действует ли RLS при обмене данными и в регламентных заданиях?

Ограничения применяются в контексте пользователя, под которым выполняется код. Регламентные задания обычно работают от имени служебного пользователя с широкими правами или в привилегированном режиме, поэтому RLS для них не действует. Учитывайте это при проектировании обменов.

Как быстро найти, в каких ролях задано ограничение на конкретный объект?

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

Можно ли дать пользователю чтение всех записей, а изменение — только своих?

Да, для этого в роли задаются разные ограничения на права «Чтение» и «Изменение». На чтение ограничение отсутствует или шире, на изменение — условие по ответственному или автору записи. Аналогично настраивается и право «Удаление».