Veritabanı dump dosyaları tarayıcıdan indirilebilir hale gelirse hangi riskler oluşur?

Veritabanı dump dosyaları, bir uygulamanın en hassas varlıklarından birini temsil eder: tablolar, kullanıcı kayıtları, şifre özetleri, oturum verileri, siparişler, loglar ve bazen API anahtarları. Bu dosyalar yanlışlıkla web kök dizinine konur ve tarayıcıdan indirilebilir hale gelirse, sorun yalnızca teknik bir yapılandırma hatası olmaktan çıkar; veri sızıntısı, itibar kaybı ve hukuki yükümlülükler doğurabilecek ciddi bir güvenlik olayına dönüşür.

Özellikle paylaşımlı hosting ortamlarında, yedek dosyalarının nereye kaydedildiği çoğu zaman gözden kaçabilir. “Geçici olarak yükledim, sonra silerim” yaklaşımı risklidir; çünkü arama motorları, botlar veya kötü niyetli tarayıcılar bu dosyaları kısa sürede tespit edebilir.

Dump dosyası nedir ve neden bu kadar kritiktir?

Dump dosyası, veritabanının belirli bir andaki dışa aktarılmış kopyasıdır. Genellikle .sql, .dump, .bak, .gz veya .zip uzantılarıyla saklanır. Geliştiriciler taşıma, yedekleme veya test ortamı kurma amacıyla bu dosyaları kullanır.

Risk, dosyanın içeriğinin doğrudan okunabilir olmasından kaynaklanır. Bir saldırgan dosyayı indirdiğinde yalnızca veri yapısını değil, uygulamanın iş mantığına dair ipuçlarını da görür. Tablo adları, kolon yapıları, yönetici hesapları ve entegrasyon kayıtları saldırı planlamasını kolaylaştırır.

Tarayıcıdan indirilebilir dump dosyalarının başlıca riskleri

Kişisel verilerin sızması

Dump dosyalarında ad, e-posta, telefon, adres, IP bilgisi, işlem geçmişi ve kullanıcı tercihleri bulunabilir. Bu bilgiler müşteri güvenini zedeler ve KVKK gibi düzenlemeler kapsamında bildirim, inceleme ve yaptırım süreçlerini tetikleyebilir.

Şifre özetlerinin kırılma ihtimali

Şifreler düz metin yerine hash olarak saklansa bile risk ortadan kalkmaz. Zayıf algoritmalar, tuzsuz hash yapıları veya tekrar kullanılan parolalar, saldırganın hesap ele geçirme girişimlerini kolaylaştırır. Aynı kullanıcıların farklı platformlarda aynı şifreyi kullanması, olayın etki alanını genişletebilir.

Yönetici paneli ve uygulama mantığının ifşa olması

Veritabanı yapısı, yönetici rollerini, yetki tablolarını, gizli durum alanlarını ve kullanılmayan ama aktif kalmış fonksiyonları gösterebilir. Saldırgan, bu bilgileri kullanarak oturum manipülasyonu, yetki yükseltme veya hedefli kimlik avı senaryoları hazırlayabilir.

API anahtarları ve entegrasyon bilgilerinin açığa çıkması

Bazı uygulamalarda ödeme sağlayıcıları, e-posta servisleri, CRM araçları veya sosyal medya entegrasyonlarına ait anahtarlar veritabanında tutulur. Facebook ile giriş, reklam pikseli veya mesajlaşma entegrasyonu kullanan sistemlerde bu kayıtların sızması, yalnızca web sitesini değil bağlı servis hesaplarını da etkileyebilir.

Bu dosyalar nasıl yanlışlıkla erişilebilir hale gelir?

En yaygın neden, yedeğin doğrudan public_html, www veya uygulamanın kök dizinine bırakılmasıdır. Bazı ekipler taşıma sırasında dosyayı FTP ile yükler, içe aktarma tamamlandıktan sonra silmeyi unutur. Bazı otomatik yedekleme eklentileri ise doğru yapılandırılmadığında dışarıdan erişilebilen klasörlere arşiv üretir.

