Paylaşımlı Hosting’de WordPress Güvenliği

Paylaşımlı Hosting’de WordPress Güvenliğini Nereye Koymalısınız?

WordPress sitenizi paylaşımlı hosting üzerinde çalıştırıyorsanız, performans kadar güvenliği de aynı ciddiyetle ele almanız gerekiyor. Paylaşımlı bir sunucuda birden fazla site aynı kaynakları ve çoğu zaman benzer yazılım yığınını paylaşır. Yanlış yapılandırılmış bir eklenti, zayıf bir parola veya güncellenmemiş bir tema sitenizi riske atabilir; ihlalin diğer hesaplara yayılma riski ise sunucudaki hesap izolasyonuna ve erişim izinlerine bağlıdır.

Altyapı güvenliği (işletim sistemi güncellemeleri, sunucu güvenlik duvarı, WAF kuralları gibi) ile WordPress içindeki uygulama güvenliğinin sorumluluklarını ayırın. Seçtiğiniz planda sağlayıcının üstlendiği işleri netleştirin; WordPress güncellemeleri, eklentiler ve hesap güvenliği için de sorumluları belirleyin. Bu yüzden eklenti tercihleriniz, WAF (Web Application Firewall) konfigürasyonunuz, 2FA (iki faktörlü kimlik doğrulama) kullanıp kullanmadığınız ve yedekleme stratejiniz doğrudan saldırıya ne kadar dayanıklı olduğunuzu belirliyor.

Bu rehberde, özellikle paylaşımlı hosting ortamını merkeze alarak şu dört başlığı detaylı şekilde ele alacağız: güvenli eklenti seçimi, WAF katmanının doğru kullanımı, 2FA ile yönetici hesaplarınızı sağlamlaştırmak ve gerçek hayatta işe yarayan yedekleme stratejileri. Amacımız, “sitem hacklenmesin” seviyesini geçip, hacklenseniz bile hızlıca ayağa kaldırabileceğiniz bir yapı kurmanıza yardımcı olmak.

Paylaşımlı Hosting’te Tehdit Modeli: Nereden Darbe Yersiniz?

Önce riskleri netleştirelim ki hangi önlemin neden kritik olduğunu daha rahat görebilin. Paylaşımlı hosting ortamında tipik tehdit yüzeyi şu başlıklarla şekillenir:

• Zayıf ya da eski eklentiler: Güvenlik açığı barındıran bir eklenti, saldırganın WordPress sitenize sızmasına yol açabilir.
• Brute-force ve parola tahmin saldırıları: wp-login.php veya XML-RPC üzerinden binlerce kullanıcı/parola denemesi yapılabilir.
• Form ve arama alanlarından gelen kötü niyetli istekler: SQL injection, XSS gibi uygulama katmanı saldırıları, ilgili açıkları taşıyan siteleri hosting türünden bağımsız olarak hedef alabilir.
• Güncellenmeyen çekirdek ve temalar: Bilinen açıkları taşıyan eski WordPress ve tema sürümleri, otomatik tarama yapan botların hedefi olabilir.
• Yanlış dosya izinleri ve zayıf FTP/Panel şifreleri: Hatalı izinler yetkisiz dosya erişimine veya değişikliğine, zayıf şifreler ise hesabın ele geçirilmesine yol açabilir.

Paylaşımlı hosting’te hesap izolasyonu ve kullanıcı başına kaynak limitleri uygulansa bile, “benim sitem küçük, bana bir şey olmaz” yaklaşımı maalesef işlemez. Otomatik botlar sitenize özel bir kin gütmüyor; sadece interneti tarayıp zayıf halkaları buluyor. Bu yüzden yeni açılan web siteleri için güvenlik check-list’inde anlattığımız gibi ilk günden itibaren doğru temelleri atmak kritik.

Eklenti Seçimi: Güvenliğin İlk Zayıf Halkasını Güçlendirmek

WordPress’in önemli avantajlarından biri zengin eklenti ekosistemi; ancak eklentiler güvenlik açısından da risk oluşturabilir. Paylaşımlı hosting ortamında sunucu erişiminiz sınırlı olduğu için yanlış eklenti seçimi sizi gereksiz yere savunmasız bırakabilir.

Çok Eklenti Değil, Doğru Eklenti

“Güvenlik için her şeyi kurayım” yaklaşımı sorun yaratabilir. Aynı işi yapan üç farklı güvenlik eklentisi kurulduğunda:

