При работе с крупными конфигурациями, содержащими сотни ролей, часто возникает задача аудита безопасности: необходимо выяснить, кто именно имеет право изменять конкретный реквизит справочника или документа. Стандартный интерфейс конфигуратора не всегда позволяет быстро получить наглядный список таких ролей, особенно если права на реквизиты зависят от прав на головной объект. В этой статье мы рассмотрим основные методы решения данной задачи, начиная от программного анализа и заканчивая низкоуровневым разбором файлов конфигурации.
Первое, что пробует разработчик — это написать цикл по всем ролям конфигурации. Однако здесь есть важный нюанс, связанный с логикой работы платформы. Разберем типичную попытку реализации и выясним, почему она может не работать корректно.
Если мы используем стандартную функцию ПравоДоступа, нам необходимо передать в нее три параметра: право (например, "Изменение"), объект метаданных и саму роль. Посмотрим на пример кода:
Для каждого Роль Из Метаданные.Роли Цикл
// Проверка права на реквизит табличной части
ОбъектМетаданных = Метаданные.Справочники.Номенклатура.ТабличныеЧасти.Состав.Реквизиты.Количество;
Если ПравоДоступа("Изменение", ОбъектМетаданных, Роль) Тогда
Сообщить("Доступ разрешен в роли: " + Роль.Имя);
КонецЕсли;
КонецЦикла;
Почему этот метод может выдавать «Истину» для всех ролей? Проанализируем ситуацию. В 1С существует настройка Независимые права подчиненных объектов. Если этот флаг у роли НЕ установлен, то права на реквизиты и табличные части автоматически наследуются от прав на сам объект (справочник или документ). Таким образом, если роль дает право на изменение справочника в целом, то ПравоДоступа вернет Истина для любого его реквизита, даже если в конфигураторе визуально галочка на реквизите не стоит. Функция возвращает результирующее право пользователя, а не наличие конкретной пометки в метаданных.
Если нам нужно получить список ролей без написания кода, воспользуемся встроенными инструментами конфигуратора. Это один из самых быстрых способов визуального контроля. Разберем шаги:
Этот метод хорош тем, что он показывает структуру прав именно так, как она задана в метаданных, помогая быстро отсеять роли с установленным доступом.
Для самых сложных случаев, когда ролей сотни, а отчеты конфигуратора становятся нечитаемыми, мы применим наиболее точный технический подход — анализ XML-структуры конфигурации. Рассмотрим этот процесс подробнее:
Выгрузим конфигурацию в файлы через меню Конфигурация — Выгрузить конфигурацию в файлы. В целевой папке мы найдем подпапку Roles, в которой каждая роль представлена отдельным XML-файлом. Каждое право на каждый объект описано в этих файлах строгими узлами.
Например, право на редактирование реквизита будет выглядеть внутри файла роли примерно так:
<Item>
<Path>Catalog.Номенклатура.Attribute.СтавкаНДС</Path>
<Permission>Edit</Permission>
<Value>true</Value>
</Item>
Используя любой текстовый поиск по файлам (например, через Notepad++ или Total Commander), мы можем мгновенно найти все файлы ролей, где строка с путем к нашему реквизиту содержит значение true. Это единственный способ увидеть "реальную" картину настроек ролей, игнорируя программное наследование прав платформой.
Если ваша конфигурация разработана на базе Библиотеки стандартных подсистем (БСП), задача значительно упрощается. Проанализируем возможности пользовательского режима:
В разделе Администрирование — Настройки пользователей и прав обычно присутствует отчет Права доступа. В нем можно выбрать объект метаданных и увидеть сводную информацию. Кроме того, в БСП часто реализован регистр сведений ПраваРолей (или аналогичный), который хранит кэшированную информацию о правах. Мы можем сделать запрос к этому регистру:
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ПраваРолей.Роль,
| ПраваРолей.ОбъектМетаданных
|ИЗ
| РегистрСведений.ПраваРолей КАК ПраваРолей
|ГДЕ
| ПраваРолей.ОбъектМетаданных ПОДОБНО &ИмяОбъекта
| И ПраваРолей.Изменение = ИСТИНА";
Запрос.УстановитьПараметр("ИмяОбъекта", "%ИмяСправочника.Реквизит.ИмяРеквизита%");
Результат = Запрос.Выполнить();
Важно помнить, что структура такого регистра зависит от версии БСП, и не всегда права там детализированы до уровня реквизитов. Однако для общего понимания прав на таблицы это отличный инструмент.
Еще один "хитрый" способ быстро просмотреть права — использовать механизм сравнения. Посмотрим на алгоритм:
.cf).Выясним еще одну причину, почему пользователь может не иметь доступа, даже если роль его дает. Помимо ролей, на видимость и возможность изменения реквизита влияют Функциональные опции. Если реквизит привязан к опции, которая в данный момент выключена в константах, пользователь его не увидит.
Также стоит учитывать RLS (Row Level Security). Хотя RLS чаще настраивается на чтение или изменение целых записей (строк таблицы), использование функции ПараметрыДоступа в коде поможет определить, наложены ли какие-то дополнительные ограничения на уровне записей, которые могут блокировать работу с конкретными данными, в которых участвует данный реквизит.
Подводя итог, можно сказать: если вам нужен быстрый результат — используйте Отчет по конфигурации. Если вам нужен максимально точный список для автоматизированной обработки — используйте анализ XML-выгрузки. А при написании собственного программного кода проверки прав всегда помните о флаге Независимые права подчиненных объектов, который определяет, будет ли ПравоДоступа возвращать реальную настройку реквизита или унаследованное право родителя.