# Microsoft 365, E-posta ve SaaS Verileri Nasıl Yedeklenmeli?

**URL:** https://securesys.com.tr/tr/bilgi-merkezi/backup-yedekleme-is-surekliligi/microsoft-365-saas-verileri-yedekleme

![Microsoft 365, E-posta ve SaaS Verileri Nasıl Yedeklenmeli?](/images/bilgi-merkezi/covers/cover-backup-10.webp)

Birçok kurum Microsoft 365, Google Workspace ve benzeri SaaS platformlarına geçtikten sonra kritik verilerinin otomatik olarak tamamen korunduğunu düşünür.

E-posta artık şirket içindeki Exchange sunucusunda değildir.

Dosyalar OneDrive veya SharePoint üzerindedir.

Ekip çalışmaları Teams üzerinden yürütülür.

Kullanıcı hesapları Entra ID üzerinden yönetilir.

Bu nedenle bazı kurumlarda şu düşünce oluşur:

**“Microsoft zaten verileri yedekliyor. Bizim ayrıca backup almamıza gerek yok.”**

Bu yaklaşım riskli olabilir.

Cloud sağlayıcısı altyapının erişilebilirliği, donanım dayanıklılığı ve servis sürekliliği konusunda güçlü mekanizmalar sağlayabilir.

Ancak bu durum kurumun her veri kaybı senaryosunda istediği noktaya geri dönebileceği anlamına gelmez.

Örneğin;

bir kullanıcı yanlışlıkla binlerce e-postayı silebilir,

bir administrator kritik SharePoint sitesini kaldırabilir,

ransomware OneDrive ile senkronize edilen dosyaları şifreleyebilir,

ele geçirilmiş hesap verileri silebilir,

retention politikası yanlış yapılandırılabilir,

eski bir çalışanın hesabı kaldırılırken verileri kaybolabilir.

Bu nedenle SaaS ortamlarında da ayrı bir **backup ve recovery stratejisi** gereklidir.

### Microsoft 365 Backup Nedir?

Microsoft 365 Backup, Microsoft 365 içerisinde bulunan kritik verilerin bağımsız veya ek bir yedekleme katmanı ile korunmasıdır.

Bu veriler arasında;

Exchange Online e-postaları,

OneDrive dosyaları,

SharePoint siteleri,

Teams verileri

bulunabilir.

Amaç yalnızca veriyi saklamak değildir.

Amaç:

**istenen zaman noktasına güvenilir ve kontrollü şekilde geri dönebilmektir.**

### Microsoft 365 Verileri Nerede Bulunur?

Microsoft 365 tek bir uygulama değildir.

Birden fazla servisten oluşur.

Örneğin:

**Exchange Online** → E-posta, takvim, mailbox verileri

**OneDrive** → Kullanıcı dosyaları

**SharePoint Online** → Kurumsal doküman ve site içerikleri

**Microsoft Teams** → Mesajlar, ekip yapıları, dosyalar ve iş birliği verileri

Bu nedenle backup planı her servisin veri yapısını ayrı ayrı değerlendirmelidir.

### Exchange Online Backup Neden Gereklidir?

E-posta kurumsal işletmeler için kritik veri kaynaklarından biridir.

E-postalar;

müşteri iletişimi,

sözleşme süreçleri,

teklifler,

muhasebe kayıtları,

proje kararları

içerebilir.

Yanlışlıkla veya kötü niyetli olarak silinen bir mailbox ciddi iş kaybına neden olabilir.

Bu nedenle Exchange Online verilerinin recovery stratejisi açıkça tanımlanmalıdır.

### Microsoft 365'te Silinen E-posta Geri Getirilebilir mi?

Belirli retention ve recovery mekanizmaları bulunabilir.

Ancak her senaryoda sınırsız süreyle geri dönüş mümkün değildir.

Bu nedenle kurum şu soruya cevap vermelidir:

**“Altı ay önce silinen bir e-postayı kesin olarak geri getirebilir miyiz?”**

Eğer cevap net değilse uzun vadeli backup ihtiyacı değerlendirilmelidir.

### Retention ile Backup Aynı Şey midir?

Hayır.

Bu SaaS dünyasında en önemli ayrımlardan biridir.

Retention Policy:

verinin ne kadar süre saklanacağını belirler.

Backup:

verinin bağımsız restore point'lerini oluşturur.

Retention veri yönetimi politikasıdır.

