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

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

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

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

Как работает RLS: принцип механизма

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

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

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

Чем RLS отличается от обычных прав и от функциональных опций

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

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

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

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

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

Виды доступа в типовых конфигурациях предопределены: организации, подразделения, склады, кассы, контрагенты, физические лица и другие. Для каждого вида можно задать конкретные разрешённые значения («только организация Ромашка») или режим «все разрешены/запрещены».

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

Как разработчику задать RLS в конфигураторе

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

#Таблица.Владелец = &ТекущийПользователь

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

RLS и производительность: главный компромисс

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

Признаки того, что RLS стал проблемой: отчёт у администратора (без ограничений) открывается за секунды, а у рядового пользователя — за минуты; в замере производительности видно, что время уходит на запросы с длинными условиями по правам. Что делать: упрощать шаблоны, избегать соединений в них, проверять индексы по полям ограничения, а для тяжёлых отчётов рассмотреть вариант выполнения в привилегированном режиме с программным отбором.

Полезный приём при поиске проблем с производительностью: сравните текст запроса, который уходит в СУБД, у пользователя с полными правами и у пользователя с RLS (через технологический журнал или консоль СУБД). Разница в плане запроса сразу покажет, какое именно условие ограничения «ломает» выборку.

Типичные ошибки и ограничения механизма

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

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

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

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

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

Норма

Видны только записи разрешённых организаций/складов, поиск не находит чужие документы

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

Видны все записи (RLS не применился) или список пуст при наличии данных (параметр сеанса не заполнен)

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

Норма

Суммы и строки в отчёте совпадают с тем, что видит пользователь в списках

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

Отчёт показывает больше данных, чем список — отчёт построен в обход RLS

Скорость работы

Норма

Списки и отчёты открываются за приемлемое время, сопоставимое с полными правами

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

Резкое замедление только у пользователей с ограничениями — шаблон слишком тяжёлый

Когда RLS нужен, а когда лучше обойтись без него

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

Без RLS можно обойтись, если разграничение нужно только «для порядка» на уровне интерфейса (достаточно ролей и функциональных опций) или если в базе одна организация и все пользователи имеют равный доступ к данным. Каждое включённое ограничение — это постоянная нагрузка на все запросы, поэтому включать RLS «на всякий случай» не стоит.

Маршрут решения

Как выбрать действие

Пользователь не должен видеть чужие документы, но работает в том же журналеНастройте RLS через профиль группы доступа с нужным видом доступа

Нужно просто убрать лишний раздел из менюДостаточно ролей и функциональных опций, RLS не требуется

После включения RLS база стала заметно медленнееПроанализируйте шаблоны ограничений и план запросов, упростите условия и проверьте индексы

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

Частые вопросы об RLS в 1С

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

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

Работает ли RLS в файловой базе 1С?

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

Можно ли обойти RLS через отчёт или обработку?

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

Что делать, если после включения RLS у пользователей пропали нужные документы?

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

Чем RLS отличается от разделителей данных в режиме SaaS?

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

Нужно ли программировать, чтобы настроить RLS в типовой конфигурации?

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