Yedek Güvenliğinin Fibonacci Kuralı: Modern yedek güvenliği için 3-2-1-1-0'ı genişletmek

Olgun Yedek Stratejileri 2026'da Neden Başarısız Oluyor

3-2-1 yedekleme kuralı yıllardır veri korumasının temel taşı. Fotoğrafçı Peter Krogh, bu adı The DAM Book'un ilk baskısını yazarken kendisinin koyduğunu anlatıyor. ASMP'nin dpBestflow projesi için yazdığı yedekleme rehberi kuralı şöyle özetliyor: her önemli dosyanın üç kopyası, iki farklı medya türünde, bir kopyası tesis dışında. Formül fotoğrafçılığın çok ötesine yayıldı; CISA'nın yedekleme seçenekleri belgesi de kişisel ve kurumsal veriler için aynı kuralı öneriyor.

İşe yaradı. Yaramaz olana dek.

Verizon'un 2025 Data Breach Investigations Report raporu, incelediği ihlallerin %44'ünde fidye yazılımı buldu; bir önceki baskıda bu oran %32'ydi. Bu baskı Kasım 2023 ile Ekim 2024 arasındaki olayları kapsıyor. Kasım 2024 ile Ekim 2025 arasını kapsayan 2026 baskısı ise oranı %48 olarak veriyor. Fidye yazılımı gruplarının yayımladığı mağdurları izleyen GuidePoint Security araştırma ekibi, 2025'te fidye yazılımı mağdurlarında yıllık %58 artış kaydetti; ekibin bugüne kadar izlediği en yoğun yıl bu oldu. Kurumsal risk yöneticileri açısından daha önemlisi: Google Threat Intelligence Group, Mandiant'ın 2025 olay müdahale çalışmalarında fidye yazılımı sızmalarının yaklaşık %77'sinde doğrulanmış ya da şüphelenilen veri hırsızlığı gördü; 2024'te bu oran yaklaşık %57'ydi. Veri zaten çalınmışsa kusursuz bir restore sistemleri geri getirir, ama ihlali çözmez.

3-2-1 kuralı; donanım arızaları, bölgesel kesintiler ve kazara silmeler için tasarlanmıştı. Özellikle yedek repository'lerini hedef alan tehdit aktörleri ya da geçerli yönetici kimlik bilgilerine sahip içeriden tehditler için tasarlanmamıştı. Saldırganlar, yedekleri yok etmenin mağdurun fidye ödememe seçeneğini ortadan kaldırdığını bilir. Aynı Google raporuna göre fidye yazılımı aktörleri "often disabled or deleted backups to inhibit and/or limit recovery options", yani kurtarma seçeneklerini kısıtlamak için yedekleri sık sık devre dışı bıraktı ya da sildi.

Kuralın genişletilmesinin nedeni bu. Veeam, kendi uzantısı olan 3-2-1-1-0'ı bir immutable kopya ve sıfır kurtarma hatası ekleyen kural olarak tanımlıyor. BackupSec olarak bir adım daha öneriyoruz: Yedek Güvenliğinin Fibonacci Kuralı dediğimiz ve 5-3-2-1-1-0 diye yazdığımız çerçeve. Bu bizim önerimiz, bir endüstri standardı değil. Fibonacci dizisini tersten okur gibi okunuyor ve altıncı bir öğe ekliyor: altındaki her katmanı desteklemesi gereken beş temel güvenlik ilkesi.

Olgun yedek ortamları işleten kuruluşlar için bu yazı, 2026'da "kapsamlı veri koruması"nın ne anlama gelmesi gerektiğini yeniden çerçeveliyor.

3-2-1'den 3-2-1-1-0'a: Kısa Bir Özet

Fibonacci Kuralı'nı tanıtmadan önce buraya nasıl geldiğimize bakmakta fayda var.

