Kurumsal e-postada iş sürekliliği: felaket kurtarma planı nasıl kurulur?

Havacılık gibi kritik sektörlerde e-posta, operasyonun omurgasıdır: uçuş planlamasından tedarikçi yazışmalarına, düzenleyici kurumlarla iletişimden ekip koordinasyonuna kadar pek çok süreç e-postaya dayanır. Skytech Group için birden fazla lokasyonda kesintisiz çalışan bir e-posta altyapısı ve felaket kurtarma çerçevesi kurduk. Bu yazıda, benzer bir yapıyı kurmak isteyen her kurumun izleyebileceği adımları paylaşıyoruz.

Neden ayrı bir plan gerekir?

Çoğu kurum "yedeğimiz var" dediğinde aslında sadece verinin bir kopyasının bulunduğunu söyler. Oysa felaket kurtarma, verinin kopyasından fazlasıdır: hangi sürede, hangi sırayla ve kimin sorumluluğunda hizmetin geri getirileceğini tanımlar. Bir sunucu arızası, yanlış yapılandırma, fidye yazılımı saldırısı ya da veri merkezindeki bir elektrik kesintisi; her biri farklı bir senaryo ve farklı bir müdahale gerektirir.

1. Hedefleri netleştirin: RTO ve RPO

Planın temelinde iki rakam vardır:

• RTO (Recovery Time Objective): Hizmetin en fazla ne kadar süre kesintide kalabileceği. Örneğin "e-posta en geç 1 saat içinde tekrar çalışmalı".
• RPO (Recovery Point Objective): Kabul edilebilir en fazla veri kaybı. Örneğin "en fazla son 15 dakikanın e-postaları kaybedilebilir".

Bu iki rakam küçüldükçe gereken altyapı da karmaşıklaşır ve maliyeti artar. Bu yüzden hedefleri teknik ekip tek başına değil, iş birimleriyle birlikte belirlemelidir. Her ekip için aynı hedefin gerekmediği de unutulmamalı: operasyon ekibinin posta kutusu ile arşiv posta kutusu farklı önceliklere sahip olabilir.

2. Mevcut durumu değerlendirin

Plan, gerçekçi bir envanterle başlar. Şu soruların cevabı net olmalıdır:

• Hangi sistemler kritik? (Posta sunucusu, kimlik doğrulama, DNS, arşiv, mobil erişim)
• Tek hata noktaları nerede? (Tek sunucu, tek internet hattı, tek DNS sağlayıcısı)
• Yedekler nerede, nasıl ve ne sıklıkla alınıyor? Geri yükleme hiç denendi mi?
• Bir kesinti anında kimin neyi yapacağı yazılı mı?

3. Yedekliliği tasarlayın

Yüksek erişilebilirlik

Posta sunucularının birden fazla düğümde çalışması, bir düğüm arızalandığında hizmetin diğerinden sürmesini sağlar. Posta kutusu verisinin düğümler arasında eşzamanlı ya da çok kısa aralıklarla kopyalanması RPO hedefini doğrudan belirler.

Coğrafi ayrım

Aynı veri merkezindeki iki sunucu, o veri merkezinin tamamen erişilemez olduğu bir senaryoda işe yaramaz. Kritik sistemler için en az bir kopyanın farklı bir lokasyonda tutulması gerekir.

3-2-1 yedekleme kuralı

Yaygın kabul gören bu kurala göre verinin en az 3 kopyası olmalı, bu kopyalar 2 farklı ortamda saklanmalı ve en az 1 kopya farklı bir lokasyonda tutulmalıdır. Fidye yazılımlarına karşı yedeklerden en az birinin değiştirilemez (immutable) ya da çevrim dışı olması önerilir.

MX ve DNS yedekliliği

E-posta teslimi DNS'teki MX kayıtlarına dayanır. Birincil sunucu erişilemez olduğunda gelen postaların kaybolmaması için ikincil bir MX kaydı ve kuyruğa alma mekanizması tanımlanmalıdır. DNS'in kendisinin de tek bir sağlayıcıya bağımlı olmaması ve kayıtlar için makul bir TTL kullanılması, geçiş anında hız kazandırır.

4. Güvenliği planın parçası yapın

Kesintilerin önemli bir kısmı arızadan değil, güvenlik olaylarından kaynaklanır. Bu yüzden felaket kurtarma planı güvenlik önlemlerinden ayrı düşünülmemelidir:

• SPF, DKIM ve DMARC kayıtları, alan adınızın sahte e-postalarda kullanılmasını zorlaştırır ve teslim edilebilirliği artırır.
• İki adımlı doğrulama, ele geçirilen bir parolanın tek başına hesaba erişim için yeterli olmamasını sağlar.
• Şifreleme, hem iletimde (TLS) hem de depolamada uygulanmalıdır.
• Yönetici erişimi en az yetki ilkesine göre sınırlandırılmalı ve kayıt altına alınmalıdır.

5. Yazılı bir müdahale planı hazırlayın

Kesinti anında en değerli şey zamandır ve o anda karar vermek en zor iştir. Bu yüzden her senaryo için kısa, uygulanabilir bir müdahale planı yazılmalıdır: kim karar verir, kim hangi sistemi devreye alır, kullanıcılara nasıl ve kim tarafından bilgi verilir. Plan, teknik olmayan bir yöneticinin de takip edebileceği açıklıkta olmalıdır.

