Закрываем исходный код конфигурации 1С 8.3 от просмотра и правки

Зашифровать модуль в 1С 8.3 паролем, как это делали во внешних отчётах 7.7, нельзя: такой кнопки в Конфигураторе нет. Штатная защита кода в 1С:Предприятии 8.3 — поставка конфигурации без исходных текстов. Её включают в Конфигурация → Поставка конфигурации → Настройка поставки, затем собирают файл .cf. В нём выбранные модули остаются только в скомпилированном виде.

Частое заблуждение — что такой модуль «зашифрован навсегда» и его невозможно восстановить. Это не так. Защита закрывает код от просмотра и правки в Конфигураторе, но не делает его секретом от упорного специалиста. Поэтому пароли, ключи API и логику лицензирования в открытом виде в коде держать нельзя даже после защиты.

Что умеет защита кода в 1С 8.3 и какой способ выбрать

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

На практике их сочетают. Тиражный разработчик ставит конфигурацию без исходников, а критичные функции завязывает на систему лицензирования. Внутренний программист обычно ограничивается правами и паролем на Конфигуратор.

Подготовка конфигурации к шифрованию: эталон и выбор модулей

Главный приём, без которого всё остальное опасно, — эталонная база с исходниками. Защищённый .cf собирают из неё, а сама она остаётся у разработчика.

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

Что сделать перед стартом

1. Выгрузите эталонную базу в .dt: Администрирование → Выгрузить информационную базу.
2. Сохраните конфигурацию отдельным файлом: Конфигурация → Сохранить конфигурацию в файл.
3. Если работаете с хранилищем, зафиксируйте версию и поставьте ей понятный комментарий, например «релиз 2.4 перед сборкой поставки».
4. Заведите версию и имя поставщика в свойствах корня конфигурации. По ним получатель отличит одну сборку от другой.

Какие модули закрывать

Закрывать всё подряд — плохая идея. Чем больше модулей без исходников, тем труднее разбирать ошибки у клиента.

• 🔒 Закрывайте: общие модули с ключевыми алгоритмами, расчётами, проверкой лицензии, интеграцией с внешними сервисами.
• 🔒 Закрывайте: модули менеджеров и объектов, где сосредоточено ноу-хау.
• 📂 Оставьте открытыми: модули форм с простым интерфейсом, печатные формы, которые клиент захочет поправить сам.
• 📂 Оставьте открытыми: модули, которые часто меняются. Каждая правка в закрытом модуле означает новую сборку.

Хорошая схема — вынести закрытую логику в несколько общих модулей. Тогда формы и объекты остаются открытыми, а ноу-хау лежит в двух-трёх местах.

Как зашифровать модуль в 1С: пошаговая настройка поставки

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

Шаг 1. Откройте настройку поставки

Откройте Конфигурация → Поставка конфигурации → Настройка поставки. Появится дерево объектов конфигурации с параметрами поставки для каждого.

Шаг 2. Отметьте модули без исходных текстов

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

Для общих модулей ищите ветку Общие → Общие модули. Для документа — сам документ, у него отдельно модуль объекта, модуль менеджера и модули форм.

Шаг 3. Соберите файл поставки

Откройте Конфигурация → Поставка конфигурации → Создать файлы поставки и обновления конфигурации. Отметьте создание файла поставки .cf, при необходимости — файла обновления .cfu от предыдущей версии. Укажите каталог и запустите сборку.

Именно в файле поставки модули окажутся без текста. Сама эталонная база не меняется.

Шаг 4. Передайте получателю

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

В базе получателя такой модуль открывается пустым или с отметкой, что исходный текст отсутствует. Код при этом выполняется как обычно.

Ключи шифрования, пароли и доступ к защищённому коду

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

Как организовать доступ

• 🗝️ Эталон храните на машине или сервере, к которому есть доступ только у разработчиков. Резервные копии .dt — на отдельном носителе.
• 🗝️ Хранилище конфигурации защищайте паролями каждого разработчика. Уволенному сотруднику пользователя хранилища отключают в тот же день.
• 🗝️ Рабочую базу клиента закрывают паролем администратора. Без административных прав пользователь не войдёт в Конфигуратор и не выгрузит конфигурацию.
• 🗝️ Секреты — логины и пароли к сервисам, токены — храните не в тексте модуля, а в защищённом хранилище данных базы или в настройках, которые заполняет администратор клиента.