• Çakışan .htaccess ve WAF kuralları yüzünden siteniz hata verebilir.
• Aynı istek birden fazla eklenti tarafından analiz edildiğinde ek işlem yükü oluşabilir ve siteniz yavaşlayabilir.
• Hangi eklentinin gerçekten işe yaradığını, hangisinin sorun çıkardığını takip etmek zorlaşır.

Yapmanız gereken, rol bazlı bir yaklaşım benimsemek. Aşağıdaki işlevleri mevcut araçlarla karşılanmıyorsa ekleyin; her biri için ayrı eklenti kurmanız gerekmez:

• Bir güvenlik sertleştirme eklentisi (dosya bütünlüğü, temel güvenlik ayarları, giriş denemesi kısıtlama vb.).
• Gerekiyorsa, ek olarak bir login koruma veya firewall eklentisi (özellikle harici WAF yoksa).
• Bir önbellekleme eklentisi (güvenlik değil ama performans ve dolaylı güvenlik için önemli).
• Bir yedekleme eklentisi (paylaşımlı hosting yedeklerine ek katman oluşturmak için).

Eklenti sayısı için sabit bir güvenlik sınırı yoktur; ihtiyaç dışı veya aynı işlevi tekrarlayan eklentiler gereksiz karmaşa yaratabilir. Temel güvenlik ayarlarını nasıl sertleştireceğiniz konusunda, WordPress güvenlik sertleştirme kontrol listesi yazımızı mutlaka gözden geçirmenizi öneririz.

Güvenli Eklenti Seçimi için Kontrol Listesi

Eklenti kurmadan önce şu mini kontrol listesini uygulayın:

• Aktif kurulum sayısı: Yaygın kullanım tek başına güvenlik veya hızlı güncelleme garantisi değildir; güncelleme geçmişini ve bildirilen açıkların nasıl ele alındığını da değerlendirin.
• Son güncelleme tarihi: 1 yıldan uzun süredir güncellenmeyen kritik eklentileri mümkünse kullanmayın.
• Uyumlu WordPress sürümü: Eklentinin, kullandığınız çekirdek sürümü ile uyumlu olduğundan emin olun.
• Geliştirici itibarı: Yalnızca tanınırlığa değil, bakım geçmişine, destek yanıtlarına ve güvenlik bildirimlerini ele alışına bakın.
• Gereksiz erişim talepleri: Basit bir özellik için dosya izinlerini genişletmenizi veya FTP/hosting paneli bilgilerinizi paylaşmanızı isteyen eklentilerin bu talebini sorgulayın.

Ek olarak, güvenlik odaklı eklentilerin log (kayıt) tutma yeteneği çok değerlidir. Bir olay olduğunda geriye dönük hangi IP’den, hangi endpoint’e, ne zaman istek geldiğini inceleyebilmek, hatalardan ders çıkarıp WAF kurallarınızı iyileştirmenize yardımcı olur.

Çakışmaları Önlemek: Hosting ile Eklentinin Rollerini Ayırın

Paylaşımlı hosting planınızda sunucu tarafında WAF veya brute-force koruması bulunup bulunmadığını ve kapsamını öğrenin. Bu korumalar mevcutsa, eklentilerle gereksiz işlev tekrarını azaltmak için örneğin şu rol dağılımını kullanabilirsiniz:

• Sunucu katmanı için olası görevler: WAF kuralları, temel brute-force engelleme, IP kara listeleme, ModSecurity tarzı imza bazlı filtreleme.
• WordPress eklentisi: Yönetici URL gizleme, özel rol bazlı kurallar, 2FA entegrasyonu, dosya bütünlüğü kontrolü.

Böylece gereksiz işlem yükünü azaltabilir ve daha yönetilebilir bir güvenlik mimarisi kurabilirsiniz.

WAF (Web Application Firewall): Paylaşımlı Ortamda Ek Güvenlik Katmanı

WAF, HTTP/HTTPS trafiğini inceleyip zararlı istekleri uygulamaya ulaşmadan önce filtreleyen bir güvenlik katmanıdır. Paylaşımlı hosting ortamında WAF’ı iki seviyede düşünebilirsiniz:

