Резервное копирование, которое реально спасёт при атаке шифровальщика

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

Почему обычный бэкап не спасает от шифровальщика

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

Что делает резервную копию действительно устойчивой

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

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

Практический чек-лист

1. Определите, какие данные критичны для непрерывности бизнеса, и обеспечьте для них наивысший приоритет резервного копирования. Не всё одинаково критично.
2. Разделите права доступа между системой резервного копирования и рабочей инфраструктурой: учётная запись, скомпрометированная в основной сети, не должна автоматически иметь доступ к бэкапам.
3. Настройте хотя бы одну неизменяемую или полностью изолированную копию, недоступную для изменения даже при компрометации административных учёток.
4. Проверяйте восстановление регулярно, не только при внедрении системы. План восстановления, ни разу не протестированный на практике, часто скрывает проблемы, которые вскрываются только в момент реального инцидента.
5. Зафиксируйте RTO и RPO, допустимое время простоя и допустимый объём потери данных, для критичных систем. Без этих цифр невозможно оценить, соответствует ли текущая схема резервного копирования реальным потребностям бизнеса.

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