Veri Merkezi Hedef Olunca: Yandex ve AWS Kesintilerinden Çıkan Süreklilik Planı

Veri merkezi sürekliliği, bir sağlayıcının tek binası fiziksel olarak hasar gördüğünde postanın, uygulamaların ve verinin başka bir arıza alanında ayakta kalmasını sağlayan plandır. Ekim 2026’da Yandex’in üç veri merkezi dört günde saldırıya uğradı ve ikisi tamamen durdu; AWS, Bahreyn bölgesinde yalnızca orada tutulan verinin kalıcı kaybolduğunu açıkladı. Ortak ders: yedeklilik aynı hasar alanında kalmamalıdır.

Olayın doğrulanmış kısmı ile savaşan tarafların kendi iddiaları bu yazıda ayrı tutuldu; iddialar tablolarda işaretli. Plan bölümü, bir işletmenin bu hafta başlayabileceği adımlarla bitiyor.

Veri merkezleri neden savaşta hedef olmaya başladı?

Eylül 2026’dan beri iki cephede de veri merkezleri vuruluyor. Rusya 15 Eylül’den itibaren Kiev’deki veri merkezlerini ve internet sağlayıcılarını hedef aldı; Ekim’de Yandex’in üç merkezi dron saldırısına uğradı. Mart 2026’da İran saldırıları AWS’nin BAE ve Bahreyn tesislerini vurmuştu. Tarafların gerekçeleri birbirinden farklı ve çoğu bağımsız doğrulanmış değil.

Gerekçeler tarafların kendi ifadesi. Rusya, Ukrayna’daki merkezlerin Ukrayna ordusu için istihbarat verisi işlediğini söylüyor; Ukrayna Dışişleri Bakanı ise Rusya’nın bilgi akışını kesmek için büyük veri merkezlerini hedef aldığını söyledi. Yandex saldırılarını Ukrayna resmen üstlenmedi; Zelenskiy, Rusya’nın Ukrayna’daki veri merkezlerini vurmaya devam ettiğini ve Ukrayna’nın karşılık verdiğini belirterek “Her zaman ayna gibi karşılık veririz” dedi (Al Jazeera).

İşletme açısından gerekçenin önemi yok, sonucun var: veri merkezi artık nadir bir fiziksel risk değil, planlanması gereken bir arıza türü. Ukrayna tarafındaki önlemler bir fikir veriyor. Eski bir savunma bakan yardımcısına göre veri merkezleri yıllar önce yurt dışına taşındı ve yer altı ağlara yatırım yapıldı, ama “her şeyi yer altına taşıyamazsınız” (Breaking Defense). Kiev’deki CityHost web barındırma sunucularını AB’ye taşıdı (RSF).

Yandex veri merkezlerinde ne oldu ve hangi hizmetler etkilendi?

Yandex’in Sasovo (8 Ekim) ve Vladimir (11 Ekim) merkezleri tamamen durdu, Kaluga’da (9 Ekim) birkaç modül devre dışı kaldı. Vladimir dalgasında 80’den fazla servis düştü; Astra’nın aktardığına göre kesinti Rusya’nın onlarca şehrinin yanında Kazakistan, Belarus ve Ermenistan’da da hissedildi (AP).

Tabloda Sasovo ve Vladimir etkileri AIF’in 12 Ekim derlemesinden, Yandex açıklamaları RG’nin aktardığı şirket yorumundan alındı. Posta 11 Ekim’den itibaren kademeli olarak geri geldi; bazı işlevler hâlâ eksik. Yandex Pay 12 Ekim’de tam çalışmıyordu; şirket hesap kayıtlarının birden çok sitede saklandığını ve hiçbirinin kaybolmadığını söyledi.

İşletmeyi ilgilendiren dört nokta var:

• Onarım takvimi uzun. AIF’in derlediği tahminlere göre güç ve soğutma onarımı haftalar, sunucu modüllerinin yenilenmesi aylar sürebilir; ekipman teslimi altı aya kadar uzayabilir.
• Sağlayıcı sorumluluğu daralıyor. AIF’e ve Informator’a göre Yandex kullanıcı sözleşmesine dron ve füze saldırılarını mücbir sebep olarak ekledi; şirket bunu Rus basınına hizmetlerde tek biçime getiren teknik bir güncelleme diye açıkladı.
• Taşınma teklif edildi. Yandex Cloud, müşterilerine Selectel, K2 Cloud ve VK Cloud’a hızlandırılmış yerleşim önerdi.
• Bulut müşterilerine çağrı. SecurityLab’ın aktardığı Yandex Cloud duyurusunda müşterilerden yalnız kendi erişilebilirlik bölgeleri arasında geçişle yetinmeyip mevcut tüm alternatif felaket kurtarma planlarını devreye almaları istendi; işlem gücü ve disk kotaları elle yönetime alındı, destek kanallarının da kararsız olabileceği bildirildi.

Güncelleme (12 Ekim 2026, akşam): Yandex’in basın servisi 11 Ekim akşamı Alice, arama, haritalar, taksi ve postaya erişimin kademeli olarak geri geldiğini, en çok kullanılan hizmetlerin öncelikli onarıldığını ve bazı işlevlerin kısıtlı kaldığını açıkladı. Yandex Pay 12 Ekim’de hâlâ tam çalışmıyordu; fintech başkanı Dmitriy Pirogov paraların güvende olduğunu söyleyip kesin süre veremedi (Interfax). Dijital Gelişim Bakanı Maksut Şadayev 12 Ekim’de saldırıları “benzeri görülmemiş” diye niteledi ve Savunma Bakanlığı ile tesislerin korunmasını görüştüklerini söyledi; somut önlem açıklamadı (Kommersant). TelecomDaily’den Denis Kuskov Vladimir’de sorunun haftalarca sürebileceğini, Mobile Research Group analisti Eldar Murtazin yurt içi sunucu fiyatlarının günler içinde yüzde 10-15 arttığını söyledi (Fontanka). Bunlar şirketlerin ve analistlerin açıklamalarıdır; bağımsız doğrulama yoktur.

Kendi ölçümümüz de var. 12 Ekim sabahı Yandex 360 kullanan bir kurumun Outlook’u giden postayı gönderemedi; web posta çalışıyordu. smtp.yandex.com 25, 465 ve 587 portlarında dışarıdaki ölçüm düğümlerinin çoğundan bağlantıyı reddediyordu, IMAP 993 açıktı. 14:11 UTC’de aynı ölçümde SMTP açıldı. Yandex 360 durum sayfasında 11 Ekim 01:00 UTC’den beri açık bir kayıt var: yükü azaltmak ve ana senaryoları ayakta tutmak için işlevlerin bir kısmı bilerek kısılıyor. Yandex’in kısıtlamayı anlatan açıklamaları Disk’te klasör ve çoklu dosya indirmeyi ve bazı Yandex 360 işlevlerini sayıyor (iXBT); posta ve SMTP anılmıyor. SMTP’nin kısılanlar arasında olduğunu Yandex doğrulamadı; elimizdeki yalnız zamanlama ve belirti uyumu.

Aynı bölgede birden çok erişilebilirlik alanı neden yetmedi?

Çünkü erişilebilirlik alanları bağımsız arızalara karşı korur; savaş ise ortak enerji, soğutma ve ağ düğümünü aynı anda keser. AWS, Bahreyn’de hasarın birden çok erişilebilirlik alanına yayıldığını ve bölgenin yedeklilik tasarımının kaldırabileceğinden fazla olduğunu bildirdi. BAE’de kayıp yalnız bir alanla (mec1-az2) sınırlı kaldı, diğer iki alan ve ortak bölgesel altyapı için onarım sürüyor (Help Net Security).

Yedekliliği basamaklara ayırınca tablo açılıyor:

Çoğu işletme ilk satırda duruyor: “çoklu bölge” ya da “yedekli bulut” alıyor ve yedekliliğin aynı hasar alanı içinde kaldığını fark etmiyor. AWS müşterilerinin çoğu kayıp kalıcı olmadan önce iş yükünü taşımış ya da yedeğine güvenmişti; kaybı taşıyanlar yalnızca o bölgede tutulan veriye sahip olanlardı.