• Sunucu tarafı WAF: Genellikle ModSecurity + OWASP CRS gibi kurallarla Apache/Nginx seviyesinde çalışır.
• CDN veya ters proxy tabanlı WAF: Proxy üzerinden geçen HTTP/HTTPS trafiği önce bu serviste incelenir; kurallarca engellenmeyen istekler origin sunucuya (hosting hesabınıza) yönlendirilir. Yalnızca DNS hizmeti kullanmak, web trafiğinin WAF’tan geçtiği anlamına gelmez.

Sunucu tarafı WAF ile harici bir WAF/CDN servisi birlikte kullanılıyorsa, iki katmanın çakışmadan çalışmasını sağlamak önemlidir. Hangi kuralların nerede uygulandığını ve istisnaları kimin yönetebildiğini netleştirin.

Paylaşımlı Hosting’te WAF Nasıl Devreye Girer?

Paylaşımlı bir sunucuda WAF, etkin kurallarına ve oran sınırlama gibi ek yeteneklerine bağlı olarak şu tip saldırıları hedef alabilir:

• wp-login.php veya XML-RPC üzerinden yapılan brute-force saldırıları,
• Form alanlarında SQL injection, XSS, LFI/RFI gibi girişimler,
• Bilinen güvenlik açıkları olan eklenti ve temaları hedefleyen, saldırı imzalarıyla tanınabilen istekler,
• HTTP/HTTPS üzerinden gelen yoğun ve tekrarlı istek dalgaları (oran sınırlama desteği varsa etkileri azaltılabilir; bu, ağ bağlantısını doyuran hacimsel DDoS saldırılarına karşı tek başına yeterli değildir).

Sunucu tarafında WAF etkinleştirildiğinde, çoğu zaman sizin ekstra bir şey kurmanıza gerek kalmaz. Ancak belli durumlarda istisna tanımlamanız gerekebilir. Örneğin büyük boyutlu JSON POST istekleri alan bir REST endpoint’i veya webhook’larınız varsa ve meşru istekler engelleniyorsa, önce WAF log’larında tetiklenen kuralı ya da limiti belirleyin. Gerekli değişikliği yalnızca ilgili endpoint ve kuralla sınırlayın; paylaşımlı hosting’te bu işlem için sağlayıcının desteği gerekebilir. Bu konuya ModSecurity ve OWASP CRS ile WAF’ı uysallaştırmak yazımızda daha teknik bakış açısıyla değinmiştik.

CDN/WAF ile Sunucu WAF’ını Birlikte Kullanmak

Bir WordPress sitesinde CDN üzerinden sağlanan WAF ile sunucu tarafındaki WAF katmanı birlikte kullanılabilir. CDN üzerinden origin’e iletilen istekler bu katmanlardan sırayla geçer; doğrudan origin’e ulaşan istekler ise CDN WAF’ını atlayabilir. Sağlayıcınızla, origin erişimini CDN’nin güvenilir çıkışları ve gerekli yönetim veya servis bağlantılarıyla sınırlama olanaklarını değerlendirin.

IP tabanlı kontroller için ön koşul: Origin’de giriş denemesi sınırlama, IP erişim kısıtlaması veya IP tabanlı kayıt kullanmadan önce gerçek ziyaretçi adresinin nasıl belirlendiğini sağlayıcınız ve eklenti belgeleriyle doğrulayın. İletilen istemci IP başlıklarını yalnızca açıkça yetkilendirilmiş proxy’lerden kabul edin; doğrudan istemciden veya doğrulanmamış zincir girdilerinden gelen değerlere güvenmeyin. Proxy–origin bağlantısının korunmasını ve izin verilen doğrudan bağlantıların nasıl ele alındığını netleştirin. Aksi halde ziyaretçiler tek proxy adresi altında toplanabilir veya sahte IP değerleri kabul edilebilir. Kontrolleri zorunlu kılmadan önce desteklenen IPv4 ve IPv6 yollarını sunucu ve eklenti kayıtlarında doğrulayın; evrensel bir WordPress ayarı olduğunu varsaymayın. Katmanların görev dağılımında temel prensip şu:

• CDN tarafında, hizmetin desteklediği ölçüde bot filtreleme, DDoS azaltma ve oran sınırlama uygulayın; ülke bazlı kısıtlamaları yalnızca hedef kitleniz ve erişim gereksinimleriniz uygunsa kullanın.
• Sunucu tarafında ise uygulama seviyesinde spesifik kuralları (belirli URL’lere özel filtreler, PHP imzaları, dosya yükleme kısıtları vb.) aktif tutun.

