Çoğu e-pin satıcısı güvenliği bir ürün sanır. Bir güvenlik duvarı alırsın, SSL takarsın, panel şifresini uzatırsın ve rahatlarsın. Oysa bu sektörde yaşanan olayların neredeyse tamamı, güvenlik önlemlerinin hiç olmadığı yerlerde değil, olay anında ne yapılacağının yazılı olmadığı yerlerde büyür. Saldırıyı engellemek her zaman mümkün değildir; saldırının maliyetini on dakikada sınırlamak ise tamamen senin hazırlığına bağlıdır.
Şunu net söyleyeyim: bir sabah uyanıp bakiyenin sıfırlandığını, stoktaki kodların tek tek tüketildiğini gördüğünde aklın çalışmaz. O anda ihtiyacın olan şey zeka değil, önceden yazılmış bir sıra. Bu yazıda e-pin satış yazılımı kullanan bir işletmenin masaya asması gereken müdahale planını adım adım kuruyoruz. Dijital ürün satış scripti tarafında hangi teknik yeteneklerin bu planı mümkün kıldığını da konuşacağız, çünkü log tutmayan bir altyapıda müdahale planı yazmak boş kağıda imza atmaktır.
Saldırı Neden Gece 03:00'te Başlar, Sabah 09:00'da Fark Edilir?
Kötü niyetli tarafın en büyük avantajı teknik bilgisi değil, senin uyku saatin. Otomatik teslimat yapan bir e-pin satış scripti, doğası gereği insan onayı beklemeden çalışır. Bakiye yükleme, sipariş, kod teslim döngüsü saniyeler içinde tamamlanır. Bu yüzden bir oturum çalındığında ya da ödeme bildirimi taklit edildiğinde zarar, sen fark edene kadar kendi kendine büyür. Müdahale planının ilk maddesi bu yüzden müdahale değil haber alma olmalıdır: kritik olaylarda Telegram veya e-posta bildirimi kurulmamışsa, planın geri kalanı hiç okunmaz. Anormal sipariş hacmi, aynı IP'den arka arkaya bakiye işlemi, gece saatlerinde yönetici girişi gibi olaylar anlık bildirime bağlanmadığı sürece her olay altı saat gecikmeyle keşfedilir.
İlk 15 Dakika: Panik Yerine Hangi Sırayla İlerleyeceksin?
Olay anında yapılan en yaygın hata, önce sebebi araştırmaktır. Yanlış. Önce kanamayı durdurursun, sonra teşhis koyarsın. Sıra şudur: teslimatı durdur, yönetici oturumlarını topluca sonlandır, ödeme bildirim uçlarını kapat, sonra logu almaya başla. Bu dört adım bir arada yapılabiliyorsa iyi bir epin yazılım kullanıyorsun demektir; tek tek veritabanına girip elle satır güncellemen gerekiyorsa altyapın olay müdahalesine uygun değil. Pinova tarafında bu adımların tamamı panel içinden tek ekranda toplandığı için, teknik bilgisi olmayan bir operasyon çalışanı bile sırayı uygulayabilir. Planın işe yaraması için gereken tek şey, o sıranın bir kişiye emanet edilmemesidir: gece kimin müdahale edeceği isim isim yazılı olmalı.
| Olay tipi | İlk hamle | Hedef süre | Karar sahibi |
|---|---|---|---|
| Yönetici oturumu ele geçirilmiş | Tüm oturumları sonlandır, 2FA zorunlu hale getir | 2 dakika | İşletme sahibi |
| Sahte ödeme bildirimi | Bildirim ucunu kapat, bekleyen siparişleri askıya al | 5 dakika | Operasyon |
| Stok kodları dışa sızmış | İlgili partiyi iptal et, tedarikçiye bildir | 15 dakika | Satın alma |
| Müşteri hesaplarında yetkisiz erişim | Şifre sıfırlama zorunlu, cüzdan çekimi dondur | 10 dakika | Destek ekibi |
| Sunucu düzeyinde şüpheli dosya | Bakım moduna al, son yedeği doğrula | 20 dakika | Teknik destek |
Bakiye ve Stok Nasıl Dondurulur? Bunu Kimse Önceden Yazmıyor
Dondurma kelimesi kulağa basit gelir ama pratikte üç ayrı musluk vardır: müşteri cüzdanından harcama, sipariş oluşturma ve otomatik teslimat. Üçünü ayrı ayrı kapatabilmek çok önemlidir, çünkü hepsini birden kapatmak siteyi tümden durdurur ve o gün ciro yazmazsın. İyi kurgulanmış bir dijital ürün satış yazılımı sana kademeli kapatma imkanı verir: teslimatı durdurup siparişi açık bırakırsın, gelen siparişler kuyrukta bekler, sen kaynağı bulurken müşteri kaybetmezsin. Kademeli kapatma yoksa tek seçeneğin bakım modudur ve bakım modu her olayda saatlerce ciro kaybı demektir. Müdahale planını yazarken hangi eşikte hangi musluğu kapatacağını sayısal olarak belirle: örneğin on dakikada aynı üründen yirmiden fazla otomatik teslim varsa teslimat otomatik dursun.
Gerçek olayların kaynak dağılımı
- Çalınan yönetici erişimi 45%
- Ödeme bildirimi manipülasyonu 25%
- Güncellenmemiş eklenti ve tema kodu 20%
- Sunucu ve barındırma kaynaklı 10%
Log Tutmayan Bir Script'te Olay Müdahalesi Neden İmkansızdır?
Bir olayın ardından sorman gereken üç soru var: kim, ne zaman, neyi değiştirdi. Bu üç sorunun cevabı yoksa yaptığın şey müdahale değil tahmindir. Tahminle kapatılan açık, iki hafta sonra aynı yerden yeniden açılır. Bu yüzden e-pin scripti seçerken değiştirilemez işlem kaydı olup olmadığını sormak, tema seçeneklerini sormaktan kat kat önemlidir. Bakiye hareketleri, manuel stok müdahaleleri, fiyat değişiklikleri, yönetici girişleri ve teslimat kayıtları ayrı ayrı, silinemez biçimde tutulmalı. Pinova bu kayıtları yönetici tarafından bile temizlenemeyecek şekilde saklar; bu özellik ilk bakışta gereksiz bir detay gibi görünür, olay gününde ise elindeki tek delil olur. Ayrıca logu dışa aktarabiliyor olman gerekir, çünkü bankadan ya da tedarikçiden geri ödeme talebinde bulunacağın anda ekran görüntüsü yeterli olmaz.
Müşteriye Ne Zaman, Hangi Cümlelerle Söylenir?
Sektörde en çok itibar kaybı, olayın kendisinden değil, olayın saklanma girişiminden doğar. Müşterinin cüzdanı etkilenmişse ya da teslim edilen kod başkası tarafından kullanılmışsa, bunu senden önce forumlardan öğrenmesi markanı bitirir. Doğru yaklaşım şu: etkilenen kullanıcı sayısı netleşmeden genel duyuru yapma, ama etkilenen kullanıcıya ilk iki saat içinde doğrudan yaz. Ne olduğunu, hangi verinin etkilenmediğini, ne yaptığını ve ne zamana kadar çözüleceğini tek paragrafta söyle. Söz verdiğin tarihi tutmak, verdiğin sözün büyüklüğünden daha değerlidir. Bir de şu: teknik detay paylaşmak zorunda değilsin, ancak yalan söylememek zorundasın.
Müdahale planını yazdıktan sonra üç ayda bir kuru tatbikat yap: gerçek olay yokken teslimatı beş dakika kapat, oturumları sonlandır, logu dışa aktar, sonra geri aç. Bu yirmi dakikalık prova, gerçek gün geldiğinde saatler kazandırır.
Olaydan Sonra: Aynı Kapıdan İkinci Kez Girilmesini Nasıl Engellersin?
Olay kapanınca herkes rahatlar ve tam bu noktada en büyük hata yapılır: sistem eski haline döndürülür. Oysa kapatılması gereken asıl şey açık değil, açığın oluşmasına izin veren alışkanlık. Yönetici paneline ofis dışından giriliyorsa IP kısıtı koy, tek yönetici hesabı üzerinden herkes çalışıyorsa rol bazlı kullanıcı aç, tedarikçi kodları düz metin tablolarda duruyorsa şifreli saklamaya geç. E-pin satış yazılımı tarafında bu üç ayarın hepsi zaten mevcuttur; eksik olan genelde bunların açılmamış olmasıdır. Olay sonrası raporunu bir sayfayı geçmeyecek şekilde yaz: ne oldu, neyi değiştirdik, hangi kontrolü ekledik. Altı ay sonra o sayfa, işini büyütürken en çok işine yarayan dokümanın olacak.
| Kontrol maddesi | Sıklık | Durum ölçütü |
|---|---|---|
| Yönetici hesaplarında iki adımlı doğrulama açık | Sürekli | İstisnasız tüm hesaplar |
| Kritik olay bildirimleri anlık kanala bağlı | Sürekli | Test mesajı son 30 günde geçti |
| Otomatik yedek alınıyor ve geri yükleme denendi | Aylık | Deneme geri yükleme başarılı |
| İşlem kayıtları dışa aktarılabiliyor | Üç aylık | CSV çıktısı alındı |
| Script ve eklenti sürümleri güncel | Aylık | Bekleyen güncelleme yok |
| Müdahale planı yazılı ve görünür yerde | Altı aylık | Nöbetçi isimleri güncel |
| Kuru tatbikat yapıldı | Üç aylık | Süreler kayda geçti |
Müdahale planını destekleyen bir altyapıyla çalış
Kademeli teslimat kapatma, silinemez işlem kaydı, rol bazlı yetki ve anlık olay bildirimi; hepsi Pinova içinde hazır gelir. Güvenliği sonradan eklenen bir yama olarak değil, panelin iskeleti olarak kur.
Olay anında siteyi tamamen kapatmalı mıyım?
Hayır, önce kademeli kapatmayı dene. Otomatik teslimatı durdurup siparişleri kuyrukta tutmak, tam bakım moduna almaktan hem cirosal hem itibari olarak daha az zararlıdır. Tam kapatma yalnızca sunucu düzeyinde şüphe varsa gereklidir.
Log kayıtlarını ne kadar süre saklamalıyım?
Bakiye ve teslimat kayıtlarını en az on iki ay, yönetici giriş kayıtlarını en az altı ay saklamak mantıklıdır. Geri ödeme itirazları ve tedarikçi anlaşmazlıkları genelde aylar sonra gündeme gelir.
Küçük bir işletmeyim, bu plan bana fazla değil mi?
Tam tersi. Büyük işletmenin nöbetçi ekibi vardır, senin yok. Plan tek sayfa olabilir ama olmak zorunda; çünkü tek kişilik operasyonda gece yarısı kararı verecek kişi de sensin.
Müdahale planını kim yazmalı?
Teknik ekip değil, işletme sahibi yazmalı ve teknik destek gözden geçirmeli. Çünkü hangi eşikte ciro kaybını kabul edeceğine dair karar ticari bir karardır, teknik bir karar değildir.
Bu planı bugün yazmak yirmi dakikanı alır; yazmamak ise bir gece yarısında bütün stoğuna mal olabilir. Panelinin bu adımları gerçekten destekleyip desteklemediğini görmek istiyorsan canlı demo üzerinden kademeli kapatma, işlem kaydı ve rol yetkilerini kendi elinle dene; kararını da özellik listesine ve fiyatlandırmaya bakarak ver.