Чужое облако, чужой DNS и ваш значимый объект: чек-лист для CISO банка
Вечером 30 января 2024 года из-за ошибки с ключами DNSSEC перестали открываться сайты и приложения в доменной зоне .ru. Мобильные банки крупнейших игроков не работали несколько часов. При этом сами банковские системы функционировали штатно: сбой случился в инфраструктуре, которая никому из пострадавших не принадлежит. В июне 2026 года история повторилась в другом виде: после обновления конфигурации фильтрующего оборудования на магистральных сетях частично легли клиенты крупных российских хостингов, от Beget до Selectel, и сами хостинги ничего не могли с этим сделать.
В обоих случаях доступность сервисов зависела от систем, которых нет ни в одной карте категорирования объектов КИИ.
Почему ждать помощи от регулирования не стоит
Закон 187-ФЗ и постановление Правительства N 127 строят защиту вокруг субъекта и принадлежащих ему систем. Банк категорирует свои АБС, процессинг, ДБО. А облако, DNS-хостинг, CDN, внешняя защита от DDoS и каналы связи принадлежат провайдерам, и обязательные требования к значимым объектам на них через договор не переходят. Провайдер может сам быть субъектом КИИ как оператор связи, но его коммерческое облако от этого значимым объектом не становится. О регуляторной стороне этого разрыва я подробно писал в колонке для другого СМИ, там же о поправках, которые сейчас проходят обсуждение. Здесь о другом: что служба ИБ банка может сделать своими руками, не дожидаясь изменений нормативки.
Шаг 1. Составьте карту внешних зависимостей каждого значимого объекта
В карту должно попасть не только облако. Сюда же относится все, что связано с DNS (регистратор домена, DNS-хостинг, валидность DNSSEC), сети доставки контента и внешний anti-DDoS, каналы связи вместе с физическими трассами до резервного ЦОДа, внешние API вроде СМС-шлюзов, антифрод-сервисов и бюро кредитных историй. Не забудьте вендоров средств защиты с автоматическим обновлением. 19 июля 2024 года дефектный апдейт агента CrowdStrike останавливал банки и биржи по всему миру, причиной простоя стало само средство защиты. Формальная зацепка для этой работы уже есть. Положение Банка России 850-П требует вести реестр технологических процессов с участками, которые выполняют поставщики ИТ-услуг. Расширьте этот реестр до полноценной карты зависимостей значимых объектов, назначьте владельца и срок актуализации.
Шаг 2. Проверьте, что провайдер обязан вам сообщать и когда
Возьмите действующий договор с облачным провайдером и найдите в нем обязанность уведомлять вас о компьютерных инцидентах и сбоях. Скорее всего, ее там нет, либо она сформулирована как «в разумный срок». При перезаключении впишите конкретные часы на уведомление, отдельный канал связи (не тикет-систему в личном кабинете, которая ляжет вместе с облаком) и контакты дежурных смен с обеих сторон. Опорой в переговорах служат требования положения 716-П к управлению риском аутсорсинга и меры ГОСТ Р 57580.3-2022, где взаимодействие с поставщиком расписано прямым текстом.
Шаг 3. Переведите SLA из деклараций в измеримые величины
Записанная в договоре доступность 99,9% сама по себе мало о чем говорит, пока непонятно, кто измеряет, откуда и что считается простоем. Требуйте перцентили времени ответа, точки измерения, порядок фиксации простоя и внятные последствия нарушения. Отдельно просите цифры по каждой зоне доступности, а не по облаку в целом. 30 марта 2025 года зона ru-central1-b Яндекса легла целиком после аварии энергоснабжения, и клиенты, развернувшие сервис в одной зоне, ждали восстановления до вечера. Мультизонная архитектура стоит денег, зато после таких кейсов обосновать эти затраты перед руководством стало проще.
Шаг 4. Посчитайте, что будет, если провайдер лежит десять дней
Сколько на самом деле может лежать контрагент после серьезной атаки, показал СДЭК в мае 2024 года. Шифровальщик, по заявлению атакующих уничтоженные резервные копии, прием и выдача отправлений остановились 26 мая, а полностью сервис восстановился только 6 июня. Полторы недели. Теперь задайте тот же вопрос своему облаку и своему ДБО. Ответ должен существовать в виде exit-плана с резервной площадкой и порядком миграции, который проверен на учениях, а не остался на бумаге. Сюда же ложится новое требование 850-П: с октября 2025 года кредитные организации обязаны определить сигнальные и контрольные значения допустимой доли деградации технологических процессов. Отказ ключевого провайдера дает готовый сценарий для этих расчетов.
Шаг 5. Мониторьте внешние сервисы своими средствами
15 мая 2025 года пятнадцатиминутный сбой в национальном контуре управления сетями связи дал всплеск жалоб на банки и операторов по всей стране. Июньский случай с фильтрацией на магистралях из той же серии. Проблема возникает там, куда не дотягивается ни ваш мониторинг, ни мониторинг вашего провайдера. Помогают внешние синтетические проверки клиентских сценариев из нескольких регионов и от разных операторов связи, а также контроль DNS-резолвинга, DNSSEC и сроков действия сертификатов. Задача в том, чтобы узнавать о сбое раньше клиентов.
Шаг 6. Отчитывайтесь, не дожидаясь уведомлений от провайдера
Юридическая ловушка внешнего сбоя в том, что на значимом объекте инцидента нет, а банковские услуги недоступны. Для 716-П это событие операционного риска, и фиксировать его нужно независимо от того, где физически случилась авария. Договоритесь внутри, кто и по каким признакам квалифицирует внешний сбой, куда о нем сообщают и как он попадает в отчетность перед Банком России. Иначе есть шанс, что о проблеме регулятор узнает не от вас.
Шаг 7. Включите провайдеров в модель угроз и в киберучения
18 ноября 2025 года ошибка конфигурации у Cloudflare, через которую проходит примерно пятая часть мирового веб-трафика, уложила тысячи сайтов, от X до ChatGPT, причем без всякой атаки. В моделях угроз по приказу ФСТЭК N 239 внешний провайдер обычно фигурирует как потенциальный нарушитель, но почти никогда как точка отказа. Добавьте сценарии: отказ облачной зоны, отказ DNS, дефектное обновление вендора СЗИ, блокировка легитимного трафика магистральным фильтром, DDoS на емкость канала оператора (волну июля 2024 года банковские дежурные смены помнят хорошо). И прогоните хотя бы два из них на ближайших учениях.
Что в итоге. Регуляторный разрыв вокруг чужой инфраструктуры рано или поздно закроют, поправки поданы и обсуждение идет. Но клиентам вашего банка все равно, кто виноват в недоступности приложения: провайдер, магистральный фильтр или ключи DNSSEC. Из семи шагов выше пять не требуют бюджета, только времени службы ИБ и юристов. Начинать разумно с карты зависимостей, она дешевле всего и нужнее всего в плохую ночь.
Автор: Николай Лобанов, независимый эксперт по информационной безопасности и защите КИИ, магистрант ИПНБ РАНХиГС (программа «Государственное управление и национальная безопасность»)
