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

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

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

С чего начать: что именно вы защищаете

Пока не решили, от чего защищаетесь, деньги уйдут впустую. Угрозы разные, и средства под них разные.

• 🔓 Клиент правит ваш код — ломает обновления, потом требует бесплатной поддержки.
• 📋 Клиент передаёт решение третьим лицам — коллегам, другой фирме, на форум.
• 🏃 Уходит разработчик и уносит исходники в личный архив.
• 🔍 Конкурент разбирает алгоритм — например, сложный расчёт или обмен.

Выпишите, какая из угроз для вас реальна, и оцените цену потери. Если алгоритм стоит три дня работы, не ставьте на него защиту ценой в месяц.

Закрытие исходного кода в поставке

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

Поставка конфигурации и расширения

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

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

Режим поддержки

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

Что получится на практике

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

Обфускация: когда она нужна и что даёт

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

Что делает обфускатор:

1. Заменяет понятные имена вроде РассчитатьСкидку на п1а7.
2. Убирает комментарии и форматирование.
3. Иногда разбивает строки и условия на вставки, которые тяжело читать.

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

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

Привязка к лицензии, ключу и клиенту

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

Серийный ключ и срок действия

Самый дешёвый способ. Вы выдаёте клиенту ключ, привязанный к ИНН или названию организации, а решение проверяет его при старте. Срок действия закладывайте сразу: продление лицензии станет регулярным событием, а не разовой продажей.

Ключ лучше проверять не одной функцией, а в нескольких местах. Одна проверка отключается правкой одной строки, а их шесть найти труднее.

Привязка к параметрам среды

Можно сверять имя информационной базы, идентификатор, часть настроек сервера. Минус: клиент обновил сервер, перенёс базу — решение «слетело». Закладывайте процедуру переактивации и не вешайте всё на одну характеристику.

Аппаратные ключи

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

Решение «по подписке»

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

Права на разработку: договор и закон

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

Кому принадлежит код

Программа для ЭВМ охраняется как произведение, и права на неё возникают с момента создания. Регистрация в Роспатенте необязательна, но помогает: свидетельство — готовое доказательство авторства в споре.

С сотрудниками и подрядчиками важна разница:

• 👤 Штатный программист, который писал код по трудовым обязанностям, — права по общему правилу у работодателя. Это стоит прописать и в договоре.
• 🧑‍💻 Подрядчик или фрилансер — по умолчанию права могут остаться у него, пока вы не заключили договор об отчуждении или лицензионный договор. Без него вы заказали код, но не получили права на него.

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

1. Вы передаёте неисключительную лицензию, а не продаёте программу.
2. Запрет на передачу третьим лицам, копирование и декомпиляцию.
3. Запрет на изменение кода, кроме случаев, когда это согласовано.
4. Срок и территория лицензии.
5. Что происходит при нарушении: штраф, отключение, расторжение.

Коммерческая тайна

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

Контроль версий и права в команде

Самые болезненные утечки идут изнутри. Закройте их дёшево.

Хранилище конфигурации и система контроля версий

Работайте только через хранилище или Git: каждое изменение имеет автора и дату. Это одновременно и защита, и порядок. Прямая правка «боевой» базы разработчиком — запрещена.

Разграничение доступа

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

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

Как заметить утечку и что делать дальше

Даже при хорошей защите стоит наблюдать за тем, что происходит с вашим решением.

Признаки того, что решение гуляет по рукам

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

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

Порядок реагирования

1. Зафиксируйте нарушение: скриншоты, нотариальный осмотр страницы, выгрузка записей проверки.
2. Сравните найденную копию со своим исходником, чтобы подтвердить авторство.
3. Отправьте претензию с требованием удалить копию и прекратить использование.
4. Если не помогло, обращайтесь к юристу: возможны блокировка ресурса, иск о защите исключительных прав и взыскание компенсации.

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

Если не помогло: запасные варианты

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

• 🔄 Выпустите обновление, которое ломает чужую копию. Новая версия проверяет ключ строже, а старые копии перестают получать исправления.
• 🧩 Вынесите ценное на сервер. Расчёт, который нельзя отдавать, переезжает в веб-сервис, а у клиента остаётся тонкая оболочка.
• 📝 Пересмотрите договоры. Добавьте штрафы за передачу решения и право проверки лицензионной чистоты.
• 📉 Не тратьте силы на мелкие нарушения. Если копией пользуется одна небольшая фирма, переговоры обычно дешевле суда.

Оценивайте ущерб трезво: иногда «утёкшее» решение приводит вам клиентов, которые потом покупают поддержку и доработки.

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