CDN WAF kurallarını WordPress’e özel ayarlamak istiyorsanız, WordPress’i botlardan koruyan WAF kuralları ve oran sınırlama rehberimiz adım adım örnekler içeriyor. Aynı zamanda, CDN, ModSecurity ve Fail2ban’i bir arada kullanmanın mantığını anlamak için WAF ve bot korumasını birlikte kurguladığımız yazımız da işin mimari tarafında size fikir verecektir.

Yanlış Pozitifler: Güvenliğin Kullanılabilirlikle İmtihanı

WAF kurallarını daha agresif hale getirmek, yanlış pozitif ihtimalini artırabilir. Form gönderemeyen kullanıcılar, ödeme sayfasında hata alan müşteriler, API çağrıları engellenen üçüncü taraf servisler… Bunlar yanlış pozitiflerin yol açabileceği sorunlara örnektir.

Sağlıklı bir paylaşımlı hosting/WAF kurulumunda şu pratikleri öneriyoruz:

• Log’ları inceleyin: 403 hatalarının WAF kaynaklı olup olmadığını tespit etmek için erişim ve hata loglarını, varsa WAF olay kayıtlarıyla birlikte kontrol edin.
• Kontrollü izleme: Yanlış pozitif şüphesi olan kuralı, mümkünse önce test ortamında yalnızca kayıt modunda inceleyin; canlıda engellemeyi kaldırmak korumayı azaltır.
• Dar kapsamlı istisnalar: Yanlış pozitif doğrulanırsa yalnızca ilgili kural, URL ve gerekiyorsa parametre için istisna tanımlayın. Ödeme, webhook ve API uçlarını topluca WAF koruması dışında bırakmayın.

Paylaşımlı hosting’te WAF ayarlarına erişiminiz yoksa, yanlış pozitifi gösteren olay zamanı, URL ve varsa kural kimliğiyle sağlayıcınızdan inceleme isteyin.

2FA (İki Faktörlü Kimlik Doğrulama)

WordPress yönetici hesapları, geniş yetkileri nedeniyle saldırganlar için değerli hedeflerdir. Kullanıcı adı tahmin edilebilir (admin, info, test…) ve parola zayıfsa, en sofistike WAF kurulumları bile yeterli olmaz. Burada 2FA devreye girerek kritik bir güvenlik katmanı ekler.

2FA Nedir, WordPress’te Nasıl Çalışır?

2FA, giriş yaparken sadece kullanıcı adı ve parola değil, ikinci bir doğrulama faktörü daha istemesi anlamına gelir. Bu genellikle:

• Mobil uygulama (Google Authenticator, Authy, Microsoft Authenticator vb.) ile üretilen tek kullanımlık kod,
• SMS ile gönderilen doğrulama kodu (SIM değişimi saldırıları nedeniyle daha zayıf bir seçenek); e-posta kodu ise bağımsız bir ikinci faktör sağladığı varsayılmadan değerlendirilmelidir,
• FIDO2 güvenlik anahtarı gibi donanım tabanlı çözümler

şeklinde uygulanır. WordPress tarafında bunu aktif etmek için bir 2FA eklentisi kullanırsınız; yönetici hesaplarında zorunlu tutup diğer roller için aşağıdaki risk temelli politikayı uygulayabilirsiniz.

Hangi Hesaplarda 2FA Zorunlu Olmalı?

Pratikte şu yaklaşımı öneriyoruz:

• Tüm admin kullanıcılar: 2FA kesinlikle zorunlu olmalı.
• Editörler: Sitenin içerik bütünlüğü açısından kritikse 2FA tavsiye edilir.
• Abone/müşteri hesapları: Zorunluluğu, erişilebilen kişisel veriler ve yapılabilen işlemlerin riskine göre belirleyin; düşük riskli hesaplarda isteğe bağlı sunulabilir.

Aynı mantığı sadece WordPress için değil, hosting paneli ve alan adı hesabınız için de uygulamanızı şiddetle öneriyoruz. Çünkü bir saldırgan alan adı panelinize erişirse, DNS kayıtlarını değiştirerek trafiğinizi kendi sunucusuna yönlendirebilir. Bu konuda alan adı güvenliği ve 2FA rehberimizde adım adım ne yapmanız gerektiğini anlattık.

2FA Kullanırken Dikkat Etmeniz Gerekenler

