Как защитить расширение 1С от копирования

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

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

Почему расширение 1С легко скопировать и что с этим делать

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

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

Поставка расширения без исходного кода модулей

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

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

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

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

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

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

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

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

Функция ЛицензияДействительна() Экспорт
    Строка = ИмяИнформационнойБазы() + "|" + ПолучитьИННОрганизации();
    Хеш = Новый ХешированиеДанных(ТипХешФункции.SHA256);
    Хеш.Добавить(Строка);
    Возврат НРег(СтрЗаменить(Строка(Хеш.ХешСумма), " ", "")) = НРег(ЭталонныйХеш());
КонецФункции

При нарушении проверки не блокируйте работу мгновенно и жёстко: смена сервера, переименование базы или перенос на новое оборудование — штатные ситуации. Корректное поведение — предупреждение администратору и ограничение новых функций с окном на перевыпуск лицензии. Жёсткая блокировка без «мягкого» режима почти гарантированно создаст конфликт с добросовестным заказчиком.

Внешние компоненты и сервер лицензий

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

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

Юридическая защита: договор и фиксация авторства

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

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

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

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

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

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

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

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

Часто задаваемые вопросы