E-Ticaret Veri Kurtarma: Trendyol, Hepsiburada, Magento, WooCommerce Senaryoları ve PCI-DSS

E-ticaret operasyonu, ardı ardına dizilmiş onlarca kritik servisin sürekli çalışmasına bağlıdır. Sipariş tablosu, ürün kataloğu, sepet oturumu, ödeme aracı entegrasyonu, kargo API'si, fatura kuyruğu, müşteri profili, kupon motoru, satıcı paneli; bunların hepsi tek bir veritabanı şemasında ya da birbirine sıkıca bağlı mikroservislerde tutulur. Bir tek InnoDB sayfası bozulduğunda kampanya günü tüm site donar, bir tek JavaScript dosyasına Magecart kodu enjekte edildiğinde haftalarca kart bilgisi sızar. Bu yazıda Türkiye e-ticaret ekosisteminin sık karşılaştığı vakaları, platform bazlı kurtarma yaklaşımlarını, PCI-DSS ve KVKK uyum sınırlarını, yerel ödeme sağlayıcılarla koordinasyonu somut adımlarla anlatıyoruz.

Konunun bütününü görmek için önce ana rehberimize bakmak isteyebilirsiniz: Veri kurtarma rehberi 2026 Türkiye. Ardından e-ticaret özelindeki ayrıntılara döneceğiz.

Türkiye e-ticaret katmanları: pazaryeri, kendi mağaza, hibrit

