Hosting Güvenliği Sorumluluğu: Sağlayıcı Neye Bakar?

Hosting güvenliğinde en sık hata, sorumluluk sınırını “tek başlıkta” toplamak: “Sağlayıcı halleder.” Oysa gerçek sistem, birden fazla katmana bölünür (altyapı, ağ, işletim sistemi, uygulama). Bu rehberde sağlayıcının sorumluluğunun nerede bittiğini ve sizin hangi kontrol adımlarını almanız gerektiğini somut başlıklarla ayırıyorum. Sonunda, kontrol listesini kullanarak sözleşme ve teknik kurulumlar üzerinden güvenlik kapsamını netleştireceksiniz.

Güvenlik sorumluluğu neden katman katman ayrılır?

Güvenlik ihlalleri çoğu zaman tek bir sebepten değil, farklı katmanlardaki zayıflıklardan doğar.

• Fiziksel ve sanal altyapı: Veri merkezi, hypervisor katmanı, ağ omurgası.
• Servis katmanı: Paylaşımlı hostingde müşteriler arası izolasyon, VDS/VPS’de VM izolasyonu.
• İşletim sistemi ve temel servisler: Güncellemeler, güvenlik yamaları, temel firewall.
• Uygulama katmanı: Web sunucusu (Apache/Nginx), CMS (WordPress vb.), dosya izinleri, kimlik doğrulama.
• Veri ve operasyon: Yedekleme (backup), erişim yetkileri, parolalar, anahtarlar (SSH key), izleme.

Bu ayrım net olmazsa iki uç senaryo yaşanır: 1) Sağlayıcıdan “her şeyi” beklemek (yanlış güven hissi),
2) “Ben zaten yönetiyorum” diyerek kritik altyapı kontrollerini tamamen göz ardı etmek.

Hosting türlerine göre sağlayıcı sorumluluğu nerede biter?

En net çerçeve, seçtiğiniz hosting modeline göre değişir. Aşağıdaki tablo, tipik sorumluluk paylaşımını özetler. (Her sağlayıcının sözleşmesi farklı olabilir; bu nedenle bunu “başlangıç haritası” olarak görün.)

Paylaşımlı hosting: Sağlayıcı daha geniş alana bakar

Paylaşımlı modelde temel izolasyon ve altyapı kontrolleri sağlayıcıdadır. Ancak uygulama güvenliği (WordPress eklenti güncellemeleri, dosya izinleri, kimlik doğrulama) çoğunlukla sizin sorumluluğunuzda kalır. Bu yüzden sağlayıcının sunduğu “otomatik güvenlik” iddialarını, hangi katmanda çalıştığını sorarak doğrulamak gerekir.

VPS/VDS: Sorunların büyük kısmı “işletim sistemi” tarafında başlar

VPS/VDS’de genelde sanal makineye tam erişim vardır. Bu durumda güvenlik yamaları, firewall kuralları, SSH erişim politikası, kullanıcı yetkileri ve yedekleme düzeni doğrudan sizin kontrolünüzdedir. Sağlayıcı tipik olarak hypervisor ve ağ altyapısından sorumludur; ama “VM içinde ne çalıştırdığınız” sizin kapsamınızdadır.

Dedicated: Daha çok kontrol, daha çok sorumluluk

Dedicated sunucuda OS ve uygulama tarafında yine büyük sorumluluk müşteride olur. Sağlayıcı çoğunlukla fiziksel donanım ve veri merkezi katmanını yönetir; ama işletim sistemi güncellemelerini yapıp yapmaması sözleşmeye bağlıdır. Managed dedicated tercih edilirse sorumluluk paylaşımı daha dengeli hale gelir.

Sağlayıcı “güvenlik” deyince somut olarak neyi kastediyor?

Güvenlik vaatleri anlaşılır olmalı; aksi halde pazarlama dili olur. Sağlayıcıdan talep edebileceğiniz teknik kanıtlar şunlardır:

DDoS koruması: Mitigasyon kapasitesi ve kapsam

Sadece “DDoS koruması var” ifadesi yetmez. Şunları net istemelisiniz: - Hangi trafik sınıfları korunuyor (L3/L4 mi L7 mi)? - Filtreleme şeması (scrubbing, rate limit) uygulanıyor mu? - Paket bazında mi, yoksa tüm altyapıda mı? - DDoS olayında hangi aksiyon alınıyor ve ne kadar sürede raporlanıyor?

