Fidye Yazılımına Karşı Yedekleme ve Felaket Kurtarma

Bir işletmenin bütün bilgisayarları çalışıyor, sunucuları sorunsuz hizmet veriyor ve günlük yedekleme görevleri başarıyla tamamlanıyor olabilir.

Ancak bu tablo tek başına kurumun veri kaybına karşı hazır olduğunu göstermez.

Fidye yazılımı saldırısı, donanım arızası, yanlışlıkla silinen dosyalar veya altyapı kesintisi yaşandığında asıl soru şudur:

Yedeklerimizden sistemlerimizi güvenli ve kabul edilebilir sürede geri yükleyebiliyor muyuz?

Kurumsal yedekleme stratejisi yalnızca veri kopyalamaktan ibaret değildir. Verinin korunması, yedeklerin saldırılara karşı güvenliği, düzenli testler ve iş sürekliliği planlaması birlikte değerlendirilmelidir.

Fidye yazılımı nedir?

Fidye yazılımı (ransomware), sistemlere veya verilere erişimi engellemek ve çoğunlukla ödeme talep etmek amacıyla kullanılan zararlı yazılım türlerini ifade eder.

Bazı saldırılarda veriler şifrelenirken, bazı olaylarda veri sızdırma ve farklı baskı yöntemleri de kullanılabilir.

Bir fidye yazılımı saldırısı yalnızca kullanıcı bilgisayarlarını değil; dosya sunucularını, sanal makineleri, yedekleme altyapısını ve ağ üzerindeki başka sistemleri de etkileyebilir.

Bu nedenle işletmelerin hem saldırıyı önlemeye hem de olası bir olaydan sonra güvenli şekilde toparlanmaya yönelik planları bulunmalıdır.

Neden yalnızca yedek almak yeterli değildir?

Bir yedekleme yazılımının her gece başarılı rapor vermesi olumlu bir göstergedir.

Ancak şu soruların da yanıtlanması gerekir:

• Yedek dosyaları gerçekten açılabiliyor mu?
• Kritik uygulamalar tutarlı şekilde geri yüklenebiliyor mu?
• Yedekler saldırganın erişebildiği aynı hesaplarla silinebiliyor mu?
• Yedekleme sunucusunun kendisi korunuyor mu?
• Bütün sistemleri geri yüklemek ne kadar sürüyor?
• Yedeklerden geri yüklenen sistemler temiz mi?

Bu soruların yanıtı bilinmiyorsa yedekleme stratejisinde önemli boşluklar bulunabilir.

3-2-1 yedekleme kuralı nedir?

3-2-1 kuralı, veri koruma planlamasında yaygın olarak kullanılan yaklaşımlardan biridir.

Temel mantığı şöyledir:

3 kopya: Verinin asıl kopyasıyla birlikte toplam en az üç kopya bulunması hedeflenir.

2 farklı ortam: Kopyaların tek bir depolama arızasından birlikte etkilenmesini azaltacak şekilde farklı ortam veya teknolojiler kullanılır.

1 farklı lokasyon: Kopyalardan en az birinin farklı bir fiziksel veya mantıksal konumda tutulması hedeflenir.

Bu yaklaşım faydalıdır ancak tek başına fidye yazılımına karşı bütün riskleri ortadan kaldırmaz.

Özellikle yedeklerin silinmeye, değiştirmeye veya yetkisiz erişime karşı korunması gerekir.

Immutable backup nedir?

Immutable backup, belirlenen koruma koşulları ve süreleri boyunca yedek verilerin değiştirilmesini veya silinmesini zorlaştıran ya da engelleyen mekanizmaları ifade eder.

Bu özellik farklı depolama ve yedekleme teknolojilerinde farklı yöntemlerle sağlanabilir.

Örneğin belirli nesne depolama hizmetlerinde nesne kilitleme veya değiştirilemez saklama özellikleri bulunabilir.

Ancak immutable özelliğinin etkin olması, yanlış yapılandırma veya yetki sorunları nedeniyle bütün risklerin ortadan kalktığı anlamına gelmez.

Kullanılan depolamanın koruma modeli, yönetici yetkileri ve kurtarma süreçleri değerlendirilmelidir.

Offline backup neden önemlidir?

