Çoğu kişi e-pin stoğunun "veritabanında durduğu için" güvende olduğunu sanır. Panelde kodlar görünür, sipariş gelince müşteriye gider, gün sonunda bakiye tutar; her şey yolunda gibidir. Oysa senin envanterin dosya sunucusunda duran bir ürün değil; okunabilir bir metin. Bir ürünü çalmak için depoya girmek gerekir, bir e-pini çalmak için tek bir SELECT yetkisi yeter. Bu yüzden e-pin işinde asıl risk "hacklenmek" değil, hacklendiğinde zararın ne kadar büyüyeceğidir.
Ama işin ilginç tarafı şu: sektördeki çoğu e-pin scripti kodları hâlâ düz metin saklıyor ve bunu bir eksiklik olarak bile görmüyor. Çünkü şifreleme yokken her şey daha hızlı çalışır, arama kolaydır, destek ekibi kodu tek tıkla görür. Kolaylık ile güvenlik arasındaki bu takas, sızıntı gününe kadar hiç kimseyi rahatsız etmez. O gün geldiğinde ise fark şudur: şifreli stokta saldırgan anlamsız karakter yığını görür, düz metin stokta ise senin üç aylık kârını cebine koyar. Bu yazıda AES'in e-pin tarafında nasıl doğru kurulduğunu, anahtarın nereye konduğunu ve dijital ürün satış yazılımı seçerken hangi soruları sorman gerektiğini tek tek açıyorum.
Veritabanı sızıntısı neden "kod çalınması" ile aynı şey değil?
Bir e-ticaret sitesi sızdığında müşteri verisi gider; üzücüdür ama ürün rafta kalır. E-pin işinde ise veritabanının kendisi kasadır. Yedek dosyası, phpMyAdmin dökümü, yanlış izin verilmiş bir klasör ya da eski bir geliştiricinin elinde kalan bir .sql dosyası doğrudan nakit demektir. Daha kötüsü, kod çalındığında bunu anında fark etmezsin: satış olmadan stok azalmaz, bakiye oynamaz, alarm çalmaz. Müşteri "kodum kullanılmış" diye yazdığında olay çoktan bitmiştir.
Şifreleme burada devreye girer ama amacı yanlış anlaşılır. AES seni saldırıdan korumaz; saldırının sonucunu değersizleştirir. Doğru kurulmuş bir e-pin satış scriptinde veritabanı tek başına işe yaramaz, çünkü çözme anahtarı orada değildir. Saldırganın hem veritabanını hem uygulama dosyalarını hem de webroot dışındaki anahtar deposunu aynı anda ele geçirmesi gerekir. Bu üç katmanı birlikte kırmak, tek bir SQL açığından çok daha zordur. Güvenlik dediğimiz şey aslında budur: tek bir hatanın toplam kayba dönüşmesini engellemek.
AES-256-GCM neden ECB veya CBC'den farklı bir dünya?
Piyasada "AES kullanıyoruz" cümlesini duyunca rahatlama. Hangi mod kullanıldığı en az algoritma kadar önemli. ECB modu aynı girdiyi her zaman aynı çıktıya çevirir; yani aynı kupon serisinden 500 kod yüklediysen veritabanında tekrarlayan desenler oluşur ve saldırgan hiç çözmeden hangi kayıtların aynı ürüne ait olduğunu anlar. CBC modu bunu düzeltir ama bütünlük doğrulaması yapmaz: biri şifreli veriyi kurcalarsa uygulama bunu fark etmez, bozuk kod müşteriye gider.
GCM modu ise şifreleme ile birlikte bir doğrulama etiketi üretir. Kayıt tek bit değişse çözme işlemi hata verir, uygulama "bu veri bozulmuş" diyerek teslimatı durdurur. E-pin tarafında bu özellik para kadar değerlidir, çünkü hatalı teslimatın maliyeti iade değil itibar kaybıdır. Ayrıca her kayıt için rastgele ve tekrar kullanılmayan bir IV üretilmesi şarttır. Sabit IV ile GCM kullanmak, kapıya kilit takıp anahtarı kilidin üstünde bırakmakla aynı şey. Pinova'nın stok katmanında kayıt başına ayrı IV üretilmesi ve etiketin ayrı sütunda tutulması bu yüzden pazarlama cümlesi değil, mimari zorunluluk.
| Saklama yöntemi | Sızıntıda kod okunur mu? | Bütünlük kontrolü | Desen sızdırır mı? | E-pin için uygun mu? |
|---|---|---|---|---|
| Düz metin | Evet, anında | Yok | Tamamı açık | Hayır |
| Base64 "gizleme" | Evet, saniyeler içinde | Yok | Tamamı açık | Hayır |
| MD5/SHA hash | Okunamaz ama geri de alınamaz | Dolaylı | Hayır | Hayır (teslimat imkânsız) |
| AES-256-ECB | Zor | Yok | Evet, tekrar desenleri | Kısmen |
| AES-256-CBC | Zor | Yok | Hayır | Kabul edilebilir |
| AES-256-GCM + kayıt bazlı IV | Pratikte hayır | Var (auth tag) | Hayır | Evet, önerilen |
Anahtarı nereye koyuyorsun? İşin gerçek sırrı burada
Şifrelemenin en çok sabote edildiği yer algoritma değil, anahtarın konumu. Anahtarı config.php içine yazıp o dosyayı webroot altında bırakan bir kurulum, şifrelemeyi tamamen kâğıt üstünde bırakır. Çünkü çoğu gerçek olayda saldırgan dosya okuma yetkisi de kazanır; veritabanı ile config aynı sunucuda, aynı klasör ağacında duruyorsa iki kapıyı tek hamlede açar.
Doğru yaklaşım şu sırayla ilerler: anahtar webroot'un dışında, web sunucusunun servis edemediği bir dizinde tutulur; dosya izni yalnızca çalışan kullanıcıya okuma verecek şekilde daraltılır (0400 veya 0440); anahtar ortam değişkeni ya da sunucu seviyesi yapılandırma ile uygulamaya aktarılır; git deposuna asla girmez. İleri seviyede ana anahtar (master key) ile veri anahtarları ayrılır: her kod grubu kendi veri anahtarıyla şifrelenir, veri anahtarları ise ana anahtarla şifreli olarak saklanır. Böylece ana anahtarı değiştirdiğinde milyonlarca kaydı yeniden şifrelemek zorunda kalmazsın, sadece veri anahtarlarını yeniden sararsın. Ciddi bir epin yazılım altyapısında bu ayrım baştan yapılır, sonradan eklemek acı verir.
E-pin sızıntılarında kök nedenin dağılımı
- Düz metin stok + veritabanı erişimi 40%
- Anahtarın webroot içinde tutulması 30%
- Korumasız yedek/döküm dosyaları 18%
- Panel yetki hatası ve iç kullanıcı 12%
Şifreli stokta arama, raporlama ve destek nasıl çalışır?
En sık duyduğum itiraz şu: "Şifrelersem kodu arayamam, destek ekibi çalışamaz." Bu doğru bir endişe ama çözülmüş bir problem. Kodun kendisini şifrelerken, yanına aranabilir bir parmak izi koyarsın: kodun tuzlanmış HMAC özeti. Müşteri "şu kod bana geldi, kullanılmış çıktı" dediğinde kodu HMAC'ten geçirip veritabanında o özeti ararsın; tek sorguda kaydı bulursun, ama veritabanı hiçbir zaman kodun kendisini barındırmamış olur.
Aynı mantık raporlamada da geçerli. Son dört hane, ürün kimliği, parti numarası, yükleme tarihi gibi hassas olmayan alanlar açık kalır; satış grafikleri, kâr hesapları ve stok uyarıları bu alanlar üzerinden çalışır. Destek ekranında kodun tamamı yerine maskeli hali gösterilir, "tam kodu göster" işlemi ayrı yetki ister ve kayıt altına alınır. Dijital ürün satış scripti tarafında bu detay, bir gün "kod sızdı mı, kim gördü" sorusunu cevaplamanın tek yoludur.
Mevcut düz metin stoğu tek seferde çevirmeye çalışma. Yeni sütunları ekle, arka planda parti parti şifrele, her partiden sonra rastgele on kaydı çözerek doğrula, ancak hepsi doğrulandıktan sonra eski sütunu düşür. Geçiş sırasında yedeğini şifreli kopyayla birlikte al; dönüşüm yarıda kalırsa geri dönebileceğin tek nokta odur.
Anahtar rotasyonu ve yedek şifrelemesi neden atlanıyor?
Şifrelemeyi kuran işletmelerin çoğu ikinci adımı hiç atmıyor: anahtarı değiştirmek. Oysa personel ayrıldığında, sunucu taşındığında ya da bir şüphe oluştuğunda anahtarın değişmesi gerekir. Veri anahtarı mimarisi varsa bu iş dakikalar sürer; yoksa tüm stoku yeniden şifrelemek gerekir ve bu yüzden hiç yapılmaz. Rotasyonu takvime bağla: yılda bir planlı, şüphe halinde derhal.
Yedekler ise en çok ihmal edilen delik. Uygulama katmanında şifrelenmiş stok, yedek alınırken zaten şifreli kalır; ama anahtarı da aynı yedeğin içine koyarsan tüm çabayı boşa çıkarırsın. Anahtar ve veri asla aynı paketle, aynı bulut klasöründe, aynı erişim yetkisiyle durmamalı. Yedeklerin kendisi de ayrı bir parola ile şifrelenmeli ve o parola yedeğin yanında değil, farklı bir kasada tutulmalı. Bir de şu var: geri yükleme provası yapmadığın yedek, yedek değildir. Yılda bir kez boş bir kurulumda geri yükleyip stokun çözülebildiğini test et.
Script seçerken hangi üç soruyu sorarsan gerçeği anlarsın?
Bir e-pin satış yazılımı incelerken demo ekranlarına bakmak yetmez. Şu üç soruyu sor: Birincisi, "stok tablosunda kodlar hangi modla şifreli ve IV kayıt başına mı üretiliyor?" Cevap net bir mod adı değilse şifreleme büyük olasılıkla yoktur. İkincisi, "anahtar nerede duruyor ve değiştirmek için ne yapmam gerekiyor?" Cevap "config dosyasında" ise mimari zayıftır. Üçüncüsü, "tam kodu kim, hangi yetkiyle görebiliyor ve bu kayıt altına alınıyor mu?"
Bu üç sorunun cevabı, yazılımın güvenliği ciddiye alıp almadığını on dakikada ortaya çıkarır. Pinova tarafında stok katmanı baştan bu üç varsayımla tasarlandı: kayıt bazlı IV ile AES, webroot dışı anahtar, maskeli görüntüleme ve yetki bazlı açığa çıkarma kaydı. Detayları özellikler bölümünde görebilir, lisans seçeneklerini fiyat tarafında karşılaştırabilirsin. Unutma: e-pin işinde güvenlik bir pazarlama başlığı değil, envanterinin sigortasıdır.
Stoğun şifreli, anahtarın yerinde olsun
Kod envanterini AES ile saklayan, anahtarı webroot dışında tutan ve her açığa çıkarmayı kayda geçen bir altyapıyla çalış.
Kodları hash'leyerek saklayabilir miyim?
Hayır. Hash tek yönlüdür, geri çevrilemez; müşteriye teslim etmen gereken kodu hash'ten üretemezsin. Hash'i yalnızca aranabilir parmak izi olarak, asıl kodu AES ile şifreli tutarak kullan.
AES şifreleme sitemi yavaşlatır mı?
Pratikte hayır. Modern sunucularda AES donanım hızlandırmalı çalışır ve tek bir kodun şifrelenmesi mikrosaniyeler sürer. Satış akışına eklenen gecikme ölçülebilir seviyenin altındadır; darboğaz neredeyse her zaman veritabanı sorguları ve dış API çağrılarıdır.
Anahtarı kaybedersem stoğuma ne olur?
Şifreli veri kalıcı olarak açılamaz hale gelir. Bu yüzden anahtarın en az iki bağımsız yerde, veriden ayrı ve erişimi kısıtlı biçimde yedeklenmesi gerekir. Anahtar yedeği olmayan bir şifreleme kurulumu, güvenlik değil risktir.
Paylaşımlı hostingde bu mimari kurulabilir mi?
Kısmen. Webroot dışı bir dizine anahtar koyabildiğin ve dosya izinlerini daraltabildiğin sürece işleyen bir kurulum yapılabilir. Ancak komşu hesap riskini azaltmak için ciddi hacimlerde kendi sunucun ya da izole bir ortam tercih edilmeli.
| Kontrol | Ne bakacaksın | Geçer ölçüt | Durum |
|---|---|---|---|
| Şifreleme modu | Stok tablosundaki kod sütunu | AES-256-GCM veya CBC | ☐ |
| IV üretimi | Kayıt başına IV var mı | Her kayıt için rastgele | ☐ |
| Anahtar konumu | Dosya yolu ve izinler | Webroot dışı, 0400 | ☐ |
| Depo hijyeni | Git geçmişi ve .gitignore | Anahtar hiç commit edilmemiş | ☐ |
| Aranabilirlik | HMAC parmak izi sütunu | Var ve tuzlu | ☐ |
| Maskeleme | Destek ekranı görünümü | Son 4 hane, yetkili açığa çıkarma | ☐ |
| Açığa çıkarma kaydı | Kim hangi kodu gördü | Zaman damgalı log | ☐ |
| Yedek ayrımı | Anahtar ve veri aynı pakette mi | Ayrı kasa, ayrı parola | ☐ |
| Rotasyon | Anahtar değiştirme prosedürü | Yazılı, yılda bir uygulanmış | ☐ |
| Geri yükleme provası | Son test tarihi | 12 aydan yeni | ☐ |
Bu listeyi eline alıp mevcut kurulumunu on dakika içinde puanlayabilirsin; çıkan tablo genelde tahmin ettiğinden daha düşük olur ve bu iyi bir haberdir, çünkü nereden başlayacağını gösterir. Kendi altyapında şifreli stok akışının satış, teslimat ve destek ekranlarında nasıl göründüğünü kendi gözünle görmek istersen canlı demo üzerinden sipariş oluşturup kodun maskeli haliyle nasıl teslim edildiğini adım adım izleyebilirsin.