Yedek zip dosyaları web kökünde bırakılırsa ne olur?

Web sitesinin yedeğini almak doğru bir güvenlik alışkanlığıdır; ancak bu yedeği hosting hesabında herkesin erişebileceği web kökünde bırakmak ciddi bir veri sızıntısına dönüşebilir. public_html, www, htdocs veya benzeri dizinler tarayıcıdan erişilebilen alanlardır. Bu alanlara konulan backup.zip, site-yedek.zip, fullbackup.tar.gz gibi dosyalar tahmin edilebilir isimler taşıyorsa, yetkisiz kişiler tarafından indirilebilir.

Web kökü neden riskli bir alandır?

Web kökü, sunucunun internet kullanıcılarına dosya servis ettiği dizindir. Bir görsel, CSS dosyası veya PDF burada yer aldığında tarayıcı üzerinden açılabilir. Aynı mantık yedek zip dosyaları için de geçerlidir. Sunucu özel bir erişim kuralı ile engellemiyorsa, dosyanın URL’sini bilen veya tahmin eden herkes yedeğe ulaşabilir.

Risk yalnızca dosyanın doğrudan listelenmesiyle sınırlı değildir. Dizin listeleme açık olabilir, arama motorları yanlışlıkla dosyayı indeksleyebilir, hata günlükleri veya eski bağlantılar dosya yolunu açığa çıkarabilir. Bu nedenle “kimse dosya adını bilmez” yaklaşımı güvenli kabul edilmez.

Yedek zip dosyası ele geçirilirse neler açığa çıkar?

Bir site yedeği çoğu zaman yalnızca tema ve eklenti dosyalarından ibaret değildir. İçinde yapılandırma dosyaları, veritabanı çıktıları, kullanıcı bilgileri, API anahtarları, ödeme entegrasyonu ayarları ve e-posta servis şifreleri bulunabilir. WordPress sitelerinde wp-config.php dosyası özellikle kritiktir; veritabanı bağlantı bilgileri ve güvenlik anahtarları bu dosyada yer alır.

Veritabanı dökümü yedeğe eklenmişse durum daha hassas hale gelir. Müşteri kayıtları, sipariş bilgileri, iletişim formları, üyelik verileri ve parola hash’leri açığa çıkabilir. Bu durum yalnızca teknik bir güvenlik açığı değil, aynı zamanda KVKK ve kurumsal itibar açısından da ciddi bir olaydır.

Saldırganlar bu dosyaları nasıl bulur?

Yetkisiz erişim her zaman gelişmiş bir saldırı gerektirmez. Otomatik tarayıcılar çok yaygın dosya adlarını dener: backup.zip, site.zip, yedek.zip, public_html.zip, wordpress-backup.zip, db.sql.zip gibi. Bazı botlar belirli tarih formatlarını da kontrol eder; örneğin 2024-12-01-backup.zip veya domainadi-yedek.zip.

Dizin listeleme açıksa saldırganın tahmin yürütmesine bile gerek kalmaz. Tarayıcıda klasör içeriği görünür ve zip dosyası tek tıkla indirilebilir. Bu nedenle dosya adı karmaşık olsa bile, web kökünde yedek tutmak güvenli bir yöntem değildir.

Yanlış güvenlik önlemleri nelerdir?

Sadece dosya adını değiştirmek

Rastgele karakterlerden oluşan bir dosya adı riski azaltabilir; fakat güvenlik kontrolü değildir. Dosya yolu loglarda, e-posta bildirimlerinde veya eklenti çıktılarında görünebilir. Ayrıca dosya web’den erişilebilir olduğu sürece temel problem devam eder.

Zip dosyasına parola koymak

Parolalı zip dosyası ek bir katman sağlayabilir; ancak zayıf parolalar kırılabilir. Daha önemlisi, parolalı da olsa hassas verinin herkese açık dizinde durması doğru bir operasyon modeli değildir. Kurumsal kullanımda esas yaklaşım, yedeğin erişilemeyen bir alanda saklanmasıdır.

