Можно ли считать SCADA российской, если она зависит от иностранного ПО?

Что находится внутри SCADA

Официально статус отечественного программного обеспечения подтверждается формальными критериями: нахождением в Реестре российского ПО, принадлежностью правообладателя к российской юрисдикции и заявленной поддержкой отечественных операционных систем. Однако если заглянуть под интерфейс оператора, окажется, что SCADA-система представляет собой сложный цепочечный стек технологий. В него входят среды исполнения, библиотеки, базы данных, средства генерации отчётов, сетевые драйверы и компиляторы. Некоторые из этих компонентов созданы за рубежом и не принадлежат самому создателю диспетчерского комплекса.

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

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

• Операционная система: среда исполнения (Windows, Linux или кроссплатформенная сборка). Поддержка Linux может быть как нативной, так и реализованной через слои совместимости.
• Среда исполнения (Runtime): промежуточные платформы вроде .NET Runtime или Java Virtual Machine, без которых запуск исполнительных файлов невозможен.
• Ядро SCADA: ключевой модуль, отвечающий за обработку тегов, логику алармов, обработку событий, архивацию данных и механизмы дублирования (горячего резервирования).
• Коммуникационный уровень: драйверы протоколов связи (Modbus, MQTT, IEC 60870-5-104), а также стек OPC DA и OPC UA.
• Хранение данных: встроенные специализированные архивы реального времени либо внешние системы управления базами данных (например, PostgreSQL или Microsoft SQL Server).
• Визуализация (HMI): графический десктопный клиент для диспетчера, веб-интерфейс или гибридный вариант.
• Сервер тревог (алармов): подсистема фиксации аварийных событий, фильтрации и отправки оповещений.
• Подсистема отчётности: встроенный генератор формализованных отчётов или внешний программный модуль.
• Инструментарий разработки (Toolchain): компиляторы, библиотеки SDK и сторонние зависимости, необходимы для сборки новых релизов.

Если в продукте применяется PostgreSQL, веб-сервер Nginx или открытый релиз .NET, это не делает весь комплекс импортным. При условии, что компоненты можно свободно дистрибутировать, ставить в автономном режиме и подменять при необходимости, такая зависимость является управляемой. Проблемы возникают тогда, когда внешний закрытый компонент нельзя исключить или подменить без полного разрушения архитектуры.

Яркий пример — запуск Windows-приложения в среде Linux с помощью прослойки Wine. Это не прямой порт под Linux, а работа через эмулятор окружения, что влечёт за собой специфические риски: сбои в работе систем печати, графических подсистем и стека OPC DA. Некоторые разработчики честно документируют такие особенности, в то время как другие используют .NET Framework или привязывают веб-клиенты к IIS в Windows и Apache/Nginx в Linux. Сама по себе технология не плоха и не хороша — имеет значение то, насколько разработчик контролирует её поведение.

Все программные зависимости SCADA я делю на три ключевых типа:

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

Иностранный компонент — ещё не иностранная SCADA

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

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

Модели технологической зависимости

Использование сред .NET или Java требует индивидуального разбора. Важно учитывать конкретный вариант исполнения (открытый .NET Core / OpenJDK или проприетарные сборки), условия лицензирования и жесткую привязку к конкретной версии фреймворка. Обычное упоминание .NET в системных требованиях само по себе не означает критическую уязвимость, если используется открытая среда исполнения.

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

На основе этого можно выделить три модели технологической зависимости:

• Российская SCADA с контролируемыми открытыми компонентами: ядро создано внутри страны, внешние модули представляют собой с открытым кодом решения с возможностью локальной сборки.
• Российская SCADA, зависящая от внешней платформы: код системы отечественный, но запуск невозможен без проприетарных иностранных фреймворков или узких закрытых сред.
• Локализованный зарубежный продукт: формальным правообладателем выступает российская структура, но ядро, архитектура и исходный код контролируются зарубежным разработчиком.

С юридической точки зрения все три варианта могут присутствовать в реестрах, однако степень реальной независимости у них кардинально отличается.

Как оценить технологическую зависимость SCADA

При оценке совместимости с Linux важно разделять нативные сборки и запуск через эмуляцию. Одна SCADA может иметь нативный бинарный код, скомпилированный непосредственно под архитектуру Linux и библиотеки glibc. Другая остается нативным Windows-приложением, запускаемым в Astra Linux или Red OS с помощью пакета Wine. Для конечного оператора интерфейс может выглядеть одинаково, но надёжность и глубинные зависимости будут разниться.

Запуск через Wine часто накладывает ограничения на работу с устаревшими стандартами OPC DA, а также на прямую печать отчётов через системные драйверы Windows. Это не аннулирует российский статус системы, но добавляет промежуточный слой, требующий отдельного сопровождения.

Аналогичным образом стоит оценивать .NET, Java, внешние СУБД и специализированные OPC-серверы. Я выделил четыре уровня контроля технологических зависимостей:

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

Сравнение технологических зависимостей российских SCADA

Для наглядности я проанализировал открытые технические данные и документацию нескольких популярных на российском рынке SCADA-систем. Сравнение строится на архитектурных особенностях, способах обеспечения кроссплатформенности и уровне прозрачности документации.

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

Сравнительный анализ показывает, что значительная часть отечественных SCADA-систем пока не имеет полноценной нативной сборки под Linux-дистрибутивы, полагаясь на слои совместимости Wine или инфраструктуру .NET Framework. Разница между продуктами заключается не столько в факте использования сторонних библиотек, сколько в глубине интеграции и количестве критических зависимостей.

При подборе SCADA для критической информационной инфраструктуры (КИИ) недостаточно просто проверить наличие записи в Реестре отечественного ПО. Я рекомендую детально изучать архитектуру и выяснять, насколько вендор способен обеспечивать жизненный цикл продукта в условиях изоляции.

Итог

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

Использование сторонних компонентов с открытым исходным кодом, сторонних СУБД или универсальных сред исполнения не лишает SCADA отечественного статуса. Однако реальный уровень суверенитета определяется тем, сможет ли продукт функционировать и развиваться, если поддержка со стороны внешних экосистем прекратится.

Источник: habr.com