Введение

Аннотация.

Системы банк-клиент и защищённого удалённого доступа являются критической инфраструктурой современного банка. Они обеспечивают безопасное взаимодействие клиентов и сотрудников с банковскими сервисами через недоверенные сети. Курс раскрывает полный цикл проектирования, внедрения и эксплуатации таких систем с учётом требований ЦБ РФ, ФСТЭК и ГОСТ. Особое внимание уделяется криптографической защите, аутентификации, управлению ключами и противодействию актуальным угрозам. Материал ориентирован на практиков, которые должны не просто знать теорию, а уметь строить и сопровождать защищённые каналы.

Цель курса.

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

Для кого этот курс.

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

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

Основы дистанционного банковского обслуживания и банк-клиента

Дистанционное банковское обслуживание (ДБО) представляет собой комплекс технологий, позволяющих клиенту совершать банковские операции без посещения отделения. Классический банк-клиент — это толстый или тонкий клиент, устанавливаемый на рабочее место пользователя и взаимодействующий с сервером банка по защищённому каналу. Современные реализации включают интернет-банк, мобильный банк, корпоративный банк-клиент и API-шлюзы для партнёров.

Ключевое отличие банковских систем от обычных веб-сервисов — требование непрерывной криптографической защиты всего сеанса и обязательное применение средств криптографической защиты информации (СКЗИ), сертифицированных ФСБ или ФСТЭК. При проектировании необходимо сразу закладывать модель угроз по ГОСТ Р 56939 и требования Положения Банка России 719-П.

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

Основные компоненты типовой системы банк-клиент: клиентское приложение (или веб-интерфейс), шлюз безопасности, сервер приложений, криптографический модуль (HSM или программный СКЗИ), система управления ключами и сертификатами, модуль аудита и журналирования. Каждый компонент должен быть размещён в своей зоне безопасности согласно модели Zero Trust или классической сегментации DMZ.

Важнейший принцип — разделение каналов управления и каналов данных. Канал управления (выпуск сертификатов, смена паролей, блокировка пользователей) всегда должен проходить через более жёсткий контур контроля, часто с обязательным участием сотрудника банка. Канал данных (платежи, выписки) может быть автоматизирован, но обязан обеспечивать целостность и неотказуемость.

Рекомендуемый стек для нового проекта 2025–2026 годов: серверная часть на Java/Spring Boot или .NET с использованием ГОСТ-криптопровайдеров, клиент — Electron или нативный с встроенной поддержкой Рутокен/JaCarta, канал — TLS 1.3 с ГОСТ-шифронаборами либо VPN на базе ГОСТ VPN.

Классификация систем банк-клиент по уровню защиты и целевой аудитории. Для физических лиц чаще всего применяется интернет-банк с SMS/push-подтверждением и опциональным аппаратным токеном. Для юридических лиц и корпоративных клиентов обязателен квалифицированный сертификат электронной подписи и, как правило, толстый клиент или специализированный веб-клиент с поддержкой СКЗИ.

Отдельный класс — системы для казначейств и крупных корпораций, где требуется интеграция с 1С, SAP и системами электронного документооборота. Здесь критически важна поддержка пакетной обработки платежей и многоуровневого подтверждения (несколько подписей по схеме «двое из трёх»).

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

Жизненный цикл системы банк-клиент включает этапы: сбор требований и моделирование угроз, проектирование архитектуры безопасности, выбор и сертификация СКЗИ, разработка/внедрение, аттестация по требованиям ФСТЭК/ЦБ, ввод в промышленную эксплуатацию, сопровождение и регулярный аудит. Каждый этап должен завершаться формальным документом (акт, протокол, заключение).

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

Инструмент для управления жизненным циклом: внутренний реестр информационных систем банка с обязательными полями «уровень критичности», «применённые СКЗИ», «дата последней аттестации», «ответственный за безопасность».

Архитектура систем защищённого удалённого доступа

