RLS

Основные принципы

• Логика разрешений: В 1С действует принцип "запрещено всё, что явно не разрешено"
• Нет механизмов запрета: Есть только механизмы выдачи доступа
• Итоговые права: Объединение (OR) всех прав из всех ролей пользователя

Стандартный режим

Проверка прав "на лету" через сложные SQL-запросы

Архитектура:

• Константа: ОграничениеДоступаНаУровнеЗаписейУниверсально = ЛОЖЬ
• Проверка с использованием регистров сведений: ТаблицыГруппДоступа, ЗначенияГруппДоступа
• Особенность: Мгновенная актуальность прав

Недостаток такого подхода заключается в масштабируемости, чем больше видов доступа настраиваем для объекта, тем больше финальный текст запроса в СУБД и количество левых соединение в нем.

4 типа шаблонов:

1. #ПоЗначениям - базовый отбор

#ПоЗначениям( "Документ.ПриобретениеТоваровУслуг","Чтение","",
"Организации","Организация",
"Склады","Склад",
"ГруппыПартнеров","Партнер",
"Подразделения","Подразделение", "","", "","", "","", "","", "","", "","", "","", "","", "","", "","", "","", "","" )

• Назначение: Ограничение доступа по реквизитам объекта (например, по организации, складу).
• Логика: Все условия соединяются по логическому «И». Объект доступен, если все указанные реквизиты объекта входят в разрешённые пользователю значения.
• Особенности:
  • Поддерживает до 16 пар "вид доступа — реквизит".
  • Можно использовать «Условие» для жёстких отборов языком запросов.
  • Можно проверять права на чтение/изменение связанных объектов (например, владельца файла).

2. #ПоНаборамЗначений - для уникальных наборов

#ПоНаборамЗначений( "Документ.УстановкаЦенНоменклатуры","Чтение","","")

• Назначение: Для объектов, где набор проверяемых значений уникален для каждого элемента (журналы, табличные части).
• Логика: Проверяет, входят ли все значения заранее подготовленного для объекта набора в разрешённые пользователю значения (проверка по «И» внутри набора).
• Как работает:
  1. В объект добавляется специальная табличная часть «Наборы значений доступа».
  2. Перед записью объекта процедура заполняет её нужными значениями (например, видами цен из документа).
  3. Данные переносятся в регистр сведений для быстрой проверки при чтении.
• Расширение: Можно группировать значения по «Номер набора». Тогда наборы проверяются по логическому «ИЛИ» (достаточно доступа к одному набору).

3. #ПоЗначениямРасширенный - сложная логика

#ПоЗначениямРасширенный("Документ.ПеремещениеТоваров", "Чтение", "",
"Внутреннее Соединение Документ.ПеремещениеТоваров.Номенклатура КАК Т2 по Т.Ссылка = Т2.Ссылка", 
"",
"Организации", "Т.Организация", "И(",
"Склады", "Т.СкладОтправитель", "ИЛИ",
"Склады", "Т.СкладПолучатель", ")И",
"ГруппыНоменклатуры", "Т2.Номенклатура", "", …)

• Назначение: Решает главное ограничение #ПоЗначениям — позволяет использовать логику «ИЛИ» между условиями.
• Логика: Можно задавать сложные логические связи (И, ИЛИ, скобки) между проверками разных реквизитов.
• Особенности:
  • Позволяет подключать дополнительные таблицы (например, табличную часть документа) и проверять реквизиты в них.
  • Для проверки по табличной части объект будет доступен, если условие выполнится хотя бы для одной строки.

4. #ПоЗначениямИНаборамРасширенный - комбинированный

• Назначение: Комбинирует все возможности предыдущих шаблонов.
• Логика: Позволяет использовать:
  1. Сложную логику (И/ИЛИ) между условиями по реквизитам.
  2. Проверку по наборам значений через специальный вид доступа "Объект".
• Важно: Самый ресурсоёмкий шаблон. Следует применять только при реальной необходимости, когда остальные шаблоны не подходят.

Проблемы стандартного режима:

1. Сложные SQL-запросы: Много JOIN'ов с ТаблицыГруппДоступа
2. Неоптимальные планы: Появление Index Spool, Row Count Spool
3. Масштабируемость: Производительность падает при увеличении видов доступа

Производительный режим

Предварительный расчёт ключей доступа + быстрая проверка

Архитектура:

• Константа: ОграничениеДоступаНаУровнеЗаписейУниверсально = ИСТИНА
• Шаблон в роли: #ДляОбъекта("")
• Логика в коде: Процедура ПриЗаполненииОграниченияДоступа()

Ключевые объекты системы:

• Справочник.КлючиДоступа (хэш, значение1-5)
• РегистрСведений.КлючиДоступаКОбъектам
• РегистрСведений.КлючиДоступаПользователей│

Синтаксис ограничений:

Процедура ПриЗаполненииОграниченияДоступа(Ограничение) Экспорт
    Ограничение.Текст =
    "РазрешитьЧтениеИзменение
    |ГДЕ
    |    ЗначениеРазрешено(Организация)
    |    И ЗначениеРазрешено(Контрагент)";
КонецПроцедуры

Основные конструкции:

