Hosting güvenliği: Sağlayıcının sorumluluğu nerede başlar, biter?

Hosting güvenliği, sadece "antivirüs kur" gibi tek adımlık bir konu değildir. Sunucu katmanında veri merkezi politikaları, işletim sistemi katmanında erişim ve güncelleme süreçleri, uygulama katmanında ise kullanıcı yapılandırmaları belirleyicidir. Bu yazıda hosting sağlayıcısının sorumluluğunun nerede başladığını ve nerede bittiğini, ayrıca bu sınırları SLA, kontrol paneli ve teknik gerçeklerle nasıl test edeceğinizi göreceksiniz.

Aşağıdaki çerçeve; paylaşımlı hosting, VPS/VDS (Virtual Private Server) ve dedicated sunucu için uygulanabilir. Hedef; belirsiz “hosting önemlidir” söylemi yerine, karar verirken elinizde somut bir kontrol listesi olsun.

1) Güvenlik sorumluluğu “katman” meselesidir

Hosting sağlayıcısı ile müşteri arasındaki sorumluluk ayrımı genellikle şu katmanlara ayrılır:

• Veri merkezi ve ağ (data center + network): Fiziksel güvenlik, upstream bağlantılar, DDoS scrubbing kapasitesi, yedekli enerji/soğutma.
• Hiper yönetim ve sanallaştırma altyapısı (hypervisor / virtualization layer): VM izolasyonu, temel erişim kontrolü, altyapı IDS/IPS gibi sistemlerin işletimi.
• İşletim sistemi ve barındırma ortamı (OS + platform): Güncelleme sorumluluğu, çekirdek (kernel) patch’leri, servis hardening.
• Hesap ve uygulama (account + application): Kullanıcıların kontrol panelinde yaptığı ayarlar, uygulama güncellemeleri, parolalar, anahtarlar, web uygulaması yapılandırmaları.
• Veri ve yedek (data + backup): Yedeklerin üretimi, saklama süresi, geri dönüş (restore) mekanizması, şifreleme (encryption) ve erişim.

Önemli nokta: Sağlayıcı genellikle veri merkezi ve platform katmanını; müşteri ise hesap/uygulama katmanını yönetir. Ancak VPS/VDS gibi kontrolün arttığı planlarda OS güncellemeleri ve hardening sorumluluğu daha çok müşteriye kayar.

Paylaşımlı hostingte sorumluluk nereye kayar?

Paylaşımlı hostingde platform genellikle daha “managed” olduğu için OS düzeyinde bazı güvenlik güncellemeleri sağlayıcı tarafından yapılır. Buna rağmen sitenizin içeriği (WordPress eklentileri, tema kaynakları, admin şifreleri, form güvenliği) sizde kalır.

VPS/VDS ve dedicatedte sınır nerede çizilir?

VPS/VDS/dedicatedte sağlayıcı çoğunlukla sunucunun temel erişimini, sanallaştırma katmanını veya bare-metal güvenliğini üstlenir. Fakat siz; OS düzeyi güncelleme, kullanıcı/SSH anahtarları, firewall kuralları, web server ayarları (Nginx/Apache), uygulama güncellemeleri gibi konulardan sorumlu olursunuz.

2) “Yaptığı şeyleri” değil “kanıtlayabildiği şeyleri” sorun

Güvenlik sorumluluğu konusu, çoğu zaman pazarlama metniyle değil, SLA ve operasyonel kanıtlarla anlaşılır. Net sorular şunlardır:

• DDoS koruması: Trafik sınırlama mı var, scrubbing mi var? Minimum hangi bant genişliği senaryoları hedefleniyor?
• Sızma/olay süreci: Olay müdahalesi (incident response) kim tarafından yönetiliyor? SLA’da ortalama tespit/iyileşme süresi var mı?
• Erişim kontrolü: Sağlayıcı destek personeli hangi yetkilerle sunucuya erişiyor? “Kayıtlı erişim” (session logging) var mı?
• Güncelleme sorumluluğu: Kernel ve kritik güvenlik yamaları kim tarafından uygulanıyor?
• Yedekleme sorumluluğu: Yedekler otomatik mi, şifreli mi, şifrenin anahtarı kimde, geri dönüş süresi (RTO) nedir?

Bu soruların cevabı “biz güvenliyiz” değil; ölçülebilir süreç olmalı.

3) Paylaşımlı hosting: Sağlayıcının ana sorumluluk alanları

