Усилить кибербезопасность банков: быстрый чек-лист для защиты

Главный риск сместился ближе к клиенту. До 80–90% успешных атак начинаются не с взлома ядра банка, а с социальной инженерии: пользователь сам передает код, подтверждает операцию, устанавливает удаленный доступ или проходит поддельную идентификацию. Технический вывод простой: защищать надо не только инфраструктуру. Надо защищать сценарий.

Угроза начинается не в дата-центре, а в канале коммуникации

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

Социальная инженерия плохо лечится одним контролем. Она проходит через несколько слабых мест:

• поддельные страницы входа в интернет-банк;
• фишинговые push-уведомления и письма;
• звонки с подменой номера;
• сценарии «службы безопасности»;
• вредоносные APK-файлы под видом банковского приложения;
• перехват SMS-кодов;
• оформление новых устройств в профиле клиента;
• вывод средств через быстрые платежи и P2P-переводы.

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

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

Если атакующий вошел с валидным логином и кодом, задача безопасности — доказать, что это все равно не клиент.

Здесь начинается практический уровень. Система должна связывать каналы: мобильное приложение, веб, контакт-центр, карточный процессинг, СБП, KYC-шлюз, CRM-события. Если они живут отдельно, фрод виден поздно. Часто уже после списания.

Быстрая инвентаризация: где контур обычно проседает

Усиление кибербезопасности банков начинается не с покупки новой платформы. Сначала фиксируются точки, где контроль формальный или разорванный. Ниже — рабочая последовательность аудита. Не как бумажная проверка. Как способ найти зоны, где атака пройдет без шума.

1. Разделить вход и подтверждение операции.

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

2. Проверить регистрацию нового устройства.

Это частая точка обхода. Злоумышленнику не всегда нужен перевод сразу. Ему достаточно привязать свое устройство, дождаться снижения подозрительности и затем вывести средства. Регистрация должна требовать step-up-аутентификацию, задержку для рискованных операций и уведомление через независимый канал.

3. Отделить SMS от сильной аутентификации.

SMS-код остается массовым инструментом, но как единственный второй фактор он слаб. SIM-swap, переадресация, вредоносные приложения и социальная инженерия делают его уязвимым. Для критичных действий нужен криптографический фактор: push с привязкой к устройству, FIDO2/WebAuthn, аппаратный ключ, биометрия как локальный фактор.

4. Свести события в единый risk engine.

Логин, смена пароля, выпуск виртуальной карты, перевод, изменение лимита, звонок в поддержку — это не отдельные события. Это цепочка. Антифрод должен видеть ее целиком и назначать риск в реальном времени.

5. Проверить хранение персональных и платежных данных.

Номера карт, PAN, CVV, токены, биометрические шаблоны, KYC-документы — разные классы данных. У них разные требования к шифрованию, маскированию, доступу и срокам хранения. Ошибка здесь превращает инцидент в крупную утечку.

6. Отработать сценарий компрометации.

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

Эта инвентаризация дает не красивую карту рисков, а список конкретных мест, где надо менять архитектуру.

2FA, MFA и биометрия: не одно и то же

Двухфакторная аутентификация снижает риск несанкционированного доступа более чем на 99% по сравнению с одним паролем. Это сильная цифра. Но она не означает, что любой второй фактор одинаково полезен.

Факторов три класса:

• знание: пароль, PIN, контрольный вопрос;
• владение: телефон, токен, аппаратный ключ, доверенное устройство;
• свойство: лицо, голос, отпечаток, поведенческий паттерн.

Корректная MFA-схема берет факторы из разных классов. Пароль плюс PIN — не MFA в техническом смысле. Это два знания. SMS плюс звонок на тот же номер — тоже слабая конструкция. Оба фактора завязаны на один операторский канал.

Для цифрового банка практичная схема выглядит иначе: пароль или PIN открывает приложение, доверенное устройство подписывает запрос, биометрия разблокирует локальный ключ, сервер проверяет риск сессии. Подтверждение операции строится не только на факте «клиент нажал кнопку», а на криптографической связке: устройство, ключ, конкретная транзакция, сумма, получатель.

Сравнение по устойчивости:

Биометрия в KYC стала стандартным элементом удаленного открытия счета. Лицо, голос, отпечаток, liveness detection, сверка документа и селфи — это снижает фрод при онбординге. Но биометрия не является абсолютной защитой. Шаблон лица нельзя «сменить» как пароль. Если он утек, проблема становится долгой.

Правильная архитектура не хранит исходное изображение как фактор доступа. Нужны шаблоны, хэширование там, где применимо, шифрование на уровне поля, изоляция ключей, контроль доступа, журналирование обращений. Для биометрии особенно критичны liveness-проверки: моргание, поворот головы, глубина, текстура, анализ отражений, признаки воспроизведения с экрана. Дипфейки и presentation attacks уже не лабораторная тема.

PCI DSS 4.0: безопасность как процесс, а не ежегодный ритуал

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

Суть не в том, чтобы «пройти PCI». Суть в том, чтобы уменьшить область, где вообще существуют чувствительные данные. Это архитектурная задача.

