Разработка и Конфигурация · 12 мин
Как защитить обработку 1С от копирования и несанкционированного использования
Практические способы защиты внешней обработки 1С: привязка к базе, лицензионные ключи, обфускация кода, скрытие модулей и контроль срока действия.
Внешняя обработка 1С — это файл с расширением .epf, который любой пользователь с достаточными правами может открыть в конфигураторе, прочитать код и скопировать. Если вы разрабатываете обработки на продажу или внедряете собственные алгоритмы внутри компании, вопрос защиты интеллектуальной собственности встаёт сразу: без неё заказчик может безвозмездно передать вашу разработку третьим лицам, а конкурент — заимствовать логику.
Полностью защитить обработку 1С невозможно: платформа не предоставляет штатного механизма компиляции внешних обработок в нечитаемый вид. Однако комбинация технических и организационных мер способна сделать копирование экономически невыгодным: взлом потребует больше усилий, чем покупка лицензии. Именно на такой уровень защиты и стоит ориентироваться.
Ниже разобраны рабочие методы: привязка к конкретной информационной базе, лицензионные ключи, ограничение срока работы, обфускация кода и перенос критичной логики на сервер. Для каждого способа указаны условия применения, ограничения и способы проверки результата.
Что именно нужно защищать в обработке
Прежде чем выбирать инструменты, определите, что представляет ценность. Обычно это три вещи: алгоритмы (формулы расчёта, логика обмена, нестандартные проверки), сам факт использования обработки без оплаты и доступ к данным, которые обработка формирует или передаёт.
Если ценность — в алгоритмах, основной упор делается на сокрытие кода. Если задача — продавать обработку по лицензиям, важнее механизм привязки к базе и контроля срока действия. Если обработка работает с конфиденциальными данными (например, выгружает зарплату), добавляется требование шифрования обмена и ограничения доступа на уровне прав 1С.
Реалистичная цель — не абсолютная защита, а уровень, при котором взлом дешевле поручить разработчику, чем взломщику. Для большинства коммерческих обработок этого достаточно.
Привязка обработки к конкретной базе
Самый распространённый метод — заставить обработку проверять при старте, в той ли базе она запущена. В качестве идентификатора используют параметры, которые сложно подделать одновременно: строка соединения с сервером 1С, ИНН и наименование организации из учётных данных, значение константы, которую вы заранее записываете при внедрении.
Типовая схема реализации: при первом запуске обработка собирает параметры базы, формирует из них хеш (например, по алгоритму MD5 или SHA-1 через объект «ХешированиеДанных») и сравнивает с эталонным значением, которое вы передаёте клиенту вместе с обработкой в виде файла лицензии или константы.
Функция ПолучитьКлючБазы()
Хеш = Новый ХешированиеДанных(ХешФункция.SHA1);
Хеш.Добавить(СтрокаСоединенияИнформационнойБазы());
Хеш.Добавить(Константы.ИННОрганизации.Получить());
Возврат СтрЗаменить(НРег(Хеш.ХешСумма), " ", "");
КонецФункции
Не полагайтесь на один параметр: ИНН организации злоумышленник легко подменит в копии базы. Комбинация из двух-трёх независимых признаков делает подделку заметно сложнее, особенно если один из них — строка соединения, содержащая имя сервера.
Лицензионный ключ и ограничение срока действия
Поверх привязки к базе удобно реализовать файл лицензии — небольшой текстовый или XML-файл, содержащий хеш базы, срок окончания действия и цифровую подпись этих данных. Обработка при запуске читает файл, проверяет подпись своим открытым ключом и сверяет хеш с текущей базой.
Подпись нужна, чтобы клиент не мог сам отредактировать срок в файле. Простейший вариант — HMAC: вы храните секретный ключ только у себя, при выдаче лицензии считаете HMAC от содержимого файла и дописываете его в конец. Обработка содержит тот же секрет и пересчитывает подпись при проверке. Здесь есть очевидная слабость: секрет лежит в коде обработки, поэтому его стоит прятать (об этом ниже).
Ограничение по времени работает только при контроле даты. Не сравнивайте срок с ТекущаяДата() клиентского компьютера — её легко перевести назад. Надёжнее брать дату сервера 1С или записывать в базу дату последнего успешного запуска и отказываться работать, если текущая дата меньше сохранённой.
- 1Определите набор параметров базы для привязки (строка соединения, ИНН, сервисная константа)
- 2Напишите функцию вычисления хеша базы и функцию проверки файла лицензии
- 3Добавьте проверку в обработчик ПриОткрытии формы и в экспортные процедуры, которые могут вызываться напрямую
- 4Реализуйте контроль срока: дата сервера плюс защита от перевода часов назад
- 5Сгенерируйте лицензию для тестовой базы и проверьте запуск
- 6Проверьте отказ: запустите обработку в копии базы на другом сервере — она должна корректно сообщить об отсутствии лицензии
Скрытие и обфускация кода
Что даёт обфускация
Обфускация — преобразование исходного кода в трудночитаемый вид без изменения логики: переименование переменных и процедур в бессмысленные идентификаторы, удаление комментариев, запутывание структуры. Готовых штатных обфускаторов в платформе нет, используются сторонние инструменты или собственные скрипты обработки модулей.
Поймите ограничение: обфусцированный код всё равно исполняется платформой и может быть отлажен. Опытный специалист восстановит логику, просто потратит больше времени. Обфускация — барьер от случайного копирования и любопытных пользователей, а не от целенаправленного взлома.
Поставка без исходных текстов
Если обработка встраивается в конфигурацию как дополнительный отчёт или обработка через механизм БСП, часть логики можно перенести в общие модули конфигурации и поставить их без исходных текстов — платформа поддерживает такой режим поставки. Модуль исполняется, но в конфигураторе показывает заглушку вместо кода.
Этот способ применим только при поставке в составе конфигурации, а не отдельным .epf-файлом, и требует аккуратности при обновлениях: клиент не сможет сам исправить ошибку в закрытом модуле, вся поддержка ложится на вас.
Вынос критичной логики за пределы обработки
Самый надёжный технический приём — не хранить ценный код в обработке вообще. Есть два рабочих варианта.
Первый — внешняя компонента (Native API или COM). Алгоритм реализуется на C++ или другом компилируемом языке, компонуется в DLL, а обработка лишь вызывает её методы. Реверс-инжиниринг скомпилированной библиотеки на порядок сложнее чтения встроенного языка 1С. Минус — стоимость разработки и необходимость поддерживать компоненту под разные платформы и разрядности.
Второй — серверная проверка лицензии через интернет. Обработка при запуске обращается к вашему веб-сервису, передаёт идентификатор базы и получает разрешение на работу. Ключевая логика (например, сложный расчёт) может выполняться прямо на сервере, а обработка получает только результат. Это даёт полный контроль: вы можете отозвать лицензию в любой момент. Ограничение очевидно — у клиента должен быть доступ в интернет, а у вас — работающий сервис, иначе обработка встанет у всех клиентов одновременно.
Сравнение вариантов защиты
Дёшево и быстро внедряется, подходит для большинства коммерческих обработок. Взламывается правкой кода, если злоумышленник доберётся до модуля
Дополнительный барьер против чтения логики. Сама по себе не защищает от копирования, требует тестирования после применения
Высокая защита алгоритмов, но дорогая разработка и сложности с развёртыванием и обновлением
Максимальный контроль и возможность отзыва доступа. Требует постоянного интернет-канала у клиента и отказоустойчивого сервера у вас
Организационные меры и типичные ошибки
Техника не заменяет договор. В лицензионном соглашении или договоре на разработку зафиксируйте: запрет передачи обработки третьим лицам, условия получения новых лицензий при смене сервера, стоимость продления. Для корпоративных заказчиков часто достаточно именно юридической защиты — риск претензий удерживает от копирования лучше любого кода.
Дополнительно ограничьте доступ на уровне платформы: внешние обработки должны открываться только у пользователей с соответствующими правами, а в типовых конфигурациях механизм «Дополнительные отчеты и обработки» позволяет назначать доступ по ролям. Так вы сократите круг лиц, которые вообще могут запустить и скопировать файл.
Как проверить, что защита работает
После внедрения обязательно смоделируйте сценарии злоумышленника. Скопируйте базу на другой сервер или в файловый вариант и запустите обработку — она должна отказать с понятным сообщением. Удалите или испортите файл лицензии — поведение должно быть аналогичным. Переведите системную дату назад и вперёд за срок лицензии — в первом случае обработка обязана работать корректно, во втором — остановиться.
Отдельно проверьте прямой вызов: создайте тестовую обработку, которая открывает вашу через ВнешниеОбработки.Создать() и вызывает экспортные процедуры без открытия формы. Если логика выполнилась без лицензии — защита пробита, переносите проверку глубже.
Как проверить результат
Обработка сообщает об отсутствии лицензии и не выполняет полезную работу
Обработка запускается и работает как обычно
Каждая публичная процедура сама проверяет лицензию
Логика выполняется, минуя проверку в форме
Обработка фиксирует откат времени и отказывает или игнорирует клиентскую дату
Просроченная лицензия снова становится «действующей»
Подпись не сходится, запуск блокируется с понятным сообщением
Обработка падает с ошибкой платформы или, хуже, продолжает работать
Полезно один раз отдать защищённую обработку коллеге-разработчику с задачей «сломай её». Час такого тестирования покажет слабые места честнее любых теоретических рассуждений: чаще всего находятся забытые экспортные процедуры и секреты, лежащие в коде открытым текстом.
Что важно запомнить
Абсолютной защиты обработки 1С не существует, поэтому стройте эшелонированную оборону: привязка к базе, подписанный файл лицензии с контролем срока по серверному времени, проверки во всех экспортных процедурах, а самую ценную логику — во внешней компоненте или на своём сервере. Обязательно тестируйте отказ, а не только успешный запуск, и подкрепляйте технические меры договором.
Частые вопросы
Можно ли полностью запретить просмотр кода внешней обработки?
Нет, штатного способа скрыть код .epf-файла платформа не предоставляет. Доступные варианты — обфускация, которая затрудняет чтение, или вынос логики во внешнюю компоненту либо на сервер, где код вообще не покидает вашу инфраструктуру.
Что делать, если клиент переезжает на новый сервер и лицензия слетает?
Это штатная ситуация, а не сбой. Заложите в регламент поддержки процедуру перевыпуска: клиент присылает новый идентификатор базы (удобно, если обработка сама показывает его в окне ошибки), вы генерируете новый файл лицензии. Чтобы снизить частоту обращений, не привязывайтесь к параметрам, которые меняются при каждой миграции, — например, к пути файловой базы.
Помогает ли пароль на модуль обработки?
Парольная защита модулей внешних обработок давно не считается надёжной: существуют инструменты её снятия. Рассматривайте пароль как минимальный барьер от случайного просмотра, но не как защиту от намеренного копирования.
Стоит ли делать онлайн-проверку лицензии для недорогой обработки?
Обычно нет. Поддержка лицензионного сервера стоит времени и денег, а его недоступность остановит работу всех клиентов. Для массовых недорогих продуктов достаточно офлайн-привязки с подписанным файлом лицензии. Онлайн-проверка оправдана для дорогих решений с ограниченным кругом клиентов.
Как защитить обработку, которую я внедряю внутри своей компании, а не продаю?
Главный риск здесь — уход сотрудника вместе с разработкой. Ограничьте круг пользователей через механизм дополнительных отчётов и обработок, храните исходники в корпоративном репозитории с разграничением доступа, а трудовым договором закрепите, что разработка — служебное произведение компании.
Нарушит ли защита обновление типовой конфигурации у клиента?
Если обработка подключена как внешняя и не встроена в конфигурацию, обновление её не затронет. Проблемы возникают, когда логика защиты размещена в общих модулях конфигурации — тогда при обновлении модули могут быть заменены. На этот случай держите инструкцию по повторному внедрению и тестируйте защиту после каждого обновления у клиента.