Veri Yedekleme Stratejisi: 3-2-1 Kuralı

"Yedeğimiz var" diyen işletmelerin çoğunda aslında tek bir harici disk ya da NAS cihazı vardır ve o cihaz bilgisayarlarla aynı odada, aynı ağda, sürekli bağlı durur. Bir fidye yazılımı, yangın ya da basit bir disk arızası hem asıl veriyi hem yedeği aynı anda götürebilir. Kısa cevap: 3-2-1 kuralı, verinizin en az üç kopyasını, iki farklı ortamda, bunlardan biri başka bir konumda olacak şekilde tutmanızı söyler. Bu yazıda kuralı bir ofise nasıl uygulayacağınızı, yedeklemeyi nasıl otomatikleştireceğinizi, fidye yazılımına karşı nasıl güçlendireceğinizi ve en çok ihmal edilen adımı, geri yükleme testini sırasıyla anlatıyoruz.

3-2-1 Kuralı Ne Söyler?

• 3 kopya: Asıl veri artı en az iki yedek. Tek yedek, yedeklemenin de başarısız olabileceği gerçeğini hesaba katmaz.
• 2 farklı ortam: Kopyalar aynı türde ve aynı arızaya açık cihazlarda durmamalı. Örneğin bir kopya ofisteki NAS'ta, diğeri bulut depolamada ya da çıkarılabilir bir diskte.
• 1 kopya başka konumda: Yangın, su baskını, hırsızlık ya da ofis ağının tamamını etkileyen bir saldırıda ayakta kalacak bir kopya.

Fidye yazılımlarının yaygınlaşmasıyla birçok kaynak kurala iki ek yapıyor ve "3-2-1-1-0" olarak anıyor: kopyalardan biri çevrimdışı ya da değiştirilemez (immutable) olmalı ve geri yükleme testlerinde sıfır hata çıkmalı. ABD siber güvenlik ajansı CISA'nın fidye yazılımı rehberi de kritik verilerin çevrimdışı ve şifreli yedeklerinin tutulmasını ve yedekleme prosedürlerinin düzenli test edilmesini öneriyor. Bu ekler, kuralı bugünün tehditlerine göre güncelleyen pratik tamamlayıcılar.

Yedek Sanılan Ama Yedek Olmayanlar

Kurulum adımlarına geçmeden önce, projelerde sık karşılaştığımız yanlış güven kaynaklarını netleştirelim:

• RAID: Bir disk bozulduğunda sistemin çalışmaya devam etmesini sağlar; silinen, şifrelenen ya da bozulan dosyayı korumaz. Siz bir dosyayı silerseniz RAID onu tüm disklerden aynı anda siler.
• Senkronizasyon klasörleri: Drive, OneDrive ya da Dropbox gibi eşitleme hizmetleri değişiklikleri anında her yere yansıtır. Fidye yazılımının şifrelediği dosyalar da buluta şifreli hâliyle eşitlenir. Sürüm geçmişi ve geri dönüşüm kutusu kısmen kurtarma sağlar ama süre ve kapsam sınırlıdır.
• Bulut uygulamasının "kendisi": Google Workspace ya da Microsoft 365 altyapının sürekliliğini sağlar, ancak bir kullanıcının ya da ele geçirilmiş bir hesabın sildiği verinin uzun süreli korunması ayrı bir konudur. Saklama ayarlarını ve gerekirse üçüncü taraf yedeği değerlendirin.
• Hosting firmasının yedeği: Yararlıdır ama kontrolünüz dışındadır: ne sıklıkla alındığını, kaç gün tutulduğunu, aynı veri merkezinde mi durduğunu çoğu zaman bilmezsiniz. Kendi bağımsız kopyanızı mutlaka tutun.

Adım Adım: Ofisiniz İçin 3-2-1 Planı

