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

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

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

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

Какие угрозы нужно учитывать при распространении расширения

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

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

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

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

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

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

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

Установка пароля на расширение

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

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

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

Программная привязка расширения к конкретной базе

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

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

Функция ПроверитьЛицензию() Экспорт
	РазрешённыйИНН = "7700000000";
	ТекущийИНН = Константы.ИННОрганизации.Получить();
	Если ТекущийИНН <> РазрешённыйИНН Тогда
		Возврат Ложь;
	КонецЕсли;
	Возврат Истина;
КонецФункции

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

Контроль целостности и защита от модификации

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

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

Юридическая защита и оформление передачи

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

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

Сравнение способов защиты и выбор комбинации

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

Частые вопросы о защите расширений 1С