Архитектура защищённого удалённого доступа в банковской среде строится на принципе многоуровневой защиты. Классическая схема включает: клиентский сегмент (рабочее место пользователя), канал связи (публичный интернет или выделенные линии), периметровый шлюз (VPN-концентратор или TLS-терминатор), демилитаризованную зону (DMZ) с прокси и антивирусными шлюзами, внутренний сегмент приложений и сегмент хранения данных.

Современный подход — переход к модели Zero Trust Access. В этой модели нет понятия «доверенной сети». Каждый запрос аутентифицируется и авторизуется заново, а доступ выдаётся по принципу наименьших привилегий на основе контекста (устройство, местоположение, поведение пользователя, время суток).

Практическая рекомендация: даже если вы пока не готовы к полноценному Zero Trust, внедрите как минимум проверку состояния клиентского устройства (наличие актуальных обновлений ОС, запущенного антивируса, отсутствия jailbreak/root) перед установкой защищённого канала.

Ключевые архитектурные решения при построении систем защищённого удалённого доступа: выбор между SSL/TLS VPN и IPsec VPN, размещение криптографических модулей (программный СКЗИ на сервере приложений vs аппаратный HSM), использование выделенных каналов (МPLS, выделенные линии) или защита через публичный интернет.

Для банк-клиента чаще всего применяется TLS-туннель с взаимной аутентификацией (mTLS) и ГОСТ-шифронаборами. IPsec остаётся актуальным для связи между площадками банка и для подключения удалённых офисов. При выборе решения обязательно проверяйте наличие сертификата ФСБ на используемое СКЗИ и соответствие требованиям Положения 719-П.

Типичная ошибка — использование одного и того же VPN-концентратора для сотрудников банка и для клиентов. Эти потоки должны быть физически или логически разделены, потому что модели угроз и требования к журналированию у них принципиально разные.

Сегментация сети — обязательный элемент архитектуры. Минимально необходимые зоны: зона публичного доступа (веб-серверы интернет-банка), зона шлюзов безопасности, зона серверов приложений ДБО, зона баз данных, зона управления ключами (отдельный сегмент с HSM), зона мониторинга и SIEM. Между зонами должны стоять межсетевые экраны с правилами «запрещено всё, что явно не разрешено».

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

Инструменты: Cisco ASA / Firepower, Check Point, UserGate, Ideco, а также отечественные решения ViPNet Coordinator и Континент. При выборе обращайте внимание на поддержку ГОСТ и наличие сертификатов ФСТЭК.

Высокая доступность и отказоустойчивость систем защищённого удалённого доступа. Банковские системы не могут останавливаться. Поэтому архитектура должна предусматривать кластеризацию VPN-шлюзов, резервирование каналов связи, географически распределённые площадки и автоматическое переключение (failover).

Криптографические ключи и сертификаты должны быть доступны на всех узлах кластера. Это решается либо через централизованный HSM с сетевым доступом, либо через репликацию контейнеров ключей с жёстким контролем. При проектировании обязательно закладывайте RTO (время восстановления) и RPO (точку восстановления) в соответствии с требованиями бизнес-подразделений.

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

Криптографическая защита канала связи

Основой защищённого удалённого доступа является криптографическая защита канала. В Российской Федерации для банковских систем обязательным является применение алгоритмов ГОСТ. Основные стандарты: ГОСТ Р 34.12-2015 (блокичные шифры «Кузнечик» и «Магма»), ГОСТ Р 34.13-2015 (режимы работы), ГОСТ Р 34.10-2012 (электронная подпись), ГОСТ Р 34.11-2012 (хеш-функция «Стрибог»).

Протокол TLS 1.2/1.3 с ГОСТ-шифронаборами — основной способ защиты веб-интерфейсов интернет-банка и API. Для этого используются сертифицированные криптопровайдеры: КриптоПро CSP, ViPNet CSP, Signal-COM CSP и другие. На стороне сервера чаще всего применяется КриптоПро NGate или аналогичные TLS-терминаторы.