2FA, yanlış kurulduğunda erişim kaybına da yol açabilir. İşin operasyon tarafında şu noktalara dikkat edin:

• Yedek kodlar: 2FA eklentinizin ürettiği yedek kurtarma kodlarını güvenli bir yerde saklayın.
• Kurtarma süreci: Cihaz kaybında kullanılacak yöntemi önceden belirleyin. İkinci bir yönetici gerekiyorsa hesabını da 2FA ile koruyun; sıfırlama yetkisini eklenti belgelerinden doğrulayın ve hesap sahibinin kimliğini doğrulamadan 2FA’yı kaldırmayın.
• Cihaz değişim süreci: Telefon değiştirirken 2FA hesaplarını yeni cihaza aktarmayı unutmayın.
• Koruma kapsamı: Seçtiğiniz çözümün hangi giriş yollarını koruduğunu belgelerinden doğrulayın. XML-RPC, uygulama parolaları ve diğer entegrasyonların tarayıcı girişindeki 2FA ile korunduğunu varsaymayın; kullanılmayan erişimleri kapatın, gerekli olanların yetkilerini sınırlayın.

Paylaşımlı hosting kullanıyor olmanız 2FA ihtiyacını azaltmaz; hesapların yetkileri ve ele geçirilmelerinin doğuracağı zarar, giriş güvenliği politikasını belirlemelidir.

Yedekleme Stratejileri: Hacklenseniz Bile Panik Yapmamak

Yedekleme, güvenliğin kurtarma katmanıdır. En iyi WAF, en sıkı 2FA, en temiz eklenti seçimi bile %100 güvenlik garantisi vermez. Bir ihlal yaşanırsa, ihlal öncesine ait temiz ve geri yüklemesi test edilmiş bir yedek kurtarmayı kolaylaştırır; yeniden yayına geçmeden önce ihlalin nedeni de giderilmelidir.

İhlalde olay müdahale planınızı uygulayın: erişimi kontrol altına alın, inceleme için kayıtları koruyun ve güvenilir bir cihazdan yönetici ve hosting erişim bilgilerini yenileyin. Sağlayıcınızdan destek kapsamı dahilinde kayıt incelemesi isteyin. Temiz yedeği önce aşağıda açıklanan, canlıdan ayrı ve erişimi kısıtlı test ortamında sınayın.

3-2-1 Kuralı: Paylaşımlı Hosting’e Nasıl Uyar?

Klasik 3-2-1 yedekleme stratejisi şunu söyler:

• 3 kopya: Verinin en az üç kopyası olsun (biri canlı, ikisi yedek).
• 2 farklı ortam: Bu kopyalar en az iki farklı depolama türünde bulunsun (örneğin disk ve teyp); yalnızca farklı bir sunucuya kopyalamak, depolama türünün farklı olduğunu göstermez.
• 1 off-site: En az bir kopya fiziksel olarak farklı bir lokasyonda tutulsun.

Paylaşımlı hosting’te bu stratejiyi şöyle uyarlayabilirsiniz:

• Katman 1: Seçilen planda sunuluyorsa sağlayıcı tarafından alınan otomatik yedekler; sıklık, kapsam ve saklama süresi doğrulanmalıdır.
• Katman 2: WordPress içinden alınan eklenti tabanlı yedekler (tam kurtarma için dosyalar + veritabanı; ek ara kopyalar için yalnızca veritabanı).
• Katman 3: cPanel üzerinden indirdiğiniz tam hesap yedeği veya harici bir depoya (S3 uyumlu, bulut, lokal NAS) senkronize ettiğiniz arşivler.

Bu yöntemler tek başına 3-2-1 koşullarını garanti etmez: canlı veri dahil üç kopyanın, iki depolama türünün ve ayrı fiziksel konumdaki kopyanın gerçekten bulunduğunu doğrulayın. Aynı hosting hesabındaki yedekler off-site sayılmaz.

Bu yaklaşımı detaylarıyla anlattığımız 3-2-1 yedekleme stratejisi rehberimiz, sadece WordPress için değil tüm web projeleriniz için uygulanabilir bir çerçeve sunuyor.

Paylaşımlı Hosting’te Otomatik Yedekler ve WordPress Eklentileri

Paylaşımlı hosting planınızı seçerken otomatik yedeklemenin dahil olup olmadığını doğrulayın. Sunuluyorsa yedeklerin ne sıklıkla ve hangi kapsamda alındığını mutlaka öğrenmelisiniz:

