Süreklililik ve Kurtarma: Kimsenin Test Etmediği Geri Yükleme

Her yedekleme panosu yeşil onay işaretleri gösterir. İşler tamamlandı, bekletme ilkesi karşılandı, depolama alanı beklendiği gibi kullanıldı. Bunların hiçbiri, bir alan denetleyicisini gerçek bir olayda dört saatin altında çıplak metalden geri getirebilip getiremeyeceğinizi söylemez. "Yedekleme başarılı oldu" ile "geri yükleme başarılı oldu" arasındaki boşluk, çoğu süreklililik planının sessizce başarısız olduğu yerdir.

Neden onay işareti yalan söyler

Yedekleme yazılımı, bir hedefe bayt yazmayı bitirdiğinde başarıyı rapor eder. Bu baytların kullanılabilir olup olmadığını bilmez. SQL Server yedeklemesi temiz bir şekilde tamamlanabilir ve yine de geri yüklenemez çünkü işlem günlüğü zinciri üç gün önce kırılmış ve kimse bunu fark etmemiş. VM anlık görüntüleri konsolda iyi görünebilirken, temel VSS yazıcısı konuk işletim sistemi içinde sessizce başarısız olabilir ve çökmesiyle tutarlı (uygulamayla tutarlı değil) bir görüntü üretebilir.

Ransomware operatörleri bunu bilir. Geçmiş olaylarda Conti tarzı oyun kitaplarını çalıştıran gruplar kasıtlı olarak yedekleme altyapısını hedeflediler — vssadmin delete shadows /all /quiet ile gölge kopyaları sildiler, Veeam depolarını devre dışı bıraktılar, SMB üzerinden erişilebilen NAS tabanlı yedekleme hedeflerini şifrelediler. Yedeklemeleriniz üretim ile aynı ağ segmentinde yaşıyorsa ve onlara dokunabilen alan kimlik bilgileri varsa, bunlar bir güvenlik ağı değil, bir hedef olur.

Yedekleme ilkesi değil, geri yükleme runbook'u oluşturun

Süreklililik planı, normalde bunu yapan kişi olmayan biri için yazılan adım adım geri yükleme talimatlarına ihtiyaç duyar. Aşağıdakileri yazın:

• Tam kurtarma sırası (alan denetleyicileri ve DNS önce, sonra temel uygulamalar, sonra diğer her şey)
• Şifre kasanız da aşağıysa yedekleme konsolu kimlik bilgileri nerede yaşıyor
• Spesifik geri yükleme komutu veya konsol yolu, "VM'yi geri yüklemek için Veeam kullan" değil
• Sistem başına beklenen süre, satıcı pazarlama numaralarına değil, gerçek ölçülen testlere dayalı

Veeam Backup & Replication için, bu gerçek adımları belgelemeyi ifade eder: konsolu açın, Backups > Disk konumuna gidin, geri yükleme noktasına sağ tıklayın, senaryoya bağlı olarak Instant VM Recovery veya Full VM Restore seçin ve yeterli boş kapasiteye sahip hedef ana bilgisayarı seçin. Birincil ana bilgisayarınız da tehlikedeyse, zaten tanımlanan ve lisanslanan ikinci, yalıtılmış bir ana bilgisayara ihtiyacınız var.

Geri yükleme testlerini bir programa göre yapın, dürtü değil

Bir döndürme seçin. Her ay, bir kritik sistemi yalıtılmış VLAN'a geri yükleyin ve önyükleme yapıp yapamadığını, kimlik doğrulaması yapıp yapamadığını ve verileri doğru bir şekilde sunup sunmadığını doğrulayın. Her çeyrek yılda, tam kapsamlı bir test yapın: alan denetleyicinizi, dosya sunucunuzu ve birincil veritabanınızı yalıtılmış altyapıya geri yükleyin, ardından yedekleme ekibi dışında birinin oturum açmaya ve rapor çekmeye çalışmasını sağlayın.

Veritabanları için, sadece .bak dosyasını geri yüklemeyin — doğrulayın:

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

Sonra gerçekten test örneğine geri yükleyin ve DBCC CHECKDB komutunu çalıştırın. VERIFYONLY'yi geçen bir yedekleme yine de mantıksal bozulmayı içerebilir ve bu yalnızca sorgulama yaptığınızda ortaya çıkar.

Bacula veya restic gibi bir şey kullanan Linux sistemleri için gerçek geri yükleme yolunu test edin:

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

Sonra geri yüklenen yapılandırma dosyalarını üretime karşı diff edin ve hiçbir şeyin sessizce düşüp düşmediğini onaylayın.

Değişmez kopyalar ve 3-2-1-1 kuralı

Klasik 3-2-1 kuralı (üç kopya, iki ortam türü, bir şirket dışı) ransomware çağı için bir güncellemeye ihtiyaç duyar: 3-2-1-1, burada ekstra "1" değişmez veya hava geçişli olmayan bir kopyadadır. S3 uyumlu depolamada Object lock (Wasabi, Backblaze B2 veya Object Lock etkinleştirilmiş AWS S3), bir yönetici kimlik bilgilerine sahip bir hesap tarafından bile tanımlanmış bir bekletme penceresi için silmeyi veya değiştirilmeyi önler. Bunu şu şekilde yapılandırın:

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

COMPLIANCE modu, kök hesap da dahil olmak üzere kimsenin bekletmeyi kısaltamayacağı veya nesneleri erken silemeyeceği anlamına gelir. Bu, saldırganın alan yöneticisine sahip olması durumunda önemlidir.

RTO ve RPO'yu tahminlerle değil, gerçek sayılarla ölçün

Kurtarma Süresi Hedefi ve Kurtarma Noktası Hedefi, bir yönetici "ne kadar veri kaybediyoruz ve ne kadar süre kapalıyız" sorusunu soruncaya kadar evrak alışverişi gibi görünür. Son üç test geri yüklemesini saatleyin. RPO hedefleriniz bir saat olsa da yedekleme işiniz sadece altı saatte çalışıyorsa, belgelenmiş bir boşluğunuz vardır ve bu boşluğu bir masa başı alıştırmasında bulmak, Cumartesi saat 2'de gerçek bir şifreleme olayında bulmaktan daha iyidir.

Testi çalıştırın, gerçek saat saatini yazın ve bunu olağanüstü durum kurtarma belgesinde vadettiğiniz şeyle karşılaştırın. Bu iki sayı arasındaki fark, süreklililik planınızın gerçek durumudur.

Koruma altına aldığınız sistemleri sertleştirme ve olay yanıt iş akışları oluşturma hakkında daha fazla bilgi için, Korra Studio üzerindeki ilişkili Blue Team ve Digital Forensics segmentlerini kontrol edin.