Базовые меры:

• сегментация CDE — карточная среда не должна смешиваться с общей инфраструктурой;
• токенизация PAN — внутренние сервисы работают с токеном, а не с номером карты;
• шифрование при передаче и хранении — без исключений для внутренних API;
• минимизация доступа — сервис получает только те поля, которые нужны для функции;
• ротация ключей — без ручных процедур и «вечных» секретов;
• контроль уязвимостей — сканирование, патчи, проверка конфигураций;
• журналирование — неизменяемые логи доступа к платежным данным;
• тестирование на проникновение — не презентация для аудита, а техническая проверка сегментации и прав.

PCI DSS 4.0 особенно неприятен для организаций, где карточные данные расползлись по логам, аналитике, BI-выгрузкам, саппорт-инструментам и тестовым средам. Там формальная сертификация превращается в дорогое упражнение. Приходится чистить архитектуру.

Чем меньше систем видят PAN, тем дешевле безопасность. Это не лозунг, а математика PCI-контура.

Для необанков и финтех-платформ типичная ошибка — быстрый запуск карточного продукта через внешнего провайдера без строгого контроля downstream-сервисов. В момент запуска все выглядит чисто: провайдер сертифицирован, API документирован, токены есть. Через год данные появляются в аналитике, клиентской поддержке, A/B-тестах, логах ошибок. Контур расширяется без решения архитектора. Потом это обнаруживает аудит.

ИИ-антифрод: полезен там, где есть данные и обратная связь

Машинное обучение в банковском антифроде нужно не для вывески. Оно работает, когда есть поток событий, нормальная разметка, низкая задержка и feedback loop. Без этого модель становится черным ящиком, который либо пропускает фрод, либо блокирует клиентов.

Антифрод в реальном времени обычно строится на нескольких слоях:

1. Правила.

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

2. Скоринговая модель.

Считает риск операции по признакам. Устройство, IP, ASN, время, сумма, частота переводов, история получателей, возраст аккаунта, канал входа, состояние KYC.

3. Графовый анализ.

Ищет связи между счетами, устройствами, картами, номерами телефонов, IP-адресами, получателями. Полезен для дроп-сетей и серийных атак.

4. Поведенческая биометрия.

Смотрит на скорость ввода, траекторию касаний, привычки навигации, давление на экран, ритм действий. Это не фактор входа, а сигнал риска.

5. Решающий слой.

Выбирает действие: пропустить, запросить дополнительный фактор, задержать, отправить на ручную проверку, заблокировать.

Ключевой параметр — задержка. Если система считает риск 30 секунд, она не подходит для массового платежного сценария. Если считает быстро, но без контекста, она пропускает сложные цепочки. Баланс зависит от продукта: карточные операции, P2P, СБП, кредитный онбординг, выпуск виртуальной карты — разные профили.

ИИ-антифрод особенно полезен против аномалий, которые не укладываются в статические правила. Например: клиент обычно платит с одного устройства, но теперь входит с нового Android, через мобильную сеть другого региона, сразу повышает лимит, добавляет получателя и делает перевод дробными суммами. Каждое событие отдельно может быть допустимым. Последовательность — нет.

Но модель не заменяет контроль. Ей нужны:

• чистая схема событий;
• единые идентификаторы клиента, устройства и сессии;
• защита от подмены device fingerprint;
• разметка подтвержденного фрода;
• механизм апелляции и пересмотра;
• мониторинг drift модели;
• ограничения на автоматическое решение по спорным операциям.

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

Удаленная идентификация: KYC-шлюз должен быть частью защиты, а не формой регистрации

KYC часто рассматривают как входную анкету. Это ошибка. Удаленная идентификация — один из главных шлюзов риска. Через него проходят синтетические личности, поддельные документы, deepfake-видео, stolen identity, дропы и повторные регистрации.

Рабочий KYC-контур включает несколько проверок:

• подлинность документа и признаки редактирования;
• сверку данных документа с внешними источниками, если это разрешено юрисдикцией;
• liveness detection при съемке лица;
• сравнение лица с документом;
• проверку устройства и IP;
• поиск повторов по биометрическим и поведенческим признакам;
• санкционные и AML-проверки;
• связку KYC-события с последующим транзакционным поведением.

Последний пункт часто выпадает. Клиент может пройти KYC без явных признаков фрода, а затем начать действовать как дроп: принимать входящие переводы, быстро выводить средства, использовать однотипных получателей, работать с нескольких устройств. Если KYC-система не передает признаки в антифрод, банк теряет контекст.

KYC-шлюз должен отдавать не только бинарный результат «прошел / не прошел». Нужен risk score: качество документа, уверенность биометрического совпадения, признаки повторной регистрации, риск устройства, риск канала, результат liveness. Эти признаки затем используются в лимитах, задержках, step-up-проверках.

Технически это выглядит как цепочка API: фронт собирает данные, KYC-провайдер делает проверку, банк сохраняет только необходимый минимум, risk engine получает признаки, IAM назначает уровень доверия, продуктовая система выставляет лимиты. Если эта цепочка разорвана, KYC остается отдельной витриной.

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

