Финансовый сектор остается одной из главных целей кибератак, но парадокс в том, что даже при росте инвестиций в безопасность риски не снижаются пропорционально. Банки внедряют десятки средств защиты, проходят проверки регуляторов и формально соответствуют требованиям — однако это не всегда означает реальную устойчивость к атакам. Кибер Медиа разбирает, где проходит граница между «галочками» и работающей защитой, какие риски появляются при интеграции с партнерами и облаками и какие практики действительно помогают снижать угрозы — разбираемся вместе с экспертами рынка.
Содержание
Банковский сектор традиционно считается одним из самых зарегулированных: требования ЦБ, жесткие ГОСТы и отраслевые стандарты создают иллюзию непробиваемого щита. На бумаге у большинства организаций всё в порядке — процессы описаны, средства защиты закуплены, аудиты пройдены. Однако соответствие нормативам (комплаенс) часто становится ловушкой, создающей «минимально допустимый» уровень безопасности, который никак не гарантирует устойчивость к реальным, подготовленным атакам.
Разрыв между отчетами и реальностью опасен тем, что регуляторные требования по своей природе консервативны и неизбежно отстают от скорости мысли злоумышленников. Пока стандарт проходит этапы согласования, хакеры уже вовсю эксплуатируют новые векторы в социальной инженерии и компрометации цепочек поставок.
Федор Музалевский
Директор технического департамента RTM Group
Следует помнить, что банки — не просто под надзором ЦБ. Они еще и операторы персональных данных (зачастую — биометрических), и субъекты КИИ. В этой ситуации надо строить систему безопасности, основанную, во-первых, на реальной защите, а во-вторых, на компиляции требований. Подход к построению при этом должен включать в себя (в первую очередь), учет защищаемой инфраструктуры и моделирование угроз. На основании последней допускаются даже корректировки базовых требований ГОСТ 57580.1 и приказов ФСТЭК. Что касается нормативки — необходимо ее применять с учетом актуальных угроз, и будут достигнуты обе цели.
Такой подход позволяет банку превратить безопасность из набора артефактов в живой, работающий механизм. Когда защита строится только «для галочки», возникают типичные проблемы: средства ИБ работают на заводских настройках, логи собираются, но не анализируются, а пентесты проводятся в тепличных условиях, чтобы не нарушить бизнес-логику. В итоге защита существует в параллельной реальности, которая редко пересекается с актуальной моделью угроз. Чтобы изменить ситуацию, банкам приходится переходить от концепции «выполнить требования» к реальному управлению рисками.
Классический подход к безопасности, выстроенный вокруг защиты периметра, окончательно потерял актуальность. С развитием облачных платформ, удаленного доступа и открытых API само понятие «доверенной зоны» внутри банка размылось. Сегодня хакеру не нужно штурмовать внешние файрволы — ему достаточно скомпрометировать одну учетную запись сотрудника или найти уязвимость в партнерском сервисе, чтобы оказаться внутри контура.
Фокус современной защиты неизбежно смещается с укрепления внешних границ на тотальный контроль внутренних процессов и сценариев взаимодействия.
Юрий Горячев
Менеджер по продукту компании NGENIX
Во-первых, нужно трезво оценить свои информационные активы и разделить их по уровню значимости и конфиденциальности данных. Например, требования от ИБ к сайту-визитке и личному кабинету с ДБО разные. И защищать первый ресурс на том же уровне, что и второй, –– избыточно и лишает финансовую организацию возможности гибко подбирать инструменты для защиты.
Во-вторых, нужно определить, какие задачи можно законно делегировать сервис-провайдерам. И первым принципом подбора провайдера должно быть соответствие необходимым для организации-заказчика регуляторным требованиям. Уже после этого идут функционал, цена и другие факторы. При заключении договора с сервис-провайдером нужно обязательно зафиксировать зоны ответственности каждого, это необходимо в первую очередь для заказчика.
В-третьих, выбор сервис-провайдера — это всегда вопрос доверия, так как в случае тех или иных инцидентов невозможно просто прикрыться аттестатами. В таких случаях всегда хорошо, когда со стороны сервис-провайдера на кону также репутация, и чем «громче» имя такого подрядчика, тем сильнее он сам будет заботиться о своих репутационных рисках. Поэтому тут рекомендую смотреть на компании, которые давно на рынке, имеют хорошие рекомендации, обладают большой экспертизой и опытом защиты веб-ресурсов.
В рамках новой архитектуры модель угроз перестает быть формальным документом и становится рабочим инструментом. Она диктует приоритеты: какие узлы сети изолировать в первую очередь, где усилить мониторинг, а где достаточно базовых средств контроля. Это позволяет уйти от стратегии «защищаем всё понемногу» и сфокусировать ресурсы на действительно критических точках отказа.
Зрелая архитектура сегодня опирается на три фундаментальных фактора, которые должны работать синхронно:
Если один из этих элементов проседает, вся система становится уязвимой. В конечном счете эффективная защита сегодня — это не «забор», а интеллектуальная система мониторинга доступа и поведения, которая позволяет банку не просто соблюдать правила регулятора, а реально управлять своей киберустойчивостью.
Финансовые организации все активнее выходят за пределы собственного контура: экосистемы, Open API, интеграции с финтех-сервисами становятся нормой. Банк больше не изолированная система — это часть распределенной среды, где данные постоянно передаются между участниками. Именно здесь возникает новая проблема: данные уходят за пределы инфраструктуры, а ответственность за них остается внутри банка.
Формально все выглядит корректно: доступы выданы, каналы защищены, взаимодействие регламентировано. Но на практике контроль начинает размываться. Банк уже не видит, как именно используются данные у партнера, кто к ним имеет доступ и как меняется контекст их обработки со временем. В результате основные риски концентрируются вокруг нескольких сценариев:
Причем эти риски редко связаны с явными нарушениями. Чаще это накопительный эффект: доступы не пересматриваются, интеграции усложняются, а требования к безопасности у разных участников экосистемы остаются на разном уровне.
Алексей Сторож
Ведущий консультант AKTIV.CONSULTING
Атаки на цепочку поставок надежно закрепились в трендах. Банк России уже сейчас обязывает финансовые организации предъявлять требования по защите информации к своим поставщикам ИТ- и ИБ-услуг и прочим контрагентам, участвующим в их технологических процессах. Самый экономный по ресурсам самой финансовой организации вариант — предъявить к контрагенту требование о необходимости соответствовать ГОСТ Р 57580.1-2017 — так, некоторые компании уже сейчас включают внешнее заключение о соответствии в перечень необходимых документов для участия в конкурсах.
На этом фоне меняется сама логика защиты. Недостаточно просто «закрыть канал» — важно контролировать каждое обращение к данным: кто, откуда, в каком контексте и с какой целью их использует. Без этого даже корректно выданный доступ может стать источником инцидента. При этом технические меры не решают проблему полностью. Даже при наличии шифрования, токенизации и контроля API слабым местом остается управление партнерскими отношениями — от первичной оценки до регулярного пересмотра доступа и мониторинга активности.
Василий Жидков
Датасан, компания «Перфоманс Лаб»
Судебная практика 2025 года окончательно закрепила вектор ответственности в вопросах утечек: за сохранность данных отвечает их первичный оператор. Передача информации третьей стороне не снимает юридических рисков с компании, которая эти данные собрала.
Главный барьер на пути к безопасной передаче данных — технологический разрыв между безопасностью и функциональностью. Для задач разработки и тестирования данные должны оставаться «живыми», сохраняя свою структуру и логические связи.
Решение проблемы лежит в плоскости автоматизированного обезличивания данных еще до того, как они покинут защищенный контур компании. Основная задача здесь — заменить реальные значения на реалистичные, но фиктивные. Автоматизация процесса лишает сотрудников возможности «по ошибке» выгрузить боевую базу в облако партнера. Решение работает внутри контура заказчика, что критически важно для соблюдения требований регуляторов. Партнер получает на вход массив, который выглядит как настоящий, но не несет в себе юридических и репутационных рисков.
Поэтому зрелый подход сегодня — это контроль не только внутри банка, но и на уровне всей экосистемы. И чем дальше данные уходят от исходного контура, тем важнее становится этот сквозной контроль, потому что именно там чаще всего и теряется реальная безопасность.
Несмотря на рост инвестиций в технологии защиты, самым эффективным способом атаки на банки остается не взлом инфраструктуры, а работа с людьми. Социальная инженерия стабильно обходит сложные системы безопасности, потому что атакует не уязвимости в коде, а поведение — сотрудников и клиентов.
Проблема в том, что технологии здесь играют вспомогательную роль. Можно выстроить сильную защиту периметра, внедрить антифрод и мониторинг, но если пользователь сам передает доступ или подтверждает операцию — система воспринимает это как легитимное действие. Именно поэтому классический подход «закрыть все технически» в этой зоне не работает. Типовые сценарии атак хорошо известны, но продолжают успешно применяться за счет адаптации под контекст:
Ключевая сложность в том, что такие атаки маскируются под нормальное поведение и не всегда выбиваются из привычных сценариев — ни для пользователя, ни для системы.
Владимир Арышев
Эксперт по комплексным проектам информационной безопасности STEP LOGIC
Защита от атак методом социальной инженерии требует комплексного подхода и применения многоуровневой защиты. Основным способом противодействия является обучение пользователей при помощи различных методик. Наибольшую эффективность показывают системы класса Security Awareness, позволяющие проверить навыки при помощи тестовых атак.
С технической стороны «подстраховать» пользователей стоит с помощью специализированных средств защиты:
- Zero Trust. Необходимо строить инфраструктуру по принципу Zero Trust — допускать, что каждый пользователь уже может быть скомпрометирован.
- Антиспам, антифишинг, антивирус, «песочница». Следует оградить пользователей от воздействия злоумышленников, используя антиспам и антифишинговые решения. «Песочницы» играют важную роль в защите от неизвестных угроз.
- Фильтрация. Открытие ссылки от злоумышленников должно быть заблокировано с помощью URL-фильтрации на уровне шлюза безопасности.
- Обновление ПО. Мы рекомендуем своевременно обновлять программное обеспечение — злоумышленники используют софт, нацеленный на известные уязвимости.
- Выявления аномалий. Если зараженный файл попал на рабочую станцию, в ход идут системы выявления аномалий, такие как EDR и XDR.
Классические решения — антифишинг, антифрод, блокировка подозрительных операций — остаются важной частью защиты, но у них есть ограничение: они реагируют на уже известные паттерны. В то время как социальная инженерия постоянно меняется и подстраивается под пользователей. Поэтому акцент смещается в сторону поведенческого анализа и контекстной проверки действий. Не просто «операция подозрительная», а «операция нетипична для этого клиента или сотрудника в данном контексте».
Но даже этого недостаточно без системной работы с пользователями. Обучение, регулярные симуляции атак, изменение интерфейсов (например, дополнительные проверки при критичных действиях) — все это становится частью архитектуры защиты, а не отдельной инициативой.
Степан Клепиков
Эксперт Security Vision
Первоисточником инцидента зачастую будет неподготовленный технически пользователь. Социальная инженерия живет за счет спешки и страха, а технологии должны эту спешку умело убирать, давая человеку время «на подумать».
Для защиты от современной социальной инженерии клиенту банка будет достаточно донесения информации о надежных паролях, двухфакторной аутентификации и основах критического мышления. Повышение осведомленности — постоянный и важный шаг. В частном случае, говоря про сотрудников банка, технологический «страховочный контур» сегодня смещается от простых презентаций к глубокому анализу контекста и поведения.
Поведенческий анализ с развитием больших языковых моделей и нейросетей приобрел особую актуальность: алгоритмы считывают уникальный почерк взаимодействия с устройством. Параллельно архитектура безопасности перестраивается под принцип нулевого доверия: микросегментация сети ограничивает злоумышленника одной изолированной точкой. Сейчас технологический стек выполняет роль второго пилота, который оценивает ситуацию в моменты, когда человеческий фактор и эмоции берут верх.
В итоге борьба с социальной инженерией — это всегда комбинация: технологии + процессы + поведение. И именно в последнем компоненте чаще всего возникает разрыв. Потому что в отличие от систем, пользователей невозможно «обновить» или «пропатчить» — с ними приходится работать постоянно.
Облачные технологии для финтеха уже не альтернатива, а стандарт. Они позволяют быстрее запускать продукты, масштабироваться под нагрузку и снижать издержки на инфраструктуру. Для бизнеса это скорость и гибкость. Для ИБ — новая поверхность атаки. Главная иллюзия здесь в том, что облако «по умолчанию безопасно». Провайдер действительно закрывает значительную часть задач — от физической безопасности до базовой защиты инфраструктуры. Но все, что происходит на уровне конфигурации сервисов и доступа, остается зоной ответственности самого банка. И именно здесь чаще всего начинаются проблемы.
В отличие от классической инфраструктуры, ошибки в облаке редко выглядят как явные нарушения. Гораздо чаще это цепочка небольших решений: доступ дали «на всякий случай», тестовую среду не закрыли вовремя, сервис развернули быстрее, чем успели проверить настройки. Каждое из этих действий по отдельности не выглядит критичным, но в совокупности формирует уязвимую конфигурацию. Дополнительную сложность создает динамика: инфраструктура постоянно меняется, ресурсы поднимаются и удаляются, права перераспределяются. В таких условиях даже корректно настроенная среда со временем начинает «дрейфовать» от исходной модели безопасности.
Отдельная проблема — shared responsibility (модель разделяемой ответственности). Формально она четко делит зоны ответственности между провайдером и клиентом. Но на практике это разделение не всегда очевидно: часть рисков оказывается в «пограничной зоне», где контроль либо дублируется, либо, наоборот, выпадает совсем.
Евгений Балк
Руководитель департамента развития и архитектуры «Кросс технолоджис»
В основном это ошибки аутентификации, избыточные права пользователей, открытые служебные порты, неправильная настройка журналирования и мониторинга и так далее. Более 70% ошибок конфигурации связаны с человеческим фактором, то есть ситуациями, когда специалист неправильно настроил систему, что и привело к инциденту информационной безопасности.
Чтобы справляться с этим, банкам приходится менять сам подход к управлению инфраструктурой. Ручной контроль перестает масштабироваться — слишком много изменений происходит одновременно. Вместо этого акцент смещается на автоматизацию и постоянную проверку состояния среды: что развернуто, какие у этого права, и соответствует ли это принятым политикам безопасности. Важно не только один раз настроить, но и регулярно подтверждать, что конфигурация не ушла в сторону.
При этом даже самые продвинутые инструменты не решают проблему без выстроенных процессов. Критично, как быстро команда видит отклонения и как на них реагирует — потому что в облаке время между ошибкой и инцидентом может быть минимальным.
Дмитрий Башков
Руководитель направления по работе с клиентами AKTIV.CONSULTING
В облачной инфраструктуре типовые ошибки почти те же, что и в on‑premise. Во‑первых, это забытые ресурсы: тестовые среды, старые S3‑бакеты, отладочные VPN, которые так и остаются с публичным доступом или слабыми/дефолтными учетными данными. Во‑вторых, безответственный харденинг: дефолтные настройки вендора, устаревшие протоколы, отсутствие MFA на админских аккаунтах, торчащие наружу панели, избыточные права сервисных учетных записей. И, в-третьих, излишняя вера в интегратора или облачного провайдера. После внедрения решения или миграции редко проводится независимый аудит конфигураций и тестирование на предмет новых точек входа, хотя практика показывает, что ошибки в настройках самого клиента, а не провайдера.
Таким образом, облако не упрощает безопасность, а делает ее более чувствительной к деталям. И чем выше скорость разработки и внедрения, тем важнее контроль — потому что именно в этих «мелочах» чаще всего и скрываются реальные уязвимости.
Для финансового сектора импортозамещение давно перестало быть стратегией «на будущее» — это уже операционная реальность. Давление со стороны регуляторов и рынка заставляет банки пересматривать стек средств защиты, зачастую в сжатые сроки и без права на ошибку. Сложность в том, что речь идет не просто о замене одного решения на другое. Критические системы ИБ глубоко встроены в инфраструктуру: они завязаны на процессы, интеграции, команды и даже на привычные сценарии работы. Любое вмешательство в этот слой — риск.
И эти риски вполне конкретные. При неаккуратной миграции можно получить временное «ослепление» мониторинга, конфликты между системами, потерю части функциональности или просто деградацию качества защиты. Отдельный сценарий — когда новая система формально внедрена, но фактически не покрывает те угрозы, которые закрывало предыдущее решение. Добавим к этому фактор времени: переход часто происходит параллельно с текущими задачами, без возможности «поставить все на паузу». В результате нагрузка на команды растет, а цена ошибки увеличивается.
Алексей Захаров
Директор по техническому консалтингу Axiom JDK
Стратегия импортозамещения критических систем защиты должна строиться на концепции перехода на единый доверенный технологический стек:
- Отбор ключевых компонентов – это основное требование для обеспечения безопасности строительных блоков архитектуры. Он позволяет использовать подготовленные и проверенные артефакты из доверенных репозиториев библиотек и Docker-образы из доверенных репозиториев на территории России. Это может существенно снизить затраты ресурсов разработчиков на стандартный функционал библиотек и перераспределить их на создание новой бизнес-логики приложений.
- Интеграция в среду РБПО в соответствии с ГОСТ Р 56939-2024 позволит проверять код и компоненты на наличие уязвимостей. В случае их обнаружения сборочный конвейер не будет завершать сборку или будет выдавать соответствующее предупреждение. В системах журналирования будут сохраняться все истории проверок и сборок. За каждым процессом будет определен ответственный, а сам процесс будет описан и формализован. В итоге разработчики смогут оперативно заменить компонент на более защищенный и устранить потенциальные уязвимости еще на этапе разработки.
- Поддержка от производителя — каждый компонент архитектуры должен иметь на территории РФ ответственного производителя. Это позволяет проводить миграцию или обновление версий доверенных компонентов максимально быстро и гарантирует возможность оперативного устранения проблемы с прямым каналом взаимодействия с производителем.
На практике устойчивый подход к импортозамещению строится через постепенную миграцию, а не через «большой переключатель». Новые решения сначала внедряются параллельно с текущими, проходят обкатку в реальных сценариях и только затем начинают брать на себя основную нагрузку. Это позволяет не только снизить риск отказа, но и выявить функциональные разрывы: где новая система работает иначе, где требует донастройки, а где не закрывает критичные задачи.
При этом важно учитывать, что сама по себе замена технологии не гарантирует сохранение уровня защиты. Если не пересобрать процессы и не адаптировать настройки под новую логику работы, эффективность может просесть — даже если решение формально «аналогичное».
Денис Бандалетов
Руководитель отдела сетевых технологий Angara Security
Импортозамещение в сфере защиты — не просто замена одного продукта на другой, а полноценная трансформация архитектуры. Главная ошибка — пытаться сделать это «в лоб», без этапа параллельной эксплуатации. На практике эффективнее выстраивать гибридные схемы, где новые решения внедряются постепенно, с обязательным тестированием под нагрузкой и проверкой совместимости. Важно также заранее предусмотреть вопросы интеграции и обучения персонала, потому что даже лучшая технология не работает без правильной эксплуатации. В итоге успешное импортозамещение — всегда баланс между технологическими рисками и требованиями к непрерывности бизнеса.
В итоге импортозамещение — это не разовый проект, а полноценная трансформация ИБ-ландшафта. И чем более критичны системы, тем важнее двигаться поэтапно: с тестированием, валидацией и постоянной проверкой того, что защита не только сохранилась, но и действительно работает в новых условиях.
В финансовом секторе вопрос «что реально защищает» уже не сводится к выбору конкретных решений. У большинства банков есть сопоставимый стек технологий. Разница проявляется в том, как эти решения встроены в процессы и используются на практике.
Работающая безопасность строится на непрерывном цикле проверки и адаптации и включает несколько ключевых элементов:
В итоге устойчивость появляется там, где есть постоянный цикл: проверка → выводы → изменения → новая проверка. Именно такая динамика создает живую, работающую безопасность, которую нельзя просто формализовать в регламенте, но можно проверить реальными атаками.
Безопасность в финансовом секторе — это не состояние, а непрерывный процесс. Соответствие регуляторным требованиям — лишь базовый минимум, но оно не гарантирует защиту от современных угроз. Реальная безопасность строится на сочетании технологий, процессов и людей. Только так организация может управлять рисками, быстро реагировать на инциденты и сохранять непрерывность бизнеса. Постоянная проверка, адаптация и обучение делают защиту живой, а не формальной галочкой в отчете.
Атаки на системы искусственного интеллекта смещаются с уровня кода на уровень данных.
Бурное внедрение нейросетей в бизнес-процессы породило не только новые возможности, но и специфические угрозы: от галлюцинаций и утечек обучающих выборок до жестких требований EU AI Act.
47% экспертов, представляющих руководство средних и крупных компаний, считают атаки с целью вымогательства главным риском своей информационной безопасности в 2025 году.
Корпоративные VPN перестают быть технической «данностью» и переходят в категорию регулируемых сетевых сервисов.
Вельц Сергей Владимирович - технический директор, соучредитель ООО "КБ ТехноСкор" специально для читателей Кибер Медиа рассказывает, как банку автоматизировать комплаенс-контроль, отказаться от рутины и превратить управление рисками из угадывания в точный расчет с помощью AI-агентов.
В 2026 году ландшафт цифровых коммуникаций претерпевает серьезные изменения: на фоне локальных сбоев связи, инфраструктурных ограничений и растущей потребности в автономности пользователи массово переходят на альтернативные способы общения.
Количество кибератак растет, а вместе с ними — и бюджеты на информационную безопасность.
Принцип security by obscurity знаком каждому, кто хоть немного погружен в кибербезопасность.
Категорирование объектов критической информационной инфраструктуры в 2026 году обрело новые контуры.
Современная атака может не оставить ни одного файла на диске — и при этом полностью скомпрометировать инфраструктуру.
