Бэкапы против шифровальщика: готовиться нужно до того, как это случилось
Профилактический разбор о резервных копиях, офлайн-хранении и тестировании восстановления - пока это не стало срочным.
Вредоносное программное обеспечение, которое шифрует файлы и требует выкуп, существует уже несколько лет. Пока это редкость - единичные случаи, которые обсуждаются в профессиональной среде как экзотика. Но механика атаки проста, а распространение таких инструментов - вопрос времени.
Я пишу этот текст сейчас, пока ситуация ещё не стала массовой. Потому что готовиться к таким вещам нужно в спокойном режиме, а не в панике, когда сервер уже зашифрован.
Почему обычный бэкап не спасает
Большинство компаний делают резервные копии. Но вопрос не в том, делаются ли бэкапы, а в том, выживут ли они при атаке. Ещё до вопроса о шифровальщике многие схемы резервного копирования уже были сломаны виртуализацией.
Если резервные копии лежат на сетевом диске, подключённом к той же инфраструктуре, - шифровальщик доберётся и до них. Если бэкапы делаются раз в сутки и хранятся несколько дней, а атака обнаружена через неделю, - актуальных копий может уже не быть. Если процедура восстановления ни разу не проверялась на практике, выяснить, что она не работает, в момент инцидента - худший возможный момент для открытия.
Резервная копия - это не файл на диске. Это способность восстановить работу за приемлемое время. Это разные вещи.
Что такое "офлайн-копия" и зачем она нужна
Офлайн-копия - это резервная копия, которая физически или логически отделена от основной инфраструктуры и не доступна по сети в обычном режиме работы.
Варианты:
- внешний носитель (лента, диск), физически отключённый после записи;
- копия в облачном хранилище с отдельными учётными данными, не связанными с основной инфраструктурой;
- резервная копия с задержкой - "воздушный зазор" во времени, когда последняя копия ещё не перезаписана.
Цель одна: если основная инфраструктура скомпрометирована, у вас должна быть копия, до которой атака не добралась.
Тестирование восстановления
Бэкап без проверки - это вера, а не защита. Типичная ситуация: компания годами делала резервные копии, а при попытке восстановления выяснилось, что файлы повреждены, формат устарел или процедура занимает в три раза больше времени, чем предполагалось.
Минимальная разумная практика:
- раз в квартал проводить тестовое восстановление хотя бы части данных в изолированную среду;
- фиксировать, сколько времени занимает полное восстановление критичных систем;
- проверять не только то, что файлы скопированы, но и то, что восстановленные системы действительно работают.
Это скучная работа. Именно поэтому она почти никогда не делается, пока не припечёт.
Что должно быть задокументировано
В момент инцидента люди, которые знают, что делать, могут быть недоступны. Поэтому процедура восстановления должна существовать в виде документа, а не только в голове у системного администратора.
Минимальное содержание:
- где физически хранятся резервные копии и как к ним получить доступ;
- в каком порядке восстанавливаются системы (что сначала, что потом);
- кто принимает решение об объявлении инцидента и запуске процедуры;
- кто кому звонит и в каком порядке.
Документ должен быть доступен без доступа к основной инфраструктуре - напечатан, лежит в сейфе или хранится в отдельном месте.
Простой аудит готовности
Четыре вопроса, которые стоит задать прямо сейчас:
- Где лежат резервные копии критичных данных - и доступны ли они из основной сети?
- Когда последний раз проверялось, что из бэкапа действительно можно восстановить рабочую систему?
- Сколько времени займёт восстановление, если всё основное хранилище недоступно?
- Есть ли письменная процедура, которую сможет выполнить человек, не работавший с этими системами раньше?
Если хотя бы на один вопрос нет ответа - это точка, с которой стоит начать.