Kurumsal Site Hosting: Güvenlik Kriterleri ve Net Kontrol Listesi

Kurumsal bir web sitesi, sadece içerik yayınlamak için değil; müşteri verisi, sözleşme süreçleri, kullanıcı kimlik doğrulaması ve ödeme ön koşulları gibi kritik akışları taşır. Bu yüzden güvenlik “tek bir özellik” değil; sunucu mimarisi, erişim politikaları, yama süreçleri, izleme ve yedekleme gibi birlikte çalışan bir kontrol setidir. Bu rehberde, hosting sağlayıcısı seçerken kurumsal güvenlik kriterlerini net maddelerle ele alacak; her kriterin hangi ölçekte risk azalttığını, hangi ispatların isteneceğini göstereceksiniz.

1) Güvenli altyapının temeli: izolasyon ve erişim sınırları

Kurumsal sitede en sık hedef alınan nokta, aynı fiziksel ortamı paylaşılan altyapılarda “çevresel” risklerin birikmesidir. Bu nedenle hosting türünüz (paylaşımlı, VPS, VDS, dedicated) kadar, sanallaştırma ve izolasyon yaklaşımı da belirleyicidir.

VDS/VPS mi, dedicated mı?

Aşağıdaki tablo “güvenlik etkisi” açısından pratik bir karar çerçevesi sunar:

Yönetim erişimi: yalnızca “kimlik doğrulama” yetmez

Sağlayıcıdan şu gereksinimler net şekilde istenmelidir: - Admin arayüzlerine erişim için çok faktörlü kimlik doğrulama (MFA) zorunluluğu - Sunucu/VM yönetiminde şifre tabanlı erişim yerine SSH anahtarları (key-based) ve devre dışı bırakılabilen parola oturumu - İdari panel ve API’lerde IP allowlist veya VPN ile sınırlandırma

Bu noktada kritik olan “var/yok” değil; sağlayıcının bunu hangi kanalla uyguladığıdır. Örneğin SSH için "root" kullanımı devre dışı mı, kullanıcı bazlı erişim mi mevcut? Bu soruların yanıtı, incident anında hız ve kapsam kontrolü sağlar.

2) Yama (patch) ve güvenlik güncellemeleri: SLA görmek gerekir

Kurumsal hostingde en büyük fark, zafiyet çıktığında güncelleme süreçlerinin hızıdır. Burada sağlayıcının “güncelliyoruz” demesi yetmez; SLA (Service Level Agreement) ve sürüm politikası istenmelidir.

Beklenen net içerikler

Sağlayıcıdan yazılı olarak şu başlıklar istenir: - İşletim sistemi (OS) için güvenlik yamaları: kritik zafiyetlerde kaç saat içinde güncelleme? - Web sunucusu bileşenleri: Nginx/Apache sürüm politikası - Kernel ve temel paketler: otomatik güncelleme var mı, yoksa kontrollü güncelleme mi? - Yüklenmiş bileşenler (PHP, Node, Java) için bakım yaklaşımı

Sağlayıcının sorumluluk sınırı net mi?

Bazı firmalar yalnızca altyapıyı günceller, uygulama katmanını sizin sorumluluğunuza bırakır. Bu durum kurumsal risk planlamasını değiştirir. Bu yüzden “hangi katmanı kim yönetiyor” sorusu mutlaka cevaplanmalıdır.

3) Uygulama katmanı savunması: WAF, bot kontrol ve sanal yamalar

Kurumsal sitelerde saldırıların önemli kısmı uygulama katmanından gelir: login sayfaları, formlar, CMS eklentileri, API uçları ve dosya yükleme noktaları.

WAF (Web Application Firewall) için aranacak net özellikler

WAF kullanımı “tek başına” güvenlik sağlamaz; yapılandırma ve kapsama bağlıdır. Şunlar doğrulanmalıdır: - OWASP Top 10 kapsamı için kural setleri - False positive yönetimi: kurumsal site için geçerli istisna mantığı - Logların merkezi izlemeye aktarımı (SIEM/SOC entegrasyonu hedefleniyorsa) - Bot koruması: credential stuffing ve scraping’e yönelik tarifler

Sanal yamalar (virtual patching)

Sağlayıcı WAF tarafında “zafiyet CVE’si için geçici koruma” sağlayabiliyorsa bu, patch gecikmelerinde zaman kazandırır. Kurumsal ihtiyaçta özellikle login ve arama gibi yüksek etkileşimli bölümler için anlamlıdır.

4) DDoS ve trafik dayanıklılığı: kapasite değil, net strateji

DDoS konusu sıkça “var/yok” olarak sunulur. Kurumsal güvenlikte ise şunlar netleştirilmelidir: Koruma hangi katmanda çalışır, eşikler nasıl belirlenir, trafik türleri nasıl ayrıştırılır?

Sağlayıcıdan istemeniz gereken 6 net bilgi

1. Katman: L3/L4 mi yoksa L7 (HTTP) mi?
2. Temizleme yaklaşımı: scrubbing center veya bulut filtreleme var mı?
3. Rate-limit ve challenge mekanizmaları (örn. JS challenge)
4. Correlation: WAF ile birlikte çalışıyor mu?
5. “Mitigation süresi” hedefi: saldırı devam ederken performans nasıl korunur?
6. Trafik raporları: saldırı histogramları ve olay dökümü

Bu veriler, incident sonrasında “neden etkilendik/etkilenmedik” sorusuna yanıt vermek için gerekir. Kurumsal ekiplerin risk raporlaması için log kalitesi kritik olur.

