Восстановление ИТ-инфраструктуры после кибератаки

В 2023 году Казахстан вышел на 7-е место в мире по числу кибератак: за год было зафиксировано более 223 млн попыток. На этом фоне атаки на банки РК выросли на 92% год к году, а Государственная техническая служба только в 2024 году зафиксировала свыше 41 тыс. инцидентов информационной безопасности.

2024 год при этом запомнился сразу тремя мегаутечками. В открытом доступе оказались более 16 млн ИИН из базы «Жители Казахстана 2024», свыше 2 млн записей клиентов МФО Zaimer.kz, а также данные клиентов крупного банка, появившиеся на BreachForums.

Если смотреть шире, по СНГ в целом на регион приходится 72% успешных атак, а по России за первое полугодие 2025 года было зафиксировано более 63 000 инцидентов. Для CISO и CTO на этом фоне вопрос давно сместился с «как не допустить?» на «как быстро вернуть сервисы и данные, когда инцидент уже произошёл?».

Восстановление данных после атаки — это заранее отрепетированный сценарий с измеримыми RPO и RTO, изолированными копиями и регламентом, согласованным с бизнесом. В этой статье разберём, что именно ломается при инциденте, как провести аудит последствий, какие механики восстановления реально работают против современных шифровальщиков и какую роль играет облако с учётом Закона РК №94-V о локализации данных и Постановления №832 о защите КВО ИКИ.

Что происходит с инфраструктурой после кибератаки

Атака редко ограничивается одним сервером. Типичный сценарий выглядит так: злоумышленники двигаются по домену, а затем последовательно шифруют файловые хранилища, СУБД, гипервизоры и системы резервного копирования.

Показателен кейс СДЭК в мае 2024 года. Группировка Head Mare развернула шифровальщик, зашифровала данные и уничтожила резервные копии, а по заявлениям самих злоумышленников бэкапы в компании делались раз в полгода. Простой превысил трое суток, а оценка ущерба экспертами достигла 1 млрд ₽.

Чаще всего злоумышленники целенаправленно идут в бэкапы ещё до шифрования прода. Если резервные копии скомпрометированы, шифрование удаётся в 89% случаев, тогда как при защищённых копиях этот показатель составляет 52%.

В российской практике к этому добавляется ещё один риск. В 2025 году 15% атак на средний и крупный бизнес были диверсиями без предложения декриптора, то есть восстановление в таких случаях в принципе невозможно без собственных чистых копий.

Последствия атак

Средняя стоимость восстановления после ransomware в мире в 2024 году составила 2,73 млн долларов, и это почти на 1 млн больше, чем годом ранее. В России одновременно выросли и выкупы: для крупного бизнеса они находятся в диапазоне от 4 до 40 млн ₽, а максимум запрашиваемого выкупа в 2025 году достиг 400 млн ₽ против рекорда 2024 года в 240 млн ₽. Для МСБ диапазон ниже, но тоже ощутимый — от 240 тыс. до 4 млн ₽.

На этом фоне растёт и масштаб компрометации данных. За 2025 год было скомпрометировано 767 млн строк данных против 457 млн годом ранее, зафиксировано 250 публичных утечек баз и 27 активных APT-групп, из которых 7 были раскрыты публично впервые.

К прямым потерям добавляются штрафы за утечки персональных данных и за нарушение требований Закона РК № 94-V «О персональных данных и их защите», а для критически важных объектов — ещё и риски, связанные с несоблюдением единых требований по информационной безопасности, закреплённых Постановлением Правительства РК № 832. Для бизнеса на этом последствия не заканчиваются: в Казахстане за нарушения в сфере информатизации и защиты данных к ответственности привлекают как юридические лица, так и должностных лиц, причём ответственность за состояние ИБ в компании в первую очередь несёт руководитель и назначенное ответственное лицо. Для enterprise любой серьёзный инцидент дополнительно бьёт по SLA-обязательствам перед клиентами, и в момент простоя эти обязательства начинают нарушаться по всей цепочке.

Аудит и диагностика инфраструктуры

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

Что фиксировать в первые часы

• Точку входа и время компрометации по логам SIEM, EDR и сетевых устройств.
• Перечень затронутых хостов, СУБД, хранилищ и систем резервного копирования.
• Признаки закрепления: учётные записи, задачи планировщика, изменённые образы гипервизоров.
• Статус копий: какие доступны, какие подписаны контрольной суммой, какие изолированы.

В Казахстане владельцы КВО ИКИ обязаны уведомить КНБ РК об инциденте в течение 3 часов, а госорганы — в течение 30 минут. В России аналогичная обязанность закреплена в 187-ФЗ: до 3 часов для значимых объектов КИИ и до 24 часов — для незначимых.

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

Clean room:

• Отключить скомпрометированный сегмент от сети и сохранить образы.
• Развернуть чистую управляющую плоскость: AD, DNS, управление резервным копированием.
• Проверить копии офлайн-сканированием и сверкой с эталонами.
• Восстанавливать приложения в чистую зону, а не поверх заражённой.

RPO и RTO как язык переговоров с бизнесом

RPO (Recovery Point Objective) задаёт допустимую потерю данных во времени, а RTO (Recovery Time Objective) — допустимый срок восстановления сервиса. Обе метрики закрепляются в DR-плане по каждому сервису и переводят ИТ-риск в бизнес-величины: в минуты простоя и стоимость недоступности для клиентов.

