Microsoft 365 Yedekleme ve İş Sürekliliği Nasıl Planlanır?

Platform dayanıklılığı ile veri kurtarma aynı şey değildir

Hizmet sürekliliği, veri saklama, yedekleme ve operasyonel kurtarma farklı ihtiyaçları karşılar. Microsoft; Exchange Online, SharePoint ve OneDrive hizmetlerinde veri çoğaltma, sürümleme, geri dönüşüm kutusu ve altyapı dayanıklılığı sağlar. Bununla birlikte kurumun yanlış silme, kötü niyetli kullanıcı, hatalı otomasyon, fidye yazılımı veya uzun süre sonra fark edilen veri kaybı gibi riskler için kendi kurtarma hedeflerini belirlemesi gerekir.

Örneğin bir SharePoint sitesi teknik olarak erişilebilir durumda olabilir; fakat hatalı çalışan bir senkronizasyon veya yetkili kullanıcı işlemi binlerce dosyanın üzerine yazmış olabilir. Bu durumda hizmet kesintisi yoktur ama ciddi bir veri kaybı vardır. Microsoft'un güncel teknik açıklamaları, SharePoint ve OneDrive ile Exchange Online dayanıklılık mekanizmalarını ayrı ayrı açıklar.

RPO ve RTO her iş yükü için ayrı belirlenmeli

Bir Microsoft 365 yedekleme çalışmasına ürün seçerek değil, iki soruyla başlamak gerekir: Kurum en fazla ne kadar veri kaybını kabul edebilir ve kritik hizmetler en geç ne kadar sürede yeniden kullanılabilir olmalıdır?

İlk sorunun yanıtı RPO'yu, ikinci sorunun yanıtı ise RTO'yu belirler. Exchange Online, yönetim dosyaları, finans belgeleri, insan kaynakları verileri ve ortak çalışma alanları aynı hedefe sahip olmak zorunda değildir. Bu sınıflandırma, yüksek erişilebilir sunucu altyapısı tasarımında olduğu gibi teknik yatırımı gerçek iş etkisiyle ilişkilendirir.

Önce iş yüklerini ve veri sahiplerini belirleyin

Başarılı bir kurtarma planının başlangıç noktası teknik araçlar değil, veri envanteridir. Her SharePoint sitesinin, Teams grubunun, ortak posta kutusunun ve kritik OneDrive hesabının bir iş sahibi bulunmalıdır.

• İş yükü veya sistem adı, iş birimi ve veri sahibi
• Verinin kritiklik seviyesi ile kabul edilebilir RPO ve RTO
• Saklama süresi, kişisel veya hassas veri durumu
• Kurtarma işlemini onaylayacak kişi
• Kurtarma testinin sıklığı ve doğrulama yöntemi

Bütün verileri aynı şekilde korumak kolay görünür; ancak maliyeti yükseltir ve gerçek öncelikleri gizler. Kritik yönetim belgeleri ile geçici proje dosyalarının aynı kurtarma politikasına tabi olması çoğu kurum için doğru değildir.

Saklama politikası yedekleme değildir

Microsoft Purview saklama politikaları; içeriklerin belirli süre korunması, kayıt olarak yönetilmesi veya süresi sonunda silinmesi için tasarlanır. SharePoint ve OneDrive içeriklerinin kopyaları Preservation Hold kitaplığında, Exchange içerikleri ise Recoverable Items alanında tutulabilir. Bu yapı mevzuat, denetim ve veri yaşam döngüsü açısından değerlidir. Ayrıntılar Microsoft Purview saklama belgelerinde açıklanır.

Ancak saklama politikasının bulunması, operasyonel kurtarma ihtiyacının tamamen karşılandığı anlamına gelmez. Yedekleme; belirli bir kurtarma noktası, ölçülebilir geri dönüş süresi, yetkilendirilmiş geri yükleme süreci ve düzenli test gerektirir.

1. Hangi veriler hukuki veya kurumsal gereklilik nedeniyle saklanacak?
2. Hangi veriler operasyonel bir olaydan sonra hızla geri getirilecek?
3. Hangi veriler hizmet veya tenant dışındaki bağımsız bir koruma katmanında tutulacak?

Microsoft 365 Backup hangi imkânları sunuyor?

Microsoft 365 Backup; Exchange Online posta kutularını, OneDrive hesaplarını ve SharePoint sitelerini koruyabilen yerleşik bir hizmettir. Güncel Microsoft belgelerine göre kurtarma penceresi politika üzerinden 3 ay, 6 ay, 1 yıl veya 2 yıl olarak yapılandırılabilir.

OneDrive ve SharePoint için yakın dönemde 10 dakikalık kurtarma noktaları ve daha eski dönemlerde haftalık anlık görüntüler sunulur. Exchange Online tarafında ise 52 haftaya kadar 10 dakikalık kurtarma noktaları desteklenmektedir. Kurtarma ayrıntısı ve kullanılabilir seçenekler iş yüküne göre değişir; bu nedenle lisans, maliyet ve geri yükleme kapsamı pilot uygulamada doğrulanmalıdır. Güncel özellik tablosu Microsoft 365 Backup genel bakışında bulunabilir.

Yerleşik hizmet ile üçüncü taraf çözümler arasında karar verirken yalnızca fiyat karşılaştırması yapılmamalıdır. Kurtarılabilecek en eski tarih, dosya veya posta düzeyindeki ayrıntı, tenant dışı saklama, değiştirilemez kopya, rol tabanlı erişim, denetim kayıtları, veri yerleşimi ve toplam geri yükleme maliyeti birlikte değerlendirilmelidir.

Yedekleme hesabını günlük yönetim hesabından ayırın

Yedekleme sistemine günlük kullanılan genel yönetici hesabıyla erişmek önemli bir risktir. Kimlik bilgileri ele geçirilirse saldırgan hem üretim verisine hem de kurtarma katmanına ulaşabilir.

• Yedekleme yöneticiliğini ayrı bir role bağlayın.
• Yönetici hesaplarında çok faktörlü kimlik doğrulamayı zorunlu tutun.
• Günlük kullanım ve yönetim için ayrı hesaplar kullanın.
• Kritik geri yüklemelerde ikinci kişi onayı uygulayın.
• Yedekleme politikasının silinmesini veya kapsamının azaltılmasını izleyin.

Amaç yalnızca veriyi kopyalamak değil, saldırganın kurtarma imkânını da ortadan kaldırmasını önlemektir.

Kurtarma testi yapılmayan yedek tamamlanmış sayılmaz

Başarılı görünen bir yedekleme görevi, verinin gerçekten kullanılabilir şekilde dönebileceğini kanıtlamaz. NIST'in iş sürekliliği yaklaşımı da kurtarma planlarının prosedür, sorumluluk, test ve doğrulama aşamalarıyla birlikte ele alınmasını önerir. NIST süreklilik planlaması rehberi bu yaklaşım için yararlı bir çerçeve sunar.

Üç aylık bir testte silinmiş bir e-postanın, OneDrive hesabındaki belirli bir tarihe ait verinin ve yanlışlıkla silinen SharePoint sitesinin geri getirilmesi denenebilir. Fidye yazılımı benzeri toplu dosya değişikliği ve yönetici hesabına erişilememesi de tatbikat senaryosuna eklenmelidir.

Test sırasında başlangıç ve bitiş zamanı kaydedilmeli, gerçekleşen RPO/RTO değeri ölçülmeli ve veri sahibi geri getirilen içeriği doğrulamalıdır. Teknik ekibin “geri yükleme tamamlandı” demesi tek başına yeterli değildir.

90 günlük uygulanabilir yol haritası