Kısa cevap: Web sitesi güvenliği bir eklenti kurmakla tamamlanmaz. Alan adı hesabından hosting paneline, yönetici rollerinden yedekleri geri yüklemeye kadar pek çok katmanın birlikte korunması gerekir. Aşağıdaki maddeler genel bir başlangıçtır; özel sunucu yapılandırmaları için yetkili uzman kontrolü gerekir.
1. Hesap ve yetki envanteri
Domain, DNS, barındırma, e-posta ve site yönetim hesaplarının sahiplerini belirleyin. Tek kişinin kişisel hesabına bağımlılık, o hesap kaybolduğunda hizmet kesintisine neden olabilir. Çalışan ayrıldığında erişimlerin kaldırılması ve kurtarma seçeneklerinin güncel tutulması önemlidir.
- Yönetici hesaplarını kaydedin.
- Her hesaba gereken en düşük yetkiyi verin.
- Kurtarma e-postasını ve sahipliği doğrulayın.
2. HTTPS neyi korur?
HTTPS tarayıcı ile sunucu arasında iletilen verinin gizlilik ve bütünlüğünü korumaya yardımcı olur. Ancak kötü amaçlı eklenti, çalınmış yönetici parolası veya uygulamadaki güvenlik açığı tek başına SSL sertifikasıyla çözülmez. Sertifikanın geçerliliği ve HTTPS yönlendirmesi kontrol edilmelidir.
- Sertifika yenilemesini izleyin.
- HTTPden HTTPSye geçişi doğrulayın.
- Karışık içerik uyarılarını araştırın.
3. Parola ve çok faktörlü doğrulama
Yönetici şifrelerinin farklı hizmetlerde tekrar edilmesi riski artırır. Benzersiz güçlü parolalar, uygun parola yöneticisi ve mümkün olduğunda MFA kullanmak önemlidir. İçerik editörlerinin her zaman tam yönetici rolüne ihtiyacı yoktur.
- Ortak hesapları gözden geçirin.
- MFA kullanın.
- Kullanıcı rollerini düzenli denetleyin.
4. Güncelleme ve eklentiler
Bakımı yapılmayan tema ve eklentiler bilinen açıklıklar barındırabilir. Bununla birlikte güncellemeler bazen form veya tema işlevini etkileyebilir; bu yüzden yedek ve test ortamı gerekir. Kurulmuş ama kullanılmayan bileşenleri ihtiyaç analiziyle kaldırın.
- Eklentinin kaynağını ve bakım durumunu kontrol edin.
- Güncellemeden önce geri dönüş planı hazırlayın.
- İşlevsel testleri güncelleme sonrasında tekrarlayın.
5. Yedek ve geri yükleme
WordPress gibi dinamik sitelerde dosyalar ve veritabanı birlikte korunmalıdır. Yedek alınması, geri yüklemenin çalışacağı anlamına gelmez. Farklı bir yerde güvenli saklama ve belirli aralıklarla gerçek geri yükleme denemeleri planın parçası olmalıdır.
- Dosya ve veritabanı yedeklerini eşleyin.
- Yedek erişimlerini sınırlandırın.
- Test ortamında geri yükleme yapın.
6. Log ve olay müdahalesi
Şüpheli istekleri, başarısız girişleri ve dosya değişikliklerini inceleyebilmek için uygun günlükler gerekir. Gerçek bir olayda hangi hesapların sınırlandırılacağı ve kimin bilgilendirileceği önceden yazılmalıdır. Hata çözmek için güvenlik kurallarını topluca kapatmak veya dosya izinlerini herkese açmak tehlikelidir.
- Olay sorumlusunu belirleyin.
- Önemli günlükleri erişim kontrollü saklayın.
- 403 gibi hatalarda önce nedeni araştırın.
7. Önce neyi koruyorsunuz? Basit risk matrisi
Her site aynı riski taşımaz. Yalnızca yazı yayımlayan bir blog ile müşteri hesabı ve sipariş barındıran mağazanın kritik varlıkları farklıdır. Başlangıçta alan adı sahipliği, yönetici hesapları, içerikler, müşteri verisi ve yedeklerin hangisinin kaybının işinizi durduracağını belirleyin.
| Varlık | Örnek risk | İlk koruma adımı |
|---|---|---|
| Alan adı / DNS | Hesap erişimi kaybı | MFA, sahiplik ve kurtarma bilgisi |
| WordPress yönetimi | Yetkisiz içerik değişimi | Benzersiz hesaplar, en az yetki |
| Dosyalar ve veritabanı | Silinme veya bozulma | Ayrı ortamda yedek ve geri yükleme testi |
| Form ve müşteri bilgisi | Gereksiz veri birikimi | Veri azaltma, yetki ve saklama kontrolü |
| Site sürekliliği | Güncelleme sonrası kesinti | Test ortamı, izleme, geri dönüş planı |
8. Yedek alındı mı, yoksa geri de dönebiliyor musunuz?
“Otomatik yedek açık” ifadesi tek başına güvence sağlamaz. WordPress kurulumu hem dosyalardan hem de veritabanından oluşur. Aynı tarihe ait iki parça, gerektiğinde temiz bir test ortamında birlikte geri yüklenebilmelidir. Yedeğin tek kopyası aynı sunucuda bulunursa sunucunun kaybı yedeği de etkileyebilir.
- İçerik değişme sıklığına göre yedekleme aralığı belirleyin.
- Yedeklerin erişim izinlerini ve saklandığı konumu kaydedin.
- Ana siteyi etkilemeyecek ayrı bir alanda geri yükleme denemesi yapın.
- Geri dönen sitede kullanıcı girişi, önemli sayfalar ve formları kontrol edin.
- Test tarihi ve sonucu için kısa bir kayıt tutun.
Özellikle form veya müşteri verisi içeren yedeklerin erişim kontrolü, saklanma süresi ve güvenli silinmesi ayrıca değerlendirilmelidir.
9. WordPress güncelleme karar tablosu
| İşlem | Öncesinde | Sonrasında |
|---|---|---|
| Çekirdek sürüm güncellemesi | Yedek ve uyumluluk kontrolü | Yönetici girişi, sayfalar, kalıcı bağlantılar |
| Eklenti / tema güncellemesi | Değişiklik notu ve test ortamı | Formlar, mobil menü, kritik akışlar |
| Yönetici yetkisi değişimi | Mevcut rol ve sahiplik listesi | Gereksiz erişim kalmadığı kontrolü |
| DNS veya hosting değişimi | Geri dönüş planı ve kayıt yedeği | HTTPS, e-posta, site ulaşılabilirliği |
Güncellemeleri süresiz ertelemek de, canlı mağazada kontrolsüz toplu değişiklik yapmak da risk yaratır. Kritik güvenlik düzeltmelerine öncelik vererek değişikliği mümkünse aşamalı ve izlenebilir uygulayın.
10. Şüpheli etkinlik görürseniz ilk kararlar
Tanımadığınız yönetici hesabı, beklenmedik dosya değişikliği veya normal dışı yönlendirme fark ettiğinizde önce durumu ve saatini kaydedin. Şüpheli hesabın erişimini yetkili kişilerce sınırlandırın, bilinen temiz bir cihazdan hesap oturumlarını ve kurtarma seçeneklerini kontrol edin. Siteyi rastgele eklenti silerek değiştirmek, araştırma için gerekli kanıtları yok edebilir.
- Öncelik: Yetkisiz erişimin ve veri kaybının devam etmesini engellemek.
- İnceleme: Hosting günlükleri, kullanıcı değişiklikleri ve yakın tarihli yüklemeler.
- Toparlanma: Yetkili uzman incelemesi, temiz yedekten kontrollü dönüş ve parola yenileme.
- Takip: Etkilenen hizmetleri ve gerekli bildirimleri sorumlu kişilerin değerlendirmesi.
Veri ihlali veya hukuki bildirim yükümlülükleri olayın niteliğine ve yürürlükteki kurallara bağlıdır; bunlar için uzman görüşü alın.
11. Aylık güvenlik bakım kontrol listesi
- Alan adı, barındırma ve yönetim hesaplarının sahipliği güncel mi?
- Tüm ayrıcalıklı hesaplarda güçlü kimlik doğrulama kullanılıyor mu?
- Gereksiz kullanıcı, eklenti ve temalar gözden geçirildi mi?
- Güncellemeler ve kritik yamalar takip edildi mi?
- Dosya ve veritabanı yedeğiyle geri yükleme testi planlı mı?
- HTTPS, site izleme ve form akışları çalışıyor mu?
- Beklenmedik değişiklikler için olay sorumlusu belli mi?
Bu liste tek başına bir güvenlik sertifikası değildir; gelişmiş ihtiyaçlar için OWASP ASVS gibi doğrulama kaynaklarına göre ayrı değerlendirme yapılabilir.
Sık sorulan sorular
SSL sertifikası siteyi tamamen güvenli kılar mı?
Hayır. HTTPS iletişimi korumaya yardımcı olur; hesap ve uygulama güvenliği ayrıca yönetilmelidir.
Yedek varsa güvenlik tamam mıdır?
Hayır. Yedeklerin güvenli saklanması, güncel olması ve geri yükleme testinden geçmesi gerekir.