При администрировании баз данных 1С:Предприятие часто возникает ситуация, когда пользователь, у которого, казалось бы, отобраны все административные права в рабочей базе, всё равно умудряется запускать Конфигуратор и вносить изменения в метаданные или код. Это создаёт колоссальные риски для стабильности системы и безопасности данных.
В этой статье мы подробно разберем, как такое возможно, где искать скрытые лазейки в правах доступа, а также рассмотрим профессиональные инфраструктурные методы блокировки Конфигуратора на уровне операционной системы и кластера серверов 1С.
Чаще всего доступ к Конфигуратору у рядового сотрудника появляется из-за банальной невнимательности администратора. Настройка прав в крупных конфигурациях (например, УПП, ERP или Комплексная автоматизация) включает десятки, а иногда и сотни ролей. Достаточно случайно оставить активной всего одну второстепенную роль, у которой в конфигураторе взведен флаг «Администрирование», как пользователь мгновенно получит доступ к конфигурации.
Проанализируем ситуацию по шагам. Если вы столкнулись с подобным поведением системы, выполните следующие действия:
Для того чтобы быстро выявить, какая именно роль дает пользователю доступ, не перебирая все роли вручную, мы можем написать простую обработку. Давайте посмотрим на пример программного кода, который перебирает всех пользователей информационной базы и выводит список назначенных им ролей, содержащих критическое системное право:
ВыборкаПользователей = ПользователиИнформационнойБазы.ПолучитьПользователей();
Для Каждого ТекПользователь Из ВыборкаПользователей Цикл
Для Каждого ТекРоль Из ТекПользователь.Роли Цикл
// Проверяем наличие права "Администрирование" в метаданных роли
Если Метаданные.Роли[ТекРоль.Имя].Права.Администрирование = Истина Тогда
Сообщить("Пользователь: " + ТекПользователь.Имя + " имеет доступ к Конфигуратору через роль: " + ТекРоль.Имя);
КонецЕсли;
КонецЦикла;
EndЦикла;
Этот скрипт моментально покажет вам «виновника» — ту самую роль, которую вы могли случайно пропустить при аудите прав безопасности.
Даже если у пользователя по какой-то причине остались административные права, мы можем физически лишить его возможности запустить режим конфигурирования. Для этого рассмотрим разделение клиентских приложений 1С.
Платформа 1С:Предприятие поставляется с различными исполняемыми файлами:
1cv8.exe — Толстый клиент. Он содержит в себе весь код, необходимый для запуска Конфигуратора.1cv8c.exe — Тонкий клиент. Он физически не имеет в своем составе модулей Конфигуратора. Запустить режим конфигуратора через него невозможно физически.Если ваши пользователи работают в терминальном режиме (RDP) или на локальных ПК, настройте запуск системы исключительно через Тонкий клиент 1cv8c.exe. В этом случае кнопка «Конфигуратор» в окне запуска будет неактивна, либо сам запуск будет невозможен.
Просто установить ярлык на Тонкий клиент недостаточно, ведь продвинутый пользователь может зайти в папку с установленной платформой и запустить 1cv8.exe вручную. Выясним, как заблокировать эту возможность на уровне ОС Windows:
C:\Program Files\1cv8\8.3.XX.XXXX\bin). Откройте свойства файла 1cv8.exe, перейдите во вкладку «Безопасность» и настройте явный запрет на «Чтение и выполнение» для группы обычных пользователей (доменных или локальных). Администраторам и разработчикам доступ оставьте разрешенным. При этом к файлу 1cv8c.exe доступ должен оставаться открытым для всех.1cv8.exe для всех учетных записей, кроме администраторов.Если в вашей организации используется лицензия уровня 1С:Предприятие КОРП, мы можем ограничить запуск Конфигуратора централизованно на стороне сервера 1С. Для этого используются Требования назначения функциональности.
Мы можем создать правило в кластере серверов, которое запрещает запуск сервиса отладки и конфигурирования (Designer) на рабочих серверах, обслуживающих сеансы обычных пользователей. В таком сценарии Конфигуратор разрешается запускать только на выделенном сервере (или выделенном порту), доступ к которому из сети обычных пользователей заблокирован аппаратным брандмауэром. При попытке запустить Конфигуратор с обычного рабочего места пользователь получит системную ошибку связи с сервером, даже если у него есть все права внутри базы данных.
Иногда на форумах предлагают «быстрое» решение проблемы — переименовать или переместить файл config.dll в каталоге платформы. Давайте проанализируем, почему этот метод является крайне нежелательным («костылем»):
config.dll, Конфигуратор перестанет работать вообще для всех пользователей, включая системных администраторов и программистов, которым он действительно необходим для работы.config.dll снова будет на своем законном месте, и всю процедуру защиты придется настраивать заново.Если у вас возникли подозрения, что кто-то посторонний запускал Конфигуратор, это легко проверить с помощью встроенного инструмента «Журнал регистрации». Любые действия по авторизации в Конфигураторе, сохранению конфигурации базы данных, а также выгрузке или загрузке информационных баз фиксируются системой автоматически.
Откройте Журнал регистрации, настройте фильтр по событию «Конфигуратор» или укажите имя подозреваемого пользователя. Вы мгновенно увидите точную хронологию его сеансов работы, что позволит оперативно принять административные меры.