Sağlayıcının durum sayfası kesintiyi göstermezse ne yapılır?

Durum sayfasını ikinci kaynak sayın ve kendi dış ölçümünüzü birinci kaynak yapın: hedefi birkaç ülkedeki düğümden, aynı düğümlerden bir kontrol hedefiyle birlikte ölçün. Yandex 360’ta 12 Ekim sabahı posta bileşeni olay göstermezken SMTP dışarıdan reddediliyordu.

1. Sağlayıcıdan bağımsız ağlardan ölçün. SMTP 587, IMAP 993 ve HTTPS için en az iki farklı ağdan, dakikada bir değil beş dakikada bir yeterli.
2. Her ölçüme bir kontrol hedefi ekleyin. Bazı ölçüm düğümleri SMTP gibi portlara çıkışa kapalıdır; kontrol hedefi (örneğin smtp.gmail.com:587) o düğümü eler.
3. İç ağdan ölçüme tek başına güvenmeyin. Aynı özel adres aralığını kullanan iki ağ, yanlış ağdaki komşuyu ölçmenize ve “sunucu kapalı” sonucuna varmanıza yol açabilir.
4. Alarmı iki ardışık ölçüme bağlayın. Tek bir başarısız ölçüm gürültüdür.

Çalışan betikler, örnek çıktılar ve host anahtarı parmak iziyle doğru makineye bağlandığınızı doğrulama yöntemi Erdem Özyurt’un ölçüm yazısında var. Sürekli izleme için Zabbix kurulum rehberi ve ağ izleme hizmetimiz aynı mantığı kurumsal ölçeğe taşır.

Posta sürekliliği için hangi adımlar atılır?

Beş adım: DNS’i posta sağlayıcısından ayırın, MX kayıtlarının TTL değerini 300 saniyeye indirin, giden posta için ikinci bir gönderim yolu hazırlayın, posta kutularını her gece ayrı bir yere IMAP ile yedekleyin ve gelen posta için yedek bir MX’in gerekip gerekmediğine karar verin.

1. DNS’i ayırın. MX kaydını değiştirebilmek için DNS’e erişmeniz gerekir. DNS’i de posta sağlayıcınız barındırıyorsa kurtarma yolu da aynı kesintiyle kapanır. Alan adı ve DNS yönetimi ayrı bir yerde, ayrı bir hesapta ve çift doğrulamayla dursun (alan adı ve SSL hizmeti).

2. TTL’i önceden düşürün. MX ve ilgili A kayıtlarında 300 saniye yeterli. Kesinti anında TTL’i düşürmek, eski değerin süresi dolana kadar işe yaramaz.

3. Gelen postayı doğru anlayın. RFC 5321, gönderen sunucunun en az 4-5 gün yeniden denemesini öngörür (bölüm 4.5.4.1). Saatler süren bir kesintide gelen posta çoğunlukla gönderenin kuyruğunda bekler. Yedek MX günler süren kesintiler için anlamlıdır ve şu gibi görünür:

ornek.com.  300  IN  MX  10  mx.birincil-saglayici.example.
ornek.com.  300  IN  MX  20  mx.yedek-saglayici.example.
ornek.com.  300  IN  TXT "v=spf1 include:_spf.birincil.example include:_spf.yedek.example -all"

Yedek MX yalnız postayı kuyruklar; çalışanlara kutu sunmaz. Bilinmeyen alıcıları da birincil gibi reddetmezse spam kabul edip sonra geri göndererek sizi kara listeye düşürebilir. Kutuya erişim için ikinci bir sağlayıcıda, alan adı doğrulaması önceden yapılmış hazır bir kiracı tutmak gerekir.

4. Giden postayı ikiye bölün. İkinci gönderim yolunun SPF ve DKIM kaydını kesintiden önce ekleyin. SPF, DNS sorgusu yapan en fazla 10 mekanizmaya izin verir (RFC 7208); include eklerken sınırı aşmamaya dikkat edin, aşarsanız tüm SPF geçersiz olur.

