При настройке прав доступа в больших конфигурациях на платформе 1С:Предприятие (таких как ERP, КА 2, БП 3) разработчики и администраторы постоянно сталкиваются с задачей аудита безопасности. Возникает закономерный вопрос: как быстро получить наглядный и структурированный список всех объектов метаданных, к которым у конкретной роли есть доступ, с детализацией по видам прав (чтение, просмотр, редактирование, проведение)?
В этой статье мы подробно разберем несколько практических способов решения этой задачи: от стандартных средств Конфигуратора до использования возможностей Библиотеки стандартных подсистем (БСП) и мощных внешних инструментов разработчика. Также мы выясним ключевые особенности иерархической модели прав платформы 1С и программного управления видимостью интерфейса.
Это самый простой и доступный способ, не требующий написания кода или использования внешних файлов. Метод подходит, когда нужно быстро получить "сырой" текстовый реестр прав по конкретной роли.
Выполним следующие шаги:
Общие, далее перейдем в раздел Роли.Платформа сформирует табличный документ, который можно сохранить в формате Excel или текстового файла. Однако у этого способа есть существенный недостаток — избыточность данных. В крупных конфигурациях (например, в «1С:Комплексная автоматизация 2») одна роль может породить список объемом более 300 000 строк. Анализировать такой массив вручную крайне неудобно, так как туда попадают абсолютно все реквизиты, табличные части и системные права. Для удобного получения состава роли по видам прав и объектам можно применить обработку для просмотра ролей для объекта и объектов для ролей.
Если вы работаете в любой современной типовой конфигурации, построенной на базе Библиотеки стандартных подсистем (БСП), вам доступен специализированный внутренний механизм. БСП автоматически кэширует структуру прав в специальном регистре для ускорения работы механизмов RLS и программных проверок.
Этот регистр называется РегистрСведений.ПраваРолей. В нем в удобном плоском виде хранятся записи о том, какие права (чтение, изменение, добавление и т.д.) предоставлены конкретным ролям для каждого объекта метаданных.
Проанализируем особенности работы с этим регистром:
Роль или ОбъектМетаданных и легко выгрузить результат в Excel стандартными средствами платформы.Для принудительного обновления идентификаторов объектов и прав программно запустите следующий код в контексте сервера:
// Вызов стандартной процедуры БСП для обновления справочника идентификаторов и связанных регистров
Справочники.ИдентификаторыОбъектовМетаданных.ВыполнитьОбновлениеДанных();
После завершения этой процедуры все новые объекты и роли корректно зарегистрируются в регистре сведений Права ролей. Для комплексного визуального аудита и анализа взаимосвязей ролей, прав и объектов можно использовать обработку для анализа и работы с правами доступа.
Если вам требуется детальный профессиональный аудит прав с группировками, подсветкой и возможностью сравнения ролей, лучшим решением является использование специализированного инструмента из бесплатного комплекса «Инструменты разработчика» (автор Tormozit).
Компонент «Анализ прав доступа» предоставляет мощнейший функционал:
Чтобы воспользоваться этим инструментом в портативном варианте:
Файл -> Открыть, выбрав файл главного компонента (обычно это обработка с именем _ИР.epf).Иногда разработчики пытаются написать собственный алгоритм обхода метаданных для сбора прав "на коленке". Рассмотрим типичный пример кода, который часто пишут с ошибками, и разберем, почему он может работать некорректно:
// Пример неверной интерпретации типов при обходе ролей
ПодсистемаОбъект = Метаданные.Подсистемы.ОСИНМА;
Для Каждого ТекущаяРоль Из Метаданные.Роли Цикл
// ОШИБКА: Функция ПравоДоступа ожидает в третьем параметре объект метаданных роли,
// либо конкретного пользователя.
ДоступРазрешен = ПравоДоступа("Просмотр", ПодсистемаОбъект, ТекущаяРоль);
Если ДоступРазрешен Тогда
ОбщегоНазначенияКлиентСервер.СообщитьПользователю("Доступ есть у роли: " + ТекущаяРоль.Имя);
КонецЕсли;
КонецЦикла;
Выясним причины странного поведения такого алгоритма, когда на все роли возвращается значение Истина:
ПравоДоступа третий параметр передан некорректно (например, в виде строки или неправильного типа), платформа может проигнорировать его и вернуть результат проверки прав для текущего пользователя, под которым запущена сессия. Если у вас полные права, функция всегда будет возвращать Истина для любого объекта.Для каждого роль из Метаданные.Роли переменная цикла имеет тип ОбъектМетаданных: Роль. В отладчике при просмотре значения она может отображаться текстовой строкой (своим именем), что вводит разработчиков в заблуждение. На самом деле это полноценный объект метаданных, у которого есть свои методы, например, проверка расширений через метод ЕстьИзмененияРасширениямиКонфигурации().При выгрузке прав разработчики часто сталкиваются с парадоксальной ситуацией: в свойствах роли на уровне самого справочника (например, Справочник.Банки) права на Чтение и Просмотр отключены (стоят в значении "Нет"), а на уровне его реквизитов (например, КоррСчет, Адрес) эти же права включены (стоят в значении "Да").
Разберем по шагам, как платформа 1С обрабатывает такие ситуации:
Чтение на сам справочник Банки, то он гарантированно не сможет получить доступ ни к одному из его реквизитов, независимо от того, какие флажки установлены внутри роли для этих реквизитов.Еще один частый вопрос: почему раздел (подсистема) отображается в панели разделов интерфейса "Такси", хотя в роли снята галочка Просмотр для этой подсистемы?
Проанализируем правила формирования командного интерфейса в современных конфигурациях:
ОСиНМА), необходимо не просто снять галочку просмотра с самой подсистемы в роли, а исключить права просмотра на абсолютно все входящие в нее объекты метаданных и общие команды, либо исключить эти объекты из состава командного интерфейса подсистемы.Рассмотрим практическую задачу: в общем журнале документов Деньги необходимо настроить видимость так, чтобы пользователь видел банковские документы, но не имел доступа к кассовым (таким как ПКО и РКО), при этом форма журнала должна оставаться доступной.
Для решения этой задачи не требуется писать сложные запросы или настраивать RLS. Платформа делает это автоматически:
Чтение объектов Документ.ПриходныйКассовыйОрдер и Документ.РасходныйКассовыйОрдер, то при открытии общего журнала Деньги строки с кассовыми ордерами просто исчезнут из динамического списка. Система не выдаст ошибку, она молча отфильтрует отображаемые данные на уровне СУБД.ПриСозданииНаСервере.Посмотрим на пример реализации такой проверки:
&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
// Проверяем интерактивные права пользователя на кассовые документы
ПравоНаПКО = ПравоДоступа("ИнтерактивноеДобавление", Метаданные.Документы.ПриходныйКассовыйОрдер);
ПравоНаРКО = ПравоДоступа("ИнтерактивноеДобавление", Метаданные.Документы.РасходныйКассовыйОрдер);
// Управляем видимостью соответствующих элементов управления на форме журнала
Если Элементы.Найти("КнопкаСоздатьПКО") <> Неопределено Тогда
Элементы.КнопкаСоздатьПКО.Видимость = ПравоНаПКО;
КонецЕсли;
Если Элементы.Найти("КнопкаСоздатьРКО") <> Неопределено Тогда
Элементы.КнопкаСоздатьРКО.Видимость = ПравоНаРКО;
КонецЕсли;
КонецПроцедуры
Такой комплексный подход гарантирует, что пользователь получит максимально чистый, понятный интерфейс без лишних элементов управления и при этом не сможет обойти ограничения прав доступа через стандартные механизмы платформы.