Подробный гайд по отладке RLS в 1С:Предприятие 8.3 - Часть 2

Практический гайд по отладке RLS в 1С:Предприятие 8.3. Разбор ролей, параметров сеанса, БСП, SQL и типичных ошибок доступа.

2026.09.15 #1С #программирование #БСП #SQL #запросы #RLS #администрирование #разработка

11. Технологический журнал 1С

Технологический журнал — мощный инструмент диагностики. Он помогает понять, что происходило на уровне сервера 1С и СУБД.

11.1. Что можно ловить

Полезные события:

EXCP — исключения и ошибки;
SCALL — серверные вызовы;
DBMSSQL — запросы к Microsoft SQL Server;
DBPOSTGRS — запросы к PostgreSQL;
RLS — если поддерживается конкретной версией/сборкой и включено.

Также могут быть полезны события блокировок, сеансов и производительности, но они увеличивают объем лога.

11.2. Пример logcfg.xml

Пример файла конфигурации технологического журнала:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
    <log location="C:\logs\1c\rls" history="1">

        <!-- Ошибки и исключения -->
        <event>
            <eq property="name" value="EXCP"/>
        </event>

        <!-- События применения RLS, если поддерживаются -->
        <event>
            <eq property="name" value="RLS"/>
        </event>

        <!-- Серверные вызовы -->
        <event>
            <eq property="name" value="SCALL"/>
        </event>

        <!-- Запросы к MSSQL длительностью более 1 секунды -->
        <event>
            <eq property="name" value="DBMSSQL"/>
            <ge property="duration" value="1000000"/>
        </event>

        <!-- Запросы к PostgreSQL длительностью более 1 секунды -->
        <event>
            <eq property="name" value="DBPOSTGRS"/>
            <ge property="duration" value="1000000"/>
        </event>

    </log>
</config>

duration обычно указывается в микросекундах. 1000000 — примерно 1 секунда. Для детальной отладки можно временно включить все запросы, но это может создать очень большой лог.

11.3. Что смотреть в логах

В технологическом журнале полезно искать:

Ошибки доступа.
Исключения при открытии формы.
Запросы, которые выполняются от имени проблемного пользователя.
Длительные запросы.
Запросы к таблицам, которые относятся к ограниченному объекту.
Наличие или отсутствие условий, похожих на RLS.
Параметры запросов, если они фиксируются.
Момент, где пользователь получает пустой результат.

11.4. Практика

Алгоритм такой:

Включить технологический журнал.
Зайти под проблемным пользователем.
Воспроизвести сценарий: открыть список, отчет, форму, выполнить действие.
Зафиксировать время.
Найти в логе события за этот период.
Посмотреть ошибки и SQL-запросы.
Сравнить поведение под администратором и под обычным пользователем.

12. Диагностика на стороне СУБД

12.1. Зачем нужен SQL-профайлер

Технологический журнал 1С показывает, что происходило в платформе, но иногда важно увидеть, какой SQL-запрос реально ушел в базу. RLS часто преобразуется в дополнительные условия WHERE, соединения или подзапросы.

Например, условие:

Организация = &МояОрганизация

в SQL может выглядеть как фильтр по полю _FldXXXX с параметром.

12.2. Для Microsoft SQL Server

Можно использовать:

Extended Events;
SQL Server Profiler, если доступен;
sp_WhoIsActive для текущих сессий;
Query Store для анализа производительности.

В минимальном случае ловите:

sql_batch_completed

или аналогичные события.

Полезные поля:

текст пакета;
длительность;
логические чтения;
пользователь;
имя приложения;
имя базы;
план запроса.

12.3. Для PostgreSQL

Можно использовать:

pg_stat_statements;
log_min_duration_statement;
auto_explain;
EXPLAIN ANALYZE;
лог запросов.

Для короткой диагностики можно временно включить логирование всех запросов на тестовой базе:

SET log_min_duration_statement = 0;

Но на продуктивной базе так делать нежелательно.

12.4. Что искать в SQL

Обращайте внимание:

Есть ли лишние JOIN.
Есть ли большие IN (...).
Есть ли преобразование типов.
Используются ли параметры.
Есть ли условия, которые всегда ложны.
Есть ли сканирование больших таблиц.
Есть ли функции в условиях, мешающие использованию индексов.
Нет ли многократного выполнения одного и того же запроса.

