Fidye yazılımına karşı yedekleme: 3-2-1 kuralı ve değiştirilemez kopya

Birçok yedek neden fidye yazılımı saldırısına dayanamıyor?

Günümüzdeki fidye yazılımı (ransomware) saldırıları nadiren doğrudan şifrelemeyle başlar. Saldırganlar çoğu zaman önce yönetici yetkisi elde eder, ardından silmek veya şifrelemek için hedefli olarak yedekleri arar. Aynı ağda bulunan ve aynı yönetici hesabıyla erişilebilen bir yedek, bu durumda canlı verilerle birlikte kaybolur.

Bir yedeğin böyle bir saldırıdan sağlam çıkması ve ardından gerçekten geri yüklenebilmesi için üç koşul gerekir: En az bir kopya çevrimdışı veya değiştirilemez olmalı, yedekleme ortamının kendine ait ayrı erişim bilgileri bulunmalı ve geri yükleme kanıtlanabilir şekilde test edilmiş olmalıdır. Bir saldırının ilk saatlerinde neler yapılması gerektiğini fidye yazılımı: ilk 24 saat yazımızda anlatıyoruz. Bu yazının konusu ise hazırlıktır.

3-2-1 kuralı ve genişletilmiş hali 3-2-1-1-0

3-2-1 kuralı uzun yıllardır yedekleme stratejilerinin temelidir. Riski, tek bir donanım arızası, yangın veya kullanıcı hatası tüm kopyaları aynı anda etkilemeyecek şekilde dağıtır. Ancak fidye yazılımına karşı tek başına artık yeterli değildir, çünkü harici kopyaya da çoğu zaman çevrimiçi olarak erişilebilir. Bu nedenle bugün genellikle genişletilmiş 3-2-1-1-0 kuralı önerilmektedir.

Belirleyici olan ikinci 1'dir. Saldırgan buluttaki kopyayı da çalınmış erişim bilgileriyle yerel kopya kadar kolay silebiliyorsa, bu harici kopya pek işe yaramaz. Uygulamada her iki 1'i de çoğu zaman aynı kopya karşılar: ek olarak değiştirilemez şekilde saklanan harici yedek.

Korunan kopya: Çevrimdışı veya değiştirilemez, ayrı erişimle

Çevrimdışı kopya

Çevrimdışı kopya ağdan fiziksel olarak ayrılmıştır; örneğin yedeklemeden sonra bağlantısı kesilen harici bir disk veya sürücüden çıkarılan bir yedekleme bandı. Buna hava boşluğu (air gap) da denir. Böyle bir kopyaya ağ üzerinden erişilemez, ancak disiplin gerektirir: Birinin diskleri veya bantları düzenli olarak değiştirmesi, etiketlemesi ve şirket dışında saklaması gerekir. Küçük işletmeler için bu çoğu zaman iyi ve uygun maliyetli bir başlangıçtır.

Değiştirilemez kopya (immutable backup)

Değiştirilemez yedeklemede depolama çevrimiçi kalır, ancak her yedek belirli bir süre boyunca değiştirmeye ve silmeye karşı kilitlenir. Bu, örneğin S3 uyumlu nesne depolama ve Object Lock ile ya da sıkılaştırılmış (hardened) yedekleme depolarıyla yapılabilir. Önemli olan, kilidin yönetici yetkisiyle bile süresinden önce kaldırılamamasıdır. Bu nedenle sağlayıcınızın böyle katı bir mod sunup sunmadığını ve bu modun gerçekten etkin olup olmadığını kontrol edin.

Yedekleme ortamı için ayrı erişim bilgileri

Birçok yedek teknik nedenlerle değil, erişim bilgileri yüzünden işe yaramaz hale gelir. Etki alanı yöneticisi hesabı yedekleme konsolunu da açabiliyorsa, çalınan tek bir hesap, verileri ve yedekleri aynı anda yok etmeye yeter. Bu yüzden yedekleme ortamını BT'nin geri kalanından net bir şekilde ayırın:

• Yedekleme yönetimi için Windows etki alanının parçası olmayan ve çok faktörlü kimlik doğrulamayla korunan ayrı hesaplar kullanın.
• Mümkünse yedekleme sunucusunu etki alanına dahil etmeyin ve yalnızca gerçekten ihtiyaç duyduğu ağ bağlantılarına izin verin.
• Şifreli yedeklerin anahtarını ayrı saklayın; örneğin şifre yöneticisinde ve ek olarak kasada kâğıt üzerinde. Anahtar olmadan özenle hazırlanmış bir yedek bile değersizdir.
• Yedekler silindiğinde, saklama süreleri kısaltıldığında veya görevler devre dışı bırakıldığında uyarı gönderilmesini sağlayın.

RPO ve RTO: Ne kadar veri kaybı ve kesinti kabul edilebilir?

