Web Sitesi Güvenliği: SSL, Güncellemeler, Yedekleme

Küçük bir kurumsal sitenin hedef olmadığını düşünmek yaygın bir yanılgı. Saldırıların büyük kısmı otomatiktir ve siteyi değil, sitede çalışan bilinen açıklı yazılımı arar. Bu yazı, teknik ekibi olmayan bir işletmenin de takip edebileceği temel önlemleri, sıklıklarıyla birlikte sıralıyor.

HTTPS ve sertifika yönetimi

HTTPS, siteniz ile ziyaretçinin tarayıcısı arasındaki iletişimin araya girilerek değiştirilmesini ve izlenmesini engeller. Google'ın web.dev rehberi, hassas veri işlemeyen siteler dahil tüm sitelerin HTTPS kullanmasını öneriyor; kamera, konum ve servis çalışanları gibi modern tarayıcı özellikleri de HTTPS olmadan çalışmıyor 1.

HTTPS'i kurmak kadar sürdürmek de önemli. Let's Encrypt, sertifikaları otomatik olarak veren kâr amacı gütmeyen bir sertifika otoritesi; varsayılan sertifika ömrü 90 gün. Sektör kuralları 15 Mart 2029'dan itibaren azami sertifika ömrünü 47 güne indiriyor ve Let's Encrypt Şubat 2028'e kadar 45 güne geçmeyi planlıyor 2. Kısacası elle yenilenen sertifika dönemi kapanıyor; barındırma sağlayıcınızın ya da sunucunuzun yenilemeyi otomatik yaptığından emin olun.

MDN'in uygulama rehberi sıralamayı da veriyor: önce güvenli TLS yapılandırması, ardından tüm kaynakların HTTPS ile yüklenmesi, HTTP isteklerinin HTTPS'e yönlendirilmesi ve tarayıcıya yalnız HTTPS kullanmasını söyleyen HSTS başlığı 6.

Güncelleme yönetimi

OWASP Top 10'un 2025 sürümünde "yazılım tedarik zinciri hataları" üçüncü sırada yer alıyor ve kapsamına güncel olmayan, desteği biten ya da açığı bilinen bileşenler de giriyor 7. WordPress'in güvenlik sıkılaştırma rehberi de ilk maddede aynı şeyi söylüyor: WordPress'i, temaları ve eklentileri güncel tutun 3.

Pratikte güncelleme yönetimi şu kararları içerir:

• Envanter: Sitede hangi eklenti, tema ve kütüphane var? Kullanılmayanlar silinmeli; pasif bırakılan eklenti de dosya olarak sunucuda durur.
• Takvim: Güvenlik güncellemeleri beklemeden, büyük sürüm güncellemeleri ise test ortamında denendikten sonra uygulanır.
• Yedek: Her güncellemeden önce geri dönülebilir bir yedek alınır.
• Sunucu tarafı: PHP, veritabanı ve işletim sistemi sürümleri de bu listenin parçasıdır.

WordPress rehberi ayrıca yönetim panelindeki dosya düzenleyicinin kapatılmasını, dosya izinlerinin daraltılmasını ve FTP yerine SFTP kullanılmasını öneriyor 3.

Güncelleme yükü, seçtiğiniz altyapıyla doğrudan ilişkilidir. Çok sayıda eklentiyle çalışan bir CMS'te her eklenti ayrı bir güncelleme takvimi ve ayrı bir risk demektir; özel yazılımda ise bağımlı kütüphanelerin takibi geliştirici ekibe düşer. Hiçbiri kendi başına daha güvenli değildir, yalnızca sorumluluğun nerede durduğu değişir. Bu dengeyi WordPress mi özel yazılım mı yazısında ayrıntılı ele aldık.

Güçlü kimlik doğrulama ve 2FA

Yönetici şifresinin ele geçmesi, en iyi güncellenmiş siteyi bile savunmasız bırakır. CISA, çok faktörlü doğrulamayı en az iki doğrulayıcının birlikte istendiği katmanlı bir yaklaşım olarak tanımlıyor ve kimlik avına dayanıklı yöntem olarak FIDO/WebAuthn'u öne çıkarıyor; yine de her türlü çok faktörlü doğrulamanın hiç olmamasından iyi olduğunu vurguluyor 4.

Uygulanacak kurallar:

• Her yönetici için ayrı hesap; ortak "admin" hesabı yok.
• Uzun, benzersiz şifreler ve bir şifre yöneticisi.
• Yönetim paneli, barındırma paneli, alan adı hesabı ve DNS sağlayıcısında iki adımlı doğrulama.
• Ayrılan çalışan ve biten ajans ilişkisinde erişimin aynı gün kapatılması.
• Hesaplara yalnız gereken yetkinin verilmesi; içerik editörünün yönetici olmaması.

Yedekleme: 3-2-1 kuralı

CISA'nın yedekleme rehberi 3-2-1 kuralını önerir: önemli her dosyanın üç kopyası (bir asıl, iki yedek), iki farklı ortam türünde ve bir kopya kurum dışında 5. Web sitesi için bu şöyle uygulanabilir: canlı site, barındırma sağlayıcısının yedeği ve sizin kontrol ettiğiniz ayrı bir bulut depolama alanındaki kopya.

