Hosting Güvenliği: Sağlayıcı sorumluluğu nereye kadar?

Hosting güvenliği konusu “her şeyi sağlayıcı yapar” ya da “tamamen müşterinin işi” gibi tek cümlelik açıklamalara sığmaz. Güvenlik, farklı sorumluluk katmanlarına bölünür: veri merkezi ve ağ altyapısı, hypervisor/host katmanı, işletim sistemi, uygulama ve kimlik yönetimi. Bu yazıda, bir hosting sağlayıcısının güvenlik sorumluluğunun nerede başladığını ve nerede bittiğini pratik bir kontrol listesiyle netleştiriyoruz.

Aşağıdaki çerçeve, VDS/VPS, managed servisler ve paylaşımlı hosting için genel olarak geçerlidir; ancak sağlayıcı sözleşmesi (Service Level Agreement - SLA) ve güvenlik dokümanlarıyla doğrulanmalıdır.

Güvenlik sorumluluğu 5 katmana ayrılır

Genelde bir güvenlik olayında incelenmesi gereken alanlar şunlardır:

1. Veri merkezi ve fiziksel güvenlik
2. Ağ (network) ve saldırı yüzeyi (edge/CDN, DDoS emici, routing)
3. Sanallaştırma/altyapı katmanı (hypervisor, host OS, sanal ağlar)
4. İşletim sistemi ve temel ayarlar (OS hardening, kernel, güncellemeler)
5. Uygulama ve kullanıcı kontrolü (web sunucusu, veritabanı, parolalar, güncellemeler, yedek ve log)

Hosting sağlayıcısının “tamamından” sorumlu olduğu alanlar, genellikle ilk 3 katmandadır. 4 ve 5 katmanlarında sorumluluk, hizmetin türüne (managed mi unmanaged mı) göre değişir.

“Managed” ile “unmanaged” arasındaki kritik fark

• Managed: Sağlayıcı OS güncellemeleri/hardening, güvenlik yamaları veya uygulama katmanında belirli aksiyonları üstlenir.
• Unmanaged: Sağlayıcı yalnızca barındırma/altyapı sağlar; OS ve uygulama güvenliği çoğunlukla müşteridedir.

Bu ayrım, güvenlik sorumluluğunun haritasını doğrudan etkiler. Aynı sunucu türünde bile (ör. VDS) yönetim kapsamı farklı olabilir.

Sağlayıcı hangi güvenlik işlerini üstlenmeli? (1-3. katman)

Aşağıdaki başlıklar, sağlayıcının kontrol etmesi gereken alanlara örnektir. Bu maddeler açıkça belirtilmiyorsa, “güvenlik sorumluluğu” tartışmalı kalır.

Veri merkezi (fiziksel güvenlik)

Sağlayıcı şunları yapabilir: - Sunucu/ekipmana erişim kontrolleri (kartlı giriş, kayıt altına alma) - Yangın/elektrik kesintisi planları - Donanım envanteri ve yetkisiz müdahale tespiti

Müşteri tarafı bu katmana teknik olarak müdahale edemez. Bu yüzden sorumluluk esasen sağlayıcıdadır.

Ağ güvenliği (network) ve DDoS

Sağlayıcıdan beklenen net şeyler: - DDoS koruması (özellikle volumetric ve layer 7 senaryolarına karşı) - BGP/route tarafında yönlendirme hijyeni - Port/servis kısıtları (ör. kontrol panel erişimlerinin güvenli tutulması) - Firewall kuralları ve anti-spoof önlemleri (yapılarına göre)

Burada “DDoS koruması var” demek yetmez. Net ifade şudur: Koruma hangi katmanda? Hangi trafik tipinde? Hangi limit/yanıt süresiyle?

Sanallaştırma/altyapı katmanı

VPS/VDS türlerinde, sağlayıcı şu riskleri azaltmalıdır: - Hypervisor güvenliği ve düzenli güncelleme (uygulanabilir olduğu ölçüde) - Aynı host üzerindeki diğer sanal makinelerden izolasyonun (isolation) sağlanması - Tuzak/izinsiz erişim tespit mekanizmaları