Backup ise recovery mekanizmasıdır.

### Legal Hold Nedir?

Legal Hold, belirli verilerin hukuki veya soruşturma amacıyla silinmesini engellemek için kullanılan saklama mekanizmasıdır.

Örneğin dava sürecindeki bir kullanıcının e-postaları silinse bile korunabilir.

Ancak Legal Hold genel backup yerine geçmez.

Çünkü amacı:

**operasyonel recovery değil, veri muhafazasıdır.**

### Microsoft 365 Retention Policy Backup Yerine Geçer mi?

Tam anlamıyla hayır.

Retention Policy verinin saklanmasını sağlayabilir.

Ancak backup sistemleri;

bulk restore,

point-in-time recovery,

cross-user restore,

ayrı storage,

bağımsız yönetim

gibi ek yetenekler sunabilir.

Bu nedenle iki yaklaşım birlikte kullanılabilir.

### OneDrive Backup Neden Gereklidir?

OneDrive birçok kurumda kullanıcıların masaüstü ve doküman klasörlerini senkronize etmek için kullanılır.

Bu büyük kolaylık sağlar.

Ancak aynı senkronizasyon mekanizması ransomware saldırısında risk oluşturabilir.

### Ransomware OneDrive Dosyalarını Nasıl Etkileyebilir?

Bir kullanıcının bilgisayarında ransomware çalıştığını düşünelim.

Dosyalar şifrelenir.

OneDrive sync client bu dosyaları değişiklik olarak algılar.

Şifrelenmiş dosyalar cloud ortamına senkronize edilebilir.

Bu nedenle cloud storage kullanmak ransomware riskini tamamen ortadan kaldırmaz.

### Versioning Ransomware'e Karşı Yeterli mi?

Versioning önemli bir koruma mekanizmasıdır.

Dosyanın eski versiyonlarına dönmeyi sağlayabilir.

Ancak çok büyük saldırılarda;

binlerce dosyanın restore edilmesi,

version geçmişinin sınırlı olması,

hesap compromise

gibi sorunlar ortaya çıkabilir.

Bağımsız backup, toplu recovery süreçlerini kolaylaştırabilir.

### SharePoint Backup Neden Önemlidir?

SharePoint yalnızca dosya saklama alanı değildir.

Kurumsal;

intranet,

doküman kütüphaneleri,

proje siteleri,

workflow'lar,

izin yapıları

içerebilir.

Yanlışlıkla site collection silinmesi veya geniş kapsamlı permission değişikliği ciddi operasyonel sorun oluşturabilir.

### SharePoint Restore Sadece Dosya Restore mudur?

Hayır.

Gerçek recovery;

site,

library,

folder,

file,

permission,

metadata

seviyelerinde yapılabilir.

Bu nedenle backup çözümü SharePoint yapısını anlamalıdır.

### Teams Backup Neden Karmaşıktır?

Microsoft Teams aslında birçok Microsoft 365 servisinin birleşimidir.

Örneğin Teams içerisindeki dosyalar çoğu zaman SharePoint veya OneDrive üzerinde bulunur.

Mesajlar farklı servislerde saklanabilir.

Bu nedenle “Teams backup” tek bir veri kaynağını yedeklemek anlamına gelmez.

### Teams Backup Neleri Kapsamalı?

İhtiyaca göre;

Teams yapıları,

kanallar,

mesajlar,

dosyalar,

ekip üyelikleri

değerlendirilebilir.

Kullanılan backup ürününün hangi Teams bileşenlerini gerçekten koruduğu kontrol edilmelidir.

### SaaS Backup Nedir?

SaaS Backup, cloud tabanlı uygulamalardaki verilerin bağımsız backup platformuna kopyalanmasıdır.

Örneğin;

Microsoft 365,

Google Workspace,

Salesforce,

CRM sistemleri,

bulut tabanlı ERP uygulamaları

backup kapsamına alınabilir.

### Cloud-to-Cloud Backup Nedir?

Cloud-to-Cloud Backup, bir SaaS veya cloud servisindeki verinin başka cloud storage veya backup ortamına kopyalanmasıdır.

Örneğin:

Microsoft 365

↓

Bağımsız Backup Cloud

Bu sayede production SaaS ortamından farklı recovery alanı oluşturulur.

### Cloud-to-Cloud Backup Neden Önemlidir?

Eğer production account tamamen compromise olursa bağımsız backup ortamı kullanılabilir.

