Web sitesi güvenliği ve bakımı: hacklenmeden önce ve sonra yapılacaklar

Sabah bir müşteriniz arıyor: “Sitenize girince bir bahis sitesine yönlendiriliyorum.” Ya da Google'da şirketinizin adını aratıyorsunuz ve sonucun altında sitenin saldırıya uğramış olabileceğine dair bir uyarı görüyorsunuz. Siteyi yapan firmaya ulaşmaya çalışıyorsunuz; proje iki yıl önce teslim edilmiş, o günden beri kimse panele girmemiş.

Bu yazı o sabahı yaşamamak ve yaşarsanız ne yapacağınızı bilmek için. Sitelerin neden hacklendiğini, WordPress özelinde alınacak önlemleri, güncelleme ve yedekleme politikasını, erişim ve altyapı ayarlarını, izlemeyi, hack sonrası adımları ve kişisel veri ihlalinde bildirim yükümlülüğünü anlatıyoruz. Sonunda bir bakım sözleşmesinde mutlaka yazılı olması gerekenleri bir tabloda topladık.

Siteler neden hacklenir?

İşletme sahiplerinin çoğu “bizim sitemizde çalınacak ne var ki” diye düşünür. Sorun şu ki saldırganların çoğu sizi seçmiyor. Otomatik araçlar internetteki siteleri sürekli tarar, bilinen bir açığı olan eklenti ya da tema sürümünü bulduğu yerde içeri girer. Sitenizin büyüklüğü, sektörünüz ya da trafiğiniz bu taramalar için önemsizdir.

İçeri girdikten sonra hedef çoğu zaman verileriniz bile değildir. Site, spam sayfaları yayımlamak, ziyaretçileri dolandırıcı sitelere yönlendirmek, oltalama sayfası barındırmak ya da başka sitelere saldırmak için bir araç olarak kullanılır. Siz bunu çoğu zaman Google uyarı gösterdiğinde ya da bir müşteri şikâyet ettiğinde fark edersiniz.

Sahada en sık gördüğümüz giriş yolları şunlar:

• Güncellenmemiş eklenti ve temalar. Açık yayımlandıktan sonra güncelleme çıkar; o güncellemeyi kurmayan siteler aylarca açık kalır.
• Terk edilmiş eklentiler. Geliştiricisi bırakmış, yıllardır güncellenmeyen eklenti bir gün açık verdiğinde düzeltme hiç gelmez. WordPress.org eklenti dizininde güvenlik gerekçesiyle kapatılan eklentilerin sayfasında “This plugin has been closed… Reason: Security Issue” uyarısı çıkar; kullandığınız eklentilerin sayfasına arada bir bakın.
• Korsan (“nulled”) temalar ve eklentiler. Ücretli bir temanın lisanssız kopyası çoğu zaman içine gizlenmiş bir arka kapıyla gelir. WordPress'in kendi güvenlik belgeleri de açıkça söyler: güvenilmeyen kaynaktan eklenti ya da tema kurmayın.
• Zayıf ya da başka yerde de kullanılan şifreler. Başka bir sitede sızan e-posta ve şifre ikilileri, otomatik araçlarla binlerce yönetim panelinde denenir.
• Yanlış yapılandırma: herkese açık bırakılmış yedek dosyaları, dizin listeleme, gereğinden geniş dosya izinleri, unutulmuş test kurulumları.

Web uygulaması güvenliğinin başvuru listesi sayılan OWASP Top 10'un 2025 sürümünde ilk üç sırada bozuk erişim kontrolü, güvenlik yapılandırma hataları ve yazılım tedarik zinciri hataları var. Bu son başlık, eski “güncel olmayan bileşenler” maddesini genişletiyor ve küçük bir şirket sitesi için anlamı basit: kullandığınız her eklenti, tema ve kütüphane sizin güvenlik yüzeyinizdir.

E-ticaret sitelerinde bir ayrıntı daha var. Kart bilgileri iyzico, PayTR gibi ödeme kuruluşunun kendi sayfasında ya da çerçevesinde alınıyorsa kart verisi sizin sunucunuza hiç uğramaz. Bu yükünüzü azaltır ama sıfırlamaz: ele geçirilmiş bir site, müşteriyi ödeme adımından önce sahte bir ödeme sayfasına da yönlendirebilir.

