Çoğu satıcı güvenliği bir kalkan sanır: SSL var, panel şifresi güçlü, sunucu güncel. Oysa e-pin işinde asıl varlık sunucu değil, veritabanındaki satılmamış kodlardır. O kodlar düz metin duruyorsa, bir yedek dosyasının yanlış yere kopyalanması bile yıllık kârını silecek boyutta bir olaydır. Saldırganın sistemine girmesine bile gerek yoktur; çoğu vakada sızan şey sunucu değil, dikkatsizce alınmış bir veritabanı yedeğidir.
İkinci ve daha sinsi yanılgı şudur: "Şifreliyorum, o zaman güvendeyim." Şifreleme tek başına bir güvence değildir; güvenceyi belirleyen şey anahtarın nerede durduğudur. Anahtarı aynı veritabanında, aynı dizinde ya da kodun içinde saklıyorsan yaptığın şey kasayı kilitleyip anahtarı kilidin üstünde bırakmaktır. Bu yazıda bir e-pin satış scripti veya dijital ürün satış yazılımı değerlendirirken hangi mimari detayların gerçekten fark yarattığını, zarf şifrelemenin nasıl kurulduğunu ve bir sızıntı anında ilk saatte ne yapman gerektiğini anlatıyorum.
Düz metin kod tutan bir sistem neden zaman bombasıdır?
Düz metin stok, riskin her yerde çoğalması demektir. Kod sadece veritabanı tablosunda durmaz; gece alınan yedekte, hata ayıklama logunda, geliştirici bilgisayarındaki test kopyasında, panelden indirilen Excel dosyasında ve destek ekibinin gönderdiği e-postada da durur. Tek bir yerde bile sızarsa satılmamış tüm stoğun değeri sıfırlanır çünkü kodlar birbirinden bağımsız değil, aynı kasanın içeriğidir. Şifreleme ise bu kopyaların hepsini tek başına anlamsız hale getirir; sızan dosya, anahtar olmadan işe yaramaz bir karakter yığınıdır.
Şifreleme ile hash arasındaki farkı karıştıranlar nerede batıyor?
Hash tek yönlüdür, geri döndürülemez; parola için doğrudur çünkü parolayı geri okumana gerek yoktur, sadece doğrulaman gerekir. Kod ise geri okunmak zorundadır, çünkü müşteriye teslim edeceksin. Dolayısıyla kodlar için tersine çevrilebilir şifreleme gerekir ve doğru seçim kimlik doğrulamalı bir simetrik algoritmadır. Kimlik doğrulamalı olması şart: yalnızca gizlilik sağlayan bir mod, veriyi gizler ama kurcalanmaya karşı korumaz. Ayrıca her kayıt kendi rastgele başlangıç vektörüyle şifrelenmelidir; aynı vektörün tekrar kullanılması, farklı kodlar arasında ilişki kurulmasına kapı açar.
| Saklama yöntemi | Nasıl görünür | Gerçek koruma | Başlıca zafiyet |
|---|---|---|---|
| Düz metin | Tabloda okunabilir kod | Yok | Yedek, log, dışa aktarım |
| Base64 kodlama | Karışık görünür | Yok | Şifreleme değil, sadece kodlama |
| Şifreli, anahtar kod içinde | Düzgün görünür | Düşük | Kaynak kodu sızarsa her şey açılır |
| Şifreli, anahtar webroot dışında | Standart kurulum | Orta-yüksek | Sunucu ele geçerse okunabilir |
| Zarf şifreleme, ayrı ana anahtar | İki katmanlı | Yüksek | Kurulum disiplini gerektirir |
Anahtarı kodun içine gömmek şifrelemeyi neden geçersiz kılar?
Kaynak dosyasına gömülü bir anahtar, sürüm kontrolüne girer, yedeklere kopyalanır, geliştirici makinesine iner ve destek için gönderilen arşivde dolaşır. Yani en çok dolaşan yerde en kritik sırrı taşırsın. Doğru yaklaşım, anahtarı web kök dizininin dışında, yalnızca uygulama kullanıcısının okuyabildiği bir konumda ya da ortam değişkeninde tutmaktır. Yedekleme betiği bu dosyayı kapsam dışı bırakmalıdır; çünkü veritabanı yedeği ile anahtar aynı arşivde yan yana duruyorsa iki katmanlı korumanın ikisi de aynı anda kaybolur. Bu tek düzenleme bile, bir e-pin yazılımı kurulumunun güvenlik seviyesini bir basamak yukarı taşır.
Dijital kod sızıntılarında gözlenen kök neden dağılımı
- Korumasız yedek ve dışa aktarım dosyaları 38%
- Yetki aşımı ve paylaşılan panel hesapları 28%
- Uygulama açığı ve güncellenmemiş bileşen 20%
- Anahtarın yanlış yerde saklanması 14%
Zarf şifreleme ve anahtar rotasyonu nasıl kurulur?
Tek anahtarla çalışan sistemlerde rotasyon kâbusa döner: anahtarı değiştirmek için tüm stoğu çözüp yeniden şifrelemen gerekir. Zarf şifreleme bu sorunu ikiye bölerek çözer. Her kod, kendi veri anahtarıyla şifrelenir; veri anahtarları ise tek bir ana anahtarla şifrelenip kaydın yanında saklanır. Rotasyon geldiğinde sadece veri anahtarlarını yeniden sararsın, milyonlarca kaydı yeniden şifrelemek zorunda kalmazsın. Her şifreli kaydın yanında hangi anahtar sürümüyle şifrelendiğini gösteren bir sürüm etiketi bulunmalıdır; bu etiket olmadan kademeli geçiş yapamaz, rotasyonu tek seferlik riskli bir operasyona dönüştürürsün.
Kod ne zaman açılmalı: tek seferlik ifşa ilkesi
Şifrelenmiş stok, panelde herkese sürekli açık gösteriliyorsa şifrelemenin operasyonel değeri düşer. Doğru kurgu şudur: kod, yalnızca teslim anında ve yalnızca alıcı oturumunda çözülür, sonrasında maskelenir. Destek personeli kodu görmemeli, yalnızca durumunu görebilmelidir. Gerçekten görmesi gerektiğinde bu işlem gerekçeli, tek seferlik ve kayıt altına alınan bir erişim olmalıdır. Böylece iç kaynaklı sızıntılar hem zorlaşır hem de ispatlanabilir hale gelir. Toplu dışa aktarım yetkisi ise varsayılan olarak kapalı olmalı, açıldığında da dosya süreli bağlantıyla ve filigranlı üretilmelidir. Bu yetki modelinin nasıl kurgulandığını özellikler bölümünde görebilirsin.
Veritabanı yedeği ile şifreleme anahtarı aynı arşivde, aynı bulut klasöründe veya aynı sunucuda duruyorsa şifreleme sadece kâğıt üzerinde vardır. Bu ayrımı yapmak beş dakika sürer.
Sızıntı olduğunda ilk altmış dakikada ne yapacaksın?
Kriz anında plan yapılmaz, plan uygulanır. Sıralama şudur: önce satışı ve teslimatı durdur, sonra etkilenen partileri satıştan çek, ardından anahtar rotasyonunu başlat ve tüm panel oturumlarını sonlandır. Bunların hepsi bittikten sonra tedarikçini bilgilendirir ve hangi kodların gerçekten ifşa olduğunu log kayıtlarından çıkarırsın. Bu adımları önceden yazıp tek bir sayfada tutmak, olay anında saatler kazandırır. Unutma: dijital kodda kayıp anlıktır, çünkü ifşa olan kod dakikalar içinde kullanılır. Hızlı müdahale, kaybı yüzde yüzden yüzde ona indirebilecek tek araçtır.
| Güvenlik kontrolü | Neden gerekli | Öncelik |
|---|---|---|
| Satılmamış kodlar kimlik doğrulamalı şifreleme ile saklanıyor | Yedek sızıntısını etkisiz kılar | Kritik |
| Anahtar webroot dışında veya ortam değişkeninde | Kaynak sızıntısını ayırır | Kritik |
| Yedekleme betiği anahtarı kapsam dışı bırakıyor | İki katmanı ayrı tutar | Kritik |
| Kayıt başına rastgele başlangıç vektörü | Desen analizini önler | Yüksek |
| Anahtar sürüm etiketi ve rotasyon planı | Kademeli geçişi mümkün kılar | Yüksek |
| Teslim anında tek seferlik çözme | İç sızıntıyı daraltır | Yüksek |
| Toplu dışa aktarım varsayılan kapalı | En büyük kaçak kanalını kapatır | Yüksek |
| Yazılı altmış dakika müdahale planı | Kayıp süresini kısaltır | Orta |
Stoğunu kasaya koy, anahtarı doğru yerde tut
Pinova, e-pin ve dijital ürün satan işletmeler için lisanslı satış yönetim yazılımıdır. Şifreli kod saklama, yetki katmanları ve erişim kaydı mimarinin parçasıdır.
Kodları hash'leyebilir miyim?
Hayır. Hash geri döndürülemez ve kodu müşteriye teslim etmen gerekir. Kodlar için kimlik doğrulamalı simetrik şifreleme kullanılmalı, hash yalnızca parolalar için tercih edilmelidir.
Paylaşımlı hosting üzerinde anahtarı nerede tutmalıyım?
Web kök dizininin bir üst seviyesinde, sınırlı okuma izniyle tutulan bir dosyada veya sunucu ortam değişkeninde. Aynı klasörde ve yedeklenen dizin içinde asla bırakılmamalıdır.
Şifreleme sistemi yavaşlatır mı?
Pratikte hissedilmez. Bir siparişte çözülen kayıt sayısı çok azdır; darboğaz genellikle raporlama sorgularında olur ve bu da doğru indeksleme ile çözülür.
Anahtarı ne sıklıkla değiştirmeliyim?
Planlı olarak üç ayda bir, şüpheli bir erişim veya personel değişimi durumunda ise derhal. Zarf şifreleme kurulmuşsa bu işlem dakikalar sürer ve stoğu yeniden şifrelemeyi gerektirmez.
Güvenlik, bu işte pazarlama cümlesi değil doğrudan bir stok koruma kalemidir: kasandaki kodlar sızarsa sattığın ürün de, müşteri güvenin de aynı anda gider. Şifreleme, anahtar ayrımı, rotasyon ve tek seferlik ifşa ilkesini kurduğunda riski yönetilebilir bir seviyeye indirirsin. Paketleri fiyat bölümünden karşılaştırabilir, yetki katmanlarının ve kod teslim akışının gerçekte nasıl çalıştığını canlı demo üzerinde deneyebilirsin.