Bir diğer hata, dosya adının tahmin edilebilir olmasıdır. backup.sql, db.sql, site-yedek.zip veya tarih içeren adlar botlar tarafından kolayca denenir. Bu nedenle dosyanın listelenmiyor olması tek başına güvenlik sağlamaz.

Sunucu tarafında hangi kontroller yapılmalı?

İlk adım, yedeklerin web kök dizini dışında saklanmasıdır. Dosya tarayıcıdan çağrılamayacak bir dizinde durmalı, yalnızca yetkili sistem kullanıcısı tarafından okunabilmelidir. hosting panelinde dosya yöneticisi kullanılıyorsa, yedek klasörünün yayın dizini içinde olmadığından emin olunmalıdır.

• Web kök dizininde .sql, .bak, .zip, .gz uzantılı dosya araması yapın.
• Otomatik yedekleme araçlarının hedef klasörünü kontrol edin.
• Dizin listelemeyi kapatın; ancak bunu tek güvenlik önlemi olarak görmeyin.
• Yedek dosyalarını güçlü biçimde şifreleyin ve kısa saklama politikası uygulayın.
• Eski test, taşıma ve staging dosyalarını düzenli olarak temizleyin.

Erişim engelleme nasıl uygulanabilir?

Apache kullanan sistemlerde, belirli uzantıların web üzerinden indirilmesini engelleyen kurallar uygulanabilir. Bu, dosyayı doğru yerde saklamanın yerine geçmez; fakat yanlışlıkla yayın dizinine düşen dosyalar için ek bir koruma katmanı sağlar.

<FilesMatch "\.(sql|bak|dump|gz|zip)$">
  Require all denied
</FilesMatch>

Nginx tarafında da benzer şekilde hassas uzantılara erişim kapatılabilir. Kurallar uygulanmadan önce test ortamında denenmeli, meşru indirme akışlarını bozmadığından emin olunmalıdır. Yanlış yapılandırma, kullanıcıların ihtiyaç duyduğu dosyalara erişimini de engelleyebilir.

Bir dump dosyasının indirildiğinden şüpheleniyorsanız ne yapmalısınız?

Öncelikle dosyayı erişimden kaldırın ve aynı dizinde benzer dosyalar olup olmadığını kontrol edin. Ardından web erişim loglarında dosya adına yapılan istekleri, IP adreslerini, zaman damgalarını ve HTTP durum kodlarını inceleyin. Dosya gerçekten indirilmişse olayın kapsamı belirlenmeden yalnızca dosyayı silmek yeterli değildir.

Şifreler, API anahtarları, veritabanı kullanıcı parolaları ve yönetici hesapları yenilenmelidir. Kullanıcı verisi etkilenmişse hukuki ve operasyonel bildirim süreçleri değerlendirilmelidir. Ayrıca yedekleme prosedürü dokümante edilmeli; kimin, hangi dosyayı, hangi dizine, ne kadar süreyle koyabileceği netleştirilmelidir.

Kalıcı güvenlik için pratik kontrol listesi

Güvenli yedekleme süreci, yalnızca teknik bir komutla değil, düzenli kontrol alışkanlığıyla güçlenir. Yedek dosyaları şifreli saklanmalı, erişim yetkileri dar tutulmalı ve geri yükleme testleri kontrollü ortamda yapılmalıdır. Sunucu üzerinde otomatik tarama planlamak, unutulan dosyaları erken fark etmeyi sağlar.

Kurumsal yapılarda en sağlıklı yaklaşım; üretim verisinin gereksiz kopyalarını azaltmak, test ortamlarında maskeleme kullanmak ve yedeklerin yaşam döngüsünü belirli kurallara bağlamaktır. Böylece hem operasyonel ihtiyaçlar karşılanır hem de olası bir yapılandırma hatasının veri güvenliği krizine dönüşme ihtimali azaltılır.