RLS в УТ 11.5 по выгрузке: 29 пар со снятым ограничением и проверка 12 ответов ИИ

В УТ 11.5 ограничения доступа на уровне записей заданы 2240 условиями в 543 ролях из 1086, и глазами их не сверить: роли складываются, а профиль состоит из десятков и сотен ролей (медиана 86, максимум 519 в 43 поставляемых профилях). Я написала скрипт rls_audit.py, который читает Roles/*/Ext/Rights.xml и статически разбирает код поставляемых профилей, и прогнала его на выгрузке УТ 11.5.22.77. Каждую пару из раздела 1в разобрала по тексту ролей и профилей. Потом отдала выдержки по шести объектам двум моделям, разобрала все двенадцать ответов по файлам и проверила на платформе 8.3.27, что пользователь с двумя ролями видит записи без ограничения.

Стенд и порядок работы

Выводы относятся к одной версии УТ, статически разобранному коду поставляемых профилей и пустой конфигурации опыта. Профили в базе заказчика могут отличаться от поставляемых, и скрипт этого не видит.

Что ищет инструмент

Инструмент читает выгрузку «в файлы», разбирает права каждой роли и условия restrictionByCondition, затем читает общие модули УправлениеДоступом* и собирает состав поставляемых профилей из текста кода. Прежде чем что-либо искать, он проверяет вход: сколько каталогов в Roles, у скольких есть Ext/Rights.xml, тот ли корневой элемент и пространство имён. Пустой Roles, роль без Rights.xml, повреждённый XML и профили, которые не удалось разобрать, дают код возврата 3 и список причин: зелёным считается только полный вход. Фрагмент одной роли из выгрузки:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<object>
	<name>Catalog.ВнешниеПользователи</name>
	<right>
		<name>Read</name>
		<value>true</value>
		<restrictionByCondition>
			<condition>#Если &amp;ОграничениеДоступаНаУровнеЗаписейУниверсально #Тогда
#ДляОбъекта("")
#Иначе
#ПоЗначениям( "Справочник.ВнешниеПользователи", "", "",
"ВнешниеПользователи", "ссылка", "","", ...)
#КонецЕсли</condition>
		</restrictionByCondition>
	</right>
</object>

Если у роли право Read записано без блока restrictionByCondition, роль читает объект без условия.

Команда excerpt собирает по объекту выдержку для модели. Код возврата ключа --fail равен 1, если остались широкие роли, пары без работающего ограничения без записи причины, вызовы не того шаблона или вызовы отсутствующих шаблонов на действующих правах.

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

Три режима на УТ 11.5

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

Разница в шести парах справочника ШаблоныСообщений и присоединённых файлов к нему. По коду поставки личная роль ДобавлениеИзменениеЛичныхШаблоновСообщений стоит только в профиле ОтветственныйЗаВедениеВзаимодействий (дополнительный) рядом с ролью без ограничения. Процедура обработчика ШаблоныСообщенийСлужебный.ДобавитьРольДобавлениеИзменениеЛичныхШаблоновВПрофилиСБазовымиПравами для версии 3.0.1.35 добавляет эту роль во все профили, где есть БазовыеПраваБСП:

1
2
3
4
5
6

НовыеРоли = Новый Массив;
НовыеРоли.Добавить(Метаданные.Роли.БазовыеПраваБСП.Имя);
НовыеРоли.Добавить(Метаданные.Роли.ДобавлениеИзменениеЛичныхШаблоновСообщений.Имя);
ЗаменяемыеРоли = Новый Соответствие;
ЗаменяемыеРоли.Вставить(Метаданные.Роли.БазовыеПраваБСП.Имя, НовыеРоли);
МодульУправлениеДоступом.ЗаменитьРолиВПрофилях(ЗаменяемыеРоли);

С ключом --update-handlers ограничение личной роли работает в 23 профилях для чтения и в 29 для добавления и изменения. Обработчик я прочитала по коду и не запускала. Скрипт находит такие записи по прямолинейным строкам НовыеРоли.Добавить и ЗаменяемыеРоли.Вставить. В УТ он нашёл четыре: две дополняют роли по партнёрам правами на банковские счета контрагентов, две добавляют роли (личные шаблоны сообщений и редактирование печатных форм) в профили с БазовыеПраваБСП. Ещё две записи в УТ (электронные подписи и настройка синхронизации данных) начинаются с ключа вида «? Роль»; такие записи скрипт пропускает.

Первая версия скрипта разбирала только Rights.xml и показывала в разделе 4 одну находку: у роли ДобавлениеИзменениеПлановЗакупок на регистре ПланыЗакупок условие права Update содержит слово «Чтение». Право Update в этой роли выключено (value=false), условие не действует. Теперь такие условия считаются отдельно (в УТ их 32) и в находки не входят. Журнал первой версии лежит в компаньоне (evidence/ut-scan-v1.txt).

Что нашлось в УТ 11.5

Рисунок 1. Итоговый прогон по выгрузке УТ 11.5.22.77 с разобранными исключениями: 29 пар раздела 1в, из них 15 без работающего ограничения по коду поставки, 0 не разобранных.

Широкая роль: одна

УдаленныйДоступOData читает без условия все 646 объектов с ограничением права Read, 394 для Insert и 465 для Update. В профили она не входит. Общий модуль ИнтерфейсODataСлужебный возвращает её как роль интерфейса OData. Полный доступ роль даёт по назначению: такую роль выдают пользователю интеграции отдельно, и ограничения по записям у него не действуют.

Остальные роли без условия: 47 пар

Тут 37 ролей и 119 троек (роль, право, объект). Самые крупные: НастройкаНСИ читает без условия 17 объектов, СамообслуживаниеВнешнийПользовательЧтениеНСИ 15, ЧтениеРегистровПланов 10. Из 119 троек 84 не пересекаются ни в одном профиле: роль без ограничения и ограничивающая стоят в разных профилях, и перекрытие возникает, только если человеку выдали роли из обоих. НастройкаНСИ ни в одном поставляемом профиле нет. Остальные 35 троек стоят в общем профиле и входят в раздел 1в.

29 пар: роль без ограничения рядом с ограничивающей

Права ролей складываются. Для каждой пары скрипт проверяет, остаётся ли профиль, где ограничивающая роль есть, а ролей без ограничения на это право нет. В 14 парах такой профиль есть: полное право получают одни профили, ограниченное другие. Например, ЧтениеНормативноСправочнойИнформации стоит в 29 профилях, и только в Казначее рядом с ней роль без ограничения на справочники касс. Четыре из этих 14 пар (три регистра электронных документов и номенклатура контрагентов) стоят в профилях, которые собирают процедуры модуля локализации. Я проверила их по Rights.xml и по строкам исходных операторов, ограничение в других профилях там работает.

В 15 парах таких профилей нет. Шесть из них ШаблоныСообщений, описаны выше. Остаются девять.

Для каждой пары я посмотрела, что даёт ограничивающая роль сверх остальных ролей профиля. У двух регистров остатков вклад нулевой: ЧтениеОстатковЗаказовПоставщикам и ЧтениеОстатковЗаказовКлиентовЗаявокНаВозврат в этих профилях ничего не добавляют, и ограничение по организациям, складам и группам партнёров там не действует. У шести остальных пар ограничивающая роль даёт от 2 до 36 прав сверх остальных ролей профиля, поэтому профиль нужен ради них, а перекрытие возникает по одному праву.

Отдельно стоит справочник внешних пользователей. В Rights.xml роли БазовыеПраваВнешнегоПользователяУТ у объекта записано только право Read без условия. В БазовыеПраваВнешнихПользователейБСП то же право ограничено по виду доступа ВнешниеПользователи, а для Update стоит условие ГДЕ Ссылка = &ТекущийВнешнийПользователь. В профилях Клиент и Респондент стоят обе роли, чтение складывается в «без условия», изменение остаётся ограниченным. По ролям выходит, что внешний пользователь этих профилей читает записи всех внешних пользователей. Намерение поставщика я установить не могу: решить, убирать ли роль без ограничения, оставить ли её или записать причину, должен владелец конфигурации.

Дубли, шаблоны и вызовы

Условий 2240, различных форм 487: пять самых частых встречаются 146, 105, 52, 48 и 40 раз. Одинаковый текст у одного объекта и права в нескольких ролях дают 497 групп, и в 378 из них есть пара ЧтениеХ и ДобавлениеИзменениеХ. Остальные группы собрали роли разных видов документов, которые работают с одним объектом, и базовые роли. Эти группы находками не считаются. Тексты условий сравниваются с учётом пробелов внутри строковых литералов: два условия, отличающиеся только пробелами в значении, в одну группу не попадают. Из 178 пар «роль целиком повторена другой» 79 не стоят в одном профиле, 87 из 99 стоящих вместе составляют схему чтение и добавление-изменение. Остаются 12 пар: например, ЧтениеПервичныхДокументов входит в пять ролей и ничего не добавляет в профиле Бухгалтер.

Неиспользуемых шаблонов 12 из 1209, в пяти ролях. В НастройкаНСИ и ЧтениеТМЦВЭксплуатации нет ни одного условия, в ИзменениеУчастниковГруппДоступа три условия вызывают только ДляОбъекта. На доступ такие шаблоны не влияют. Вызовов шаблона для другого объекта или права нет, вызовов отсутствующих шаблонов нет: проверка идёт по всем достижимым вызовам от условий действующих прав, включая тела шаблонов.

Сложение прав на платформе

Правило «если у пользователя есть роль без ограничения, ограничения других его ролей на это право не действуют» я проверила на пустой конфигурации и повторила опыт 26.10.2026 исправленным скриптом. Скрипт platform_rls_proof.py создаёт базу, выгружает пустую конфигурацию, дописывает справочник Склады, три роли и два общих модуля, загружает выгрузку и проверяет модули. Роль РольСОграничением читает склады с условием ГДЕ Наименование = "Склад А", роль РольБезОграничения читает без условия. Скрипт создаёт администратора и трёх пользователей для проверки (только ограниченная роль, только свободная, обе роли) и три склада. Каждый подключается через COM, и модуль без привилегированного режима возвращает список складов.

Рисунок 2. Три пользователя на платформе 8.3.27.2130: роль с ограничением даёт один склад, роль без ограничения и обе роли вместе дают три.

В модуле проверки запрос с ограничением записан так:

1
2

Запрос = Новый Запрос("ВЫБРАТЬ РАЗРЕШЕННЫЕ Наименование КАК Н ИЗ Справочник.Склады УПОРЯДОЧИТЬ ПО Н");
Возврат СтрСоединить(Запрос.Выполнить().Выгрузить().ВыгрузитьКолонку("Н"), "; ");

Без слова РАЗРЕШЕННЫЕ запрос и перебор Справочники.Склады.Выбрать() у пользователя с ограничением завершились ошибкой «У пользователя недостаточно прав на исполнение операции над базой данных», потому что в таблице есть запись, которую он видеть не должен. Условие, которое не отсекает ни одной записи, ошибки не дало: на условиях ГДЕ ИСТИНА и ГДЕ НЕ ПометкаУдаления (элементы не помечены) пользователь с ограничением увидел все склады обоими способами. Журналы лежат в компаньоне: evidence/platform-rls-proof.txt, platform-rls-cond-true.txt, platform-rls-cond-deletionmark.txt, коды возврата в platform-exit-codes.txt. Скрипт завершается нулём, только если создание базы, выгрузка, загрузка и проверка модулей дали код 0, подготовка данных подтверждена, а результаты трёх пользователей совпали с ожидаемыми (один склад, три, три, отказ запроса без РАЗРЕШЕННЫЕ у ограниченного); при любом расхождении код ненулевой. Рабочий каталог должен быть новым: существующий каталог с данными скрипт не трогает.

Правило проверено на трёх ролях и одном справочнике в файловом режиме. Роли УТ с шаблонами ПоЗначениям и настройками видов доступа групп доступа в опыт не входили.

Учебная выгрузка и тесты

Находки всех видов заложены в учебную выгрузку из 12 ролей: роль без ограничения на два ограниченных справочника, профиль с обеими ролями, одинаковое условие у двух ролей, лишний шаблон, вызов шаблона для чужой таблицы и чужого права, вызов отсутствующего шаблона и роль, которую добавляет обработчик обновления. Вариант clean те же объекты без находок.

Рисунок 3. Прогон по варианту seeded из чистой распаковки архива: две пары раздела 1в, один дубль, один лишний шаблон, два неверных вызова и один вызов отсутствующего шаблона.

На варианте clean скрипт с ключом --fail возвращает 0, на seeded 1. На заведомо неполном входе (пустой Roles, роль без Rights.xml, повреждённый XML, чужое пространство имён) он возвращает 3 и не печатает «находок нет»: это проверяет stand/ci_check.py.

Что ответили модели

Для опыта я выбрала пять объектов УТ с разными случаями и одну контрольную выдержку: документ ПоступлениеТоваровИУслуг, которого в УТ нет (в УТ он называется ПриобретениеТоваровУслуг). Выдержку по объекту готовит команда excerpt с ключом --prompt:

1

python rls_audit.py excerpt <выгрузка> Document.Анкета --prompt

Рисунок 4. Выдержка по документу Анкета (без вводной инструкции): три роли, профиль Респондент с обеими ролями и счётчики профилей.

Инструкция просит ответить на вопросы: есть ли роль, снимающая ограничение; есть ли повторяющиеся или противоречащие условия; что выглядит ошибкой и что типовым решением; что проверить в конфигурации. Выдержки по 950-3700 знаков ушли двум моделям, всего 12 запросов за 0,036 доллара, ответ приходил за 3,5-10,7 секунды.

Каждое утверждение в ответах я сверила с Rights.xml и текстом профилей скриптом verify_claims.py, который читает сырые файлы без rls_audit.py. Все 28 проверок скрипта подтвердили факты, а четыре отрицательные проверки на изменённой копии данных показали, что сверка реагирует на изменение условия, пробелов в литерале и закомментированной строки. Правило разбора такое: утверждение относится к одному из пяти видов (факт подтверждён, факт опровергнут, оценка не подтверждена, оценка противоречит проверке, условная рекомендация). Число «верных» ответов я не вывожу: считаются ответы с опровергнутым фактом и ответы с оценкой против проверки.

Итого опровергнутый факт есть в одном ответе каждой модели, оценка против проверки в одном ответе GPT-4.1 mini, остальные девять ответов опровергнутых фактов не содержат. Это не значит, что девять ответов верны: оценки в них не проверены. Что в этих ответах полезно: обе модели называют профиль, где ограничение снято, когда он есть в выдержке (Респондент для анкет, ОтветственныйЗаВедениеВзаимодействий для шаблонов, Клиент и Респондент для внешних пользователей); Gemini нашла дубль условия, который пропустила вторая модель. Что опасно: обе модели не видят обработчиков обновления и не знают, зачем стоит роль, поэтому «типовое» и «ожидаемое» в их ответах ничем не подкреплено; этого файлы не опровергают, но и не подтверждают. Ни одна модель по выдержке с отсутствующим объектом не предложила проверить имя объекта; одна написала об ошибке конфигурации, и перед отправкой имя объекта поэтому проверяют по выгрузке.

Вывод для работы такой. Выдержка с промптом хорошо отвечает на вопрос, что стоит в ролях, и один раз перепроверяется скриптом по файлам. Вопрос «зачем» остаётся за кодом поставки и владельцем конфигурации. Разбор 12 ответов с цитатами утверждений, их видом и проверкой лежит в model-review.md компаньона. Выборка мала: две модели, шесть объектов, один ответ на выдержку, и вывод относится к этим двенадцати ответам.

Файлы к статье

К статье приложены два архива.

Инструмент rls-audit-26-2-tool.zip содержит rls_audit.py, ask_model.py, 82 тестов, stand/make_stand.py, stand/ci_check.py и готовые варианты учебной выгрузки stand/seeded и stand/clean. Запуск из корня распакованного архива:

1
2
3

python rls_audit.py scan stand/seeded/src
python rls_audit.py scan stand/clean/src --fail
python -m unittest discover -s tests -v

Компаньон rls-audit-26-2-companion.zip содержит пошаговый чек-лист аудита, промпт для разбора RLS моделью с порядком проверки ответа, отчёт по УТ 11.5 с разбором 29 пар, разбор 12 ответов моделей, сами выдержки и ответы с датой и расходом, verify_claims.py, platform_rls_proof.py, журналы запусков с кодами возврата и 57 тестов. Тесты компаньона работают без платформы: они сверяют вердикты и числа в отчётах с журналами и ответами и проверяют на временных данных, что опыт на платформе не трогает чужой каталог и не возвращает успех после ошибки.

Рисунок 5. Тесты обоих архивов из чистой распаковки: 82 у инструмента и 57 у компаньона (один запускает платформу и по умолчанию пропущен).

Итог

Выгрузка УТ 11.5.22.77 даёт список мест, где ограничение доступа на уровне записей перекрыто соседней ролью профиля, за один прогон (три прогона подряд 26.10.2026 заняли 33, 26 и 28 с (рабочая машина с посторонними процессами)): 29 пар, из них 15 без работающего ограничения по коду поставки и 9 с ролями из обработчиков обновления. Каждая пара разобрана вручную по тексту ролей и профилей, ложных среди них не найдено. Это относится к этому набору строк и не распространяется на инструмент вообще. Самая значимая пара касается чтения справочника внешних пользователей профилями Клиент и Респондент. Роль УдаленныйДоступOData читает всё без условия по назначению роли интерфейса OData.

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

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

 

Нинель Адольевна Щербакова (Ninel_S)

Архитектор • SRE & DevOps инженер • HighLoad 1С

Автор технических публикаций на Infostart. Разработчик NOPik, SRE-Suite-for-1C и мультиагентных ассистентов для экосистемы 1С:Предприятие.

Каталог статей и открытых репозиториев Ninel_S