WordPress'te temel önlemler

WordPress, kurumsal sitelerde en sık karşılaştığımız sistem ve kendi başına güvensiz değil. Sorunların büyük kısmı çekirdekten değil, üzerine eklenenlerden ve bakımsızlıktan çıkar. Temel önlemler şunlar:

• Eklenti sayısını azaltın. Her eklenti ayrı bir kod tabanı, ayrı bir geliştirici ve ayrı bir güncelleme takvimi demek. Kullanmadığınız eklentiyi devre dışı bırakmakla yetinmeyin, silin.
• Eklentiyi yalnızca WordPress.org dizininden ya da tanınmış geliştiricilerden alın; son güncelleme tarihine ve WordPress sürümünüzle test edilip edilmediğine bakın.
• wp-config.php dosyasına define( 'DISALLOW_FILE_EDIT', true ); satırını ekleyin. Bu, panelden tema ve eklenti dosyalarının düzenlenmesini kapatır; ele geçirilmiş bir yönetici hesabıyla koda doğrudan zararlı satır eklemek zorlaşır.
• “admin” gibi tahmin edilebilir kullanıcı adları kullanmayın; tüm yönetici hesaplarında iki adımlı doğrulamayı açın.
• Giriş denemelerini sınırlayın. Bunu bir güvenlik eklentisiyle ya da sunucu önündeki güvenlik duvarında yapabilirsiniz.
• Dosya izinlerini daraltın. WordPress belgeleri wp-config.php için yalnızca sizin ve web sunucusunun okuyabileceği izinleri (genellikle 400 ya da 440) önerir.
• Araçlar > Site Sağlığı ekranını düzenli kontrol edin; eski PHP sürümü, devre dışı otomatik güncellemeler gibi sorunları burada görürsünüz.

Güncelleme politikası ve test ortamı

“Güncellemeleri yapıyoruz” bir politika değildir. Politika, neyin ne zaman, kim tarafından ve nasıl güncelleneceğini yazar.

WordPress 3.7'den beri küçük bakım ve güvenlik sürümleri varsayılan olarak otomatik kurulur; 5.5 sürümünden beri de Eklentiler ekranında her eklenti ve tema için otomatik güncellemeyi ayrı ayrı açabilirsiniz. Bu özellik varsayılan olarak kapalıdır. Hangisini otomatiğe bırakacağınız sitenin ne kadar özel kod barındırdığına bağlıdır.

Bizim önerdiğimiz düzen şöyle:

1. Güvenlik güncellemelerini öncelikli sınıfa koyun. Kullandığınız bir eklentide açık duyurulduğunda, güncelleme günler içinde, ciddi açıklarda aynı gün kurulmalı.
2. Diğer eklenti ve tema güncellemelerini toplu ve düzenli yapın, örneğin haftada ya da iki haftada bir.
3. Büyük sürümleri (WordPress'in ana sürümleri, sayfa oluşturucu ya da e-ticaret eklentisinin büyük güncellemeleri) önce bir test ortamında deneyin.
4. Her güncellemeden önce yedek alın ve geri dönüş yolunu bilin.
5. Güncellemeden sonra ana sayfayı, formları, ödeme akışını ve üye girişini kontrol edin.

Test ortamı (staging), canlı sitenin bir kopyasıdır ve arama motorlarına kapalı, şifreyle korunur. Birçok barındırma firması tek tıkla kurulum sunar. Test ortamı yoksa güncelleme ya hiç yapılmaz ya da canlı sitede kör dövüş olur; ikisi de kötü.

Yedekleme: 3-2-1 kuralı ve geri yükleme testi

Yedek, ancak geri yüklenebildiğinde yedektir. En sık karşılaştığımız tablo, yedek alındığına inanılan ama hiç denenmemiş bir düzen ve kötü günde yedeğin eksik ya da bozuk çıkması.

3-2-1 kuralı şunu söyler: verinin en az üç kopyası olsun, bunlar en az iki farklı ortamda dursun ve en az biri başka bir yerde, sunucunuzdan ayrı tutulsun. Web sitesi için pratik karşılığı şöyle:

• Barındırma firmasının günlük yedeği birinci katmandır, ama tek başına yetmez; sunucu ya da hesap ele geçirildiğinde yedek de aynı yerdedir.
• İkinci kopya başka bir sağlayıcıda, örneğin ayrı bir bulut depolama hesabında durmalı ve bu hesabın şifresi site şifrelerinden farklı olmalı.
• Fidye yazılımlarına karşı kopyalardan biri değiştirilemez ya da çevrim dışı olmalı; saldırgan önce ulaşabildiği yedekleri siler.
• Yedek hem dosyaları hem veritabanını kapsamalı. Yalnızca veritabanı yedeği, yüklenen görsel ve belgeleri kurtarmaz.
• Saklama süresini düşünün: bir hack bazen haftalar sonra fark edilir. Yalnızca son yedi günü tutuyorsanız elinizdeki bütün yedekler zaten virüslü olabilir.

En önemli madde geri yükleme testidir. Üç ayda bir, yedeği test ortamına geri yükleyin ve sitenin çalıştığını görün. Bu testte iki şeyi öğrenirsiniz: yedeğin sağlam olup olmadığını ve geri yüklemenin ne kadar sürdüğünü. İkincisi, kötü günde müşterilerinize ne söyleyeceğinizi belirler.

Erişim ve altyapı

İki adımlı doğrulama ve en az yetki

Sitenizin anahtarları yalnızca WordPress panelinde değildir. Alan adı kayıt firması, DNS yönetimi, barındırma paneli, e-posta, Google Search Console ve Analytics hesaplarının her biri siteyi ele geçirmek için kullanılabilir. Hepsinde iki adımlı doğrulamayı açın; SMS yerine doğrulama uygulaması ya da donanım anahtarı daha güvenlidir. Alan adınızda transfer kilidinin açık olduğundan emin olun.

En az yetki ilkesi basittir: herkes yalnızca işini yapmaya yetecek yetkiye sahip olsun. Blog yazısı giren birine yönetici değil editör ya da yazar rolü yeter. Ortak kullanılan tek bir “firma” hesabı yerine herkesin kendi hesabı olsun ki kimin ne yaptığı görülebilsin. İşten ayrılan çalışanların ve çalışmayı bıraktığınız ajansların hesaplarını aynı gün kapatın; devraldığımız sitelerde sık rastladığımız bir açık, yıllar önce ayrılmış birinin hâlâ çalışan yönetici hesabıdır.

HTTPS ve HSTS

HTTPS artık tartışma konusu değil; sertifika çoğu barındırma paketinde hazır geliyor ve tarayıcılar HTTP sayfalarında form doldurana uyarı gösteriyor. Önemli olan sertifikanın otomatik yenilenmesi ve tüm sayfaların, görsellerin ve betiklerin HTTPS üzerinden yüklenmesidir.

HSTS (HTTP Strict Transport Security) başlığı, tarayıcıya sitenize bundan sonra yalnızca HTTPS ile bağlanmasını söyler. Tarayıcıların ön yükleme listesine (HSTS preload) girmek isterseniz başlıkta en az bir yıllık (31536000 saniye) max-age, includeSubDomains ve preload yönergelerinin bulunması gerekir. Dikkat: bu listeden çıkmak aylar sürer ve tüm alt alan adlarınızın HTTPS desteklemesi şarttır. Unutulmuş, sertifikasız bir alt alan adı erişilemez hâle gelir.

WAF, CDN ve barındırma yalıtımı

Web uygulaması güvenlik duvarı (WAF), bilinen saldırı kalıplarını sunucunuza ulaşmadan engeller. Cloudflare gibi bir CDN ve güvenlik katmanı, Sucuri gibi hizmetler ya da sunucudaki ModSecurity bu işi görebilir. WAF, güncellemenin yerine geçmez; açığa güncelleme gelene kadar zaman kazandırır.

Barındırma tarafında en sık hata, birden fazla siteyi aynı kullanıcı hesabı altında çalıştırmaktır. Unutulmuş bir kampanya sitesi hacklendiğinde aynı hesaptaki ana siteniz de etkilenir. Her site kendi sistem kullanıcısıyla, yalıtılmış biçimde çalışmalı. FTP yerine SFTP ya da SSH anahtarı kullanın, PHP'nin hâlâ desteklenen bir sürümünde kalın.

İzleme: sorunu müşteriden önce görmek

İzleme yoksa sorunu müşteriniz, Google ya da saldırgan size haber verir. Kurulması gereken asgari izleme şunlardır:

• Çalışma süresi izleme: site birkaç dakikadan uzun süre yanıt vermezse e-posta ya da mesajla uyarı.
• Dosya bütünlüğü: çekirdek ve eklenti dosyalarının resmî sürümlerle karşılaştırılması. Bunu güvenlik eklentileriyle ya da WP-CLI'daki wp core verify-checksums ve wp plugin verify-checksums komutlarıyla yapabilirsiniz.
• Google Search Console'daki Güvenlik sorunları raporu: Google sitenizde zararlı yazılım, kod ya da içerik yerleştirme gibi bir sorun tespit ederse burada görünür ve e-postayla bildirilir. Search Console hesabınız yoksa bu uyarıyı hiç almazsınız.
• Sertifika ve alan adı bitiş tarihleri. Süresi dolan alan adı, bir hack kadar zarar verebilir.
• Yeni yönetici hesabı oluşturulması, eklenti kurulması gibi olayların kaydı.
• Kara listeler: sitenizin Google Safe Browsing'e ya da USOM'un yayımladığı zararlı bağlantılar listesine girmesi, bu listeleri kullanan tarayıcı, ağ ve güvenlik araçlarında engellenmesi demektir.

Hacklendiyseniz: adım adım

Panik en kötü danışmandır. Aceleyle her şeyi silmek, saldırganın nasıl girdiğini anlamayı imkânsız hâle getirir ve aynı açıktan bir hafta sonra yeniden girilir. Sıra şöyle olmalı:

1. Durumu kaydedin. Ekran görüntüsü alın, uyarı e-postalarını saklayın, sunucu kayıtlarının silinmediğinden emin olun.
2. Siteyi karantinaya alın: bakım moduna geçin ya da barındırma firmasıyla birlikte geçici olarak erişime kapatın. Ziyaretçileri zararlı içerikten korumak önceliklidir.
3. Barındırma firmanıza haber verin; aynı sunucudaki başka hesapları da etkileyen bir durum olabilir.
4. Bütün şifreleri değiştirin: yönetici hesapları, veritabanı, SFTP, barındırma paneli, API anahtarları. WordPress'te wp-config.php içindeki güvenlik anahtarlarını (salt) yenileyin ki açık oturumlar kapansın.
5. Kullanıcı listesini inceleyin; tanımadığınız yönetici hesaplarını kaldırın.
6. Temizleyin. En güvenli yol, hack öncesine ait doğrulanmış temiz bir yedeğe dönmektir. Yoksa çekirdek, eklenti ve tema dosyalarını resmî kaynaklardan yeniden yükleyin; yükleme klasörlerinde PHP dosyası aramak gibi kontrollerle kalıntı bırakmayın.
7. Giriş yolunu bulun ve kapatın. Güncellenmemiş bir eklenti mi, sızmış bir şifre mi? Bunu bulmadan yayına dönmek, kapıyı açık bırakmaktır.
8. Search Console'da Güvenlik sorunları raporundan “İnceleme İsteğinde Bulunun” düğmesiyle inceleme isteyin ve ne yaptığınızı açıkça yazın. Google'a göre incelemeler birkaç günden birkaç haftaya kadar sürebilir; uyarı o süre boyunca kalır.
9. Sonrası için izlemeyi sıkılaştırın ve olayın kısa bir raporunu yazın.

Kişisel veri ihlalinde bildirim yükümlülüğü

Önce bir hatırlatma: KVKK'nın 12. maddesinin 1. fıkrası, veri sorumlusuna kişisel verilerin hukuka aykırı işlenmesini ve bunlara hukuka aykırı erişilmesini önlemek için uygun güvenlik düzeyini sağlayacak teknik ve idari tedbirleri alma yükümlülüğü yükler. Kurum'un Kişisel Veri Güvenliği Rehberi bu tedbirleri tek tek sayar. Yani güncelleme, yedekleme ve erişim kontrolü yalnızca iyi uygulama değil, kanuni yükümlülüğün de parçasıdır.

Sitenizde form kayıtları, üye bilgileri ya da sipariş verileri varsa ve bunların yetkisiz kişilerin eline geçmiş olma ihtimali varsa, konu teknik olmaktan çıkar. 6698 sayılı KVKK'nın 12. maddesinin 5. fıkrası, işlenen kişisel verilerin kanuni olmayan yollarla başkalarınca elde edilmesi hâlinde veri sorumlusunun bu durumu en kısa sürede ilgili kişiye ve Kurul'a bildirmesini ister. Kurul, 2019/10 sayılı kararıyla bu süreyi yorumladı: veri sorumlusu ihlali öğrendiği andan itibaren gecikmeksizin ve en geç 72 saat içinde Kurul'a bildirmelidir. Etkilenen kişilere ise kişiler belirlendikten sonra makul olan en kısa sürede bildirim yapılır.

Bildirim Kurum'un çevrim içi ihlal bildirim formuyla yapılır; bilgilerin tamamı hemen elde edilemiyorsa aşamalı olarak verilebilir. 72 saat haklı bir sebeple aşılırsa gecikmenin gerekçesi de bildirilmelidir. Ayrıca ihlale ilişkin bilgilerin, etkilerinin ve alınan önlemlerin kayıt altında tutulması ve bir veri ihlali müdahale planının hazırlanıp düzenli gözden geçirilmesi beklenir. Ajansınız ya da barındırma firmanız veri işleyen konumundaysa ihlali size gecikmeksizin bildirmelidir; formu dolduracak olan veri sorumlusu, yani sizsiniz.

Bakım sözleşmesinde neler olmalı?

“Aylık bakım” her ajansta başka bir şey demek. Kimi yalnızca güncelleme düğmesine basar, kimi izleme, yedek testi ve olay müdahalesini de üstlenir. Fark, kötü günde ortaya çıkar. Sözleşmede şu maddelerin açıkça yazılı olmasını isteyin:

Son satır sık atlanır ama en önemlilerinden biridir. Alan adı, barındırma ve yönetici hesapları ajansın değil, sizin adınıza olmalı. Ajansla yollar ayrıldığında sitenizin anahtarları da sizde kalmalı.

Nereden başlamalı?

1. Sitenizin bütün hesaplarını listeleyin: alan adı, DNS, barındırma, CMS yöneticileri, e-posta, Search Console. Her birinin kimin adına olduğunu ve iki adımlı doğrulamanın açık olup olmadığını yazın.
2. Kullanılmayan eklenti, tema ve kullanıcı hesaplarını silin.
3. Kalan eklentilerin son güncelleme tarihine ve dizindeki durumuna bakın; terk edilmiş olanların yerine alternatif bulun.
4. Yedeklerinizin nerede durduğunu öğrenin ve bu ay bir geri yükleme testi yapın.
5. Search Console'u doğrulayın ve çalışma süresi izlemeyi kurun.
6. Yazılı bir güncelleme politikası ve bir test ortamı edinin.
7. Kişisel veri ihlali için kısa bir müdahale planı hazırlayın: kim karar verir, kim hukuk danışmanını arar, Kurul'a kim bildirir.
8. Bakım sözleşmenizi yukarıdaki tabloyla karşılaştırın ve eksik maddeleri yazılı hâle getirin.

AYTE Digital olarak sitelerin bakımını bu tablodaki maddelerle yürütüyoruz; yalnızca kendi yaptığımız siteler için değil, devraldığımız siteler için de önce mevcut durumu inceleyip hangi açıkların önce kapatılması gerektiğini birlikte belirliyoruz. Sitenizin bugünkü hâline bakmamızı isterseniz, hesap listesiyle başlamak yeterli.