Защита расширений и конфигураций 1С: что реально мешает украсть ваш код

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

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

От чего защищаемся: сравнение способов защиты конфигурации 1С

Сначала определите угрозу. Защита «чтобы клиент не правил код» и защита «чтобы решение не ушло на сто баз бесплатно» — разные задачи.

• 🔍 Чтение кода — конкурент или франчайзи смотрит, как вы решили задачу.
• 📦 Тиражирование — одну купленную копию ставят в несколько баз или перепродают.
• ✏️ Изменение — клиент правит ваши модули и потом требует поддержки «сломанной» версии.
• 🔬 Реверс-инжиниринг — восстановление алгоритма по скомпилированному коду.

Штатная защита конфигурации 1С: поставка без исходных текстов

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

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

1. Сделайте копию рабочей конфигурации с полными исходниками. Храните её у себя: восстановить код из поставки без исходников штатными средствами нельзя.
2. В свойствах корня конфигурации заполните поля «Поставщик» и «Версия». Без них механизм поставки и обновлений работает неполноценно.
3. Откройте Конфигурация → Поставка конфигурации → Настройка поставки.
4. В дереве объектов выделите модули, которые нужно закрыть, и установите для них режим поставки без исходных текстов. Можно выделить ветку целиком — например, все общие модули.
5. Там же задайте правила поддержки для объектов: разрешены изменения или нет.
6. Выполните Конфигурация → Поставка конфигурации → Создать файлы поставки и обновления конфигурации, отметьте создание файла поставки и укажите путь к .cf.
7. Загрузите полученный .cf в чистую тестовую базу и проверьте все сценарии, особенно те, где код вызывается через Выполнить() или Вычислить().

Что закрывать, а что оставить открытым

Закрывать весь код подряд неудобно: клиент не сможет даже посмотреть, почему падает его печатная форма. Разумное деление:

• 🔒 Закрыть — общие модули с алгоритмами, расчётами, проверкой лицензии, обменом.
• 🔓 Оставить открытыми — модули форм, печатные формы, простые обработчики событий объектов.

Так клиент или его программист решает мелкие задачи сам, а ценная логика остаётся у вас.

Правила поддержки — не защита от копирования

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

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

Расширение (.cfe) и внешняя обработка (.epf) — самые популярные форматы тиражных доработок. И самые уязвимые: файл легко скопировать и подключить в любую базу.

Особенности расширений

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

• 🧩 Держать в расширении только «обвязку» — формы, подписки, вызовы. Ценный алгоритм вынести во внешнюю компоненту или веб-сервис.
• 🔑 Подключить СЛК: она умеет защищать модули расширений и внешних обработок, а не только основной конфигурации.
• 📝 Если доработка делается под конкретного заказчика — закрепить права на код договором, а не техникой.

Внешние обработки и отчёты

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

Проверка, написанная в открытом модуле, снимается правкой одной строки. Код проверки должен лежать в защищённой части: в модуле, закрытом СЛК, во внешней компоненте или на вашем сервере.

Лицензирование и привязка решения 1С к оборудованию

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

Система лицензирования и защиты конфигураций (СЛК)

СЛК — продукт фирмы 1С для разработчиков тиражных решений. Схема работы:

1. Разработчик покупает комплект СЛК и получает инструменты для защиты модулей.
2. Защищённые модули хранятся в зашифрованном виде и исполняются, только если сервер СЛК подтвердил лицензию.
3. У клиента устанавливается сервер СЛК, на котором активируются программные лицензии или подключаются аппаратные ключи.
4. Количество лицензий ограничивает число баз или рабочих мест — как задумал разработчик.

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

Аппаратные ключи сторонних производителей

USB-ключи защиты (Guardant, Sentinel и аналоги) подключают к 1С через внешнюю компоненту, которую поставляет производитель ключа или пишет разработчик. Ключ хранит идентификатор и лицензионные параметры. Из минусов — физический ключ теряется, ломается и плохо дружит с виртуальными машинами и облаком.

Свой сервер лицензий

Популярный у небольших разработчиков вариант. Решение при запуске или по расписанию обращается к вашему HTTP-сервису, передаёт идентификатор базы и получает ответ «можно / нельзя».

Каркас проверки на стороне 1С выглядит так:

Функция ЛицензияДействует(КлючЛицензии) Экспорт

    Соединение = Новый HTTPСоединение("license.example.ru", 443, , , , 10,
        Новый ЗащищенноеСоединениеOpenSSL);
    Запрос = Новый HTTPЗапрос("/api/check?key=" + КодироватьСтроку(КлючЛицензии,
        СпособКодированияСтроки.КодировкаURL));

    Попытка
        Ответ = Соединение.Получить(Запрос);
    Исключение
        // Нет связи: решите заранее, давать ли льготный период
        Возврат Ложь;
    КонецПопытки;

    Возврат Ответ.КодСостояния = 200
        И СокрЛП(Ответ.ПолучитьТелоКакСтроку()) = "OK";

КонецФункции

Это скелет для понимания схемы. В боевом решении ответ сервера подписывают, чтобы его нельзя было подменить, а саму функцию прячут в защищённый модуль. Для привязки к рабочему месту подходит СистемнаяИнформация().ИдентификаторКлиента, для привязки к базе — собственный идентификатор, который решение генерирует при первом запуске и регистрирует на сервере.

Обфускация кода 1С: польза и пределы

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

Что даёт

• 🌀 Код формально открыт, но разбирать его долго и неприятно.
• 🧱 Работает там, где поставка без исходников недоступна, — например, в расширениях и внешних обработках.
• 🧰 Можно сочетать с поставкой без исходников: даже если байт-код разберут, получат кашу.

Где ломается

• 🐞 Отладка обфусцированного кода почти невозможна, в том числе для вас самих. Держите исходник и обфусцируйте только сборку для клиента.
• 🐢 Схемы с Выполнить() и сборкой кода из строк замедляют работу и не работают в безопасном режиме: расширение или обработка, запущенные в безопасном режиме, не смогут выполнить такой код.
• 🔁 Каждое обновление нужно заново прогонять через обфускатор и заново тестировать.

Обфускаторы для языка 1С выпускают сторонние разработчики. Перед покупкой проверьте, поддерживает ли инструмент вашу версию платформы и формат исходников (выгрузку в файлы, проекты EDT).

Юридическая защита: лицензионный договор и закон

Техника отпугивает, договор позволяет взыскать. Программа для ЭВМ по ГК РФ охраняется как литературное произведение, а исключительное право на неё принадлежит автору или работодателю, если код написан сотрудником в рамках трудовых обязанностей.

Что прописать в договоре с клиентом

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

Что даёт закон

Учтите статью 1280 ГК РФ: правомерный владелец экземпляра программы вправе вносить изменения, нужные для её работы на своих технических средствах, и в ряде случаев исследовать программу. Запретить клиенту адаптацию «в ноль» не получится, а вот копирование и распространение — можно.

Комплексная защита конфигурации 1С: как собрать схему под свою задачу

Схема зависит от того, как вы продаёте решение. Подберите вариант под свой случай:

Типичные промахи при защите

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

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