Когда нужна система лицензирования

Поставка без исходников не мешает скопировать базу и запустить её где угодно. Если нужно ограничить число рабочих мест или срок использования, подключают систему лицензирования. У 1С это СЛК — «Система лицензирования и защиты конфигураций», есть и сторонние решения.

Логику проверки лицензии в этом случае кладут в закрытые модули. Иначе её легко отключить одной правкой.

Выпуск обновлений для конфигурации с закрытым кодом

Защита — не разовая операция. Каждая новая версия проходит тот же путь: правка в эталоне, проверка, сборка поставки. Чтобы не сбиться, держите порядок одинаковым от релиза к релизу.

Порядок выпуска версии

1. Внесите правки в эталон и отладьте их там, пока исходники под рукой.
2. Поднимите номер версии в свойствах корня конфигурации. Без этого клиент не поймёт, какая сборка у него стоит.
3. Откройте настройку поставки и проверьте, что новые модули тоже отмечены как закрытые.
4. Создайте .cf и .cfu от предыдущей версии одной командой сборки.
5. Загрузите .cf в поставочную копию и пройдите проверку по чек-листу из раздела об отладке.
6. Отправьте клиенту файл обновления и короткий список изменений.

Как хранить выпущенные сборки

Складывайте каждую сборку в отдельный каталог с номером версии: .cf, .cfu, выгрузку эталона .dt на момент сборки. Через год клиент пришлёт ошибку из старой версии, и вы поднимете ровно тот код, который у него работает.

Отладка и тестирование зашифрованных модулей

Модуль без исходного текста отладить нельзя. Точку останова не поставить, пошаговое выполнение не работает , а в тексте ошибки нет строки кода. Поэтому всю отладку проводят до сборки, в эталоне.

Две сборки: рабочая и для разработчика

Держите у себя две копии одной версии:

• 🧪 отладочную — эталон с исходниками, на ней ищете ошибки;
• 📦 поставочную — база, загруженная из того же .cf, что ушёл клиенту.

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

Журнал регистрации вместо отладчика

Чтобы ошибки из закрытого кода можно было разобрать у клиента, пишите их в журнал регистрации. Строки кода в закрытом модуле клиент не увидит, но подробности ошибки сохранятся.

Процедура ВыполнитьРасчет(Параметры) Экспорт
	
	Попытка
		РассчитатьНачисления(Параметры);
	Исключение
		ТекстОшибки = ПодробноеПредставлениеОшибки(ИнформацияОбОшибке());
		ЗаписьЖурналаРегистрации("МойПродукт.Расчет",
			УровеньЖурналаРегистрации.Ошибка, , ,
			ТекстОшибки);
		ВызватьИсключение;
	КонецПопытки;
	
КонецПроцедуры

Клиент открывает журнал регистрации, ставит отбор по событию МойПродукт.Расчет и пересылает вам текст. Имя процедуры и описание ошибки там будут.

Что проверить на поставочной копии

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

Ошибки при защите кода и как их избежать

Исходники удалены в единственной копии

Самая дорогая ошибка. Программист собрал поставку, загрузил её в свою же базу поверх эталона и стёр исходники. Если нет .dt или .cf эталона, восстановить текст штатно нельзя. Выход один — резервная копия или хранилище.

Клиент не может обновить доработанную конфигурацию

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

Новый модуль ушёл с исходниками

Разработчик добавил общий модуль, а в настройку поставки не заглянул. В результате ключевой алгоритм уехал клиенту открытым текстом. Лечится только новой сборкой, а старый .cf уже у клиента. Сверяйте настройку поставки перед каждым релизом.

Ошибка у клиента без строки кода

В сообщении есть имя модуля, но нет текста строки. Без журнала регистрации разбирать такое — гадание. Логирование из раздела выше стоит заложить в каждый закрытый модуль с важной логикой.

Секреты в коде

Пароль к сервису записан строкой в закрытом модуле. Байт-код можно частично восстановить сторонними инструментами, и строковые константы там видны лучше всего. Секреты — только в данных базы.

Частые вопросы о шифровании модулей 1С