Вопрос разграничения прав доступа на уровне записей и полей (Record Level Security, RLS) — один из самых ответственных архитектурных этапов разработки в 1С. Разработчики часто сталкиваются с дилеммой: внедрять полноценный механизм RLS для закрытия видимости данных или ограничиться наложением условий в запросах динамических списков и формах. Выясним причину возможного замедления системы, разберем ключевые факторы влияния RLS на СУБД и рассмотрим практические способы оптимизации.
Факторы, определяющие производительность RLS
Влияние RLS на быстродействие может варьироваться от практически незаметного до критического падения скорости выполнения операций в разы. Проанализируем, от чего именно зависит производительность:
Сложность условий в шаблонах RLS: если ограничение содержит тяжелые вложенные запросы, соединения с несколькими таблицами или проверки наличия условий для каждой строки, СУБД вынуждена многократно выполнять эти вычисления при каждом обращении к данным.
Режим работы базы данных: в файловом варианте работы базы данных наложение условий RLS вызывает ощутимые задержки даже на небольших объемах данных. В клиент-серверном варианте (SQL) оптимизатор запросов лучше справляется с фильтрацией, однако при неоптимальной структуре условий нагрузка на сервер СУБД резко возрастает.
Количество назначенных ролей: когда пользователю назначено несколько ролей с ограничениями на один и тот же объект метаданных, платформа 1С объединяет эти условия через логический оператор ИЛИ (OR). Это существенно усложняет план выполнения запроса на стороне СУБД и часто приводит к отказу от использования индексов (переход от Index Seek к Index Scan).
Индексация реквизитов: поля, участвующие в проверке прав (организации, подразделения, группы контрагентов, владельцы), обязательно должны быть проиндексированы. Отсутствие индексов приводит к полному сканированию таблиц.
Объем выборки и структура списков: при открытии динамических списков или формировании тяжелых отчетов RLS модифицирует основной текст SQL-запроса, добавляя условия отбора во все секции чтения данных.
RLS против ручной фильтрации в динамических списках
Рассмотрим ситуацию, когда требуется ограничить видимость документов по группам контрагентов или организациям. Сравним два возможных архитектурных подхода:
Ручная фильтрация в динамических списках и формах: разработчик вручную добавляет условия в тексты запросов списков или накладывает отборы на форме. Плюсы: простота контроля конкретного запроса и минимальная нагрузка. Минусы: безопасность данных не гарантируется. Пользователи сохраняют доступ к конфиденциальным данным через отчеты, универсальные обработки, ссылки в связанных документах и журналы. Трудозатраты на покрытие всех интерфейсных элементов системы кодом растут в геометрической прогрессии.
Использование механизма RLS: ограничение накладывается на уровне платформы в ролях конфигурации. Плюсы: гарантированная защита данных во всех разрезах конфигурации (списки, отчеты, поиск по ссылкам). Минусы: необходимость проектирования шаблонов ограничений с учетом индексов и планов запросов.
Если цель задачи — гарантированная изоляция данных, правильным решением является использование RLS. Ручная фильтрация в формах подходит исключительно для интерфейсного удобства («бантиков»), но не обеспечивает информационную безопасность.
Причины замедления СУБД при использовании RLS
Разберем подробнее, почему СУБД может испытывать повышенные нагрузки при активации ограничений доступа:
Коррелированные подзапросы: конструкции вида ГДЕ Ссылка В (ВЫБРАТЬ ...) или предикаты EXISTS вынуждают СУБД выполнять вложенный запрос построчно для каждой проверяемой записи результирующего набора.
Разрушение индексного поиска из-за объединений: при наложении нескольких ролей платформа формирует конструкцию (УсловиеРоли1) ИЛИ (УсловиеРоли2). Оптимизатор СУБД в таких случаях не может однозначно выбрать индекс, что приводит к сканированию всей таблицы.
Нагрузка на базу TempDB: сложные выборки с RLS требуют создания промежуточных таблиц и выполнения операций Spool на сервере СУБД, создавая узкое место по дисковому вводу-выводу во временной базе данных.
Методы оптимизации и лучшие практики работы с RLS
Чтобы свести влияние RLS к минимуму и сохранить высокую скорость работы пользователей, разберем по шагам ключевые правила настройки:
Использование производительного режима RLS (механизм ключей доступа): в современных конфигурациях на базе Библиотеки стандартных подсистем (БСП) используется механизм предрассчитанных прав доступа. Вместо вычисления сложных запросов «на лету» права рассчитываются в фоновом режиме и записываются в плоские регистры соответствий (ключи доступа). Обращение к данным в этом случае происходит через быстрое индексное соединение с плоской таблицей.
Использование параметров сеанса: внутри текстов условий RLS не следует выполнять прямые запросы к таблицам баз данных. Списки доступных значений (массивы групп контрагентов, подразделений, организаций) необходимо рассчитывать заранее при старте сеанса или обновлении настроек и помещать в ПараметрыСеанса.
Посмотрим на пример правильной структуры простого условия RLS с использованием параметров сеанса:
ГДЕ ГруппаДоступа В (&ПараметрСеанса_ДоступныеГруппыКонтрагентов)
ИЛИ ЭтоГруппа = ИСТИНА
Применение привилегированного режима: критичные к скорости алгоритмы, такие как проведение документов, регламентные задания, пакетная обработка данных и служебные расчеты, не должны выполнять проверку RLS. Для этого код необходимо обрамлять в привилегированный режим или выносить в привилегированные общие модули:
УстановитьПривилегированныйРежим(Истина);
// Выполнение критичных операций проведения и записи без накладных расходов RLS
ДокументОбъект.Записать(РежимЗаписиДокумента.Проведение);
УстановитьПривилегированныйРежим(Ложь);
Оптимизация динамических списков: в формах списков с включенным RLS следует избегать сортировок по составным или неиндексированным полям. Также необходимо отключить автоматический подсчет общего числа строк в динамическом списке, так как эта операция заставляет СУБД полностью сканировать всю таблицу с применением RLS.
Использование механизма разделения данных: если требуется изолировать данные разных организаций или филиалов на уровне всей информационной базы, проанализируем возможность использования встроенного механизма разделения данных (мультитенантность). Разделители работают на уровне платформы без модификации условий в SQL-запросах, что гарантирует максимальное быстродействие.
Соблюдение этих правил позволяет внедрить разграничение прав доступа любой сложности без ощутимой потери производительности информационной системы.