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