Kapsamda neler var?
- Sistem envanteri ve mevcut yedeklerin ön değerlendirmesi
- Sistem bazında RTO ve RPO hedeflerinin belirlenmesi
- 3-2-1-1-0 kuralına uygun yedekleme mimarisi tasarımı
- Değiştirilemez (immutable) ve lokasyon dışı kopyaların kurgulanması
- Yedekleme konsolunun MFA ve ayrı kimlik bilgileriyle korunması
- İlk tam geri yükleme testi ve sonuç raporu
- Felaket kurtarma runbook'u ve test takvimi
- Kurulum sonrası dokümantasyon ve devir
Yedekleme ve felaket kurtarma arasındaki fark nedir?
Yedekleme, verinin bir kopyasını başka bir yerde saklamaktır; felaket kurtarma (DR, Disaster Recovery) ise bir kesinti sonrasında sistemlerin ve iş süreçlerinin ne kadar sürede ve hangi sırayla yeniden çalışır hale getirileceğinin planıdır. Yedeğiniz olabilir ama sunucuları, ağı ve uygulamaları hangi sırayla ayağa kaldıracağınızı bilmiyorsanız kesinti beklenenden çok daha uzun sürebilir.
Fidye yazılımı, donanım arızası, yangın veya su baskını, yanlışlıkla silinen veriler ve hatalı güncellemeler felaket kurtarma planının kapsaması gereken tipik senaryolardır.
Fidye yazılımına karşı yedekleme neden farklı düşünülmeli?
Fidye yazılımı saldırılarında saldırganlar verileri şifrelemeden önce genellikle yedekleri bulmaya ve silmeye çalışır. Yedekleme sunucusu domain'e üye ise, yedek deposu ağ paylaşımı olarak erişilebilir durumdaysa veya yedekleme konsolunun parolası domain yönetici parolasıyla aynıysa, yedekler de üretim verisiyle birlikte kaybedilebilir.
Bu yüzden fidye yazılımına dayanıklı bir yedekleme mimarisinde şu ilkeler öne çıkar:
- Yedekleme altyapısının üretim domain'inden ayrılması veya ayrı kimlik bilgileriyle yönetilmesi
- Yedekleme konsoluna erişimde MFA kullanılması
- En az bir yedek kopyanın değiştirilemez (immutable) veya çevrim dışı (offline) olması
- Yedek silme ve saklama süresi değiştirme işlemlerinin kayıt altına alınması ve izlenmesi
3-2-1-1-0 yedekleme kuralı nedir?
3-2-1 yedekleme kuralı, verinin en az üç kopyasının, iki farklı ortamda ve bir kopyanın farklı bir lokasyonda tutulmasını öngörür. Fidye yazılımı riskine karşı bu kural 3-2-1-1-0 olarak genişletilmiştir:
| Rakam | Anlamı | Pratikte örnek |
|---|---|---|
| 3 | Verinin en az üç kopyası | Üretim verisi + iki yedek |
| 2 | En az iki farklı depolama ortamı | Disk tabanlı yedek deposu + nesne depolama veya teyp |
| 1 | En az bir kopya farklı lokasyonda | Başka bir şube, veri merkezi veya bulut |
| 1 | En az bir kopya değiştirilemez veya çevrim dışı | Değiştirilemez depolama, ağdan ayrılmış teyp veya disk |
| 0 | Doğrulamada sıfır hata | Yedeklerin otomatik doğrulanması ve düzenli geri yükleme testleri |
Immutable (değiştirilemez) yedekleme nedir?
Immutable yedekleme, yazıldıktan sonra belirlenen saklama süresi dolana kadar silinemeyen ve değiştirilemeyen yedektir. Saldırgan yönetici yetkisi ele geçirse bile bu kopyayı şifreleyemez veya silemez. Değiştirilemezlik; nesne depolamadaki kilit özellikleri, sertleştirilmiş Linux tabanlı yedek depoları veya bu özelliği sunan yedekleme cihazları ile sağlanabilir. Saklama süresinin, bir saldırının fark edilmesi için gereken süreyi kapsayacak kadar uzun seçilmesi önemlidir.
Çevrim dışı (offline / air-gapped) kopya ise ağ bağlantısı fiziksel veya mantıksal olarak kesilmiş yedektir. Teyp veya dönüşümlü olarak bağlanan diskler bu amaçla kullanılabilir.
RTO ve RPO nedir?
RTO ve RPO, felaket kurtarma planının iki temel hedefidir ve her sistem için ayrı belirlenir. İş birimleriyle birlikte "bu sistem ne kadar süre kapalı kalabilir ve ne kadarlık veri kaybını tolere edebiliriz?" soruları cevaplanarak tanımlanır.
| Kavram | Sorduğu soru | Neyi belirler? |
|---|---|---|
| RTO (Recovery Time Objective, kurtarma süresi hedefi) | Sistem en fazla ne kadar süre kapalı kalabilir? | Kurtarma yöntemi: yerinde geri yükleme, yedek ortamda çalıştırma, ikincil lokasyon |
| RPO (Recovery Point Objective, kurtarma noktası hedefi) | En fazla ne kadarlık veri kaybı kabul edilebilir? | Yedekleme sıklığı ve replikasyon ihtiyacı |
Örneğin ERP veritabanı için RPO birkaç saat kabul edilebilirken, dosya sunucusu için günlük yedek yeterli görülebilir. RTO ve RPO kısaldıkça gereken altyapı ve maliyet artar; bu yüzden her sistem için aynı hedefi koymak yerine iş önceliğine göre sınıflandırma yapılır.
Geri yükleme testi neden şarttır?
Test edilmemiş bir yedek, çalışacağı varsayılan bir yedektir. Yedekleme işinin "başarılı" görünmesi, verinin gerçekten ve beklenen sürede geri yüklenebileceği anlamına gelmez. Düzenli testlerde şunlar kontrol edilir:
- Rastgele seçilen dosyaların ve klasörlerin geri yüklenmesi
- Kritik sunucuların yalıtılmış bir ortamda tamamen ayağa kaldırılması
- Veritabanlarının tutarlı şekilde açılıp uygulamanın çalışması
- Gerçekleşen geri yükleme süresinin RTO hedefiyle karşılaştırılması
- Kurtarma adımlarının yazılı runbook (işletim kılavuzu) ile uyumu
Bulut yedekleme mi, yerel yedekleme mi?
İkisi birbirinin alternatifi değil, tamamlayıcısıdır. Yerel yedek deposu hızlı geri yükleme sağlar ve kısa RTO hedefleri için uygundur. Bulut yedekleme ise lokasyon dışı kopya ihtiyacını karşılar; yangın, hırsızlık veya bina erişiminin kaybı gibi senaryolarda verinin erişilebilir kalmasını sağlar. Bulut kopyasında değiştirilemezlik özelliği, saklama süresi ve büyük veri setlerinin geri indirilmesi için gereken süre ayrıca hesaplanmalıdır. Kişisel veri içeren yedeklerde verinin saklandığı konum ve şifreleme de değerlendirilir.
Felaket kurtarma planında neler bulunmalı?
Felaket kurtarma planı, kriz anında kimin neyi hangi sırayla yapacağını önceden belirleyen yazılı bir dokümandır. Kriz anında karar vermek yerine plana bakmak, kesinti süresini kısaltır ve hataları azaltır. Planda en az şu başlıklar yer almalıdır:
- Sistemlerin kurtarma önceliği ve bağımlılıkları (ör. önce domain controller, sonra veritabanı, sonra uygulama)
- Her sistem için RTO ve RPO hedefleri
- Yedeklerin konumu, erişim bilgilerinin güvenli saklanma yeri ve geri yükleme adımları
- Sorumlu kişiler, yedekleri ve iletişim bilgileri
- Fidye yazılımı senaryosunda temiz bir ortamda kurtarma ve yeniden enfeksiyonun önlenmesi
- İş birimleri, yönetim ve gerekirse müşterilerle iletişim adımları
Kişisel veri içeren sistemlerde bir ihlal yaşanırsa, KVKK kapsamında Kurul'a bildirimin en kısa sürede ve en geç 72 saat içinde yapılması gerektiği de planda hatırlatılmalıdır.
Kimler için uygun?
- Yedeği olan ama hiç geri yükleme testi yapmamış kurumlar
- Yedekleri aynı ağda, aynı domain yetkileriyle erişilebilir şekilde tutan şirketler
- ERP, muhasebe, üretim planlama veya hasta kayıt sistemleri gibi kesintiye hassas uygulamaları olan işletmeler
- Microsoft 365 veya Google Workspace verilerinin ayrıca yedeklenmesi gerektiğini değerlendiren kurumlar
- Siber sigorta, denetim veya ISO/IEC 27001 kapsamında yedekleme ve süreklilik kanıtı istenen firmalar
Süreç nasıl işler?
- Envanter ve önceliklendirme: Sunucular, uygulamalar, veritabanları ve bulut verileri listelenir; her biri için iş önceliği belirlenir.
- RTO / RPO tanımı: İş birimleriyle birlikte her sistem için hedefler kararlaştırılır.
- Mevcut yedeklerin değerlendirilmesi: Kapsam boşlukları, saklama süreleri ve fidye yazılımına karşı zayıf noktalar tespit edilir.
- Mimari tasarım: 3-2-1-1-0 kuralına uygun, değiştirilemez ve lokasyon dışı kopyaları içeren yapı planlanır.
- Kurulum ve yapılandırma: Yedekleme yazılımı, depolama ve iş tanımları devreye alınır; konsol erişimi MFA ile korunur.
- Geri yükleme testi: İlk tam test yapılır, sonuçlar RTO hedefleriyle karşılaştırılır.
- Runbook ve devir: Felaket senaryolarına göre kurtarma adımları, sorumlular ve test takvimi dokümante edilir.
Yedekleme, saldırıyı önlemez ama saldırıdan sonra ayağa kalkmanızı sağlar. Saldırı yüzeyini azaltmak için uç nokta güvenliği (EDR/XDR) ve kimlik ve erişim yönetimi, altyapının düzenli bakımı için ise güvenlik altyapısı bakım ve destek hizmetimizi inceleyebilirsiniz.
Mevcut yedeklerinizi ve kurtarma hedeflerinizi birlikte değerlendirelim: yedekleme ve felaket kurtarma için teklif isteyin.
Yedekleme ve Felaket Kurtarma: sık sorulanlar
3-2-1 yedekleme kuralı nedir?
3-2-1 kuralı, verinin en az üç kopyasının iki farklı depolama ortamında tutulmasını ve bir kopyanın farklı bir lokasyonda bulunmasını öngörür. Fidye yazılımı riskine karşı bu kural 3-2-1-1-0 olarak genişletilmiştir. Ek kurallar, bir kopyanın değiştirilemez veya çevrim dışı olmasını ve yedek doğrulamasında hata olmamasını ifade eder.
Immutable yedekleme nedir?
Immutable yedekleme, belirlenen saklama süresi dolana kadar silinemeyen ve değiştirilemeyen yedektir. Saldırgan yönetici yetkisi ele geçirse bile bu kopyayı şifreleyemez. Nesne depolama kilitleri, sertleştirilmiş yedek depoları veya bu özelliği sunan cihazlarla sağlanabilir.
RTO ve RPO arasındaki fark nedir?
RTO, bir sistemin kesinti sonrası en fazla ne kadar sürede yeniden çalışır hale gelmesi gerektiğini ifade eder. RPO ise kabul edilebilir en fazla veri kaybı süresidir ve yedekleme sıklığını belirler. Her iki hedef de iş birimleriyle birlikte, sistem bazında tanımlanır.
Fidye yazılımı yedekleri de şifreleyebilir mi?
Evet, yedekler ağdan erişilebilir durumdaysa ve aynı yönetici kimlik bilgileriyle yönetiliyorsa saldırgan tarafından silinebilir veya şifrelenebilir. Bu yüzden yedekleme altyapısı üretim ortamından ayrılmalı, konsol MFA ile korunmalı ve en az bir kopya değiştirilemez veya çevrim dışı tutulmalıdır.
Microsoft 365 verilerini ayrıca yedeklemek gerekir mi?
Microsoft 365 ve benzeri bulut servisleri hizmet sürekliliğini sağlar, ancak yanlışlıkla silinen veya fidye yazılımıyla şifrelenen verilerin uzun süreli geri dönüşü için tasarlanmış yedekleme hizmetleri değildir. Saklama ve geri yükleme ihtiyacına göre üçüncü taraf bulut yedekleme çözümleri değerlendirilir. Sorumluluk paylaşımı servis sözleşmesinde tanımlıdır.
Geri yükleme testi ne sıklıkla yapılmalı?
Sıklık sistemin kritikliğine göre belirlenir; kritik sistemler için daha sık, diğerleri için daha seyrek bir takvim oluşturulur. Ayrıca büyük altyapı değişikliklerinden sonra test tekrarlanmalıdır. Test sonuçları RTO hedefleriyle karşılaştırılarak kayıt altına alınır.