Bu nedenle özellikle;

ayrı identity,

ayrı tenant,

ayrı cloud account

kullanılması güvenliği artırabilir.

### Shared Responsibility Model Nedir?

Cloud ve SaaS güvenliğinde temel kavramlardan biri:

#### Shared Responsibility Model

yani:

**Paylaşılan Sorumluluk Modelidir.**

Cloud sağlayıcısı platformun belirli katmanlarından sorumludur.

Kurum ise;

kullanıcı hesapları,

erişim yetkileri,

veri yönetimi,

retention,

backup stratejisi,

endpoint güvenliği

gibi konulardan sorumlu olabilir.

### SaaS Sağlayıcısı Her Veriyi Geri Getirmek Zorunda mı?

Her durumda değil.

Sağlayıcının sunduğu retention ve restore sınırları sözleşmeye ve hizmet özelliklerine bağlıdır.

Bu nedenle kurum sağlayıcının özelliklerine güvenmek yerine kendi recovery gereksinimlerini belirlemelidir.

### Microsoft 365 Backup'ta RPO Nasıl Belirlenir?

RPO, kabul edilebilir veri kaybı süresine göre belirlenir.

Örneğin kritik mailbox için:

RPO = 1 saat

belirlenebilir.

Bu durumda backup platformunun yaklaşık saatlik veri koruması sağlaması gerekebilir.

### Microsoft 365 Backup'ta RTO Nasıl Belirlenir?

RTO yalnızca backup'ın varlığıyla ilgili değildir.

Ayrıca;

restore hızı,

API limitleri,

veri hacmi,

network,

kullanıcı sayısı

gibi faktörlere bağlıdır.

Örneğin tek e-posta birkaç dakika içinde restore edilebilir.

Ancak 5 TB SharePoint ortamının tamamı çok daha uzun sürebilir.

### API Throttling Nedir?

SaaS platformları API kullanımını sınırlayabilir.

Bu:

#### API Throttling

olarak adlandırılır.

Backup veya restore işlemi çok fazla API çağrısı yaparsa servis geçici olarak hız sınırlaması uygulayabilir.

Bu durum özellikle büyük restore işlemlerinde RTO'yu etkileyebilir.

### SaaS Backup'ta Büyük Restore Neden Test Edilmeli?

Tek dosya restore testi başarılı olabilir.

Ancak gerçek felakette;

500 kullanıcı,

binlerce mailbox,

terabaytlarca dosya

restore edilmesi gerekebilir.

Bu nedenle yalnızca küçük restore testleri gerçek kapasiteyi göstermeyebilir.

### Microsoft 365 Tenant Compromise Nedir?

Tenant Compromise, saldırganın Microsoft 365 ortamında yüksek yetki elde etmesidir.

Örneğin Global Administrator hesabı ele geçirilebilir.

Bu durumda saldırgan;

kullanıcıları değiştirebilir,

MFA politikalarını etkileyebilir,

mailbox'lara erişebilir,

SharePoint verilerini silebilir.

Bu nedenle backup account'larının aynı trust boundary içerisinde tutulması risklidir.

### Global Administrator Backup Admin Olmalı mı?

Mümkünse görev ayrımı uygulanmalıdır.

Bir account'ın hem Microsoft 365 tenant üzerinde hem backup sistemi üzerinde sınırsız yetkiye sahip olması blast radius'u artırır.

Bu nedenle:

Microsoft 365 Admin

ve

Backup Admin

hesapları ayrılabilir.

### MFA SaaS Backup İçin Zorunlu mu?

Kritik backup ortamında güçlü şekilde uygulanmalıdır.

Özellikle;

backup portal,

restore işlemleri,

administrator login

MFA ile korunmalıdır.

### Conditional Access Kullanılabilir mi?

Evet.

Backup administrator erişimi;

belirli cihaz,

belirli ülke,

belirli IP,

compliant device

gibi koşullarla sınırlandırılabilir.

Bu özellikle cloud backup yönetim konsollarında faydalıdır.

### SaaS Backup Admin Hesabı Günlük Kullanıcı Hesabı Olmalı mı?

Hayır.

Günlük e-posta ve web kullanımı yapılan account yüksek risk taşır.

Phishing ile ele geçirilebilir.

Backup admin hesabı ayrı ve daha sıkı güvenlik politikalarıyla korunmalıdır.

### Privileged Access Workstation Kullanılabilir mi?

