Web Sitesi Güvenlik Audit’i Nasıl Yapılır?

Web sitesi güvenlik audit’i yalnız zararlı yazılım taraması yapmak değildir. Uygulamanın saldırı yüzeyi, kullanıcı yetkileri, dependency’leri, sunucu konfigürasyonu ve incident kabiliyeti birlikte değerlendirilmelidir.

Audit’in amacı her ihtimali ortadan kaldırmak değil, riskleri görünür hale getirip etki ve olasılığa göre önceliklendirmektir.

Varlık ve Saldırı Yüzeyi Envanteri

Domain, subdomain, admin paneli, API endpoint, upload alanı, üçüncü taraf script ve entegrasyonlar listelenmelidir.

Unutulmuş staging veya eski subdomain’ler beklenmeyen saldırı yüzeyi oluşturabilir.

TLS ve HTTPS

Sertifika zinciri, süresi, HTTP yönlendirmesi ve mixed content kontrolleri yapılmalıdır.

Security Headers

• Content-Security-Policy
• X-Content-Type-Options
• Referrer-Policy
• Permissions-Policy
• Frame kısıtları
• HSTS uygunluğu

Authentication

Admin ve kritik kullanıcı hesaplarında güçlü parola politikası, 2FA ve brute-force koruması değerlendirilmelidir.

Authorization

Kullanıcının yalnız kendi rolüne ait işlemleri yapabildiği doğrulanmalıdır. Authentication başarılı olması her veriye erişim hakkı anlamına gelmez.

Dependency ve Patch Yönetimi

CMS, framework, plugin, tema ve paketlerin destek durumu kontrol edilmelidir. Kullanılmayan bileşenler kaldırılmalıdır.

Upload ve Input Güvenliği

Dosya yükleme alanları dosya tipi, boyut ve saklama yöntemi açısından incelenmeli; tüm kullanıcı girdileri güvenilmeyen veri kabul edilmelidir.

Log ve Incident Readiness

Başarısız login, admin değişikliği, uygulama hatası ve kritik güvenlik olayı sonradan incelenebilir biçimde loglanmalıdır.

Production Readiness Nasıl Değerlendirilmeli?

Web Sitesi Güvenlik Audit’i Nasıl Yapılır? kapsamında production hazırlığı yalnız sayfanın tarayıcıda açılmasıyla tamamlanmış sayılmaz. Özellikle Varlık ve Saldırı Yüzeyi Envanteri, TLS ve HTTPS ve Security Headers için ölçülebilir kabul kriterleri oluşturulmalıdır. Uptime, response time, hata oranı, deployment süresi ve kritik kullanıcı akışları için baseline değerler bulunması sonraki değişikliklerin etkisini ölçmeyi kolaylaştırır. Staging ile production ortamlarının temel konfigürasyon farkları kayıt altına alınmalı ve canlı sistem üzerinde doğrudan manuel değişiklikler mümkün olduğunca sınırlandırılmalıdır.

Güvenlik ve performans birlikte değerlendirilmelidir. CDN veya cache kullanımı origin yükünü azaltırken yanlış cache kuralı kullanıcıya özel içeriğin paylaşılmasına neden olabilir. Benzer şekilde WAF veya rate limit saldırı yüzeyini azaltabilir fakat kritik API veya entegrasyonların çalışmasını engellememelidir. Bu nedenle güvenlik değişiklikleri gerçek trafik senaryolarıyla test edilmeli; uygulama logları, reverse proxy kayıtları ve dış servis health metrikleri merkezi olarak izlenmelidir.

Yayın ve Geri Dönüş Planı

Yeni sürüm, CMS güncellemesi veya altyapı değişikliğinde deployment öncesi database ve dosya backup durumu doğrulanmalı; gerekiyorsa maintenance veya trafik yönlendirme planı hazırlanmalıdır. Database migration içeren sürümlerde geri dönüş yöntemi ayrıca tasarlanmalıdır. Yayın sonrasında yalnız ana sayfayı kontrol etmek yerine login, form, arama, API, ödeme veya lead akışı gibi sitenin iş açısından kritik fonksiyonları smoke test ile doğrulanmalıdır. Bu yaklaşım web altyapısını tek seferlik proje değil sürekli işletilen üretim sistemi olarak ele alır.

Web Altyapısı Teknik Kontrol Listesi

• Staging ve production ayrılmış mı?
• Deployment geri alınabilir mi?
• Backup restore testi yapıldı mı?
• Application ve web server logları izleniyor mu?
• Security header ve TLS kontrolleri yapıldı mı?
• Cache bypass kuralları test edildi mi?
• Runtime ve dependency lifecycle takip ediliyor mu?
• Kritik kullanıcı akışları smoke test ile doğrulanıyor mu?

Değişiklik Yönetimi, SLO ve Incident Readiness

Web Sitesi Güvenlik Audit’i Nasıl Yapılır? kapsamında teknik kalite yalnız ilk canlıya çıkış anında değerlendirilmemelidir. Sistem güncellendikçe dependency, CMS, runtime, cache, güvenlik kuralı ve entegrasyon davranışı değişebilir. Bu nedenle değişikliklerin ticket veya release kaydıyla izlenmesi, hangi sürümün ne zaman production ortamına çıktığının bilinmesi ve kritik değişikliklerde geri dönüş yönteminin önceden tanımlanması gerekir. Özellikle Varlık ve Saldırı Yüzeyi Envanteri, TLS ve HTTPS ve Security Headers üzerinde yapılan değişiklikler yayın öncesi ve sonrası karşılaştırılabilir metriklerle doğrulanmalıdır.

Operasyonel hedefler için Service Level Objective benzeri ölçülebilir sınırlar tanımlanabilir. Uptime, P95 response time, 5xx oranı, kritik form veya işlem başarısı ve deployment sonrası hata oranı gibi metrikler uygulamanın gerçek sağlığını gösterir. Sadece sunucunun erişilebilir olması yeterli değildir; örneğin ana sayfa 200 dönerken iletişim formu, ödeme, arama veya API entegrasyonu çalışmıyor olabilir. Bu nedenle teknik monitoring yanında iş açısından kritik synthetic veya smoke kontrolleri de kullanılmalıdır.

Incident hazırlığında sorunun kim tarafından fark edileceği, ilk müdahaleyi hangi ekibin yapacağı ve hangi durumda rollback uygulanacağı önceden belirlenmelidir. Log, request ID, deployment zamanı ve infrastructure metriği aynı olay üzerinde ilişkilendirilebildiğinde kök neden analizi hızlanır. Olay sonrasında yalnız sistemi tekrar ayağa kaldırmak yerine tekrar oluşmayı engelleyecek teknik veya süreç aksiyonlarının kaydedilmesi, web altyapısının zaman içinde daha dayanıklı hale gelmesini sağlar.

Sıkça Sorulan Sorular

Güvenlik audit’i penetration test ile aynı mı?

Hayır. Penetration test audit’in bir parçası olabilir; audit yapılandırma ve süreç kontrollerini de kapsar.

HTTPS siteyi tamamen güvenli yapar mı?

Hayır. TLS yalnız iletişim güvenliğinin önemli bir bileşenidir.

Security header eklemek yeterli mi?

Hayır. Uygulama, erişim, dependency ve sunucu güvenliği birlikte ele alınmalıdır.

Güvenlik audit’i ne sıklıkla yapılmalı?

Risk seviyesi ve değişiklik sıklığına göre periyodik ve önemli değişiklikler sonrasında yapılabilir.