Обеспечение информационной безопасности банка

Банк — одна из самых привлекательных целей для киберпреступников: на кону деньги клиентов, платёжные каналы и персональные данные. Поэтому обеспечение информационной безопасности банка строится как многоуровневая система, где сбои на любом участке — от периметра до сотрудника с доступом к базе — оборачиваются реальными потерями. Разбираем, как эта система устроена изнутри: какие зоны ответственности закреплены за подразделениями ИБ, что банк обязан защищать по закону и стандартам ЦБ, и какие инструменты — антифрод, СКУД, DLP, SIEM — применяются на практике.

Отдельно остановимся на защите клиентских данных и каналов ДБО: шифровании и токенизации, которые снижают риск утечки даже при компрометации отдельных узлов. Покажем, как выстроить защиту периметра и внутренних систем, что происходит после кибератаки — по какому регламенту и в какие сроки банк уведомляет ЦБ, куда обращаться при инциденте (ЦБ, ФинЦЕРТ, Роскомнадзор, полиция). В финале — как проверить и усилить защиту через аудит, пентест и обучение персонала, чтобы система работала не на бумаге, а в реальных условиях.

Как устроена защита банка: контур ИБ и зоны ответственности

Защита банка строится не как одна стена, а как несколько вложенных контуров, каждый со своим владельцем и своим набором мер. Внешний контур — периметр сети: межсетевые экраны, защита от DDoS, фильтрация трафика, сегментация на DMZ. Средний контур — прикладные системы: АБС, процессинг карт, ДБО, антифрод. Внутренний контур — рабочие места сотрудников, админские доступы, кассовые узлы, хранилища ключей. Отдельно стоит контур данных: базы клиентской информации, платёжные реквизиты, кредитные истории.

Зоны ответственности распределены жёстко, и это принципиально для устойчивости. За периметр и инфраструктуру отвечает подразделение ИБ и ИТ-эксплуатация. За бизнес-риски — владельцы процессов: розничный блок, кредитный департамент, казначейство. За соответствие требованиям регулятора — комплаенс и внутренний контроль. Персональную ответственность несёт куратор ИБ в правлении, а итоговую — совет директоров и CEO. Размытая ответственность — первая причина, по которой защита разваливается: каждый считает, что «за ИБ отвечает безопасник».

Ключевой принцип — эшелонированность (defense in depth). Ни один контроль не считается достаточным сам по себе: если обошли антивирус, сработает сегментация; если скомпрометировали учётку — упрётся в двухфакторную аутентификацию и PAM-хранилище привилегированных доступов. Второй принцип — минимальные привилегии: сотрудник видит только то, что нужно для его функции, а админский доступ выдаётся на время и под задачу. Третий — разделение обязанностей: тот, кто настраивает систему, не должен единолично закрывать по ней инциденты.

Практически контур ИБ описывается моделью нулевого доверия (Zero Trust): ни одна сеть, устройство или пользователь не считаются «своими» по умолчанию. Каждый запрос к системе проверяется заново — по устройству, учётке, геолокации, времени, поведению. Для клиента это означает простую вещь: подозрительный вход в ДБО с нового устройства или из другого региона банк не пропустит молча, а запросит подтверждение. Это не паранойя, а базовая логика современной защиты.

Что банк обязан защищать по закону и стандартам ЦБ

Обязанности банка по защите информации вытекают из нескольких слоёв регулирования. Первый — 152-ФЗ «О персональных данных»: банк выступает оператором и обязан обеспечить конфиденциальность, целостность и доступность ПДн клиентов, а при утечке — уведомить Роскомнадзор. Второй — 161-ФЗ «О национальной платёжной системе»: требования к защите информации при переводах денежных средств. Третий — 115-ФЗ в части противодействия легализации и антифрод-мероприятий. Четвёртый — отраслевые документы Банка России: ГОСТ 57580.1 (состав организационных и технических мер), положение 683-П (защита информации в платёжных приложениях и ДБО), положение 719-П (защита в кредитных организациях).

ГОСТ 57580 задаёт уровни защиты: минимальный, стандартный и усиленный. Уровень выбирается по масштабу бизнеса и значимости объекта, но для банковской сферы фактически всегда требуется не ниже стандартного, а для значимых систем — усиленный. Оценка соответствия проводится по ГОСТ 57580.2 — это не декларация, а проверяемая процедура с оценкой соответствия и последующей регулярной переоценкой. Соответствие подтверждается документально и проверяется в рамках надзора.

