Привет! Мы — команда сопровождения банковских телекоммуникаций Национального Расчётного Депозитария (НРД) Группы Компаний «Московская Биржа». Сегодня мы подробно расскажем о практическом опыте импортозамещения АРМ КБР-Н и АРМ КБР-СПФС (далее – АРМы) на базе отечественной операционной системы Astra Linux.
Почему это важно?
Тема импортозамещения стала более актуальной с тех пор, как был принят ряд нормативных актов:
• Федеральный Закон (ФЗ)187 – о защите КИИ;
• Указ Президента №166 – о развитии отечественного ПО;
• Постановление Правительства №1478 –о перечне критически важных систем.
Как Сервис-Бюро, предоставляющее подключение к СПФС, мы не просто обязаны соблюдать регуляторные требования – мы несём ответственность в том числе и перед нашими клиентами. Сбой в работе АРМов – это сбой в доставке финансовых сообщений, а значит – риск для всей цепочки.
Примечание: Эта статья является продолжением цикла о внедрении отечественных решений. В предыдущей публикации “Внедрение ГОСТ-шифрования канала передачи данных с ЦБ РФ” мы описали переход на ПАК “ДИОНИС”. В этой статье мы фокусируемся исключительно на АРМах, без Рассмотрения ПО Disec, т.к. это решение в нашей архитектуре не используется: ПАК «ДИОНИС» является более отказоустойчивым Программно-аппаратным комплексом для шифрования канала связи.
Выбор ОС: почему Astra Linux?
АРМы разработаны Банком России для трёх платформ:
- Windows
- Alt Linux
- Astra Linux
Из двух отечественных вариантов мы выбрали Astra Linux – как наиболее распространённую в финансовой сфере, с хорошей документацией, поддержкой и совместимостью.
Архитектура развертывания:
• Физические серверы с аппаратной защитой;
• Использование Средств защиты информации (СЗИ) от Несанкционированного доступа (НСД);
• Средство криптографической защиты информации (СКЗИ) Сигнатура-L.
Установка Сигнатуры и самого АРМа проходит без сложностей, документация подробна и понятна.
При установке создаются стандартные группы пользователей и временные учётные записи. Для первичной настройки достаточно задать пароли и войти под ними.
С какими нюансами мы столкнулись при переходе?
1. Перенос конфигураций из Windows в Linux
Наиболее трудоёмкий этап – миграция конфигурационных файлов. В Windows-версиях прописаны пути вида C:\..., которые в Linux не существуют.
• Для АРМ КБР-Н: все пути легко находятся в интерфейсе и редактируются вручную.
• Для АРМ КБР-СПФС: необходимо проделать следующее:
– Открывать все вкладки, где указаны пути (например, ufebs);
– Включать неиспользуемые потоки, менять пути и в них, после чего отключать;
– Переключать настройки и корректировать форматы в неиспользуемых механизмах, например, при включении автоматической смены Операционного дня (далее ОД) при изменении системной даты на сервере доступна опция выбора часового пояса. Корректный часовой пояс нужно выбрать независимо от того, какой механизм смены ОД Вы используете.
2. Запуск через локальную консоль
При запуске АРМа локально (через IPMI или напрямую к серверу) – приложение Mono может падать с ошибкой неверного разрешения экрана.
При этом через RDP-сессию с тем же разрешением всё работает идеально.
Решение, которое работает стабильно:
В Astra Linux используем функцию “Новый вход в окне”:
1. Нажимаем «Завершение работы» → «Новый вход» → «В окне»;
2. В открывшемся окне запускаем АРМ.
3. Файловая интеграция
Разница между Windows и Linux:
• В Windows файл, открытый на запись, недоступен для чтения другими процессами;
• В Linux при работе с сетевыми файловыми системами (NFS, SMB и др.) запись может быть асинхронной.
Результат: АРМ пытается прочитать файл до завершения записи и отбраковывает его как повреждённый. Для избегания этого есть пару решений:
• Решение 1: Писать в файл с именем, начинающимся на точку (например, .temp.dat), а затем переименовывать его в data.dat.
АРМ не читает скрытые файлы и не будет пытаться их обработать до переименования.
• Решение 2 (рекомендуемое):
Перевести интеграцию с файлового взаимодействием на AMQP v.1.0, который уже на текущий момент поддерживает АРМ
Мы выбрали второй путь.
У нас в Группе MOEX разработан и внедрён собственный брокер сообщений, который в том числе умеет работать с AMQP 1.0 и уже используется в других проектах.
Планируем полный переход на него в 2026 году.
Это позволит улучшить отказоустойчивость, масштабируемость и безопасность.
Итоги и выводы
На момент первого квартала 2026 года:
✅ АРМы работают на Astra Linux стабильно, с минимальными сбоями.
✅ Запланирован Переход на AMQP – стратегически верное решение, которое позволит улучшить отказоустойчивость, масштабируемость и безопасность.
Что дальше?
• Планируем полный переход на AMQP 1.0 в 2026 году;
• Планируем участвовать в рабочих группах по стандартизации импортозамещённых решений;
• Поддерживать и развивать собственное решение брокера сообщений
Заключение
Импортозамещение – это не просто смена ОС. Это перестройка архитектуры, процессов и взаимодействия с поставщиками.
Мы прошли путь от “работает на Windows” к “работает на Astra Linux”, и результат точно оправдывает усилия.
Мы не просто соблюдаем требования регулятора – мы строим устойчивую, независимую и безопасную инфраструктуру для финансовой системы России.
Если вы также внедряете импортозамещённые решения – пишите в комментариях: с какими нюансами столкнулись? Какие обходные варианты решения нашли? Давайте обмениваться опытом – это ускорит переход всей отрасли.