Когда «час Х» наступил: что делать в первые сутки после кибератаки

Массированные кибератаки с последующим заражением вредоносным ПО – это то, с чем сегодня приходится сталкиваться все чаще. Главная мысль, которую стоит усвоить еще до того, как наступит «час Х», такая: если все уже случилось, строить оборону, поздно, подготовиться надо было заранее. А вот первые сутки после атаки — это уже не про предотвращение, а про грамотное спасение того, что осталось.

Почему просто бэкап больше не спасает

Ландшафт угроз изменился радикально, и относиться к нему по-старому опасно. В 2025 году акцент злоумышленников сместился с дефейсов, хищения данных и DDoS-атак на полное уничтожение инфраструктуры: 76% критических кибератак были направлены именно на это. Их большая часть — это шифрование (Babyk, LockBit, Zeppelin, Phobos и др.), а еще около трети — вообще разрушение ИТ-контура.

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

И вот ключевой нюанс, который меняет все. Если раньше атаки шли на «прод», «боевую инфраструктуру», то теперь начинают с другого конца — бэкапов. За недели присутствия внутри сети хакеры изучают инфраструктуру, находят резервные копии и готовят удар, который максимально парализует работу организации. Сначала пробираются в систему резервного копирования, шифруют или уничтожают копии, делают восстановление невозможным — и только потом наносят удар по основной инфраструктуре. Эта скрытность стала нормой: 35% выявленных APT-группировок уже находились в инфраструктуре жертв на момент обнаружения.

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

Первый час: три линии обороны одновременно

Когда все уже началось, времени на раскачку нет. Счет идет буквально на минуты, ведь именно за первые часы шифровальщик успевает «съесть» половину инфраструктуры. Поэтому действовать надо сразу по нескольким направлениям — параллельно, а не последовательно.

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

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

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

Главное правило восстановления: сначала карантин, потом «прод»

Вот мы подошли к самому интересному — восстановлению. Казалось бы, логика проста: достаем систему резервного копирования (СРК), разворачиваем данные, работаем дальше. Но именно здесь кроется ловушка, в которую попадают многие. Поскольку атакующие сегодня в первую очередь метят в бэкапы, нельзя слепо доверять резервной копии. Перед тем как разворачивать данные на «боевой» контур, их обязательно нужно восстановить в изолированной среде — на отдельном стенде, отрезанном от всего. Там вы проверяете восстановленный объект, убеждаетесь, что он «чист» и работоспособен, и только потом разворачиваете на «прод». Иначе легко угодить в ситуацию, когда вы с гордостью «восстановились», а на деле вернули в строй повторно зараженные файлы и запустили катастрофу по второму кругу.

Этот подход уже стал индустриальной нормой. Спрос на независимые аудиты СРК вырос вдвое, а 74% крупных компаний внедрили регулярные тестовые восстановления данных в изолированных средах. Эксперты по реагированию формулируют это прямо: ключ к быстрому восстановлению бизнеса — не плата вымогателям, а заранее спроектированный и отрепетированный сценарий реагирования и восстановления после атаки.

Честно говоря, идеальный сценарий доступен не всем. Некоторые сознательно идут на риск и восстанавливаются сразу в «прод», потому что или не хватает физической инфраструктуры для изолированного стенда, или простой стоит слишком дорого, и проще рискнуть. Это рабочий компромисс, но важно понимать, на что вы идете. В идеальной же системе, о которой мечтает любой администратор СРК, путь всегда один: сначала восстановили в карантин, проверили, выдали заключение, и только потом развернули туда, где это нужно бизнесу.

И еще одна деталь, о которой часто забывают в горячке. Когда после атаки собирается команда разбора, один из самых первых вопросов должен звучать так: что у нас с бэкапами? Нужно сразу привлекать администратора СРК и выяснять, есть ли актуальные копии и насколько они свежие. От ответа напрямую зависит вся дальнейшая стратегия: может оказаться, что копия есть, но сделана слишком давно, и тогда план действий будет совсем другим.

Гранулярно или «все и сразу»: как выбрать стратегию

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

Первый — гранулярное восстановление. Если инфраструктура в целом уцелела, а пострадал, скажем, один сервер (не обновили пароль, проморгали уязвимость — и вот он заражен, а с ним пострадала одна база данных), то нет никакого смысла «поднимать» все подряд. Восстанавливаем точечно конкретные БД, почтовый ящик, виртуальную машину и. т.п. Хирургически, без лишних движений.

Другой полюс — восстановление крупными сущностями. Если же ущерб масштабный, гораздо быстрее перевосстановить все разом из аппаратных снимков системы хранения данных, чем «поднимать» каждый сервер отдельно. Условно говоря, возвращаем на место все, что было на дисках, целым пластом. Именно здесь играют роль показатели RPO и RTO: умея бэкапить инфраструктуру снапшотами СХД, можгно может радикально ускорить восстановление и уложиться в жесткие временные рамки, которые диктует бизнес.

Решение, какой путь выбрать, принимается исходя из локализации ущерба. Задело один контур — работаем точечно. Накрыло половину инфраструктуры — «поднимаем» все из снимков. Современные средства резервного копирования поддерживают оба сценария: например, репликацию и аварийное восстановление виртуальных машин, многопоточную передачу данных и гранулярное восстановление файлов и папок. Это позволяет выбирать инструмент под конкретную ситуацию, а не подстраиваться под единственный доступный инструмент.

Что делает восстановление по-настоящему быстрым

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

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

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

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

Устойчивость к кибератакам — это не разовая покупка решения и не героизм ИТ-отдела в день инцидента, а выстроенная заранее система: проверенные бэкапы, отработанный план, понятные роли и инструменты, которые позволяют выбирать стратегию под ситуацию. Те, кто инвестирует в эту готовность сегодня, в «час Х» будут заниматься управляемым восстановлением, а не борьбой за само существование бизнеса.

Андрей Кузнецов, генеральный директор ООО «РуБэкап» (входит в «Группу Астра»)