İki ölçüt uygun çözümü seçmenize yardımcı olur. RPO (Recovery Point Objective, kurtarma noktası hedefi), en fazla ne kadar veri kaybedebileceğinizi zaman cinsinden ifade eder. Yedekleme gecede bir kez çalışıyorsa, en fazla 24 saatlik iş kaybolabilir. Daha az risk almak istiyorsanız daha sık, örneğin günde birkaç kez yedekleme yapın. RTO (Recovery Time Objective, kurtarma süresi hedefi) ise bir sistemin yeniden çalışır hale gelene kadar en fazla ne kadar süre devre dışı kalabileceğini tanımlar.

Her iki değeri de tüm sistemler için tek tip değil, sistem bazında ve yönetimle birlikte belirleyin. Muhasebe bir günlük kesintiyi kaldırabilir, kasa sistemi veya sipariş süreçleri ise belki yalnızca birkaç saati. Büyük veri miktarlarının buluttan geri yüklenmesinin, bant genişliğine bağlı olarak uzun sürebileceğini de unutmayın. Bu nedenle hızlı geri yükleme için yerel bir kopya ile korunan harici bir kopyanın birlikte kullanılması çoğu zaman mantıklı bir çözümdür.

Neler yedeklenmeli? Dosya sunucusundan fazlası

Bir envanter çıkarıldığında, önemli verilerin çoğu zaman klasik sunucunun dışında da bulunduğu görülür. Aşağıdaki alanlar yedekleme konseptine dahil edilmelidir:

• Sunucular ve sanal makineler: dosya sunucuları, veritabanları, ERP, muhasebe ve uygulama sunucuları; ideal olarak tam imaj şeklinde.
• Microsoft 365: Exchange posta kutuları, OneDrive, SharePoint ve Teams dosyaları. Platformu Microsoft işletir, ancak verilerinizi silinmeye, şifrelenmeye veya hatalı kullanıma karşı korumak sizin sorumluluğunuzdadır. Ayrıntılar için Microsoft 365 güvenliği yazımıza göz atabilirsiniz.
• NAS sistemleri: Çoğu zaman önemli verilerin asıl depolandığı yerdir ve bu durumda başka bir sisteme ayrı bir yedek gerekir.
• Ağ ve güvenlik cihazları: güvenlik duvarı, switch, kablosuz ağ denetleyicisi ve video kayıt cihazlarının yapılandırmaları. Bunlar olmadan sistemi yeniden kurmak çok daha uzun sürer.
• Dokümantasyon: ağ planları, acil durum el kitabı ve geri yükleme talimatları; ayrıca çevrimdışı veya basılı olarak.

Geri yüklemeyi test edin ve belgeleyin

Hiç geri yüklenmemiş bir yedek yalnızca bir varsayımdır. Verilerin eksiksiz olup olmadığını, anahtarın çalışıp çalışmadığını ve geri yüklemenin planlanan sürede tamamlanıp tamamlanmadığını ancak bir test gösterir. Basit bir test planı şöyle olabilir:

1. Her ay tek tek dosyaları, klasörleri ve bir posta kutusunu geri yükleyin.
2. Her üç ayda bir, eksiksiz bir sunucuyu yalıtılmış bir test ortamına geri yükleyin ve gereken süreyi RTO ile karşılaştırın.
3. Yedekleme raporlarını her gün kontrol edin veya otomatik olarak değerlendirilmesini sağlayın ve her uyarının nedenini araştırın.
4. Her testin sonucunu, süresini ve karşılaşılan sorunları kısaca kayda geçirin.
5. Geri yükleme talimatlarını her değişiklikten sonra güncelleyin ve bir kopyasını BT sistemlerinin dışında saklayın.

Sık yapılan hatalar ve bunlardan kaçınma yolları

• Yedeğin aynı NAS üzerinde olması: Veriler ve yedek aynı cihazdaysa, bir arıza veya şifreleme her ikisini birden yok eder. NAS üzerindeki anlık görüntüler (snapshot) faydalıdır, ancak ayrı bir kopyanın yerini tutmaz.
• Sürekli takılı USB disk: Sürekli bağlı kalan bir disk, saldırı sırasında diğer verilerle birlikte şifrelenir.
• Hiç test edilmemiş yedek: Hatalı görevler, eksik veriler veya kaybolmuş bir anahtar aksi halde ancak acil durumda fark edilir.
• Çok kısa saklama süresi: Saldırganlar çoğu zaman bir süre fark edilmeden kalır. Temiz bir duruma dönebilmek için birkaç haftaya yayılan birden fazla yedek kuşağı saklayın.
• Görmezden gelinen uyarılar: Haftalardır başarısız olan bir görev, düzenli kontrol yapılmazsa kimsenin dikkatini çekmez.

Sonuç: Bir yedek, geri yükleme başarılı olduğunda tamamlanır

Fidye yazılımına dayanıklı bir yedek tek bir ürün değildir; 3-2-1-1-0 kuralının, ayrı erişim bilgilerinin, net RPO ve RTO değerlerinin ve düzenli testlerin bir bütünüdür. Mevcut yedekleme konseptinizi kontrol ettirmek veya yeniden kurmak isterseniz Q-entra, siber güvenlik hizmeti kapsamında size destek olur. İsterseniz yönetilen güvenlik hizmetiyle yedeklerin düzenli kontrolünü ve geri yükleme testlerini de üstleniyoruz.