При настройке прав доступа в системе «1С:Предприятие» разработчики часто сталкиваются с жестким требованием со стороны заказчиков или службы безопасности: предоставить системному администратору права на управление пользователями и обновление базы данных, но полностью исключить для него возможность изменения программного кода.
На первый взгляд задача кажется стандартной, но при попытке настроить её через Конфигуратор разработчик упирается в архитектурное ограничение платформы. Давайте подробно разберем, почему стандартный механизм ролей здесь бессилен, и проанализируем четыре практических способа решения этой проблемы.
В платформе «1С:Предприятие» права доступа внутри Конфигуратора спроектированы монолитно. Для того чтобы системный администратор мог выполнять свои обязанности, ему требуются следующие ключевые административные права:
Как только мы включаем эти флаги в роли пользователя, платформа автоматически открывает ему полный доступ к Конфигуратору. Разграничить права на уровне объектов метаданных внутри самого Конфигуратора (например, разрешить изменять список пользователей, но запретить открывать общие модули) технически невозможно. Если пользователь зашел в Конфигуратор с административными правами, он может открыть любой модуль и внести туда изменения.
Посмотрим на альтернативные, проверенные практикой методы обхода этого ограничения.
---
Это один из самых надежных и элегантных способов защиты программного кода от случайного или намеренного изменения администратором, не требующий написания дополнительного кода.
Рассмотрим подробнее логику этого метода:
Результат: Системный администратор заходит в Конфигуратор под своей учетной записью 1С, имея полные права на управление пользователями ИБ. Однако при попытке открыть и изменить любой модуль системы платформа выдаст предупреждение о том, что объект не захвачен в хранилище, и заблокирует ввод любых символов. Таким образом, код остается в безопасности, а административные функции выполняются в полном объеме.
---
Зачем вообще пускать системного администратора в Конфигуратор? В современных конфигурациях, разработанных на базе Библиотеки стандартных подсистем (БСП), управление учетными записями полностью перенесено в пользовательский интерфейс.
Выясним, как правильно организовать этот процесс по шагам:
Шаг 1. Настройка прав в режиме «1С:Предприятие»
Вместо того чтобы давать сисадмину доступ к Конфигуратору, назначим ему в пользовательском режиме предопределенную группу доступа или роль Администратор системы (или Администрирование в зависимости от конфигурации). Это позволит ему:
Пользователи.Шаг 2. Автоматизация обновления конфигурации базы данных
Если сисадмину все же требуется запускать обновление конфигурации базы данных (применение изменений после загрузки обновлений разработчиком), мы можем полностью исключить его интерактивный вход в Конфигуратор. Для этого настроим пакетный скрипт автоматизации.
Проанализируем пример такого скрипта (бат-файла) для запуска обновления через командную строку:
@echo off
set BIN_PATH="C:\Program Files\1cv8\8.3.22.1709\bin\1cv8.exe"
set BASE_PATH="C:\v8_bases\trade_db"
set ADMIN_USER="SysAdmin"
set ADMIN_PASS="StrongPassword123"
echo Запуск обновления конфигурации базы данных...
%BIN_PATH% DESIGNER /F %BASE_PATH% /N %ADMIN_USER% /P %ADMIN_PASS% /UpdateDBCfg /Out "C:\logs\update_log.txt" -NoTruncate
if %errorlevel% neq 0 (
echo Произошла ошибка при обновлении! Подробности в логе update_log.txt.
pause
) else (
echo Обновление успешно завершено.
)
При таком подходе у системного администратора вообще отпадает необходимость интерактивного запуска Конфигуратора. Скрипт отрабатывает в фоновом режиме, а риск несанкционированного изменения кода сводится к нулю.
---
Если мы имеем дело с тиражным решением или заказчик требует жесткого разделения сред разработки и эксплуатации, применим метод компиляции модулей (поставка без исходных текстов).
Разберем, как реализовать этот метод:
.cf) или файл обновления (.cfu).При генерации этих файлов платформа компилирует исходный код на языке 1С в промежуточный байт-код, полностью удаляя исходный текст из поставки. После того как системный администратор загрузит этот файл в рабочую базу, он (и любой другой пользователь) при попытке открыть защищенный модуль увидит пустое окно с надписью «Исходный текст модуля отсутствует». Код будет выполняться системой в штатном режиме, но прочитать или отредактировать его станет невозможно.
---
Если изменения вносятся часто и собирать каждый раз поставку без исходных текстов неудобно, применим более простой локальный метод защиты — установку паролей.
Выполним следующие шаги:
После этой процедуры текст модуля шифруется. При попытке любого пользователя (включая системного администратора с полными правами) открыть данный модуль, система потребует ввести пароль. Если пароль сисадмину не сообщать, он не сможет увидеть и отредактировать алгоритмы внутри этого модуля.
Важное ограничение метода: Помните, что данный способ нельзя применить к модулям управляемых форм и модулям команд, так как они должны оставаться открытыми для клиентской компиляции. Кроме того, для крупных конфигураций ручная установка паролей на сотни модулей может оказаться крайне трудоемкой.
---
Мы проанализировали ситуацию и выяснили, что напрямую запретить редактирование кода в Конфигураторе штатными правами роли нельзя. Тем не менее, задача решается организационными и техническими обходами: