8 (800) 302-34-73

Импортозамещение для банковского сектора: сервер под требования ЦБ

11 октября 2026 г.

Разбираем применимые требования ЦБ, совместимость российского стека и этапы перехода банковской серверной инфраструктуры.

Импортозамещение для банковского сектора: сервер под требования ЦБ

Региональный банк обновляет инфраструктуру и определяет требования к безопасности, непрерывности и импортозамещению для своих систем. Сервер для банка выбирают вместе с ОС, СУБД, приложением и средствами защиты: замена оборудования сама по себе не подтверждает соответствие регуляторике. Разбираем, как проверить применимость норм, совместимость российского стека и готовность к миграции.

Что требует ЦБ от серверной инфраструктуры банка

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

Документ

Что требует

Как закрывается

851-П от 30.01.2025

Защита информации при банковской деятельности против переводов без согласия клиента

Меры защиты по применимым требованиям, проверка области сертификатов

821-П от 17.08.2023

Защита при переводах денежных средств

Меры для платежных процессов, журналирование и применимая криптография

850-П от 13.01.2025

Операционная надежность, метрики непрерывности

Целевые показатели, резервирование, испытания восстановления

ГОСТ Р 57580.1 и 57580.2

Три уровня защиты и методика оценки соответствия

Меры под нужный уровень защиты

Реестр происхождения продукции, сертификат средства защиты и соответствие банковским требованиям подтверждают разные свойства. Импортозамещение ПО на значимых объектах КИИ проверяют по Указу Президента №166 от 30.03.2022 и применимым актам. Приказ ФСТЭК №239 относится к значимым объектам КИИ, №21 к защите ИСПДн. Национальный режим закупок по ПП №1875 от 23.12.2024 рассматривают отдельно, когда закупка входит в его область. Это не общее требование реестрового происхождения всех серверов банка.

Какие серверные задачи в банке критичны

АБС и процессинг платежей

АБС ведет счета, вклады, кредиты, учет и отчетность. Для выбранной версии запрашивают поддержку архитектуры CPU, ОС, СУБД, модулей и интеграций. Xeon на x86-64 и Baikal-S на ARM не взаимозаменяемы: нужны подходящие сборки и драйверы. Конфигурацию рассчитывают по транзакциям, объему БД, регламентным операциям и задержке хранения, затем подтверждают пилотом. Число отделений не определяет память и диски.

Для процессинга задают задержку, простой и восстановление конкретного процесса. Применимые пороги 850-П сопоставляют с внутренними целями. Кластер испытывают отказом узла и площадки. Общих «миллисекунд на транзакцию» и «минут простоя в год» для любого сервиса нет.

Дистанционное банковское обслуживание и антифрод

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

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

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

Иллюстрация к разделу «Какие серверные задачи в банке критичны»
Иллюстрация к разделу «Какие серверные задачи в банке критичны»

Российский стек для банка на 2026: что реально доступно

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

  1. Серверные платформы. Для модели с подтвержденным происхождением проверяют реестровую запись, исполнение и состав поставки, гарантию и поддержку. Название производителя не подтверждает статус всех его моделей.
  2. Операционные системы. Для Astra Linux и РЕД ОС проверяют выпуск, архитектуру, поддержку оборудования и сертификат, когда он необходим. Реестр ПО и сертификат ФСТЭК имеют разное назначение. Для сохраняемого Windows-контура обосновывают допустимость использования и план перехода.
  3. СУБД. Postgres Pro и Tantor рассматривают по поддержке конкретной АБС, редакции и модулей. Пилот включает перенос схем, процедур, заданий, отчетов и интеграций, сверку расчетов и нагрузку закрытия дня. Наличие PostgreSQL-версии продукта не гарантирует миграцию текущей банковской системы.
  4. Средства защиты. Межсетевые экраны, WAF и SIEM подбирают по функциям, совместимости и применимым требованиям. Проверяют ОС, источники событий, резервирование и обновления. Каталог не заменяет документ об области применения.
  5. Криптография. Обозначения алгоритмов берут из документации выбранного СКЗИ, например ГОСТ Р 34.10–2012 и ГОСТ Р 34.11–2012 для соответствующего исполнения. Их не смешивают с межгосударственными ГОСТ 34.10–2018 и ГОСТ 34.11–2018. Для CSP и HSM проверяют точный выпуск, класс, область и условия сертификата ФСБ, совместимость с приложением и порядок управления ключами.