Важный нюанс: при использовании ГОСТ в TLS необходимо следить за совместимостью клиентских и серверных реализаций. Не все браузеры «из коробки» поддерживают ГОСТ. Поэтому для корпоративных клиентов часто применяют либо специализированные браузеры, либо плагины, либо толстые клиенты.

Взаимная аутентификация (mutual TLS) — обязательный элемент для систем банк-клиент высокого уровня защиты. Клиент предъявляет свой сертификат, сервер — свой. Только после успешной двусторонней проверки устанавливается защищённый канал. Это исключает атаки типа man-in-the-middle даже при компрометации DNS или маршрутизации.

Сертификаты клиентов выпускаются либо собственным удостоверяющим центром банка, либо аккредитованным УЦ. Для юридически значимых операций требуется квалифицированная электронная подпись (КЭП). Сертификат должен содержать необходимые расширения (keyUsage, extendedKeyUsage) и быть привязан к конкретному пользователю или роли.

Практика управления: срок действия клиентских сертификатов обычно устанавливают 1–2 года. Обязательно реализуйте механизм автоматического или полуавтоматического перевыпуска с уведомлением пользователя заранее. Потеря доступа из-за истекшего сертификата — одна из самых частых причин обращений в поддержку.

Аппаратные средства криптографической защиты (токены, смарт-карты, HSM) значительно повышают уровень безопасности по сравнению с программными контейнерами. Наиболее распространённые в банковской среде: Рутокен ЭЦП, JaCarta ГОСТ, ESMART Token, а также серверные HSM — КриптоПро HSM, ViPNet HSM, Thales Luna (с поддержкой ГОСТ через доверенные модули).

При выборе токена обращайте внимание на наличие сертификата ФСБ, поддержку ГОСТ Р 34.10-2012, возможность работы без драйверов (CCID) и наличие защищённого PIN-кода с блокировкой после нескольких неверных попыток. Для массового клиента иногда применяют облачную электронную подпись, однако она имеет ограничения по юридической значимости и модели угроз.

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

Управление криптографическими ключами — один из самых сложных и критичных процессов. Жизненный цикл ключа включает генерацию, распределение, хранение, использование, ротацию, резервное копирование и уничтожение. Все операции должны журналироваться, а доступ к ключам — строго разграничиваться по ролям.

Для генерации ключей электронной подписи рекомендуется использовать аппаратные датчики случайных чисел (ДСЧ), сертифицированные ФСБ. Программные генераторы на основе /dev/urandom или стандартных библиотек не всегда удовлетворяют требованиям регуляторов для квалифицированной подписи.

Рекомендуемый подход: централизованная система управления ключами (KMS) с интеграцией в HSM. Все запросы на создание, использование и уничтожение ключей проходят через KMS и фиксируются в неизменяемом журнале. Это сильно упрощает прохождение аудитов ЦБ и ФСТЭК.

Аутентификация и управление доступом

Аутентификация в системах банк-клиент почти никогда не ограничивается одним фактором. Минимальный приемлемый уровень — двухфакторная аутентификация (2FA): что-то, что пользователь знает (пароль/PIN), и что-то, что у него есть (токен, смарт-карта, OTP-приложение, SMS). Для операций высокого риска добавляют третий фактор — биометрию или подтверждение через отдельный канал.

Современные реализации всё чаще отходят от SMS в сторону push-уведомлений в мобильном приложении банка или аппаратных OTP-токенов. SMS уязвима к SIM-swap атакам и перехвату. Банк России неоднократно рекомендовал снижать зависимость от SMS-подтверждений.

Практика: внедряйте адаптивную аутентификацию. Система анализирует контекст (IP-адрес, устройство, время, геолокацию, поведение) и решает, достаточно ли текущих факторов или нужно запросить дополнительное подтверждение. Это снижает трение для легитимных пользователей и повышает защиту при аномалиях.

Управление доступом строится на ролевой модели (RBAC) с элементами атрибутного контроля (ABAC). Каждому пользователю назначается роль (клиент-физлицо, бухгалтер, директор, казначей, администратор безопасности), а роли — набор разрешённых операций и лимитов. Для корпоративных клиентов часто требуется схема множественных подписей: платёж становится возможным только после сбора необходимого количества электронных подписей.

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