Orijinal 3-2-1 kuralı, verinin iki farklı medya türünde üç kopyasını ve birinin tesis dışında saklanmasını istiyordu. Odağı yedeklilikti: tek bir fiziksel olayın üç kopyayı aynı anda yok edemeyeceği varsayımı.

Veeam'in orijinal kurala getirdiği ve bugün yaygın biçimde kullanılan 3-2-1-1-0 kuralı iki iyileştirme ekledi:

• Yönetici kimlik bilgilerine sahip bir saldırganın bile değiştiremeyeceği ya da silemeyeceği bir immutable ya da air-gap'li kopya.
• Yedek doğrulamasında sıfır hata: her yedeğin yalnızca var olduğu değil, restore edilebildiği bilinir.

Bu evrim iki önemli boşluğu kapattı: yedekleri hedef alan fidye yazılımı ve felaket gelene dek hiç test edilmeyen yedeklerin sessiz başarısızlığı. Ancak kural, bu kopyaların çevresindeki güvenlik mimarisinin tamamını tanımlamaya çalışmaz: kimlik ayrımı, ayrıcalıklı erişim, segmentasyon, sürekli izleme ve etki alanının sınırlanması.

Yedek Güvenliğinin Fibonacci Kuralı bu boşluğu kapatmak için tasarlandı.

Neden Fibonacci? Sayıların Ardındaki Mantık

Fibonacci dizisi (0, 1, 1, 2, 3, 5, 8, 13...) matematiğin en zarif örüntülerinden biri: her sayı, kendisinden önceki iki sayının toplamı. Çerçevemizi tersten okuduğumuzda (5, 3, 2, 1, 1, 0) aynı birikimli mantık geçerli: her koruma katmanı, altındaki temellerin üzerine kurulur.

• 5 temel güvenlik ilkesi. Yedeğin nasıl tasarlandığını yöneten beş ilke.
• 3 veri kopyası. Her kritik veri kümesinin en az üç kopyası.
• 2 farklı medya ya da depolama/platform türü. İki farklı medya, depolama platformu ya da teknoloji yığını.
• 1 tesis dışı kopya. Coğrafi olarak ayrı bir konumda bir kopya.
• 1 immutable, izole ya da başka biçimde korunan ek kopya. Değiştirilmeye ya da yok edilmeye karşı korunan bir kopya daha.
• 0 doğrulanmamış yedek ya da çözülmemiş kurtarma hatası. Doğrulanmamış yedek, açık kalmış kurtarma hatası kalmaz.

Orijinal 3-2-1-1-0 kuralı "Kaç kopya, nerede ve hangi durumda?" şeklindeki operasyonel soruyu yanıtlıyordu. Eklediğimiz "5" ise daha temel bir mimari soruyu yanıtlıyor: "Bir yedeğin güvenli olması gerçekte ne anlama gelir?"

Bu beş ilke olmadan zincirin geri kalanı içi boştur. Üç kopya hâlinde, iki medyada ve immutable durumda duran, ama yetersiz erişim denetimleriyle yönetilen ya da ele geçirilmiş bir yönetici iş istasyonundan erişilebilen bir yedek korunmuş değildir. O yedek, bir açığın belgesidir.

"5": Yedek Güvenliğinin Beş Temel İlkesi

Bu beş ilke, platform seçiminden saklama politikasına ve erişim yönetimine kadar yedek ortamınızdaki her mimari kararı şekillendirmeli.

1. Tasarım Gereği Siber Dayanıklı Mimari

Yedek güvenliği sonradan eklenemez. İlk günden bir tasarım kısıtı olmalı.

Siber dayanıklı bir yedek mimarisi her bileşeni (kataloğu, depolama katmanını, yönetim düzlemini, kurtarma ortamını) potansiyel bir hedef olarak görür. İhlali varsayar, ele geçirilmeyi planlar ve teknik, insani ya da saldırgan kaynaklı hiçbir tekil arızanın kurtarılabilirliğin tamamen kaybına dönüşmemesini sağlar.

