В процессе настройки прав доступа в конфигурации «Управление нашей фирмой» (УНФ) программисты часто сталкиваются с ситуацией, когда пользователь видит данные, к которым, на первый взгляд, у него нет доступа. Типичный пример — работа с документом Событие. Пользователь может не иметь прав на справочник УчетныеЗаписиЭлектроннойПочты, но при этом спокойно просматривать содержание писем в документах типа «Электронное письмо». Разберемся, как устроена эта логика, как извлечь реальный текст RLS и почему стандартные отчеты по правам не всегда дают полную картину.
Для начала проанализируем, где именно зарыты условия ограничения доступа. В 1С RLS (Record Level Security) настраивается на уровне ролей. Если у пользователя есть роль, например, «Добавление и изменение событий и заданий», нам необходимо найти её в дереве конфигурации.
Рассмотрим последовательность действий для получения текста шаблона:
Документ.Событие.#ПоЗначениям("Документ.Событие","Чтение","", ... ).Важный момент: просматривать сложные запросы непосредственно в маленьком окне конфигуратора крайне неудобно. Рекомендуется скопировать текст шаблона и текст ограничений в текстовый редактор (блокнот или VS Code), чтобы увидеть структуру параметров, передаваемых в типовые механизмы БСП (Библиотеки стандартных подсистем).
Выясним причину, по которой отсутствие прав на учетную запись почты не блокирует чтение самого события. В архитектуре 1С:Предприятие права на объект и права на его реквизиты работают следующим образом:
Если у пользователя есть право на «Чтение» документа Событие, он видит все его реквизиты, включая Тема, ТекстПисма и ссылку на УчетнуюЗапись. Даже если на справочник УчетныеЗаписиЭлектроннойПочты наложен строгий RLS, платформа просто скроет детали самой учетной записи (в поле будет отображаться «Объект не найден»), но данные самого документа (текст сообщения) останутся доступными. Это происходит потому, что текст письма хранится непосредственно в документе или в связанных с ним присоединенных файлах, а не «подтягивается» динамически из почтового сервера при каждом открытии.
Проанализируем ситуацию: для защиты содержимого писем необходимо накладывать ограничения именно на объект Документ.Событие, а не только на настройки почты. Настройки учетных записей обычно ограничиваются для того, чтобы рядовые сотрудники не могли изменять пароли или отправлять почту от чужого имени, но просмотр входящей корреспонденции регулируется правами на взаимодействия.
В современных версиях УНФ механизм RLS может работать в двух режимах, что существенно влияет на то, где искать «текст» запроса:
1. Стандартный режим. Текст запроса формируется платформой на лету на основании того, что написано в роли в конфигураторе. Это те самые условия ГДЕ..., которые мы видим в шаблонах.
2. Производительный режим. В этом режиме в конфигураторе прописан лишь короткий вызов функции БСП. Реальная проверка прав происходит через специальные регистры сведений, такие как КлючиДоступаКОбъектам и КлючиДоступаПользователей. Система заранее рассчитывает, к каким «ключам» у пользователя есть доступ, и просто соединяет таблицу документа с таблицей ключей.
Чтобы увидеть итоговый запрос в производительном режиме, стандартного просмотра ролей недостаточно. Рассмотрим способы отладки:
Одним из самых эффективных методов является запуск специализированной консоли запросов (например, из состава инструментов разработчика). Посмотрим на алгоритм проверки:
ВЫБРАТЬ * ИЗ Документ.Событие.Если нам нужно увидеть абсолютно точный SQL-запрос, который уходит на сервер СУБД, придется обратиться к Технологическому журналу (ТЖ). Это «тяжелая артиллерия», позволяющая выяснить причину избыточных прав. Разберем пример настройки logcfg.xml для отлова таких событий:
<event query="DBMSSQL">
<condition>
<contains name="sql" value="Event" />
</condition>
</event>
Проанализировав лог ТЖ, мы увидим секцию WHERE, в которой будут перечислены все идентификаторы (GUID), по которым система фильтрует документы. Если в этом списке окажутся лишние документы, значит, проблема в логике заполнения регистров доступа БСП.
В конфигурациях на базе БСП логика прав часто описывается программно. Нам следует изучить общий модуль УправлениеДоступомПереопределяемый, процедуру ПриЗаполненииСписковОграниченияДоступа. Посмотрим, как это выглядит в коде:
Процедура ПриЗаполненииСписковОграниченияДоступа(Списки) Экспорт
Списки.Вставить(Метаданные.Документы.Событие, Истина);
КонецПроцедуры
Если документ включен в этот список, значит, его RLS управляется централизованно через БСП. В этом случае нужно проверять не текст в конфигураторе, а настройки в режиме «Предприятие» (раздел «Настройки пользователей и прав» — «Группы доступа»).
Если вы обнаружили, что пользователь видит лишние события, рекомендуем выполнить следующие шаги:
Таким образом, для получения текста RLS на документ Событие в УНФ недостаточно просто заглянуть в конфигуратор. Необходимо учитывать специфику БСП, режим работы ограничений и понимать, что содержимое документа и настройки учетной записи — это независимые с точки зрения безопасности объекты базы данных.