1. Veri envanteri çıkarın. Neyi koruduğunuzu bilmeden doğru planı kuramazsınız. Liste şunları içermeli: dosya sunucusu ya da paylaşımlı klasörler, muhasebe ve ERP veritabanları, web sitesi dosyaları ve veritabanı, e-posta ve bulut uygulamaları, çalışan bilgisayarlarında yerel tutulan dosyalar, telefon ve tabletlerdeki iş verileri. Her kalemin nerede durduğunu, yaklaşık boyutunu ve sahibini yazın. Kayıtlarını hâlâ Excel dosyalarında tutan ekiplerde bu envanter, verinin dağınıklığını da ortaya çıkarır; o durumda Excel'den web tabanlı uygulamaya geçiş yazımız ilgi çekici olabilir.
2. Her veri için RPO ve RTO belirleyin. RPO (kurtarma noktası hedefi) "en fazla ne kadar veri kaybını göze alabilirim?" sorusunun cevabıdır; RTO (kurtarma süresi hedefi) ise "sistem ne kadar sürede yeniden çalışmalı?" sorusunun. Örneğin muhasebe veritabanı için "en fazla 4 saatlik veri kaybı, en geç bir iş gününde geri dönüş", arşiv klasörü için "bir haftalık kayıp kabul edilebilir" gibi. Bu hedefler yedekleme sıklığını ve hangi teknolojinin gerektiğini belirler. NIST'in süreklilik planlama rehberi bu iş etkisi analizinin nasıl yapılacağını ayrıntılı anlatır.
3. Birinci yedeği yerel ve hızlı kurun. Ofisteki bir NAS ya da yedekleme sunucusu, günlük kullanımda en hızlı geri dönüşü sağlar. Bilgisayarlar ve sunucular buraya zamanlanmış görevlerle yedeklenir. Bu kopya "küçük kazalar" için: yanlışlıkla silinen dosya, bozulan bir Excel, dünkü sürüme dönme ihtiyacı.
4. İkinci yedeği farklı ortamda ve farklı konumda tutun. NAS'taki yedeği şifreli olarak bir bulut depolama hizmetine ya da başka bir şubedeki cihaza kopyalayın. Bulut kullanıyorsanız depolama bölgesini ve kişisel veriler açısından yurt dışına aktarım konusunu da değerlendirin. Bu kopya, ofisin tamamını etkileyen bir olay için.
5. Bir kopyayı çevrimdışı ya da değiştirilemez yapın. Fidye yazılımları ağdan erişebildikleri yedekleri bulup silmeye ya da şifrelemeye çalışır. Çözüm seçenekleri: dönüşümlü kullanılan ve yedekleme sonrası fiziksel olarak çıkarılan harici diskler; nesne kilitleme (object lock) ya da değiştirilemezlik özelliği olan bulut depolama; NAS üzerinde silinmeye karşı korumalı anlık görüntüler (snapshot). Çevrimdışı diskleri ofis dışında, örneğin kilitli bir dolapta ya da başka bir adreste saklayın.
6. Yedeklemeyi tamamen otomatikleştirin. "Cuma günleri elle kopyalarız" planı ilk yoğun haftada unutulur. Zamanlanmış görevler kurun ve sürüm saklama politikası belirleyin; örneğin son 14 günün günlük, son 8 haftanın haftalık ve son 12 ayın aylık yedeği. Bu kademeli saklama, fark edilmesi geç olan bozulmalarda (ör. üç hafta önce silinmiş bir klasör) geriye dönebilmenizi sağlar.
7. Yedekleri şifreleyin ve anahtarı ayrı saklayın. Ofis dışına çıkan her kopya şifrelenmiş olmalı; çalınan bir disk ya da sızdırılan bir bulut hesabı veri ihlaline dönüşmesin. Şifreleme anahtarını ya da parolasını yedeğin yanında değil, bir parola yöneticisinde ve basılı olarak güvenli bir yerde tutun. Anahtarı kaybedilmiş bir yedek, hiç olmayan bir yedekle aynıdır.
8. Yedek altyapısını ayrı kimlik bilgileriyle koruyun. Yedek sunucusunun ya da bulut hesabının yönetici şifresi, günlük kullanılan hesaplardan farklı olmalı ve iki adımlı doğrulama açık olmalı. Etki alanı yöneticisi hesabıyla yedeklere tam erişim veren yapılar, saldırganın tek hesapla her şeyi silmesine imkân tanır. Yedek konumunu çalışanların bilgisayarlarına bağlı ağ sürücüsü olarak eklemeyin.
9. İzleme ve uyarı kurun. Her yedekleme görevi başarılı ya da başarısız sonucunu e-postayla veya bir izleme panelinde bildirmeli. Başarısızlık bildirimlerinin gittiği adres gerçekten okunan bir adres olmalı; "başarılı" bildirimlerinin aniden kesilmesi de alarm sayılmalı.
10. Geri yükleme testini takvime koyun. Bu adım ayrı bir bölümü hak ediyor.

