Bir işletmeye “Yedeğiniz var mı?” diye sorduğumuzda cevap çoğunlukla “Evet” olur. Sonraki soru ise genellikle bir sessizlik yaratır: “Son kez ne zaman geri yüklediniz?” Veri kurtarma laboratuvarında karşılaştığımız kurumsal vakaların önemli bir kısmı, yedeği hiç olmayan firmalardan değil, yedeğinin işe yaramadığını kriz anında öğrenen firmalardan gelir. Aşağıda en sık gördüğümüz yedi hatayı ve her biri için uygulanabilir bir çözümü bulacaksınız.
1. Yedekleme raporlarının sahibi yok
Yedekleme yazılımı her gece bir e-posta gönderir; bu e-posta ya kimsenin bakmadığı bir posta kutusuna düşer ya da filtrelere takılır. Bir disk dolduğunda veya bir parola değiştiğinde görev aylarca sessizce başarısız olabilir.
Çözüm: Yedeklemenin sorumlusu olarak bir kişi ve bir yedek kişi belirleyin. Başarısız görevler için ayrı ve dikkat çekici bir bildirim kanalı kurun, haftada bir de başarılı raporları gözle kontrol edin.
2. Bulut uygulamalarının “zaten yedeklendiğini” sanmak
Kurumsal e-posta, ortak takvim ve çevrim içi ofis dosyaları için kullanılan bulut hizmetleri, kendi altyapılarının çalışmasından sorumludur. Bir çalışanın yanlışlıkla sildiği klasör, ayrılan bir personelin kapatılan hesabı ya da ele geçirilen bir hesabın verdiği zarar ise çoğu zaman kullanıcı tarafının sorumluluğundadır. Hizmetin geri dönüşüm süresi dolduğunda bu veriler kalıcı olarak gidebilir.
Çözüm: Kullandığınız bulut hizmetlerinin saklama ve geri yükleme koşullarını okuyun; kritik posta kutuları ve paylaşılan alanlar için hizmetten bağımsız bir yedekleme çözümü değerlendirin.
3. Saklama süresinin çok kısa olması
Yalnızca son yedi günü tutan bir düzen, sorun yedinci günden sonra fark edildiğinde işe yaramaz. Bozulan bir muhasebe dosyası ya da sessizce şifrelenen bir arşiv klasörü haftalarca kimsenin dikkatini çekmeyebilir; o süre içinde her yedek bozuk sürümü kopyalar.
Çözüm: Günlük kopyaların yanında haftalık ve aylık kopyaları da daha uzun süre saklayın. Ne kadar geriye gitmeniz gerekebileceğini, sektörünüzün kayıt saklama yükümlülükleriyle birlikte düşünün.
4. Yedeğe, sistemle aynı anahtarla girilebilmesi
Yedek sunucusuna veya NAS’a etki alanı yöneticisi hesabıyla erişilebiliyorsa, o hesabı ele geçiren bir saldırgan yedekleri de silebilir ya da şifreleyebilir. Fidye yazılımı vakalarında sık rastlanan senaryo budur.
Çözüm: Yedekleme ortamı için ayrı, yalnızca o iş için kullanılan hesaplar tanımlayın ve iki aşamalı doğrulama kullanın. Kopyalardan en az biri ağdan kopuk ya da değiştirilemez olsun. Saldırı sonrası yapılacaklar için fidye yazılımı veri kurtarma sayfamıza bakabilirsiniz.
5. Yalnızca dosyaları yedekleyip sistemi unutmak
Muhasebe verileri yedekte duruyor olabilir; peki programın kurulumu, lisans bilgileri, sunucunun ayarları, yazıcı ve kullanıcı tanımları? Sıfırdan kurulan bir sunucuda verileri geri yüklemek, bazen günler süren bir yapılandırma işinin yalnızca son adımıdır. Veritabanlarının da tutarlı biçimde yedeklenmesi gerekir; çalışırken kopyalanan bir veritabanı dosyası açılmayabilir.
Çözüm: Kritik sunucular için sistemin tamamını geri getirebilen imaj tabanlı yedek alın ve veritabanlarını kendi araçlarıyla yedekleyin. Bozulan veritabanları için veritabanı kurtarma sayfamızda bilgi bulabilirsiniz.
6. Dizüstüleri ve sahadaki cihazları kapsam dışı bırakmak
Satış ekibinin teklif dosyaları, mühendislerin saha ölçümleri, yöneticinin dizüstündeki sunumlar çoğu zaman ortak sunucuya hiç ulaşmaz. Çalınan veya sıvı dökülen bir dizüstü, şirketin en güncel bilgilerini de yanında götürebilir. Sıvı vakalarında ilk adımları laptopa su döküldü yazımızda anlattık.
Çözüm: Taşınabilir cihazları merkezi yedekleme kapsamına alın ya da çalışma klasörlerinin otomatik olarak şirket depolama alanına eşitlenmesini sağlayın. Disk şifrelemesi kullanıyorsanız kurtarma anahtarlarını merkezi olarak kayıt altına alın; neden önemli olduğunu BitLocker yazımızda açıkladık.
7. Kriz anı için yazılı bir plan olmaması
Sunucu çöktüğünde kim kimi arayacak, yedekler nerede, şifreleme parolası kimde, hangi sistem önce ayağa kaldırılacak? Bu soruların cevabı yalnızca bir kişinin aklındaysa ve o kişi izindeyse, en iyi yedek bile geç devreye girer. Bir başka sık rastlanan durum: yedeklerin şifre çözme anahtarı, tam da çöken sunucunun içinde saklanmaktadır.
Çözüm: Bir iki sayfalık bir kurtarma planı hazırlayın; iletişim listesini, kritik sistemlerin öncelik sırasını ve erişim bilgilerinin güvenli olarak nerede tutulduğunu yazın. Yılda en az bir kez masa başı bir tatbikatla planı sınayın.
Yedekler de kişisel veridir
Yedekleriniz müşteri, personel veya hasta bilgisi içeriyorsa, asıl sistemle aynı özenle korunmalıdır. Şifrelenmemiş bir yedek diskin kaybolması da bir veri ihlali olabilir. İşin bu boyutunu KVKK ve gizlilik başlıklı yazımızda inceledik. NAS tabanlı yedekleme kullanıyorsanız NAS cihazınız açılmıyorsa yazımız da işinize yarayabilir.
Tüm önlemlere rağmen yedek eksik çıkarsa, arızalı sistemler üzerinde deneme yapmadan önce bize ulaşın. Bursa’daki laboratuvarımızda şirket verileri, istendiğinde imzalanan bir gizlilik sözleşmesi çerçevesinde ve sadece kurtarma amacına yönelik olarak ele alınır. Kurumsal süreç için kurumsal veri kurtarma sayfamıza bakabilirsiniz.
Sık sorulan sorular
Yedeklerimizin çalıştığını nasıl anlarız?
Tek güvenilir yol geri yükleme denemesidir. Belirli aralıklarla rastgele dosyaları ve en az bir kritik sistemi, canlı ortamı etkilemeyecek şekilde ayrı bir yere geri yükleyip açılıp açılmadığını kontrol edin.
Küçük bir işletmeyiz; bu önlemlerin hepsine gerçekten gerek var mı?
Ölçek küçüldükçe çözümler sadeleşir ama ilkeler değişmez. Bir sorumlu kişi, ayrı tutulan bir kopya, makul bir saklama süresi ve ara sıra yapılan bir geri yükleme testi, küçük ofislerde de büyük farkı yaratır.
Yedekleme düzenimizi gözden geçirmemize yardım eder misiniz?
Bilgi güvenliği ve KVKK danışmanlığı da verdiğimiz hizmetler arasında. İhtiyacınızı konuşmak için bizimle iletişime geçebilirsiniz.