Инструменты: встроенные модули банка-клиента, IdM-системы (One Identity, Avanpost, Blitz Identity), интеграция с Active Directory / FreeIPA для сотрудников банка.

Блокировка и разблокировка доступа — критически важный процесс. Система должна автоматически блокировать учётную запись после заданного числа неудачных попыток входа, при обнаружении компрометации, при истечении срока действия сертификата или по запросу клиента/сотрудника банка. Разблокировка должна происходить только после надёжной идентификации пользователя (через отделение, видеозвонок, контрольные вопросы + документы).

Обязательно реализуйте «горячую» блокировку: клиент должен иметь возможность самостоятельно заблокировать доступ через мобильное приложение, колл-центр или СМС-команду. Время реакции на такую блокировку измеряется минутами, а не часами.

Журналирование всех событий аутентификации и изменения прав доступа должно быть неизменяемым и храниться не менее срока, установленного регулятором (обычно 5 лет и более).

Единый вход (SSO) и федеративная аутентификация в банковской среде применяются осторожно. Для сотрудников банка SSO с корпоративным каталогом — стандарт. Для клиентов банка полноценный SSO с внешними IdP почти не используется из-за регуляторных ограничений и рисков. Однако внутри экосистемы банка (интернет-банк + мобильный банк + личный кабинет на сайте) единая сессия и бесшовный переход между каналами — ожидаемый уровень сервиса.

При реализации SSO необходимо обеспечить корректное завершение всех сессий при выходе и защиту от session fixation. Токены сессии должны быть короткоживущими, привязанными к устройству и защищёнными от кражи (HttpOnly, Secure, SameSite cookies либо хранение в защищённом хранилище приложения).

Нормативно-правовое регулирование и требования регуляторов

Основным регулятором в области информационной безопасности банков является Банк России. Ключевые документы: Положение 719-П «О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств», Положение 683-П, Указание 4926-У, а также стандарты СТО БР ИББС. Эти документы устанавливают обязательные требования к защите каналов ДБО, применению СКЗИ, журналированию и реагированию на инциденты.

ФСТЭК России регулирует вопросы защиты информации ограниченного доступа и аттестации объектов информатизации. Для систем, обрабатывающих персональные данные и сведения, составляющие банковскую тайну, требуется выполнение требований приказов ФСТЭК № 17, № 21 и прохождение аттестации.

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

ГОСТ Р 57580.1-2017 «Безопасность финансовых (банковских) операций» и связанные с ним стандарты задают базовый уровень защиты для финансовых организаций. Они содержат требования к организационным мерам, защите инфраструктуры, управлению доступом, криптографической защите и мониторингу.

При проектировании системы банк-клиент необходимо провести оценку соответствия выбранных технических решений требованиям этих стандартов. Часто требуется привлечение лицензиатов ФСТЭК и ФСБ для проведения аудита и подготовки заключения.

Практика: создайте матрицу соответствия «требование регулятора — реализованная мера — подтверждающий документ». Такая матрица существенно упрощает взаимодействие с аудиторами ЦБ и внешними проверяющими.

Требования к юридической значимости электронных документов. Для того чтобы электронный платёж имел ту же юридическую силу, что и бумажный, необходимо применение квалифицированной электронной подписи (КЭП) в соответствии с 63-ФЗ «Об электронной подписи». Сертификат КЭП должен быть выдан аккредитованным удостоверяющим центром, а средство электронной подписи — сертифицировано ФСБ.

Банк обязан обеспечить проверку всех реквизитов сертификата, статуса отзыва (через OCSP или CRL) и корректности подписи перед исполнением операции. Результаты проверки должны сохраняться в неизменяемом виде вместе с самим документом.

Важный момент: при использовании облачной электронной подписи (когда ключ хранится у оператора) необходимо тщательно проанализировать договор и модель угроз. Не все виды облачной подписи признаются судами как полноценная КЭП.

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

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