Geri Yükleme Testi: Asıl Sınav

Yedekleme yazılımının "başarılı" demesi, dosyaların geri yüklenebileceği anlamına gelmez. Bozuk arşivler, eksik veritabanı dökümleri, unutulmuş şifreleme anahtarları ve yanlış yapılandırılmış klasör filtreleri genellikle yalnızca gerçek bir geri yükleme sırasında ortaya çıkar. Bunu bir kriz anında öğrenmek istemezsiniz.

• Aylık dosya testi: Rastgele seçilen birkaç dosyayı ve bir klasörü yedekten farklı bir konuma geri yükleyin, açılıp açılmadığını kontrol edin.
• Üç aylık sistem testi: Muhasebe veritabanı ya da web sitesi gibi kritik bir sistemi test ortamında tamamen geri kurun. Ne kadar sürdüğünü ölçün; RTO hedefinize uyuyor mu?
• Yıllık felaket senaryosu: "Ofis tamamen erişilemez" varsayımıyla yalnızca dış konumdaki kopyadan geri dönüşü deneyin. Bu testte çoğu zaman eksik bir parola, belgelenmemiş bir ayar ya da yalnızca bir kişinin bildiği bir adım ortaya çıkar.
• Bütünlük kontrolü: Restic gibi yedekleme araçları depo bütünlüğünü doğrulayan kontrol komutları sunar; bunları düzenli çalıştırın.
• Test kaydı tutun: Tarih, test edilen sistem, geçen süre ve karşılaşılan sorun. Bu kayıt, hem süreci iyileştirir hem de denetimlerde işinize yarar.

Fidye Yazılımına Karşı Yedek Stratejisi

Fidye yazılımı saldırılarında amaç yalnızca dosyaları şifrelemek değil; geri dönüş yollarını da kapatmaktır. Saldırganlar çoğu zaman ağda günlerce dolaşır, yedek sunucusunu bulur ve önce onu etkisiz hâle getirir. Bu yüzden yedek stratejisi saldırının bir parçası olarak düşünülmeli:

• Erişilemez kopya: En az bir kopya ağdan fiziksel olarak ayrılmış ya da belirli bir süre boyunca silinemez olmalı.
• Uzun sürüm geçmişi: Saldırı fark edilmeden önceki temiz duruma dönebilmek için yeterince geriye giden yedekler.
• Temiz ortama geri yükleme: Saldırı sonrası yedeği, enfekte olmuş sistemlerin üzerine değil, temizlenmiş ya da yeniden kurulmuş sistemlere geri yükleyin. Giriş noktası kapatılmadan geri dönmek, aynı saldırının tekrarı demektir. Bu süreç web siteleri için site hacklendiğinde yapılacaklar yazımızda ayrıntılı anlatıldı.
• Yedeklerin de taranması: Geri yüklenecek yedeğin enfeksiyondan önceye ait olduğunu doğrulayın.

Yedekleme, fidye yazılımına karşı son savunma hattıdır; ilk hatlar ise güncellemeler, iki adımlı doğrulama, e-posta güvenliği ve çalışan farkındalığıdır. Bu önlemlerin bütününü KOBİ siber güvenlik kontrol listemizde bulabilirsiniz.

Örnek Senaryo: 12 Kişilik Bir Muhasebe Bürosu

Aşağıdaki kurgu, gerçek bir müşteri değil, bu ölçekte bir ofis için mantıklı bir başlangıç noktası örneğidir:

Bu planda NAS yalnızca yedekleme hesabı tarafından yazılabilir, çalışanların bilgisayarlarında ağ sürücüsü olarak görünmez. Aylık dosya testi ofis sorumlusunda, üç aylık tam geri kurulum testi IT partnerinde. Mali kayıtların yasal saklama süreleri gibi yükümlülükler ayrı bir başlıktır; ilgili mevzuatı mali müşavirinizle kontrol edin.