• Sadece dosyalar mı yedekleniyor, yoksa veritabanı da dahil mi?
• Günlük mü, haftalık mı, aylık mı?
• Kaç versiyon geriye gidebiliyorsunuz? (örneğin son 7 gün, son 14 gün)

Buna ek olarak, WordPress içinden çalışan bir yedekleme eklentisi ile veritabanını daha sık (örneğin günde 1–4 kez) yedekleyip, bu yedekleri hosting hesabınızın dışında bir depoya gönderebilirsiniz. Sıklığı, kabul edebileceğiniz veri kaybı süresine ve içerik veya sipariş akışına göre belirleyin; bu örnek takvim yoğun sipariş alan bir site için yetersiz kalabilir. Dosyalar için de değişim sıklığına uygun bir takvim oluşturun ve geçmiş temiz kopyalara dönebilmek için saklama süresini belirleyin. Harici depoda ayrı erişim bilgileri kullanın, erişimi sınırlandırın ve yedekleri aktarımda ve depolamada şifreleyin. Arşivleri public_html gibi web üzerinden erişilebilen dizinlerde bırakmayın; web kökü dışında veya özel, erişim kontrollü harici depoda saklayın. Böylece hosting hesabı dışında bir ek kopya elde edersiniz; sağlayıcı yedekleri de mevcutsa bu kopya onları tamamlar.

Bu konuyu, örnek senaryolar ve geri yükleme adımları ile anlattığımız WordPress yedekleme stratejileri yazımızı da okursanız, burada özetlediğimiz mimari kafanızda tamamen oturacaktır.

cPanel Üzerinden Tam Hesap Yedeği Almak

Paylaşımlı hosting kullanırken elinizde bir de panel bazlı tam hesap yedeği olması, kurtarma seçeneklerinizi artırır. Ancak cPanel’in standart kullanıcı arayüzü, Full Backup arşivini doğrudan tam hesap olarak geri yükleyemez; bu işlem için WHM’de gerekli yetki veya hosting sağlayıcısının desteği gerekir. Sağlayıcınızla geri yükleme koşullarını, varsa ücretini ve ayrı bir test hesabına kurtarma olanağını önceden netleştirin. WordPress dosyalarını ve veritabanını ayrı geri yüklemek, sitenin çalışmasını sınamak için bir alternatiftir; tam hesap kurtarma testiyle aynı şey değildir. Arşiv oluşturmak için yeterli kota bulunduğunu da kontrol edin; kotasına yaklaşmış veya kotasını aşmış hesaplarda yedekleme başarısız olabilir. cPanel için tipik yedek alma adımları şunlardır:

1. cPanel’e güvenli HTTPS bağlantısıyla giriş yapın.
2. Yedekleme / Backup bölümüne girip tam yedek (Full Backup) oluşturmayı seçin.
3. Hedef seçenekleri Home Directory, Remote FTP Server, pasif modda Remote FTP Server ve Secure Copy (SCP) olarak belgelenmiştir; kurulumunuzda hangilerinin kullanılabildiğini kontrol edin. SCP, SFTP ile aynı seçenek değildir. Standart FTP, pasif modda da kimlik bilgilerini ve verileri şifrelemez; tam hesap yedeği için Home Directory üzerinden güvenli indirmeyi veya destekleniyorsa SSH üzerinden şifreli aktarım sağlayan SCP’yi tercih edin.
4. Home Directory seçtiyseniz: Yedekleme tamamlandığında Backups Available for Download listesindeki arşivi HTTPS panel bağlantısı üzerinden bilgisayarınıza indirin. SCP seçtiyseniz: Uzak hedefin gerekli bağlantı ve erişim bilgilerini girin; işlem sonunda arşivin hedefe ulaştığını kontrol edin.

cPanel üzerinden tam yedek alma ve geri yükleme adımlarını anlattığımız cPanel’de tüm siteyi yedekleme rehberimiz, bu süreci adım adım takip edebilmeniz için hazırlanmış durumda.

Yedeğin Gerçek Değeri: Geri Yükleme Testleri

Henüz test edilmemiş bir yedek, aslında sadece iyi niyetli bir varsayımdır. Şu kontrolleri düzenli olarak yapmanızı tavsiye ederiz:

