Kontinuitas dan Pemulihan: Restore yang Tidak Pernah Diuji

Setiap dashboard backup menampilkan centang hijau. Job selesai, kebijakan retensi terpenuhi, penyimpanan digunakan seperti yang diharapkan. Tidak ada yang mengatakan apakah Anda dapat membawa domain controller kembali dari bare metal dalam waktu kurang dari empat jam selama insiden sebenarnya. Celah antara "backup berhasil" dan "restore berhasil" adalah tempat sebagian besar rencana kontinuitas diam-diam gagal.

Mengapa centang itu berbohong

Software backup melaporkan sukses ketika selesai menulis byte ke destinasi. Itu tidak tahu apakah byte tersebut dapat digunakan. Backup SQL Server dapat selesai dengan bersih dan tetap tidak dapat dipulihkan karena rantai log transaksi putus tiga hari sebelumnya dan tidak ada yang memperhatikan. Snapshot VM bisa terlihat baik di konsol sementara VSS writer yang mendasar diam-diam gagal di dalam guest OS, menghasilkan image yang crash-consistent (bukan application-consistent).

Operator ransomware tahu ini. Grup yang menjalankan playbook gaya Conti dalam insiden sebelumnya dengan sengaja menargetkan infrastruktur backup — menghapus shadow copy dengan vssadmin delete shadows /all /quiet, menonaktifkan repositori Veeam, mengenkripsi target backup berbasis NAS yang dapat dijangkau melalui SMB. Jika backup Anda berada di segmen jaringan yang sama dengan production dengan kredensial domain yang dapat menyentuhnya, itu adalah target, bukan jaring pengaman.

Bangun runbook restore, bukan kebijakan backup

Rencana kontinuitas membutuhkan instruksi restore langkah demi langkah yang ditulis untuk seseorang yang bukan orang yang biasanya melakukannya. Tuliskan:

• Urutan recovery yang tepat (domain controller dan DNS terlebih dahulu, kemudian aplikasi inti, kemudian semuanya)
• Di mana kredensial untuk konsol backup berada jika vault password Anda juga down
• Perintah restore atau jalur konsol spesifik, bukan "gunakan Veeam untuk restore VM"
• Durasi yang diharapkan per sistem, berdasarkan tes terukur aktual, bukan angka pemasaran vendor

Untuk Veeam Backup & Replication, itu berarti mendokumentasikan langkah aktual: buka konsol, navigasi ke Backups > Disk, klik kanan restore point, pilih Instant VM Recovery atau Full VM Restore tergantung skenario, dan pilih host target dengan kapasitas bebas yang cukup. Jika host utama Anda juga dikompromikan, Anda membutuhkan host kedua yang terisolasi yang sudah diidentifikasi dan berlisensi.

Uji restore sesuai jadwal, bukan sesuka hati

Pilih rotasi. Setiap bulan, restore satu sistem kritis ke VLAN terisolasi dan validasi itu boot, autentikasi, dan melayani data dengan benar. Setiap kuartal, jalankan tes cakupan penuh: restore domain controller, file server, dan database utama Anda ke infrastruktur terisolasi, kemudian biarkan seseorang di luar tim backup mencoba masuk dan menarik laporan.

Untuk database, jangan hanya restore file .bak — verifikasi:

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

Kemudian benar-benar restore ke instance test dan jalankan DBCC CHECKDB terhadapnya. Backup yang lulus VERIFYONLY masih dapat berisi logical corruption yang hanya muncul ketika Anda query.

Untuk sistem Linux menggunakan sesuatu seperti Bacula atau restic, uji jalur restore aktual:

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

Kemudian diff file konfigurasi yang dipulihkan terhadap production untuk mengkonfirmasi tidak ada yang diam-diam hilang.

Salinan immutable dan aturan 3-2-1-1

Aturan klasik 3-2-1 (tiga salinan, dua tipe media, satu offsite) perlu update untuk era ransomware: 3-2-1-1, di mana "1" tambahan adalah salinan immutable atau air-gapped. Object lock pada penyimpanan kompatibel S3 (Wasabi, Backblaze B2, atau AWS S3 dengan Object Lock diaktifkan) mencegah penghapusan atau modifikasi untuk jendela retensi yang ditentukan, bahkan oleh akun dengan kredensial admin. Konfigurasikan dengan:

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

Mode COMPLIANCE berarti tidak ada orang, termasuk akun root, yang dapat mempersingkat retensi atau menghapus objek lebih awal. Itu penting ketika penyerang memiliki domain admin.

Ukur RTO dan RPO dengan angka nyata, bukan tebakan

Recovery Time Objective dan Recovery Point Objective terdengar seperti latihan paperwork sampai eksekutif bertanya "berapa banyak data yang kami hilangkan dan berapa lama kami down." Waktu tiga test restore terakhir Anda. Jika target RPO Anda adalah satu jam tetapi job backup hanya berjalan setiap enam, Anda memiliki celah yang didokumentasikan, dan lebih baik menemukan celah itu dalam latihan tabletop daripada selama event enkripsi aktual pada pukul 2 pagi pada hari Sabtu.

Jalankan tes, tulis waktu clock aktual, dan bandingkan dengan apa yang Anda janjikan dalam dokumen disaster recovery. Perbedaan antara dua angka itu adalah keadaan nyata rencana kontinuitas Anda.

Untuk informasi lebih lanjut tentang pengerasan sistem yang Anda lindungi dan membangun alur respons insiden, lihat segmen Blue Team dan Digital Forensics terkait di Korra Studio.