Доверенное связующее ПО: требования к middleware и интеграционным платформам

Материал точно раскрывал техническую специфику связующего ПО и корректно описывал лицензии реальных open source проектов, на которых строится большинство российских интеграционных платформ. Но подкреплял разбор прайс-листом и статистикой, которые нельзя подтвердить. Разбираем требования для middleware по существу.

Главное: для связующего ПО — сервисных шин предприятия (ESB), брокеров сообщений, интеграционных платформ, API-шлюзов — обязательность доверенного статуса наступает 1 января 2027 года, одновременно с серверным ПО и СУБД. Поскольку интеграционная шина обрабатывает данные всех подключённых систем государственного заказчика, требования к безопасности этой категории особенно строгие: проверяется маршрутизация данных, защита транзитных данных по российским криптоалгоритмам, разграничение доступа к интеграционным сценариям и полнота журналирования обмена сообщениями.

Что относится к связующему ПО

Категория охватывает сервисные шины предприятия (ESB) для оркестрации сервисов и централизованной маршрутизации сообщений, брокеры сообщений для асинхронного обмена данными между приложениями, интеграционные платформы и iPaaS-решения для построения интеграционных сценариев, API-шлюзы для управления и защиты программных интерфейсов, платформы оркестрации бизнес-процессов в части интеграционной функциональности, а также адаптеры и коннекторы для подключения унаследованных систем к общему интеграционному контуру. Граница между связующим и прикладным ПО не всегда очевидна, поэтому правильное определение класса продукта до начала процедуры имеет практическое значение для дальнейшей экспертизы.

Почему middleware проверяется особенно тщательно

Интеграционная шина, через которую проходят данные всех подключённых систем, — привлекательная цель для атак и потенциальная точка утечки данных сразу из нескольких систем одновременно, а не одной. Поэтому экспертиза детально проверяет маршрутизацию данных на предмет несанкционированного копирования или перенаправления сообщений (особое внимание — к коннекторам с внешними системами и облачными сервисами), защиту транзитных данных с применением российских криптоалгоритмов по ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012, разграничение прав на создание и редактирование интеграционных маршрутов (несанкционированное добавление маршрута в ESB — критическая уязвимость для всего контура), а также полноту и защищённость журналов передачи данных.

Open source в основе российских платформ

Большинство российских интеграционных платформ и шин данных построены на open source основе: Apache Kafka и Apache ActiveMQ под лицензией Apache License 2.0, RabbitMQ под Mozilla Public License 2.0, платформы на базе WSO2 (community-версия также под Apache License 2.0). Для каждой лицензии — свой набор вопросов при проверке прав на доверенный статус: для продуктов на Apache License важно подтвердить права именно на коммерческую надстройку, российские коннекторы и управляющий интерфейс; для решений на MPL — совместимость этой лицензии с закрытыми расширениями и права на плагины.

Отдельный юридический риск, который часто упускают при беглом анализе, — компоненты под лицензией AGPL (Affero GPL). В отличие от обычной GPL, AGPL распространяет обязательство раскрытия исходного кода не только на распространяемые копии программы, но и на сетевое использование — то есть на сервисы, доступные пользователям через сеть без физической передачи копии. Если продукт включает такой компонент, это может создавать обязательство раскрыть код коммерческой надстройки, что для большинства коммерческих middleware-решений неприемлемо. Такие ситуации требуют отдельной юридической оценки задолго до подачи заявления, а не постфактум.

Совместимость с доверенными ОС: где преимущество, а где сложность

Связующее ПО работает в серверном окружении, поэтому совместимость с двумя доверенными ОС означает подтверждение полноценной функциональности именно на серверных дистрибутивах вроде Astra Linux SE или РЕД ОС Server. Большинство интеграционных платформ на Java или Go изначально кросс-платформенны, и если продукт не использует Windows-специфичных компонентов, адаптация может пройти относительно быстро — основные риски здесь обычно сосредоточены в коннекторах и плагинах, а не в ядре платформы. Сложнее ситуация для Windows-ориентированных решений, использующих COM/DCOM и другие платформенно-зависимые механизмы: замена таких компонентов на кросс-платформенные аналоги и адаптация управляющего интерфейса — работа на месяцы, а не на недели. Дополнительная сложность для полноценного тестирования любого middleware — необходимость воспроизвести реальный интеграционный контур с совместимыми версиями всех подключаемых систем на доверенных ОС, а не проверять сам продукт в изоляции.

Почему график совпадает с СУБД и серверным ПО

Дедлайн для связующего ПО (1 января 2027 года) совпадает с датой для серверного ПО и СУБД не случайно: все три категории технически близки и часто поставляются одними и теми же компаниями в составе комплексных инфраструктурных решений. Практическое следствие — разработчикам middleware стоит закладывать в план подготовки и собственно свою категорию, и возможную загрузку организаций, проводящих оценку соответствия, в этот же период: одновременный наплыв заявок по трём технически близким категориям может увеличить фактические сроки рассмотрения по сравнению с более спокойными периодами.

Начать стоит с консультации: специалисты, которые следят за практикой применения постановления №1937 к серверным категориям, помогут заранее спланировать подготовку с учётом этой конкуренции за внимание экспертов и провести технический аудит лицензионной чистоты open source компонентов до того, как сроки станут критичными.

Источники

• КонсультантПлюс, порядок формирования перечня доверенного ПО: требования постановления №1937 к серверным категориям, включая связующее ПО.
• Реестр российского программного обеспечения, Минцифры России: реестровые записи интеграционных платформ.