WordPress Güvenliği İçin Kurumsal Kontrol Listesi

WordPress güvenliği yalnız bir security plugin yüklemekle sağlanmaz. Kullanıcı yönetimi, plugin politikası, hosting, güncelleme, backup ve edge güvenliği birlikte ele alınmalıdır.

Kurumsal kullanımda asıl hedef WordPress’i değiştirilmesi zor bir sistem haline getirmek değil, kontrollü ve izlenebilir bir işletim modeli kurmaktır.

Admin Hesaplarını Sınırlayın

Her editörün administrator olması gerekmez. Kullanıcılara görevleri için gereken minimum rol verilmelidir.

2FA Kullanın

Özellikle administrator ve site yönetim yetkisi bulunan hesaplarda ikinci faktör hesap ele geçirme riskini azaltır.

Plugin Envanteri

Kullanılmayan veya artık desteklenmeyen plugin’ler kaldırılmalıdır. Her plugin yeni kod ve potansiyel saldırı yüzeyi ekler.

Tema ve Child Theme Yönetimi

Canlı tema dosyasında doğrudan değişiklik yapmak update sürecini zorlaştırabilir. Custom değişikliklerin kontrollü yapıda tutulması gerekir.

Dosya İzinleri

Web server kullanıcısına gereksiz geniş yazma yetkisi verilmemelidir. wp-config ve kritik dosyaların erişimi sınırlandırılmalıdır.

XML-RPC ve Kullanılmayan Özellikler

Kullanılmayan endpoint veya özellikler ihtiyaç ve entegrasyon bağımlılıkları kontrol edilerek sınırlandırılabilir.

WAF ve Rate Limit

Login, XML-RPC veya yoğun saldırı alanlarında edge veya web application firewall kuralları ek koruma sağlayabilir.

Backup, Staging ve Güncelleme

• Otomatik backup
• Restore testi
• Staging
• Core update
• Plugin update
• Tema update
• PHP/runtime lifecycle

Production Readiness Nasıl Değerlendirilmeli?

WordPress Güvenliği İçin Kurumsal Kontrol Listesi kapsamında production hazırlığı yalnız sayfanın tarayıcıda açılmasıyla tamamlanmış sayılmaz. Özellikle Admin Hesaplarını Sınırlayın, 2FA Kullanın ve Plugin Envanteri 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

WordPress Güvenliği İçin Kurumsal Kontrol Listesi 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 Admin Hesaplarını Sınırlayın, 2FA Kullanın ve Plugin Envanteri ü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

WordPress kurumsal kullanım için güvenli olabilir mi?

Doğru işletim, güncelleme ve güvenlik kontrolleriyle kurumsal yapılarda kullanılabilir.

Security plugin tek başına yeterli mi?

Hayır. Sunucu, kullanıcı, update ve backup süreçleri de güvenli olmalıdır.

Plugin sayısı güvenliği etkiler mi?

Her ek bileşen bakım ve güvenlik yüzeyini artırabilir; kullanılmayan plugin’ler kaldırılmalıdır.

WordPress güncellemeleri hemen yapılmalı mı?

Kritik güvenlik güncellemeleri hızlı ele alınmalı; uyumluluk riski olan değişiklikler staging üzerinde test edilmelidir.