Kritik organizasyonlarda evet.

Backup administrator yalnızca hardened PAW üzerinden yönetim yapabilir.

Bu yöntem phishing ve endpoint malware riskini azaltır.

### SaaS Backup Verileri Şifrelenmeli mi?

Evet.

Backup verisi hem:

#### In Transit

hem:

#### At Rest

şifrelenmelidir.

Bu özellikle e-posta ve doküman backup'larında kritiktir.

### Encryption Key Kimde Olmalı?

Bu kullanılan backup çözümüne göre değişebilir.

Kurum;

provider-managed key

veya

customer-managed key

kullanabilir.

Önemli olan key management sorumluluğunun net olmasıdır.

### SaaS Backup Immutable Olabilir mi?

Evet.

Backup platformu immutable storage veya Object Lock destekleyebilir.

Bu özellikle administrator compromise ve ransomware riskine karşı önemlidir.

### Microsoft 365 Backup Air-Gapped Olabilir mi?

Fiziksel anlamda zor olabilir.

Ancak logical air-gap oluşturulabilir.

Örneğin;

ayrı backup tenant/account,

farklı identity,

immutable storage,

restricted API access

kullanılabilir.

### Aynı Tenant İçinde Backup Riskli mi?

Tamamen yanlış değildir.

Ancak tenant-wide administrator compromise senaryosunda backup ortamının da etkilenme riski değerlendirilmelidir.

Kritik kuruluşlarda ayrı güvenlik sınırı oluşturmak daha güçlü olabilir.

### E-posta Account Compromise Sonrası Backup Neden Önemlidir?

Saldırgan mailbox'a eriştiğinde yalnızca mail okuyabilir değil, mail silebilir veya kurallar oluşturabilir.

Örneğin:

forward rule,

inbox rule,

mail deletion

uygulanabilir.

Backup geçmiş e-posta kayıtlarının korunmasını sağlar.

### Business Email Compromise ve Backup İlişkisi

Business Email Compromise – BEC saldırılarında saldırgan e-posta hesabına erişebilir.

Bazı durumlarda izlerini gizlemek için mail silebilir.

Backup, olay sonrası forensic incelemede eski e-postaların geri getirilmesine yardımcı olabilir.

### Backup Forensic Amaçla Kullanılabilir mi?

Evet.

Geçmiş mailbox verileri incident investigation için değerli olabilir.

Örneğin saldırganın ilk phishing e-postası silinmiş olabilir.

Backup üzerinden geri getirilebilir.

Ancak forensic süreçlerde veri bütünlüğü ve chain of custody gereksinimleri ayrıca değerlendirilmelidir.

### Mailbox Backup Ne Kadar Süre Saklanmalı?

Tek bir doğru süre yoktur.

Retention;

iş ihtiyacı,

hukuki gereksinimler,

regülasyon,

depolama maliyeti

dikkate alınarak belirlenmelidir.

Örneğin bazı veriler birkaç yıl saklanabilir.

Ancak gereksiz uzun retention veri riskini de artırabilir.

### Kullanıcı İşten Ayrıldığında Verileri Ne Olur?

Offboarding süreçlerinde en kritik konulardan biri budur.

Kullanıcının hesabı silindiğinde;

mailbox,

OneDrive,

Teams verileri

etkilenebilir.

Bu nedenle çalışan ayrılmadan önce veri sahipliği ve retention süreci planlanmalıdır.

### Leaver Backup Nedir?

Çalışan kurumdan ayrıldığında mailbox ve OneDrive verisinin belirli süre backup'ta saklanması:

#### Leaver Backup

yaklaşımı olarak düşünülebilir.

Bu sayede lisans kaldırıldıktan sonra da eski veriye erişim mümkün olabilir.

### Microsoft 365 Lisansı Kaldırılırsa Ne Olur?

Veri saklama davranışı kullanılan servis ve retention yapılandırmasına göre değişebilir.

Bu nedenle kurum offboarding prosedürünü test etmeli ve dokümante etmelidir.

Backup bu sürece ek güvenlik sağlayabilir.

### OneDrive Kullanıcıdan Kullanıcıya Restore Edilebilir mi?

İyi bir backup sistemi:

Kullanıcı A'nın dosyasını

Kullanıcı B'ye

veya alternatif lokasyona restore edebilir.

Bu özellikle çalışan ayrıldığında faydalıdır.