Uygulamada bu şu anlama gelir:

• Derinlemesine savunma: Her katmanı birden çok bağımsız denetim korur; birinin başarısız olması sistemi açıkta bırakmaz.
• Etki alanını (blast radius) sınırlama: Üretim ortamının ele geçirilmesi yedek altyapısına, bir yedek katmanının ele geçirilmesi de diğerlerine yayılamaz.
• Önce kurtarma tasarımı: Mimariler yalnızca veriyi ne kadar iyi yedeklediğine göre değil, düşmanca koşullarda (DNS çöktüğünde, kimlik sağlayıcılar ele geçirildiğinde ya da birincil tesise erişilemediğinde) ne kadar güvenilir restore yapabildiğine göre değerlendirilir.
• Bir özellik değil, mimari bir yapı taşı olarak şifreleme: Her yedek, her durumda, beklemede ve aktarımda güçlü, sektör standardı şifrelemeyle korunmalı. Şifreleme anahtarları mümkün olan her yerde yedek altyapısından bağımsız yönetilmeli; ideal olarak özel bir HSM'de ya da yönetim sahipliği ayrı bir anahtar yönetim hizmetinde. Anahtarlarınız verinizle aynı yerde duruyorsa şifrelemeniz yok, yalnızca gizlemeniz var. Sınır ötesi veri akışı olan kurumlar için anahtar egemenliği (kimin, hangi yargı yetkisi altında, hangi sürede ifşayı zorlayabileceği) bir olay müdahale sorunu değil, bir tasarım kararıdır.

Eski bir tehdit ortamı için tasarlanmış bir yedek sistemine sonradan eklenen güvenlik, açıklarını genellikle olayın ortasında gösterir; zayıf nokta mimarinin kendisi çıkar. Dayanıklılık baştan tasarlanmalı.

2. Sıfır Güven Erişimi ve Güçlü Kimlik Doğrulama

İlke basit: asla güvenme, her zaman doğrula. Bir yedeği okumak, yazmak ya da değiştirmek için yapılan her istek, ağ kaynağından bağımsız olarak, istek anında kimlik doğrulamasından ve yetkilendirmeden geçmeli.

Pratikte bu şunları gerektirir:

• Yedek altyapısına dokunan her yönetici kimliği için, ideal olarak donanım anahtarı gibi oltalamaya dirençli yöntemlerle çok faktörlü kimlik doğrulama (MFA).
• En az ayrıcalık ilkesini ayrıntılı kapsamda uygulayan rol tabanlı erişim denetimi (RBAC).
• Üretim ve yedek sistemleri için ayrı yönetici kimlikleri. Ele geçirilmiş bir domain admin hesabı son savunma hattınıza erişememeli.
• Tam zamanında yetki yükseltme, oturum kaydı ve retention politikası değişikliği gibi hassas işlemler için onay akışları içeren ayrıcalıklı erişim yönetimi (PAM).

Sophos'un fidye yazılımından etkilenmiş 3.400 kuruluşla yaptığı State of Ransomware 2025 anketinde mağdurlar, saldırıların %23'ünün kök nedeni olarak ele geçirilmiş kimlik bilgilerini gösterdi. Bu, istismar edilen güvenlik açıklarından (%32) sonra en sık görülen ikinci teknik kök neden. Yedek ortamınız üretimi koruyan kimlik altyapısının aynısına güveniyorsa, katmanlı savunma kılığına girmiş tek bir hata noktanız var demektir.

3. Immutability ve WORM Depolama

Immutability, yani verinin yazıldıktan sonra tanımlı bir saklama süresi boyunca değiştirilememesi ya da silinememesi, "en iyi uygulama" olmaktan çıkıp "pazarlık konusu olmayan" bir gereksinime dönüştü. İster bulut depolamada Object Lock, ister Write Once Read Many (WORM) medya, isterse donanım tabanlı retention kilitleriyle uygulansın, immutability özellikle yedek repository'lerini avlayan tehdit aktörlerine karşı en etkili mimari savunmalardan biri.

