Защита кода 1С от копирования и правок: что работает на практике

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

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

Что именно защищает разработчик модуля 1С

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

• 👀 Закрыть алгоритм от чтения. Вы продаёте отраслевое решение, и ценность в расчёте, а не в формах.
• ✏️ Запретить правки. Клиент меняет код, ломает обновление, а потом звонит на поддержку.
• 📦 Ограничить тиражирование. Одна купленная копия не должна расходиться по десяти базам.

Платформа 1С хранит модуль в двух видах: исходный текст на встроенном языке и скомпилированный байт-код. Исполняется байт-код. Если убрать исходник, программа продолжит работать, но прочитать и поправить её в Конфигураторе станет нельзя.

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

Это встроенный в Конфигуратор механизм поставщика. Он не требует денег и сторонних программ.

Пошагово

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

Никогда не удаляйте исходные тексты в единственной копии конфигурации. Эталон с исходниками храните в хранилище конфигурации или в Git и делайте резервную копию. Восстановить исходный текст из поставки штатными средствами нельзя.

Что вы получаете и чего лишаетесь

Что проверить перед выпуском закрытой поставки

• 🧪 Сообщения об ошибках. Добавьте в закрытые модули понятные тексты исключений через ВызватьИсключение. Без исходника это единственное, что подскажет вам, где упал код у клиента.
• 📞 Канал поддержки. Клиент не сможет поправить ошибку сам. Договоритесь заранее, в какой срок вы выпускаете исправление.
• 🔁 Обновление. Соберите .cfu от предыдущего релиза и обновите им тестовую копию клиентской базы: доработки клиента в открытых объектах должны сохраниться.
• 📚 Журнал регистрации. Пишите ключевые события закрытого модуля в журнал регистрации — так вы восстановите ход событий без отладчика.

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

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

Сторонние инструменты: лицензирование и шифрование кода

Если нужно, чтобы решение работало только у тех, кто заплатил, штатной поставки мало. Здесь есть два рабочих пути.

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

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

• 🔐 разработчик шифрует выбранные модули с помощью инструментов СЛК;
• 🔑 у клиента ставится сервер лицензирования и ключ — программный (привязан к оборудованию) или аппаратный USB;
• ▶️ зашифрованный код исполняется только при наличии действующей лицензии; без неё защищённые функции недоступны.

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

Внешняя компонента с ядром алгоритма

Второй приём — перенести самую ценную часть (расчёт, проверку, генерацию ключа) во внешнюю компоненту по технологии Native API. Компонента пишется на C++ и компилируется в .dll или .so. В 1С остаётся только вызов её методов.

• ✅ Скомпилированный машинный код разобрать на порядок сложнее, чем байт-код 1С.
• ✅ Внутри компоненты можно проверять собственный лицензионный ключ.
• ❌ Нужен программист C++ и сборки под каждую платформу (Windows, Linux, разрядность).
• ❌ Компонента подключается в 1С с ограничениями безопасности, и при развёртывании на сервере у клиента её придётся устанавливать и проверять.

Логика на вашем сервере

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

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

Обфускатор переписывает текст модуля так, чтобы он оставался рабочим, но перестал читаться. Среди известных инструментов для 1С — «Нетленка». Типичные приёмы:

• 🔤 переименование переменных и процедур в бессмысленные имена;
• 🧩 вставка «мёртвого» кода и лишних ветвлений;
• 🔒 хранение строк и фрагментов кода в зашифрованном виде с расшифровкой при исполнении;
• 🗜 удаление комментариев, отступов и переносов строк.

Чем вы платите:

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

Сравнение способов защиты модуля 1С

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

Расширения конфигурации: изоляция вместо замка

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

Что даёт расширение разработчику:

• 🧱 Граница ответственности. Ваши доработки лежат отдельно, типовая конфигурация остаётся на поддержке. Сломалось после обновления — сразу видно, чьё это.
• 🔄 Обновление без слияния. Клиент обновляет типовую 1С, ваше расширение подключается поверх. Конфликт возникает только там, где вы перехватили изменённый метод.
• 🛡 Безопасный режим. У расширения есть свойства «Безопасный режим» и «Защита от опасных действий». Клиент видит, что ваш код не пишет в файловую систему и не запускает внешние программы без разрешения.
• 📋 Учёт версий. Расширение можно выпускать собственными релизами и сравнивать версии у разных клиентов.

Как совместить расширение с защитой:

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

Права на код и лицензионный договор

Техническая защита только поднимает цену взлома. Остановить тиражирование в споре поможет право. Программа для ЭВМ, в том числе конфигурация и отдельный модуль на встроенном языке 1С, охраняется как литературное произведение (ст. 1261 ГК РФ).

Что стоит сделать разработчику:

• 📝 Определить, чей код. Если доработку пишет штатный программист в рамках трудовых обязанностей, исключительное право по общему правилу принадлежит работодателю. Для подрядчика всё решает договор: передаёт он исключительное право или только даёт лицензию на использование.
• 📄 Заключить лицензионный договор. Укажите число баз и рабочих мест, территорию, срок, запрет передачи третьим лицам и запрет декомпиляции сверх того, что разрешает закон.
• 🗂 Зафиксировать авторство. Право возникает с момента создания, регистрация не обязательна. Но регистрация программы в Роспатенте и архив релизов в хранилище с датами упрощают доказывание.
• 🔐 Сослаться на техническую защиту. Обход технических средств защиты авторских прав (ст. 1299 ГК РФ) сам по себе нарушение. Поставка без исходников и СЛК — такие средства.

Помните и о правах клиента. Законный владелец экземпляра программы может без вашего согласия вносить изменения для работы на своём оборудовании и в ограниченных случаях декомпилировать код для совместимости (ст. 1280 ГК РФ). Запретить ему это договором полностью нельзя.

За незаконное использование правообладатель вправе требовать компенсацию — от 10 тыс. до 5 млн руб. по решению суда, либо двукратную стоимость экземпляров или права (ст. 1301 ГК РФ).

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