Bir haftada iki hosting firması saldırıya uğradı: Yedekleriniz sağlayıcınızın kontrol düzleminden ne kadar uzakta?

Geçen hafta Rusya'daki iki hosting sağlayıcısı arka arkaya ağır saldırılar yaşadı. Olaylar Rusya'da geçtiği için buradan uzak görünebilir. Yine de konu jeopolitik değil, mimari: Altyapıyı yöneten sistemin kendisi ele geçirildiğinde müşterinin elinde ne kalıyor? Bu soru, Türkiye'de bir VPS sağlayıcısında, Hetzner'de ya da büyük bir bulutta çalışan her ekip için geçerli.

Ne oldu?

Beget: Kontrol düzlemi üzerinden silme

Rusya'nın büyük hosting firmalarından Beget, 2 Kasım gecesi bir siber saldırıya uğradı. Şirketin müşterilerine yaptığı açıklamalara göre saldırganlar altyapının yönetim katmanına (control plane) erişti ve verileri sıfırlayan betikler çalıştırdı. Beget, sanal sunucuların (VPS) ikili (binary) yedeklerinin tamamen kaybolduğunu söyledi. 6 Kasım'da ise VPS, S3 ve Kubernetes hizmetlerini kapsayan bulut altyapısının yok edildiğini ve sıfırdan kurulduğunu duyurdu.

Şirketin dosya düzeyinde yedekleri var. Ancak Beget'in kendi tahminine göre bu yedekler VPS müşterilerinin yalnızca yaklaşık yarısını kapsıyor. Paylaşımlı hosting tarafında 6 Kasım itibarıyla sunucuların yüzde 60'ından fazlası yeniden çalışıyordu. Tam kurtarma için bir tarih verilmedi, saldırganın içeri nasıl girdiği de açıklanmadı.

ESTT: Sanallaştırma kümelerinde fidye yazılımı

Birkaç gün sonra, 8 Kasım'da sıra ESTT'ye geldi. Şirketin açıklamasına göre ilk bulgular dosya şifreleyen bir fidye yazılımına işaret ediyor. Saldırı sanallaştırma kümelerini ve bulut yönetim sistemlerini vurdu. Dikkat çekici ayrıntı şu: Müşterilere ait fiziksel dedicated sunucular etkilenmedi. ESTT ertesi gün sanal sunucuların yaklaşık yüzde 90'ını geri getirdiğini açıkladı. Buna karşın müşteri paneli ve bakiye yükleme hâlâ çalışmıyordu. Şirket müşteri verisinin sızdırıldığına dair bir iz bulmadığını söylüyor.

Bu olaylar neden önemli?

Bulut ve hosting kesintilerini genellikle donanım arızası, elektrik ya da veri merkezi yangını gibi fiziksel risklerle düşünürüz. Felaket kurtarma planları da buna göre yazılır: başka bir zone, başka bir bölge, başka bir veri merkezi. Bu iki olay farklı bir senaryoyu gösteriyor. Sorun tek bir veri merkezinde değil, bütün veri merkezlerini yöneten yazılımdaydı.

Kontrol düzlemi ele geçirildiğinde bölge ayrımının pek bir anlamı kalmaz. Aynı API ve aynı yönetim araçları bütün kaynaklara erişebiliyorsa, saldırgan da hepsine erişebilir. Sağlayıcının sunduğu otomatik snapshot veya yedekleme özellikleri de genellikle aynı yönetim katmanında çalışır. Beget örneğinde VPS yedeklerinin de silinen veriler arasında olması tam olarak bunu gösteriyor.

ESTT tarafındaki ayrıntı da öğretici. Sanallaştırma katmanı vurulduğunda fiziksel sunucular ayakta kaldı. Bu, dedicated sunucunun her durumda daha güvenli olduğu anlamına gelmiyor. Ama paylaşılan yönetim katmanına ne kadar bağımlıysanız, o katmandaki bir sorundan o kadar çok etkileneceğinizi hatırlatıyor.

Pratikte ne anlama geliyor?

