Непрерывность и восстановление: восстановление, которое никто не тестировал

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

Почему галочка лжёт

ПО резервного копирования сообщает об успехе, когда заканчивает записывать байты в назначение. Оно не знает, пригодны ли эти байты к использованию. Резервная копия SQL Server может завершиться нормально и при этом быть невосстанавливаемой, потому что цепь журнала транзакций разорвалась три дня назад и никто этого не заметил. Снимки ВМ могут выглядеть нормально в консоли, а встроенный VSS writer тихо выйти из строя внутри гостевой ОС, создав образ, согласованный со сбоем (а не согласованный с приложением).

Операторы вирусов-вымогателей знают это. Группы, использующие playbook-ы в стиле Conti в прошлых инцидентах, целенаправленно нацеливались на инфраструктуру резервного копирования — удаляли теневые копии командой vssadmin delete shadows /all /quiet, отключали репозитории Veeam, шифровали целевые хранилища резервных копий на основе NAS, доступные по SMB. Если ваши резервные копии находятся на том же сегменте сети, что и рабочая среда, с учётными данными домена, которые могут их изменять, они являются целью, а не подстраховкой.

Создайте runbook восстановления, а не политику резервного копирования

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

• Точный порядок восстановления (контроллеры домена и DNS в первую очередь, затем основные приложения, потом всё остальное)
• Где хранятся учётные данные для консоли резервного копирования, если ваше хранилище паролей также недоступно
• Конкретную команду восстановления или путь в консоли, а не «используйте Veeam для восстановления ВМ»
• Ожидаемая длительность по системам, основанная на фактических измеренных тестах, а не на маркетинговых цифрах поставщика

Для Veeam Backup & Replication это означает документирование реальных шагов: откройте консоль, перейдите в Backups > Disk, щёлкните правой кнопкой по точке восстановления, выберите Instant VM Recovery или Full VM Restore в зависимости от сценария и выберите целевой хост с достаточной свободной ёмкостью. Если ваш основной хост также скомпрометирован, вам нужен второй, изолированный хост, уже определённый и лицензированный.

Тестируйте восстановления по расписанию, а не по желанию

Установите ротацию. Каждый месяц восстанавливайте одну критическую систему на изолированную VLAN и проверьте, что она загружается, аутентифицируется и правильно обслуживает данные. Каждый квартал проводите полномасштабный тест: восстановите контроллер домена, файловый сервер и основную БД на изолированную инфраструктуру, затем попросите кого-нибудь вне команды резервного копирования попытаться войти и получить отчёт.

Для баз данных не просто восстанавливайте файл .bak — проверьте его:

RESTORE VERIFYONLY FROM DISK = 'D:\Backups\prod_2024.bak'

Затем действительно восстановите его в тестовый экземпляр и запустите DBCC CHECKDB против него. Резервная копия, прошедшая VERIFYONLY, может всё ещё содержать логическую корруптацию, которая проявляется только при запросе к ней.

Для Linux систем, использующих что-то вроде Bacula или restic, тестируйте реальный путь восстановления:

restic restore latest --target /tmp/restore-test --repo /mnt/backup-repo

Затем сравните восстановленные файлы конфигурации с рабочей средой, чтобы убедиться, что ничего не пропало молча.

Неизменяемые копии и правило 3-2-1-1

Классическое правило 3-2-1 (три копии, два типа носителей, одна в другом месте) нуждается в обновлении для эпохи программ-вымогателей: 3-2-1-1, где дополнительная «1» — это неизменяемая или изолированная копия. Object lock на хранилище, совместимом с S3 (Wasabi, Backblaze B2 или AWS S3 с включённым Object Lock), предотвращает удаление или изменение в определённом окне хранения, даже учётной записью с правами администратора. Сконфигурируйте это следующим образом:

aws s3api put-object-lock-configuration \
  --bucket backup-vault \
  --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'

Режим COMPLIANCE означает, что никто, включая корневую учётную запись, не может сократить время хранения или удалить объекты раньше. Это важно, когда злоумышленник имеет доступ администратора домена.

Измеряйте RTO и RPO реальными цифрами, а не предположениями

Recovery Time Objective и Recovery Point Objective звучат как упражнения на бумаге, пока руководитель не спросит «сколько данных мы потеряем и как долго мы будем в отключении». Время ваши последние три тестовых восстановления. Если ваша цель RPO — один час, но задача резервного копирования запускается только каждые шесть часов, у вас есть задокументированный разрыв, и лучше найти его в настольном упражнении, чем во время реального события шифрования в 2 утра в субботу.

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

Для получения дополнительной информации об усилении защиты систем, которые вы защищаете, и построении workflows реагирования на инциденты, ознакомьтесь с соответствующими разделами Blue Team и Digital Forensics на Korra Studio.