• WordPress’i staging ortamında geri yükleme: Site dosyalarını ve veritabanını doğrudan canlıya değil, erişimi kısıtlanmış ayrı bir test ortamına geri yükleyin. Canlıdan ayrı dosyalar ve veritabanı kullanın; test kopyasının bağlantı ayarlarını ve adreslerini bu ortama uyarlayın. Gerçek ödeme, e-posta ve webhook gönderimlerini devre dışı bırakın. Yönetici girişini, içerikleri, medya dosyalarını ve kritik iş akışlarını kontrol edin.
• cPanel tam hesap kurtarma testi: Full Backup arşivini standart cPanel arayüzünden tek adımda geri yüklemeyi planlamayın. WHM yetkisine sahip yönetici veya sağlayıcıyla, canlı hesabı etkilemeyecek ayrı bir hedefte deneme planlayın. Sağlayıcı bu olanağı sunmuyorsa tam hesap kurtarmasının test edildiğini varsaymayın. Arşivdeki WordPress dosyalarını ve veritabanını ayrı geri yüklemek yalnızca site düzeyindeki kurtarmayı sınar; e-posta ve diğer hesap bileşenlerinin kurtarıldığını göstermez.
• En azından veritabanı testi: Veritabanı yedeğini boş bir test veritabanına geri yükleyip hata almadığınızdan emin olun; bu kontrol tek başına sitenin tamamen kurtarılabildiğini kanıtlamaz.
• Periyodik kontrol: En azından 3–6 ayda bir ve önemli altyapı veya yedekleme değişikliklerinden sonra tam WordPress geri yükleme simülasyonu yapın. Tam hesap yedeğine de güveniyorsanız, sağlayıcıyla bu kurtarma yolunun test sıklığını ayrıca belirleyin.

Bu testler, hack veya veri kaybı anında geri yükleme adımlarını ve ihtiyaç duyulacak süreyi önceden değerlendirmenizi sağlar; sitenin dakikalar içinde döneceğini garanti etmez.

Operasyonel Güvenlik: Güncellemeler, Şifreler ve Staging Ortamı

Güvenliğin önemli bir kısmı teknolojiden değil, operasyon alışkanlıklarınızdan gelir. Paylaşımlı hosting kullanan WordPress sitelerinde özellikle şu üç başlık belirleyici oluyor: güncellemeler, erişim yönetimi ve staging (test) ortamı.

Güncellemeleri Yönetmek: Otomatik mi, Kontrollü mü?

WordPress çekirdeği, güvenlik güncellemelerini çoğu zaman otomatik olarak uygular. Ancak büyük sürüm güncellemeleri ve eklenti/tema güncellemeleri için stratejinizi belirlemeniz gerekiyor:

• Güvenlik güncellemeleri: Çekirdekte otomatik güncellemelerin etkinliğini ve başarıyla tamamlandığını kontrol edin. Eklenti ve temaların güvenlik duyurularını izleyin; kritik veya aktif istismar edilen açıkların yamalarını haftalık kontrolü beklemeden, yedek ve hızlı işlev testiyle uygulayın.
• Büyük versiyon atlamaları: Önce staging ortamında test edin, ardından canlıya alın.
• WooCommerce ve kritik eklentiler: Özellikle ödeme alan eklentiler için, güncellemeleri güvenle yapma rehberimizde anlattığımız kontrollü akışı takip edin.

Güncelleme yönetiminde temel hedef, güvenlik açıklarını kapatırken, sitenin işlevselliğini bozmamak. Bu dengeyi sağlamak için, özellikle kritik eklentilerde ve büyük sürüm geçişlerinde staging ortamında test yapmak yararlıdır.

Staging Ortamı Kurmak: Canlıyı Bozmadan Deneme Yapmak

Staging, sitenizin birebir kopyasını (dosyalar + veritabanı) ayrı bir alan adı veya alt alan adı altında barındırdığınız test ortamıdır. Burada:

• Yeni tema ve tasarım denemeleri,
• Çekirdek, eklenti ve tema güncellemeleri,
• WAF kural değişiklikleri,
• PHP sürüm yükseltmeleri

gibi riskli işleri ilk önce test edersiniz. cPanel üzerinde staging kurulumunu ve WordPress’i alt alan adında klonlama adımlarını WordPress staging ortamı rehberimizde detaylandırdık. Test kopyasını ayrı bir veritabanına bağlayın, erişimini sınırlandırın ve kişisel verileri mümkün olduğunca anonimleştirin. Gerçek ödeme, e-posta ve webhook işlemlerini devre dışı bırakın veya test uçlarına yönlendirin. WAF ve PHP değişikliklerinin yalnızca test ortamına uygulandığından emin olun; aynı hosting hesabındaki canlı siteleri etkileyen ortak ayarları staging’e özel sanmayın.

