В практике администрирования крупных или коммерчески чувствительных баз данных 1С часто возникает дилемма. С одной стороны, специалисту (будь то приходящий программист, аутсорсер или внутренний администратор) необходимо регулярно обновлять конфигурацию через Конфигуратор. С другой стороны, бизнес-требования и служба безопасности настаивают на том, что этот специалист не должен иметь доступа к реальным коммерческим данным в режиме 1С:Предприятие.
Многие считают, что если у пользователя есть доступ к Конфигуратору, то он автоматически получает «ключи от королевства» и может беспрепятственно просматривать любые таблицы. Однако в платформе 1С:Предприятие 8.3 предусмотрены механизмы, позволяющие гибко разграничить эти полномочия. Давайте подробно рассмотрим несколько эффективных способов решения этой задачи.
Самый простой и быстрый способ ограничить доступ к интерактивному запуску системы — настроить свойства специальной роли в Конфигураторе. Разберем этот процесс по шагам:
ОбновлениеКонфигурации.Проанализируем, что произойдет при такой настройке. Когда пользователь с единственной назначенной ролью ОбновлениеКонфигурации попытается запустить режим «1С:Предприятие», платформа мгновенно заблокирует это действие и выдаст ошибку авторизации, так как у него нет прав на запуск ни одного из доступных клиентов. При этом авторизация в Конфигураторе для выполнения процедур обновления пройдет успешно.
Часто служба безопасности опасается, что администратор в Конфигураторе может просто выгрузить базу данных в файл резервной копии (формат .dt) и унести ее с собой. Чтобы предотвратить это, проанализируем разницу между двумя ключевыми правами платформы 1С:
.dt), удаление помеченных объектов и непосредственный доступ к таблицам.Если мы заберем у роли нашего администратора право Администрирование данных, он сможет обновлять конфигурацию, но попытка выгрузить базу в .dt завершится ошибкой доступа. Это существенно снижает риски утечки конфиденциальной информации.
Кроме того, в современных типовых конфигурациях, построенных на базе БСП (Библиотеки стандартных подсистем), реализован механизм синхронизации пользователей. Если такой администратор зайдет в Конфигуратор и попытается вручную добавить себе роль «Полные права», при первой же попытке входа или выполнения регламентных процедур БСП автоматически сверит его роли с настроенными «Группами доступа» в пользовательском режиме. Поскольку в режиме «Предприятия» полные права ему не назначались, система БСП автоматически сбросит несанкционированные роли в Конфигураторе.
Если нам требуется реализовать сложную логику проверки (например, разрешить вход только с определенных IP-адресов, компьютеров или в строго определенное время), мы можем задействовать программные модули 1С.
Рассмотрим пример реализации проверки в глобальном модуле приложения. Мы можем прописать логику в обработчике события ПередНачаломРаботыСистемы в модуле управляемого приложения:
Процедура ПередНачаломРаботыСистемы(Отказ)
// Проверяем, есть ли у пользователя роль администратора обновлений
Если РольДоступна("ОбновлениеКонфигурации") Тогда
// Проверяем, что запуск происходит интерактивно (в режиме Предприятия)
#Если Клиент Тогда
Предупреждение("Запуск режима '1С:Предприятие' для вашей учетной записи запрещен службой безопасности.");
Отказ = Истина;
#КонецЕсли
КонецЕсли;
КонецПроцедуры
Использование директив компиляции и предопределенных методов позволяет гарантированно отсечь интерактивные сеансы работы, оставляя при этом возможность выполнения регламентных и фоновых заданий, если это необходимо для завершения обновления.
Самым надежным и современным решением проблемы «человеческого фактора» является организация процесса обновлений по принципу CI/CD (непрерывная интеграция и доставка). В этой схеме обновляющий специалист вообще не имеет доступа к рабочей (продуктивной) базе данных.
Выясним, как выглядит этот процесс по шагам:
.cf или .cfu) на тестовой (обезличенной) копии базы данных, где нет реальных коммерческих сведений.Для реализации автоматического обновления без запуска графического интерфейса можно использовать штатные возможности командной строки платформы или утилиту ibcmd (автономный сервер администрирования 1С). Скрипт запускается от имени системной учетной записи, параметры авторизации шифруются, а сам специалист по обновлениям физически не знает паролей администратора к рабочей СУБД.
Пример простейшей команды для выполнения пакетного обновления конфигурации базы данных из командной строки:
"C:\Program Files\1cv8\8.3.XX.XXXX\bin\1cv8.exe" DESIGNER /F "C:\PutToBAse" /N "AdminUpdate" /P "SecurePassword" /UpdateDBCfg
Такой подход полностью снимает любые вопросы доверия к персоналу, так как разработчики работают исключительно в изолированном контуре разработки, а перенос изменений на «боевую» систему полностью автоматизирован.
В случае, если администратору все-таки необходимо запускать систему в режиме «Предприятие» для контроля выполнения обработок обновления БСП, мы можем ограничить его среду выполнения на уровне кластера серверов 1С.
Использование Профилей безопасности позволяет жестко ограничить возможности выполнения кода в сеансе конкретного пользователя. С их помощью можно запретить:
Таким образом, даже находясь в режиме «Предприятие» под учетной записью с широкими полномочиями, пользователь окажется в «песочнице», из которой он не сможет выгрузить коммерческую информацию наружу.