Что усиливать в первую очередь

Приоритеты зависят от зрелости банка. Но есть порядок, который обычно дает максимальный эффект без иллюзий.

Первый слой: доступ

Здесь закрывается захват учетной записи. Нужны MFA, риск-ориентированная аутентификация, контроль нового устройства, защита сброса пароля, ограничения на массовые попытки входа, детектирование credential stuffing.

Отдельный фокус — сотрудники. Внутренний доступ должен быть сильнее клиентского. Администраторы, операторы поддержки, аналитики, разработчики, подрядчики — разные уровни риска. Для привилегированных ролей пароль и SMS недопустимы. Нужны аппаратные ключи или фишинг-устойчивые методы, PAM, JIT-доступ, запись сессий, контроль команд.

Второй слой: данные

Здесь сокращается ущерб от утечки. Персональные данные, платежные данные, биометрия и документы должны жить в разных хранилищах и режимах доступа. Логи не должны содержать PAN, CVV, полные документы, токены с возможностью повторного использования.

Нужны DLP, маскирование, шифрование, KMS/HSM, контроль экспортов, политики retention. Но без инвентаризации данных эти инструменты работают частично. Сначала надо знать, где данные лежат.

Третий слой: транзакции

Здесь ловится фрод после входа. Risk engine должен анализировать операции до исполнения. Не после выгрузки в отчет. Режим near real-time для платежей недостаточен, если деньги уходят мгновенно.

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

Четвертый слой: каналы коммуникации

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

DMARC, DKIM, SPF, мониторинг фишинговых доменов, контроль мобильных приложений-клонов, push-уведомления с контекстом операции — базовый набор. Но он работает только при дисциплине коммуникаций.

Пятый слой: реагирование

Инцидент неизбежен. Вопрос — сколько времени система будет считать его нормой. Нужны playbook-и по ATO, фишингу, утечке, компрометации ключей, подозрительной KYC-волне, массовым переводам на дропов.

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

Где технологии не закрывают риск

Биометрия не дает 100% защиты. Дипфейки, replay-атаки, маски, подделка голоса, атаки на сенсор, компрометация устройства — реальные сценарии. Поэтому биометрия должна быть одним из сигналов, а не единственным замком.

2FA тоже не абсолютна. Push fatigue работает просто: пользователь получает серию запросов и подтверждает один из них. SMS перехватывается. Почта компрометируется. Устройство заражается. Поэтому MFA должна быть связана с транзакцией. Подтверждение «войти» слабее, чем подтверждение «перевести 50 000 рублей получателю X».

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

PCI DSS 4.0 не защищает весь банк. Он закрывает область платежных карт. ISO/IEC 27001 дает систему управления информационной безопасностью, но не заменяет конкретные технические контроли. Сертификат не блокирует фишинговый перевод.

Скептический подход здесь полезен. Каждый контроль надо проверять вопросом: что произойдет, если пользователь передал пароль и код? Что произойдет, если устройство заражено? Что произойдет, если оператор поддержки ошибся? Что произойдет, если KYC прошел дроп? Если ответа нет, контроль декоративный.

Практическая матрица усиления

Для банка или финтех-платформы удобнее смотреть на защиту не по названиям продуктов, а по точкам атаки.

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

Стоимость внедрения: платить придется за связность

Основная стоимость кибербезопасности в цифровом банке — не лицензия. Стоимость в интеграции. Надо связать IAM, мобильное приложение, карточный процессинг, KYC, CRM, антифрод, SIEM, DWH, контакт-центр и SOC. Разные команды. Разные SLA. Разные владельцы данных.

Быстро покупается только точечный контроль. Например, новый KYC-провайдер или MFA-шлюз. Но если события не уходят в risk engine, а результаты не влияют на лимиты, эффект ограничен. Если антифрод не видит звонок в поддержку перед переводом, он теряет сигнал. Если SIEM не получает события из мобильного приложения, расследование начинается с дырой в таймлайне.

Поэтому план усиления должен идти от критичных сценариев:

• вход в аккаунт;
• сброс пароля;
• регистрация устройства;
• открытие счета;
• выпуск карты;
• добавление получателя;
• перевод на нового получателя;
• изменение лимитов;
• обращение в поддержку;
• закрытие и разблокировка аккаунта.

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

Финальный технический ориентир простой. Кибербезопасность банков в 2024 году держится на связке: MFA, токенизация, сегментация данных, PCI DSS 4.0 для карточного контура, KYC с liveness, антифрод в реальном времени, контроль социальной инженерии и готовое реагирование. Отдельный элемент не решает задачу. Система работает только как цепь.

Слабое звено почти всегда находится не там, где самый сложный криптографический модуль. Оно находится на стыке: между KYC и лимитами, между поддержкой и антифродом, между мобильным приложением и SIEM, между карточным токеном и логами. Усиление начинается с этих стыков. Там же обычно лежит основной риск и основная стоимость внедрения.