Модель угроз и актуальные атаки

Модель угроз для систем банк-клиент и защищённого удалённого доступа должна строиться в соответствии с ГОСТ Р 56939 и методическими документами ФСТЭК. Основные категории угроз: компрометация клиентского устройства, перехват и подмена трафика, атаки на серверную инфраструктуру, социальная инженерия, инсайдерские угрозы, атаки на цепочку поставок СКЗИ и ПО.

Особую опасность представляют целевые атаки (APT), направленные на кражу средств через системы ДБО. Классический сценарий: заражение рабочей станции бухгалтера трояном-банкером, перехват сессии или подмена платёжного поручения, вывод средств на подставные счета с последующим обналичиванием.

При построении модели угроз обязательно учитывайте актуальные бюллетени ФинЦЕРТ Банка России. Они содержат описание реальных схем атак и рекомендации по противодействию.

Атаки на канал связи. Несмотря на применение TLS и VPN, остаются риски, связанные с неправильной конфигурацией (слабые шифронаборы, устаревшие протоколы, отсутствие проверки сертификатов), компрометацией центров сертификации, атаками на DNS и BGP. Поэтому рекомендуется применять certificate pinning на клиенте, мониторинг прозрачности сертификатов (Certificate Transparency) и использование DNSSEC там, где это возможно.

Отдельный класс угроз — атаки на конечные точки VPN и TLS-терминаторов. Уязвимости в ПО шлюзов неоднократно приводили к массовым компрометациям. Поэтому критически важно своевременно устанавливать обновления безопасности и иметь процедуру экстренного патчинга.

Социальная инженерия и фишинг остаются одним из самых эффективных способов компрометации. Злоумышленники создают поддельные сайты интернет-банка, рассылают письма с вредоносными вложениями, звонят от имени службы безопасности банка. Технические меры защиты (антифишинг, DMARC, фильтрация) должны дополняться регулярным обучением клиентов и сотрудников.

Практика: внедряйте «кнопку тревоги» в интерфейсе банк-клиента, по которой пользователь может мгновенно сообщить о подозрительном звонке или письме. Также полезны уведомления о входе с нового устройства и о попытках изменения реквизитов.

Инсайдерские угрозы. Сотрудник банка или подрядчик с легитимным доступом может нанести ущерб, сопоставимый с внешней атакой. Меры противодействия: принцип наименьших привилегий, разделение обязанностей, мониторинг привилегированных сессий (PAM), запись действий администраторов, регулярный анализ логов на аномалии.

Особое внимание — к учётным записям сервисных учётных записей и учётным записям с доступом к HSM и системам управления ключами. Эти учётные записи должны быть максимально ограничены и находиться под усиленным контролем.

Средства криптографической защиты информации

СКЗИ — основа защиты банковских систем в России. Все применяемые средства должны иметь действующий сертификат ФСБ России. Основные классы: программные криптопровайдеры (КриптоПро CSP, ViPNet CSP, Signal-COM CSP), аппаратные токены и смарт-карты, сетевые шлюзы (КриптоПро NGate, ViPNet Coordinator, Континент), аппаратные модули безопасности HSM.

При выборе СКЗИ необходимо учитывать: класс защиты (КС1, КС2, КС3, КВ), поддерживаемые алгоритмы, производительность, наличие API для интеграции, сроки действия сертификата и возможность получения обновлений. Для систем, обрабатывающих информацию ограниченного доступа, часто требуется класс не ниже КС2 или КС3.

Интеграция СКЗИ в приложения. Большинство современных банк-клиентов используют стандартные интерфейсы: CryptoAPI / CNG (Windows), PKCS#11, либо собственные API производителя (КриптоПро API). Для кроссплатформенных решений часто применяют обёртки над PKCS#11 или встроенные криптопровайдеры.

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

Рекомендация: абстрагируйте криптографический слой в отдельный модуль приложения. Это позволит при необходимости заменить одного производителя СКЗИ на другого без переписывания всей бизнес-логики.

