Шина для Росатома: собрали ядро из опенсорса и прошли сертификацию ФСТЭК

Возможно, вы слышали много историй про то, как для какой-то крупной компании разрабатывается система, которая потом становится просто неприменимой примерно нигде, включая изначальную компанию.

Мы Гринатом — условно говоря, ИТ-интегратор Росатома, но не только. Наш основной заказчик ставит задачу на отраслевые решения. То есть по факту мы делаем решения для Росатома, но при этом учитываем, что другим российским компаниям они тоже нужны. И в этом месте случается самое интересное: эти решения должны быть конкурентными, применимыми за пределами контура заказчика и вообще работать.

В 2022 году у всех стала «болеть» шина. На самом деле наша история началась в 2017-м, но к 2020 году у нас уже был проект, который можно было доделать до отраслевого решения. А когда доделали — решили вывести его на коммерческий рынок, чтобы шину как продукт могла купить любая российская компания, которой это нужно.

Но у нас в задаче она должна иметь 4-й уровень доверия ФСТЭК и входить в реестр российского ПО.

В общем, мы взяли опенсорсное ядро Apache NiFi под лицензией Apache 2.0, выделили ядро и коннекторы, провели многоступенчатый аудит кода, модифицировали его под локальные требования и засертифицировали во ФСТЭК свой форк, а потом к этой стабилизированной версии дописали всё остальное, что нужно. К слову, лицензия Apache 2.0 позволяет сильно перерабатывать исходный код и распространять результат коммерчески как самостоятельное произведение. Ничего сверхоригинального, но это много довольно тяжёлой работы. Про неё и расскажу подробнее под катом.

Суть задачи

Дано: куча объектов инфраструктуры, связанных напрямую по принципу точка-точка. Это создавало кучу проблем архитектурного уровня, например, если надо было внести какое-то изменение, то нужно было идти в код каждой интеграции и менять все связанные объекты. В 2022 году ещё очень остро встал вопрос ИБ, поэтому пришлось пересмотреть подходы. При интеграциях точка-точка доступы хранятся во всех элементах инфраструктуры, и достаточно выбрать одну самую слабую часть, чтобы получить доступы к ближайшим интегрированным объектам.

Нужна шина, и это понятно.

Требования стандартные:

• Не брокер, а именно шина.
• Lowcode + встроенные преобразования форматов.
• Коннекторы (адаптеры) для стандартных протоколов «из коробки».
• Гарантированная доставка сообщений.
• Отказоустойчивость при выходе нод из строя (+ геораспределённость).
• Масштабируемость.

Чуть более официальные требования:

Технические характеристики

Пользовательское ПО является тонким клиентом и поддерживает работы в следующих средах:

• Операционные системы семейства Microsoft Windows, Linux (Unix), MacOS и др., поддерживающие работу веб-браузеров.
• Веб-браузер Mozilla Firefox версии не ниже 70.0, Google Chrome версии не ниже 50.0 или Safari.

Серверная часть может исполняться в следующих ОС:

• ОС СН Astra Linux Special Edition версии 1.6 «Смоленск».
• CentOS версии 8.3.
• РЕД ОС версии 7.2 «Муром».

Функциональные возможности

• Устойчивость к потерям сообщений.
• Гибкое управление приоритизацией обработки сообщений.
• Трансформация передаваемых данных.
• Интуитивно понятный интерфейс, позволяющий просто создавать новые интеграционные потоки.
• Внесение изменений в потоки во время выполнения.

Получилась платформа для объединения информационных систем в единое пространство, где есть:

• Масштабируемость и отказоустойчивость с использованием модели кластеризации.
• Поддержка расширений — возможность создания собственных процессоров на языке Java.
• Использование SSL, SSH, HTTPS.
• Поддержка большинства стандартных протоколов взаимодействия: JMS, HTTP, HTTPS, REST, FTP, FTPS, SFTP, SMTP, POP3, IMAP, JDBC.
• Синхронный и асинхронный обмен сообщениями.
• Гибкая ролевая система.

Продукт позволяет интегрировать системы между собой без их доработок. Атом.Мост является связующим звеном для передачи сообщения от одной информационной системы к другой.

В рамках платформы поддерживается взаимодействие по всем стандартным коммуникационным протоколам и ряду специализированных — СМЭВ, SAP RFC, SAP XI.

