Администрирование · 9 мин
1С RLS: что это такое и как настроить ограничение доступа на уровне записей
1С RLS — механизм ограничения доступа на уровне записей. Разбираем, как работает RLS в 1С, как настроить шаблоны, роли и проверить результат без падения производительности.
RLS (Record Level Security) в 1С — это встроенный механизм платформы, который ограничивает доступ пользователей не к целым объектам (документам, справочникам), а к отдельным записям внутри них. Благодаря RLS один менеджер видит только своих контрагентов, кассир — только кассу своей организации, а сотрудник филиала — только документы своего подразделения, хотя все они работают в одной базе и с одними и теми же таблицами.
Механизм реализован на уровне запросов: когда пользователь обращается к данным, платформа автоматически добавляет к запросу дополнительные условия отбора. Пользователь не просто «не видит кнопку» — записи физически исключаются из выборки, поэтому обойти ограничение через консоль запросов, отчёты или обработки невозможно (если код не выполняется в привилегированном режиме).
Настройка RLS выполняется через роли в конфигураторе: для каждого права (чтение, добавление, изменение, удаление) задаётся шаблон ограничения на встроенном языке запросов. Ошибки в шаблонах — частая причина как «дыр» в безопасности, так и серьёзного падения производительности, поэтому тема требует аккуратности.
Как RLS работает внутри платформы
Когда разработчик задаёт для роли ограничение доступа к данным, он пишет текст на языке запросов 1С — например, условие, что поле «Организация» документа должно входить в список организаций, доступных текущему пользователю. При выполнении любого запроса (из формы, отчёта, кода) платформа подставляет это условие в итоговый SQL-запрос к СУБД.
Ключевые свойства механизма:
- Ограничение действует на уровне данных, а не интерфейса — скрыть записи «визуально» не получится, они исключаются из выборки;
- RLS применяется к каждому праву отдельно: можно разрешить чтение всех документов, но изменение — только своих;
- В привилегированном режиме (УстановитьПривилегированныйРежим) ограничения RLS не действуют — это важно учитывать при разработке;
- Ограничения из нескольких ролей одного пользователя объединяются по принципу «ИЛИ»: достаточно, чтобы доступ разрешала хотя бы одна роль.
Где RLS применяется на практике
Типовые сценарии, встречающиеся в конфигурациях 1С:Предприятие (УТ, ERP, Бухгалтерия, ЗУП):
- разграничение по организациям в многофирменной базе;
- разграничение по подразделениям, складам, кассам;
- ограничение доступа менеджеров к «чужим» контрагентам и сделкам;
- в ЗУП — ограничение доступа к данным по физическим лицам и зарплате отдельных сотрудников;
- ограничение по группам доступа контрагентов, номенклатуры, партнёров.
В типовых конфигурациях на базе БСП (Библиотека стандартных подсистем) большая часть этих сценариев уже реализована: администратору достаточно включить нужные функциональные опции и настроить профили групп доступа, не редактируя роли вручную.
Как настроить RLS в типовой конфигурации
В конфигурациях на БСП настройка выполняется в пользовательском режиме, без изменения конфигурации:
- 1Включите функциональную опцию ограничения доступа на уровне записей (раздел «Администрирование» → «Настройки прав и пользователей»).
- 2Создайте или откройте профиль группы доступа и отметьте нужные роли и виды доступа (организации, подразделения, группы контрагентов).
- 3Создайте группу доступа, привяжите к ней профиль и добавьте пользователей.
- 4Задайте конкретные разрешённые значения: какие организации, склады или группы партнёров доступны группе.
- 5Зайдите под тестовым пользователем и проверьте, что он видит только свои записи в списках, отчётах и подборах.
После включения RLS проверьте производительность: динамические списки и отчёты могут начать работать заметно медленнее, особенно на больших таблицах. Если база крупная, тестируйте на копии под нагрузкой, близкой к реальной.
Как настроить RLS через роли в конфигураторе
Если типовых механизмов недостаточно или конфигурация самописная, ограничения задаются напрямую в ролях. Откройте роль в конфигураторе, выберите объект (например, документ «Реализация товаров»), право (например, «Чтение») и в поле «Ограничение доступа» укажите условие:
РеализацияТоваров ГДЕ РеализацияТоваров.Организация В (&ДоступныеОрганизации)
Значения параметров (например, список доступных организаций текущего пользователя) обычно подставляются через параметры сеанса, которые заполняются при входе пользователя в систему. В типовых конфигурациях для этого используется подсистема «Управление доступом» БСП.
Для сложных условий создавайте шаблоны ограничений: они позволяют писать условие один раз и применять его к десяткам объектов с разными параметрами. Это снижает количество ошибок и упрощает сопровождение.
Влияние RLS на производительность
Главная цена RLS — дополнительные соединения и условия в каждом запросе. Сложный шаблон с обращением к нескольким таблицам (например, проверка вхождения контрагента в иерархию групп доступа) может замедлить списки и отчёты в разы.
Практические рекомендации:
- используйте простые условия по индексированным полям (организация, подразделение);
- избегайте соединений с большими таблицами внутри шаблонов;
- не применяйте RLS к объектам, где он не нужен, — каждое ограничение добавляет нагрузку;
- проверяйте итоговые запросы через технологический журнал или план запроса СУБД;
- по возможности используйте механизм групп доступа БСП — он оптимизирован и проверен на больших базах.
Как проверить, что RLS работает правильно
Проверку выполняйте только под реальным пользователем с целевыми правами: администратор с полными правами ограничений не заметит.
Как проверить результат
Видны только записи разрешённых организаций/подразделений
Видны чужие записи или список пуст при наличии данных
Итоги совпадают с доступными пользователю записями
В отчёте светятся суммы по недоступным организациям
Можно сохранить документ только по доступной организации
Удаётся записать документ по чужой организации
Списки открываются за приемлемое время
Резкое замедление после включения RLS
Дополнительно проверьте обмены и фоновые задания: они часто выполняются под служебным пользователем. Если у него не настроены нужные значения доступа, обмен может не видеть часть данных.
Типичные ошибки при настройке RLS
Частые вопросы
Чем RLS отличается от обычных прав на объекты?
Обычные права разрешают или запрещают доступ к объекту целиком (например, ко всему документу «Реализация»). RLS работает внутри уже разрешённого объекта и фильтрует конкретные записи по условию: какие документы пользователь увидит, а какие — нет.
Можно ли обойти RLS через отчёт или консоль запросов?
Нет, если код выполняется в обычном режиме: платформа добавляет условия RLS к любому запросу. Ограничения не действуют только в привилегированном режиме, поэтому внешние обработки и отчёты нужно контролировать на предмет вызова УстановитьПривилегированныйРежим.
Почему после включения RLS пользователи не видят никаких данных?
Чаще всего не заполнены значения доступа: профиль создан, но пользователю не назначены конкретные организации, склады или группы контрагентов. Проверьте группы доступа и значения по умолчанию в настройках пользователя.
Как сильно RLS замедляет работу базы?
Зависит от шаблона. Простое условие по индексированному полю почти незаметно, а шаблон с соединениями и иерархией может замедлить запросы в разы. Замерять нужно на реальных объёмах через технологический журнал или план запросов СУБД.
Работает ли RLS в файловой базе?
Да, механизм реализован платформой и работает в обоих режимах. Но на файловой базе с несколькими пользователями дополнительная нагрузка от RLS ощущается сильнее, чем на клиент-серверном варианте.
Нужно ли менять конфигурацию, чтобы включить RLS в типовой 1С?
В конфигурациях на БСП (УТ, ERP, Бухгалтерия, ЗУП) — нет: достаточно включить опцию ограничения на уровне записей и настроить профили групп доступа в пользовательском режиме. Редактирование ролей требуется только для нестандартных сценариев.
Что важно запомнить
RLS в 1С — фильтрация записей на уровне запросов платформы: пользователь физически не получает чужие данные ни в списках, ни в отчётах. В типовых конфигурациях настройка ведётся через профили групп доступа, в остальных случаях — через роли и шаблоны в конфигураторе. Ключевые риски — избыточный доступ при объединении ролей, привилегированный режим в коде и падение производительности из-за тяжёлых шаблонов.