5. Arşivi ayrı tutun. Her gece IMAP ile posta kutularını şifreli olarak başka bir bölgedeki depoya aktarın (imapsync ya da mbsync gibi araçlarla) ve geri yüklemeyi çeyrekte bir deneyin. Sağlayıcı kapanırsa elinizde geçmiş posta olur. Yedeğin silinememesi için değişmez yedek yazımızdaki ilkeler burada da geçerli.

Outlook’ta gönderilemeyen iletiler Giden Kutusu’nda bekler ve sağlayıcı dönünce kendiliğinden gider. Acil bir iletiyi web postadan ayrıca gönderdiyseniz Giden Kutusu’ndaki kopyayı silin, yoksa alıcıya iki kez gider.

Bulut iş yükleri ve veri için hangi hazırlık gerekir?

Veriyi iki arıza alanında tutun: biri sağlayıcının dışında ve başka bir ülkede. Uygulamayı kodla tanımlayın ki başka yerde yeniden kurulabilsin, DNS TTL değerini düşük tutun ve geri yüklemeyi düzenli deneyin. AWS Bahreyn’de kayıp, iş yükünü önceden taşımamış ve yedeği olmayan müşterilere kaldı.

• Veri: üç kopya, iki ortam, bir kopya sağlayıcı ve ülke dışında. Kopyalardan biri değiştirilemez (immutable) olsun.
• Kurulum: sunucu yapılandırması ve uygulama dağıtımı kodda dursun; sıfırdan kurulum süresini bir kez ölçün. Ölçmediğiniz süre planınızda yazan süre değildir.
• Bağımlılıklar: kimlik doğrulama, ödeme, e-imza, DNS ve izleme gibi ortak servisleri listeleyin. İş yükünüz sağlam bölgede olsa bile bunlardan biri aynı sağlayıcıdaysa kesinti size de ulaşır.
• Süre hedefleri: her kritik hizmet için en fazla kabul edilebilir kesinti süresini (RTO) ve veri kaybını (RPO) yazın; yedekleme sıklığı ve ikinci site bu iki sayıdan türer.

Sözleşmede savaş ve mücbir sebep maddesi neden önemli?

Çünkü mücbir sebep listesindeki bir olay, hizmet seviyesi tazminatını ve sağlayıcının sorumluluğunu doğrudan sınırlar. AIF’e ve Informator’a göre Yandex dron saldırılarını mücbir sebep listesine ekledi; şirket bunu tek biçime getiren teknik bir güncelleme olarak açıkladı. Hukuki etkisi sözleşmeden sözleşmeye değişir, ama böyle bir kesintide tazminat beklentisini azaltır. Kendi sözleşmenizde savaş, terör ve kamu otoritesi eylemi maddelerini, veri konumunu ve alt yüklenicileri okuyun.

Kişisel veri işliyorsanız verinin hangi ülkede tutulduğu ayrıca KVKK kapsamında değerlendirilir; teknik tedbirlerin kontrol listesi KVKK teknik tedbirler yazımızda. Bu bölüm hukuki görüş değildir; kritik sözleşmelerde hukuk danışmanınızla doğrulayın.

Bu hafta başlamak için kontrol listesi nedir?

On soru; tamamına “evet” diyemiyorsanız ilk “hayır” planınızın zayıf halkasıdır.

Genel güvenlik tabanı için KOBİ siber güvenlik kontrol listesi bu planın tamamlayıcısıdır.

Sonuç

Veri merkezi saldırıları bir haber başlığı olmaktan çıkıp bir planlama girdisi oldu. Olayın tarafları ve gerekçeleri tartışmalı; işletmenin sorusu ise kısa: bugün sağlayıcım bir sabah kapanırsa postam, verim ve ekibim ne yapar? Cevabın iki kısmı var. Birincisi ölçüm: sağlayıcının durum sayfası değil, kendi dış ölçümünüz. İkincisi ayrım: DNS, yedek ve ikinci gönderim yolu aynı arıza alanında olmasın.

Kurumsal postanızın ve yedeklerinizin süreklilik planını kurmak için kurumsal e-posta ve yedekleme hizmetlerimize bakabilir veya doğrudan iletişime geçebilirsiniz.