Больше 90% атак с вымогателями теперь сначала пытаются удалить или испортить резервные копии. Если верить этим данным, спор о том, достаточно ли просто делать бэкапы, можно закрывать: в 2026 году на первый план выходит не хранение копий, а готовность к восстановлению. Для IT-команд это неприятная, но полезная коррекция оптики: бизнесу нужен не отчет об успешном backup job, а работающие сервисы после инцидента.
Об этом сообщает ZDNet в материале о том, почему recovery readiness становится новым стандартом киберустойчивости. Издание ссылается сразу на несколько цифр, которые хорошо объясняют сдвиг. Почти 60% атак, нацеленных на бэкапы, достигают цели. А среди руководителей малого и среднего бизнеса в США 94% считают, что их компания переживет катастрофу, хотя только у четверти реально есть инфраструктура восстановления. Разрыв между уверенностью и готовностью здесь, мягко говоря, не косметический.
Ключевая мысль довольно простая: резервное копирование и восстановление — не синонимы. Бэкап создает дубликат данных. Восстановление отвечает на совсем другой вопрос: сможете ли вы быстро поднять системы, вернуть доступ сотрудникам и не оставить клиентов наедине с ошибкой 500, пустым CRM или недоступной почтой. Пока многие компании путают одно с другим, атакующим даже не нужно особенно изобретать новые трюки. Они бьют по самому очевидному слабому месту: сначала ломают или шифруют хранилища копий, а уже потом добивают остальную инфраструктуру.
На этом фоне особенно показателен другой тренд: злоумышленники все реже «взламывают периметр» в классическом смысле и все чаще просто входят в систему через учетные записи. По данным, приведенным ZDNet, около четырех из пяти атак с вымогателями начинаются с identity-based подходов. Речь о компрометации учеток, обходе MFA, захвате активных сессий и работе через легитимный доступ. В гибридной инфраструктуре это логично: компании продолжают выносить нагрузки в облако, а вместе с этим растет площадь атаки на идентичности, гостевые аккаунты и админские роли. И если после такого входа атакующий первым делом добирается до backup-репозитория, организация без отработанного сценария восстановления остается без запасного выхода.
Отдельный холодный душ — ситуация с SaaS. У многих команд до сих пор живет полуофициальная вера, что Microsoft 365, Google Workspace и другие облачные платформы «как-нибудь сами разберутся» с потерей данных. Но модель shared responsibility работает иначе: провайдер отвечает за доступность сервиса, а не за то, что ваша компания сможет нормально восстановиться после шифрования, массового удаления или захвата учетных записей. В материале приводится еще одна показательная цифра из Kaseya 2026 SaaS Security Report: 69% отслеживаемых SaaS-аккаунтов в 2025 году были гостевыми, а MFA активно применяли только 27% SMB. При такой дисциплине встроенная корзина, история версий и retention policy выглядят скорее утешительным призом, чем планом выживания.
Проблема усугубляется фрагментированной защитой. У многих компаний набор средств собирался по мере роста: немного нативных инструментов от облачного провайдера, отдельный продукт для резервного копирования, еще один — для endpoint-защиты, плюс ручные процедуры «на крайний случай». На бумаге получается стек. В реальности — длинная цепочка зависимостей, где любая несостыковка растягивает Recovery Time Objective дальше, чем может позволить себе бизнес. По данным опроса Redmond/Kaseya среди 200 IT-специалистов, только каждая пятая организация сообщила о единой защите резервных копий в гибридной среде. Остальные живут в мире, где каждый кусок инфраструктуры вроде бы прикрыт, но собрать из этого быстрое восстановление в критический момент почти невозможно.
Именно поэтому готовность к восстановлению все чаще измеряют не объемом сохраненных копий, а качеством проверок. Если бэкап прошел «успешно», но образ виртуальной машины не загружается, база не монтируется, а ключевые SaaS-учетки по-прежнему недоступны, ценность такого успеха стремится к нулю. В том же опросе 53% IT-специалистов признались, что лишь отчасти уверены в своей способности восстановить среду, а ежемесячно проверяют это предположение только 18%. То есть у большинства организаций есть не подтвержденная способность восстановиться, а скорее надежда, что в день X все не развалится. История IT знает, насколько дорогой бывает такая надежда.
Для разработчиков и инфраструктурных команд вывод тоже вполне прикладной. Надо тестировать не только целостность копий, но и фактическую загрузку систем, доступность приложений, работу зависимостей и сценарии возврата доступа к учетным записям. Для продактов и IT-руководителей акцент смещается на честные показатели RTO и RPO: страховщики и регуляторы все реже готовы принимать декларации «у нас все зарезервировано» без подтвержденных процедур восстановления. В материале прямо упоминаются CMMC, GDPR, NIS2 и DORA: устойчивость там трактуется уже не как приятная практика из методички, а как обязательство. И это, пожалуй, главный сигнал для рынка. Если бизнес не может доказать, что восстановится в разумные сроки, он уязвим не только для шифровальщика, но и для аудитора, страховщика и собственного совета директоров.
Следующий логичный этап для отрасли — переход от культуры «делаем бэкапы» к культуре регулярных репетиций восстановления с изолированными, неизменяемыми копиями и отдельными учетными данными. Вопрос теперь не в том, есть ли у компании резервная копия, а в том, сможет ли она пережить день, когда эта копия окажется единственным шансом вернуть бизнес в строй.