Web sitesi güvenliği: küçük ekiplerin gerçekten yapması gereken 10 şey

Küçük ekiplerin çoğu güvenliği bir ürün satın alma meselesi sanır. Oysa gerçek dünyada siteler sıfırıncı gün açıklarıyla değil, güncellenmemiş bir eklenti, paylaşılan bir şifre ve çalıştığı hiç denenmemiş bir yedekle düşer.

Aşağıdakiler pahalı değil, sadece disiplin gerektiriyor.

1 · Saldırı yüzeyini küçültün

En etkili güvenlik önlemi, olmayan koddur. Sitenizin sunucu tarafında çalışan bir parçası yoksa, o parça istismar edilemez.

Statik olarak üretilen bir site bu yüzden yapısal olarak daha güvenlidir: veritabanı yok, yönetim paneli girişi yok, çalışan bir yorumlayıcı yok. Sunucu tarafı mantık gerekiyorsa tek bir uca sıkıştırın ve o ucu iyi koruyun.

Kullanmadığınız her eklentiyi, her kütüphaneyi ve her alt alan adını silin. “Belki lazım olur” diye duran şey, güncellenmediği için ilk kırılan şeydir.

2 · Güncellemeyi rastlantıya bırakmayın

İhlallerin büyük kısmı, yaması aylar önce yayımlanmış bilinen açıklardan gerçekleşiyor.

Takvime bağlayın: ayda bir sabit gün, bağımlılıkları güncelleyip testleri çalıştırın. Otomatik bağımlılık uyarılarını açın. Güvenlik yamalarını normal güncellemelerden ayırın ve onları beklemeyin.

3 · Yedeği değil, geri yüklemeyi test edin

“Yedeğimiz var” cümlesi bir güvence değil. Güvence, son geri yüklemeyi ne zaman denediğinizdir.

Yedek dosyaları bozuk olabilir, veritabanı şeması uyuşmayabilir, medya klasörü hiç dâhil edilmemiş olabilir. Bunu ilk kez olay anında öğrenmek, yedek almamış olmakla neredeyse aynı sonucu verir.

Üç ayda bir, yedeği ayrı bir ortama geri yükleyin ve sitenin açıldığını görün. Yedekleri asıl sunucudan ayrı bir yerde tutun; sunucu ele geçirilirse yedekler de gitmesin.

4 · Erişimi kişiye bağlayın

Paylaşılan bir yönetici hesabı, kimin ne yaptığını bilinemez hâle getirir ve ekipten biri ayrıldığında geride açık kapı bırakır.

• Her kişiye kendi hesabı.
• İki adımlı doğrulama zorunlu — özellikle alan adı, barındırma ve kod deposu hesaplarında.
• En az yetki: herkes yönetici olmamalı.
• Ayrılan kişinin erişimini aynı gün kapatın.

Alan adı kayıt hesabınız en kritik varlıktır. Orası ele geçirilirse e-postanız dâhil her şey yönlendirilebilir.

5 · Güvenlik başlıklarını verin

Birkaç HTTP başlığı, sınıf olarak birçok saldırıyı kapatır. Statik sitelerde bu genelde tek bir yapılandırma dosyasıdır:

• Content-Security-Policy — hangi kaynaktan script çalışabileceğini sınırlar. En etkilisi ve en çok atlanı.
• X-Content-Type-Options: nosniff
• X-Frame-Options veya CSP frame-ancestors — sitenizin başka bir sayfaya gömülmesini engeller.
• Strict-Transport-Security — tarayıcıya yalnızca HTTPS kullanmasını söyler.
• Referrer-Policy: strict-origin-when-cross-origin

CSP’yi önce rapor modunda açın, gerçek trafikte neyi kırdığını görün, sonra zorunlu hâle getirin.

6 · Formları kötüye kullanıma kapatın

Sitenizde bir form varsa, o form bir e-posta gönderme aracıdır ve botlar bunu bilir.

Sunucu tarafında hız sınırı koyun, bal küpü alanı ekleyin, alan uzunluklarını sınırlayın ve gelen içeriği e-postaya basmadan kaçış işleminden geçirin. Doğrulamayı yalnızca tarayıcıda yapmak, doğrulama yapmamaktır.

7 · Sırları koda koymayın

API anahtarları, veritabanı şifreleri ve token’lar ortam değişkenlerinde durmalı, depoda değil.

Bir kez depoya girmiş bir anahtar, sonradan silinse de geçmişte durur. Böyle bir şey olduysa dosyayı silmek yeterli değildir — anahtarı iptal edip yenisini üretin. Depoya sır girmesini engelleyen bir tarama adımını CI’a ekleyin.

8 · Bağımlılıkları sayın

Modern bir projede binlerce dolaylı bağımlılık olabilir. Hepsini okumanız mümkün değil, ama şunlar mümkün:

• Sürümleri kilitleyin.
• Otomatik güvenlik denetimi çalıştırın.
• Kurulum betiği çalıştıran paketleri bilinçli onaylayın.
• Aynı işi yapan üç kütüphaneden ikisini silin.

9 · Log tutun ve saklayın

Bir olay yaşandığında ilk soru “ne zaman ve nasıl girdiler” olur. Log yoksa cevap da yoktur.

Erişim loglarını, yönetim paneli girişlerini ve başarısız giriş denemelerini kaydedin. Logları en az birkaç ay saklayın — ihlaller genellikle olduktan haftalar sonra fark edilir.

10 · Olay anı planını önceden yazın

Kriz anında kimse doğaçlama iyi karar vermez. Tek sayfalık bir plan yeterli:

• Şüphe hâlinde siteyi kim, nasıl bakım moduna alır?
• Alan adı, barındırma ve kod deposu şifreleri hangi sırayla değiştirilir?
• Kişisel veri sızıntısı varsa KVKK bildirimi kim tarafından, kaç saat içinde yapılır?
• Müşterilere ne zaman ve kim tarafından haber verilir?

Bu planı yazmak yarım saat sürer ve olay anında saatler kazandırır.

Öncelik sırası

Hepsini bir günde yapamazsanız şu sırayla ilerleyin: erişim yönetimi ve iki adımlı doğrulama → geri yükleme testi → güncelleme disiplini → güvenlik başlıkları → form koruması.

İlk ikisi, gerçek dünyada olan olayların çoğunu kapsar.