Задача как таковая встала ещё в 2017 году. Архитекторы заявили, что пора импортозамещаться с SAP PI. На рынке не было готового решения, поэтому предложили допилить напильником несколько кубиков из опенсорса. Точнее, поскольку тогда не было особых стимулов переезжать с немецких решений, до 2019 года задача находилась на исследовании, и активных работ не было. Просто присматривались. В 2019-м это стало проектом.

NiFi

На тот момент со стороны технических требований лучше всего для наших задач подходил движок Apache NiFi. К тому же проект открытый, и можно свободно его использовать в рамках лицензий. Юристы проработали все детали, и в конце 2019-го мы взяли исходные коды NiFi и начали собирать ядро будущего Атом.Моста.

NiFi — опенсорс, он похож на Hadoop, если сильно прищуриться, при этом NiFi — на одной стороне Волги, Hadoop — на другой, а между ними — туман. Но там полноценные коннекторы к Cassandra, Mongo, ElasticSearch, Kafka, RabbitMQ и ещё десяткам систем. Есть богатое API для создания модулей, есть преобразование данных, есть GUI для настройки потоков данных (достаточно быть аналитиком, и даже не надо разрабатывать или знать встроенный язык либо регулярные выражения) и так далее.



То есть в идеальном мире мы взяли бы NiFi, снабдили кучей своих плагинов и выкатили на прод. И это в полной мере решило бы задачу.

Но мир неидеален

Когда вы делаете что-то для корпорации вроде Росатома, то нельзя просто взять опенсорсный продукт и выкатить его на прод. С 2022 года нельзя вдвойне, потому что требуются очень внимательная проверка и переработка кода через РБПО (разработка безопасного ПО).

Во-первых, код опенсорса постоянно обновляется, и вы не всегда можете отследить зависимости третьего и дальше порядков. Решение — стабилизировать версию и втягивать обновления крупными релизами через аудит кода.

Во-вторых, даже если вы так сделаете, то это хорошо работает для некоторых компаний, но далеко не для всех. Для нескольких нужен аудитор, которому все доверяют. В России для компаний с госучастием это ФСТЭК. Они обещают, что в коде не будет закладок и уязвимостей (точнее, по факту они обещают, что проверят это насколько могут), и после сертификации ФСТЭК решения можно использовать железобетонно. В смысле на проверках вас не накрячат за то, что вы приняли в эксплуатацию какой-то левый софт.

В этих условиях мы сделали следующее:

1. Отделили ядро NiFi (сам движок) от всех интерфейсов (процессоров и адаптеров).
2. Доказали, что все требования безопасности относятся именно к ядру, то есть адаптеры не требуют отдельной сертификации.
3. Прогнали очень большое количество тестов ядра в собственной лаборатории.
4. Засертифицировали ядро во ФСТЭК.
5. Доработали собственные адаптеры (в основном к SAP-стеку). Были разработаны коннекторы для протоколов SAP — XI и RFC, позволяющие переносить существующие интеграции с SAP без доработки бизнес-систем.

Как проходили сертификацию

Опенсорсное ядро достаточно хорошо, но, как показывает практика, случается всякое. Нужны доказательства. Вот, например, история про внедрение бэкдора в одну из популярных nix-библиотек и включение этой библиотеки в Debian.

Собственно, нужно убедиться самим, а потом отдать проверенное во ФСТЭК.

Во-первых, наши эксперты читали код.

Во-вторых, мы прошлись по этому коду статическими анализаторами.

В-третьих, наши безопасники написали обширную программу тестов для испытательной лаборатории на своих стендах.

Это вызывало очень необычное распределение ролей: если разработку (отделение ядра и написание коннекторов) делали пять человек, то ещё около 20 занимались безопасностью.

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

Вот примеры:



Из этого было что-то важное:



И что-то не очень:



Больше всего проблем было с тем, как пофиксить то, что находил статический анализ, и при этом не поломать всю остальную систему. Ещё нюанс с «количествами»: если минорная ошибка, например, в количестве 300 штук, то это, стало быть, надо было пофиксить 300 штук мест, при этом часто однотипно, а как следствие можно запутаться в правках. Там, где копипаст несильно работает, нужно по коду править очень внимательно. Вот это вот «много плюс внимательно» — это довольно сложно.

Ещё одна особенность — статический анализ, конечно, классная штука, но сложнее всего находить те баги, которые он не видит.

По юнит-тестам: сложно было увеличить процент покрытия. Начинали там вообще с 10–20 %, а без юнит-тестов фаззинг-тесты делать несильно понятно как. То есть «одна сложность тянет за собой вторую», и это нарастает, как снежный ком.

