Как ограничить доступ к объектам расширения для пользователей с полными правами?

В процессе разработки расширений для типовых конфигураций (таких как УТ 11, ERP 2 или КА) программисты часто сталкиваются с задачей: необходимо добавить новые объекты (справочники, документы, отчеты), доступ к которым должен быть строго ограничен. Однако стандартная роль Полные права в 1С устроена так, что по умолчанию она дает доступ ко всем объектам метаданных, включая те, что добавлены через расширения. Более того, попытки заимствовать роль ПолныеПрава в расширение и снять в ней галочки с новых объектов часто не приносят результата.

В этой статье мы подробно разберем, почему платформа 1С и Библиотека стандартных подсистем (БСП) ведут себя подобным образом, и рассмотрим эффективные стратегии решения этой задачи.

Почему «Полные права» игнорируют настройки расширения?

Разберем ситуацию: мы добавили новый справочник в расширение, создали специальную роль ДоступКНовомуСправочнику и назначили ее только нужным пользователям. Казалось бы, остальные (включая администраторов) не должны его видеть. Но на практике администраторы продолжают видеть объект. Выясним причину этого поведения, которая кроется в двух аспектах:

1. Принцип суммирования прав: В платформе 1С права доступа работают по принципу «Разрешено все, что разрешено хотя бы одной ролью». Если в основной конфигурации у пользователя есть роль ПолныеПрава, она обладает мощным набором общих прав, таких как Администрирование, Конфигурирование и, что самое важное, ИнтерактивноеОткрытиеВнешнихОтчетовИОбработок и другие системные привилегии.
2. Логика БСП (Библиотеки стандартных подсистем): В современных типовых конфигурациях управление правами автоматизировано через подсистему «Управление доступом». Проанализируем программный код БСП: если пользователю в справочнике Пользователи назначена группа доступа с ролью Полные права или установлен флаг Администратор, система при каждом входе в программу принудительно обновляет список ролей в информационной базе. Она оставляет только Полные права и Администратор системы, считая любые дополнительные роли (в том числе из расширений) избыточными для «всемогущего» администратора.

Рассмотрим подробнее способы обхода этого ограничения.

Способ 1. Программная проверка прав в формах (самый надежный)

Поскольку роль Полные права игнорирует механизмы RLS (ограничение на уровне записей) и часто «пробивает» настройки метаданных, самым эффективным методом остается жесткая программная проверка непосредственно в коде расширения. Даже администратор не может обойти код, написанный в обработчиках событий формы.

Рассмотрим пример кода, который необходимо разместить в модуле формы нового объекта, добавленного в расширение. Для этого используем событие ПриСозданииНаСервере:

&НаСервере
Процедура Расш1_ПриСозданииНаСервереПосле(Отказ, СтандартнаяОбработка)
    // Проверяем наличие специальной роли из расширения
    Если НЕ РольДоступна("Расш1_ДоступКНовымОбъектам") Тогда
        // Если роли нет, закрываем форму с уведомлением
        Отказ = Истина;
        ТекстСообщения = "Доступ к данному объекту ограничен. 
                         |Ваших полномочий (даже с полными правами) недостаточно.";
        ОбщегоНазначенияКлиентСервер.СообщитьПользователю(ТекстСообщения);
    КонецЕсли;
КонецПроцедуры

Преимущество этого метода в том, что он работает безусловно. Мы можем расширить логику, проверяя не только наличие роли, но и конкретных пользователей или другие условия. Это «последний рубеж» обороны данных.

Способ 2. Использование функциональных опций для управления интерфейсом

Если задача стоит в том, чтобы пользователи с полными правами не видели объекты в интерфейсе (меню, панели разделов), лучшим решением будет использование Функциональных опций. В 1С функциональные опции влияют на видимость команд и элементов интерфейса даже для администраторов.

Разберем по шагам, как это реализовать:

1. Создадим в расширении новую Константу (например, Расш1_ИспользоватьСпецОбъекты) с типом Булево.
2. Создадим Функциональную опцию, где в качестве хранилища укажем нашу константу.
3. В состав функциональной опции включим все объекты нашего расширения: справочники, документы, команды подсистем.
4. Теперь, пока константа имеет значение Ложь, объекты будут скрыты из интерфейса.
5. Для управления доступом можно пойти дальше: создать Параметр функциональных опций, связанный с текущим пользователем. Тогда система будет проверять видимость персонально для каждого.

Этот метод хорош тем, что он не выдает ошибок доступа, а просто «чистит» интерфейс от лишних элементов, не вызывая вопросов у рядовых администраторов.

Способ 3. Создание профиля «Почти полные права»

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

Посмотрим, как это настроить:

1. Создадим новый Профиль групп доступа, назовем его «Администратор без доступа к спец. объектам».
2. В этот профиль включим все роли конфигурации, кроме Полные права. Да, их будет много, но это позволит БСП воспринимать пользователя не как «Суперпользователя», а как обычного пользователя с широким набором прав.
3. При таком подходе роли из расширения начнут работать корректно, так как система перестанет «схлопывать» права пользователя до одной-единственной роли ПолныеПрава.

Это трудоемкий, но правильный с точки зрения архитектуры БСП путь, позволяющий реализовать полноценный RLS и детальное разграничение прав.

Способ 4. Программный запрет на уровне модулей объектов

Чтобы обезопасить данные не только от просмотра через формы, но и от программного изменения или удаления (например, через групповую обработку), следует использовать механизмы модулей объектов. Рассмотрим применение метода ПередЗаписью в расширении:

&НаСервере
Процедура Расш1_ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
    // Проверка прав на запись объекта
    Если НЕ ПравоДоступа("Изменение", Метаданные.Справочники.Расш1_СекретныеДанные) 
         ИЛИ НЕ РольДоступна("Расш1_АдминистраторСпецДанных") Тогда
        
        Отказ = Истина;
        ВызватьИсключение "У вас нет прав на модификацию данных в этом расширении!";
    КонецЕсли;
КонецПроцедуры

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

Резюме и рекомендации

Подведем итог нашего анализа. Если вам необходимо скрыть объекты расширения от пользователей с Полными правами в типовой конфигурации 1С:

• Не пытайтесь просто снимать галочки в заимствованной роли ПолныеПрава — в конфигурациях с БСП это зачастую бесполезно.
• Используйте программные проверки в формах (ПриСозданииНаСервере) и модулях объектов (ПередЗаписью) для жесткого ограничения доступа.
• Применяйте функциональные опции для «красивого» скрытия объектов из командного интерфейса.
• Помните, что пользователь с правом Администрирование данных (входящим в полные права) все равно сможет увидеть данные через консоль запросов или обработку «Выгрузка загрузка данных XML», если у него есть доступ к серверной части. Поэтому для абсолютной безопасности требуется комплексный подход: программный код + административные регламенты.

Рассмотренные методы позволяют гибко настроить доступ и избежать конфликтов со стандартными механизмами платформы и БСП, сохраняя при этом целостность и безопасность информационной системы.