Temel çıkarım: WordPress sertleştirme tek bir düzeltme değil, erişim kontrolü, yazılım hijyeni, sunucu seviyesi yapılandırma, ağ koruması ve sürekli izlemeyi kapsayan katmanlı bir checklist'tir — her katman farklı bir risk kategorisini kapatır ve birini atlamak, diğerlerinin kapatmadığı bir boşluk bırakır.
Neden Tek Bir Düzeltme Değil, Bir Checklist
WordPress sitelerini gerçekte ele geçiren belirli güvenlik açıklarını — güncel olmayan eklentiler, zayıf kimlik bilgileri, SQL injection, XSS, XML-RPC istismarı — yaygın WordPress güvenlik açıkları rehberimizde ele aldık. Sertleştirme ise proaktif karşılığı: herhangi bir belirli güvenlik açığı devreye girmeden önce saldırı yüzeyini azaltan, hiçbir şeyin atlanmaması için burada katman katman düzenlenmiş, yapılandırma seçimlerinden oluşan yapılandırılmış bir set.
Erişim Kontrolü Sertleştirmesi
- Sadece birincil yönetici için değil, yayınlama veya admin erişimi olan her hesap için iki faktörlü kimlik doğrulamayı zorunlu kıl.
- En az yetki rollerini uygula — her kullanıcıya (site ajans tarafından yönetiliyorsa her müşteriye) herkesi varsayılan olarak Yönetici yapmak yerine gerçek işini yapmasına izin veren en düşük WordPress rolünü ver.
- Bir ekip üyesi veya müşteri ilişkisi sona erdiğinde, kalıcı erişimi olan uykuda bir hesap bırakmak yerine kullanılmayan hesapları hemen kaldır.
- wp-login.php'yi hedef alan otomatik brute-force araçlarını yavaşlatmak için giriş denemelerini sınırla.
- Hâlâ kullanımdaysa varsayılan "admin" kullanıcı adını yeniden adlandır veya kısıtla, çünkü bu otomatik saldırıların denediği ilk kullanıcı adıdır.
Çekirdek, Eklenti ve Tema Hijyeni
- WordPress çekirdeği, eklentiler ve temalar için, güncellemenin düşük regresyon riski taşıdığı her yerde otomatik güncellemeleri etkinleştir, ve geri kalanını production'a göndermeden önce bir staging kopyasında test et.
- Kurulu eklentileri üç ayda bir denetle, aktif olarak kullanılmayan her şeyi kaldır — bilinen bir güvenlik açığı olan devre dışı bir eklenti, devre dışı bırakılsa bile bazı saldırı zincirlerinde hâlâ istismar edilebilir.
- Bir eklentiyi kurmadan önce güvenlik açığı geçmişini ve bakım aktivitesini kontrol et, temiz bir açıklama geçmişi olan aktif olarak bakımı yapılan eklentileri terk edilmişlere tercih et.
Sunucu ve Dosya Seviyesi Sertleştirme
- Dosyalar için 644, dizinler için 755 izin ayarla, WordPress'in kendi sertleştirme dokümantasyonuna göre, wp-config.php'nin ise veritabanı kimlik bilgilerini doğrudan tuttuğu için daha da kilitlenmesi gerekiyor.
- wp-config.php'ye define('DISALLOW_FILE_EDIT', true); ekleyerek wp-admin'den dosya düzenlemeyi devre dışı bırak, bu admin erişimi olan bir saldırgana kod çalıştırma için doğrudan bir yol veren yerleşik tema/eklenti düzenleyicisini kaldırır.
- Sunucuda dizin taramasını devre dışı bırak, böylece yanlış yapılandırılmış bir klasör, onu doğrudan isteyen herkese ham bir dosya listesi göstermez.
- Kurulum sırasında veya bir taşıma aracı üzerinden varsayılan veritabanı tablo önekini (wp_) değiştir, bazı otomatik SQL injection denemelerinin dayandığı bir varsayımı ortadan kaldır.
- Belirli bir eklenti (en yaygın olarak Jetpack) veya mobil uygulama aktif olarak gerektirmedikçe XML-RPC'yi devre dışı bırak.
Ağ Seviyesi Korumalar
- Site genelinde HTTPS'yi zorunlu kıl, tüm HTTP trafiğini yönlendir, çünkü şifrelenmemiş bir bağlantı, aynı ağdaki herkese giriş kimlik bilgilerini ve oturum çerezlerini açık eder.
- Bir web uygulama güvenlik duvarı (WAF) ekle, CDN seviyesi bir hizmet veya bir güvenlik eklentisi üzerinden, bilinen saldırı desenlerini WordPress'in kendisine ulaşmadan önce engelle.
- Güvenlik başlıklarını ayarla — Content-Security-Policy, X-Frame-Options ve Strict-Transport-Security — çoğu CDN ve bazı güvenlik eklentileri, WordPress'in kendi koduna dokunmadan bunları uygulayabilir.
İzleme, Loglama ve Yedekleme
- Dosya bütünlüğü izlemeyi etkinleştir, böylece bir çekirdek dosyasında beklenmeyen bir değişiklik veya wp-content'te görünen tanıdık olmayan bir dosya fark edilmeden geçmek yerine bir uyarı tetikler.
- Düzenli kötü amaçlı yazılım taramaları planla, bir şeyler zaten yanlış görünmeye başladıktan sonra kontrol etmek yerine bir güvenlik eklentisi veya harici bir tarama hizmeti kullanarak.
- Sitenin gerçekte ne sıklıkla değiştiğine uygun bir takvimde otomatik, site dışı yedekler tut, ve bir yedeğin işe yaradığını varsaymak yerine periyodik olarak gerçekten geri yüklendiğini test et.
- WPScan veya Patchstack gibi bir güvenlik açığı açıklama akışına abone ol, böylece yeni açıklanan bir eklenti güvenlik açığı, istismar edildikten sonra keşfedilmek yerine saatler içinde bilinir hale gelir.
Bir Bakışta Tam Checklist
| Kategori | Anahtar Eylemler |
|---|---|
| Erişim kontrolü | 2FA, en az yetki rolleri, kullanılmayan hesapları kaldır, giriş denemelerini sınırla |
| Yazılım hijyeni | Otomatik güncellemeler, üç aylık eklenti denetimi, kurmadan önce güvenlik açığı geçmişini kontrol et |
| Sunucu/dosya yapılandırması | 644/755 izinler, dosya düzenlemeyi devre dışı bırak, dizin taramasını devre dışı bırak, tablo önekini değiştir, XML-RPC'yi devre dışı bırak |
| Ağ koruması | HTTPS'yi zorunlu kıl, bir WAF ekle, güvenlik başlıklarını ayarla |
| İzleme ve yedekleme | Dosya bütünlüğü izleme, planlı kötü amaçlı yazılım taramaları, test edilmiş site dışı yedekler, güvenlik açığı akışı aboneliği |
Uyumluluk Boyutu: Sertleştirme Sadece Güzel Bir Ekstra Değil
AB'de faaliyet gösteren ajanslar ve işletmeler için, sertleştirme önlemleri artık tamamen isteğe bağlı bir en iyi uygulama olmaktan çok, düzenleyici yükümlülüklerle giderek daha fazla örtüşüyor. AB Siber Dayanıklılık Yasası, belirli koşullar altında ticari WordPress eklentilerini ve temalarını da kapsayan dijital öğeleri olan ürün üreticilerinin, temel siber güvenlik gereksinimlerini karşılamasını ve bir ürünün ömrü boyunca — sadece lansmanda değil — güvenlik açığı açıklamasını sorumlu bir şekilde ele almasını gerektiriyor.
Yukarıdaki teknik sertleştirme adımları (güncellemeler, erişim kontrolü, güvenlik açığı izleme) bu yükümlülüğün güvenlik tarafını doğrudan destekliyor, ancak tam uyumluluk, sertleştirmenin tek başına üretmediği ayrı belgeler de gerektiriyor — bir güvenlik açığı açıklama politikası, bir yazılım malzeme listesi (SBOM) ve uygunluk kayıtları. Bu, Erdo CRA Compliance eklentimizin izlemeye yardımcı olmak için tasarlandığı belirli boşluk: bir siteyi CRA, GDPR ve NIS2 gereksinimlerine göre taramak ve bir sertleştirme checklist'inin tek başına kapsamadığı belgeleri üretmek.
Yaygın Sertleştirme Hataları
- Sertleştirmeyi tek seferlik bir kurulum görevi olarak ele almak, tekrarlayan bir gözden geçirme yerine, kullanıcı hesaplarının ve eklenti listelerinin aylar içinde güvenli bir durumdan kaymasına izin vermek.
- Bir güvenlik eklentisi kurup checklist'in tamamlandığını düşünmek, sunucu seviyesi dosya izinleri ve erişim kontrolü kararlarının hâlâ bağımsız olarak ele alınması gerekirken.
- Dosya düzenlemeyi devre dışı bırakmak veya izinleri kısıtlamak gibi değişiklikler için canlı siteyi doğrudan sertleştirmek, bir eklentinin devre dışı bırakılan işlevselliğe bağımlı olma ihtimaline karşı önce staging'de test etmeden.
- Yedeklerin gerçekten geri yüklendiğini hiç test etmemek, bozuk veya eksik bir yedeği ancak gerçek bir olay sırasında keşfetmek.
- Güncellemeler hariç her sertleştirme adımını uygulamak, geri kalan her şey ne kadar sertleştirilmiş olursa olsun güncel olmayan yazılım tek en çok istismar edilen giriş noktası olarak kalırken.
Özetle
Kısacası, WordPress sertleştirmesi tek bir eylem değil katmanlı bir checklist olarak çalışır — erişim kontrolü, yazılım hijyeni, sunucu yapılandırması, ağ koruması ve sürekli izleme her biri farklı bir risk kategorisini kapatır, ve AB'ye yönelik siteler için bu adımların birçoğu artık isteğe bağlı bir en iyi uygulamadan çok düzenleyici uyumluluk için bir temel görevi görüyor. Tam listeyi bir kez kurup öylece kaldığını varsaymak yerine üç ayda bir gözden geçirmek, sertleştirilmiş bir sitenin zaman geçtikçe gerçekten sertleştirilmiş kalmasını sağlayan şeydir.