Türkiye'de e-ticaret işleten markalar genelde üç katmanlı çalışır. Birinci katman pazaryeri satıcı panelleridir; Trendyol, Hepsiburada, n11, Amazon TR ve Çiçeksepeti gibi platformlar satıcıya kendi siparişlerini, ürünlerini ve mesajlarını yönetebilecek bir hesap verir. İkinci katman markanın kendi e-ticaret sitesidir; burada Magento (Adobe Commerce), WooCommerce (WordPress), Shopify, PrestaShop, OpenCart ve Türkiye'de yaygın IdeaSoft, Ticimax, T-Soft gibi yerli platformlar kullanılır. Üçüncü katman ERP, muhasebe ve e-fatura tarafıdır; GİB e-Belge sistemi (https://ebelge.gib.gov.tr) üzerinden e-Arşiv ve e-Fatura kuyrukları işletilir.

Veri kurtarma planı yapılırken bu üç katman ayrı ayrı düşünülmelidir. Çünkü pazaryeri verisi (siparişler, müşteri adresleri, mesajlar) çoğu zaman markanın elinde değildir; API üzerinden çekilip kendi veritabanına yansıtılır. Bir veritabanı çöküşü yaşandığında pazaryerinden tekrar çekmek mümkündür ancak limit, sayfalama ve geriye dönük tarih kısıtları vardır. Kendi mağazasının veritabanı kaybedildiğinde ise yedek yoksa müşteri tarihçesi geri gelmez.

Tipik vaka 1: Black Friday'de MySQL bozulması

E-ticaret veri kurtarma talebinin tepe yaptığı dönem kasım sonu kampanya günleridir. Sezonun en yoğun trafiğinde tek bir SSD'nin firmware'i kilitlenir, RAID controller cache'i flush edemez, MySQL InnoDB tablespace'inin ortasındaki bir sayfa bozulur. Site açık kalmaya çalışırken Got error 1712 from storage engine ya da Page corruption mesajları log'a düşer.

Bu noktada yapılacak ilk şey siteyi yazma trafiğine kapatmaktır. read_only=1 bayrağı çekilir veya yük dengeleyici sipariş POST'larını dondurur. Ardından canlı diskten önce bit-bit imaj alınır; ddrescue ile read-only modda kopya çıkarmadan hiçbir InnoDB tamir komutu denenmemelidir, çünkü innodb_force_recovery=6 kötü sayfaları geri dönülmez şekilde atabilir.

İmaj alındıktan sonra üç paralel yol denenir: birincisi bozuk sayfaların atlanarak mysqldump ile mantıksal dışa aktarımı, ikincisi binary log'lardan (mysql-bin.*) son sağlam yedeğin üzerine point-in-time replay, üçüncüsü Percona Toolkit ile tablo bazlı extract. RAID seviyesinde de sorun varsa süreç daha uzar; konuyu derinlemesine ele aldığımız RAID 5 çöktü kurtarma süreci ve maliyet yazımıza bakabilirsiniz.

Sezon trafiğinde kritik olan, yedeğin "kaç saatlik kayba razıyız" sorusudur. RPO (Recovery Point Objective) hedefi 5 dakika ise binary log shipping veya MySQL group replication şarttır. Günlük tek mysqldump ile çalışan e-ticaret sitesi, Black Friday öğleden sonra çöktüğünde sabahki yedekten dönmek zorunda kalır ve binlerce sipariş tekrar girilemez.

Tipik vaka 2: Magecart skimming ve kart sızıntısı

Magento ve WooCommerce mağazalarına yıllardır en çok zarar veren saldırı tipi Magecart adı verilen JavaScript skimmer ailesidir. Saldırgan, mağazanın ön yüzüne ya da üçüncü parti bir analytics, chat, kupon, A/B test scriptine kart bilgisi çalan bir JS satırı enjekte eder. Müşteri kart numarasını yazar, form gönderilmeden önce skimmer karakterleri uzak sunucuya gönderir. CISA, Magecart varyantları için uyarılar yayımladı ve tedarik zinciri riskinin somut hâli olarak gösterdi (https://www.cisa.gov).

Magecart vakasında "veri kurtarma" iki anlam taşır. Birincisi mağazanın temiz haline geri dönmek; ikincisi ise sızdırılan kart datasının kapsamını forensic olarak belirlemek. Süreç şudur:

1. Web sunucusunun ve veritabanının okunabilir imajı alınır.
2. CSP (Content Security Policy) ihlal log'ları, CDN erişim log'ları, core_config_data ve cms_block tabloları taranır. CSP ve SRI'nin nasıl yapılandırılması gerektiği konusunda MDN dokümantasyonu (https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) iyi bir başlangıçtır.
3. OWASP Top 10 (https://owasp.org/www-project-top-ten/) A08 "Software and Data Integrity Failures" kapsamındaki kontroller işletilir; özellikle üçüncü parti script bütünlüğü için SRI hash'leri kontrol edilir.
4. Etkilenen kart aralığı (BIN, ilk-son 4 hane, tarih penceresi) belirlenir.
5. Acquiring bank ve ödeme aracısı bilgilendirilir.

Burada PCI-DSS uyumu kritik rol oynar. PCI Security Standards Council (https://www.pcisecuritystandards.org) tarafından yayımlanan PCI-DSS v4.0 standardı, kart datasının saklandığı her ortam için sıkı kontroller getirir. Türkiye'de markaların büyük çoğunluğu iyzico, PayTR, Param, MOKA, Sipay, Birleşik Ödeme gibi BDDK lisanslı ödeme kuruluşlarını kullanır. Bu aracılar kartı kendi PCI-DSS Level 1 ortamlarında tokenize eder; satıcının veritabanında sadece token kalır. Doğru yapılandırılmış iframe ya da hosted payment page kullanımı, satıcının PCI kapsamını ciddi biçimde daraltır.

Ancak Magecart, "ben kartı tutmuyorum, iyzico tutuyor" diyen mağazaları da vurur. Çünkü skimmer form gönderilmeden önce DOM'dan değeri okur, satıcının veritabanına asla yazılmasa bile saldırgan eline geçer. Bu yüzden CSP script-src direktifinin sıkı tutulması, üçüncü parti script'lerin SRI hash'i ile sabitlenmesi ve checkout sayfasının ayrı bir alt-domain altında, minimum üçüncü parti içerikle servis edilmesi PCI-DSS v4.0'ın da önerdiği savunma katmanıdır.

Tipik vaka 3: WooCommerce plugin XSS ve veritabanı zehirlenmesi

WooCommerce dünyasında en sık karşılaşılan zafiyet, eklenti kaynaklı stored XSS ve SQL injection vakalarıdır. Lisanssız ya da güncellenmemiş bir "ürün filtresi", "review slider", "import/export" eklentisi, saldırgana wp_options, wp_users, wp_woocommerce_order_items tablolarına yazma imkânı verebilir.

Bu tip vakada veri kurtarmanın sırası şudur. Önce site bakım moduna alınır, ardından wp-content/uploads, wp-content/plugins, wp-content/mu-plugins, .htaccess ve wp-config.php dosyaları farklı bir kopya üzerinden taranır. PHP webshell imzaları (eval(base64_decode, assert($_REQUEST, gzinflate(str_rot13) aranır. Veritabanında wp_options içindeki siteurl, home, active_plugins değerleri ve wp_users tablosundaki yeni admin hesapları sorgulanır.

Veritabanı temizliği için iki yaklaşım vardır: ihlalin başladığı tarihten önceki son sağlam yedeğe dönüp aradaki siparişleri elle ya da pazaryeri API'sinden senkronize etmek, ya da mevcut veritabanını satır satır temizleyip enjekte edilmiş kayıtları silmek. Hangisinin uygun olduğu ihlalin süresine ve sipariş yoğunluğuna göre belirlenir.

Tipik vaka 4: Ransomware ve e-ticaret hosting'i

Ransomware artık sadece Windows dosya sunucularını değil, Linux tabanlı web hosting'leri de hedef alıyor. ESXi tabanlı sanallaştırma katmanına sızılan vakalar Türkiye'de de görüldü. Hosting sağlayıcının paylaşımlı yedeği şifrelendiyse iş ciddidir.

İlk 24 saatte yapılacaklar konusunda kapsamlı bir rehberimiz var: Fidye yazılım sonrası ilk 24 saat acil müdahale. E-ticaret özelinde ek olarak şu adımlar gerekir:

1. Hosting sağlayıcısı ile derhal iletişime geçilir, log'ların döngüde silinmemesi için tutma süresi uzatılır. Apache/Nginx access log'ları, FTP/SSH oturum log'ları, MySQL general log varsa kopyalanır.
2. Ödeme aracısı uyarılır. iyzico, PayTR, Param ve MOKA olayın boyutuna göre webhook trafiğini geçici durdurabilir.
3. Pazaryeri (Trendyol, Hepsiburada) satıcı paneline saldırganın eriştiği şüphesi varsa, API anahtarları yenilenir.
4. KVKK madde 12 kapsamında 72 saat içinde Kurul'a ihlal bildirimi yapılır. Detaylı süreç ve form için KVKK veri ihlali bildirimi 72 saat formu yazımız var.

Tipik vaka 5: Accidental DELETE ve "binary log var mı?"

İnsan hatası klasik. Geliştirici prod veritabanında DELETE FROM orders WHERE status='draft' yazmak isterken WHERE koşulunu unutur ve tüm sipariş tablosu silinir. Bu durumda kurtarma şansı tamamen yedek ve binary log yapılandırmasına bağlıdır.

MySQL'de log_bin=ON ve binlog_format=ROW ise, son tam yedek geri yüklenir, ardından mysqlbinlog ile silme komutundan bir saniye öncesine kadar replay yapılır, silinen satırlar geri gelir. PostgreSQL kullanıyorsa WAL arşivi şarttır; pgBackRest veya Barman ile point-in-time recovery yapılır. MongoDB'de oplog penceresi yeterince genişse benzer şekilde geri sarma mümkündür.

Bu noktada şu kural belirir: e-ticaret veritabanlarında yedekleme stratejisi 3-2-1 ile bitmemelidir. 3-2-1 (üç kopya, iki farklı medya, biri off-site) temel taban çizgisidir, ancak modern e-ticaret için ek katmanlar gerekir. Immutable yedek (object lock'lu S3 ya da WORM disk), point-in-time recovery (binary log/WAL arşiv), ve restore tatbikatı (en az ayda bir, gerçek bir RTO testi). Yedek var ama restore denenmedi ise yedek yok demektir.

KVKK kapsam: B2C müşteri + B2B satıcı

E-ticaret operasyonu hem B2C (tüketici müşteri) hem de B2B (pazaryeri satıcıları, dropshipping tedarikçileri, kargo şirket çalışanları) veriyi işler. KVKK madde 6 kapsamındaki özel nitelikli veriler (sağlık, din, biyometrik) e-ticaret veritabanlarında genelde bulunmaz; ancak isim, adres, telefon, e-posta, IP, sipariş tarihi, T.C. kimlik numarası (e-fatura için) madde 5 kapsamında işlenir.

Bir ihlal yaşandığında KVKK (https://www.kvkk.gov.tr) en geç 72 saat içinde bildirim ister. Bildirim formunda ihlalin başlangıç tarihi, etkilenen kayıt sayısı, veri kategorileri ve alınan önlemler istenir. Magecart gibi uzun süreli sızıntılarda kayıt sayısının tespiti kritik; forensic ekibinin günlük bazda sızdırılan kart sayısını verebilmesi gerekir.

İlginç bir nokta: B2B satıcı verisi de gerçek kişiye ait olduğunda KVKK kapsamındadır. Pazaryerinde bireysel satıcı (şahıs şirketi) hesabı hacklenip kişisel bilgileri sızdığında, satıcı da ihlal mağduru sayılır ve bildirim kapsamına girer.

Sosyal mühendislik ve satıcı paneli devralma

Son yıllarda Türkiye'de yaygınlaşan başka bir saldırı tipi, pazaryeri satıcı panellerinin phishing ile devralınmasıdır. Saldırgan, Trendyol veya Hepsiburada'dan geliyormuş gibi "iade onay", "kampanya katılım", "hesap doğrulama" konulu e-postalar gönderir. Satıcı linke tıklar, kimlik bilgilerini gönderir, saldırgan panele girip kendi IBAN'ını ekler, bekleyen ödemeleri kendine yönlendirir.

Bu tür e-postaların nasıl ayırt edileceğini detaylıca anlattığımız bir yazı var: Phishing oltalama e-postası nasıl anlaşılır 2026. E-ticaret ekiplerinin tüm çalışanlarına bu içeriği iletmesini öneriyoruz.

Ödeme aracısı ile koordinasyon

Bir ihlal sonrası iyzico, PayTR, Param veya MOKA ile koordineli çalışmak şarttır. Genel akış şöyledir. İhlalin doğrulanmasını takiben aracıya yazılı bildirim yapılır, etkilenen işlem aralığı (tarih, sipariş ID, BIN aralığı) iletilir. Aracı, kart şemaları (Visa, Mastercard, Troy) ile compromised account management programı (CAMP) süreçlerini başlatır. Etkilenen kartlar bankalarına bildirilir, bankalar müşteri bazlı karar verir.

Bu süreçte satıcının PCI-DSS SAQ (Self-Assessment Questionnaire) tipi önem kazanır. iframe veya redirect mimarisi kullanan satıcılar genelde SAQ A kapsamındadır ve kart datasına hiç dokunmaz. Doğrudan kart numarasını sunucudan ileten satıcılar SAQ D kapsamındadır, çok daha ağır yükümlülük altındadır. Magecart vakası SAQ A satıcıyı bile yakar, çünkü zafiyet sunucuda değil tarayıcıdaki DOM'da gerçekleşir; PCI-DSS v4.0 bu sebeple "script integrity" maddelerini sıkılaştırdı.

Pazaryeri verisi geri çekimi

Kendi mağaza veritabanı tamamen kayıp ve yedek yoksa son çare pazaryeri API'leri olur. Trendyol Marketplace API'si son siparişleri tarih aralığı ile sayfalı çeker, Hepsiburada satıcı API'si benzer. Burada kısıtlar:

• Geriye dönük tarih limiti (genelde 14-30 gün, daha eskisi için manuel destek talebi).
• Saatlik istek kotası (rate limit aşılırsa hesap geçici kısıtlanır).
• Mesajlaşma tarihçesi, iade gerekçeleri her zaman API'den dökülemez; ihtiyaç olursa satıcı paneli ekran kayıtları gerekir.
• Müşterinin gerçek e-posta ve telefonu KVKK gereği maskelenmiştir; iletişim için pazaryerinin kendi mesajlaşma kanalı kullanılır.

Yedek mimarisi: 3-2-1'in ötesi

E-ticaret işletmesi için önerdiğimiz yedek tasarımı şu katmanlardır.

1. Saatlik incremental veritabanı yedeği (XtraBackup, pgBackRest ya da MongoDB ops manager) yerel NAS'ta.
2. Günlük tam yedek, farklı bir veri merkezindeki S3 uyumlu object storage'a, object lock (WORM) açık.
3. Binary log/WAL sürekli ship (point-in-time recovery için).
4. Haftalık snapshot, soğuk medyaya (LTO bant veya farklı bulut bölgesine immutable).
5. Aylık restore tatbikatı; yedek dosyası alınır, ayrı bir sunucuya geri yüklenir, sipariş tablosu satır sayısı doğrulanır.

Magento için ek olarak var/, pub/media/, app/etc/env.php ve özelleştirilmiş tema/modül klasörleri ayrı sıklıkta yedeklenmelidir. WooCommerce için wp-content/uploads ve veritabanı eş zamanlı olmazsa görseller siparişle uyumsuz kalır.

Şifreleme ve anahtar yönetimi

PCI-DSS, kart verisinin "data at rest" şifrelenmesini ister; Türkiye'de aracı kullanan satıcılar zaten bu yükümlülüğü aracıya devretmiş olur. Ancak kişisel veri (KVKK kapsamı) için de uygulamalı seviyede şifreleme önerilir. Veritabanı dosyalarının disk seviyesinde şifrelenmesi (LUKS, dm-crypt) bir katman sağlar, kolon seviyesinde şifreleme (özellikle T.C. kimlik, telefon) ikinci bir katman ekler. Anahtarlar veritabanından ayrı bir KMS'te (AWS KMS, HashiCorp Vault, Türkiye'de TÜBİTAK BİLGEM anahtar sistemleri) tutulmalıdır.

Dikkat: tam disk şifrelemesi sadece "sunucu çalınırsa" senaryosunu çözer. Sunucu açıkken ransomware girerse şifreleme zaten transparan açık olduğundan saldırgan da verilere ulaşır. Bu yüzden tek başına yeterli savunma değildir.

Türkiye'de yerel laboratuvar desteği

Magento veritabanı çökmesi, WooCommerce hack sonrası temizlik, MySQL InnoDB tablespace tamiri, ransomware sonrası mağaza ayağa kaldırma; bu işlerin hepsi kontrollü bir ortamda, üreticisi belli ekipmanla ve PCI-DSS bilincine sahip ekiple yapılmalıdır.

Hacettepe Teknokent Ankara'daki laboratuvarımız e-ticaret operasyonlarına özel süreç işletir. Sipariş veritabanı, ürün medyası, fatura kuyruğu ve ödeme webhook log'ları birlikte ele alınır; ödeme aracısı ile koordinasyon, KVKK bildirimi ve forensic raporlama tek paket sunulur. İstanbul'dan veya başka şehirden çalışan müşteriler için lojistik akışı detaylı anlattığımız İstanbul veri kurtarma Ankara Hacettepe Teknokent yazımıza bakabilirsiniz.

Sezon ortasında veya gecenin bir vakti site çöktüğünde 7/24 acil müdahale hattımız açıktır: +90 536 662 38 09. İlk arama ücretsiz teknik ön değerlendirmedir; ekibimiz veritabanı tipinden ödeme aracısı entegrasyonuna kadar tüm tabloyu çıkarır, ardından net süre ve fiyat verir. Sonrasında kararı işletme verir.

E-ticaret veri kurtarma, sadece dosya geri getirmek değildir. Mağaza yeniden açılırken aynı anda ödeme aracısı uyumu, KVKK bildirimi, pazaryeri senkronizasyonu, müşteri iletişimi ve SEO etkisinin yönetimi gerekir. Doğru ekiple çalışmak hem süreyi kısaltır hem de ihlalin uzun vadeli ticari etkisini sınırlandırır.