Как зашифровать модуль в 1С и защитить код от просмотра

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

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

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

Что платформа умеет на самом деле: два механизма защиты

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

Второй механизм — пароль на модуль внешней обработки или внешнего отчёта. При сохранении файла .epf или .erf можно задать пароль, без которого модуль объекта не открывается в конфигураторе. Этот вариант подходит, когда вы передаёте заказчику отдельную обработку, а не целую конфигурацию.

Оба способа комбинируются с лицензионной защитой (например, системой лицензирования СЛК для тиражных решений), но это уже отдельный уровень — он контролирует право использования, а не читаемость кода.

Подготовка: что обязательно сделать до защиты

Главное правило — защита применяется к копии, а не к рабочей базе разработки. Поставка без исходных текстов необратима: если вы потеряете исходники, восстановить текст модуля из поставки не получится никакими штатными средствами. Поэтому первым шагом создайте выгрузку конфигурации в файл .cf и сохраните её в надёжном месте, а лучше — в системе контроля версий (хранилище конфигурации, Git через EDT).

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

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

Как создать поставку без исходных текстов модулей

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

1. 1
   Откройте конфигуратор и меню «Конфигурация → Поставка конфигурации → Настройка поставки».
2. 2
   На закладке «Состав» отметьте модули, которые должны поставляться без исходных текстов (вариант поставки «без исходных текстов»).
3. 3
   При необходимости создайте несколько вариантов поставки: например, полный и демонстрационный.
4. 4
   Выполните «Конфигурация → Поставка конфигурации → Создать файлы поставки и обновления» и укажите каталог для файлов.
5. 5
   Полученные файлы .cf и .cfu передайте на тестовую базу и проверьте работоспособность.

В настройке поставки для каждого объекта и модуля доступны варианты: поставляется с исходным текстом, без исходного текста или не поставляется вовсе. Выбирайте «без исходных текстов» только для тех модулей, где это действительно нужно: чем больше закрытого кода, тем сложнее заказчику диагностировать проблемы и тем больше нагрузка на вашу поддержку.

После создания файлов поставки не удаляйте исходную конфигурацию разработки. Файл поставки — это продукт для распространения, а не рабочая копия.

Как поставить пароль на модуль внешней обработки

Для внешних обработок и отчётов механизм проще. Откройте обработку в конфигураторе, перейдите к модулю объекта и выполните команду установки пароля (в меню действий с текстом модуля либо через свойства обработки — в зависимости от версии платформы пункт называется «Установить пароль»). После сохранения файла модуль будет запрашивать пароль при попытке открытия.

Пароль должен быть стойким: не короче 8–10 символов, с буквами разного регистра и цифрами. Простые пароли перебираются известными утилитами. Сам пароль храните в менеджере паролей — при его утере доступ к коду модуля будет потерян так же, как и для постороннего.

Учтите ограничение: пароль защищает только модуль объекта. Формы, макеты и прочие данные обработки остаются доступными. Если критичная логика размазана по модулям форм, вынесите её в модуль объекта или в общий закрытый механизм.

Как проверить, что защита сработала

Проверку выполняйте на чистой тестовой базе, загрузив туда созданный файл поставки или обработку. Не ограничивайтесь визуальным осмотром в конфигураторе разработки — там исходники остаются.

Контрольные точки

Как проверить результат

Открытие защищённого модуля в конфигураторе тестовой базы

Норма

Текст модуля отсутствует или запрашивается пароль

Тревожный признак

Код открывается и читается без ограничений

Выполнение функционала, использующего закрытый модуль

Норма

Прикладная логика работает без ошибок

Тревожный признак

Ошибки вызова процедур, сообщения о недоступности модуля

Обновление конфигурации базы данных

Норма

Обновление проходит штатно

Тревожный признак

Конфликты, требование исходных текстов

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

Ограничения и риски, о которых нужно знать

Ни один штатный механизм не даёт абсолютной защиты. Байт-код в поставке без исходных текстов поддаётся анализу специализированными инструментами, а пароли на модули внешних обработок подбираются. Реалистичная цель — отсечь массовое копирование и случайное чтение, а не противостоять целенаправленному взлому.

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

Отдельный риск — обновления. Если заказчик обновит защищённую конфигурацию неподходящим файлом или типовым релизом, закрытые модули могут быть затёрты. Поставляйте корректные файлы обновления .cfu и инструкции по их применению.

Альтернативы и дополнительные меры

Если требуется защита сильнее штатной, рассмотрите вынос критичных алгоритмов во внешнюю компоненту (Native API или COM) на компилируемом языке. Код компоненты читается существенно сложнее, чем байт-код 1С. Минус — усложнение разработки, развёртывания и требований к окружению клиента.

Для тиражных решений применяется система лицензирования СЛК: она привязывает защищённые модули к аппаратному ключу или программной лицензии и одновременно скрывает код. Это промышленный вариант для коммерческих продуктов, но он требует изучения отдельной технологии и влияет на процесс продаж.

Сравнение вариантов защиты

Поставка без исходных текстов

Подходит для целых конфигураций; штатно и бесплатно, но необратимо и не защищает от анализа байт-кода.

Пароль на модуль обработки

Подходит для отдельных .epf/.erf; просто, но защищает только модуль объекта и уязвимо к подбору.

Внешняя компонента

Для самых критичных алгоритмов; высокая стойкость, но нужны навыки компилируемых языков и усложняется развёртывание.

СЛК (лицензирование)

Для тиражных коммерческих решений; совмещает защиту кода и контроль лицензий, требует освоения технологии.

Опыт показывает: разумный баланс — закрывать только модули с уникальными алгоритмами и лицензионными проверками, а типовую обвязку оставлять открытой. Так вы сохраняете коммерческую тайну и не мешаете заказчику сопровождать систему.

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

Можно ли восстановить исходный текст модуля из поставки без исходных текстов?

Штатными средствами — нет, текст физически отсутствует в файле поставки. Поэтому резервная копия конфигурации с исходниками обязательна до создания поставки. Существующие инструменты анализа байт-кода дают лишь приблизительное представление о логике, а не исходный код.

Защищает ли пароль на конфигурацию (пароль администратора) тексты модулей?

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

Можно ли закрыть только часть модулей конфигурации?

Да. В настройке поставки для каждого объекта выбирается свой режим: с исходным текстом, без исходного текста или исключить из поставки. Это позволяет закрыть только коммерчески значимые модули.

Работает ли защищённая обработка в базе без изменения конфигурации?

Да, внешняя обработка с паролем на модуль открывается и выполняется через «Файл → Открыть» в режиме предприятия как обычно. Пароль запрашивается только при попытке просмотра кода в конфигураторе.

Что делать, если пароль на модуль обработки утерян?

Штатного способа сброса нет — доступ к коду будет потерян. Восстановить логику придётся по документации или писать заново. Храните пароли в защищённом менеджере паролей и держите незащищённую копию файла у себя.

Законно ли защищать свой код в 1С такими способами?

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