Пользователь видит чужие данные или получает отказ: разбираем RLS по шагам
Содержание
Проверить РЛС в 1С быстрее всего так: зайти в базу под нужным пользователем (или под его копией с теми же группами доступа), открыть проблемный список или отчёт и сравнить результат с ожиданием. Если результат не совпадает — смотреть роли пользователя, настройки групп доступа и текст ограничения, а для медленных запросов — технологический журнал и план запроса в СУБД.
РЛС (RLS, Record Level Security) — это ограничение доступа к данным на уровне записей и полей. Оно задаётся в ролях конфигурации и решает, какие строки справочников, документов и регистров увидит конкретный пользователь. Ниже — проверка от простого к сложному: от интерфейса пользователя до SQL-запроса, который платформа отправляет в базу.
Что такое RLS в 1С и когда его нужно проверять
Ограничение на уровне записей — это условие, которое платформа добавляет к каждому обращению к таблице. Пользователь с ограничением по организации читает документы только своей организации, даже если открывает общий журнал.
Условие пишется в роли, на закладке ограничений доступа к данным, на языке, похожем на язык запросов. Ограничение задаётся отдельно для прав Чтение, Добавление, Изменение, Удаление.
Когда проверка нужна:
- 🔓 пользователь видит документы чужого подразделения или склада;
- 🚫 пользователь не видит свои документы или получает ошибку прав при открытии списка или отчёта;
- 🐢 после включения ограничений списки и отчёты стали открываться в разы дольше;
- 🔄 после обновления конфигурации поменялось поведение прав;
- 🧩 вы доработали роль или добавили объект в расширение и хотите убедиться, что ограничение на нём работает.
Три правила, которые объясняют большинство сюрпризов
- Права ролей складываются. Если хотя бы одна роль пользователя даёт право на объект без ограничения, ограничения из других ролей на это право не действуют. Отсюда частый случай «ограничение есть, а пользователь видит всё».
- Привилегированный режим обходит RLS. Код на сервере, выполняемый в привилегированном режиме (общий модуль с флагом «Привилегированный» или вызов
УстановитьПривилегированныйРежим(Истина)), читает все записи. - Запрос без
РАЗРЕШЕННЫЕпадает, а не фильтрует. Если в запросе нет словаВЫБРАТЬ РАЗРЕШЕННЫЕ, а пользователю доступна только часть записей, платформа выдаёт ошибку недостаточных прав. СРАЗРЕШЕННЫЕнедоступные строки просто отсекаются.
Пользователь с ролью «Полные права» не проверяет RLS вообще: эта роль в типовых конфигурациях даёт доступ без ограничений. Проверять нужно только под учётной записью с рабочим набором ролей.
Проверка RLS под пользователем: быстрый тест в рабочей базе
Самый честный тест — посмотреть на данные глазами пользователя. Делайте это в копии базы, если нельзя войти под чужой учётной записью.
Шаг 1. Создайте тестового пользователя-двойника
В типовых конфигурациях на БСП (Бухгалтерия 3.0, ЗУП 3.1, УТ 11) это делается в разделе Администрирование → Настройки пользователей и прав → Пользователи:
- Откройте карточку проблемного пользователя.
- Скопируйте её (команда копирования в списке) — у копии будут те же группы доступа.
- Задайте копии имя для входа и пароль.
- Проверьте на закладке прав доступа, что набор групп доступа совпадает с оригиналом.
Шаг 2. Воспроизведите проблему
Войдите под двойником и откройте тот же список, отчёт или документ. Запишите, что именно не так:
- какие записи лишние или каких не хватает;
- какой текст ошибки появляется и на каком действии (открытие, запись, проведение, печать);
- воспроизводится ли проблема в другом списке того же объекта.
Если двойник видит то же, что и пользователь, дело в настройках прав. Если не видит — проверьте персональные настройки пользователя: отборы в списке, сохранённые варианты отчёта, основную организацию. Это не RLS, но выглядит похоже.
Шаг 3. Проверьте настройки групп доступа
В конфигурациях на БСП ограничение задаётся не кодом, а данными:
- в профиле группы доступа — какие роли входят и по каким видам доступа ограничивать (организации, склады, группы номенклатуры и т. п.);
- в группе доступа — конкретные разрешённые значения для каждого вида доступа и список участников.
Типичная находка: вид доступа стоит в режиме «Все разрешены» с исключениями, а администратор считал, что там «Все запрещены» с разрешёнными значениями. Логика меняется на противоположную.
Также убедитесь, что в разделе Администрирование → Настройки пользователей и прав включён флажок «Ограничивать доступ на уровне записей». Без него виды доступа в группах ни на что не влияют.
Проверка ролей и текста ограничения в Конфигураторе
Если настройки групп доступа правильные, а поведение нет — открывайте Конфигуратор.
Какие роли действуют на объект
- В дереве конфигурации найдите объект (например, документ «Реализация товаров и услуг»).
- В контекстном меню объекта есть команда поиска ссылок на объект — она покажет роли, где он упоминается.
- Откройте каждую роль пользователя и посмотрите права на этот объект и колонку ограничений.
Ищите роль, где право есть, а ограничения нет. По правилу сложения прав она отменит все остальные ограничения.
Что смотреть в тексте ограничения
- 📌 Шаблоны (
#ИмяШаблона(...)) — в конфигурациях на БСП ограничения почти всегда построены на шаблонах. Текст шаблона лежит на закладке шаблонов той же роли. - 📌 Параметры сеанса — условие часто сравнивает поле с параметром сеанса. Если параметр заполнен неправильно, ограничение работает «не на того».
- 📌 Препроцессор (
#Если ... #ИначеЕсли ... #КонецЕсли) — ветка может зависеть от функциональной опции или параметра, и для конкретной базы срабатывает не та ветка, которую вы ждёте. - 📌 Поля ограничения — проверьте, что условие наложено на право
Чтение, а не только наИзменение. Тогда пользователь видит записи, но не может их менять — частая причина вопроса «почему он видит, но не сохраняет».
Проверка в отладке
Запустите отладку из Конфигуратора под тестовым пользователем. Пользователя для запуска задают в параметрах Конфигуратора, в разделе параметров запуска 1С:Предприятия. Поставьте точку останова перед проблемным запросом и выполните его в отладчике через окно вычисления выражений: так видно, какие строки вернутся с учётом прав этого пользователя.
Отладка на рабочем сервере замедляет работу сеансов и требует включить отладку на сервере 1С. Делайте это в копии базы или в нерабочее время.
Технологический журнал: как увидеть запросы с ограничениями
Технологический журнал (ТЖ) — главный инструмент, когда нужно понять, что платформа реально делает с запросом пользователя. Он пишет события сервера в текстовые логи.
Настройка logcfg.xml
Файл logcfg.xml кладут в каталог conf установленной платформы (например, C:\Program Files\1cv8\conf\). Сервер подхватывает изменения без перезапуска, обычно в течение минуты.
Пример: собрать запросы одного пользователя к СУБД и события ошибок:
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="D:\techlog\rls" history="2">
<event>
<eq property="name" value="DBMSSQL"/>
<eq property="Usr" value="ПетроваТест"/>
</event>
<event>
<eq property="name" value="DBPOSTGRS"/>
<eq property="Usr" value="ПетроваТест"/>
</event>
<event>
<eq property="name" value="EXCP"/>
</event>
<property name="all"/>
</log>
</config>
Что здесь важно:
DBMSSQL— запросы к MS SQL Server,DBPOSTGRS— к PostgreSQL. Оставьте событие той СУБД, которая у вас стоит.Usr— фильтр по имени пользователя, чтобы не утонуть в логах всей базы.EXCP— исключения, в том числе ошибки прав.history="2"— хранить логи 2 часа, дальше сервер удаляет их сам.
Не оставляйте ТЖ с широким фильтром включённым надолго: на нагруженной базе он за час набирает гигабайты и забивает диск сервера. После сбора данных удалите или закомментируйте блок <log>.
Как читать результат
Воспроизведите проблему под тестовым пользователем, затем найдите в логах событие с текстом запроса (свойство Sql). У запроса пользователя с RLS видны дополнительные соединения или подзапросы EXISTS к служебным таблицам — это и есть наложенное ограничение. У того же запроса под полными правами их нет.
Сравните длительность (свойство duration) запроса под тестовым пользователем и под администратором. Разница в разы — признак того, что тормозит именно ограничение, а не сам отчёт.
Единицы измерения duration зависят от версии платформы. Сравнивайте два запроса из одного журнала между собой, а не с абсолютными цифрами из чужих статей.
Анализ запросов RLS в SQL Server и PostgreSQL
Когда ТЖ показал медленный запрос, его разбирают уже на стороне СУБД.
Как понять, какие таблицы участвуют
В SQL-тексте таблицы называются не по-русски, а служебными именами: _Document123, _InfoRg456, _Reference78. Сопоставить их с объектами конфигурации поможет функция платформы ПолучитьСтруктуруХраненияБазыДанных() — она возвращает таблицу соответствия имён метаданных и имён в СУБД. Вызвать её можно из внешней обработки под администратором.
План выполнения запроса
| СУБД | Чем смотреть план | На что смотреть |
|---|---|---|
| MS SQL Server | SSMS, фактический план выполнения (Actual Execution Plan) | сканирование больших таблиц вместо поиска по индексу, вложенные циклы с миллионами строк |
| PostgreSQL | EXPLAIN (ANALYZE, BUFFERS) перед текстом запроса | Seq Scan по большим таблицам, расхождение оценки строк с фактическим числом |
Скопируйте текст запроса из ТЖ, подставьте параметры и выполните его в копии базы. Для PostgreSQL:
EXPLAIN (ANALYZE, BUFFERS)
SELECT ... -- текст запроса из свойства Sql технологического журнала
EXPLAIN ANALYZE реально выполняет запрос. Для запросов на изменение данных (UPDATE, DELETE) запускайте его только в копии базы.
Что обычно находится
- 📉 Устаревшая статистика СУБД. Оптимизатор выбирает плохой план для подзапроса ограничения. Лечится регламентным обновлением статистики (в SQL Server — задание обслуживания, в PostgreSQL —
ANALYZE). - 🧱 Слишком сложное условие. Ограничение по нескольким видам доступа сразу (организация + склад + контрагент) превращается в несколько вложенных проверок на каждую строку.
- 📚 Огромная таблица без отбора по периоду. Отчёт за пять лет под пользователем с RLS проверяет ограничение по каждой записи. Отбор по периоду ускоряет его сильнее любой настройки.
Проверка настроек ограничения доступа в конфигурации на БСП
В конфигурациях на Библиотеке стандартных подсистем есть два варианта работы ограничений:
- стандартный — условия строятся на шаблонах по значениям доступа;
- производительный (универсальное ограничение) — платформа сверяет запись не со списком значений, а с заранее рассчитанными ключами доступа. Работает быстрее на больших базах, но требует, чтобы ключи были актуальны.
Какой вариант у вас, видно по составу шаблонов в ролях и по настройкам в разделе Администрирование → Настройки пользователей и прав. В новых релизах типовых конфигураций по умолчанию применяется производительный вариант.
Чек-лист проверки настроек
Доработки и расширения
Если в базе есть доработанные объекты или расширения, проверьте три вещи:
- У нового объекта в расширении есть права в роли расширения и, при необходимости, ограничение. Без ограничения объект будет доступен всем, у кого есть право.
- Новый объект зарегистрирован в механизме ограничения доступа БСП. Без этого в производительном варианте для него не рассчитываются ключи.
- В коде доработок запросы, которые выполняются под пользователем, содержат
ВЫБРАТЬ РАЗРЕШЕННЫЕ, если пользователь может не иметь доступа к части данных.
Обслуживание данных RLS: обновление ключей доступа и очистка логов
Отдельного «журнала RLS», который нужно чистить, в 1С нет. Обслуживания требуют служебные данные ограничений и логи, которые вы собрали при диагностике.
Обновление доступа в БСП
В производительном варианте при изменении групп доступа, значений доступа или самих объектов платформа пересчитывает ключи доступа в фоне — регламентным заданием обновления доступа. Пока пересчёт не закончен, пользователь может временно не видеть новые документы или видеть старые права.
Что делать:
- В разделе
Администрирование → Настройки пользователей и праврядом с флажком ограничения доступа на уровне записей откройте форму обновления доступа (в старых релизах её может не быть). - Посмотрите, идёт ли обновление и есть ли ошибки по отдельным таблицам.
- Если обновление зависло, проверьте, что регламентные задания в базе не заблокированы, а у сервера есть свободные рабочие процессы.
Первичный расчёт после включения флажка на большой базе может идти часы. Включайте ограничение вечером или в выходные, а пользователей предупредите, что до конца расчёта права могут вести себя непредсказуемо.
Перезапуск расчёта прав
Крайний способ — выключить флажок «Ограничивать доступ на уровне записей» и включить снова: служебные данные будут рассчитаны заново.
На время выключения флажка ограничения по видам доступа не действуют: пользователи с ролями без собственных ограничений увидят все данные. Делайте это только вне рабочего времени и после резервной копии базы.
Логи технологического журнала
Логи ТЖ сервер удаляет сам по истечении history. Если журнал собирал данные несколько дней или каталог переполнен, удалите старые подкаталоги вручную, предварительно убрав или сузив блок <log> в logcfg.xml. Для долгого мониторинга держите отдельный журнал с узким фильтром (например, только запросы длительнее нескольких секунд) на отдельном диске.