Утро понедельника, у половины пользователей внезапно пропал доступ к нужным документам, а у другой половины он, наоборот, расширился там, где не должен был. Причина – неудачный перенос правил RLS в «1С» при переходе на новую версию.
Такой сценарий пугает любого ИТ-директора, и именно поэтому тема перехода со стандартного на производительный режим ограничения доступа требует отдельного разговора, а не строчки в общем плане обновления.
Материал написан для ИТ-администраторов и специалистов служб безопасности компаний с большим числом пользователей и сложными правами доступа – холдингов, розничных сетей, распределенных структур на «1С:ERP», «1С:КА» или «1С:УТ». Если у вас еще включен стандартный RLS, переход на производительный режим станет обязательным условием перед обновлением до редакции 2.6.
Что такое RLS в 1С и зачем нужны два его варианта
RLS (Row Level Security) – это ограничение доступа на уровне записей: механизм, который определяет, какие конкретно строки таблицы (документы, элементы справочников, движения регистров) видит и может редактировать конкретный пользователь, а не все данные объекта целиком. Простыми словами – это фильтр, который отсекает от менеджера филиала данные других филиалов без необходимости создавать отдельную роль под каждый случай.
В прикладных решениях «1С» долгое время использовался стандартный RLS, где условие ограничения выполнялось напрямую SQL-запросом к СУБД при каждом обращении к таблице. С версии 2.4.6 доступен производительный RLS – механизм, который вычисляет права заранее и хранит их в виде «ключей доступа» в отдельных служебных регистрах, а не пересчитывает условие на каждый запрос.
| Понятие / документ | Что это означает для бизнеса |
|---|---|
| Шаблон ограничения доступа | Правило (например, «ДляОбъекта») в роли пользователя, определяющее, по какому признаку фильтруются записи – организация, склад, подразделение |
| Регистр «Используемые виды доступа по таблицам» | Служебная структура производительного RLS, где хранятся ключи доступа – без корректного заполнения этого регистра ограничение просто не сработает |
| Процедура «ПриЗаполненииОграниченияДоступа» | Программный код в модуле объекта, который описывает логику ограничения – критична для нетиповых документов и доработок |
| Регистр сведений «Параметры ограничений доступа» | Хранит текущие настройки RLS в базе; при переносе правил его иногда нужно очищать и пересчитывать вручную |
Стандартный RLS проще настроить, но плохо масштабируется – на больших объемах данных и при большом числе пользователей запросы к СУБД начинают заметно тормозить систему. Производительный RLS решает именно эту проблему за счет предварительного расчета прав, а не проверки «на лету».
Кого касается переход на производительный RLS
-
Холдинги и группы компаний – где нужно ограничивать доступ по организациям, но при этом сохранять высокую скорость работы при большом штате пользователей.
-
Розничные сети – с десятками магазинов и необходимостью показывать каждому менеджеру только данные своей точки.
-
ИТ-администраторы – отвечают за корректный перенос ролей, профилей доступа и нетиповых шаблонов ограничений.
-
Служба безопасности – контролирует, чтобы после перехода никто не получил доступ к данным, которые ему не положены, и наоборот, не потерял нужный доступ.
Отдельно стоит развеять частое заблуждение небольших компаний: «у нас 10 пользователей, RLS нам не критичен». Формально это может быть правдой с точки зрения производительности – стандартный режим справляется с небольшой нагрузкой без проблем. Но если компания планирует переход на редакцию 2.6, отключение стандартного RLS все равно станет обязательным шагом, независимо от количества пользователей.
Когда переход на производительный RLS оправдан технически
Прежде чем бросаться в миграцию, стоит понимать: производительный RLS не универсально лучше стандартного – у него есть конкретные условия применимости.
Производительный RLS дает эффект, если у вас:
-
больше 50 пользователей с ограниченными правами доступа;
-
сложная схема доступа – три и более вида ограничения на один объект (например, организация + подразделение + склад одновременно);
-
преобладают операции чтения над записью – отчеты, динамические списки, аналитика;
-
большие объемы данных – от 100 тысяч записей в таблицах с ограничением;
-
частые обращения к динамическим спискам с фильтрацией по правам.
Стандартный RLS может остаться оправданным, если:
-
ограничения простые и затрагивают один-два вида доступа;
-
база небольшая, а число активных пользователей минимально;
-
в системе много нетиповых доработок, которые сложно и рискованно адаптировать под новую архитектуру прав.
На практике мы видим, что компании часто переходят на производительный RLS не по собственной инициативе, а потому что это стало обязательным условием для новой редакции – и это нормально, если переход спланирован заранее.
Практический блок: что нужно сделать перед переходом
-
Инвентаризация действующих правил RLS. Составьте полный список ролей, профилей доступа и шаблонов ограничений, которые сейчас используются в базе – без этого шага перенос превращается в угадывание.
-
Проверка поддержки RLS в типовых ролях. Часть типовых ролей в некоторых конфигурациях и отраслевых решениях официально не поддерживает ограничение на уровне записей – такие роли нужно выявить заранее, чтобы не столкнуться с сюрпризом после переключения режима.
-
Аудит нетиповых доработок. Если в базе есть собственные документы, справочники или расширения с настроенным доступом, для каждого объекта нужно проверить процедуру «ПриЗаполненииОграниченияДоступа» – производительный RLS требует явного описания логики ограничения для каждого типа объектов.
-
Проверка регистрации ограничения на все три права. В версиях 2.5 и новее фильтр нередко требует установки ограничения не только на право «Чтение», но и на «Изменение» и «Добавление» – иначе нужные записи в служебном регистре не появятся, и ограничение «не сработает» без видимой причины.
-
Обновление вспомогательных данных. После изменения ролей необходимо запустить процедуру обновления вспомогательных данных и очистить регистр сведений «Параметры ограничений доступа», чтобы система пересчитала права с учетом новых настроек.
Таблица ключевых отличий: стандартный RLS и производительный RLS
| Параметр | Стандартный RLS | Производительный RLS |
|---|---|---|
| Принцип работы | Условие ограничения выполняется SQL-запросом при каждом обращении к таблице | Права вычисляются заранее и хранятся в виде ключей доступа в служебных регистрах |
| Производительность при большой нагрузке | Снижается с ростом числа пользователей и объема данных | Остается стабильной даже при десятках тысяч записей и большом числе пользователей |
| Простота первичной настройки | Проще для небольших и типовых сценариев | Требует более тщательной настройки шаблонов и процедур для нетиповых объектов |
| Поддержка расширений и доработок | Гибче адаптируется без изменения типовой конфигурации | Требует регистрации новых объектов в общем модуле «УправлениеДоступомПереопределяемый» |
| Совместимость с редакцией 2.6 | Снимается с поддержки | Обязательное условие для перехода |
| Доступность | Использовался во всех версиях до появления альтернативы | Доступен с версии 2.4.6 |
Главный практический вывод из таблицы: производительный RLS выигрывает там, где важна скорость на больших объемах данных, но требует более внимательной настройки для нетиповых объектов – это не автоматическая замена «один к одному».
Что вы не сможете использовать при отказе от перехода
-
Работа нетиповых шаблонов RLS, написанных под старую архитектуру, окажется под риском – часть кастомных ограничений доступа просто не будет работать в новой архитектуре без адаптации.
-
Массовые ошибки доступа «нет прав» – характерный симптом при обновлении без предварительного переноса правил: пользователи внезапно теряют доступ к привычным документам.
-
Повышенная нагрузка на производительность системы до момента перехода – если компания использует много пользователей и сложные правила на стандартном RLS, она уже сейчас может ощущать замедление работы, которое усилится с ростом объема данных.
Типичные ошибки при переходе на производительный RLS
| Ошибка | Последствие | Как исправить |
|---|---|---|
| Включили производительный RLS прямо в рабочей базе без теста | Массовые обращения в техподдержку «нет доступа», паника пользователей | Тестировать переход только на копии базы с полным набором ролей |
| Не проверили, какие типовые роли не поддерживают RLS | После перехода часть пользователей получает доступ ко всем данным без ограничения | Составить список ролей без поддержки RLS заранее, до переключения режима |
| Установили ограничение только на право «Чтение» | В версиях 2.5+ ограничение «не срабатывает», хотя формально настроено | Устанавливать код ограничения на права «Чтение», «Изменение» и «Добавление» одновременно |
| Не обновили вспомогательные данные после изменения ролей | Новые настройки RLS не применяются, пользователи видят старые данные | Запустить обработку обновления вспомогательных данных после каждого изменения ролей |
| Забыли зарегистрировать нетиповой объект в общем модуле «УправлениеДоступомПереопределяемый» | Ограничение доступа на новый документ или справочник просто отсутствует | Явно добавить объект в список контролируемых таблиц перед вводом в эксплуатацию |
| Не протестировали доступ по каждой роли отдельно, а проверили только «в общем» | Отдельные редкие роли остаются без ограничений или наоборот блокируются полностью | Провести полное тестирование доступа по каждой роли, а не выборочно |
| Перешли в рабочую базу в период высокой нагрузки пользователей | Замедление работы всех пользователей одновременно во время пересчета прав | Планировать переход на период минимальной активности – вечер, выходные |
Как перейти правильно
-
Проведите инвентаризацию всех действующих правил RLS и доработок. Зафиксируйте список ролей, шаблонов ограничений и нетиповых объектов с настроенным доступом.
-
Включите производительный режим на тестовой базе. Разверните копию рабочей базы и переключите RLS именно там – без риска для пользователей.
-
Проведите полное тестирование доступа по ролям. Проверьте каждую роль отдельно: пользователь должен видеть ровно те данные, которые видел раньше, – не больше и не меньше.
-
Обновите вспомогательные данные и очистите параметры ограничений. Запустите соответствующую обработку после внесения изменений в роли и профили доступа.
-
Перенесите изменения в рабочую базу в период низкой нагрузки. Технологическое окно снижает риск того, что пересчет прав повлияет на работу активных пользователей.
Слово эксперта
«Самая частая причина провальных переходов на производительный RLS – попытка перенести правила «по аналогии», не проверяя каждую роль по отдельности. Механизм требует, чтобы для каждого нетипового объекта явно была описана процедура заполнения ограничения доступа – если ее забыли, объект просто не будет защищен, и это не покажет ошибку, пока кто-то не заметит, что видит чужие данные.
Поэтому тестирование по ролям – не формальность, а обязательный этап, который экономит недели разбора инцидентов после перехода».
– Титов Руслан, технический архитектор направления информационной безопасности «1С» в ГЭНДАЛЬФ
Нужна помощь с переходом на производительный RLS?
Мы поможем перейти без потери прав доступа пользователей и без риска для безопасности данных.
-
проведем аудит текущих правил RLS и нетиповых доработок в вашей базе;
-
перенесем и адаптируем шаблоны ограничений под производительный режим;
-
выполним нагрузочное тестирование прав доступа по каждой роли отдельно;
-
обновим вспомогательные данные и параметры ограничений доступа корректно;
-
сопроводим первый вход пользователей после перехода в рабочую базу.
Более 15 лет проектная команда ГЭНДАЛЬФ сопровождает технические миграции клиентов на новые версии платформы «1С» и конфигурации – включая сложные схемы доступа в холдингах и распределенных розничных сетях.
Оценить переходЧасто задаваемые вопросы
Права не пропадают автоматически, но при некорректном переносе правил отдельные роли могут временно потерять нужный доступ или, наоборот, получить лишний. Именно поэтому тестирование каждой роли на копии базы перед переходом в продуктив – обязательный, а не рекомендательный шаг.
Нужно протестировать доступ по каждой роли отдельно на тестовой базе: зайти под пользователем с этой ролью и убедиться, что он видит ровно тот набор данных, который видел раньше. Дополнительно стоит сформировать отчет по правам пользователя и сверить его со списком, составленным на этапе инвентаризации.
Да, если у вас действительно большой объем данных и много пользователей – производительный RLS вычисляет права заранее, а не при каждом запросе, что снижает нагрузку на СУБД. Для небольших баз с простыми ограничениями заметного ускорения может не быть, поскольку стандартный режим и без того справлялся с нагрузкой.
Список неподдерживаемых ролей есть в отраслевых решениях и некоторых модулях – их нужно выявить на этапе инвентаризации. Для таких ролей придется либо пересмотреть логику назначения прав, либо оставить ограничение через альтернативный механизм для конкретного объекта.
Формально можно оставаться на стандартном RLS, если он справляется с текущей нагрузкой. Но как только компания примет решение переходить на редакцию 2.6, отключение стандартного режима станет обязательным условием – поэтому разумнее спланировать переход заранее, а не в последний момент перед обновлением.
 1.png){kind=icon}
.png){kind=icon}