Kayıt saklama kurallarına tabi kurumlarda immutability uyuma da destek olabilir. SEC Rule 17a-4, aracı kurumların elektronik kayıtları ya eksiksiz ve zaman damgalı bir audit trail ile ya da "in a non-rewriteable, non-erasable format" (yeniden yazılamaz, silinemez biçimde) saklamasına izin veriyor. HIPAA Security Rule ise elektronik sağlık verisinin "retrievable exact copies" (geri alınabilir birebir kopyalarını) oluşturan bir yedekleme planı istiyor. Sizi fidye yazılımından koruyan denetim yüzeyi, çoğu zaman denetçinizin sorduğu yüzeyin aynısıdır.

CISA ise çoğu üreticiden daha temkinli. #StopRansomware Guide, kritik verilerin çevrimdışı ve şifreli yedeklerini tutmayı ve bu yedeklerin erişilebilirliğini ve bütünlüğünü düzenli olarak test etmeyi öneriyor. Bulut sağlayıcılarının sunduğu immutable depolamadan ise bir uyarıyla söz ediyor: bazı düzenlemelerin uyum kriterlerini karşılamadığını ve yanlış yapılandırmanın ciddi maliyet doğurabileceğini belirtiyor. Immutability, yönetici kimlik bilgilerini zaten ele geçirmiş bir saldırgana karşı yedekleri sağlam tutar. Çevrimdışı bir kopyanın ya da test edilmiş bir restore'un yerini tutmaz.

4. Sürekli Doğrulama ve Kurtarma Testi

Test etmediğiniz bir yedek, yedek değildir. Bir hipotezdir.

3-2-1-1-0'daki "0" sıfır hata ister; bu iddiayı kanıtlamanın tek yolu sürekli test etmektir. Olgun programlar otomatik bütünlük kontrolleri, düzenli tam restore tatbikatları, doğrulama için izole kurtarma ortamları ve insan ile süreç katmanlarını teknik katmanlar kadar zorlayan masa başı (tabletop) tatbikatları uygular.

Kurtarma hızlanıyor. Aynı Sophos anketinde fidye yazılımı mağdurlarının %53'ü bir hafta içinde tamamen kurtuldu; 2024'te bu oran %35'ti. Mağdurların %97'si üç ay içinde tamamen kurtulmuştu. Sophos bu iyileşmenin olay hazırlığına ve kurtarma hazırlığına yapılan yatırımı yansıtıyor olabileceğini söylüyor. Anket test edilmiş planların etkisini ayrıca ölçmüyor, ama Sophos'un kendi tavsiyesi de kaliteli yedek almak ve bu yedeklerden restore'u düzenli olarak prova etmek.

Risk liderleri için ders şu: test, yedeği olan kuruluşları kurtarabilen kuruluşlardan ayırır.

5. İzolasyon ve Ağ Segmentasyonu

Yedek altyapısı üretimden güçlü biçimde ayrılmalı ve mümkün olan her yerde üretim sistemlerini koruyan yönetimsel güven sınırlarına bağlı olmamalı.