13. Практический пример отладки

Допустим, есть задача:

Пользователь должен видеть только заказы, где менеджер равен текущему пользователю.

13.1. Шаг 1. Проверка пользователя

Создаем пользователя test_manager. Назначаем роль МенеджерЗаказов. Убеждаемся, что нет роли ПолныеПрава.

13.2. Шаг 2. Проверка роли

В роли МенеджерЗаказов есть право чтения документа ЗаказКлиента.

Настроено ограничение:

Менеджер = &ТекущийМенеджер

Проверяем:

объект выбран правильно;
операция — чтение;
параметр существует;
имя параметра совпадает.

13.3. Шаг 3. Проверка параметра сеанса

Добавляем диагностику:

&НаСервере
Процедура ОтладкаRLS_ЗаписатьПараметр()

    ЗаписьЖурналаРегистрации(
        "ОтладкаRLS",
        УровеньЖурналаРегистрации.Информация,
        ,
        "ТекущийМенеджер = " + Строка(ПараметрыСеанса.ТекущийМенеджер)
    );

КонецПроцедуры

Выполняем под test_manager. Смотрим журнал регистрации.

Допустим, видим:

ТекущийМенеджер =

Значит параметр не заполнен. Это и есть причина, почему пользователь не видит заказы.

13.4. Шаг 4. Исправление заполнения параметра

Упрощенный пример заполнения:

Процедура ПриОпределенииПараметровСеанса(ПараметрыСеанса) Экспорт

    ПараметрыСеанса.ТекущийМенеджер =
        ПолучитьСсылкуНаМенеджераПоПользователю(
            ПользователиИнформационнойБазы.ТекущийПользователь()
        );

КонецПроцедуры

В реальной конфигурации получение менеджера может выполняться через:

справочник пользователей;
регистр сведений;
механизм БСП;
общий модуль управления доступом.

13.5. Шаг 5. Повторная проверка запросом

Выполняем:

Запрос = Новый Запрос;

Запрос.Текст =
"ВЫБРАТЬ
|   Заказ.Ссылка КАК Ссылка,
|   Заказ.Менеджер КАК Менеджер
|ИЗ
|   Документ.ЗаказКлиента РАЗРЕШЕННЫЕ КАК Заказ";

Результат = Запрос.Выполнить();

Сообщить("Количество строк: " + Результат.Выгрузить().Количество());

Теперь пользователь должен видеть только свои заказы.

13.6. Шаг 6. Проверка конкретной записи

Ссылка = Документы.ЗаказКлиента.НайтиПоНомеру("0000002", );

Сообщить("Чтение: " + ПравоДоступа("Чтение", Ссылка));

Если запись должна быть доступна, но функция возвращает Ложь, значит ограничение все еще не разрешает эту запись.

14. Типичные ошибки и решения

Ниже — типовые ситуации.

14.1. Пользователь не видит ничего

Причина	Что проверить
Параметр сеанса пустой	Заполняется ли параметр, какое значение
Параметр неверного типа	Тип реквизита и тип параметра
Пользователь не входит в группу доступа	Состав групп в БСП
Условие слишком жесткое	Текст ограничения
Ограничение задано не для той операции	Чтение, изменение, удаление
Записи не соответствуют условию	Проверить данные вручную
Кэш сеанса	Перезайти пользователем

14.2. Пользователь видит лишнее

Причина	Что проверить
Есть роль с полными правами	Состав ролей
Одна роль дает неограниченный доступ	Отключить лишние роли
Профиль БСП разрешает все	Настройки профиля
Запрос без `РАЗРЕШЕННЫЕ`	Текст запроса
Отчет читает данные в привилегированном режиме	Код отчета
Временная таблица заполнена без ограничений	Источник временной таблицы

14.3. Список пуст, но напрямую запись открывается

Причина	Что проверить
В списке стоят пользовательские отборы	Настройки списка
Форма списка использует собственный фильтр	Модуль формы
Динамический список читает данные иначе	Источник данных
Отбор по организации, складу, пользователю	Панель отборов
Кэш списка	Обновить/сбросить настройки

