Банковский сектор переживает тектонический сдвиг: облака перестали быть экспериментом для некритичных задач и превратились в площадку для систем, обрабатывающих чувствительные данные. Одновременно растёт интенсивность целевых атак, а вместе с ней – и цена ошибки при выборе поставщика. О том, как соотносятся регуляторные риски и угрозы кибератак, почему Security by Design – это не только про технологии, но и про архитектуру доверия, и где чаще всего банки ошибаются в ожиданиях от провайдера, главному редактору Национального банковского журнала (NBJ) Станиславу КОМАРОВУ рассказал директор департамента информационной безопасности Astra Cloud (входит в «Группу Астра») Дмитрий ЖАБИН.

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

Д. ЖАБИН: На мой взгляд, многое зависит от задачи, которую банк планирует решать с помощью облачных технологий, и от того, какую часть инфраструктуры он собирается перенести в облако.

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

Для каждого сценария требования будут различаться. Банк должен учитывать критичность системы для бизнес-процессов, чувствительность данных, требования к доступности и отказоустойчивости, допустимое время восстановления, риски информационной безопасности с учётом требований регулятора.

Поэтому при выборе провайдера наряду со стоимостью ресурсов банк оценивает архитектуру и защищённость платформы, возможность использования её средств защиты информации или размещения собственных решений, SLA, резервирование и DR-сценарии, возможность проведения аудита, процессы реагирования на инциденты и распределение зон ответственности.

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

NBJ: Если сравнивать риски для банка. Регуляторные нарушения и санкции с одной стороны, кибератаки – с другой, что сегодня опаснее?

Д. ЖАБИН: Я бы не стал прямо противопоставлять эти риски. Нарушение регуляторных требований, конечно, может привести к штрафным санкциям, но «выписать штраф» не является основной целью регулирования. Требования к информационной безопасности и операционной надёжности прежде всего направлены на снижение вероятности инцидентов и возможного ущерба для клиентов банка и самой финансовой организации.

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

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

NBJ: За последние пару лет были задокументированы атаки группировок типа Hellhounds и др., нацеленные на российские компании. Насколько банковская инфраструктура сегодня попадает в зону риска?

Д. ЖАБИН: Банки уже сталкиваются с этим. По данным Банка России, в 2025 году число целевых атак на участников финансовой сферы оставалось стабильно высоким. Российские банки продолжают привлекать внимание новых группировок. В IV кв. 2025 года специалисты Positive Technologies зафиксировали фишинговые атаки Silver Fox на российские банки, хотя ранее группировка не проявляла интереса к России.

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

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

NBJ: Нельзя не упомянуть ИИ. Уже есть сообщения об использовании ИИ-агентов в кибератаках, обнаружены вредоносные MCP-компоненты и уязвимости в инструментах подключения ИИ к внешним системам. Банки при этом активно внедряют собственные ИИ-решения. Какие новые риски возникают, когда такие решения получают доступ к внутренним данным и возможность выполнять действия?

Д. ЖАБИН: Когда ИИ получает доступ к внутренним данным и инструментам банка, важно понимать, какие действия он может выполнять, и кто их контролирует. Для агентов это критично: ошибка или вмешательство злоумышленника может привести к нежелательным действиям с теми правами, которые агенту выдали.

Я вижу здесь два источника угроз. Первый связан с использованием ИИ злоумышленниками. Они находят способы обходить ограничения публичных сервисов, разворачивают локальные модели и создают собственных агентов – это подтверждают и сами разработчики моделей, например Anthropic. Так, злоумышленники автоматизируют подготовку и проведение атак и сокращают затраты на отдельные операции.

Второй источник связан с работой ИИ внутри самого банка: во внутренних сервисах, клиентских приложениях, средствах информационной безопасности. Если агенту выдали избыточные права, он может причинить ущерб даже в доверенном контуре. Для этого ему необязательно выходить из «песочницы» – достаточно нежелательного действия в пределах уже разрешенного доступа.

Банки уже систематизируют эти риски. Сбер опубликовал модель угроз кибербезопасности ИИ, охватывающую подготовку данных, разработку модели и её интеграцию в приложение, а в июне 2026 года Банк России выпустил рекомендации по безопасности разработки и применения ИИ на финансовом рынке.

Для Astra Cloud это означает работу на двух уровнях. Защиту инфраструктуры мы закладываем при проектировании облачной платформы, начиная со встроенных механизмов безопасности Astra Linux. Но права агента, доступ к банковским данным и контроль его действий нужно определять уже на уровне конкретного ИИ-сервиса.

NBJ: Как команда Astra Cloud проверяет, что защита облачной инфраструктуры работает?

Д. ЖАБИН: Мы регулярно проверяем и тестируем системы защиты информации, обновляем их и корректируем настройки, а также проверяем безопасность других продуктов, на которых построена платформа Astra Cloud Platform. В её основе – сертифицированная ФСТЭК России ОС Astra Linux со встроенными средствами защиты, средства виртуализации, служба каталога, решения для резервного копирования и мониторинга.

В 2026 году мы представили «Защищённое аттестованное облако». Его инфраструктура прошла аттестацию по требованиям приказов ФСТЭК России № 21 и № 117 для размещения информационных систем персональных данных до первого уровня защищённости (УЗ-1) и государственных информационных систем до первого класса защищённости (К1) включительно. В аттестованный контур входят сертифицированные средства защиты, в том числе межсетевые экраны, антивирусная защита, средства обнаружения вторжений и криптографической защиты.