Тип	Назначение	Пример
Типы ограничений
РазрешитьЧтениеИзменение	Полный доступ	Основной тип
РазрешитьИзменениеЕслиРазрешеноЧтение	Ограниченное изменение
Функции проверки
ЗначениеРазрешено()	Проверка значения	ЗначениеРазрешено(Организация)
ЧтениеОбъектаРазрешено()	Проверка через объект	ЧтениеОбъектаРазрешено(Владелец)
ДляВсехСтрок()	Проверка всех строк Т (И)	ДляВсехСтрок(ЗначениеРазрешено(...))
ДляОднойИзСтрок()	Проверка хотя бы одной строки (ИЛИ)	ДляОднойИзСтрок(...)

Сравнительная таблица:

Критерий	Стандартный RLS	Производительный RLS
Производительность чтения	Низкая (сложные запросы)	Высокая (фиксированный запрос)
Производительность записи	Выше	Ниже (обновление ключей)
Актуальность прав	Мгновенная	С задержкой (регламентное задание)
Масштабируемость	Плохая	Отличная
Сложность настройки	Проще (шаблоны в ролях)	Сложнее (код в объектах)
Планы запросов	Сложные, нестабильные	Простые, предсказуемые
Использование tempdb	Частое (Spool операторы)	Минимальное

Переход на производительный режим

Предварительные требования:

• БСП версии 3.0.1 и выше
• Обновлённые типовые роли

Пошаговая процедура:

1. Включение режима:

   • Ограничивать доступ на уровне записей = Истина
   • Ограничивать доступ на уровне записей Производительный = Истина

2. Обновление ролей:

   #Если &ОграничениеДоступаНаУровнеЗаписейУниверсально #Тогда
       #ДляОбъекта("")
   #Иначе
       #ПоЗначениям(...)
   #КонецЕсли

3. Регистрация объектов:

   // В УправлениеДоступомПереопределяемый
   Процедура ПриЗаполненииСписковСОграничениемДоступа(Списки)
       Списки.Вставить(Метаданные.Документы.МойДокумент, Истина);
   КонецПроцедуры

4. Описание ограничений в модуле менеджера объекта

5. Добавление в определяемые типы:

   • ВладелецЗначенийКлючейДоступаДокумент (для документов)
   • ВладелецЗначенийКлючейДоступаОбъект (для справочников)
   • ВладелецЗначенийКлючейДоступаНаборЗаписей (для регистров)

6. Добавление обработчиков в форму:

   &НаСервере
   Процедура ПриЧтенииНаСервере(ТекущийОбъект)
       УправлениеДоступом.ПриЧтенииНаСервере(ЭтотОбъект, ТекущийОбъект);
   КонецПроцедуры
   
   &НаСервере
   Процедура ПослеЗаписиНаСервере(ТекущийОбъект, ПараметрыЗаписи)
       УправлениеДоступом.ПослеЗаписиНаСервере(...);
   КонецПроцедуры

7. Обновление ключей через обработку "Обновление доступа на уровне записей"

Инструменты для работы

Для разработки:

1. Обработка "УправлениеДоступом" — визуальный редактор ограничений
2. Проверка синтаксиса — встроенная проверка текстов ограничений

Для администрирования:

1. Обработка "Обновление доступа на уровне записей" — ручное управление ключами
2. Регламентное задание — автоматическое обновление ключей
3. Отчёт "Права доступа" — анализ итоговых прав пользователей

Важные нюансы и проблемы

Особенности производительного режима:

• Задержка прав: 5-15 минут до обновления ключей
• Объём данных: Справочник "КлючиДоступа" может быть большим
• Проверка записи: В модуле объекта, требует аккуратной реализации

Потенциальные проблемы:

1. Ранние версии БСП (< 3.1.3.179): Ошибки в компоновке запросов
2. Дублирование ролей: Неправильная настройка может давать избыточные права
3. Производительность записи: Дополнительная нагрузка при обновлении ключей

Рекомендации по оптимизации:

• Настраивать обновление ключей в часы минимальной нагрузки
• Регулярно анализировать размер справочника "КлючиДоступа"
• Использовать выборку обновления по конкретным объектам

Критерии выбора режима

Выбирать производительный RLS если: ✅ Много пользователей с ограниченными правами (50+)
✅ Сложная схема доступа (3+ вида доступа на объект)
✅ Преобладают операции чтения над записью
✅ Большие объёмы данных (100 тыс.+ записей)
✅ Частые выборки в динамических списках

Оставаться на стандартном RLS если: ✅ Простые ограничения (1-2 вида доступа)
✅ Преобладают операции записи
✅ Малые/средние объёмы данных
✅ Критична мгновенная актуальность прав
✅ Нет возможности обновить БСП до 3.0.1+

Выводы и рекомендации

Преимущества производительного RLS:

1. Производительность чтения: Ускорение в 2-10 раз
2. Масштабируемость: Стабильная работа при любом количестве видов доступа
3. Предсказуемость: Простые планы запросов в СУБД
4. Гибкость: Богатый язык описания ограничений

Стоимость перехода:

• Время разработки: Описание ограничений в коде объектов
• Накладные расходы: Дополнительные 2-4% на операциях записи
• Администрирование: Регулярное обновление ключей

Материалы

• Возможности типовых шаблонов ограничения доступа на уровне записей (RLS)

• Производительный режим работы RLS

• От экспертов «1С-Рарус»: Производительность нового RLS в 1С БСП 3. Переходить или нет?