Sunucu ve Web Sitesi Yedekleri İçin Ek Notlar

• Veritabanını tutarlı yedekleyin: Çalışan bir veritabanının dosyalarını kopyalamak bozuk yedek üretebilir. Veritabanının kendi döküm aracını (ör. mysqldump, pg_dump) ya da tutarlı anlık görüntü desteğini kullanın.
• Yapılandırmayı da yedekleyin: Web sunucusu ayarları, ortam değişkenleri, cron görevleri ve SSL yapılandırması; sistemi yeniden kurarken veriler kadar önemli.
• Sunucu dışına çekin: Aynı sunucuda duran yedek, sunucu ele geçirildiğinde ya da silindiğinde işe yaramaz. Yedeği uzak bir depoya "itme" yerine, mümkünse ayrı bir sistemin sunucudan "çekmesi" saldırganın yedeğe erişimini zorlaştırır.
• Hosting modeline göre sorumluluk değişir: Paylaşımlı hosting'de panelin yedekleme aracı, VPS'te ise tamamen kendi kurduğunuz düzen geçerlidir. Bu ayrımı hosting türleri karşılaştırmamızda anlattık.

Kişisel veri içeren yedekler, asıl veriyle aynı korumayı hak eder: erişim yetkisi, şifreleme ve saklama süresi sonunda imha. Bu konudaki genel çerçeve için KVKK kontrol listemize göz atabilirsiniz.

Sık Sorulan Sorular

Bulut yedekleme tek başına yeterli mi?

Tek bir bulut kopyası 3-2-1'in yalnızca "dış konum" ayağını karşılar. Büyük veri hacimlerinde buluttan geri yükleme internet hızına bağlı olarak uzun sürebilir; yerel bir kopya, günlük küçük kurtarmalarda zaman kazandırır. İkisi birlikte daha sağlıklıdır.

Yedekleri ne kadar süre saklamalıyım?

İş ihtiyacınıza ve yasal yükümlülüklerinize göre değişir. Teknik açıdan, bir sorunun fark edilmesi haftalar sürebileceği için en az birkaç aylık geçmiş önerilir. Kişisel verilerde ise gereğinden uzun saklamak da ayrı bir risktir; saklama ve imha politikanızla uyumlu olmalı.

Harici diski ne sıklıkla değiştirmeliyim?

Dönüşümlü en az iki disk kullanın; biri ofiste yedek alırken diğeri dışarıda dursun. Haftalık değişim çoğu küçük ofis için makul bir başlangıçtır. Disklerin de ömrü vardır; düzenli test bu yüzden önemlidir.

Yedekleme yazılımı seçerken nelere bakmalıyım?

Şifreleme, sürüm saklama politikası, değiştirilemez depolama desteği, bütünlük kontrolü, başarısızlık bildirimi ve en önemlisi geri yüklemenin ne kadar kolay olduğu. Deneme sürümünde mutlaka bir geri yükleme yapın.

Fidye yazılımı yedekleri de şifrelerse ne olur?

Bu yüzden en az bir kopya çevrimdışı ya da değiştirilemez olmalıdır. Ağdan erişilebilen her kopya risk altındadır; erişilemeyen kopya ise kurtarmanın garantisidir.

Sonuç

İyi bir yedekleme stratejisi pahalı donanımla değil, doğru soruyla başlar: "Yarın sabah her şey gitse, neyi ne kadar sürede geri getirebilirim?" 3-2-1 kuralı bu sorunun cevabını sistematik hâle getirir; çevrimdışı kopya ve düzenli geri yükleme testi ise onu fidye yazılımı çağına uyarlar. Ofisinizin veri envanterini çıkarmak, RPO/RTO hedeflerini belirlemek ve otomatik, izlenen bir yedekleme altyapısı kurmak için IT hizmetlerimizden yararlanabilirsiniz. İş uygulamalarınızın yedeklenebilir ve taşınabilir bir mimaride geliştirilmesi gerekiyorsa özel yazılım ekibimizle de konuşabilirsiniz. Mevcut yedek düzeninizi birlikte gözden geçirmek için bize yazın.

Kaynaklar

• CISA – #StopRansomware Guide
• NIST SP 800-34 Rev. 1 – Contingency Planning Guide
• Restic Documentation