14.4. Запись видна, но не меняется

Причина	Что проверить
Нет права на изменение	Роли и права
Ограничение задано только на чтение	Условия для изменения
БСП запрещает изменение	Профили и группы
При записи читаются недоступные регистры	Код записи, движения
Используется привилегированный режим	Модули объекта и менеджера

14.5. Отчет показывает данные, которых нет в списке

Причина	Что проверить
В отчете нет `РАЗРЕШЕННЫЕ`	Запрос СКД
Отчет использует временные таблицы	Заполнение временных таблиц
Отчет выполняется под привилегированным пользователем	Контекст выполнения
СКД читает регистры без ограничений	Источники данных
В отчете специально отключены права	Настройки отчета

14.6. После изменения прав ничего не поменялось

Причина	Что проверить
Пользователь не перелогинился	Завершить сеанс и войти заново
Изменения не приняты	Обновить конфигурацию
Роль изменена в расширении, но расширение не активно	Активность расширения
Кэш 1С	Очистить кэш клиента
Кэш БСП	Обновить настройки прав, перезапустить сеанс
Рабочие процессы сервера 1С держат старые данные	Перезапуск процессов при необходимости

15. Привилегированный режим и административный доступ

15.1. Привилегированный режим

В коде 1С может использоваться:

УстановитьПривилегированныйРежим(Истина);

Он может отключать проверки прав доступа для некоторых операций.

При отладке RLS важно понимать:

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

15.2. Администраторы и полные права

Если проверяете RLS под администратором, результат может быть недостоверным.

Административный пользователь может:

не попадать под часть ограничений;
иметь полные права;
иметь специальные системные роли;
обходить проверки прав в некоторых механизмах.

Для диагностики создавайте отдельного пользователя с минимальными правами.

16. Фоновые задания, обмены и сервисы

16.1. Фоновые задания

Фоновые задания часто выполняются под пользователем с полными правами или под служебным пользователем.

Если данные обрабатываются фоном, проверьте:

под каким пользователем выполняется задание;
есть ли у этого пользователя ограничения;
не используется ли привилегированный режим;
должен ли фон вообще применять RLS.

Часто фон должен работать без пользовательских ограничений, но тогда нужно контролировать, какие данные он возвращает в пользовательский интерфейс.

16.2. Обмены данными

Обмены обычно выполняются под привилегированным пользователем. RLS в обменах может не применяться. Это нормально, если обмен так спроектирован. Но если обмен возвращает данные в пользовательский интерфейс, безопасность должна быть обеспечена на уровне интерфейса или повторной проверки прав.

16.3. Веб-сервисы и HTTP-сервисы

Для сервисов проверьте:

под каким пользователем аутентифицируется запрос;
есть ли у пользователя права;
применяются ли ограничения;
не выполняется ли код в привилегированном режиме;
не возвращает ли сервис данные без проверки доступа.

Особенно опасно, когда сервис читает данные через запрос без РАЗРЕШЕННЫЕ и возвращает их внешнему клиенту.

17. Производительность RLS

17.1. Почему RLS тормозит

Ограничения могут приводить к:

дополнительным соединениям;
подзапросам;
большим спискам IN;
сложным условиям ИЛИ;
проверкам нескольких параметров;
многократным вычислениям одного и того же условия;
отсутствию индексов по полям из условия.

17.2. Рекомендации по производительности

1. Используйте простые условия

Лучше:

Организация = &МояОрганизация

Чем сложные цепочки:

(Организация В (&Организации) ИЛИ Подразделение В (&Подразделения) ИЛИ Ответственный В (&Ответственные))

Если такие условия действительно нужны, проверяйте план запроса.

2. Избегайте огромных массивов значений

Плохо:

Ссылка В (&ОгромныйМассивСсылок)

Лучше хранить разрешенные значения в регистре сведений или временной таблице и соединять с ней.

3. Индексируйте поля из условий

Если условие использует:

Организация = &Организация

то поле Организация должно быть индексировано или входить в состав подходящего индекса. Если условие использует составной фильтр:

Организация = &Организация
И Склад = &Склад

рассмотрите составной индекс.