5) Yedekleme ve geri dönüş (recovery): test edilmiş plan şart

Birçok kurumsal site yedek alıyor gibi görünür; ancak geri dönüş test edilmediğinde yedek “kağıt üstünde var” olur. Net güvenlik kriteri, yedeğin geri getirilebilir ve doğrulanabilir olmasıdır.

3-2-1 mantığı ve kurumsal uyarlama

Genel yaklaşım şu şekilde okunur: - 3 kopya - 2 farklı ortam - 1 kopya offsite

Kurumsal sitelerde ek olarak: - Yedeklerin şifrelenmiş olması - Erişim kontrolünün yedekleme hesabında MFA ve minimum yetki ile yapılması - Geri dönüş senaryolarında RTO/RPO hedefleri

Net olarak nasıl test edilir?

Aşağıdaki plan, sağlayıcıdan isteyebileceğiniz doğrulama düzenini somutlaştırır: - Haftalık: dosya sistemi + veritabanı geri dönüş simülasyonu (staging ortamına) - Aylık: “tam site restore” (uygulama bağımlılıkları dahil) - Her restore sonrası: uygulama ayağa kalkış kontrolü (health check) ve veri tutarlılığı doğrulaması

NetKıyas açısından bakıldığında, sağlayıcının yedekleme “sıklığı” kadar “restore edilebilirlik” bilgisini açıkça vermesi belirleyicidir.

6) Loglama, izleme ve olay yanıtı: görünürlük olmadan güvenlik olmaz

Kurumsal güvenlik kriterlerinde en sık gözden kaçan parça loglardır. Saldırı sonrası tespit, kök neden analizi ve yasal/denetim ihtiyaçları için log kalitesi belirleyicidir.

Log kapsamı (minimum set)

• Web sunucusu erişim logları (request, status code, user agent)
• Kimlik doğrulama logları (login başarısızları dahil)
• WAF olay logları (engellenen URL/route, rule id)
• Sistem logları (kernel, authentication)
• Değişiklik izleri (config değişiklikleri, deploy zamanları)

Merkezi izleme entegrasyonu

SOC/SIEM kullanımı planlanıyorsa şu soruların net yanıtı gerekir: - Loglar dışa aktarılıyor mu (syslog, API, agent)? - Retention süresi nedir? - İndeksleme ve arama hızı nasıl etkilenir?

Bunlar yoksa bile en azından olay dökümü için “sonra bakılabilir log” elde edilmesi gerekir.

7) Kurumsal güvenlik doğrulamaları: KVKK/GDPR ve erişim kontrolleri

Türkiye’de kurumsal şirketlerin KVKK, Avrupa’da ise GDPR kapsamında değerlendirilmesi gereken veri işleme süreçleri vardır. Hosting tarafı bu uyumda doğrudan etkili olabilir.

Sunucu tarafı net önlemler

• Depolanan verinin şifrelenmesi (en azından at-rest)
• Aktarım şifrelemesi: TLS zorunluluğu, zayıf şifre takımlarının kapatılması
• Anahtar yönetimi: sağlayıcının anahtar saklama yaklaşımı (kendi anahtarın mı, sağlayıcı mı?)
• Personel/teknik ekip erişimi: yetki seviyeleri, MFA, erişim süreleri

Veri konumu ve yasal süreç

Sunucu lokasyonu, veri işleme süreçleri için önem taşır. Kurumsal güvenlik kriterinde şu netleştirilmelidir: - Sunucu konumu/region - Veri taşınmasının (replication veya backup) nasıl yapıldığı

8) Kurumsal site için “seçim filtresi”: kısa karar matrisi

Yukarıdaki başlıkları tek sayfalık bir kontrol mekanizmasına indirmek işinizi hızlandırır. Aşağıdaki matriste, her kriter için “var + nasıl + kanıt” aranır.

Net seçim matrisi (kopyala-kullan)

• İzolasyon: VDS/VPS/dedicated hangi modelle? (kanıt: doküman)
• Yama SLA: Kritik zafiyetlerde kaç saat? (kanıt: SLA metni)
• MFA + erişim: Yönetim erişimi MFA ile zorunlu mu? (kanıt: politika)
• SSH güvenliği: Parola girişi kapatılabiliyor mu? (kanıt: yapılandırma)
• WAF: L7 koruma, kural kapsamı, loglar (kanıt: örnek rapor)
• DDoS: L3/L4 + L7, challenge/rate-limit yaklaşımı (kanıt: mitigation rapor örneği)
• Yedek: Şifreleme + offsite + restore testi (kanıt: RTO/RPO ve test planı)
• Loglama: Retention süresi + merkezi izleme (kanıt: log örneği)
• Uyum: TLS, at-rest şifreleme, veri lokasyonu (kanıt: teknik/uyum dokümanı)

Sonuç: İlk adım teknik talep listesi hazırlamak

Kurumsal site hosting seçiminde “hangi fiyata hangi paket” yerine hangi güvenlik kontrolünün kim tarafından, hangi SLA ile ve nasıl kanıtlanacağı belirleyicidir. Hızlı aksiyon için sağlayıcılara göndereceğiniz bir teknik talep listesi hazırlayın: izolasyon modeli, yama SLA’sı, yönetim erişiminde MFA, WAF/DDoS kapsamı, yedeklerin restore edilebilirliği ve log retention süresi. Bu yanıtlar net geldiğinde, seçenekleri karşılaştırmak hızlı ve objektif hale gelir.