Paylaşımlı planda sağlayıcının güvenlik sorumluluğu genellikle şu başlıklarda netleşir:

• Veri merkezi + ağ korumaları (DDoS planları, upstream kapasite yönetimi)
• Barındırma altyapısının güvenliği (sunucu işletim sistemi, sanal ortam izolasyonu)
• Barındırma paneli ve sistem servislerinin temel hardening’leri
• Sitenin çalışması için gerekli çekirdek servisler (bazı planlarda otomatik patch)

Buna karşılık müşterinin sorumluluğu:

• Panel şifresi, FTP/SFTP kullanıcıları, e-posta hesapları
• Uygulama güncellemeleri (ör. WordPress çekirdek + eklenti + tema)
• Web uygulaması yapılandırması (form doğrulama, captcha, rate limit)
• Güvenli parola/anahtar yönetimi

Kontrol listesi (paylaşımlı)

• Kontrol panelinde WAF / bot koruma / rate limit seçenekleri var mı?
• Sağlayıcının yaptığı güvenlik yamaları için bir “patch schedule” (periyot) bilgisi mevcut mu?
• Yedekleme: Günlük/haftalık mı, kaç gün saklanıyor, restore süreci nasıl işliyor?
• SSL yönetimi: Otomatik sertifika yenileme var mı?

4) VPS/VDS: Sınır, “OS ve uygulama”ya doğru kayar

VPS/VDS planlarında sorumluluğun yönü daha net olur: Sizde sunucu ortamına erişim (SSH) arttıkça güvenlik sorumluluğu da artar.

VPS/VDS için sağlayıcının sorumlu olduğu minimumlar

• Sanallaştırma altyapısının ve temel platformun güvenliği
• Sunucuya fiziksel/virtual erişim kontrolleri
• Ağ izolasyonu ve müşteriler arası kapsayıcı güvenlik
• Sağlayıcının yükümlü olduğu durumlarda çekirdek seviyesinde kritik patch (planınıza bağlı)

VPS/VDS için sizin sorumlu olduğunuz başlıklar

• İşletim sistemi güncellemeleri (OS patch)
• Firewall (UFW/iptables/nftables) ve port politikası
• SSH güvenliği: parola girişini kapatma, anahtar kullanma, fail2ban/benzeri yaklaşım
• Web server hardening: gereksiz modülleri kapatma, security headers
• Dosya yetkileri, servis yetkileri (least privilege)
• Uygulama güncellemeleri (WordPress, panel scriptleri, bağımlılıklar)
• Sunucu loglarının tutulması ve incelenmesi (en azından erişim logları)

Net test: “Güncelleme kimin işi?”

VPS/VDS seçmeden önce şu şekilde ilerleyin: - Plan açıklamasında “managed” OS patch sunuluyor mu? - Destek kanallarında “çekirdek güvenlik yamaları tarafımızca uygulanır” cümlesi geçiyor mu? - Geçmişte kritik CVE patch’leri için sağlanan tarih/duyuru var mı?

Bu üçünden hiçbiri yoksa OS güvenliğini tamamen sizin yöneteceğinizi varsayın.

5) Dedicated sunucu: Teknik kontrol yüksek, risk de yüksektir

Dedicated sunucuda donanıma erişim düzeyi yüksek olduğu için güvenlik sorumluluğu daha geniştir.

• Sağlayıcı: veri merkezi ağ güvenliği, fiziksel güvenlik, bare-metal izole yönetim altyapısı
• Siz: OS güncellemeleri, servis yönetimi, firewall, IDS/IPS entegrasyonları, uygulama hardening

Dedicated’te “tek başına güvenli” kurulum beklentisi doğru değildir. Sunucu tek kullanıcı için olsa bile saldırı yüzeyi aynı kalır: açık portlar, zayıf parola politikası, güncel olmayan uygulamalar, yanlış yapılandırılmış panel erişimleri.

6) Yedekleme (backup) ve restore: Güvenlikte en kritik bölge

Birçok ihlalde asıl belirleyici “ne kadar çabuk geri dönülebildiği”dir. Yedekleme güvenliği şu sorularla ölçülür:

• Yedekler otomatik mi?
• Yedeklerin saklama süresi kaç gün/kaç sürüm?
• Yedekler şifreli (encrypted) mi?
• Şifreleme anahtarı kimde? (Sağlayıcı mı, siz mi?)
• Restore için RTO (devreye alma süresi) ve RPO (veri kaybı miktarı) hedefi var mı?

