Вопрос защиты интеллектуальной собственности в среде «1С:Предприятие» всегда стоит остро. Разработчик вкладывает сотни часов в создание уникального алгоритма, сложного отчета или расширения, которое автоматизирует специфические бизнес-процессы. Однако стандартная поставка в виде файла расширения .cfe или обработки .epf позволяет легко скопировать продукт на неограниченное количество информационных баз. Рассмотрим, какие методы защиты существуют, разберем их техническую реализацию и проанализируем эффективность каждого подхода.
Проанализируем самый доступный способ — программную проверку окружения, в котором запущена доработка. Суть метода заключается в том, чтобы разрешить выполнение кода только в конкретной базе или организации. В качестве идентификаторов обычно выбирают ИНН организации, GUID информационной базы или путь к базе (для файловых вариантов).
Разберем реализацию проверки ИНН. Мы можем зашить в код список разрешенных ИНН и проверять их при старте. Посмотрим на пример кода, который можно разместить в модуле объекта или в обработчике события ПриУстановкеПараметровСеанса:
Функция ПроверитьЛицензию() Экспорт
РазрешенныеИНН = "7701234567, 5001098765"; // Список ИНН через запятую
// Получаем ИНН основной организации из констант или параметров учета
ТекущийИНН = СокрЛП(Константы.ИННВашейОрганизации.Получить());
Если Найти(РазрешенныеИНН, ТекущийИНН) = 0 Тогда
ВызватьИсключение "Лицензия не найдена! Данная доработка не предназначена для использования в организации с ИНН " + ТекущийИНН;
КонецЕсли;
КонецФункции
Этот метод прост, но имеет существенный недостаток: если модуль не закрыт паролем, любой программист может закомментировать это условие. Поэтому данный метод всегда должен сочетаться с закрытием модулей.
Рассмотрим более продвинутый подход, упомянутый участниками форума. Вместо того чтобы хранить всю логику внутри 1С, мы можем вынести часть алгоритмов или хотя бы механизм проверки лицензии на удаленный веб-сервер. Выясним причину популярности этого метода: он позволяет гибко управлять доступом, отключая его удаленно при окончании подписки.
Проанализируем схему работы:
HTTPЗапрос на ваш сервер.Давайте посмотрим, как может выглядеть отправка такого запроса:
Соединение = Новый HTTPСоединение("api.vash-server.ru", 443,,,,, Новый ЗащищенноеСоединениеOpenSSL());
Запрос = Новый HTTPЗапрос("/v1/check_license?inn=" + ТекущийИНН + "&db_id=" + Строка(СтрокаСоединенияИнформационнойБазы()));
Ответ = Соединение.Получить(Запрос);
Если Ответ.КодСостояния <> 200 Тогда
ОтказВРаботе();
КонецЕсли;
Самым эффективным вариантом здесь является передача макетов СКД или настроек с сервера. Если клиент не авторизован, отчет просто не получит структуру (макет), и формировать будет нечего.
Если ваша разработка претендует на статус тиражного программного продукта, стоит рассмотреть использование 1С:СЛК (Система Лицензирования Конфигураций). Это индустриальный стандарт, разработанный компанией «1С» совместно с «Катран Софт».
Разберем принципы работы СЛК:
Этот метод требует финансовых вложений в покупку комплектов разработчика СЛК, но обеспечивает максимально возможный уровень защиты для платформы 1С.
Выясним, что делать, если вы не хотите использовать внешние серверы, но боитесь, что ваш закрытый паролем модуль вскроют (существуют специальные утилиты для обхода паролей модулей 1С). В этом случае на помощь приходит обфускация.
Проанализируем процесс: специальная программа-обфускатор берет ваш исходный код и заменяет понятные имена переменных и функций на бессмысленные наборы символов. Рассмотрим пример преобразования:
Исходный код:
Если СуммаДокумента > ПорогСкидки Тогда
РассчитатьСкидку(СуммаДокумента);
КонецЕсли;
После обфускации:
Если а1 > а2 Тогда
_l1l(а1);
КонецЕсли;
Код остается полностью работоспособным для платформы, но становится абсолютно нечитаемым для человека. Даже если злоумышленник снимет пароль с модуля, разобраться в логике и адаптировать её под свои нужды будет крайне трудозатратно.
Рассмотрим наиболее технически сложный, но надежный метод — написание части функционала на языках низкого уровня (C++, Rust, Go) и подключение их через механизм ВнешниеКомпоненты.
Посмотрим на преимущества этого подхода:
Мало кто знает, что на уровне платформы заложена возможность защиты расширений. Как упоминалось в обсуждении, расширения можно защищать ключами, подобно основным конфигурациям. Однако этот функционал требует настройки системы лицензирования на стороне сервера предприятия. Это позволяет сделать расширение неработоспособным, если в системе отсутствует соответствующая лицензия на программный продукт.
Подводя итог нашему анализу, можно сделать вывод: абсолютной защиты не существует (даже саму платформу 1С иногда взламывают), но можно сделать взлом экономически нецелесообразным. Разберем оптимальную стратегию защиты для разных уровней:
Также важно помнить о юридической стороне вопроса. Регистрация программы в Роспатенте и наличие грамотного лицензионного соглашения (EULA) помогут защитить ваши права в суде, если технические средства защиты все же будут преодолены.