Мы продолжаем развивать процессы защиты информации и уже начали прорабатывать соответствие требованиям по защите критической информационной инфраструктуры и прохождение аудита по ГОСТ 57580.

NBJ: Про Security by Design сегодня говорят многие. Чем ваш подход отличается?

Д. ЖАБИН: В нашем случае Security by Design – модель не только Astra Cloud, но и всей «Группы Астра». Подход применяется на раннем этапе проектирования отдельных продуктов и продуктовых связок.

В основе используется Astra Linux Special Edition со встроенными средствами защиты, работающими в том числе на уровне ядра. Поверх неё строятся виртуализация, управление учётными записями и другие службы платформы. Все продукты проходят испытания на совместимость. Заказчику это даёт возможность видеть компоненты как единое целое и понимать, как разграничивается доступ, изолируются среды, и как изменения в одном влияют на остальные.

Безопасность отдельных продуктов дополнительно проверяют независимые исследователи. Astra Linux и другие решения «Группы Астра» участвуют в программах BI.ZONE Bug Bounty: специалисты ищут уязвимости и передают разработчикам отчёты для их устранения.

NBJ: Крупные банки строят практически всегда собственный контур, так как законодательство этого требует. Когда им нужно облако?

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

Как уже говорил, практических сценариев эксплуатации достаточно. Если проект начинался в облаке, он может остаться там после выхода в промышленную эксплуатацию. Но это отдельное решение: перед запуском нужно заново оценить данные, подключения, нагрузку и требования к защите. Сложившиеся банковские системы, так называемые legacy-системы, переносят осторожнее, поскольку у них много зависимостей, а цена ошибки выше.

У Astra Cloud есть два варианта размещения на нашей стороне. Первый вариант – «Защищённое аттестованное облако» с готовыми средствами защиты. Второй – выделенное облако, где под требования банка можно подобрать и настроить собственный набор СЗИ и СКЗИ. Доступна круглосуточная поддержка. В любом сценарии инфраструктура запускается через нашу Astra Cloud Platform.

Если ресурсы должны оставаться у банка, например, при мультиоблачном сценарии, то мы готовы предоставить платформу для развёртывания на оборудовании заказчика – это удобно и надёжно. Так можно использовать продукты одной экосистемы и в своём контуре, и у провайдера.

NBJ: Почему банку выгоднее закрывать это у одного вендора, а не собирать решение по частям? Ведь сейчас же «модно» говорить про мультиоблачные стратегии?

Д. ЖАБИН: Банк выбирает архитектуру под свои задачи и оценивает риски зависимости от поставщика. При этом единый вендор платформы и несколько облачных площадок вполне могут сочетаться.

Преимущество вендорской модели Astra Cloud – в эксплуатации. Банк получает согласованный набор продуктов и единое окно поддержки. Если проблема затрагивает несколько компонентов, ему проще организовать решение и контролировать результат. Объём работы по согласованию действий разных поставщиков снижается, хотя требования к собственным банковским приложениям всё равно нужно учитывать отдельно.

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

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

Если для конкретной задачи нужен второй провайдер, это обоснованный выбор. Astra Cloud может участвовать в такой архитектуре, в том числе через платформу, развернутую в собственном контуре банка.

NBJ: Допустим, банк заключил контракт с провайдером. Где чаще всего банки ошибаются в ожиданиях?

Д. ЖАБИН: Чаще всего сложности возникают там, где стороны по-разному понимают состав услуг, если отдельно не были зафиксированы зоны ответственности.

В Astra Cloud мы разделяем ответственность по составу сервиса. На нашей стороне – инфраструктура и те компоненты платформы, сопровождение которых включено в договор. У банка остаются бизнес-процессы, решения о доступе к данным и требования к прикладным системам. У нас индивидуальный подход к заказчикам, и мы готовы совместно фиксировать перечень услуг в договоре.

Есть и регуляторная граница. Аттестованная инфраструктура Astra Cloud не равно автоматическая аттестация размещённой на ней информационной системы. Если требуется аттестация, то банк организует её отдельно, при необходимости с участием профильного подрядчика. Со своей стороны мы всегда готовы к оперативному предоставлению документов, подтверждающих выполнение требований.

NBJ: Один из ваших кейсов – выделенное облако с повышенными ИБ-требованиями для банка из ТОП-10. В чём именно заключалась уникальность запроса этого банка, и как вы его закрыли? Что стало для вас самым неожиданным вызовом в этом проекте?

Д. ЖАБИН: Заказчиком выступает подразделение информационной безопасности одного из крупнейших российских банков. При этом решение создаётся не только для самого банка: на его базе планируется предоставление облачных сервисов различным компаниям внутри холдинга. Поэтому задача изначально была значительно шире, чем просто предоставить IaaS. Фактически мы создаём технологическую основу для внутреннего корпоративного облака заказчика – полностью выделенную инфраструктуру на базе Astra Cloud Platform, которую размещаем на своей площадке, обеспечиваем её эксплуатацию и техническую поддержку.

Одна из ключевых особенностей проекта – повышенные требования к ИБ. Архитектура изначально проектировалась с учётом возможности дальнейшей аттестации, интеграции со средствами защиты заказчика и размещения его собственного оборудования в нашем дата-центре. Такой подход позволяет гибко адаптировать облако, сохраняя при этом преимущества сервисной модели.

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

Для нас это пример того, как выделенное облако постепенно превращается в полноценную корпоративную сервисную платформу – от базовой инфраструктуры до платформы разработки и сервисов искусственного интеллекта.   

Беседовал Станислав КОМАРОВ

Материал также опубликован в печатной версии Национального банковского журнала (сентябрь 2026)