Yedekleme senaryoları: Sizi ne kurtarır?

• Dosya bozulması / site defacement: Web klasörünü temiz restore etmek.
• Uygulama ele geçirilmesi: Veritabanı + uygulama dosyaları ile birlikte yeniden konuşlandırma.
• Ransomware etkisi: Yedek erişimi saldırganın erişimindeyse kurtarma zorlaşır.

Bu nedenle yedekleri sadece sunucunun içinde tutmak risklidir. En sağlıklısı; yedeklerin ayrıca dış depoda saklanmasıdır (S3 uyumlu depolama gibi). Net bir hedef: Yedek geri dönüşünü, normalde görmeyeceğiniz kadar sık doğrulayın.

7) SLA ve sözleşmede “güvenlik” maddesi nasıl okunur?

Sözleşmelerde güvenlik bazen “pazarlama dili” gibi yazılır. Siz şu ifadeleri aramalısınız:

• “DDoS koruması mevcuttur” yerine: bant genişliği sınırı, devreye alma prensibi
• “Güvenlik güncellemeleri yapılır” yerine: hangi katman (kernel/OS/app) ve hangi süre (ör. kritik yamalar X gün içinde)
• “Yedekleme yapılır” yerine: frekans, saklama, restore adımları ve maliyet

Aşağıdaki tablo, sorumlulukların pratikte nasıl ayrıştığını özetler:

8) Net öneri: Sunucu tipinize göre “güvenlik sorumluluğu haritası” çıkarın

Karar verirken “sağlayıcı her şeyi yapar” varsayımı hatalıdır. En iyi yaklaşım, kendi güvenlik sorumluluk haritanızı çıkarmaktır.

Paylaşımlı hosting için 7 adım

• Panelde SSL otomasyonu ve güvenlik araçları (WAF/rate limit) var mı doğrulayın.
• Uygulama (WordPress vb.) için otomatik güncelleme stratejisini belirleyin.
• Yönetici parolalarını güçlü yapın, kullanıcı sayısını minimumda tutun.
• Form/endpoint’ler için bot koruması ve captcha politikanızı netleştirin.
• Sağlayıcının yedekleme sıklığını ve restore sürecini yazılı doğrulayın.
• Güvenlik olayında destek yanıt süresini SLA üzerinden kontrol edin.
• Siteler arası etki riskine karşı, aynı sağlayıcıda çok sayıda kritik site biriktirmeyin.

VPS/VDS için 10 adım

• SSH için parola girişini kapatın, yalnızca anahtar kullanın.
• Firewall ile varsayılan tüm portları kapatın, sadece gerekli portları açın.
• Fail2ban veya benzeri saldırı denemesi engelleyicileri kurun.
• OS güncellemelerini düzenli zaman planına bağlayın (kritik yamalar öncelikli).
• Web server güvenlik başlıklarını standardize edin.
• Dosya izinleri ve servis yetkilerini (root kullanımını azaltın) kontrol edin.
• Logları merkezi bir yere aktarın veya düzenli inceleme planlayın.
• Yedeklemeyi iki katmana ayırın: sunucu yedeği + dış depoda kopya.
• Restore testini (ör. haftada bir) gerçek bir dosya/DB geri dönüşü olarak doğrulayın.
• Sağlayıcının sağlayamadığı güvenlik katmanlarını (OS hardening gibi) dokümante edin.

Sonuç: “Sorumluluk sınırı”nı sözleşme + teknik test ile belirleyin

Hosting sağlayıcısının güvenlik sorumluluğu; veri merkezi ve platform katmanında başlar, hesap/uygulama katmanında müşteriyle ayrışır. Paylaşımlı hostingte yönetsel güvenlik daha fazladır; VPS/VDS ve dedicated’te OS hardening, firewall, SSH güvenliği ve uygulama güncellemeleri sizdedir. En doğru aksiyon, satın almadan önce SLA ve yedekleme/restore maddelerini yazılı doğrulamak ve sunucu tipinize göre yukarıdaki güvenlik sorumluluğu haritasını oluşturmaktır.

İsterseniz, elinizdeki plan türünü (paylaşımlı/VPS/VDS/dedicated) ve kullanacağınız uygulamayı (WordPress, Node.js, e-ticaret vb.) yazın; “sağlayıcı sorumluluğu - sizin sorumluluğunuz” şeklinde net bir kontrol listesi çıkarayım.