Как закрыть расширение 1С от чужих правок и лишних прав

Пароль на само расширение 1С поставить нельзя. Такой кнопки в платформе нет, и это самое частое заблуждение. Защита расширения от несанкционированных изменений складывается из нескольких слоёв: кто вообще может открыть конфигуратор , где лежит исходник, кто имеет право загружать .cfe и как опубликована база.

Разберём слои по порядку, от самого дешёвого к самому надёжному. Если хотите ограничить только случайные правки, хватит первых двух. Если расширение продаётся или стоит у клиента, понадобятся все.

Что именно можно защитить и от кого

Сначала определитесь с угрозой. От неё зависит набор мер.

Честно: полностью закрыть код от человека с правами администратора и доступом к серверу нельзя. Можно сделать правку заметной, затруднить её и оставить след.

Кто может менять расширение: права и режим конфигуратора

Изменить расширение можно двумя путями: открыть его в конфигураторе или загрузить новый .cfe поверх старого. Оба действия требуют определённых прав.

Права на конфигурирование

В списке пользователей в конфигураторе (меню «Администрирование» → «Пользователи») у каждого пользователя есть набор ролей. Для работы с конфигурацией нужна роль с правом «Администрирование» и с правом на конфигуратор. Практика такая:

• 🔒 администратору базы оставляем полные права;
• 🔒 программистам даём доступ только на копию базы для разработки;
• 🔒 пользователям с ролью «Полные права» в рабочей базе — не даём доступ к конфигуратору без нужды;
• 🔒 обычные пользователи не должны иметь административных ролей вообще.

Список тех, у кого роль «Полные права», пересматривайте раз в квартал. На практике этот список разрастается: туда добавляют «на время» и забывают убрать.

Защита от опасных действий

В свойствах самого расширения есть параметр «Защита от опасных действий». Он включает предупреждение при потенциально опасных операциях: например, когда база скопирована на другой сервер и платформа спрашивает, не копия ли это. Это не защита кода, но снижает шанс, что копия базы случайно начнёт отправлять письма и обмениваться данными как боевая.

💡 Не путайте этот параметр с защитой кода. Он про окружение, а не про исходники.

Хранилище конфигурации: контроль версий для расширения

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

Что даёт хранилище:

• ✅ видно, кто, когда и что менял;
• ✅ нельзя править объект, пока его не захватил другой разработчик;
• ✅ любую версию можно откатить;
• ✅ у каждого разработчика своя учётная запись хранилища с отдельными правами.

Роли в хранилище

В хранилище три уровня доступа: чтение, захват объектов и администрирование. Разработчикам давайте захват, чтение — тестировщикам и аналитикам, администрирование — одному-двум людям. Пользователя хранилища создаёт администратор в окне хранилища, пароль у каждого свой. Общий пароль на всех — худшее, что можно сделать: теряется авторство правок.

Хранилище вместо «просто файла»

Если расширение живёт только как файл .cfe на флешке у программиста, у вас нет ни истории, ни защиты. Минимум, который стоит сделать:

1. Создать отдельное хранилище для расширения.
2. Подключить к нему базу разработки.
3. Закрыть прямой доступ к конфигуратору в рабочей базе.
4. Выкладывать в рабочую базу только готовую версию из хранилища, выгруженную в .cfe.

Ту же схему поддерживают системы контроля версий: расширение выгружают в файлы и коммитят. Для небольших команд хранилища достаточно.

Что с паролем: чего нет и чем его заменить

Прямого пароля на расширение нет. Но у защиты по паролю есть разумные заменители.

• 🔑 Пароль на пользователя. У каждого пользователя с правом на конфигуратор должен быть свой сложный пароль. Пустой пароль у администратора — прямая дыра.
• 🔑 Пароль на хранилище. Захватить объект без учётки хранилища нельзя.
• 🔑 Парольная защита доступа к кластеру. Для серверной базы администрирование кластера 1cv8 закрывается отдельными учётными записями администратора кластера и администратора базы.
• 🔑 Защита файла .cfe. Сам файл можно положить в архив с паролем или в закрытую папку. Это защита транспорта, не кода.

⚠️ Не рассчитывайте на «секретные» названия объектов и скрытые формы. Любой, у кого есть доступ к конфигуратору, увидит всё.

Закрытие исходных текстов

Если нужно, чтобы клиент не видел и не менял код, в платформе есть механизмы поставки без возможности редактирования модулей. Их доступность и поведение зависят от версии платформы и режима поставки, поэтому смотрите описание вашей версии в документации на «Руководство разработчика». Но помните: даже закрытый от редактирования код можно запускать и изучать поведение. Дополнительно защищайтесь договором и лицензией.

Публикация расширения и безопасность сервера

Расширение работает там, где подключено, поэтому безопасность публикации не менее важна, чем защита кода.

Безопасный режим расширения

В свойствах расширения есть параметр «Безопасный режим». Когда он включён, код расширения исполняется с ограничениями: нельзя запускать внешние программы, обращаться к файловой системе и COM-объектам без разрешения. Для чужих и сторонних расширений безопасный режим лучше оставлять включённым и снимать только осознанно.

