Защита исходного кода внешних обработок и конфигураций 1С

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

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

Почему встроенный язык 1С нельзя закрыть наглухо

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

Три уровня, на которых вообще можно действовать:

• 🔒 Технический — спрятать или удалить исходный текст модулей, чтобы в конфигураторе клиента его не было видно.
• 🛡️ Организационный — ограничить права: кто и что может открыть, выгрузить, изменить.
• ⚖️ Правовой — договор и авторское право: право запретить использование и взыскать убытки.

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

Варианты передачи внешней обработки клиенту

Внешняя обработка .epf (или отчёт .erf) — это файл, который открывается через Файл → Открыть или подключается в разделе Администрирование → Печатные формы, отчёты и обработки → Дополнительные отчёты и обработки. По умолчанию её модуль открыт: любой с конфигуратором видит весь код.

Что можно сделать перед передачей:

1. Пароль на модуль. В конфигураторе откройте обработку, вызовите свойства модуля и задайте пароль (пункт установки пароля в контекстном меню модуля). После этого текст модуля в конфигураторе без пароля не открыть.
2. Удаление исходного текста. Более жёсткий вариант — поставлять обработку, из которой убраны тексты модулей, но оставлен исполняемый код. Этим занимается отдельная утилита защиты (см. следующий раздел), она работает и с внешними обработками.
3. Вынос логики на сервер. Если обработка обращается к общему модулю или внешней компоненте на стороне сервера, ключевая логика физически не попадает в файл .epf у клиента.

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

Утилита защиты и поставка конфигурации без исходников

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

Штатный механизм поставки. В конфигураторе: Конфигурация → Поставка конфигурации → Создать файлы поставки и обновления. Здесь для каждого объекта задаются правила изменения:

• изменения разрешены;
• изменения разрешены, но не рекомендуются;
• изменения не разрешены (объект «закрыт на замок»).

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

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

Типичный порядок работы:

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

Сравнение способов по уровню закрытия:

Ограничение прав доступа к обработкам и данным

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

Что настраивается через Администрирование → Настройки пользователей и прав:

• Роли и профили групп доступа. Если у пользователя нет права на интерактивное открытие внешних обработок, он не подключит постороннюю .epf и не выгрузит вашу.
• Запрет открытия обработок через меню Файл. Право «Интерактивное открытие внешних обработок» и «…отчётов» регулируется отдельно; без него пункт меню недоступен.
• Ограничение на выгрузку конфигурации. Право на административные функции и выгрузку базы (.dt) стоит оставлять только тем, кому оно действительно нужно.

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

Вынос логики в расширение конфигурации

Расширения конфигурации (появились в платформе 8.3.6) позволяют добавлять функциональность, не меняя основную конфигурацию и не снимая её с поддержки. Для защиты кода это даёт два плюса.

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

Когда расширение уместнее обычной доработки:

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

Что выбрать под вашу ситуацию:

Вынос ключевой логики на сервер

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

Варианты, которые это дают:

• Общий серверный модуль. Расчётную часть выносят в общий модуль с флагом «Сервер» и без флага «Клиент». Клиентская обработка только вызывает экспортные процедуры — алгоритм исполняется на сервере и в клиентский файл не попадает.
• Внешняя компонента. Критичную логику оформляют отдельной компонентой (например, на C++). Код компоненты скомпилирован, встроенным языком не читается, а 1С обращается к ней через заданный интерфейс.
• Веб-сервис на вашей стороне. Обработка отправляет данные на ваш сервер по HTTP-сервису и получает результат. Самого расчёта у клиента нет совсем — но появляется зависимость от доступности сервиса и вопросы передачи данных.

У подхода есть цена: отладка усложняется, а веб-сервис требует постоянно доступного сервера. Поэтому на сервер выносят не всё подряд, а именно те алгоритмы, ради которых решение и покупают.

Правовая защита: авторское право и договор

Техника задерживает вскрытие, а право даёт основание требовать и взыскивать. В России программа для ЭВМ охраняется авторским правом как литературное произведение (ст. 1261 ГК РФ) — с момента создания, без каких-либо регистраций и знаков охраны.

Что это даёт на практике:

• Исключительное право на код принадлежит автору или работодателю (если код написан в рамках служебного задания). Чужое использование без разрешения — нарушение.
• Государственная регистрация программы в Роспатенте (ст. 1262 ГК РФ) необязательна, но свидетельство — весомое доказательство авторства и даты в споре.
• Лицензионный договор (ст. 1235–1238 ГК РФ) определяет, что именно клиент вправе делать с вашим кодом: использовать, но не копировать, не передавать третьим лицам, не декомпилировать сверх разрешённого законом.

Минимальный набор документов при передаче решения:

1. Договор на разработку или лицензионный договор с прямым указанием: право использования передаётся, исключительное право остаётся за вами.
2. Запрет на передачу третьим лицам и на создание производных решений без согласия.
3. Пункт о конфиденциальности (NDA), если клиент получает доступ к исходникам в принципе.

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

Частые ошибки при защите кода

Ошибки, из-за которых защита либо не работает , либо мешает вам самим:

• 🔑 Один пароль на все обработки. Утёк один раз — открыты все. Пароли разные, хранятся отдельно от файлов поставки.
• 🗑️ Вырезали исходники, не сохранив оригинал. Доработать такую обработку или конфигурацию уже нельзя — только переписать заново. Полная версия с кодом всегда остаётся у вас.
• 👤 Закрыли код, но раздали административные права. Пользователь с правом выгрузки .dt развернёт копию базы и изучит её. Техническая защита без ограничения прав дырявая.
• 📄 Понадеялись только на пароль. Пароль на модуль — не шифрование. Для коммерческого продукта это нижняя планка, а не достаточная мера.
• ✍️ Нет договора. Без лицензионного договора и фиксации перехода прав защищать в суде нечего, даже если код закрыт технически.
• 🧩 Перепутали «закрыть» и «запретить изменения». Запрет изменений в правилах поставки прячет структуру, но не текст модулей. Чтобы убрать исходники, нужна утилита защиты.

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