Отдельный слой — требования к устойчивости к компьютерным атакам: банк обязан иметь процессы выявления, реагирования и информирования регулятора об инцидентах. Значимые инциденты передаются в ФинЦЕРТ — центр мониторинга и реагирования на компьютерные атаки в кредитно-финансовой сфере Банка России. Сроки и форматы уведомлений регламентированы, и их нарушение — самостоятельное нарушение, даже если сам инцидент был быстро закрыт.

Что это значит для клиента: банк не может «забыть» про защиту — это не добрая воля, а лицензионное требование. Если банк систематически нарушает требования ИБ, регулятор вправе применить меры вплоть до ограничения операций. Поэтому проверка банка начинается не с его рекламы, а с официальных реестров на сайте Банка России (cbr.ru, раздел «Реестры»): компании нет в реестре — значит, она работает нелегально и передавать ей деньги нельзя. Тот же принцип действует и для МФО — легальная организация обязана состоять в государственном реестре ЦБ РФ, а выдача займов вне реестра незаконна.

Какие инструменты ИБ применяет банк: антифрод, СКУД, DLP, SIEM

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

Антифрод работает на стыке скоринга и поведенческой аналитики: система оценивает нетипичность операции — сумму, получателя, устройство, геолокацию, скорость ввода данных. Сработал высокий риск — операция приостанавливается до подтверждения. Именно поэтому банк может позвонить и уточнить перевод: это не «лишний контроль», а работающий механизм. Важно: сотрудник банка при таком звонке не вправе требовать коды из SMS, CVV/CVC или данные карты.

DLP следит за движением конфиденциальных данных внутри и наружу: выгрузка клиентской базы, отправка файлов на личную почту, копирование на флешку. SIEM собирает логи со всех систем и ищет корреляции — например, серию неудачных входов, за которой следует успешный вход из нехарактерного региона. СКУД и PAM закрывают физический и привилегированный доступ: администратор не войдёт в серверную без пропуска, а его сессия пишется и хранится для разбора.

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

Как выстроить защиту периметра и внутренних систем банка

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

1. Определите активы и данные. Составьте реестр систем, баз данных, ключевых сервисов и владельцев каждого. Отметьте, где хранятся ПДн и платёжные реквизиты.
2. Сегментируйте сеть. Разделите периметр, DMZ, внутреннюю сеть и критичные сегменты (процессинг, АБС, хранилище ключей). Между сегментами — правила межсетевого экрана по принципу «запрещено всё, что не разрешено явно».
3. Введите управление доступом. Единая учётная запись на сотрудника, ролевая модель, обязательная двухфакторная аутентификация для админов и удалённого доступа, PAM для привилегированных сессий с записью.
4. Настройте мониторинг и логирование. Сбор событий в SIEM, алерты на аномалии, обязательное логирование входов в ДБО, изменений прав и доступа к базам.
5. Закройте физический контур. СКУД, видеонаблюдение, регламент доступа в ЦОД, запрет личных носителей на рабочих местах с доступом к ПДн.
6. Опишите регламенты. Управление уязвимостями и патчами, реагирование на инциденты, восстановление после сбоев, резервное копирование с проверкой восстановления.
7. Проверьте себя. Пентест, аудит конфигураций, учения по инцидентам — и повторяйте цикл регулярно, а не раз в год.

Типовые ошибки, из-за которых защита формально есть, а фактически нет: общие учётные записи «на отдел», пароли без ротации, доступ подрядчиков без ограничения по времени, отключённые алерты из-за «шума», резервные копии, которые ни разу не восстанавливали. Каждая из этих ошибок — открытая дверь.

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

Защита клиентских данных и каналов ДБО: шифрование и токенизация

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

Шифрование канала (TLS) защищает передачу между устройством клиента и сервером банка: перехватить трафик и прочитать его в открытом виде нельзя. Но шифрование канала не спасает, если клиент сам передал данные мошеннику — поэтому второй слой это аутентификация. Современный стандарт — двухфакторная аутентификация и подтверждение операций: пароль плюс одноразовый код или push, а для критичных операций — отдельное подтверждение. Ни банк, ни ЦБ никогда не просят коды из SMS, CVV/CVC и данные карты и не предлагают перевести деньги на «безопасный счёт» — такого счёта не существует. Любой такой звонок — мошенничество: кладите трубку и звоните в банк сами по номеру с обратной стороны карты.

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

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