Эксплуатация СКЗИ. Каждое сертифицированное средство имеет формуляр и правила пользования, которые необходимо строго соблюдать. Нарушение правил (например, установка неподдерживаемой версии ОС или использование в непредусмотренной конфигурации) может привести к потере статуса защищённости.

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

Обновление и миграция СКЗИ. Сертификаты ФСБ имеют ограниченный срок действия. Кроме того, появляются новые версии алгоритмов и протоколов. Банк должен иметь план миграции на новые версии СКЗИ с минимальным простоем сервисов. Миграция обычно включает: тестирование совместимости, выпуск новых сертификатов, обновление клиентских компонентов, параллельную работу старого и нового контуров в переходный период.

Практика показывает, что миграцию лучше начинать за 12–18 месяцев до окончания срока действия текущего сертификата. Иначе можно оказаться в ситуации, когда критический сервис внезапно становится несоответствующим требованиям.

Построение и настройка защищённого канала

Настройка TLS с ГОСТ-шифронаборами. На сервере необходимо установить сертифицированный TLS-терминатор (например, КриптоПро NGate или nginx с модулем КриптоПро). В конфигурации указываются только разрешённые шифронаборы (GOST2012-GOST8912-GOST8912 и аналогичные), отключаются устаревшие протоколы (SSLv3, TLS 1.0, TLS 1.1), включается обязательная проверка клиентских сертификатов при необходимости.

На стороне клиента — либо встроенная поддержка в специализированном ПО, либо плагин для браузера, либо использование системного криптопровайдера. Обязательно проверяйте цепочку сертификатов до доверенного корневого УЦ и срок действия.

Инструмент проверки: openssl s_client с поддержкой ГОСТ (через КриптоПро) или специализированные утилиты производителей СКЗИ.

Построение VPN на базе ГОСТ. Для связи офисов и для доступа сотрудников часто применяются решения ViPNet, Континент, S-Terra. Они обеспечивают шифрование на сетевом уровне и могут работать как в режиме точка-точка, так и в режиме клиент-сервер.

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

Совет: разделяйте VPN-контуры для разных категорий пользователей и не используйте один и тот же концентратор для доступа к промышленным и тестовым системам.

Проверка корректности настройки защищённого канала. После развёртывания необходимо провести тестирование: проверка согласованных алгоритмов, тест на устойчивость к известным атакам (BEAST, POODLE, ROBOT — хотя для ГОСТ они частично неприменимы), проверка производительности под нагрузкой, тест на корректную обработку отозванных сертификатов.

Рекомендуется использовать как автоматизированные сканеры (если они поддерживают ГОСТ), так и ручное тестирование с помощью тестовых клиентов и средств анализа трафика (Wireshark с диссекторами ГОСТ).

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

Настройте алерты на критические события: массовые неудачные попытки установления канала, появление соединений с неожиданных IP-адресов, истечение срока действия серверных сертификатов в ближайшие 30 дней.

Журналирование, мониторинг и реагирование на инциденты

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

Журналы должны передаваться в централизованную систему (SIEM) в режиме, близком к реальному времени, и храниться в неизменяемом виде. Срок хранения определяется требованиями ЦБ и внутренними политиками, но обычно составляет не менее 5 лет.

Интеграция с SIEM и SOC. События от систем ДБО должны обогащаться данными из других источников (антивирус, межсетевые экраны, системы предотвращения утечек) и обрабатываться правилами корреляции. Типичные сценарии: множественные неудачные попытки входа с последующим успешным входом, платёж сразу после смены реквизитов, вход с нового устройства в необычное время.

Для банков критически важна интеграция с ФинЦЕРТ. Многие инциденты требуют оперативного обмена информацией с регулятором и другими участниками финансового рынка.

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

Регулярно проводите киберучения (table-top и практические), имитирующие компрометацию банк-клиента. Это позволяет выявить слабые места в процедурах и обучить персонал.

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

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