Geçici olarak bırakıp unutmak

En sık görülen hata, taşıma veya güncelleme sırasında alınan yedeğin işlem bitince silinmemesidir. “Birazdan kaldırırım” denilen dosyalar aylarca kalabilir. Bu durum özellikle çok kullanıcılı ekiplerde, ajans çalışmalarında ve bakım süreçlerinde sık yaşanır.

Güvenli yedekleme için pratik yaklaşım

Yedek dosyaları mümkünse web kökünün dışında tutulmalıdır. Örneğin public_html ile aynı seviyede, tarayıcıdan erişilemeyen özel bir dizin kullanılabilir. Alternatif olarak özel erişimli bulut depolama, şifreli uzak yedekleme veya kontrol panelinin güvenli yedek alanları tercih edilebilir.

Bir hosting ortamında çalışıyorsanız, dosyanın gerçekten web’den erişilemediğini tarayıcı üzerinden test edin. Yedek dosyanın URL’sini açmaya çalıştığınızda indirme başlamamalı; 403, 404 veya erişim engeli dönmelidir. Bu kontrol, varsayımlarla hareket etmekten daha güvenilirdir.

Web kökünde yedek bulunduysa hemen ne yapılmalı?

• Dosyayı silin veya web dışı alana taşıyın: public_html içinde bırakmayın.
• URL erişimini test edin: Eski dosya adresi artık indirilebilir olmamalıdır.
• Sunucu loglarını inceleyin: Dosyanın daha önce indirilip indirilmediğini kontrol edin.
• Şifreleri değiştirin: Veritabanı, yönetici, FTP/SFTP, panel ve API anahtarlarını yenileyin.
• Veritabanı sızıntısı ihtimalini değerlendirin: Kişisel veri bulunuyorsa hukuki ve idari süreçleri gözden geçirin.
• Yedekleme akışını düzeltin: Otomatik yedeklerin nereye yazıldığını ve ne zaman silindiğini netleştirin.

Teknik engelleme yeterli mi?

.htaccess veya Nginx kurallarıyla zip, sql, tar, gz gibi dosya türlerine erişim engellenebilir. Bu iyi bir ek önlemdir; ancak tek başına yeterli görülmemelidir. Yanlış yapılandırma, sunucu değişikliği veya taşıma sonrasında kural devre dışı kalabilir. Kalıcı çözüm, hassas yedeklerin web’den servis edilen dizine hiç konulmamasıdır.

WordPress bakım süreçlerinde yedek eklentilerinin hedef klasörü mutlaka kontrol edilmelidir. Bazı eklentiler varsayılan olarak wp-content altında yedek klasörü oluşturabilir. Bu klasör erişime kapalı değilse, yedekler beklenmedik şekilde dış dünyaya açılabilir. Düzenli bakım listesine “yedek dosya konumu ve erişim testi” maddesini eklemek, küçük ama etkili bir güvenlik adımıdır.

Kurumsal ekipler için kontrol listesi

Taşıma, güncelleme veya geliştirme çalışması yapan ekiplerde yedek dosyalarının yaşam döngüsü tanımlı olmalıdır. Kim yedek alıyor, dosya nerede tutuluyor, ne kadar süre saklanıyor, kim erişebiliyor ve ne zaman siliniyor soruları net cevaplanmalıdır. Bu düzen, hem teknik riski hem de operasyonel belirsizliği azaltır.

Paylaşımlı sunucu ortamlarında dosya izinleri, kullanıcı ayrımı ve panel yetkileri ayrıca gözden geçirilmelidir. Kritik projelerde yedekler şifreli, erişim kayıtları tutulabilir ve düzenli geri yükleme testi yapılabilir şekilde yönetilmelidir. Böylece yedekleme yalnızca “dosya kopyalamak” olmaktan çıkar; güvenilir, denetlenebilir ve sürdürülebilir bir iş sürekliliği sürecine dönüşür.