Я всё чаще встречаю уверенность, что вопрос киберустойчивости решён, если компания внедрила immutable backup.

Копии нельзя изменить. Политики хранения настроены. Периодический restore проходит успешно.

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

Получить контроль над Active Directory.

Скомпрометировать систему виртуализации.

Удалить backup-каталог.

Заблокировать доступ к ключам.

Захватить административные учётные записи.

Уничтожить документацию или изменить конфигурации.

Оставить persistence на уровне, который не видит гостевая EDR.

Mandiant в M-Trends 2026 описывает переход ransomware к recovery denial: атакующие целенаправленно воздействуют на identity services, backup infrastructure и virtualization management planes, чтобы организация не могла нормально восстановиться. (Google Cloud)езультате возникает парадокс: данные сохранились, а бизнес восстановить нельзя.

На мой взгляд, причина часто не в качестве backup-продукта.

Причина в архитектуре доверия.

Production, backup, гипервизоры, PAM, KMS и recovery orchestration могут использовать один Active Directory, одни административные станции и одни каналы управления.

Для эксплуатации это удобно.

Для атакующего — тоже.

Компрометация одного identity control plane открывает путь одновременно к production, средствам защиты и восстановлению.

Формально системы размещены в разных сегментах или даже на разных площадках. Но если ими управляют одни учётные записи и они зависят от одного домена, это не независимые среды.

Это одна зона доверия.

Поэтому я считаю, что recovery нужно проектировать как отдельную плоскость.

Она должна иметь: — независимые identity; — отдельные административные устройства; — изолированные backup-каталоги и ключи; — offline-копии критичных конфигураций; — доверенные golden images; — собственное журналирование; — clean room для проверки восстановленных систем; — сценарий восстановления при полной потере production AD.

Отдельно стоит пересмотреть RTO.

Обычно его начинают измерять с момента запуска процедуры restore.

Но бизнес не волнует, сколько минут копировалась виртуальная машина.

Бизнесу важно, сколько времени прошло с момента решения о восстановлении до возвращения управляемого процесса.

Между этими событиями могут находиться часы или дни: — оценка масштаба компрометации; — поиск доверенных администраторов; — восстановление identity; — подготовка чистой инфраструктуры; — выбор точки восстановления; — проверка данных; — смена секретов; — подтверждение отсутствия persistence.

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

Моя позиция:

Backup — это сохранённое прошлое. Recovery — способность безопасно построить рабочее будущее.

Проверка одного файла или сервера не отвечает на вопрос, сможет ли компания восстановиться после системной атаки.

Для этого нужно проводить учение полной потери доверия: без production-домена, обычных административных устройств и привычных средств управления.

И восстанавливать не виртуальную машину, а минимально жизнеспособный бизнес-сервис.

Как вы считаете: наличие immutable backup уже можно считать доказательством устойчивости — или компания должна отдельно доказывать жизнеспособность всего recovery path?