Администрирование · 12 мин
Какие компоненты типовой поставки 1С:Предприятие 8 защищены
Какие компоненты типовой поставки 1С:Предприятие 8 защищены: платформа, лицензии, закрытые модули конфигураций. Как проверить защиту и не нарушить её при доработке.
Типовая поставка «1С:Предприятие 8» — это не один файл, а набор компонентов с разным уровнем защиты. Часть защищена технически: аппаратными ключами, программными лицензиями, закрытым исходным кодом. Часть — только юридически, условиями лицензионного договора. Понимание того, где проходит граница, важно и администратору, и разработчику: попытка доработать защищённый фрагмент либо невозможна технически, либо приводит к потере поддержки и юридическим рискам.
В этой статье разобраны основные защищённые компоненты: ядро платформы, система лицензирования, закрытые модули конфигураций, механизм поставки без исходного кода, средства защиты от копирования информационной базы. Для каждого компонента указано, как именно он защищён, что можно и что нельзя делать, а также как проверить состояние защиты в конкретной системе.
Ядро платформы: закрытый код и лицензионная защита
Платформа «1С:Предприятие 8» (исполняемые файлы технологической платформы — толстый, тонкий и веб-клиент, сервер 1С) распространяется только в скомпилированном виде. Исходный код ядра не поставляется ни партнёрам, ни крупным заказчикам. Это базовый уровень защиты: изменить поведение платформы «изнутри» нельзя, можно лишь использовать документированные механизмы расширения.
Второй уровень — лицензионная защита платформы. Запуск клиентских приложений и сервера контролируется лицензиями двух видов: аппаратными ключами HASP (USB-ключи на платформу и на клиентские подключения) и программными лицензиями, привязанными к аппаратным параметрам компьютера. Без действующей лицензии платформа запустится только в ограниченном режиме или откажется работать с сообщением «Не найдена лицензия».
Программная лицензия привязывается к ключевым параметрам оборудования: материнской плате, процессору, дискам, объёму памяти, сетевым адаптерам. Замена одного-двух компонентов обычно не нарушает лицензию, но существенное изменение конфигурации (например, перенос на другой сервер или замена материнской платы) делает лицензию недействительной, и её приходится активировать заново резервным пин-кодом.
Как проверить, какие лицензии использует система
Проверка выполняется штатными средствами и не требует вмешательства в систему. На клиентском компьютере список полученных лицензий виден через диалог «О программе» в любом клиенте 1С — там отображается, какая лицензия выдана: аппаратная или программная, локальная или с сервера. На сервере 1С:Предприятия выданные лицензии видны в консоли администрирования кластера.
- 1Откройте клиент 1С и вызовите «Сервис → О программе» (или меню «Файл → О программе») — посмотрите тип и источник лицензии.
- 2На сервере откройте консоль кластера 1С и проверьте раздел лицензий: сколько выдано и какого типа.
- 3Найдите файлы программных лицензий (*.lic) в служебных каталогах платформы и убедитесь, что они включены в резервное копирование.
- 4Сверьте количество доступных лицензий с числом одновременно работающих пользователей — зафиксируйте запас.
Признак нормы: лицензии выдаются стабильно, их количество соответствует закупленным, файлы лицензий присутствуют и копируются. Тревожные признаки: периодические ошибки «не найдена лицензия» при свободных лицензиях (часто это проблема сетевой видимости ключа HASP или службы HASP License Manager), исчезновение программной лицензии после обновления оборудования или переноса виртуальной машины.
Закрытые модули конфигурации: поставка без исходного кода
На уровне конфигурации фирма «1С» и партнёры-разработчики могут поставлять отдельные модули без исходного текста. Такой модуль содержит только скомпилированный байт-код: он исполняется платформой, но его текст в конфигураторе не отображается. В типовых решениях этим способом защищаются, как правило, лицензируемые подсистемы, механизмы проверки легальности, отдельные алгоритмы, составляющие ноу-хау разработчика.
Отличить закрытый модуль просто: в конфигураторе при попытке открыть его текст выводится сообщение, что модуль поставляется без исходного кода. В дереве метаданных такой модуль выглядит обычно — защита касается именно текста, а не наличия объекта. Вызовы процедур и функций закрытого модуля из другого кода работают штатно, если соответствующие методы экспортные.
Практическое следствие: доработать закрытый модуль нельзя никакими штатными средствами. Если требуется изменить его поведение, доступны только обходные пути: расширение конфигурации с переопределением вызывающего кода, подмена логики в открытых модулях, которые обращаются к закрытому, либо обращение к поставщику за изменением функциональности. Любые попытки декомпилировать байт-код — это нарушение лицензионного соглашения и, в ряде юрисдикций, закона.
Режим поддержки и защита от изменения типовых объектов
Третий уровень защиты — не технический, а организационный: режим поддержки конфигурации. Типовая конфигурация по умолчанию находится на полной поддержке поставщика: объекты заблокированы для изменения, и конфигуратор не даст их редактировать, пока режим поддержки не будет изменён. Это защищает типовой код от случайных правок и гарантирует возможность автоматического обновления.
Снятие объекта с поддержки (или перевод в режим «изменения через расширение») — осознанное действие администратора. Последствия нужно понимать заранее: объект, снятый с поддержки, перестаёт обновляться автоматически, и при каждом обновлении его изменения придётся сопоставлять с типовой версией вручную. Массовое снятие с поддержки превращает обновление в трудоёмкую операцию на часы вместо штатных минут.
Современная альтернатива — механизм расширений конфигурации. Расширение позволяет изменять формы, модули и ряд других объектов, не трогая типовой код: конфигурация остаётся на полной поддержке и обновляется автоматически, а доработки живут отдельным слоем. Для большинства прикладных задач (дополнительные проверки, печатные формы, отчёты, изменение логики документов) расширение — предпочтительный путь.
Способы доработки типовой конфигурации
Подходит для большинства доработок: типовая поддержка сохраняется, обновления автоматические. Ограничение: не все объекты и не все изменения доступны в расширениях.
Полная свобода правок, но объект снимается с поддержки, обновление становится ручным. Оправдано только при невозможности решить задачу расширением.
Не затрагивают конфигурацию вообще. Подходят для печатных форм, отчётов, разовых обработок данных. Не меняют поведение типовых объектов.
Защита данных и доступа внутри информационной базы
Отдельный блок защиты относится не к коду, а к данным. Пароли пользователей хранятся в информационной базе в виде хэшей — восстановить исходный пароль из базы нельзя, можно только задать новый. Разграничение прав реализовано через роли и механизм RLS (ограничение доступа на уровне записей), который работает на уровне платформы и не может быть обойдён из встроенного языка.
В файловом варианте база защищена слабее: файл 1Cv8.1CD физически доступен любому, кто имеет доступ к каталогу, и шифрование содержимого платформой не выполняется. Защита здесь обеспечивается правами файловой системы и, при необходимости, шифрованием диска. В клиент-серверном варианте прямой доступ к данным ограничивается средствами СУБД, а платформа добавляет собственный контроль ролей.
Как проверить состояние защиты
Конфигурация на полной поддержке или изменения вынесены в расширения
Массово снятые с поддержки объекты без документированной причины
Лицензии выдаются стабильно, файлы *.lic в резервной копии
Ошибки «не найдена лицензия», отсутствие копий файлов лицензий
Состав закрытых модулей известен, обходная логика задокументирована
Доработки ссылаются на закрытые модули без учёта смены сигнатур при обновлении
Пароли задаются через конфигуратор или предприятие, хранятся как хэши
Пароли где-то записаны «на всякий случай» открытым текстом
Что в типовой поставке не защищено технически
Большая часть кода типовых конфигураций — общие модули, модули объектов, формы — поставляется с исходным текстом. Она не защищена технически: код можно читать, копировать и изменять (после изменения режима поддержки). Защита здесь только юридическая: конфигурация является объектом авторских прав, и её распространение за пределами лицензионных условий запрещено, хотя технических препятствий для копирования нет.
Также открыты: макеты, схемы компоновки данных, запросы, роли, интерфейсные настройки. Это сознательное решение вендора: открытость прикладного кода — основа экосистемы доработок 1С. Закрывается лишь то, что связано с лицензированием, защитой от подделки и ключевым ноу-хау.
Маршрут действий при необходимости доработки
Порядок выбора способа доработки зависит от того, что именно нужно изменить. Сначала проверяется, доступен ли объект в исходном коде. Если да — оценивается, решается ли задача расширением. Если объект закрыт (модуль без исходного кода), остаются только обходные механизмы или обращение к поставщику.
Как выбрать действие
FAQ
Можно ли посмотреть текст закрытого модуля типовой конфигурации?
Нет. Модуль, поставляемый без исходного кода, содержит только скомпилированный байт-код, и конфигуратор его текст не показывает. Декомпиляция сторонними средствами нарушает лицензионное соглашение. Если нужно понять логику, используйте документацию поставщика или отладку на уровне вызовов.
Что произойдёт с программной лицензией при замене жёсткого диска?
Замена одного компонента обычно не нарушает привязку — лицензия проверяет совокупность ключевых параметров оборудования. Но при замене нескольких компонентов или материнской платы лицензия может стать недействительной, и потребуется повторная активация резервным пин-кодом.
Почему после обновления перестала работать доработка вокруг закрытого модуля?
При обновлении закрытый модуль заменяется новой версией, и сигнатуры его экспортных процедур могут измениться. Ваш код в расширении или открытых модулях продолжает вызывать старые методы. Проверьте вызовы по журналу ошибок и скорректируйте их под новые сигнатуры.
Нарушается ли защита, если снять объект с поддержки?
Нет, это штатная операция, предусмотренная платформой. Последствия другие: объект перестаёт обновляться автоматически, и ответственность за сопоставление изменений при обновлениях переходит к вам. Само по себе снятие с поддержки лицензию не нарушает.
Защищён ли файл базы 1Cv8.1CD от копирования?
Технически — нет: платформа не шифрует файл базы. Защита обеспечивается правами доступа файловой системы и, при необходимости, шифрованием диска. Если данные критичны, рассмотрите клиент-серверный вариант с разграничением доступа на уровне СУБД.
Как узнать, какие модули в конфигурации закрыты?
В конфигураторе откройте дерево конфигурации и попробуйте открыть текст модуля: для закрытого модуля появится сообщение об отсутствии исходного кода. Для массовой проверки используйте выгрузку конфигурации в файлы — закрытые модули выгружаются без текста.
Что важно запомнить
В типовой поставке 1С защищены ядро платформы (закрытый код и лицензии HASP/программные), закрытые модули конфигураций и ключевые данные доступа. Прикладной код в основном открыт: дорабатывайте через расширения, сохраняйте поддержку и резервные копии лицензий — это снимет большинство рисков.