По отраслевой практике для транзакционных СУБД RPO обычно составляет 5–15 минут, для архивных систем — до 24 часов. RTO для критичных систем находится в диапазоне от 5 минут до 1 часа, для вторичных сервисов — до 72 часов. Конкретные значения зависят от SLA перед клиентами и стоимости минуты простоя, поэтому универсальной нормы здесь нет, а сами диапазоны используются как ориентир при выборе технологий копирования и репликации.

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

Восстановление данных после кибератаки

Правило 3-2-1-1-0

Это 3 копии, 2 типа носителей, 1 off-site, 1 immutable или offline, 0 ошибок восстановления при регулярной проверке. Кейс СДЭК показал цену отсутствия immutable-слоя и редкого бэкапа: резервные копии были уничтожены вместе с продом.

Immutable backup и air-gap

Immutable-бэкап — это копия с атрибутом неизменяемости. В облачных объектных хранилищах он реализуется через S3 Object Lock в режимах Compliance или Governance. Air-gap — это физическая или логическая изоляция копии.

Приоритеты

Disaster Recovery план

По наблюдениям Kaspersky, ключ к быстрому восстановлению — не выкуп, а заранее спроектированный и отрепетированный сценарий реагирования.

Состав DRP

В DRP входят матрица сервисов с RPO и RTO, runbook по сценариям, схема коммуникаций — в РК это КНБ и ГТС, в РФ — НКЦКИ и Роскомнадзор, а также клиенты, список IR-подрядчиков, ресурсы для clean room и критерии возврата к штатной работе.

Регулярность учений. Для enterprise-сегмента полные учения Disaster Recovery проводятся минимум один раз в 12 месяцев. Такой подход работает для стабильных инфраструктур с редкими изменениями архитектуры, а при миграциях, смене провайдера или крупных релизах учения проводят дополнительно.

Полный DR-drill переводит критичные сервисы на резервную площадку с участием бизнес-пользователей и позволяет замерить фактические RPO и RTO. Целевая метрика здесь — расхождение между заявленными и фактическими показателями: если превышение составляет более 50%, план нужно пересматривать до следующего инцидента.

При этом tabletop-формат и partial-failover не заменяют полный drill. Они помогают проверить runbook, но не показывают пропускную способность резервных каналов и поведение приложений под продовой нагрузкой.

Compliance: Казахстан и Россия. В Казахстане DR — это требование закона. Постановление Правительства №832 обязывает госорганы, квазигоссектор и владельцев КВО ИКИ обеспечивать резервирование и непрерывность. Закон №94-V, статья 17, пункт 2, запрещает хранение персональных данных граждан РК за пределами страны, поэтому бэкапы должны находиться на территории Казахстана. Требования НБ РК дополнительно ужесточают SLA на восстановление для банков.

В России аналогичную роль выполняют 187-ФЗ и Приказ ФСТЭК №239, а также Указ №166, который запрещает использование иностранного ПО на КИИ с 1 января 2025 года, и Указ №250, закрепляющий персональную ответственность руководителя за информационную безопасность.

Роль облака в восстановлении инфраструктуры

DRaaS и облачное резервное копирование. DRaaS — это непрерывная репликация и автоматизированное переключение в облако провайдера. Типовая схема строится вокруг локального бэкап-шлюза и объектного хранилища с Object Lock.

Гибридная модель. В этой модели прод размещается в ЦОД, резерв — в другом облаке или регионе, immutable-слой — в объектном хранилище, а air-gap для критичных данных обеспечивается на офлайн-носителях.

Выбор провайдера: требование локализации. В Казахстане Закон №94-V, статья 17, пункт 2, обязывает хранить персональные данные граждан на территории РК. Это напрямую исключает размещение бэкапов казахстанских клиентов в зарубежных облаках и делает выбор локального провайдера не предпочтительным, а обязательным.

VK Cloud KZ предоставляет DRaaS и Cloud Backup с дата-центрами на территории Казахстана, что соответствует требованию локализации и Постановлению №832. На рынке РК также работают ИТ-ГРАД KZ с RPO от 15 минут, LanCloud с восстановлением менее чем за 15 минут и KazTeleport SmartCloud.

Выбор провайдера определяется тремя факторами: соответствием Закону 94-V и ПП №832, в России — 187-ФЗ и ФСТЭК №239, фактическими RPO и RTO по результатам учений на его площадке, а также стоимостью владения на горизонте 3–5 лет. Сам по себе бренд провайдера без этих трёх проверок не является аргументом для enterprise-архитектуры.

Регуляторика: РК и РФ в сравнении

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

Заключение

Восстановление данных после атаки давно перестало быть упражнением для ИТ и стало измеримым бизнес-процессом с RPO, RTO, регламентом и ответственностью перед регулятором. Казахстан входит в топ-10 стран по числу кибератак, а три мегаутечки за один только 2024 год показали, что от этого не застрахованы ни банки, ни МФО, ни госсервисы. Кейс СДЭК из соседней России подтвердил: бэкап без изоляции — это не бэкап.

Рабочая рамка на 2026 год выглядит так: правило 3-2-1-1-0 с immutable-слоем, сегментированный план восстановления по Tier 0–3, DR-учения минимум раз в год с замером фактических метрик, гибридная архитектура с облачным DRaaS на площадке внутри РК как требование Закона 94-V, а также соответствие ПП №832 для КВО ИКИ. Это не гарантия отсутствия инцидентов, а гарантия того, что инцидент не превратится в остановку бизнеса.