6. Test edin, tekrar test edin

Test edilmemiş bir kurtarma planı yalnızca bir varsayımdır. Düzenli tatbikatlarla şunlar doğrulanmalıdır:

1. Yedekten tek bir posta kutusu belirlenen sürede geri yüklenebiliyor mu?
2. Birincil sunucu kapatıldığında ikincil sistem RTO hedefi içinde devreye giriyor mu?
3. Gelen postalar geçiş sırasında kaybolmadan teslim ediliyor mu?
4. Müdahale planındaki sorumlular adımları yazılı plana bakarak uygulayabiliyor mu?

Her tatbikattan sonra ölçülen süreler hedeflerle karşılaştırılmalı ve plan güncellenmelidir.

7. Sürekli izleyin

Disk doluluğu, kuyruk uzunluğu, replikasyon gecikmesi, sertifika süreleri ve yedekleme işlerinin başarı durumu sürekli izlenmeli ve eşik değerler aşıldığında uyarı üretilmelidir. Birçok kesinti, önceden görülebilecek küçük bir sorunun büyümesiyle ortaya çıkar.

Sık yapılan hatalar

Yıllar içinde farklı kurumların e-posta altyapılarını incelerken bazı hataların tekrar tekrar karşımıza çıktığını gördük:

• Yedeklerin aynı ortamda tutulması: Posta sunucusu ile yedekleri aynı disk dizisinde ya da aynı hesap altında tutmak, fidye yazılımı gibi bir saldırıda ikisinin birlikte kaybedilmesine yol açabilir.
• Geri yüklemenin hiç denenmemesi: Yedekleme işinin "başarılı" görünmesi, verinin geri yüklenebileceği anlamına gelmez. Bozuk ya da eksik yedekler genellikle ancak ihtiyaç anında fark edilir.
• Belgelenmemiş yapılandırmalar: Sunucu yapılandırmasını yalnızca bir kişinin bildiği durumlarda, o kişi ulaşılamaz olduğunda kurtarma süresi katlanır.
• Sertifika ve alan adı sürelerinin takip edilmemesi: Süresi dolan bir TLS sertifikası ya da yenilenmeyen bir alan adı, donanım arızası kadar ciddi bir kesintiye neden olabilir.
• Kullanıcı iletişiminin unutulması: Kesinti anında kullanıcılara ne olduğunu ve ne zaman düzeleceğini anlatacak alternatif bir kanal (SMS, kurumsal mesajlaşma) önceden belirlenmelidir.

Bulut mu, şirket içi mi?

Kurumsal e-posta için bulut hizmetleri, şirket içi sunucular ya da ikisinin karışımı (hibrit) tercih edilebilir. Bulut hizmetleri altyapı yedekliliğini büyük ölçüde sağlayıcıya devreder; ancak hesap güvenliği, yanlışlıkla silinen veriler ve sağlayıcı kaynaklı kesintiler için yine de bir plan gerekir. Şirket içi sunucular daha fazla kontrol sunar, fakat yedeklilik, izleme ve güncelleme sorumluluğunun tamamı kurumdadır. Düzenleyici gereklilikler, veri yerleşimi ve maliyet; bu kararı belirleyen başlıca etkenlerdir.

Hangi model seçilirse seçilsin, "sağlayıcı yedekliyor" düşüncesi tek başına yeterli değildir. Paylaşılan sorumluluk modelinde, verinin kendisinin korunması ve hesap güvenliği çoğu zaman müşterinin sorumluluğundadır.

Planı canlı tutmak

Bir felaket kurtarma planı yazıldığı gün en güncel halindedir; sonrasında her altyapı değişikliği, yeni bir uygulama ya da personel değişikliği planı biraz daha eskitir. Bu yüzden planın bir sahibi olmalı, belirli aralıklarla ve her büyük değişiklikten sonra gözden geçirilmelidir. Tatbikat sonuçları, planın gerçekte ne kadar işe yaradığını gösteren en değerli veridir.

Kontrol listesi

• RTO ve RPO hedefleri iş birimleriyle birlikte belirlendi.
• Kritik sistemlerin ve tek hata noktalarının envanteri çıkarıldı.
• Yüksek erişilebilirlik ve coğrafi olarak ayrı bir kopya mevcut.
• 3-2-1 kuralına uygun, en az bir kopyası değiştirilemez yedekler alınıyor.
• İkincil MX ve DNS yedekliliği tanımlı.
• SPF, DKIM, DMARC ve iki adımlı doğrulama etkin.
• Yazılı müdahale planı var ve sorumlular biliniyor.
• Kurtarma tatbikatları düzenli yapılıyor, sonuçlar kayıt altında.

Sonuç

Skytech Group projesinde, kapsamlı testlerin ardından devreye alınan altyapıyla operasyonel güvenilirlik arttı, kesinti riski azaldı ve kritik veriler daha iyi korunur hale geldi. E-posta ya da başka bir kritik sistem için iş sürekliliği planı oluşturmak istiyorsanız, mevcut durumunuzu birlikte değerlendirmekten memnuniyet duyarız.