Права и RLS в 1С: что можно узнать из выгрузки ролей
Как разобрать Rights.xml через explain_rls: матрица прав, тексты ограничений и фильтры. Почему выгрузка не доказывает доступ конкретного пользователя.
Из выгрузки ролей можно узнать, какие права заданы для объекта и какие ограничения RLS записаны в исходниках. Для этого не нужен доступ к рабочим данным. Но ответить по такой выгрузке, что увидит конкретный пользователь, нельзя: в ней нет назначений его ролей и параметров сеанса.
В Профессиональной редакции MCP-1C с v2.27.0 есть инструмент explain_rls. Он читает дерево Roles/ и показывает матрицу прав, шаблоны и дословные ограничения RLS. Его область — структура конфигурации; эффективный доступ конкретного пользователя он не рассчитывает. Контракт опубликован в справочнике explain_rls, версия появления — в истории изменений.
В статье: подготовка, фильтры, чтение результата, проверка доступа.
Подготовьте исходники ролей
Нужна актуальная выгрузка конфигурации, содержащая каталог Roles/. Источник можно указать через dump_path либо выбрать зарегистрированную базу через base, если для неё настроен --dump. Путь должен соответствовать правилам доступа к выгрузкам.
Пример аргументов explain_rls для условной зарегистрированной базы:
{
"base": "test",
"object": "Справочник.Контрагенты",
"format": "json"
}
Замените test и имя объекта на свои. Запрос по одному объекту удобен, когда задача уже сформулирована: например, выяснить, в каких ролях описано чтение справочника. Для общего знакомства начните без фильтра объекта, а затем сужайте результат.
Выберите подходящие фильтры
| Параметр | Назначение |
|---|---|
role |
Оставить одну роль по имени |
object |
Оставить один объект метаданных |
with_restrictions_only |
Показать только права с ограничением RLS |
format |
Получить text или json |
Фильтр with_restrictions_only полезен для чтения условий, но скрывает права без ограничений. Поэтому для вопроса «есть ли чтение без RLS» он не подходит: получите полный набор соответствующих прав. Выбор фильтра меняет видимую часть материала, а не саму конфигурацию.
Что означает запись отчёта
В основе результата — роль, объект, право, его значение и текст ограничения либо отсутствие текста. Выданное право без RLS отмечается как структурный факт. Это ещё не вывод о нарушении безопасности: назначение роли может предполагать полный доступ к объекту.
Условие показывается дословно. Инструмент не исполняет язык ограничений и не подставляет параметры сеанса. Если роль ссылается на шаблон, рассмотрите его вместе с остальными исходниками. Не просите агента объявить условие безопасным только потому, что оно присутствует в отчёте.
Проверяйте примечания. Нечитаемый, слишком большой или недоступный Rights.xml не становится «ролью без проблем»: он попадает в список ограничений разбора. Отсутствие записи при неполном чтении не доказывает отсутствие права.
Как проверить доступ конкретного пользователя
В выгрузке нет назначений пользователей и значений параметров сеанса. explain_rls также не объединяет права набора ролей. Поэтому вопрос «увидит ли менеджер документ другой организации» требует отдельного прикладного сценария.
В тестовой базе создайте синтетические записи разрешённой и запрещённой области, назначьте пользователю нужный набор ролей и проверьте чтение и изменение через соответствующий путь доступа. Зафиксируйте ожидаемый результат до запуска. Если запросы идут через интеграцию, проверьте учётную запись именно этой интеграции: её права могут отличаться от прав интерактивного пользователя.
Сохраните рядом два результата: что задано в ролях и что получилось при входе под проверяемой учётной записью. Это другая задача, чем управление правами самого ИИ-клиента или шлюза: возможности редакций нельзя подменять друг другом.
Для уточнения объектов используйте метаданные конфигурации, а для структуры проекта — карту подсистем.