К статье
Практический материал

Администрирование · 11 мин

RLS в 1С: что это такое и для чего нужно

RLS в 1С — механизм ограничения доступа на уровне записей. Разбираем, как работает, как настроить, типичные ошибки и влияние на производительность.

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

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

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

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

RLS задаётся внутри роли конфигурации. Для каждого права (чтение, добавление, изменение, удаление) разработчик может прописать условие на встроенном языке запросов. Когда пользователь обращается к данным, платформа подставляет это условие в итоговый SQL-запрос, и СУБД возвращает только разрешённые записи.

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

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

Для чего нужен RLS: типовые сценарии

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

  • Несколько организаций в одной базе: бухгалтер видит документы только своей организации.
  • Разделение по филиалам и складам: кладовщик работает только со своим складом.
  • Разграничение клиентской базы: менеджер видит только закреплённых за ним контрагентов.
  • Ограничение доступа к чувствительным данным: зарплата, персональные данные, закрытые договоры.
  • Разделение по видам деятельности или направлениям бизнеса внутри холдинга.

Без RLS альтернативой остаются только грубые решения: отдельные базы с обменами (дорого в поддержке), запрет доступа к целым объектам (ломает бизнес-процессы) или договорённости «не смотреть чужое» (что не является защитой).

Способы разграничить данные

Отдельные базы для подразделений

Полная изоляция, но нужны обмены, свёртка консолидированной отчётности и двойное сопровождение

Роли без RLS

Просто и быстро, но ограничение только на уровне целых объектов — нельзя скрыть часть записей

RLS

Гибкое разграничение записей в одной базе; цена — нагрузка на СУБД и сложность настройки

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

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

Общий порядок выглядит так:

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

Ограничение на чтение и на запись — не одно и то же

Частая ошибка — настроить RLS только на чтение. Пользователь не увидит чужие записи в списке, но если право изменения не ограничено, он сможет создать документ с чужой организацией или изменить доступную запись так, что она «уйдёт» из его зоны видимости. В типовых решениях на запись часто действует более строгое правило: запрещено всё, что не разрешено явно (конструкция вида «ГДЕ Ложь» с перечнем разрешённых случаев).

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

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

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

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

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

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

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

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

Типичные ошибки
01
Ограничение задано только на чтение — пользователь может создавать и менять чужие записи
02
Пользователь не добавлен ни в одну группу доступа — по логике «запрещено всё, что не разрешено» он не видит ничего
03
Сложный шаблон с вложенными запросами — списки и отчёты открываются по несколько минут
04
Полные права у пользователя с RLS-ролью — при противоречии ролей выигрывает более слабое ограничение, логика доступа становится непредсказуемой
05
Забыли обновить данные ограничения после смены группы доступа — пользователь работает со старыми правами

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

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

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

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

Видны только записи своих организаций/складов

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

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

Отчёт по продажам
Норма

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

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

В отчёт попали чужие данные

Скорость открытия списков
Норма

Сопоставимо с работой под полными правами

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

Резкое замедление после включения RLS — шаблон требует оптимизации

Когда RLS не нужен и чем его заменить

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

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

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

Как выбрать подход

Нужно скрыть часть записей внутри общего справочника или журналаИспользуйте RLS через роли или группы доступа
Нужно закрыть целый вид документов или справочниковДостаточно обычных ролей без RLS — быстрее и проще
Подразделения полностью автономны и не имеют общих данныхРассмотрите отдельные базы с обменом вместо RLS
После включения RLS критично просела производительностьОптимизируйте шаблоны или откажитесь от RLS для некритичных объектов

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

Можно ли настроить RLS без программирования?

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

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

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

Влияет ли RLS на обмены данными и регламентные задания?

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

Можно ли обойти RLS через отчёт на СКД?

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

RLS и права на объекты — что применяется первым?

Они работают вместе: сначала проверяется наличие права на объект как таковой, затем к запросу добавляются условия RLS. Если права на чтение справочника нет вообще, RLS уже ни на что не влияет — доступа нет независимо от записей.

Как отключить RLS, если он мешает?

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

Итог

Что важно запомнить

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