Разработка и Конфигурация · 10 мин
Как запаролить модуль в 1С
Как поставить пароль на модуль в 1С через конфигуратор: поставка без исходных текстов, защита формы, ограничения и проверка результата.
Запаролить модуль в 1С — значит ограничить доступ к исходному коду модуля: общего модуля, модуля объекта, модуля формы или модуля конфигурации. Прямой команды «поставить пароль на модуль» в конфигураторе нет: защита реализуется через настройки поставки конфигурации, где отдельные модули исключаются из поставки с исходными текстами. Пользователь, получивший такую конфигурацию, видит модуль в дереве объектов, но открыть и прочитать его код не может.
Такая защита применяется разработчиками тиражных решений и расширений, чтобы скрыть алгоритмы лицензирования, обмена с внешними сервисами или ноу-хау прикладной логики. При этом важно понимать: скрытый модуль продолжает исполняться на сервере и клиенте, защищается именно читаемый текст кода, а не сама функциональность.
Перед настройкой поставки убедитесь, что у вас есть полная копия исходной конфигурации с открытыми модулями. После поставки без исходных текстов восстановить код из защищённого файла штатными средствами невозможно — потеря исходников означает потерю возможности доработки.
Что именно защищается и как это работает
Конфигурация 1С хранит модули в двух видах: исходный текст на встроенном языке и скомпилированный байт-код, который исполняет платформа. При обычной работе в базе присутствуют оба. Механизм поставки позволяет исключить исходный текст из файла поставки: в базе клиента останется только байт-код, модуль будет исполняться, но открыть его в конфигураторе не получится — появится сообщение о том, что модуль поставляется без исходных текстов.
Пароль в этой схеме задаётся на уровне файла поставки или на уровне конфигурации при создании файла обновления. То есть «запаролить модуль» на практике означает комбинацию двух действий: исключить исходные тексты нужных модулей и защитить сам файл поставки паролем, чтобы его нельзя было распаковать и изменить состав.
Подготовка перед настройкой поставки
Сначала сделайте выгрузку конфигурации в файл .cf с полными исходными текстами и сохраните её в надёжном месте отдельно от рабочей базы. Это ваш единственный источник для дальнейшей доработки: после поставки без исходных текстов вернуть код из защищённой копии нельзя.
Определите, какие именно модули нужно скрыть. Обычно защищают общие модули с лицензионной логикой, обменами и коммерчески значимыми алгоритмами. Модули форм и объектов, которые клиенту может понадобиться дорабатывать, чаще оставляют открытыми — иначе любая адаптация решения под клиента станет невозможной.
Проверьте, что конфигурация находится на поддержке с возможностью изменения или полностью снята с поддержки — настройка поставки доступна для конфигурации, которую вы разрабатываете как поставщик. Для чужой типовой конфигурации защитить отдельный модуль штатно не получится.
Настройка поставки: исключаем исходные тексты модулей
Откройте конфигуратор под пользователем с полными правами и перейдите в меню «Конфигурация → Поставка конфигурации → Настройка поставки». Если пункт недоступен, сначала выполните «Создать файлы поставки и обновления конфигурации» или включите режим поставщика через «Поддержка → Настройка поддержки» с указанием себя как разработчика.
В окне настройки поставки отображается дерево объектов конфигурации с флажками. Снимите флажки с тех модулей, исходные тексты которых нужно скрыть: общих модулей, модулей объектов, модулей менеджеров. Состав поставки можно сохранить в файл, чтобы не настраивать заново при каждом выпуске новой версии.
- 1Сделайте резервную выгрузку конфигурации в .cf с открытыми исходниками
- 2Откройте Конфигурация → Поставка конфигурации → Настройка поставки
- 3Снимите флажки с модулей, которые не должны поставляться с исходными текстами
- 4Сохраните настройки поставки в файл для повторного использования
- 5Создайте файл поставки через «Создать файлы поставки и обновления конфигурации»
- 6Установите пароль на файл поставки при его создании
- 7Проверьте результат на тестовой базе: модули должны исполняться, но не открываться
Установка пароля на файл поставки
При создании файлов поставки конфигуратор предлагает задать пароль. Этот пароль защищает сам файл поставки: без него нельзя загрузить конфигурацию из файла или изменить состав поставки. Пароль храните в менеджере паролей — восстановить его нельзя, а без пароля вы не сможете выпускать обновления на основе того же файла поставки.
Для расширений конфигурации действует похожий механизм: в свойствах расширения и при его сохранении в файл можно задать пароль, а исходные тексты модулей расширения защищаются настройкой поставки расширения. Это удобно для небольших коммерческих доработок, которые не требуют изменения основной конфигурации.
Проверка результата на тестовой базе
Создайте пустую базу и загрузите в неё файл поставки. Откройте конфигуратор и попробуйте открыть защищённые модули: вместо текста должно появляться сообщение о поставке без исходных текстов. Одновременно проверьте, что прикладная функциональность работает — проведите документы, выполните обмены, вызовите защищённые процедуры через типовые сценарии.
Отдельно проверьте клиентские вызовы: если защищённый общий модуль вызывается с клиента, а флажки «Клиент (обычное приложение)» или «Клиент (управляемое приложение)» у него сняты, после поставки возникнут ошибки вызова. Такие ошибки проявляются только в защищённой версии, поэтому тестировать нужно именно поставку, а не исходную базу разработчика.
Как проверить результат
Сообщение о поставке без исходных текстов
Модуль открывается и показывает код
Все сценарии выполняются без ошибок
Ошибки вызова процедур и функций
Платформа запрашивает пароль
Файл загружается свободно
Типичные ошибки и ограничения
Самая частая ошибка — защита модулей, которые клиенту нужно дорабатывать: модуля формы документа или модуля объекта, к которому у заказчика есть собственные требования. Итог — конфликт с клиентом и вынужденная перепоставка открытой версии. Заранее фиксируйте в договоре или описании решения, какие части закрыты.
Вторая ошибка — потеря исходников: разработчик выпускает поставку без исходных текстов, а рабочая база разработки повреждается или теряется. Храните исходники в системе контроля версий (хранилище конфигурации, EDT с Git) и дублируйте выгрузки .cf.
Учитывайте и ограничение механизма: байт-код 1С теоретически поддаётся анализу сторонними инструментами, поэтому поставка без исходных текстов — это защита от обычного просмотра и копирования, а не абсолютная криптографическая гарантия. Критичные секреты (ключи, пароли к внешним сервисам) нельзя хранить прямо в коде даже защищённого модуля.
Альтернативы и дополнительные меры
Если цель — не скрыть код, а ограничить запуск решения, вместо пароля на модуль используют систему лицензирования: привязку к аппаратному ключу или сервису проверки лицензий. В этом случае модули могут оставаться открытыми, но без лицензии функциональность отключается программно.
Для защиты от несанкционированного доступа пользователей к самой базе применяйте штатные механизмы: пароли пользователей, разграничение ролей, ограничение доступа к конфигуратору. Это ортогональная задача — она защищает данные и настройки, а не исходный код.
Сравнение вариантов защиты
Подходит для тиражных конфигураций; модуль исполняется, но не читается. Требует бережного хранения исходников
Удобно для небольших доработок без изменения основной конфигурации; не защищает логику основной базы
Контролирует запуск, а не чтение кода; требует реализации проверок и инфраструктуры лицензий
Защищают данные и настройки от пользователей, но не скрывают код от администратора базы
Что важно запомнить
Модуль в 1С «запароливается» через поставку без исходных текстов плюс пароль на файл поставки. Перед настройкой обязательно сохраните полную копию исходников, после — протестируйте поставку на отдельной базе. Не храните секреты в коде и не закрывайте модули, которые клиенту нужно дорабатывать.
Частые вопросы
Можно ли поставить пароль на один общий модуль без поставки всей конфигурации?
Нет, штатный механизм работает только через поставку конфигурации или расширения целиком. Если нужно защитить одну доработку, оформите её как расширение — в нём можно защитить модули и задать пароль, не трогая основную конфигурацию.
Что увидит клиент при открытии защищённого модуля?
Конфигуратор покажет сообщение, что модуль поставляется без исходных текстов. Сам модуль останется виден в дереве объектов, его свойства доступны, а код исполняется в обычном режиме.
Можно ли восстановить исходный код из защищённой поставки?
Штатными средствами платформы — нет. Поэтому исходники хранят отдельно: в хранилище конфигурации, в Git через EDT или в выгрузках .cf. Потеря исходников означает невозможность дальнейшей доработки защищённых модулей.
Влияет ли поставка без исходных текстов на производительность?
Нет, платформа в обоих случаях исполняет один и тот же скомпилированный байт-код. Различие касается только наличия читаемого текста модуля в базе.
Можно ли защитить модуль в файловой базе без конфигуратора?
Нет, настройка поставки выполняется только в конфигураторе. Альтернатива без конфигуратора отсутствует: любые сторонние способы «запаролить» файл базы не скрывают код модулей от того, кто откроет базу в конфигураторе.
Безопасно ли хранить ключи API внутри защищённого модуля?
Нет. Байт-код потенциально поддаётся анализу, поэтому ключи и пароли следует хранить в защищённом хранилище, настройках с ограниченным доступом или получать с сервера лицензий в момент работы, а не вшивать в текст модуля.