Ещё было сложно фиксить баги сборки, то есть когда в результате в дистрибутив попадали не те артефакты, которых ожидали. Особенно речь идёт про nifi-assembly — блок в ванильном дистрибутиве исходников, который выпил нам много крови.

Было то, что статанализ видел как ошибку, но ошибкой оно не являлось:



А в конце этих работ нужно было составить список документов для сертификации. «Покрыть документацией» — это далеко не так просто, как вы думаете. Конкретно нужны были:

• Функциональная спецификация.
• Базовый модульный проект.
• Руководство администратора.
• Описание инструментальных средств разработки.
• Руководство пользователя (оператора) по эксплуатации.
• ПМИ функционального тестирования.
• Спецификация.
• Руководство по безопасной разработке продукта (GADF).
• Документ «Описание архитектуры безопасности».
• Анализ влияния обновлений на безопасность.
• Ведомость эксплуатационных документов (ВЭД).
• Технические условия.
• Описание применения (продукта).
• Описание программы.
• ПМИ на проникновение.
• Протоколы функционального тестирования.
• Протоколы тестирования на проникновение.
• Формуляр.
• Документ «Модель безопасности».
• Документ «Анализ скрытых каналов».
• Документ «Процедуры устранения недостатков».
• Регламент безопасной разработки.

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

Затем всё это в собранном протестированном виде уехало во ФСТЭК. После всех мучений длиной почти в год получили документ, что соответствуем.

Всё это случилось в 2021 году.

Внедрение

Есть SAP-шина, рядом стоит наш Атом.Мост. Мы взяли в команду около 35 стажёров, они брали потоки SAP и аккуратно переводили уже на российский Атом.Мост. Что-то автоматизацией покрывалось хорошо, что-то — не очень. Стремимся всё автоматизировать, конечно, чтобы дальше на коммерческом рынке были инструменты для миграции с SAP’а на Мост.

Затем после описания потока меняли эндпоинт. С точки зрения владельцев систем, ничего не менялось. Система переключалась и работала дальше. Как исходная сборка думала, что стучит в SAP-шину, так и продолжает думать — никаких изменений.

Дальше стали копиться запросы новых фич и особенности, которые хорошо бы включить в следующий релиз. А, напомню, релиз ядра — это проблема, потому что нужно заново проходить сертификацию. Конечно, это уже не с такими болями, как в первый раз, но всё равно долго, сложно и дорого.

Поэтому всё, что можно сделать без изменения ядра, делается без изменения ядра, чтобы не затрагивать функции безопасности. Из важных апдейтов — прикрутили Graylog (продукт по управлению логами, предупреждениями и уведомлениями) и с помощью него сделали мониторинги.

Следующая версия, которую уже делаем, — там внушительная часть доработок от ядра 2021 года. Наша задача — органично связать бизнес-мониторинг с ядром. Сейчас сообщения с ошибкой отправляются в Graylog, но нет возможности сделать прямую линку на ошибку, чтобы перейти в конкретный объект. Приходится искать по идентификатору. Это усложняет работу поддержки. Есть сложности с навигацией: Атом.Мост — самодокументируемый, и нет необходимости писать документацию к потокам. Но потоки собираются из кубиков, и там сложная система вложений. Может быть до 10 иерархических уровней, и это затрудняет чтение. Хотим приделать модуль, чтобы навигация была удобнее, каталогизировать потоки. Добавляем автоматизацию управления конфигурациями, чтобы Мост запускался, как сервис с управлением, из одной точки (совместимость с оркестратором). Есть особенности маппинга SAP, нельзя править из Моста (можно только читать), а хотелось бы менять. Сейчас будем делать маппинг, что позволит из двух табличек связывать поля перетаскиванием стрелочек, а на самих стрелочках можно будет рисовать функции, что делать с полем. Добавляем совместимость со СМЭВ — это требования заказчиков.

Итог

Готово!

Как я уже говорил, по стратегии Росатома к внутренним решениям есть требование, чтобы они были применимы и конкурентоспособны и на коммерческом рынке. Это определяет уровень качества ПО. Мы начинали с решения для атомной отрасли, а выросли в продукт, который, как показало общение с сообществом, интересен и другим компаниям, кроме Росатома. Поэтому мы продаем шины всем, кому это актуально. Посмотреть можно тут, если что.