Şifre Yönetimi ve Erişim Politikaları

Şifre ve erişim yönetimi için temel kurallar şunlardır:

• Tahmin edilebilir kullanıcı adlarına güvenmeyin: Yeni yönetici hesaplarında “admin” gibi yaygın adlardan kaçınabilirsiniz; ancak kullanıcı adını gizlemek veya değiştirmek güçlü parola ve 2FA’nın yerini tutmaz.
• Güçlü parola zorunlu kılın: WordPress ve cPanel hesaplarında uzun, benzersiz parolalar kullanın; bunları parola yöneticisinde saklayın. Kullanılan araçların desteklediği parola politikalarını ve bunları uygulamak için gereken yetkileri doğrulayın.
• Gereksiz hesapları kapatın: Eski çalışan, ajans veya freelance geliştirici hesaplarını yetkileriyle birlikte kaldırın.
• Şifreli dosya aktarımı kullanın: Planınız destekliyorsa SFTP/SSH kullanın; mümkünse şifre yerine SSH anahtarıyla oturum açın. Desteklenmiyorsa sağlayıcınızdan FTPS veya HTTPS panel aktarımı gibi şifreli seçenekleri öğrenin; standart FTP’yi şifreli aktarım sanmayın.

Paylaşımlı hosting’te aynı kullanıcı hesabı altında birden çok site barındırıyorsanız, her proje için ayrı WordPress yönetici hesapları ve benzersiz parolalar kullanın. Bu, aynı parolanın başka sitelerde denenmesi riskini azaltır; ancak aynı hosting hesabındaki siteler arasında dosya veya veritabanı erişimi bakımından izolasyon sağlamaz. Bir sitenin ele geçirilmesinin diğerlerini etkileyip etkilemeyeceği, hesap izolasyonuna ve erişim izinlerine de bağlıdır.

DCHost Perspektifinden Özet ve Yol Haritası

Paylaşımlı hosting üzerinde WordPress çalıştırmak, doğru kurgulandığında hem maliyet-etkin hem de güvenli bir çözüm olabilir. Bunun için güvenliği üç katmanda düşünmenizi öneriyoruz:

• Altyapı katmanı (hosting sağlayıcısı): Sunucu güvenliği, WAF kapsamı, işletim sistemi ve PHP güncellemelerinin sorumluluğu ile otomatik yedeklerin sıklığı, saklama süresi ve geri yükleme koşulları, plan seçerken doğrulanması gereken başlıklardır.
• Uygulama katmanı (WordPress): Güvenli eklenti seçimi, 2FA, doğru dosya izinleri, güncellemelerin düzenli ve kontrollü yapılması.
• Operasyon katmanı (siz ve ekibiniz): Şifre politikaları, yedek testleri, staging kullanımı, log takibi ve olay müdahale planı.

Bu yazıda özellikle dört başlığa odaklandık: eklenti seçimiyle güvenlik açığı yüzeyini daraltmak, WAF ile istekleri filtrelemek, 2FA ile yönetici hesaplarınızı sağlamlaştırmak ve 3-2-1 prensibine uygun yedekleme stratejileri kurmak. Eğer siteniz büyüyor, trafiğiniz artıyor ve güvenlik ihtiyacınız paylaşımlı hosting sınırlarını zorluyorsa, paylaşımlı hosting’den VPS’e sorunsuz geçiş rehberimize de göz atarak geçişi planlayabilirsiniz. VPS tek başına güvenlik artışı sağlamaz; sunucu yönetimi, güncellemeler ve yedekleme sorumluluklarının kimde olacağını da belirleyin.

Mevcut paylaşımlı hosting planınızı değerlendirirken WAF kapsamını, yedeklerin geri yüklenebilirliğini ve destek hizmetinin sınırlarını netleştirin; daha güvenli bir mimari gerekiyorsa bu gereksinimlere göre geçiş planı hazırlayın. Güvenlikte hedef, sıfır risk değil; riski kabul edilebilir seviyede tutup, sorun yaşandığında hızla ayağa kalkabilecek bir yapı kurmaktır.