### SharePoint Site Restore Nasıl Yapılır?

Recovery ihtiyacına göre;

full site,

library,

folder,

file

seviyesinde restore yapılabilir.

Granular restore imkanı operasyonel süreyi azaltır.

### Granular Restore Nedir?

Granular Restore, tüm backup yerine yalnızca gerekli objenin geri getirilmesidir.

Örneğin:

tek mail,

tek dosya,

tek klasör,

tek kullanıcı

restore edilebilir.

Bu özellikle SaaS backup için çok önemlidir.

### Full Tenant Restore Mümkün mü?

Backup ürününe bağlıdır.

Ancak gerçek dünyada tüm Microsoft 365 tenant'ını aynı anda restore etmek oldukça karmaşık olabilir.

Bu nedenle recovery priority önceden belirlenmelidir.

### SaaS Recovery Priority Nasıl Belirlenir?

Örneğin:

Priority 1 → Yönetim ve kritik operasyon mailbox'ları

Priority 2 → Finans ve satış

Priority 3 → Genel kullanıcılar

gibi sıralama yapılabilir.

Aynı yaklaşım SharePoint siteleri için de uygulanabilir.

### Exchange Online Restore Testi Nasıl Yapılmalı?

Örnek test:

- Test e-postası oluşturulur.
- Backup alınır.
- E-posta silinir.
- Restore işlemi yapılır.
- İçerik ve attachment kontrol edilir.
- Restore süresi ölçülür.

### OneDrive Restore Testi

Test sırasında;

dosya silme,

dosya ransomware benzeri değiştirme,

folder restore,

alternate location restore

senaryoları uygulanabilir.

### SharePoint Restore Testi

Sadece dosya değil;

metadata,

permission,

version

bilgileri de doğrulanmalıdır.

### Teams Restore Testi

Kullanılan çözümün hangi Teams verilerini koruduğu test edilmelidir.

Örneğin;

channel,

file,

team structure,

message

restore yetenekleri ayrı ayrı incelenebilir.

### SaaS Backup Monitoring

Backup sisteminin günlük olarak izlenmesi gerekir.

Örneğin;

failed job,

authentication failure,

API error,

license issue,

storage full,

backup delay

alarm üretmelidir.

### Backup Job Başarısızlığı Ne Kadar Kritik?

Microsoft 365 ortamında 500 kullanıcı varsa birkaç günlük backup başarısızlığı ciddi veri açığı oluşturabilir.

Bu nedenle backup failure yalnızca bilgi mesajı olmamalıdır.

Belirlenen sürede çözülmezse escalation uygulanmalıdır.

### SaaS Backup SIEM'e Entegre Edilebilir mi?

Evet.

Özellikle şu olaylar SIEM'e gönderilebilir:

administrator login,

restore işlemi,

backup deletion,

retention change,

MFA change,

API access failure.

Bu olaylar güvenlik izleme açısından değerlidir.

### Restore İşlemleri Loglanmalı mı?

Kesinlikle.

Bir administrator'ın binlerce mailbox e-postasını restore veya export etmesi normal davranış olmayabilir.

Bu nedenle restore işlemleri audit edilmelidir.

### Backup Export Riski

Backup çözümleri bazen veri export özelliği sunar.

Örneğin mailbox PST olarak indirilebilir.

Bu özellik yetkisiz kullanılırsa data exfiltration riski oluşturur.

Bu nedenle export yetkileri sınırlandırılmalıdır.

### DLP Backup Verisini Korur mu?

DLP çoğunlukla production veri hareketlerini izler.

Backup storage ayrı bir alan olduğundan doğrudan aynı kontrol kapsamında olmayabilir.

Bu nedenle backup repository'ye erişim ayrıca korunmalıdır.

### Backup Verisi Hassas Veri midir?

Evet.

Backup genellikle production sistemindeki verinin tam kopyasını içerir.

Bu nedenle bazı durumlarda production'dan bile daha değerli olabilir.

Çünkü tek backup dosyası içerisinde;

binlerce mailbox,

müşteri verileri,

çalışan verileri,

dokümanlar

bulunabilir.

### KVKK Açısından Microsoft 365 Backup

Backup içerisinde kişisel veri varsa KVKK açısından bu veriler de korunmalıdır.

Dikkat edilmesi gereken konular arasında;

erişim kontrolü,

retention,

şifreleme,

imha,

yurt dışı veri aktarımı

bulunabilir.