Paylaşımlı hostingte izolasyon daha kritiktir. Ancak isolation’in derecesi sağlayıcıdan sağlayıcıya değişir; bu nedenle “benim güvenliğim” beklentisi sözleşmeye göre şekillenmelidir.

İşletim sistemi güvenliği: Sorun çoğunlukla burada başlar (4. katman)

Dördüncü katman OS’tir. Linux’ta güvenlik, sadece “firewall açmak” değildir; çekirdek (kernel) yamaları, SSH yapılandırması, kullanıcı yetkileri ve temel hardening de dahildir.

Paylaşımlı hostingte (shared) OS sorumluluğu

Paylaşımlı hostingde genellikle sağlayıcı OS güncellemelerini ve temel hardening’i üstlenir. Müşteri tarafı: - Uygulama güncellemeleri - E-posta/FTP/Panel parolaları - Erişim yetkileri - Uygulama eklentileri konularına odaklanır.

VDS/VPS’te OS sorumluluğu: managed/unmanaged belirleyici

VDS/VPS’te OS sorumluluğu şöyle ayrılır: - Managed VDS/VPS: OS yamaları, temel hardening ve izleme (monitoring) sağlayıcı kapsamında olabilir. - Unmanaged VDS/VPS: OS güncelleme ve güvenlik ayarları doğrudan müşterinindir.

Net bir karar için sağlayıcıdan istemeniz gereken bilgi seti: - “Kernel/security update’leri kim yapıyor?” - “Reboot planı (zorunlu reboot) ne zaman bildiriliyor?” - “OS hardening baseline’imiz var mı? (ör. SSH root login kapalı mı?)” - “Güncelleme SLA’sı var mı? (yamalar kaç gün içinde uygulanır?)”

Uygulama güvenliği ve kimlik yönetimi: 5. katman tamamen kritik (çoğunlukla sizde)

Beşinci katman uygulamadır. Burada bir saldırı zincirinin halkaları sıkça şunlardır: - Zayıf şifreler (veya eski şifreler) - Yönetici paneli (ör. WordPress admin, control panel) erişim açıkları - Güncel olmayan eklenti/tema - Veritabanı yetki aşırılığı (least privilege uygulanmaması) - Yetkisiz dosya yükleme (upload) ve zafiyetlerin sömürülmesi

Sağlayıcı, uygulamaya dair tüm detaylara müdahale edemez. Güvenlik sonucu doğrudan doğruya sizin konfigürasyonunuza bağlıdır.

Hosting sağlayıcısı genelde nerede durur?

Genel beklenti şöyledir: - Web uygulamanızın kodunu siz yazıyorsanız, zafiyet sizin sorumluluğunuzdur. - Uygulama güncellemesi ve sürüm standardı sizin sorumluluğunuzdur. - Veritabanı şema tasarımı ve kullanıcı yetkileri sizin sorumluluğunuzdur.

Ancak sağlayıcı, bazı managed paketlerde uygulama katmanına dokunabilir. Örneğin: - WordPress’in güncelleme/patch politikaları - CMS için güvenlik taraması - WAF kurallarının sağlanması

Bu yine sözleşme ve teknik dokümana bağlıdır.

Başka örneklerle “kim neyi yapar?” ayrımı

Aşağıdaki senaryolar, sorumluluk sınırını anlamak için pratik bir yol sağlar.

Senaryo 1: DDoS saldırı nedeniyle site erişilemez oldu

• Beklenti: Ağ katmanı koruması sağlayıcıdadır.
• Sizden istenen: Web uygulamanızın ölçeklenebilir olması, servis tasarımının DoS’a dayanıklı olması ve CDN/WAF politikalarına uyum.

Net soru: Sağlayıcı layer 7’de de koruma sağlıyor mu, yoksa yalnızca volumetric mi?

Senaryo 2: Sunucuda izinsiz SSH denemeleri var (brute force)

• Beklenti: Sağlayıcı temel ağ/erişim güvenliğinde yardımcı olur (ör. kaba kuvvete karşı baseline).
• Sizden beklenen: SSH kimlik doğrulama ayarları, rate limiting, parola politikaları, mümkünse anahtar (SSH key) ve 2FA.

