Sunucu güvenliği, tek bir güvenlik yazılımı kurmaktan çok, internete açık servisleri azaltma, yönetici erişimini sınırlandırma, sistemi güncel tutma ve olayları izlenebilir hâle getirme sürecidir. Önce mevcut erişimleri ve çalışan servisleri çıkarın; ardından kritik yönetim yollarını koruyup gereksiz yüzeyi kapatın. Böylece sorun çıktığında nedeni daha dar bir alanda arayabilirsiniz.
İlk adım, sunucunun ne yaptığını ve dışarıya hangi kapıları açtığını yazılı hâle getirmektir. Web sunucusu, veritabanı, e-posta, uzak yönetim veya dosya aktarımı gibi her işlev farklı bir servis ve port anlamına gelebilir. Kullanılmayan bir servisi yalnızca güvenlik duvarında engellemek yerine mümkünse durdurmak ve başlangıçta otomatik açılmasını kaldırmak, saldırı yüzeyini doğrudan küçültür.
Bu envanter sırasında sağlayıcının ağ güvenlik duvarı ile işletim sistemi içindeki güvenlik duvarını birbirinin yerine koymayın. İlk katman sunucuya ulaşmadan önce trafiği filtreleyebilir; ikinci katman ise makine üzerindeki servisleri korur. Hangi katmanın hangi kuralı uyguladığı sağlayıcıya ve altyapıya göre değişebilir. Bir portun dışarıdan kapalı görünmesi, uygulamanın yerel olarak güvenli yapılandırıldığı anlamına gelmez.
Uzaktan yönetim hesabı, sunucunun en kritik giriş noktasıdır. Paylaşılan parolalar yerine kişiye özel hesaplar, güçlü kimlik doğrulama ve mümkünse anahtar tabanlı erişim tercih edilmelidir. Doğrudan yönetici hesabıyla giriş yapmak yerine sınırlı yetkili bir kullanıcı üzerinden gerektiğinde yükseltilmiş yetki kullanmak, bir hesabın ele geçirilmesi durumunda ilk etki alanını azaltır. Kullanılmayan hesapların ve eski erişim anahtarlarının kaldırılması da aynı ölçüde önemlidir.
Karar, yönetim servisinin gözlemlenebilirliğine göre verilmelidir: Uzak yönetim portu tüm internete açıksa önce erişimi bilinen yönetim ağlarıyla sınırlandırın; böyle bir sabit ağ yoksa anahtar tabanlı girişe ek olarak çok faktörlü doğrulama veya VPN gibi desteklenen bir katmanı değerlendirin. Erişim kuralını değiştirirken mevcut oturumu kapatmadan yeni yöntemi ayrı bir oturumda test edin; aksi hâlde hatalı bir kural dışarıda kalmanıza neden olabilir.
İşletim sistemi, web sunucusu, çalışma zamanı ve uygulama bağımlılıkları ayrı güncelleme kaynaklarına sahip olabilir. Sadece işletim sistemini güncellemek, uygulamanın eski bir bileşeninden doğan riski ortadan kaldırmaz. Güncelleme öncesinde çalışan hizmetleri, yapılandırma dosyalarını ve geri dönüş planını belirleyin; özellikle üretim sistemlerinde değişikliği önce benzer bir ortamda doğrulamak kesinti riskini azaltır.
Bir servis güncellemeden sonra çalışmıyorsa tüm güvenlik ayarlarını gevşetmek yerine belirtileri ayırın. Yalnızca dış bağlantı başarısızsa güvenlik duvarı ve dinleme adresini; servis başlıyor fakat uygulama hata veriyorsa yapılandırma uyumluluğunu ve ilgili günlükleri inceleyin. Kuralı geçici olarak genişletmeniz gerekiyorsa kapsamı ve süreyi açıkça belirleyin, doğrulama biter bitmez eski sınıra dönün. “Çalıştı” sonucu tek başına güvenli yapılandırma kanıtı değildir.
Güvenlik olaylarında yalnızca saldırı olup olmadığını bilmek değil, hangi hesabın ne zaman ve hangi servise eriştiğini görebilmek gerekir. Başarısız yönetim girişimleri, yetki değişiklikleri, servis yeniden başlatmaları ve uygulamanın kritik hataları düzenli izlenmelidir. Günlüklerin aynı sunucuda sınırsız büyümesine izin vermeyin; saklama süresi, erişim yetkisi ve mümkünse ayrı bir sisteme aktarım planlanmalıdır.
Örneğin, varsayımsal olarak bir sunucuda kısa süre içinde çok sayıda başarısız yönetim girişi görüyorsunuz, fakat web uygulamasının yanıtları normal. Bu gözlem önce yönetim erişiminin kaynaklarını, kimlik doğrulama yöntemini ve ilgili hesapların durumunu incelemeyi gerektirir; web uygulamasını kapatmak doğrudan gerekçeli bir sonraki adım değildir. Buna karşılık aynı zaman aralığında yeni bir yönetici hesabı oluşturulduysa, hesabı hemen devre dışı bırakıp erişim kayıtlarını korumak ve yetkili değişiklikleri doğrulamak daha güvenli bir tepkidir. Kayıtların eksik olması durumunda ise olayın kapsamı hakkında kesin sonuç vermek yerine izleme ve saklama yapılandırmasını düzeltin.
Yedek, yalnızca dosyaların başka bir konuma kopyalanması değildir; geri yüklenebildiği ve saldırıya uğrayan sunucudan bağımsız tutulduğu doğrulanmalıdır. Veritabanı için tutarlı yedek, uygulama dosyaları için sürümlü kopya ve yapılandırmalar için güvenli saklama yöntemi gerekebilir. Yedek hesabının üretim sunucusuyla aynı yetkilere sahip olması, sunucu ele geçirildiğinde yedeklerin de etkilenmesine yol açabilir.
İş yükünüz kritik veritabanı ve sık değişen dosyalardan oluşuyorsa, geri yükleme süresini ve veri kaybı toleransını belirleyip buna göre yedekleme sıklığı seçin; yalnızca nadiren değişen statik içerik barındırıyorsanız daha basit bir sürümlendirme düzeni yeterli olabilir. Yedekleri geri yükleme testi yapılmıyorsa başarılı görünen görev kayıtları gerçek kurtarma kabiliyetini kanıtlamaz. Altyapı seçerken erişim ve ağ kurallarının nasıl yönetildiğini ayrıca incelemek için sunucu kiralama çözümleri sayfasını değerlendirebilirsiniz; bağlantıdaki bilgiler, sizin yapılandırmanız için teknik doğrulama yerine geçmez.
Güvenli bir başlangıç için önce envanteri çıkarın, gereksiz servisleri kapatın ve yönetim erişimini sınırlandırın. Sonra güncelleme ve yedekleme düzenini kurup günlüklerin gerçekten toplandığını doğrulayın. Bir erişim kuralı değişikliğinden sonra beklenen bağlantının çalışmadığını görürseniz kuralı rastgele genişletmek yerine kaynak adres, hedef port ve uygulamanın dinlediği arayüzü ayrı ayrı karşılaştırın. Bulgular tutarsızsa değişikliği geri alıp kayıtları koruyun; sonraki güvenli adım, etkilenmiş hesabı veya servisi izole ederek kontrollü inceleme yapmaktır.
İlk pratik sonraki adım, sunucudaki tüm dışa açık servisleri, bunlara erişebilen kaynakları ve sorumlu hesapları tek sayfalık bir listeye dökmektir. Bu liste olmadan yapılan güvenlik değişiklikleri, bir açığı kapatırken gerekli bir yönetim yolunu fark edilmeden bozabilir.
Copyright © 2026 Tüm Hakları Saklıdır.
Türkiye (Türkçe)
Worldwide (English)