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

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

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

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

Как устроена защита внешней обработки и что реально защитить

Файл внешней обработки — это контейнер, внутри которого лежат формы, макеты, модули и метаданные. Платформа умеет хранить модули в двух видах: с исходным текстом и только в скомпилированном виде (байт-код). Пароль на модуль шифрует исходный текст, а поставка без исходников удаляет его из файла вовсе.

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

Пароль на модуль: базовый уровень защиты

Самый простой способ — установить пароль на модуль объекта обработки. Откройте обработку в конфигураторе, перейдите в модуль объекта и в меню «Текст» выберите пункт «Установить пароль». После этого открыть текст модуля без пароля нельзя.

Ограничения метода существенные. Пароль защищает только от просмотра через конфигуратор; существуют инструменты, позволяющие снять или обойти такую защиту. Кроме того, пароль легко потерять: если вы забудете его и не сохраните исходники отдельно, код будет утрачен безвозвратно. Всегда храните незащищённую копию обработки в системе контроля версий (Git, хранилище конфигурации).

Поставка без исходных текстов модулей

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

Байт-код исполняется платформой как обычно, но прочитать его как текст программы штатными средствами нельзя. Декомпиляторы байт-кода 1С существуют, однако восстановленный код получается неполным и трудным для анализа — для большинства сценариев этого достаточно.

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

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

Обфускация кода

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

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

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

Привязка обработки к конкретной базе

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

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

Ограничение срока работы и контроль версий

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

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

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

Пароль на модуль

Быстро и просто, подходит для внутренних обработок. Слабая стойкость, риск потери кода при утрате пароля

Поставка без исходников

Основной метод для коммерческих поставок. Требует контроля совместимости с версиями платформы

Обфускация

Усиливает остальные методы, усложняет анализ. Трудоёмко, требует полного тестирования после применения

Привязка к базе и сроку

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

Частые ошибки и проверка результата

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

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

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

Контрольные точки

Как проверить результат

Открытие модуля в конфигураторе

Норма

Текст запрашивает пароль или отсутствует вовсе

Тревожный признак

Исходный код виден без ограничений

Запуск в целевой базе

Норма

Все функции работают, как в открытой версии

Тревожный признак

Ошибки выполнения, недоступные процедуры

Запуск в посторонней базе

Норма

Обработка сообщает об отсутствии лицензии и завершает работу

Тревожный признак

Обработка запускается без ограничений

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

Можно ли полностью защитить обработку от взлома?

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

Что делать, если потерян пароль от модуля?

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

Работает ли обработка без исходных текстов на любой версии платформы?

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

Как передать клиенту демо-версию обработки?

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

Защищает ли привязка к базе от копирования файла?

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

Нужно ли согласие клиента на привязку и сбор данных о запусках?

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