Modern en iyi uygulama, mantıksal segmentasyonu (ayrı VLAN'lar, özel alt ağlar, katı güvenlik duvarı kuralları, mikro segmentasyon) her yedeğin en az bir kopyası için air-gap'li ya da yarı air-gap'li mimarilerle birleştirir. Ayrı kimlik sağlayıcılı bulut immutability'si, çevrimdışı teyp rotasyonları, özel kurtarma ortamları ve paylaşımlı altyapıda müşteri izolasyonu aynı amaca hizmet eder: tek bir ele geçirilmenin etki alanının kurtarma katmanına uzanmaması.

Domain controller'ınızdaki bir tehdit aktörü yedek repository'nize aynı kimlik bilgileriyle erişebiliyorsa, yedeğiniz saldırı yüzeyinden ayrı değil, onun bir parçasıdır.

"3-2-1": Hâlâ Önemli Olan Yedeklilik

Beş ilke temel olduğunda, klasik 3-2-1 katmanı hâlâ vazgeçilmez.

• Her kritik veri kümesinin 3 kopyası: üretim verileriniz artı en az iki yedek.
• 2 farklı medya ya da depolama platformu: yerel disk ve bulut ya da şirket içi nesne depolama ve ayrı bir bulut sağlayıcısı. Amaç, tek bir teknoloji arızasının, sağlayıcı kesintisinin ya da saldırı türünün tüm kopyaları aynı anda yok edememesi.
• 1 tesis dışı kopya: birincil tesisinizden coğrafi olarak ayrı, ideal olarak farklı bir tehdit alanında ve gerektiğinde farklı bir hukuki yargı alanında.

Kural ilk formüle edildiğinden beri değişen şey yorum. Aynı sağlayıcının iki bulut bölgesi "iki farklı medya" sayılmaz. Üretim dizinizin yanında duran bir SAN üzerindeki yedek birimi gerçek anlamda "tesis dışı" değildir. Modern kurumsal tehdit modellemesi her gereksinimin daha katı okunmasını ister.

"1-1": Tesis Dışı ve Immutable ya da Air-Gap'li

İki "1" farklı arıza alanlarını ele alır.

Birincisi bir kopyanın tesis dışında, birincil ortamdan coğrafi olarak ayrı bir yerde saklanmasını ister; böylece saha düzeyinde bir olay, altyapı arızası ya da fiziksel felaket tüm kurtarma seçeneklerini aynı anda ortadan kaldıramaz.

İkincisi en az bir ek kopyanın immutability, air-gap ya da eşdeğer bir izolasyon mekanizmasıyla değiştirilmeye ya da yok edilmeye karşı korunmasını ister. Amacı farklıdır: tesis dışı ayrım konum kaybına karşı korur; immutability ya da izolasyon ise yönetici erişimi elde etmiş bir saldırgana karşı korur.

Bu gereksinimler uygulamada örtüşebilir. Tesis dışındaki bir kopya aynı zamanda immutable olabilir; olgun ortamlar hem immutable bir kurtarma katmanı hem de daha derinde çevrimdışı ya da air-gap'li bir kopya tutabilir. Önemli olan, coğrafyanın tek başına güvenlik izolasyonu sayılmaması.

Immutability'nin Fibonacci Kuralı'nın beş güvenlik ilkesi arasında da yer almasının nedeni bu ayrım. Sayısal "1" bir yedek kopya için asgari koruma gereksinimini tanımlar; güvenlik ilkesi ise immutability'nin retention denetimleri, yönetici erişimi, kimlik ayrımı ve yönetim düzlemi dâhil tüm mimaride düşünülmesini ister.

"0": Doğrulanmamış Yedeklere Sıfır Tolerans

Her yedek doğrulanmış. Her restore test edilmiş. Her boşluk belgelenmiş ve kapatılmış.

"0", çerçevenin operasyonel disiplin katmanı. Titizlik ister: otomatik checksum'lar, planlı restore doğrulaması, backup job meta verilerinde anomali tespiti (job boyutundaki ani bir artış, bir tehdit aktörünün şifreleme öncesi hazırlığına işaret edebilir), yedek yönetim faaliyetinin davranışsal izlenmesi ve doğrulama başarısız olduğunda net eskalasyon yolları.

Mantığı basit. Yedekleri yok etmeye hazırlanan bir saldırgan önce yedek sistemine dokunmak zorunda; bu değişiklikler bir restore başarısız olmadan çok önce job ayarlarında, retention değerlerinde ve audit loglarında görünür. Sıfır hata bir gösteriş metriği değil. Bu ayrımın en çok önem taşıdığı anda güven ile sahte güven arasındaki farktır.

Bunun Kurumsal Risk Liderleri İçin Anlamı

Kuruluşunuz farklı bir tehdit ortamı için tasarlanmış bir yedek stratejisiyle çalışıyorsa, elinizdeki ile ihtiyacınız olan arasındaki fark artık teorik değil. Finansal tabloya bakın:

• Sophos'un 2025 anketi medyan fidye ödemesini 1 milyon dolar, fidye hariç ortalama kurtarma maliyetini 1,53 milyon dolar olarak verdi.
• Verizon'un 2025 DBIR raporuna göre fidye yazılımı mağduru kuruluşların %64'ü ödeme yapmadı; iki yıl önce bu oran %50'ydi. Farklı bir örneklemle çalışan Sophos ise mağdurların %49'unun verisini geri almak için fidye ödediğini buldu. Her iki durumda da ödemek artık varsayılan seçenek değil ve ödemeyi reddeden bir kuruluşun çalışan bir restore yoluna ihtiyacı var.

Düzenlemeye tabi sektörlerdeki ya da karmaşık hibrit altyapı yöneten kurumlar için hesap daha da keskin. ABD'de borsada işlem gören şirketler, önemli (material) bir siber güvenlik olayını Form 8-K ile açıklamak zorunda; bu açıklama genellikle olayın önemli olduğuna karar verildikten sonraki dört iş günü içinde yapılmalı. Başka pek çok ülke ve sektör de kendi bildirim yükümlülüklerini getiriyor. Kurtarılamayan bir olayın maliyeti artık yalnızca operasyonel değil; itibar ve mevzuat maliyeti de var.

Fibonacci Kuralı'nı uygulamak altyapınızı sıfırdan kurmayı gerektirmez. Dürüst bir mimari değerlendirme, net bir ilke setine göre önceliklendirilmiş iyileştirme ve yedek güvenliğini bir satın alma kalemi değil, bütünleşik bir disiplin olarak ele alma taahhüdü gerektirir.

BackupSec Devreye Nerede Giriyor

BackupSec olarak ekiplerin Veeam yedek ortamlarını yukarıdaki ilkelere göre işletmesine yardımcı oluyoruz. Yedek platformunu değiştirmiyoruz; güvenliğini görünür, danışmanlıkla desteklenmiş ve test edilmiş hâle getiriyoruz.

• ZeroMON Veeam Backup & Replication'ı izler: job sağlığı, kim/ne/ne zaman kaydıyla yapılandırma değişiklikleri, Security Analyzer kontrol listesi, raporlar ve honeypot. Immutability durumunu Veeam'in repository ayarlarının bildirdiği şekliyle gösterir; depolamadaki nesne düzeyindeki kilitleri doğrulamaz. Uyarılar e-posta ve uygulama içi bildirimle gelir. Şirket içinde OVA olarak kurulur, salt okunur bir hesapla bağlanır ve BackupSec'e ya da herhangi bir üçüncü tarafa hiçbir şey göndermez.
• ZeroTAM mimari, kapasite, fidye yazılımı kurtarma planlaması ve öncelikli kriz desteği için size özel bir yedek güvenliği danışmanı sağlar.
• ZeroPEN, Veeam Backup & Replication, Veeam ONE ve Enterprise Manager için tehdit odaklı bir sızma testidir: MITRE ATT&CK'e eşlenmiş sekiz kill chain aşaması. Çalışma, restore bütünlüğü ve immutability doğrulamasını da kapsar. Gerçek yedekleri asla silmez, gerçek şifreleme yapmaz, üretim ya da yedekleme servislerini durdurmaz. Sonunda denetime hazır kanıt ve kritik bulgular için yeniden test alırsınız.
• ZeroVault, tesis dışındaki immutable kopya için Object Lock destekli, S3 uyumlu immutable bulut nesne depolamasıdır.

Yedek güvenliği duruşunuz hakkında BackupSec ile konuşun →