Çevrimiçi yedek neden tek başına yeterli olmayabilir?
Ağa sürekli bağlı yedekleme depoları operasyon açısından hızlı ve pratiktir. Ancak saldırgan yedekleme yazılımının yönetim hesabına veya depolama altyapısına erişirse kopyaları silmeye, şifrelemeye veya saklama politikalarını değiştirmeye çalışabilir.
Bu nedenle en az bir kopyanın üretim ağına sürekli erişilebilir olmaması veya belirli süre boyunca değiştirilememesi, saldırı etkisini sınırlandırmaya yardımcı olur.
Çevrimdışı ve değiştirilemez yedek farkı
Çevrimdışı kopya, normal operasyon sırasında ağa bağlı olmayan veya erişimi kesilmiş bir ortamda tutulur. Değiştirilemez (immutable) yedek ise belirlenen saklama süresi içinde verinin değiştirilmesini veya silinmesini engelleyen teknik ve idari korumalar kullanır.
Her iki yaklaşım aynı şey değildir. Bulut depolamada nesne kilidi veya saklama kilidi gibi seçenekler olabilir; ancak yönetim hesabının yetkileri, kilidin geri alınabilirliği ve saklama süresi ayrıntılı incelenmelidir.
Yedekleme hesabı ve erişim ayrımı
Yedekleme yönetim hesabını günlük kullanıcı hesabından ayırın. Yönetim erişiminde MFA, ayrıcalıklı erişim yönetimi ve işlem kaydı kullanın. Üretim etki alanı yöneticilerinin yedekleri silebilmesini veya saklama kilidini kaldırabilmesini önleyecek ayrı kontrol noktaları tasarlayın.
Yedekleme altyapısının işletim sistemi, ajanları ve yönetim konsolunu güncel tutun. İnternete açık yönetim portlarını sınırlandırın ve servis hesaplarının parolalarını güvenli biçimde yönetin.
Yedeklerin kapsamı ve saklama takvimi
Dosya sunucuları, veritabanları, sanal makineler, yapılandırma dosyaları, kimlik altyapısı ve kritik uygulamaların hangi sırayla korunacağını belirleyin. Yalnızca kullanıcı dosyalarını değil, sistemi yeniden kurmak için gereken yapılandırma ve lisans bilgilerini de düşünün.
Günlük, haftalık ve aylık kopyaların saklama süresi kurumun mevzuat, operasyon ve veri kaybı toleransına göre belirlenmelidir. Saklama süresini gereksiz büyütmek maliyeti artırır; çok kısa tutmak ise olayın geç fark edildiği durumlarda temiz kopya bulmayı zorlaştırabilir.
Geri yükleme tatbikatı nasıl yapılır?
Yedekleme raporunda işin başarılı görünmesi, gerçek bir kurtarma sürecinin tamamlanabildiğini tek başına göstermez. İzole bir test ortamında dosya, sunucu ve uygulama geri yüklemesi yaparak bütünlüğü ve çalışabilirliği kontrol edin.
Fidye yazılımı sonrasında temiz sistemlere dönüşte enfekte olabilecek makineleri yedekten hemen üretim ağına bağlamayın. Önce olayın kapsamı belirlenmeli, temiz kurulum ve kimlik bilgilerinin yenilenmesi gibi adımlar uygulanmalıdır.
İş sürekliliği planına bağlayın
Kritik iş süreçlerini, bağımlı uygulamaları ve geri dönüş önceliklerini yazılı hale getirin. Hangi hizmetin önce ayağa kalkacağı, kimlerin onay vereceği ve kullanıcıların ne zaman bilgilendirileceği olay öncesinde belirlenmelidir.
CISA, kritik veriler için çevrimdışı ve şifrelenmiş yedek tutulmasını ve yedeklerin düzenli olarak test edilmesini önerir. Kurumun planı kendi sistemleri, veri türleri ve operasyonel risklerine göre uygulanmalıdır.
Sıkça sorulan sorular
Immutable yedek fidye yazılımından tamamen korur mu?
Hayır. Değiştirilemez kopya silme veya değiştirme riskini azaltabilir; ancak hesap ele geçirilmesi, veri sızıntısı, yanlış yapılandırma ve geri yükleme süreci gibi diğer riskler için ek kontroller gerekir.
Bulut yedek her zaman çevrimdışı mıdır?
Hayır. Bulut yedekleme çoğu zaman ağ üzerinden erişilen bir hizmettir. Değiştirilemez saklama, ayrı hesap ve çevrimdışı kopya seçeneklerinin gerçekten uygulanıp uygulanmadığı kontrol edilmelidir.
Yedek geri yükleme testi ne sıklıkta yapılmalı?
Kritiklik, veri değişim hızı ve iş sürekliliği gereksinimlerine göre belirlenmelidir. Kritik sistemlerde düzenli ve belgelenmiş testler yapılmalı, sistem değişikliklerinden sonra plan yeniden doğrulanmalıdır.