Как банк реагирует на кибератаку: регламент и сроки уведомления ЦБ

Реагирование на инцидент — это заранее прописанный сценарий, а не импровизация в момент атаки. Регламент определяет роли, порядок действий, каналы связи и критерии эскалации. В банке действует круглосуточная дежурная смена ИБ и SOC — центр мониторинга, который первым видит аномалию.

Типовой цикл реагирования выглядит так:

1. Обнаружение. SIEM, антифрод или сотрудник фиксирует подозрительную активность. Создаётся инцидент с приоритетом.
2. Локализация. Изолируются затронутые узлы, блокируются скомпрометированные учётные записи и IP, при необходимости останавливается конкретный сервис — но не весь банк.
3. Оценка масштаба. Определяется, какие данные и системы затронуты, есть ли утечка ПДн или платёжных реквизитов.
4. Устранение. Закрывается уязвимость, восстанавливаются системы из проверенных резервных копий, меняются ключи и пароли.
5. Уведомление. Инцидент передаётся в ФинЦЕРТ Банка России в установленные сроки, при утечке персональных данных — в Роскомнадзор, при признаках преступления — в правоохранительные органы.
6. Разбор. Пост-инцидентный анализ, корректировка регламентов и мер защиты, отчёт руководству и регулятору.

Сроки уведомления регулятора регламентированы: значимые инциденты передаются в ФинЦЕРТ оперативно, в установленном формате. Нарушение сроков или сокрытие инцидента — отдельное нарушение со стороны банка, поэтому банку невыгодно «замалчивать» атаку. Для клиента это означает: если затронуты его данные, банк обязан проинформировать и объяснить, что делать.

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

Куда обращаться при инциденте: ЦБ, ФинЦЕРТ, Роскомнадзор, полиция

Маршрут обращения зависит от того, кто пострадал и что именно произошло. Ниже — кто за что отвечает и в каком случае идти куда.

Порядок действий для клиента при подозрении на мошенничество или взлом: немедленно позвонить в банк по номеру с обратной стороны карты (не по номеру из SMS или звонка), заблокировать карту и доступ к ДБО, зафиксировать всё — скриншоты, время, суммы, номера. Затем подать письменное заявление в банк и получить входящий номер: без него спор сложно двигать дальше. Если банк не решает вопрос, жалоба направляется в Банк России — регулятор рассматривает обращения граждан по работе поднадзорных организаций.

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

И главное правило, которое перекрывает все процедуры: сотрудники банка или ЦБ никогда не просят коды из SMS, CVV/CVC и данные карты и не предлагают перевести деньги на «безопасный счёт». Такого счёта не существует. Любой такой звонок — мошенничество: положите трубку и перезвоните в банк сами.

Как проверить и усилить защиту: аудит, пентест, обучение персонала

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

1. Проверьте контрагента или банк. Лицензию банка, страховщика, брокера или МФО можно проверить в официальных реестрах на сайте Банка России (cbr.ru, раздел «Реестры»). Компании нет в реестре — значит, она работает нелегально и передавать ей деньги нельзя.
2. Проведите аудит конфигураций и прав доступа. Проверьте, нет ли общих учёток, избыточных привилегий, «временных» доступов, которые живут годами.
3. Закажите пентест. Внешний и внутренний: имитация атаки снаружи и изнутри, включая социальную инженерию. Результат — не отчёт ради галочки, а список конкретных уязвимостей с приоритетами.
4. Проверьте восстановление из резервных копий. Резервная копия, которую ни разу не восстанавливали, — это гипотеза, а не защита.
5. Обучите персонал. Регулярные тренинги по фишингу, парольной гигиене, работе с данными. Люди — самый атакуемый канал, и обучение снижает риск сильнее, чем ещё один технический контроль.
6. Проведите учения по инцидентам. Смоделируйте атаку и проверьте, укладывается ли команда в регламентные сроки.
7. Повторяйте цикл. Аудит и пентест — не разовое мероприятие, а регулярная процедура с фиксированной периодичностью.

Для клиента из этого списка применимы пункты 1, 5 и частично 6: проверять легальность организации в реестрах ЦБ, не сообщать никому коды и данные карты, включать двухфакторную аутентификацию, проверять, не оформлены ли на вас чужие обязательства. Если банк или МФО не в реестре — не переводите деньги и не оформляйте займ, это не «серая» схема, а прямое нарушение закона.

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

Информационный сервис. Не является финансовой рекомендацией. Окончательные условия уточняйте на сайте банка.