### SaaS Backup Verisi Yurtdışında Tutulursa

Backup sağlayıcısının data center lokasyonu önemlidir.

Kişisel veri içeren backup'ların yurtdışında tutulması veri aktarımı açısından hukuki değerlendirme gerektirebilir.

Bu nedenle sözleşme öncesinde veri lokasyonu öğrenilmelidir.

### Backup Retention ile Veri Minimizasyonu

Backup'ı sınırsız süre saklamak her zaman daha güvenli değildir.

Gereksiz veri;

hukuki,

gizlilik,

siber güvenlik

riskini artırabilir.

Bu nedenle retention iş ve mevzuat ihtiyacına göre belirlenmelidir.

### SaaS Backup ve ISO 27001

ISO/IEC 27001 açısından cloud ve SaaS sistemlerindeki verilerin;

gizlilik,

bütünlük,

erişilebilirlik

gereksinimleri risk bazlı şekilde korunmalıdır.

Backup bu kapsamda veri erişilebilirliğini ve recovery kabiliyetini destekleyen önemli kontrollerden biridir.

### ISO 22301 ve SaaS Recovery

Kritik iş süreçleri Microsoft 365 veya başka SaaS platformlarına bağımlıysa iş sürekliliği planında bu servislerin kaybı da değerlendirilmelidir.

Örneğin Microsoft 365 erişilemiyorsa:

İletişim nasıl sağlanacak?

Dosyalara nasıl erişilecek?

Alternatif iletişim sistemi var mı?

Bu konular yalnızca backup ile çözülemez.

### SaaS Provider Outage Senaryosu

Microsoft 365 gibi büyük platformların yüksek erişilebilirliği vardır.

Ancak hiçbir sistem yüzde 100 kesintisiz değildir.

Provider outage durumunda backup verisinin bulunması faydalı olabilir.

Ancak backup'tan production SaaS servisine erişim olmadan her zaman doğrudan çalışma mümkün değildir.

Bu nedenle BCP ayrıca planlanmalıdır.

### E-posta İçin Alternatif İş Sürekliliği

Kritik organizasyonlarda büyük SaaS outage durumunda;

alternatif domain,

acil durum mailbox sistemi,

telefon veya messaging

gibi yöntemler değerlendirilebilir.

Backup yalnızca geçmiş veriyi sağlar.

### SaaS Backup ile High Availability Arasındaki Fark

SaaS sağlayıcının yüksek erişilebilirliği:

servisin çalışmasını sağlar.

Backup ise:

veri kaybı durumunda geçmişe dönmeyi sağlar.

Bu iki kavram birbirinin alternatifi değildir.

### SaaS Backup ile Archive Arasındaki Fark

Archive daha çok uzun süreli saklama ve arama için kullanılır.

Backup ise hızlı veya güvenilir recovery için tasarlanır.

Örneğin e-posta archive sistemi compliance için kullanılabilir.

Ancak mailbox disaster recovery için ayrı backup gerekebilir.

### SaaS Backup ile eDiscovery Arasındaki Fark

eDiscovery;

hukuki arama,

soruşturma,

veri inceleme

amacıyla kullanılır.

Backup ise restore amacı taşır.

Birbirlerini destekleyebilirler ancak aynı değildirler.

### SaaS Backup Vendor Seçiminde Nelere Bakılmalı?

Çözüm seçerken şu sorular sorulabilir:

Microsoft 365'in hangi servislerini destekliyor?

Granular restore var mı?

Immutable backup var mı?

Data hangi ülkede tutuluyor?

Encryption var mı?

MFA destekliyor mu?

Retention ne kadar?

API throttling nasıl yönetiliyor?

Tenant-to-tenant restore mümkün mü?

Bulk restore performansı nasıl?

Audit log var mı?

### SaaS Backup SLA Nasıl Değerlendirilmeli?

Sadece backup platformunun uptime'ına bakılmamalıdır.

Ayrıca;

backup success rate,

restore time,

support response,

data durability

değerlendirilmelidir.

### Exit Plan SaaS Backup İçin Neden Önemli?

Backup sağlayıcısı değiştirildiğinde eski verilerin nasıl alınacağı bilinmelidir.

Örneğin:

Bulk export mümkün mü?

Hangi formatta?

Ne kadar sürede?

Ek ücret var mı?

Bu sorular vendor lock-in riskini azaltır.

### Microsoft 365 Backup için Örnek Mimari