Если расширение написано вами и использует ЗапуститьПриложение или работу с файлами на сервере, безопасный режим придётся ограничить. Тогда ответственность — на вас: проверяйте каждую такую точку.

Что важно на сервере

• 🖥️ web-публикацию делайте только по HTTPS, а для внутренних баз закрывайте её фаерволом;
• 🖥️ учётную запись службы сервера 1С:Предприятия держите без прав администратора ОС;
• 🖥️ каталог с расширениями и резервными копиями закройте от чтения обычными пользователями;
• 🖥️ в настройках публикации отключите анонимный доступ, если он не нужен.

Права расширения на данные

Расширение может добавлять свои роли. Не давайте этим ролям больше, чем нужно: хорошая практика — отдельная роль на каждую функцию расширения, без «полных прав». Проверьте и обратное: расширение не должно расширять права пользователя незаметно, через привилегированный режим. Поиск по коду слова УстановитьПривилегированныйРежим занимает пять минут и сразу показывает риски.

Разграничение прав пользователей 1С под расширение

Здесь важно не ломать общую модель: у расширения есть свои объекты и свои роли, но назначаются они тем же способом, что и основные.

1. Откройте список пользователей и найдите нужного человека.
2. На вкладке ролей отметьте только те роли расширения, которые нужны ему по должности.
3. Для ролей основной конфигурации оставьте только необходимые.
4. Проверьте результат, зайдя в базу под этим пользователем в тестовом режиме.

Дополнительно можно использовать RLS — ограничения доступа на уровне записей, если расширение работает с чувствительными данными. Но RLS замедляет запросы, поэтому применяйте его только там, где без него нельзя.

💡 Права на объекты расширения проверяйте отдельно после каждого обновления: при загрузке новой версии роли могут измениться.

Аудит и мониторинг: как заметить правку

Защита без контроля — полумера. Следить нужно за двумя вещами: что менялось в конфигурации и кто заходил в конфигуратор.

Журнал регистрации

Журнал регистрации записывает события, связанные с изменением конфигурации: обновление, загрузку расширений, вход в конфигуратор. Откройте журнал («Администрирование» → «Журнал регистрации» в конфигураторе или в режиме 1С:Предприятие) и отберите события по категории, связанной с конфигурацией и сеансами. Такие события нужно просматривать после каждого планового окна обслуживания и после любых жалоб на «странное поведение».

Что смотреть регулярно

• 📋 вход в конфигуратор вне рабочего времени;
• 📋 загрузка расширений: кто и с какого компьютера;
• 📋 изменение состава ролей у пользователей;
• 📋 отключение или удаление расширения.

Сравнение с эталоном

Раз в месяц выгрузите расширение в .cfe и сравните с версией из хранилища. Для этого подойдёт сравнение и объединение конфигураций: платформа покажет все отличия до уровня строки модуля. Если расхождения есть, а в хранилище их не оформляли, кто-то правит в обход процесса.

Рабочий регламент

Технические меры держатся на человеческих. Зафиксируйте на бумаге:

1. Кто имеет право менять расширение.
2. Как выглядит запрос на изменение и кто его согласует.
3. Где хранится эталонная версия.
4. Как часто проверяется журнал.

Регламент стоит одной страницы текста, но решает больше, чем половина технических настроек.

Мини-кейс: как это выглядит в небольшой компании

Типичная картина: интегратор написал расширение для учёта, а в базе работают три программиста клиента и пять пользователей с ролью «Полные права». Через полгода выясняется, что в одном из модулей появилась лишняя строка, и отчёт считает по-другому. Кто правил, неизвестно.

Что помогает навести порядок за один день:

1. Сократить «полные права» до двух человек.
2. Выгрузить расширение в .cfe и положить его в новое хранилище.
3. Завести каждому разработчику свою учётку хранилища.
4. Раз в неделю сравнивать рабочую версию с хранилищем.

После этого лишняя правка либо не появится, либо будет видна в первую же проверку.

Сводка: какая мера от чего защищает

Ни одна мера не работает в одиночку. Роли без журнала слепы, журнал без регламента бесполезен, хранилище без дисциплины превращается в архив.

Обновления и защита

Когда выходит новая версия расширения, её заливают в базу заново. В этот момент чаще всего и ломается защита: кто-то временно выдаёт себе широкие права и забывает их убрать. Выдавайте такие права на конкретное окно и фиксируйте в заявке, когда они сняты. После обновления откройте список пользователей и убедитесь, что состав ролей вернулся к прежнему.

Типичные ошибки при защите расширения

Что чаще всего ломает защиту на практике:

• ❌ одна учётная запись Администратор на всех, без пароля;
• ❌ расширение правят прямо в рабочей базе, «чтобы не ждать»;
• ❌ хранилище есть, но все подключаются под одним пользователем;
• ❌ безопасный режим выключен «для удобства», и забыт;
• ❌ резервные копии .cfe и баз лежат в общей папке с правом чтения всем.

Если расширение уже правили без вашего ведома, сначала сравните его с эталоном, потом смотрите журнал регистрации и только после этого меняйте пароли.

Частые вопросы