Sunucu Güvenliği için 10 Temel Adım (2026 Kontrol Listesi)

Sunucu güvenliği; tek bir ayar değişikliğiyle biten bir konu değil. Saldırılar genellikle güncel olmayan yazılımlar, zayıf kimlik doğrulama, aşırı açık servisler ve yetersiz gözlemlenebilirlik üzerinden ilerler. Bu rehberde 2026 pratiklerine uygun şekilde, VDS/VPS/dedicated sunuclar için uygulanabilir 10 temel adımı net bir kontrol listesi olarak bulacaksınız. Her adımın hangi riski azalttığını, hangi kontrolün nasıl yapılacağını ve doğru öncelik sırasını okuyacaksınız.

1) Güncelleme ve yamaları “takvimli” hale getirin

Sunucu güvenliğinin en hızlı kazanımı, işletim sistemi ve servis yamalarını geciktirmemektir. Birçok güvenlik olayı; kernel, OpenSSH, web sunucusu (Nginx/Apache), veritabanı ve kontrol panel bileşenlerindeki bilinen açıkların kullanılmasından çıkar.

Ne yapın?

• İşletim sistemi için üreticinin yayın takvimini referans alarak haftalık güncelleme penceresi belirleyin.
• Kritik yamaları (örn. kernel/SSH/SSL ile ilgili) için hedef: 24-72 saat içinde uygulama koyun.
• Kontrol panel kullanıyorsanız (cPanel, Plesk vb.) panel bileşenlerinin güncellemesini ayrıca takip edin.

Kontrol noktası

• Güncelleme sonrası yeniden başlatma gereksinimi varsa “planlı reboot” prosedürü tanımlayın.
• Güncellemeler öncesi uygulama düzeyinde kısa test (staging varsa) yapın.

2) Erişimleri azaltın: servisleri kapatın, portları sıkılaştırın

İlk saldırı yüzeyi genellikle “açık kalan her servis”tir. Kullanmadığınız portlar, saldırgan için ekstra giriş kapısıdır.

Ne yapın?

• Sunucuda çalışan servisleri listeleyin ve gereksiz olanları devre dışı bırakın.
• Firewall (örn. UFW/iptables/nftables) üzerinde sadece gerekli portları açın.
• SSH dışında internetten yönetim arayüzü (panel) erişimi veriyorsanız bunu gözden geçirin.

Uygulanabilir hedefler

• Yönetim trafiği yalnızca belirli IP aralıklarına kısıtlanıyorsa bunu netleştirin.
• Varsayılan yönetim portları yerine “gerekçeli” port düzenlemeleri tek başına güvenlik sağlamaz; asıl güvenlik kısıtlama ve kimlik doğrulamadır.

3) SSH’yi sertleştirin: parola yerine anahtar, root erişimini kaldırın

OpenSSH, yanlış yapılandırmayla doğrudan hedef olur. Güvenlikte en büyük artış; kimlik doğrulamanın parola yerine anahtara alınması ve yetki kontrollerinin sıkılaştırılmasıdır.

Ne yapın?

• SSH için parola oturumlarını kapatın (Public key only).
• Root ile doğrudan SSH girişini devre dışı bırakın; yönetici kullanıcı üzerinden geçin.
• İsterseniz fail2ban tarzı brute-force korumasını etkinleştirin.

Minimum doğrulama

• SSH erişiminizden önce firewall ile sadece gerekli kaynakları açtığınızdan emin olun.
• Şifre sıfırlama gibi acil durumlar için “break-glass” hesabı tanımlayın.

4) Çok faktörlü kimlik doğrulama (MFA) ve tekil yönetici hesabı

Sunucu güvenliğinde “kim” sorusu kritik. Panel, SSH, cloud yönetimi ve uzaktan erişim yetkileri tek kişiye yayılmamalı; iz bırakacak şekilde doğrulanmalıdır.

Ne yapın?

• Kontrol paneli ve cloud/konzol erişiminde MFA kullanın.
• Yönetici hesap sayısını azaltın; her hesabın yetkisi minimum olmalı (least privilege).
• Uzaktan erişim için paylaşılan hesaplar kullanmayın.

Kontrol listesi

• Her yönetici hesabı için yetki düzeyini yazılı hale getirin.
• İsteyen yönetici için erişim süresi/geri alım planı belirleyin.

5) Dosya izinleri ve dizin yetkileri: yazılabilirlik denetimi

Kötü niyetli bir kullanıcı, uygulama dosyalarına yazabildiği anda kalıcılık (persistence) kurabilir. Bu yüzden dizin ve dosya izinleri kritik bir güvenlik unsurudur.

Ne yapın?

• Uygulama dizinlerinde sadece gerekli klasörleri yazılabilir yapın.
• Web kökü altında çalıştırılmaması gereken dosyalar için doğru izinleri kullanın.
• Dışarıdan yüklenen içerikler için ayrı bir dizin planlayın ve izinleri ayrıştırın.

Kontrol noktası

• Son 30 günde değiştirilmemesi gereken kritik dosyaların (config, servis unitleri) izinlerini ve sahipliğini doğrulayın.

6) Uygulama katmanı: WAF, rate limiting ve güvenli nag/headers

Sunucu güvenliği yalnızca işletim sistemi değildir; web uygulaması katmanında da hızlı kazanımlar vardır. Botlar ve istismar denemeleri, sunucu kaynaklarını tüketip uygulamanızı etkileyebilir.

Ne yapın?

• Önüne bir WAF (Web Application Firewall) yerleştirin veya en azından temel kuralları etkinleştirin.
• Rate limiting ile çok sık istekleri kontrollü hale getirin.
• Güvenli başlıklar (ör. Content-Security-Policy, HSTS) uygulayın.