Buradan çıkan ders sağlayıcı değiştirmek değil. Herhangi bir sağlayıcının, büyük ya da küçük, bir gün benzer bir olay yaşayabileceğini varsayarak tasarım yapmak. Bunun için birkaç somut adım var.

1. En az bir yedek kopya başka bir sağlayıcıda olsun

Aynı sağlayıcının farklı bölgesi, sağlayıcının kendi hatalarına karşı korur. Sağlayıcının yönetim sisteminin ele geçirilmesine karşı korumaz. Kritik verilerinizin en az bir kopyası farklı bir firmada, farklı kimlik bilgileriyle erişilen bir yerde durmalı. Klasik 3-2-1 kuralının "bir kopya başka yerde" maddesi, bugün "bir kopya başka bir sağlayıcıda" diye okunmalı.

2. Yedekler silinemez olsun

Yedek hedefinizde nesne kilitleme (object lock / WORM) ya da append-only mod kullanın. Böylece üretim ortamındaki bir anahtar sızsa bile saldırgan geçmiş yedekleri silemez ya da üzerine yazamaz. Restic veya Borg gibi araçlarda yedek alan sunucunun yalnızca yazma yetkisi olsun, silme ve budama (prune) işi ayrı ve yetkili bir yerden yapılsın.

# Örnek: Restic deposunu başka bir sağlayıcıdaki S3 uyumlu bucket'ta tutmak
export RESTIC_REPOSITORY=s3:https://baska-saglayici.example.com/yedek-bucket
restic backup /var/lib/postgresql-dump /etc --tag gunluk
# Bucket tarafında object lock açık, bu sunucunun anahtarında silme yetkisi yok

3. Sağlayıcı snapshot'ını yedek saymayın

VPS panelindeki tek tıkla snapshot pratik bir geri dönüş aracıdır. Yanlış bir güncellemeden sonra işe yarar. Ama sağlayıcının kendisi sorun yaşadığında yedek değildir. Snapshot ile uygulama düzeyinde yedeği (veritabanı dump'ı, dosya yedeği) ayrı tutun.

4. Altyapıyı yeniden kurabilir olun

Beget'in de yaptığı gibi bazen her şeyi sıfırdan kurmak gerekir. Sunucu yapılandırmanız Terraform/OpenTofu, Ansible ya da en azından düzgün belgelenmiş betiklerle kodlanmışsa, başka bir sağlayıcıda ortamı ayağa kaldırmak saatler sürer, haftalar değil. Elle kurulmuş ve kimsenin tam hatırlamadığı bir sunucu ise en kırılgan halkadır.

5. DNS ve sırlar aynı sepette olmasın

Beget'in ilk önceliği DNS (NS) sunucularını geri getirmekti. Alan adınızın DNS'i, sitenizi barındıran firmadaysa, o firma düştüğünde trafiği başka yere yönlendirme imkânınız da gider. Ayrıca Beget müşterilerine sunucularda tutulan parola ve erişim anahtarlarını değiştirmelerini önerdi. Sunucu üzerinde düz metin halinde duran API anahtarlarının bir envanterini tutmak, böyle bir günde neyi döndüreceğinizi bilmenizi sağlar.

6. Geri yüklemeyi gerçekten deneyin

Test edilmemiş yedek bir umuttur. Üç ayda bir, yedeklerden başka bir sağlayıcıda boş bir ortam kurup uygulamanın ayağa kalkıp kalkmadığını kontrol etmek, bu yazıdaki en sıkıcı ama en değerli maddedir.

Son söz

Bu iki olayda saldırganın kim olduğu ve içeri nasıl girdiği henüz bilinmiyor. Bu yüzden teknik bir kök neden analizi yapmak için erken. Ama müşteri tarafından görülen tablo yeterince net: Sağlayıcının yönetim katmanı tek bir hata noktası. Büyük bulut sağlayıcıları bu katmanı korumak için ciddi yatırım yapıyor, küçük firmaların imkânları daha sınırlı olabiliyor. Hangisini kullanırsanız kullanın, bu hafta kendinize şu soruyu sormaya değer: Sağlayıcım yarın sabah her şeyi kaybetse, verilerimin hangi kopyası onun erişemeyeceği bir yerde duruyor?