VPS/VDS tarafında, bazı sağlayıcılar ağ katmanında trafik yönetimi sağlar; ancak web uygulaması katmanındaki hatalı yapılandırma (ör. hatalı rate-limit, açık panel endpoint) yine sizin sorumluluğunuzdadır.

Güvenlik yamaları (patching): Kim OS çekirdeğini ve servisleri güncelliyor?

Bu soru kritik çünkü birçok ihlal, “uzun süre güncellenmemiş” bileşenlerden çıkar. - Sağlayıcı OS çekirdeği ve temel paketleri otomatik güncelliyor mu? - Yoksa sadece “hazır imaj” sunup sonraki sorumluluğu size mi bırakıyor? - Managed hizmette güncelleme pencere politikası nedir (hangi saatlerde, hangi servisler etkilenebilir)?

VPS/VDS’de “kendi güncellemelerinizi yapın” yaklaşımı yaygındır. Bu yaklaşım doğru olabilir; ama yama disiplini kurmadıysanız risk büyür.

Erişim kontrolü: Root/console erişimi nasıl denetleniyor?

Siz yönetmeyi seçseniz bile sağlayıcının acil durumlarda erişimi olabilir. Burada beklenenler: - Root erişimi için olay kaydı (audit log) tutuluyor mu? - Sağlayıcı erişimi için onay/çift kontrol var mı? - Erişim denemeleri nasıl izleniyor?

Bu kontroller yoksa hem güvenlik hem de olay sonrası inceleme zorlaşır.

Loglar ve izleme: Olayı fark etmek kimin görevi?

Güvenlik ihlalleri genellikle aylar sonra anlaşılır. Bunu erken yakalamak için logların doğru yere akması gerekir. - Sağlayıcı sunduğu temel logları nerede saklıyor? - Log saklama süresi kaç gün? - Siz (veya sağlayıcı) SIEM/izleme araçlarına entegrasyon yapabiliyor mu?

VPS/VDS’de sizin sorumluluğunuzun “en kritik” 10 adımı

VPS/VDS kullanıyorsanız, sağlayıcı ağ ve sanal altyapıyı yönetir; siz ise VM içindeki güvenlik düzenini kurarsınız. Aşağıdaki liste pratik olarak “sorumluluk sınırı”nı sahada gösterir.

1) Güvenli erişim: SSH key + parola girişini kapatma

• SSH girişini anahtar (SSH key) ile yapın.
• Parola ile oturum açmayı kapatın.
• Anahtarları rotasyona tabi tutun.

2) Varsayılan portları kör körüne kapatmak yerine servisleri sınırla

• Kullanılmayan servisleri devre dışı bırakın.
• Firewall’da hedef servisleri (örn. 22/80/443) sadece gerekli IP aralıklarına açın.

3) Güvenlik yamalarını düzenli işlet

• Sistem güncellemeleri için takvim oluşturun.
• “Aylık yamalama” yerine kritik zafiyetlerde hızlı döngü (ör. 24-72 saat) hedefleyin.

4) Web uygulaması katmanını sertleştirin

• WordPress’te eklenti ve tema güncellemelerini sürdürün.
• Yönetici paneli için ek katmanlar (IP kısıtlama / 2FA) kullanın.

5) Dosya izinleri ve çalışma dizinlerini kontrol edin

Yanlış izinler uzaktan kod çalıştırma ve veri sızıntısı riskini büyütür. Uygulamanın yazma ihtiyacı olan dizinleri dışındakilere geniş yetki vermeyin.

6) Yedekleme (backup): otomatik + geri dönüş testli

Yedek almanın güvenlik değeri, gerektiğinde geri yükleyebilmenizle ölçülür. - Otomatik yedekleme planı kurun. - Yedekten geri dönüş testi yapın. - Yedekleri aynı sistemde tutmayın (ayrı depolama/ayrı hesap hedefleyin).

7) Şifreleme: disk ve transit

• Veritabanı bağlantıları TLS ile olsun.
• Yüksek hassas veride disk şifreleme (örn. LUKS) kullanın.

