Вирус шифрует и бэкапы: как выстроить защиту восстановления

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

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

Разница между «делаем бэкапы» и «умеем восстанавливаться после шифрования» — это разница между галочкой в политике и реальной живучестью бизнеса.

Как резервные копии оказываются в одной судьбе с продом

Общая папка резервов в том же каталоге учёток, с теми же широкими правами администраторов. Скомпрометировали админа — получили и прод, и архив. Удобство администрирования совпало с удобством атаки.

Снимки только на том же хранилище без независимого копирования. Шифрование массива или его логики убивает оба слоя. «Второй слой» оказывается иллюзией.

Нет проверки восстановления. «Бэкап зелёный» в отчёте означает, что задача стартовала, а не что вы умеете поднять систему за оговорённое время. Зелёный цвет усыпляет лучше любой презентации.

Одинаковые сетевые пути и постоянные учётные записи агентов с избыточными правами. Чем шире права агента, тем вкуснее он для злоумышленника.

Нет изоляции по времени: последние копии перезаписываются так быстро, что чистая точка уезжает за горизонт раньше, чем атаку замечают.

Почему это всплывает слишком поздно

Резервное копирование считают закрытым проектом после настройки расписания. Угрозы меняются, схема — нет. Годовая политика без учений — бумага.

Ответственность размыта: кто проверяет восстановление? кто хранит независимую копию? кто реагирует ночью? В кризис начинается поиск добровольцев.

Учения не проводят, потому что «некогда останавливать». В день атаки время всё равно остановится — только дороже.

Ошибки, которые любят шифровальщики

Хранить единственную копию онлайн в той же зоне безопасности, что и боевой контур.

Давать агенту резервного копирования права «админ везде» без сегментации.

Не использовать неизменяемость или режим однократной записи там, где это уместно и доступно. Возможность мгновенно стереть историю — подарок атакующему.

Игнорировать средний срок хранения и внешний контур: всё в одном шкафу, одном дата-центре, одном облачном аккаунте без разделения ролей.

Путать наличие бэкапа с готовым планом аварийного восстановления: нет порядка подъёма, нет приоритетов приложений, нет контактов.

Платить выкуп «потому что бэкапы тоже лежат», хотя иногда проблема именно в схеме хранения, а не в отсутствии копий как идеи.

Как строят копии, которые переживают атаку

Разделяют домены безопасности. Учётки резервного копирования не должны быть теми же ключами от всего, что повседневная админка. Доступ к хранилищу копий — узкий, по возможности с отдельным контуром.

Держат правило нескольких копий на разных системах и одной вне оперативного контура — в рабочей, а не плакатной версии. Плакат на стене не поднимает сервис.

Вводят окна, в которых критичные копии нельзя молниеносно удалить или зашифровать теми же правами, что повседневные задачи. Даже администратору должно быть трудно уничтожить историю за минуту.

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

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

После учений правят схему. Бэкап без итераций стареет так же, как антивирус десятилетней давности.

Вопрос, который стоит задать на следующем совещании

«Если шифровальщик получит права нашего админа, уцелеет ли чистая копия, из которой мы поднимемся за оговорённое время?» Если в комнате нет уверенного ответа с датой последнего учения — у вас есть задача, а не стратегия.

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

Что считать минимально приемлемой схемой

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

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

Храните дату последнего успешного учения восстановления рядом с датой последнего бэкапа. Обе даты должны быть свежими. Одна свежая без другой создаёт ложное спокойствие — самое опасное состояние перед атакой.

Отдельно проверьте права сервисных учёток агентов копирования: часто они шире, чем нужно. Сужение прав само по себе уже уменьшает радиус поражения, даже до покупки новых систем хранения.

Итог для руководства

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

Спокойствие даёт не слоган «мы бэкапим», а пройденное учение: подняли, уложились в срок, данные целы. Всё остальное — надежда.

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