Offline backup, yedek kopyasının belirli koşullarda üretim ağı ve erişilebilir sistemlerden ayrılmış biçimde saklanması yaklaşımıdır.

Bu yöntem, saldırganın ağ üzerinden erişebildiği sistemlerin kapsamını azaltmaya yardımcı olabilir.

Ancak çevrimdışı yedeklerin de fiziksel korunması, güncelliği, şifrelenmesi ve geri yüklenebilirliği önemlidir.

Kurumun ihtiyacına göre offline, immutable veya farklı koruma yöntemleri birlikte kullanılabilir.

RPO ve RTO nedir?

Yedekleme ve felaket kurtarma planlarında iki kavram özellikle önemlidir.

RPO — Recovery Point Objective

RPO, bir kesintide kabul edilebilir veri kaybı süresini ifade eder.

Örneğin RPO hedefi bir saat olarak belirlenmişse sistemin veri koruma planı buna uygun tasarlanmalıdır.

Bu bir garanti değil, iş gereksiniminden hareketle belirlenen hedeftir.

RTO — Recovery Time Objective

RTO, bir sistemin veya iş sürecinin kabul edilebilir sürede yeniden çalışır duruma getirilmesi için belirlenen hedeftir.

Örneğin bir ERP sistemi için dört saatlik RTO hedefi varsa yedekleme, altyapı ve kurtarma planı bu hedefe göre değerlendirilmelidir.

RPO ile RTO farklı kavramlardır.

Çok sık yedek almak, sistemin mutlaka çok hızlı geri yüklenebileceği anlamına gelmez.

Veeam ve Acronis gibi yedekleme çözümlerinde nelere dikkat edilmeli?

Kurumsal yedekleme altyapılarında Veeam, Acronis ve diğer ürünler farklı kullanım senaryolarında değerlendirilebilir.

Ürün seçimi kadar yapılandırma da önemlidir.

Dikkat edilmesi gereken konular şunlardır:

• Korunacak sistemlerin envanteri
• Sanal ve fiziksel sunucu desteği
• Veritabanı ve uygulama tutarlılığı
• Yedekleme sıklığı
• Saklama politikaları
• Koruma ve erişim yetkileri
• Yedeklerin farklı lokasyonlara aktarılması
• Geri yükleme performansı
• Güncelleme ve güvenlik yönetimi
• İzleme ve hata bildirimi

Kullanılacak özelliklerin ürün sürümü ve lisans kapsamında doğrulanması gerekir.

VMware ve Proxmox ortamlarında yedekleme

Sanallaştırma platformları, işletmelerin birden fazla sunucuyu aynı fiziksel altyapı üzerinde yönetmesine imkân verir.

Ancak sanal makinelerin bulunması, bu makinelerin yeterince korunduğu anlamına gelmez.

VMware veya Proxmox tabanlı altyapılarda sanal makinelerin, yapılandırmaların, uygulama verilerinin ve gerekiyorsa başka kritik bileşenlerin yedeklenmesi planlanmalıdır.

Özellikle Active Directory, dosya sunucuları, veritabanları ve ERP sistemleri için uygulama tutarlılığı ve geri yükleme yöntemi değerlendirilmelidir.

Bir sanal makinenin açılabilmesi, içerisindeki uygulamaların doğru çalıştığını tek başına kanıtlamaz.

Bulut yedekleme güvenli mi?

Bulut yedekleme, uygun mimariyle güçlü bir veri koruma seçeneği olabilir.

Ancak güvenlik düzeyi; erişim yetkileri, şifreleme, yedeklerin izolasyonu, depolama politikaları ve izleme gibi kontrollerle ilişkilidir.

Kurum içi yedekler güvenli, bulut yedekler güvensiz şeklinde bir ayrım doğru değildir.

Her iki ortamda da doğru yapılandırma ve düzenli doğrulama önemlidir.

Bulut ve kurum içi altyapılar, ihtiyaca göre birlikte de kullanılabilir.

Yedekleme geri dönüş testi nasıl yapılır?

Yedekleme sisteminin güvenilirliğini değerlendirmek için geri yükleme testleri uygulanmalıdır.

Örnek bir test planı şu adımları içerebilir:

1. Test edilecek kritik sistem belirlenir.
2. Uygun ve izole test ortamı hazırlanır.
3. Belirli bir tarihe ait yedek seçilir.
4. Veri veya sistem geri yüklenir.
5. Dosyaların ve uygulamaların bütünlüğü kontrol edilir.
6. Gerekli servislerin çalıştığı doğrulanır.
7. Geri dönüş süresi ölçülür.
8. Sonuçlar raporlanır ve eksikler için iyileştirme planı hazırlanır.

Test ortamının üretim sistemlerini etkilememesi gerekir.

Özellikle fidye yazılımı sonrasında geri yükleme yapılacaksa yedeklerin ve kurtarılacak sistemlerin güvenlik açısından değerlendirilmesi önemlidir.

Felaket kurtarma planı nedir?

Felaket kurtarma planı (Disaster Recovery Plan), önemli bir kesintinin ardından BT sistemlerinin nasıl geri döndürüleceğini tanımlar.

Bu plan genellikle şu bilgileri içerir:

• Kritik sistemlerin öncelik sırası
• Sistemler arasındaki bağımlılıklar
• Kurtarma sorumluları
• Alternatif erişim ve iletişim yöntemleri
• Yedekleme kaynakları
• RPO ve RTO hedefleri
• Kurtarma adımları
• Test ve raporlama süreçleri

Örneğin Active Directory hizmeti çalışmadan bazı uygulamaların kimlik doğrulaması tamamlanamayabilir.

Bu nedenle kurtarma sırası yalnızca sunucuların önem derecesine değil, birbirlerine olan bağımlılıklarına göre de belirlenmelidir.

Kurumsal yedekleme için kontrol listesi

1. Bütün kritik sistemler yedekleniyor mu?
2. Yedekler yetkisiz silme ve değiştirmeye karşı korunuyor mu?
3. Farklı konumda veya farklı koruma katmanında kopyalar bulunuyor mu?
4. Yedekleme hesapları ve yönetici erişimleri güvenli mi?
5. Geri yükleme testleri düzenli yapılıyor mu?
6. RPO ve RTO hedefleri belirlendi mi?
7. Son testin sonuçları kayıt altına alındı mı?
8. Bir fidye yazılımı olayında temiz kurtarma planı var mı?

Bu sorulara verilen yanıtlar, yedekleme stratejisinin gerçek dayanıklılığını değerlendirmek için başlangıç noktası oluşturur.

RelGen Teknoloji ile yedekleme ve felaket kurtarma

RelGen Teknoloji, işletmelerin mevcut sunucu ve veri altyapısını değerlendirerek yedekleme, veri koruma ve felaket kurtarma gereksinimlerinin belirlenmesine yardımcı olur.

Windows Server, sanallaştırma, kurumsal depolama, bulut altyapısı, yedekleme çözümleri ve geri yükleme süreçleri birlikte değerlendirilebilir.

Amaç, yalnızca başarılı yedekleme raporları üretmek değil; gerektiğinde kritik sistemlerin güvenilir biçimde yeniden çalıştırılabilmesini sağlamaktır.

BT Hizmetlerimizi inceleyebilir veya RelGen Teknoloji ile iletişime geçerek mevcut yedekleme altyapınızı değerlendirebilirsiniz.

Sık sorulan sorular

Fidye yazılımı yedekleri de şifreleyebilir mi?

Evet. Saldırganın erişebildiği yedekleme sistemleri ve bağlı depolama alanları etkilenebilir. Bu nedenle yedeklerin korunması ve izolasyonu önemlidir.

Her gün yedek almak yeterli midir?

Her işletme için yeterli olmayabilir. Veri kaybı toleransı, kritik sistemler ve RPO hedefi değerlendirilmelidir.

Yedekleme testi ne sıklıkla yapılmalı?

Tek bir doğru süre yoktur. Sistemin kritikliğine, değişiklik sıklığına ve risk seviyesine göre test programı oluşturulmalıdır.

Yedekleme ile felaket kurtarma aynı şey mi?

Hayır. Yedekleme veri koruma mekanizmalarından biridir. Felaket kurtarma ise sistemlerin ve iş süreçlerinin yeniden çalışmasını hedefleyen daha geniş bir planlama sürecidir.

Teknik kaynak: CISA — StopRansomware Guide