8) En az ayrıcalık (least privilege) ile kullanıcı yönetin

• Root kullanımını azaltın.
• Uygulama kullanıcılarını ayrı yaratın.

9) Orta katman güvenliği: WAF ve rate-limit

WAF tek başına tüm sorunları çözmez; ama kaba kuvvet ve bilinen saldırı yüzeylerini azaltır. Uygulama tarafında rate-limit ayarlarıyla birlikte ele alın.

10) İzleme: anomaliyi erken yakalayın

• CPU/RAM/disk alarm eşiklerini belirleyin.
• Kimlik doğrulama başarısız deneme sayıları takip edilmeli.
• Dışarıdan giden olağan dışı trafik sinyallerini izleyin.

Managed (yönetilen) hizmette sorumluluk nasıl değişir?

Managed servislerde sağlayıcı genellikle OS yamaları, temel hardening ve izleme gibi alanları üstlenir. Ancak “yönetiliyor” ifadesi kapsam demek değildir. Şu üç noktayı netleştirin:

1) Managed kapsamı hangi katmana kadar?

• Sadece sunucu (OS) mı?
• Web sunucusu ve temel uygulama katmanı da dahil mi?
• Log izleme ve incident yanıtı var mı?

2) Değişiklik yönetimi (change management)

• Yama/konfigürasyon değişiklikleri önceden bildiriliyor mu?
• Rollback planı var mı?

3) SLA/geri dönüş hedefleri

• Olay anında yanıt süresi nedir?
• Kritik güvenlik vakalarında aksiyon prosedürü var mı?

Bu netleşirse “sorun olursa kim neyi yapar?” sorusu pratik şekilde yanıtlanır.

Sözleşme ve teklif incelemesi: Sağlayıcı sorumluluğunu yazılı hale getirin

Güvenlik sorumluluğunu sadece teknik bilgiyle değil, sözleşme/teklif maddeleriyle de bağlamanız gerekir. Özellikle şunları kontrol edin:

Kontrol listesi (görüşme + SLA)

• Yama sorumluluğu: OS çekirdeği ve servis güncellemeleri kim tarafından ve hangi sıklıkta?
• DDoS kapsamı: L3/L4 mi L7 mi, kapasite ve olay prosedürü nedir?
• Yedek saklama: Otomatik yedek var mı, saklama süresi kaç gün, geri dönüş denemesi var mı?
• Loglar: Hangi loglar tutulur, erişim ve saklama süresi nedir?
• Erişim: Sağlayıcı root erişimi nasıl kayıt altına alınıyor?
• Hardening: Firewall, temel güvenlik ayarları varsayılan olarak uygulanıyor mu?

NetKıyas’ta karar verirken pratik öneri: “Sorumluluk soruları paketi”

Hosting seçerken sadece CPU/RAM ya da disk alanına bakmak güvenlikte yetersiz kalır. Bunun yerine tedarikçiyle aynı sorgu setini kullanın. Önerilen 8 soru: 1) OS çekirdeği yamaları kim yapıyor, frekans nedir? 2) Firewall kuralları varsayılan olarak nasıl? 3) SSH için erişim politikası nedir (parola kapatma destekleniyor mu)? 4) Otomatik yedek var mı, saklama süresi nedir, geri dönüş testi yapılır mı? 5) DDoS koruması hangi katmanda ve kapasitesi nedir? 6) Loglar ne kadar saklanıyor, dışarı aktarma mümkün mü? 7) Olay olduğunda kim ne yapıyor (incident runbook)? 8) Sağlayıcı erişimi için audit log var mı?

Sonuç: Aksiyon planı ile sorumluluk sınırını netleştirin

Hosting sağlayıcısının güvenliği “tamamen onun işi” değildir; ancak sağlayıcının kontrol ettiği katmanlar da küçümsenemez. İlk adım olarak kullandığınız hosting modeline göre sorumluluk tablosunu çıkarın, ardından sağlayıcıdan yama, DDoS, erişim, log ve yedekleme konularında yazılı kapsam isteyin. Sizin tarafınızda ise özellikle SSH erişimi, düzenli güncelleme, firewall, yedekleme ve izleme kurulumlarını hedefleyin. Bu şekilde aynı altyapıda güvenlik belirsizliği azalır ve operasyonel hata riski düşer.