Yedeğin iki parçası vardır: dosyalar ve veritabanı. Yalnız birini almak çoğu zaman siteyi geri getirmeye yetmez. Asıl sınav geri yüklemedir; hiç denenmemiş bir yedek, olay günü sürprizlerle doludur.

Güvenlik başlıkları ve form spam koruması

Güvenlik başlıkları, tarayıcıya sitenizi nasıl ele alacağını söyleyen kısa sunucu ayarlarıdır. MDN'in rehberi bunları etki ve zorluk derecesiyle sıralıyor 6:

• HSTS: Tarayıcının siteye yalnız HTTPS ile bağlanmasını sağlar.
• X-Frame-Options ya da CSP frame-ancestors: Sitenizin başka bir sayfada gizli çerçeve içine alınarak tıklama tuzağına dönüştürülmesini engeller.
• X-Content-Type-Options: Tarayıcının dosya türünü tahmin etmesini engeller.
• Content Security Policy (CSP): Hangi kaynaklardan betik yüklenebileceğini sınırlar; etkisi yüksek ama kurulumu en zahmetli olanıdır.
• Referrer-Policy ve güvenli çerez ayarları: Gizlilik ve oturum güvenliği için tamamlayıcıdır.

İletişim ve teklif formları da ayrı bir saldırı yüzeyidir. Form spam'ine karşı katmanlı düşünün: insanların görmediği bir tuzak alan, aynı adresten gelen isteklere hız sınırı, sunucu tarafında doğrulama ve gerekiyorsa görünmez çalışan bir bot doğrulama servisi. Doğrulamanın yalnız tarayıcıda yapılması yeterli değildir; kontrolün sunucuda tekrarlanması gerekir.

OWASP Top 10'a kısa giriş

OWASP Top 10, web uygulamalarındaki en kritik güvenlik risklerini veriye dayanarak sıralayan, geliştiricilerin ve denetçilerin ortak referans olarak kullandığı bir listedir. Güncel sürüm 2025 sürümüdür ve kategorileri şunlardır 7:

Bu listeyi ezberlemeniz gerekmiyor; ama sitenizi geliştiren ya da bakımını yapan ekibe "OWASP Top 10'a göre hangi kontrolleri yapıyorsunuz?" diye sormak, konuşmayı somut bir zemine taşır. Hazır bir CMS kullanıyorsanız A02, A03 ve A07 sizin doğrudan etkileyebileceğiniz alanlardır: yapılandırma, güncelleme ve kimlik doğrulama. Özel yazılım geliştiriliyorsa erişim kontrolü ve enjeksiyon testleri teslim kriterlerine yazılmalıdır. A09 ise çoğu küçük sitede gözden kaçar: yönetici girişleri, başarısız giriş denemeleri ve dosya değişiklikleri kayıt altına alınmıyorsa, saldırı ancak sonuçları görünür olduğunda fark edilir. WordPress rehberi de bu nedenle kayıt tutmayı ve dosya bütünlüğü izlemeyi öneriyor 3.

Risk, önlem ve sıklık tablosu

Tablodaki sıklıklar başlangıç önerisidir; trafiği, veri hassasiyeti ve yazılım sayısı yüksek sitelerde daha sık kontrol gerekir.

Olay anında adımlar

WordPress.org'un "sitem hacklendi" rehberi, olay sonrası süreci şöyle sıralıyor; adımlar başka sistemlere de büyük ölçüde uyar 8:

1. Sakin kalın ve belgeleyin. Ne gördüğünüzü, ne zaman fark ettiğinizi ve son yapılan değişiklikleri (yeni eklenti, tema değişikliği) yazın.
2. Siteyi ve kendi bilgisayarınızı tarayın. Bazı saldırılar, yönetici bilgisayarındaki zararlı yazılımla çalınan şifrelerle başlar.
3. Barındırma firmasını bilgilendirin. Özellikle paylaşımlı barındırmada sorun başka siteleri de etkileyebilir.
4. Tüm erişimleri sıfırlayın. Yönetim paneli, SFTP, barındırma paneli ve veritabanı şifrelerini değiştirin; açık oturumları kapatın.
5. Mevcut durumun kopyasını alın. Temizlikten önce, enfekte olsa bile, bir anlık görüntü saklayın.
6. Temizleyin ya da temiz bir yedekten geri dönün. Çekirdek dosyaları aynı sürümle yeniden yükleyin, tema ve eklentileri tek tek kontrol edin.
7. Güncelleyin ve şifreleri yeniden değiştirin. Temizlik sonrası değişiklik, saldırganın elindeki eski bilgileri geçersiz kılar.
8. Nasıl girildiğini anlayın ve sıkılaştırın. Kayıtları inceleyin, açığı kapatın, sıkılaştırma önlemlerini uygulayın 3.

Güvenliğin süreklilik isteyen kısmı bakımdır; kalemleri web sitesi bakımı yazısında sıraladık. Barındırma türünün güvenlik yüküne etkisini barındırma seçimi yazısında, bu işleri düzenli olarak nasıl üstlendiğimizi bakım ve destek sayfamızda bulabilirsiniz.