Связующее программное обеспечение — один из самых незаметных для конечного пользователя, но критически важных слоёв современной IT-инфраструктуры. Шины данных, брокеры сообщений, интеграционные платформы и ESB-решения работают в фоне, обеспечивая взаимодействие между десятками систем государственного заказчика. Именно поэтому требования к доверенному статусу для этой категории особенно важны: ненадёжное или скомпрометированное связующее ПО открывает доступ сразу ко всем подключённым системам. Дедлайн для категории — 1 января 2027 года, и он совпадает с серверным ПО и СУБД. Это означает, что разработчики middleware работают в том же временном окне, что и производители баз данных — конкуренция за внимание центров тестирования и экспертов в этот период будет высокой.
Что относится к связующему ПО по классификатору Минцифры
Категория связующего ПО охватывает программные продукты, обеспечивающие интеграцию и взаимодействие между различными информационными системами. Это не самый простой класс для классификации — граница между связующим и прикладным ПО иногда размыта, и правильное определение класса продукта до начала процедуры имеет практическое значение.
🚌 Сервисные шины предприятия (ESB)
Платформы для оркестрации сервисов и централизованной маршрутизации сообщений между информационными системами. Используются как основа интеграционного контура государственных структур.
📨 Брокеры сообщений
Системы асинхронного обмена сообщениями между приложениями. Российские аналоги Kafka и RabbitMQ в коммерческом исполнении, ориентированные на государственный сегмент.
🔄 Интеграционные платформы и iPaaS
Платформы для построения интеграционных сценариев между корпоративными системами. Управление API, трансформация данных, маршрутизация потоков.
🌐 API-шлюзы и платформы управления API
Решения для управления, мониторинга и защиты программных интерфейсов. Контроль доступа к API государственных информационных систем.
⚙️ Платформы оркестрации бизнес-процессов
BPM-системы в части интеграционной функциональности, платформы для автоматизации рабочих процессов между несколькими системами.
🔗 Адаптеры и коннекторы
Специализированные программные компоненты для подключения унаследованных и специфических систем к интеграционному контуру. Часто поставляются как самостоятельные программные продукты.
Почему связующее ПО проверяется особенно тщательно
Архитектурная роль middleware в государственной IT-инфраструктуре делает требования к безопасности этой категории принципиально строгими. Интеграционная шина, через которую проходят данные всех подключённых систем, является привлекательной целью для атак и точкой потенциальной утечки данных. Центр тестирования работает с этим пониманием.
🔀
Контроль потоков данных
Для интеграционных платформ детально проверяется маршрутизация данных: нет ли несанкционированного копирования, перехвата или перенаправления сообщений. Особое внимание — к коннекторам с внешними системами и облачными сервисами.
🔐
Безопасность транзитных данных
Данные, проходящие через шину, должны быть защищены в транзите. Проверяется применение российских криптоалгоритмов по ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012 при шифровании канала передачи и подписи сообщений.
🎛️
Разграничение доступа к интеграционным сценариям
Платформа должна обеспечивать чёткое разграничение прав на создание, редактирование и выполнение интеграционных маршрутов. Несанкционированное добавление маршрута в ESB — критическая уязвимость для всего интеграционного контура.
📋
Журналирование и аудит сообщений
Полнота и защищённость журналов передачи данных. Возможность восстановить хронологию обмена сообщениями и выявить аномалии. Для государственных информационных систем требования к аудиту особенно строгие.
Специфика open source ядра в middleware
Большинство российских интеграционных платформ и шин данных построены на open source основе. Apache Kafka, RabbitMQ, MuleSoft Community Edition, WSO2 — популярные базы для коммерческих российских решений. Это создаёт те же вопросы по правам и лицензиям, что и для СУБД, но с дополнительной спецификой.
Open source основа Лицензия Ключевые вопросы для доверенного статуса Apache Kafka Apache License 2.0 Права на коммерческую надстройку, российские коннекторы, управляющий интерфейс RabbitMQ Mozilla Public License 2.0 Совместимость MPL с закрытыми расширениями, права на плагины и управляющий слой Apache ActiveMQ Apache License 2.0 Права на коммерческие модули, история создания адаптеров WSO2 платформы Apache License 2.0 (Community) Разграничение Community и Enterprise версий, права на российские доработки
Важный нюанс для middleware на open source ядре: если продукт включает компоненты под лицензией AGPL (Affero GPL), это может создавать обязательства по раскрытию кода коммерческой надстройки. Такие ситуации требуют отдельной юридической оценки до подачи заявления.
Совместимость с доверенными ОС для middleware
Связующее ПО работает в серверном окружении, поэтому требование совместимости с двумя доверенными ОС означает подтверждение полноценной функциональности именно на серверных дистрибутивах. По нашей практике у middleware-продуктов здесь есть как преимущества, так и специфические сложности.
Преимущество: большинство интеграционных платформ на Java или Go изначально кросс-платформенны. Если продукт не использует Windows-специфичных компонентов, адаптация к Astra Linux SE или РЕД ОС Server может быть относительно быстрой. Сложность: коннекторы к конкретным внешним системам нередко разработаны с Windows-зависимостями. Для полноценного тестирования нужна среда, воспроизводящая реальный интеграционный контур, — а это требует наличия совместимых версий всех подключаемых систем на доверенных ОС.
Java/Go middleware vs Windows-нативные решения
Кросс-платформенный стек
- Запуск на доверенных ОС без глубокой переработки
- Основные риски — в коннекторах и плагинах
- Документация и тестирование — главный объём работ
- Подготовка: 1–2 месяца при хорошей базе
Windows-ориентированная платформа
- Переработка слоя взаимодействия с ОС
- Замена COM/DCOM на кросс-платформенные аналоги
- Адаптация управляющего интерфейса
- Подготовка: 3–6 месяцев и более
Как мы сопровождаем получение доверенного статуса для связующего ПО
1
Технический аудит архитектуры и потоков данных
Анализируем архитектуру платформы с точки зрения требований информационной безопасности: механизмы маршрутизации, разграничение доступа, защита транзитных данных, журналирование. Проверяем кросс-платформенность ядра и зависимости коннекторов. Отдельно — анализ лицензионной чистоты open source компонентов. Срок: 7–12 рабочих дней.
2
Юридический анализ прав
Для middleware с open source ядром — детальный анализ лицензий всех компонентов и прав на коммерческую надстройку. Проверяем договоры с разработчиками коннекторов и адаптеров. Для компаний с историей слияний и поглощений — цепочка передачи прав при реорганизациях.
3
Тестирование совместимости с доверенными ОС
Проверяем полноценную функциональность платформы на серверных доверенных ОС. Для ESB и интеграционных платформ это включает тестирование передачи сообщений, трансформации данных и работы коннекторов в Linux-среде. Фиксируем несовместимости и передаём список в команду разработки.
4
Подготовка документации и сопровождение подачи
Готовим полный пакет: архитектурная документация, модель угроз, описание механизмов защиты данных, тестовые сценарии. Подаём заявление в Минцифры, параллельно ведём переговоры с центром тестирования для минимизации разрыва между этапами.
5
Сопровождение экспертизы и получение отметки
Координируем взаимодействие с аккредитованным центром тестирования, оперативно закрываем запросы экспертов. После положительного заключения сопровождаем направление в правительственную комиссию по цифровому развитию до получения отметки в реестровой записи ФГИС.
Стоимость и сроки для связующего ПО
Статья расходов Стоимость Срок Технический и юридический аудит от 60 000 ₽ 7–12 рабочих дней Сопровождение под ключ от 190 000 ₽ весь проект Экспертиза центра тестирования от 450 000 до 750 000 ₽ до 30 рабочих дней Доработка совместимости с ОС индивидуально 1–6 месяцев в зависимости от стека Полный бюджет без доработки от 640 000 до 940 000 ₽ 4–6 месяцев
Вопросы разработчиков связующего ПО
Наша платформа построена на Apache Kafka. Права на коммерческую надстройку у нас — достаточно ли этого?
Права на коммерческую надстройку — необходимое, но не всегда достаточное условие. Нужно убедиться, что права на все компоненты надстройки оформлены корректно: договоры с разработчиками коннекторов, история создания управляющего интерфейса, права на документацию и конфигурационные схемы. Apache License 2.0 для ядра Kafka не создаёт проблем с закрытой надстройкой, но сама надстройка должна быть юридически чистой.
Наша шина данных используется для передачи медицинских данных между МИС. Есть ли дополнительные требования?
Да. Для middleware, работающего с медицинскими данными в контуре ЕГИСЗ, требования информационной безопасности включают соответствие приказу Минздрава об информационной безопасности медицинских информационных систем. Это не отдельная от доверенного статуса процедура, но при экспертизе центр тестирования будет оценивать защиту медицинских данных в транзите. Применение ГОСТ-шифрования для медицинских данных — фактически обязательное условие.
Платформа работает в контейнерах Kubernetes. Как тестировать совместимость с доверенными ОС в этом контексте?
Kubernetes-оркестрация не снимает требование к доверенной хостовой ОС. Для тестирования нужно развернуть кластер на серверах под управлением доверенной ОС — например, Astra Linux SE в серверной конфигурации. Если платформа использует специфические возможности ядра Linux, которые могут различаться между дистрибутивами, это нужно проверить заранее. Контейнеризация обычно упрощает перенос, но не гарантирует его автоматически.
Мы продаём коннекторы к нашей платформе как отдельные программные продукты. Нужен ли доверенный статус на каждый коннектор отдельно?
Если коннекторы имеют отдельные реестровые записи в реестре российского ПО и продаются как самостоятельные продукты — да, каждый из них проходит процедуру отдельно. Если коннекторы входят в состав основной платформы и не имеют отдельных записей — они проверяются в рамках экспертизы основного продукта. Это принципиально влияет на бюджет и сроки, и определять стратегию нужно до начала процедуры.
Дедлайн 1 января 2027 года совпадает с СУБД и серверным ПО. Не будет ли очереди в центрах тестирования?
Это обоснованное опасение. Три категории с одним дедлайном — это концентрированный спрос на экспертизу в центрах тестирования во второй половине 2026 года. По аналогии с тем, как работают очереди в любых регуляторных процедурах, компании, подавшие заявления раньше, получат экспертизу в менее загруженный период. Ждать до осени 2026 года — значит рисковать попасть в пиковую нагрузку с непредсказуемыми сроками ожидания.
Связующее ПО в контексте СМЭВ и государственной интеграции
Система межведомственного электронного взаимодействия (СМЭВ) является основным интеграционным контуром для государственных информационных систем России. Продукты, работающие как адаптеры или коннекторы для СМЭВ, находятся в особо чувствительной архитектурной позиции. Для таких решений доверенный статус — не просто конкурентное преимущество, а вопрос доверия со стороны государственных заказчиков, которые принимают решения о доступе к межведомственным данным.
1 янв. 2027 — дедлайн для связующего ПО 4–6 мес. реальный срок процедуры от 450 000 ₽ стоимость экспертизы middleware 95% успешных включений с первого раза
Обсудить получение доверенного статуса для вашей платформы
Расскажите о продукте: тип платформы, open source основа, ключевые коннекторы, текущий статус в реестре. Проведём аудит и составим план с учётом дедлайна января 2027 года.
Телефон / WhatsApp / Telegram: +7 920-898-17-18
Email: reestrgarant@mail.ru
Первичная консультация бесплатная в рабочее время.
Оригинальная статья
Полная версия статьи на нашем сайте: https://vnesenie-v-reestr.ru/news/doverennoe-svyazuyuschee-po-middleware-i-integratsionnye-platformy-s-doverennym-statusom
Мы занимаемся включением в реестр Минпромторга
📞 Телефон: +7 920-898-17-18
✉️ Email: reestrgarant@mail.ru