Nerede ölçün?

Aşağıdaki metrikler güvenliğin “somut” çıktısıdır: - 5xx yanıt oranı (artış saldırı/uygulama yorgunluğu sinyali olabilir) - Trafik anomali türleri (çok sayıda 404/403, tek IP’den yoğun POST vb.) - Rate limit tetiklenme sayıları

7) Yedekleme (backup) stratejisi: test edilmiş kurtarma hedefleri

Yedek almak tek başına güvenlik değildir; yedekten geri dönüşün mümkün olduğu gösterilmelidir. Özellikle VDS/VPS’lerde disk snapshot’ları veya dosya tabanlı backup’lar düzenli test edilmelidir.

Ne yapın?

• Yedekleri en az iki seviyede kurgulayın: (1) konfigürasyon dosyaları, (2) uygulama/veri (veritabanı + uploadlar).
• Yedekleri sunucudan bağımsız bir yere saklayın (ayrı depolama hesabı/konum).
• Geri yükleme (restore) testini aylık rutin haline getirin.

3 hedef önerisi

• RPO (kurtarma için maksimum veri kaybı) için net hedef: örn. “veritabanında 4 saatten fazla veri kaybetmeyeceğim”.
• RTO (geri dönüş süresi): örn. “en fazla 2 saat içinde servisi yeniden ayağa kaldıracağım”.
• Yedek saklama: düzenli günlük/haftalık/aylık katman.

8) Logları merkezileştirin ve anomaliyi erken yakalayın

Saldırı sonrası en büyük kayıp; ne olduğunu anlamaya çalışırken geç kalmaktır. Sunucu güvenliği için loglar, yalnızca “dosyada dursun” diye tutulmamalı; okunabilir, filtrelenebilir ve alarm üretebilir olmalıdır.

Ne yapın?

• SSH girişleri, sudo kullanımı, web erişim logları ve hata loglarını takip edin.
• Başarısız giriş denemeleri, beklenmeyen istek paternleri ve kritik dosya değişikliklerini alarm konusu yapın.
• Mümkünse logları merkezi bir sisteme gönderin (tek sunucuya sıkışmayın).

Hızlı kontrol senaryoları

• Son 24 saatte başarısız SSH denemeleri kaç IP’den geldi?
• Web sunucusunda tek bir endpoint’e aşırı istek var mı?
• Veritabanı tarafında artan yavaş sorgu veya bağlantı sayısı var mı?

9) Şifreleme: disk, veri ve aktarım güvenliğini doğru seviyede yapın

Şifreleme; hem dinleme (in transit) hem de fiziksel disk erişimi (at rest) risklerini azaltır. Yanlış kurulum ise yalnızca “varmış gibi” bir güvenlik yaratır.

Ne yapın?

• Aktarım için TLS kullanın; sertifika yenileme süreçlerini otomatik ve izlenebilir yönetin.
• Mümkünse disk şifrelemesi (LUKS/benzeri) yapın.
• Veritabanı bağlantılarını şifreli şekilde kurun.

Somut doğrulama

• Sertifika bitiş tarihlerini ve otomatik yenilemenin çalıştığını kontrol edin.
• Zayıf şifre takımları (cipher suite) kullanımını devre dışı bırakın.

10) Yetki ve değişiklik yönetimi: “kim neyi ne zaman yaptı” zorunluluğu

Bir sunucuda güvenlik, değişikliklerle bozulur. Bu yüzden değişiklik yönetimi, erişim kontrolü kadar önemlidir.

Ne yapın?

• Konfigürasyon değişikliklerini dokümante edin.
• Paket/servis değişikliklerinde değişiklik kaydı (ticket veya değişiklik notu) tutun.
• Üretim dışı ortamda doğrulama (staging) varsa burada test edin.

Net ölçüm

• Son 30 günde kritik konfigürasyon değişikliği oldu mu?
• Bu değişikliklerin öncesi/sonrası logları nerede? Geri izlenebiliyor mu?

Uygulama sırası: 10 adımı 7 günde nasıl devreye alırsınız?

Aşağıdaki sıra “ilk hafta en fazla riski düşürme” mantığıyla hazırlanmıştır. Uygulama sırasını hızlandırmak için kritik etkiyi yüksek olanlardan başlayın.

1. Güncelleme ve yamalar (Adım 1)
2. Port/servis azaltma + firewall (Adım 2)
3. SSH sertleştirme (Adım 3)
4. MFA + yönetici yetkileri (Adım 4)
5. Dosya izinleri ve web kökü güvenliği (Adım 5)
6. Log merkezileştirme + temel alarm seti (Adım 8)
7. Yedekleme + restore testi planı (Adım 7)

Hızlı kontrol tablosu: neyi kontrol edeceksiniz?

Aşağıdaki tablo, her adımı pratik bir kontrol maddesine dönüştürür.

Sonuç: Hemen başlayın, önce “yüzeyi küçültün”

Sunucu güvenliği için en hızlı sonuç; saldırı yüzeyini azaltmak, kimlik doğrulamayı güçlendirmek ve gözlemlenebilirliği artırmaktır. Bu rehberdeki 10 adımı tek seferde yapmak yerine, yukarıdaki 7 günlük sırayla ilerleyin; özellikle Adım 1 (yamalar), Adım 2 (portlar), Adım 3 (SSH) ve Adım 7 (restore testli yedek) maddeleri ilk haftada tamamlanmalıdır. Sonraki adım olarak log/alarmlarınızı büyütün ve değişiklik yönetimini kalıcı hale getirin.