4. Проверяйте план запроса

Ищите:

сканирование больших таблиц;
дорогие соединения;
повторное вычисление подзапросов;
неявные преобразования типов;
отсутствие использования индексов.

5. Кэшируйте значения доступа осторожно

Кэш может ускорить заполнение параметров сеанса, но он должен корректно инвалидироваться при изменении прав. Если пользователь изменил группу доступа, но кэш старый, он может временно видеть лишнее или не видеть нужное.

6. Не применяйте ограничения там, где они не нужны

Если служебный алгоритм должен читать все данные, но не возвращает их пользователю, возможно, лучше выполнять его под привилегированным пользователем, а пользовательский доступ ограничивать на этапе выдачи данных. Но это нужно делать осознанно и безопасно.

18. Проверка безопасности после настройки

После исправлений обязательно выполните регрессионную проверку.

18.1. Минимальный набор тестов

Для каждого объекта и роли проверьте:

Пользователь видит только разрешенные записи.
Пользователь не видит запрещенные записи.
Пользователь может открыть разрешенную запись.
Пользователь не может открыть запрещенную запись.
Пользователь может изменить разрешенную запись, если должно быть можно.
Пользователь не может изменить запрещенную запись.
Отчеты показывают только разрешенные данные.
Списки показывают только разрешенные данные.
Веб-сервисы не возвращают лишнего.
Фоновые задания не выдают лишнего в пользовательский интерфейс.

18.2. Матрица доступа

Полезно составить таблицу:

Пользователь	Роль / группа	Объект	Запись	Ожидаемое чтение	Ожидаемое изменение
user1	Менеджеры	Заказ №1	свой	Да	Да
user1	Менеджеры	Заказ №2	чужой	Нет	Нет
user2	Кладовщики	Расход №1	свой склад	Да	Нет

Такая матрица экономит время и делает проверку доказуемой.

19. Частые ошибки проектирования

19.1. Ограничили один объект, но не ограничили связанные данные

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

19.2. RLS используется как единственный уровень защиты

RLS не заменяет:

права на объекты метаданных;
права на реквизиты;
проверку в коде;
защиту сервисов;
аудит безопасности;
безопасное проектирование отчетов.

19.3. Ограничение зависит от сложной бизнес-логики

Если условие доступа зависит от расчета, который сложно выполнить в RLS, лучше заранее рассчитать разрешенные значения и хранить их в регистре или таблице соответствий.

19.4. Параметры сеанса заполняются ненадежно

Если параметр сеанса может остаться пустым из-за ошибки, лучше явно запретить работу или записать ошибку в журнал. Плохо, когда система молча показывает пустой список, и пользователь думает, что данных нет.

19.5. Тестирование только под администратором

Администратор может не попадать под ограничения. Если тестировать только под ним, можно пропустить серьезную ошибку доступа.

20. Пошаговый алгоритм отладки

Ниже — краткий алгоритм, который можно использовать как чек-лист.

Шаг 1. Сформулировать проблему

Ответьте:

Кто пользователь?
Какой объект?
Какая запись?
Какая операция?
Что ожидается?
Что происходит фактически?

Шаг 2. Проверить пользователя

Пользователь активен.
Пользователь не администратор.
Нет роли с полными правами.
Назначены только нужные роли.
Если БСП — пользователь в нужных группах.

Шаг 3. Проверить права на объект

Есть право на чтение.
Есть право на просмотр, если нужно открытие формы.
Есть право на изменение, если проблема с записью.
Нет конфликтов между ролями.

Шаг 4. Проверить условие RLS

Условие задано для нужной операции.
Поле указано правильно.
Оператор правильный.
Параметр сеанса существует.
Параметр заполняется.
Тип параметра подходит.

Шаг 5. Проверить параметры сеанса

Параметр заполняется при входе.
Значение не пустое.
Значение корректное для пользователя.
После изменений пользователь перезашел.
Нет кэша.

Шаг 6. Проверить запросом

Выполнить запрос с РАЗРЕШЕННЫЕ.
Выполнить запрос без РАЗРЕШЕННЫЕ только для диагностики.
Проверить количество строк.
Проверить конкретную запись через ПравоДоступа.

