Механизм RLS (Row-Level Security) в 1С:Предприятии является мощным инструментом разграничения прав доступа на уровне записей базы данных. Однако его настройка требует четкого понимания того, как платформа обрабатывает запросы к данным. Рассмотрим основные аспекты настройки RLS на примере конфигурации «Управление торговлей 10.3» и выясним, как правильно выстроить систему ограничений.
Разберем типичное заблуждение: «Если я ограничу чтение справочника Организации, то пользователь автоматически перестанет видеть документы по запрещенным организациям». Это не так.
В системе 1С условия RLS действуют строго на те таблицы метаданных, на которые они наложены. Проанализируем ситуацию: если вы установили шаблон ограничения только на справочник Организации, но не тронули документы (например, РеализацияТоваровУслуг), пользователь по-прежнему сможет открыть список документов и сами документы. Однако в поле «Организация» он увидит надпись «Объект не найден» (или пустую ссылку), так как права на чтение конкретной записи справочника у него отсутствуют, а права на чтение самого документа — есть.
Для корректной работы системы фильтрации необходимо прописывать условия ограничения (или указывать шаблоны) для каждого объекта метаданных, где используется данный реквизит:
Организация.Важно помнить о фундаментальном принципе безопасности 1С: действует политика разрешения. Это означает, что если пользователю назначено несколько ролей, то доступ к объекту будет разрешен, если он разрешен хотя бы в одной из этих ролей. Условия RLS в разных ролях объединяются по логическому закону ИЛИ.
Если в одной роли вы жестко ограничили доступ к документам по организации, а в другой роли (например, добавленной позже для других целей) дали полные права на этот же документ без RLS — пользователь увидит абсолютно все записи. Перед внедрением RLS необходимо убедиться, что ни одна из других ролей пользователя не дает неограниченный доступ к целевым объектам.
Когда требуется ограничить доступ одновременно по нескольким критериям (например, по Организации и по Контрагенту), возникает вопрос о количестве шаблонов. В рамках одного права (например, на «Чтение») для одного объекта метаданных можно прописать текст ограничения, который будет сочетать в себе проверку нескольких полей.
Рассмотрим пример логики ограничения, когда нам нужно проверить доступ и по организации, и по контрагенту. В типовых конфигурациях (таких как УТ 10.3 или УПП) часто используются комплексные шаблоны. Если вы создаете свое ограничение, оно должно выглядеть примерно так:
ГДЕ Организация В (&ПараметрСеанса_ДоступныеОрганизации)
И (Контрагент = ЗНАЧЕНИЕ(Справочник.Контрагенты.ПустаяСсылка)
ИЛИ Контрагент В (&ПараметрСеанса_ДоступныеКонтрагенты))
Использование конструкции ГДЕ ЛОЖЬ фактически означает полный запрет на чтение данных из таблицы для данной роли. Если же вам нужно применить фильтр, необходимо использовать либо прямой запрос на языке запросов 1С, либо обратиться к имеющемуся шаблону через символ #.
Применение RLS неизбежно ведет к снижению производительности, так как платформа динамически модифицирует каждый SQL-запрос, добавляя в него условия фильтрации. Проанализируем, как минимизировать негативное влияние:
Организация.ГоловнаяОрганизация.Код). Каждая такая точка — это неявное соединение (JOIN) в SQL-запросе, которое выполняется для каждой строки таблицы.РАЗРЕШЕННЫЕ: Выясним важную деталь программной разработки. Если вы делаете выборку в коде или отчете, всегда используйте ВЫБРАТЬ РАЗРЕШЕННЫЕ. Если этого не сделать, и запрос попытается прочитать хотя бы одну «запрещенную» запись, система выдаст ошибку нарушения прав доступа.Писать сложные условия RLS вручную в текстовом поле роли неудобно. Начиная с платформы 8.3, в распоряжении разработчика есть Конструктор ограничений доступа, который позволяет визуально составлять условия и работать с шаблонами. В типовых конфигурациях на базе БСП (Библиотека стандартных подсистем) механизм RLS значительно модернизирован и использует специальные «ключи доступа», что работает быстрее классических шаблонов, но требует строгого соблюдения методики БСП при добавлении новых объектов в систему.
Для проверки того, как именно RLS ограничивает данные, рекомендуется использовать «Консоль запросов», запущенную под пользователем с ограниченными правами. Если результаты запроса с ключевым словом РАЗРЕШЕННЫЕ соответствуют ожиданиям, значит, логика шаблона настроена верно.