Модернизация IT-инфраструктуры регионального банка иллюстрирует другой аспект: гибридную архитектуру с VMware для приложений и выделенными физическими серверами для баз данных и аналитики. Такой кейс полезен для обсуждения отказоустойчивости, но не подтверждает переход на отечественные ОС и СУБД.

Как планировать переход

Пошаговый план миграции банковской инфраструктуры

Первый этап: инвентаризация. Фиксируют роль, владельца, критичность, данные, нагрузку, версии и поддержку. Карту зависимостей связывают с нормами и категориями объектов КИИ. Имя сервера без приложения и интеграций не определяет порядок миграции.

Второй этап: пилоты. Инфраструктурный тест проверяет управление, резервное копирование и эксплуатацию. В отдельной среде целевой АБС испытывают ОС, СУБД, модули, расчеты и обмен с внешними системами. Файловый сервер не заменяет такую проверку. Критерии приемки и допустимые отклонения определяют до испытаний.

Третий этап: перенос важных сервисов в согласованные окна. Готовят проверенную копию, откат и ответственных. Приоритет учитывает окончание поддержки и последствия отказа. До переключения проверяют сетевые правила, учетные записи и восстановление.

Четвертый этап: миграция АБС и процессинга. График и параллельную работу определяют сложность, интеграции, сверка расчетов и окна. Нужно исключить двойное исполнение платежей. Проект задает источник достоверных данных, условия переключения и границу безопасного возврата.

Пятый этап: документирование и приемка. Обновляют архитектуру, регламенты, сведения о средствах защиты и результаты испытаний восстановления. 850-П от 13.01.2025 действует с учетом переходных положений. Опубликованное в 2026 году Указание №7419-У от 22.07.2026 предусматривает изменения с 01.01.2027, а подпункт 1.5 с 01.01.2028. Эти даты не являются дедлайном замены всех серверов на отечественные. Для 821-П учитывают изменения №7220-У от 28.10.2025 и сроки их действия.

Иллюстрация к разделу «Как планировать переход»
Иллюстрация к разделу «Как планировать переход»

Типичные ошибки банковской миграции

При планировании проверьте следующие риски:

  • Перенос АБС без целевого пилота: тест инфраструктуры не подтверждает правильность банковских расчетов.
  • Непроверенное резервирование: отказ общего хранилища или сети может остановить оба узла.
  • Неточная область сертификата: название продукта не подтверждает нужную версию и условия применения.
  • Отсутствие проверенного отката: старый контур может содержать уже неактуальные данные.
  • Испытания только среднего потока: закрытие дня и пакетные задания создают другой профиль нагрузки.
  • Недостаточная подготовка команды: эксплуатацию новой ОС и СУБД нужно отработать до переноса.
  • Забытые интеграции: проверьте обмен с ЦБ, платежными системами и внешними сервисами.
  • Неуточненные уведомления: определите, какие сведения требуются регулятору для конкретных изменений и инцидентов.
  • Перенос без оценки архитектуры: общие зависимости могут сохранить прежние причины отказов.
  • Резервная копия без теста восстановления: наличие файла не подтверждает возможность запуска приложения.

Заключение

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

В кейсе регионального банка описана комплексная поставка и внедрение серверного оборудования с аудитом и поддержкой. Полный состав ОС, СУБД и объем регуляторной проверки требуют подтверждения. Поможем спланировать переход ваших приложений, проверить совместимость и согласовать приемку.