Шаг 7. Проверить интерфейс

Список: отборы, настройки, фильтры.
Форма объекта: модуль формы, связанные данные.
Отчет: текст запроса, временные таблицы, привилегированный режим.
Сервис: пользователь аутентификации и контекст выполнения.

Шаг 8. Включить технологический журнал

Включить EXCP.
Включить RLS, если поддерживается.
Включить SCALL.
При необходимости включить DBMSSQL или DBPOSTGRS.
Воспроизвести ошибку.
Проанализировать лог за точное время.

Шаг 9. При проблемах производительности посмотреть SQL

Технологический журнал.
SQL Profiler или Extended Events.
PostgreSQL log / pg_stat_statements.
План запроса.
Индексы.
Большие списки значений.

Шаг 10. Исправить и перепроверить

Внести минимальное изменение.
Перезапустить сеанс пользователя.
Повторить сценарий.
Проверить матрицу доступа.
Убедиться, что не появились лишние права.

21. Экспресс-чек-лист

Если нужно быстро проверить проблему, пройдитесь по этому списку.

Пользователь

[ ] Тест выполняется не под администратором.
[ ] Нет роли с полными правами.
[ ] Пользователь состоит в нужных группах.
[ ] Пользователь перелогинился после изменений.

Права

[ ] Есть право на объект.
[ ] Есть право на нужную операцию.
[ ] Нет конфликтующих ролей.
[ ] Расширения не добавляют лишние права.

Параметры сеанса

[ ] Параметр существует.
[ ] Параметр заполняется.
[ ] Значение не пустое.
[ ] Тип значения корректный.
[ ] Значение соответствует пользователю.

Условие ограничения

[ ] Условие относится к нужному объекту.
[ ] Условие относится к нужной операции.
[ ] Поля и операторы корректны.
[ ] Нет опечаток.
[ ] Условие не всегда ложно.
[ ] Условие не всегда истинно.

Запросы

[ ] В запросе используется РАЗРЕШЕННЫЕ, если нужно.
[ ] Временные таблицы заполняются с учетом прав.
[ ] Отчет не читает данные в привилегированном режиме.
[ ] СКД не обходит ограничения.

БСП

[ ] Профиль не дает полный доступ.
[ ] Группа доступа настроена.
[ ] Значения доступа назначены.
[ ] Нет конфликтующих групп.
[ ] Вид доступа включен для объекта.

Диагностика

[ ] Проверено через ПравоДоступа.
[ ] Проверено запросом под пользователем.
[ ] Включен технологический журнал.
[ ] Проанализированы ошибки.
[ ] Проанализированы SQL-запросы.

22. Главная мысль при отладке RLS

Отладка RLS в 1С почти всегда сводится к четырем вопросам:

Кто пользователь?
Какие у него роли, группы и профили?
Какие параметры сеанса и значения доступа у него реально установлены?
Где именно читаются данные: список, форма, запрос, отчет, сервис, временная таблица?

Если последовательно ответить на эти вопросы, проблема обычно локализуется до одного из слоев:

роль;
параметр сеанса;
условие RLS;
БСП;
запрос;
код формы или отчета;
привилегированный режим;
производительность СУБД.

23. Краткая шпаргалка

Задача	Инструмент
Проверить видимость записей	Запрос с `РАЗРЕШЕННЫЕ`
Проверить доступ к конкретной записи	`ПравоДоступа`
Проверить параметры сеанса	Серверный код + журнал регистрации
Найти ошибки	Технологический журнал, событие `EXCP`
Найти тяжелые запросы	Технологический журнал, SQL-профайлер
Проверить настройки БСП	Группы доступа, профили, значения доступа
Проверить отчет	Текст запроса СКД, временные таблицы
Проверить форму	Модуль формы, связанные данные
Исключить админский доступ	Тестовый пользователь без полных прав
Проверить производительность	План запроса, индексы, длительность запросов

Мы делимся этой технической информацией, чтобы помочь вам в решении задач — используйте её с пониманием. Статья носит рекомендательный характер, поэтому, пожалуйста, применяйте описанные методы осмотрительно.

Статью подготовил: Аверко Денис Сергеевич @Nymexis г. Омск (специалист по ЗИ)