Защита конфигурации 1С: как закрыть исходный код
Содержание
Закрыть код своей конфигурации 1С можно несколькими способами, и выбор зависит от того, что именно вы защищаете. Самая надёжная защита исходных текстов — поставка конфигурации без исходных текстов модулей: в этом случае модули попадают клиенту скомпилированными, и прочитать их в Конфигураторе нельзя. Запрет на доработку даёт механизм правил поддержки (тот самый «замочек» на объектах). Отдельные модули можно закрыть паролем, а внешние обработки и отчёты — встроенной защитой при сохранении.
У каждого способа своя цель: один прячет алгоритм, другой запрещает менять структуру, третий просто мешает случайному просмотру. Чаще всего их комбинируют — например, ставят конфигурацию на поддержку с запретом изменений и дополнительно убирают исходные тексты ключевых модулей.
Ниже — когда какой способ выбрать, как закрыть код пошагово, чем способы отличаются и что потом можно, а чего нельзя сделать с закрытой конфигурацией.
Какой способ защиты выбрать под вашу задачу
Защита кода в 1С решает три разные задачи, и путать их не стоит:
- 🔒 Скрыть алгоритм (чтобы конкурент не прочитал вашу бизнес-логику) — убирают исходные тексты модулей из поставки.
- ✋ Запретить доработку (чтобы клиент не ломал типовой функционал и не слетал с обновлений) — ставят конфигурацию на поддержку с правилами изменений.
- 📦 Защитить тиражный продукт (продаёте решение многим клиентам, нужна привязка к ключу) — используют систему лицензирования (СЛК).
Пароль на модуль и защита внешних обработок — это дополнительные, более слабые меры: они отсекают случайный просмотр, но не останавливают того, кто целенаправленно хочет добраться до кода.
Что сделать до того, как закрывать код
Закрытие кода — операция почти необратимая для клиентской копии, поэтому подготовка важнее самих шагов.
Главное правило: оригинальную конфигурацию с исходными текстами всегда держите у себя. Если вы отдадите клиенту единственную копию без исходных текстов, вернуть их будет уже неоткуда — компиляция необратима.
Перед выгрузкой файла поставки убедитесь, что это именно та версия, которую вы готовы «заморозить». После закрытия внести правку в закрытый модуль можно будет только из вашего оригинала, пересобрав поставку заново.
Как закрыть исходные тексты модулей (главный способ)
Это основной способ спрятать алгоритм. Модули уходят клиенту в скомпилированном виде, их нельзя открыть и прочитать в Конфигураторе.
Работа идёт через файлы поставки. Порядок такой:
- Откройте базу в режиме Конфигуратор.
- Зайдите в меню
Конфигурация → Поставка конфигурации → Настройка поставки. - В настройке поставки задайте, для каких объектов не поставлять исходные тексты модулей. Можно закрыть всю конфигурацию целиком или только отдельные объекты с вашей логикой.
- Там же задайте правила изменения объектов (см. следующий раздел) — обычно это делают одновременно.
- Вернитесь в меню
Конфигурация → Поставка конфигурации → Создать файлы поставки и обновления. - Укажите путь и получите файл поставки (
.cf) и, если нужно, файл обновления (.cfu).
Клиент загружает полученный .cf в свою базу. Модули, помеченные как «без исходных текстов», будут работать, но их содержимое в Конфигураторе недоступно — вместо кода пусто.
Файл поставки .cf — это полная конфигурация, его загружают при первой установке. Файл обновления .cfu содержит только изменения относительно предыдущей версии — им выкатывают новые релизы вашего решения клиенту, который уже стоит на поддержке. Для каждой новой версии вы пересобираете поставку из своего оригинала с теми же правилами закрытия.
После загрузки стоит убедиться, что защита сработала: откройте в Конфигураторе один из закрытых модулей. Если текста нет, а объект при этом работает, — всё сделано верно.
Закрывать всю конфигурацию целиком не обязательно. Часто достаточно убрать исходные тексты у нескольких ключевых общих модулей и модулей объектов, где лежит ваша уникальная логика. Остальное можно оставить открытым — так клиенту проще дорабатывать периферию, не трогая защищённое ядро.
Важный нюанс: даже закрытый модуль клиент сможет переопределить через расширение конфигурации , не видя исходного кода. То есть поставка без исходных текстов скрывает алгоритм, но не делает поведение абсолютно неизменным — для этого нужны ещё и правила поддержки.
Запрет изменений через правила поддержки
Когда конфигурация стоит на поддержке, рядом с каждым объектом в дереве метаданных виден «замочек». Он и есть индикатор правил поддержки — того, что клиент может делать с объектом поставщика.
Правила задаются в той же настройке поставки для каждого объекта и имеют несколько уровней:
- Изменения не разрешаются — клиент не может редактировать объект. Самый жёсткий режим.
- Изменения разрешаются — объект можно менять, при этом он остаётся на поддержке (с сохранением возможности обновления).
- Объект можно снять с поддержки — тогда он становится полностью клиентским и больше не обновляется автоматически.
Для защиты от случайных правок типовой логики ставят «изменения не разрешаются» на всё ядро. Клиент при этом может добавлять свои объекты и использовать расширения, но не ломает вашу конфигурацию и спокойно принимает обновления.
Разница между правилами поддержки и закрытием исходных текстов принципиальна. Правила поддержки управляют тем, можно ли менять объект, но не прячут его код: при разрешённых изменениях исходный текст виден. Поставка без исходных текстов, наоборот, прячет код, но сама по себе не запрещает переопределять поведение через расширение. Поэтому для полной защиты эти два механизма применяют вместе.
При обновлении объект, который клиент оставил неизменным и на поддержке, обновляется автоматически. Если же объект был изменён с сохранением поддержки, при накате новой версии платформа предложит сравнить и объединить изменения — здесь клиенту придётся решать конфликты вручную. Объект, снятый с поддержки, обновляться от вас уже не будет.
Если закрыть объект от изменений слишком жёстко, клиент не сможет сделать даже обоснованную доработку и будет вынужден всё решать через расширения. Для гибких решений часть объектов оставляют открытыми для изменения с сохранением поддержки.
Пароль на модуль и защита внешних обработок
Это дополнительные меры для частных случаев — закрыть отдельный модуль или внешний файл.
Пароль на модуль. В Конфигураторе у модуля можно установить пароль на просмотр и редактирование: откройте модуль и задайте пароль через контекстное меню (пункт установки пароля). После этого, чтобы открыть модуль , Конфигуратор потребует пароль.
Защита слабая: пароль хранится вместе с конфигурацией и снимается относительно легко. Используйте его как «замок от честных людей», а не как серьёзную защиту алгоритма. Для настоящей защиты кода пароль на модуль не подходит — поставляйте без исходных текстов.
Защита внешних обработок и отчётов. Внешний файл (.epf — обработка, .erf — отчёт) можно защитить при сохранении из Конфигуратора: его код компилируется, а исходный текст в защищённом файле недоступен. Это удобно, когда вы распространяете отдельную обработку, а не всю конфигурацию. Учтите: защищённую обработку нельзя открыть на редактирование обратно — правки вносят в незащищённый оригинал и каждый раз пересохраняют с защитой. Поэтому, как и с конфигурацией, незащищённую версию держат у себя.
СЛК и тиражная защита. Если вы продаёте решение многим клиентам и хотите привязать его к лицензии, одной поставки без исходных текстов мало. Здесь применяют систему лицензирования и защиты конфигураций (СЛК) или сторонние аналоги: они шифруют модули и привязывают работу решения к аппаратному или программному ключу. Это отдельный продукт со своей настройкой и сервером лицензий — для внутренней доработки одного клиента он избыточен. СЛК имеет смысл, когда без защиты решение легко скопировать и запустить на другом предприятии без оплаты, и когда количество таких установок стоит денег.
Сравнение способов защиты кода
| Способ | Что защищает | Надёжность | Когда применять |
|---|---|---|---|
| Поставка без исходных текстов | Алгоритм модулей | Высокая | Нужно скрыть бизнес-логику от клиента |
| Правила поддержки («замок») | Структуру от правок | Средняя | Чтобы клиент не ломал типовое и не слетал с обновлений |
| Пароль на модуль | Отдельный модуль от просмотра | Низкая | Быстро закрыть один модуль от случайного взгляда |
| Защита внешней обработки | Код .epf / .erf | Средняя | Распространяете отдельную обработку или отчёт |
| СЛК / лицензирование | Тиражный продукт | Высокая | Продаёте решение многим, нужна привязка к ключу |
На практике для продаваемой доработки комбинируют первые два пункта: ставят на поддержку с запретом изменений и убирают исходные тексты ключевых модулей. Для коробочного тиражного продукта добавляют СЛК.
Снятие защиты и работа с закрытым кодом
С закрытой конфигурацией клиент продолжает работать как обычно — закрытие кода не мешает проведению документов, формированию отчётов и повседневной эксплуатации. Ограничения касаются только Конфигуратора.
Что можно с закрытой конфигурацией:
- 🔧 Дорабатывать через расширения. Это штатный и рекомендованный путь: расширение добавляет или переопределяет поведение, не требуя изменения и просмотра закрытых модулей. Расширения работают с платформы 8.3.6.
- 📥 Принимать обновления — если объекты стоят на поддержке, обновление от поставщика накатывается штатно.
Что с закрытой конфигурацией нельзя и как снять защиту законно:
- Прочитать исходные тексты модулей, поставленных без них, из клиентской копии нельзя — их там физически нет. Единственный законный источник — ваш оригинал с текстами, который вы сохранили до закрытия.
- Снять правила поддержки можно легально: владелец базы вправе снять конфигурацию с поддержки (
Конфигурация → Поддержка → Настройка поддержки, затем включить возможность изменения). После этого объекты можно редактировать, но автоматические обновления по ним прекращаются. - Пароль на модуль снимает тот, кто его знает, — через свойства модуля.
Если вам как владельцу своей базы нужно вернуть полный доступ к коду — не ищите способы «взломать» защиту. Запросите у разработчика оригинал конфигурации с исходными текстами или снимите конфигурацию с поддержки штатными средствами. Обход чужой защиты интеллектуальной собственности — это нарушение прав правообладателя.