Kurumsal bir yapı şu şekilde olabilir:

#### Microsoft 365 Tenant

↓

#### Backup API / SaaS Connector

↓

#### Independent Backup Platform

↓

#### Separate Backup Account

↓

#### Encrypted & Immutable Storage

↓

#### Long-Term Retention

Bu mimaride production SaaS ortamıyla backup güvenlik sınırı ayrılır.

### Kritik Kullanıcılar İçin Farklı Backup Politikası Olmalı mı?

Olabilir.

Örneğin;

üst yönetim,

finans,

hukuk,

AR-GE

kullanıcıları daha yüksek kritik seviyeye sahip olabilir.

Bunlar için daha uzun retention veya daha sık backup uygulanabilir.

### VIP Mailbox'lar Neden Özel Korunmalı?

VIP mailbox'lar saldırganlar için yüksek değer taşır.

CEO veya CFO mailbox'ında;

finansal bilgiler,

stratejik planlar,

müşteri yazışmaları

bulunabilir.

Bu nedenle recovery ve audit politikaları daha sıkı olabilir.

### Shared Mailbox'lar Backup Kapsamına Alınmalı mı?

Evet.

Shared mailbox'lar bazen kritik iş süreçlerini taşır.

Örneğin:

sales@

finance@

support@

gibi hesaplar backup kapsamına dahil edilmelidir.

### Public Folder'lar Unutulmamalı

Kurum hâlâ Public Folder kullanıyorsa bu veriler de backup scope içerisine alınmalıdır.

### Microsoft 365 Backup'ta En Sık Yapılan Hatalar

Kurumlarda sık görülen hatalar şunlardır:

- “Microsoft zaten yedekliyor” varsayımı,
- retention ile backup'ı aynı şey sanmak,
- yalnızca e-posta yedekleyip SharePoint ve OneDrive'ı unutmak,
- Teams verilerini kapsam dışında bırakmak,
- backup admin hesabını Global Admin ile aynı kullanmak,
- MFA kullanmamak,
- restore testi yapmamak,
- API throttling'i hesaba katmamak,
- backup data location'ını bilmemek,
- çalışan ayrıldığında backup politikasını planlamamak,
- bulk restore performansını test etmemek.

### Microsoft 365 Backup Kontrol Listesi

Kurum şu sorulara net cevap verebilmelidir:

Exchange Online backup var mı?

OneDrive backup var mı?

SharePoint backup var mı?

Teams backup kapsamı nedir?

Retention süresi ne kadar?

Immutable backup kullanılıyor mu?

Backup production tenant'tan bağımsız mı?

MFA kullanılıyor mu?

Backup verisi hangi ülkede?

Encryption aktif mi?

Restore test edildi mi?

Bulk restore süresi ölçüldü mü?

Bu sorular SaaS backup olgunluğunu anlamak için güçlü bir başlangıç noktasıdır.

### Sonuç: SaaS Kullanmak Backup Sorumluluğunu Ortadan Kaldırmaz

Microsoft 365 ve diğer SaaS platformları yüksek erişilebilirlik ve güçlü altyapı avantajı sunar.

Ancak bu servisleri kullanmak:

yanlış silme,

hesap ele geçirilmesi,

ransomware,

retention hatası,

administrator hatası,

offboarding problemi

gibi veri kaybı risklerini ortadan kaldırmaz.

Bu nedenle modern SaaS güvenliğinde backup ayrı bir güvenlik katmanı olarak değerlendirilmelidir.

Güçlü bir SaaS backup mimarisinde;

**Cloud-to-Cloud Backup,**

**Immutable Storage,**

**Encryption,**

**MFA,**

**Separate Backup Admin,**

**Long-Term Retention,**

#### Granular Restore

ve **Restore Testing**

birlikte kullanılmalıdır.

En kritik prensip şudur:

**SaaS sağlayıcının hizmeti ayakta tutması ile kurumun kendi verisini istediği zamana geri döndürebilmesi aynı şey değildir.**

Bu nedenle Microsoft 365 backup stratejisi yalnızca:

“Veri cloud'da mı?”

sorusuyla değil;

**“Bu veri yanlışlıkla silinir, şifrelenir veya administrator hesabı ele geçirilirse bağımsız olarak nasıl geri döneriz?”**

sorusuyla tasarlanmalıdır.

Gerçek SaaS dayanıklılığı bu noktada başlar.