Burada sağlayıcının “port açık” riskini tek başına çözmesi beklenmez; OS seviyesinde doğru yapılandırma gerekir.

Senaryo 3: Web uygulaması hacklendi ve dosyalar değişti

• Beklenti: Uygulama zafiyeti (zayıf eklenti, yanlış izinler, güncel olmayan sürüm) genelde sizin sorumluluğunuzdur.
• Sağlayıcının rolü: WAF/filtreler, logların erişilebilirliği, kriz anında destek prosedürleri.

Senaryo 4: Veritabanı sızdırıldı

• Beklenti: Veritabanı erişim yetkileri, parolalar, ağ kısıtları (DB port erişim kuralı) sizin sorumluluğunuzdur.
• Sağlayıcıdan beklenti: Yönetim paneli ve altyapı güvenliği; yanlış yapılandırmayı engelleyecek kontroller (kapsamına göre).

Güvenlik sorumluluğu için sağlayıcıdan talep edilecek net kanıtlar

“Güvenli hosting” iddiasını, doğrulanabilir maddelerle konuşun.

Talep listesi (kopyala-kullan)

• DDoS koruması kapsamı: hangi katman, hangi trafik türleri, limitler.
• Firewall/WAF: WAF var mı, yönetimi kimde, kural seti nasıl.
• OS güncelleme politikası: managed ise yamalar ne zaman, unmanaged ise müşterinin ne yapacağı.
• Log erişimi: sistem/ağ loglarına erişim var mı, olay kaydı (audit) sağlanıyor mu.
• Yedekleme (backup) yaklaşımı: yedeklerin saklama süresi, şifreleme, geri dönüş süresi (RTO) ve geri dönüş garantisi (Restore).
• İzolasyon: VPS/VDS multi-tenant izolasyonu için temel güvenlik yaklaşımı.
• SLA ve güvenlik SLA’sı: acil güvenlik olaylarında destek yanıt süresi.

“Kapsam bende” nasıl anlaşılır? Hızlı kontrol matrisi

Aşağıdaki matris, hizmet türünüze göre kontrol alanlarınızı görmenizi sağlar.

Kötü sürprizleri azaltan 6 somut aksiyon

Sorumluluk sınırı net olsa bile, güvenlikte en çok zaman kazandıran şey hazırlıktır.

1. Güvenlik baseline dokümanı isteyin: Sağlayıcının sunduğu default firewall, WAF ve erişim politikalarını yazılı alın.
2. Managed’de bile restore testi yapın: Yedek var demek yetmez; geri dönüş süresi ve dosya tutarlılığı test edilmelidir.
3. SSH erişimini anahtara bağlayın: Parola doğrulaması yerine SSH key kullanın; root login kapalı olsun.
4. Yetkileri daraltın (least privilege): Uygulama kullanıcıları sadece ihtiyaç duyduğu yetkileri alsın.
5. Güncelleme takvimi oluşturun: OS, web sunucusu, PHP/Node/Python bileşenleri ve eklentiler için net tarih/hatırlatıcı.
6. Logları olay öncesi tutarlı tutun: Panik anında log yoksa müdahale zorlaşır. Web sunucusu, uygulama ve kimlik olayları kaydedilmeli.

Sonuç: Aksiyonu sağlayıcıdan başlatın, uygulamayı siz bitirin

Hosting sağlayıcısının güvenlik sorumluluğu, fiziksel ve altyapısal katmanlarda belirgin şekilde başlar; ancak OS hardening ve uygulama güvenliği büyük oranda müşteriye devredilir. En doğru yaklaşım, “kim neyi yapıyor” sorusunu sözleşme ve dokümantasyonla netleştirip sonra kendi tarafınızda erişim, güncelleme, yetki ve yedek/restore rutinlerini standarda bağlamaktır. Bugün seçim yapacağınız sağlayıcı için önce managed kapsamını yazılı doğrulayın, ardından kendi kontrol listenizdeki (SSH/anahtar, least privilege, güncelleme takvimi ve restore testi) maddeleri kurun.