Microsoft 365 ve Bulut Altyapısında Süreklilik

Microsoft 365’e geçen birçok işletmede sık duyulan bir varsayım vardır: “Artık her şey bulutta, yedekleme ve süreklilik Microsoft’un işi.”

Bu varsayım kısmen doğrudur. Microsoft, hizmetin çalışırlığından, veri merkezlerinden ve platformun altyapısından sorumludur. Ancak verinin kendisi, kullanıcı kimlikleri, erişim yetkileri ve yapılandırma kararları büyük ölçüde işletmenin sorumluluğundadır.

İş sürekliliği açısından asıl soru şudur: Bir kullanıcı hatası, kötü niyetli bir silme işlemi ya da ele geçirilmiş bir yönetici hesabı durumunda işletme ne kadar hızlı ve eksiksiz toparlanabilir?

Paylaşılan sorumluluk modeli

Bulut hizmetlerinde sorumluluk, sağlayıcı ile müşteri arasında paylaşılır. SaaS hizmetlerinde fiziksel altyapı, ağ ve uygulama platformu sağlayıcının sorumluluğundadır. Bilgi ve veri, cihazlar, hesaplar ve kimlikler ise her hizmet modelinde müşterinin sorumluluğunda kalır.

Bu ayrım pratikte şu anlama gelir: Microsoft, Exchange Online’ın veya SharePoint’in çalışmasını sağlar; fakat yanlışlıkla silinen bir klasörü fark edip zamanında geri getirmek, hangi verinin ne kadar süre saklanacağına karar vermek ve hesapları korumak işletmenin görevidir.

Geri dönüşüm kutusu yedek değildir

Microsoft 365’te silinen öğeler hemen kaybolmaz; belirli bir süre geri alınabilir durumda tutulur. Örneğin Exchange Online’da silinen öğeler varsayılan olarak 14 gün saklanır ve bu süre posta kutusu başına en fazla 30 güne çıkarılabilir. SharePoint ve OneDrive’da silinen içerikler geri dönüşüm kutularında sınırlı bir süre tutulur.

Bu mekanizmalar günlük kullanıcı hatalarına karşı faydalıdır, ancak bir yedekleme stratejisinin yerini tutmaz:

• Kayıp, saklama süresi dolduktan sonra fark edilirse geri dönüş imkânı kalmayabilir.
• Fidye yazılımı tarafından şifrelenen yerel dosyalar, OneDrive senkronizasyonu üzerinden buluttaki kopyaları da etkileyebilir.
• Yetkili bir hesapla yapılan toplu ve kasıtlı silme işlemleri, geri dönüşüm kutularını da hedef alabilir.
• Geri dönüşüm kutusu, belirli bir tarihe dönük tutarlı bir kopya sunmaz.

Saklama ilkeleri ve yedekleme farkı

Microsoft Purview saklama ilkeleri (retention policies), içeriğin belirli bir süre silinmeden korunmasını sağlar ve özellikle mevzuat ve uyum gereksinimleri için önemlidir. Ancak saklama ilkesinin amacı uyumdur; hızlı ve toplu geri yükleme için tasarlanmış bir yedekleme çözümü değildir.

Kritik veriler için saklama ilkeleri ile birlikte, belirli zaman noktalarına geri dönmeyi mümkün kılan ayrı bir yedekleme çözümü değerlendirilmelidir.

Kimlik güvenliği sürekliliğin parçasıdır

Bulut ortamında kimlik, yeni güvenlik sınırıdır. Ele geçirilmiş tek bir yönetici hesabı; posta kutularına, dosyalara ve tüm kiracı yapılandırmasına erişim anlamına gelebilir.

Microsoft’a göre çok faktörlü kimlik doğrulama (MFA) ve eski kimlik doğrulama protokollerinin engellenmesi, yaygın kimlik saldırılarının çok büyük bölümünü durdurur. Temel adımlar şunlardır:

