Безперервність та відновлення: Restore, який ніхто не тестував

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

Чому галочка брехує

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

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

Побудуйте план відновлення, а не політику резервного копіювання

План безперервності потребує пошагових інструкцій з відновлення, написаних для людини, яка зазвичай це не робить. Запишіть:

• Точний порядок відновлення (контролери домену та DNS спочатку, потім основні додатки, потім все інше)
• Де знаходяться облікові дані для консолі резервного копіювання, якщо ваш сховище паролів також не працює
• Конкретна команда відновлення або шлях консолі, а не «використовуйте Veeam для відновлення VM»
• Очікувана тривалість для кожної системи, на основі фактичних виміряних тестів, а не маркетингових цифр виробника

Для 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 реальними числами, не здогадками

Ціль часу відновлення та Точка цілі відновлення звучать як вправи на папері, доки керівник не запитає «скільки даних ми втрачаємо та як довго ми будемо недоступні». Синхронізуйте останні три тести відновлення. Якщо ваша цільова RPO — одна година, але ваше завдання резервного копіювання запускається тільки кожні шість, у вас є задокументована розбіжність, і краще знайти цю розбіжність на табличній вправі, ніж під час реального інциденту шифрування о 2 ранку в суботу.

Запустіть тест, запишіть фактичний час на годинниці та порівняйте його з тим, що ви обіцяли в документі відновлення після аварії. Різниця між цими двома цифрами — це реальний стан вашого плану безперервності.

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