RLS в 1С: цена безопасности в миллисекундах и как её снизить

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

RLS — это не фильтр, накладываемый на результат. Это модификация самого запроса до его выполнения.

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

Простой пример логики: «показывать документы, у которых организация входит в список организаций, доступных текущему пользователю». В SQL это превращается в дополнительное соединение или подзапрос EXISTS по таблице настроек доступа.

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

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

В какой-то момент план перестаёт быть оптимальным. Оптимизатор SQL Server имеет ограниченное время на поиск плана, и запрос с сорока соединениями он просто не успевает разобрать хорошо.

Одна деталь механизма объясняет большую часть удивления.

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

Отсюда и нелинейность. Добавление второго вида ограничения не удваивает стоимость — оно её умножает.

И отсюда же вывод про диагностику: смотреть надо не на конфигурацию прав, а на итоговый текст запроса.

Хорошая новость: цена RLS измеряется тривиально. Плохая: почти никто этого не делает.

Методика на пятнадцать минут:

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

Ориентиры из практики. Замедление в полтора-два раза — норма, это цена механизма. В три-пять раз — есть что оптимизировать. В десять раз и больше — RLS настроен неудачно, и надо менять подход.

Рекорд, который мы встречали: отчёт по продажам за квартал строился 4 секунды под администратором и 6 минут 40 секунд под менеджером. Разница в сто раз.

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

Полезный приём: сравнить длину текста SQL-запроса под администратором и под пользователем. Мы видели случаи, когда исходный запрос на 4 килобайта после наложения RLS превращался в 180 килобайт.

Не все ограничения одинаково затратны. Есть несколько конкретных факторов.

Число видов ограничений. Одно ограничение по организации — дёшево. Пять ограничений по разным измерениям — дорого, и рост нелинейный.

Размер таблицы настроек доступа. Если у каждого из 60 пользователей прописано по 200 доступных контрагентов, регистр настроек содержит 12 000 записей, и подзапрос к нему выполняется для каждой строки основного запроса.

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

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

Ограничения «на чтение и запись» там, где хватило бы «на чтение». Ограничение на запись проверяется при каждом движении, что делает проведение документов заметно дороже.

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

Меры в порядке возрастания трудоёмкости.

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

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

Сократить таблицы настроек доступа. Ограничение по группам контрагентов вместо перечисления каждого контрагента уменьшает регистр настроек на порядок.

Добавить отборы по умолчанию в динамические списки. Период, статус, ответственный. Меньше строк на входе — дешевле применение ограничений.

Проверить индексы регистра настроек доступа. И обновить статистику по нему — планировщик должен знать реальную селективность.

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

Первые два пункта занимают час работы и в нашей практике дают эффект чаще, чем любые технические ухищрения. Просто потому, что настройка прав редко пересматривается после внедрения, а бизнес за это время меняется.

Иногда правильный ответ — не оптимизировать RLS, а решить задачу иначе.

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

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

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

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

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

Клиент — дистрибьютор бытовой техники, 52 рабочих места, УТ на MS SQL, база 140 ГБ.

Жалоба: менеджеры не могут пользоваться отчётом по продажам, он строится «бесконечно». Руководители отделов при этом строят его нормально.

Разница в правах сразу указывала на RLS, но требовалось понять масштаб и причину.

Замер дал цифры: 4,1 секунды под администратором, 6 минут 38 секунд под менеджером. Отношение — около ста.

Технологический журнал показал текст запроса. Исходный SQL занимал 6 килобайт, после наложения ограничений — 214 килобайт. В нём было 47 подзапросов EXISTS к регистру настроек доступа.

Разбор настройки прав дал объяснение. За три года эксплуатации в профиль менеджера последовательно добавили четыре вида ограничений: по организации, по складу, по группе номенклатуры и по контрагенту. Каждое добавляли под конкретную задачу, никто не смотрел на картину целиком.

При этом регистр настроек доступа содержал 41 000 записей, потому что контрагенты были перечислены поимённо для каждого менеджера.

Что сделали. Во-первых, выяснили у коммерческого директора реальное требование — оно оказалось одно: менеджер видит только своих контрагентов. Ограничения по складу и группе номенклатуры были историческим наследием и никому не требовались. Убрали.

Во-вторых, перевели ограничение по контрагентам с поимённого перечисления на группы справочника. Регистр настроек сократился с 41 000 записей до 380.

В-третьих, добавили в динамический список отчёта отбор по периоду с умолчанием «текущий месяц».

Итог: отчёт под менеджером стал строиться за 7 секунд вместо 398. Ускорение в пятьдесят с лишним раз без единой правки кода и без изменений в железе.

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

• Замерена ли цена RLS: одна и та же операция под администратором и под обычным пользователем.
• Сколько видов ограничений реально включено и все ли они требуются бизнесом сегодня.
• Есть ли профили без RLS для тех, кто видит всё по должности.
• Размер регистра настроек доступа: перечисляются элементы или группы.
• Индексы и актуальность статистики по регистру настроек доступа.
• Установлены ли отборы по умолчанию в тяжёлых динамических списках.
• Не используются ли ограничения «на запись» там, где достаточно «на чтение».
• Рассматривался ли вариант разделения данных или отдельных баз.

И последнее соображение. RLS — не то, что настраивают один раз. Права выдаются по мере роста компании, каждое добавление кажется незначительным, а деградация накапливается годами и проявляется постепенно, из-за чего её списывают на «база выросла».

Раз в год пересматривайте состав ограничений вместе с владельцем процесса. Занимает полдня, экономит месяцы недовольства.

Насколько RLS замедляет работу 1С?

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

Как измерить цену RLS?

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

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

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

Чем можно заменить RLS?

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