• MFA’yı tüm kullanıcılar için zorunlu kılın. Özellikle yönetici hesapları için istisna bırakmayın.
• Eski kimlik doğrulamayı engelleyin. MFA desteklemeyen protokoller saldırganlar için açık kapıdır.
• Güvenlik varsayılanlarını veya Koşullu Erişim’i kullanın. Güvenlik varsayılanları (Security Defaults) ek lisans gerektirmeden temel korumayı sağlar; daha ayrıntılı kurallar için Microsoft Entra ID P1 ile gelen Koşullu Erişim (Conditional Access) kullanılabilir.
• Yönetici hesaplarını ayırın. Günlük işler için kullanılan hesap ile yönetim hesabı aynı olmamalıdır.

Acil durum erişim hesapları

Kimlik doğrulama yöntemlerinde yaşanabilecek bir sorun veya yanlış yapılandırılmış bir erişim kuralı, tüm yöneticilerin kiracıya erişimini kaybetmesine yol açabilir. Microsoft bu nedenle iki veya daha fazla acil durum erişim (break-glass) hesabı oluşturulmasını önerir.

Bu hesaplar yalnızca bulutta tanımlı, güçlü ve kimlik avına dayanıklı yöntemlerle korunan, kullanımları izlenen ve günlük işlerde hiç kullanılmayan hesaplar olmalıdır.

Erişim yönetimi

Süreklilik yalnızca veriyi geri getirmekle ilgili değildir; doğru kişilerin doğru verilere erişmeye devam etmesi de gerekir.

• Yetkiler “en az yetki” ilkesine göre verilmeli, yönetici rolleri düzenli olarak gözden geçirilmelidir.
• Dışarıyla paylaşılan dosyalar ve misafir kullanıcılar periyodik olarak kontrol edilmelidir.
• İşten ayrılan personel için hesap kapatma, posta kutusu ve OneDrive verisinin devri tanımlı bir süreçle yapılmalıdır.

Hibrit ortamlarda dikkat edilmesi gerekenler

Birçok işletmede kullanıcılar şirket içi Active Directory’de tutulur ve Microsoft Entra ID ile eşitlenir. Bu yapıda bulut erişimi, şirket içi altyapının sağlığına da bağlıdır.

Eşitleme sunucusunun arızalanması, parola değişikliklerinin veya yeni kullanıcıların buluta yansımamasına neden olabilir. Bu nedenle eşitleme sunucusu kritik sistemler arasında değerlendirilmeli, yedeklenmeli ve izlenmelidir. Etki alanı denetleyicilerinin sağlığı da bulut sürekliliğinin bir parçası olarak ele alınmalıdır.

Senaryolara göre hazırlık

Kısa kontrol listesi

1. Kritik Microsoft 365 verileri için yedekleme yaklaşımı belirlendi mi?
2. Saklama süreleri iş ve mevzuat ihtiyacına göre tanımlandı mı?
3. Tüm kullanıcılar için MFA zorunlu mu?
4. Eski kimlik doğrulama protokolleri engellendi mi?
5. En az iki acil durum erişim hesabı var mı ve izleniyor mu?
6. Yönetici rolleri ve misafir erişimleri düzenli gözden geçiriliyor mu?
7. Hibrit yapıda eşitleme sunucusu yedekleniyor ve izleniyor mu?
8. Geri yükleme senaryoları en az bir kez test edildi mi?

Sonuç

Microsoft 365, güçlü ve yüksek erişilebilirlikli bir platformdur. Ancak platformun çalışıyor olması, işletmenin verisinin ve kimliklerinin korunduğu anlamına gelmez.

Gerçek süreklilik; verinin geri getirilebilir olmasını, kimliklerin korunmasını ve erişimlerin kontrol altında tutulmasını birlikte gerektirir.

Eretek Bilgi Sistemleri olarak Microsoft 365 ve hibrit altyapılarda yedekleme, kimlik güvenliği ve erişim yönetimini işletmenin süreklilik hedefleriyle uyumlu şekilde planlıyoruz.