В процессе администрирования баз данных 1С нередко возникает ситуация, когда пользователю необходимо предоставить широкие полномочия для работы с данными, но при этом требуется исключить возможность его входа в режим Конфигуратор. Это может быть связано с требованиями безопасности, защитой интеллектуальной собственности или предотвращением случайных изменений в структуре конфигурации. В рамках данной статьи мы подробно разберем, как программно и административно ограничить доступ к инструментам разработки, не урезая при этом необходимые бизнес-права пользователя.
Первым делом проанализируем стандартный механизм ролей в платформе 1С:Предприятие 8.3. Многие начинающие администраторы полагают, что право ПолныеПрава является монолитным, однако это не совсем так. В современных типовых конфигурациях и самой платформе права на техническое управление разделены.
Рассмотрим два ключевых права, которые часто путают:
.dt.Чтобы решить задачу, нам необходимо создать новый профиль или роль (назовем её, например, ПолныеПраваБезКонфигуратора), в которой будут отмечены все галочки, кроме Администрирование системы. Проанализируем ситуацию: пользователь сможет удалять документы, проводить регламентные операции и даже управлять другими пользователями (если оставить обычное Администрирование), но кнопка «Конфигуратор» в окне запуска станет для него бесполезной — система выдаст ошибку доступа. Для упрощения этой задачи и наглядной настройки профилей можно использовать инструмент для управления правами доступа.
Выясним еще один важный момент: платформа позволяет жестко закрепить тип клиентского приложения для каждого конкретного пользователя. Если мы хотим минимизировать шансы на запуск тяжелых административных инструментов, выполним следующие шаги в Конфигураторе (под учетной записью главного администратора):
После этой настройки, даже если пользователь попытается запустить базу через 1cv8.exe (толстый клиент), система принудительно попытается переключить его в режим тонкого клиента, который физически не поддерживает функции конфигуратора. Это создаст дополнительный барьер для продвинутых пользователей. При необходимости быстро протестировать работу интерфейса и новые ограничения под учетной записью сотрудника можно воспользоваться обработкой для запуска сеанса под другим пользователем.
Рассмотрим радикальный, но крайне эффективный метод на уровне системного администрирования. Проблема доступа к Конфигуратору часто заключается в том, что на компьютер пользователя установлена полная версия платформы 1С. Разберем, как это изменить.
При развертывании 1С на рабочих станциях (особенно через групповые политики или инсталлятор) мы можем выбрать только компонент 1С:Предприятие — Тонкий клиент. В составе тонкого клиента отсутствуют библиотеки, необходимые для работы конфигуратора (например, те самые config.dll или backend.dll в старых версиях). Если на компьютере физически нет исполняемых файлов для разработки, зайти в Конфигуратор будет невозможно технически, какие бы права ни были назначены в самой базе.
Посмотрим на ситуацию с другой стороны. Если нам нужно абсолютно гарантировать, что пользователь не доберется до конфигурационных файлов и инструментов, идеальным решением будет публикация базы на веб-сервере (Apache или IIS).
Когда пользователи работают через Веб-клиент (браузер), они взаимодействуют только с интерфейсом «Предприятия». В браузере по определению нет режима «Конфигуратор». Вы можете дать пользователю роль ПолныеПрава, но находясь в веб-интерфейсе, он никогда не сможет инициировать сессию разработчика. Это самый современный и безопасный метод для удаленных офисов или сотрудников на аутсорсе.
Иногда требуется быстро настроить ярлыки так, чтобы пользователи не путались. Хотя это не является строгим методом защиты (пользователь может отредактировать ярлык), это хорошо работает как организационная мера. Проанализируем параметры командной строки:
Для запуска режима предприятия используется параметр ENTERPRISE. Если мы создадим ярлык с таким путем:
"C:\Program Files\1cv8\common\1cestart.exe" ENTERPRISE /F "D:\Bases\Accounting"
Система сразу начнет загрузку интерфейса пользователя. В противовес этому, режим разработчика вызывается ключом DESIGNER. Если мы исключим любые упоминания этого ключа в ярлыках и инструкциях, вероятность случайного захода в конфигуратор снизится.
Разберем продвинутый метод мониторинга. Если база работает в клиент-серверном режиме, мы можем использовать программный интерфейс для анализа текущих соединений. С помощью расширения конфигурации или фонового задания мы можем реализовать следующий алгоритм:
Соединения = СоединенияИнформационнойБазы.ПолучитьСоединения();
Для Каждого Соединение Из Соединения Цикл
Если Соединение.ИмяПриложения = "Configurator" Тогда
Пользователь = Соединение.Пользователь;
// Проверяем, входит ли пользователь в список разрешенных
Если Не ЭтоАдминистраторРазработчик(Пользователь) Тогда
// Здесь может быть код для записи в лог или уведомления
// Платформа не позволяет просто так "выбить" конфигуратор изнутри кода 1С,
// но мы можем оперативно отреагировать.
КонецЕсли;
КонецЕсли;
КонецЦикла;
Важно понимать, что внутри самого Конфигуратора встроенный язык 1С практически не исполняется (за исключением редких случаев при обновлении), поэтому «заблокировать кнопку» программным кодом внутри МодуляУправляемогоПриложения не получится. Основной упор всегда должен идти на права доступа (роли) и состав установленных компонентов на стороне клиента.
Подведем итог нашему анализу. Для надежного закрытия доступа к Конфигуратору при сохранении полных прав на данные рекомендуется:
ПолныеПрава, исключив из неё право Администрирование системы.Помните, что удаление системных библиотек (вроде config.dll) — это «костыльный» метод, который может привести к ошибкам при обновлении платформы или некорректной работе системы. Используйте штатные механизмы платформы 1С для достижения стабильного и предсказуемого результата.