Как настроить RLS в 1С: ограничение доступа на уровне записей

RLS (Record Level Security) — механизм платформы 1С:Предприятие, который ограничивает доступ пользователей не к объектам целиком, а к отдельным записям внутри них. Например, менеджер видит только свои документы продаж, а кладовщик — только остатки своего склада, хотя оба работают с одними и теми же таблицами.

Без RLS ограничение доступа реализуется только на уровне объектов метаданных: роль либо даёт право чтения документа «Реализация товаров» целиком, либо не даёт вовсе. RLS добавляет к запросам дополнительные условия отбора, и пользователь физически не может получить «чужие» строки — ни через форму списка, ни через отчёт, ни через запрос в консоли.

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

Как работает механизм RLS и когда он нужен

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

Типовые сценарии применения RLS: разделение данных между организациями в одной базе, доступ менеджеров только к своим контрагентам и сделкам, ограничение складских документов по складам, разграничение кадровых данных по подразделениям. В типовых конфигурациях (ERP, УТ, БП) механизм уже реализован — его нужно только включить и настроить.

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

Подготовка: параметры сеанса и права

Перед настройкой RLS нужно определить, по какому признаку будут разделяться данные, и создать соответствующий параметр сеанса. В конфигураторе откройте ветку «Общие → Параметры сеанса» и добавьте параметр нужного типа — например, «ТекущаяОрганизация» типа «СправочникСсылка.Организации» или «ТекущийПользователь» типа «СправочникСсылка.Пользователи».

Параметр сеанса должен заполняться при старте сеанса, иначе ограничение получит пустое значение и отберёт ноль записей. Заполнение выполняется в модуле сеанса в обработчике «УстановкаПараметровСеанса»:

Процедура УстановкаПараметровСеанса(ТребуемыеПараметры)
	Если ТребуемыеПараметры = Неопределено
		Или ТребуемыеПараметры.Найти("ТекущийПользователь") <> Неопределено Тогда
		ПараметрыСеанса.ТекущийПользователь = ПользователиИнформационнойБазы.ТекущийПользователь().Имя;
	КонецЕсли;
КонецПроцедуры

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

Настройка ограничения в роли

Откройте роль, через которую пользователи получают доступ к объекту (в типовых конфигурациях лучше не менять типовые роли, а создать свою или использовать механизм профилей групп доступа). Выделите нужный объект метаданных — например, документ «Реализация товаров и услуг».

В правой части окна роли, на закладке «Шаблоны ограничений», создайте новый шаблон. Пример простого шаблона ограничения по организации:

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

Затем на закладке «Права» для права «Чтение» (и при необходимости «Добавление», «Изменение», «Удаление») в поле «Ограничение доступа» укажите созданный шаблон. Для права «Чтение» ограничение обычно задаётся для всех полей, для остальных прав — тоже, иначе пользователь сможет изменить запись, которую не видит.

1. 1
   Создайте или проверьте параметр сеанса (Общие → Параметры сеанса)
2. 2
   Убедитесь, что параметр заполняется в модуле сеанса
3. 3
   Откройте роль и добавьте шаблон ограничения на закладке «Шаблоны ограничений»
4. 4
   Привяжите шаблон к правам Чтение/Добавление/Изменение/Удаление нужного объекта
5. 5
   Назначьте роль тестовому пользователю и проверьте видимость записей

Настройка RLS в типовых конфигурациях

В типовых решениях на БСП (Библиотека стандартных подсистем) ручное редактирование ролей обычно не требуется. Ограничение на уровне записей включается в настройках: «Администрирование → Настройки прав и пользователей» — флаг «Ограничивать доступ на уровне записей». После включения платформа начнёт применять уже встроенные шаблоны.

Далее настраиваются профили групп доступа и сами группы доступа. Например, чтобы менеджер видел только документы своей организации, создаётся группа доступа, в которой в качестве значения доступа указана конкретная организация, и в неё включаются нужные пользователи. Виды доступа (организации, склады, контрагенты, подразделения) включаются в карточке профиля.

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

Проверка работы ограничений

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

Контрольные точки: список документов показывает только разрешённые записи; отчёт по тем же данным не выводит чужие строки; быстрый поиск по номеру «чужого» документа не находит его; при попытке открыть чужой документ по прямой ссылке система сообщает о нарушении прав или показывает пустую форму.

Дополнительно полезно проверить заполнение параметра сеанса через консоль кода: вывести значение параметра в сообщение. Пустое значение параметра — самая частая причина ситуации «пользователь не видит вообще ничего».

Производительность и типичные ошибки

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

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

Когда RLS не подходит: альтернативы

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

Если требуется ограничить доступ к целым разделам учёта (например, скрыть зарплату от бухгалтера по товарам), достаточно обычных ролей без RLS — это дешевле по производительности. RLS оправдан только тогда, когда пользователи работают с одним объектом, но с разными наборами записей.

Частые вопросы по настройке RLS