Çoğu e-pin satıcısı stok güvenliğini tek bir cümleyle özetler: "Kodlar veritabanında duruyor, sunucuya kimse giremez." Bu cümle, sektörde yaşanan stok sızıntılarının neredeyse tamamının arkasındaki yanlış varsayımdır. Çünkü bir kodun çalınması için sunucunun tümüyle ele geçirilmesi gerekmez. Yanlış klasörde kalmış tek bir yedek dosyası, hosting taşıma sırasında WhatsApp'tan gönderilen bir .sql dökümü, panele bir hafta erişimi olan eski bir destek elemanının ekran görüntüsü ya da bakım için verdiğin geçici phpMyAdmin şifresi yeter. Kod dediğin şey sonuçta düz metindir; düz metin ise kopyalandığı anda senin kontrolünden tamamen çıkar.
İşin konuşulmayan tarafı şu: piyasadaki pek çok e-pin scripti stok kodlarını hâlâ olduğu gibi, sıradan bir metin kolonunda tutar. Bunu kötü niyetten değil, kolaylıktan yapar; çünkü şifrelenmiş kodun üstünde arama yapmak, toplu içe aktarmak ve "bu kod kime gitti" sorusunu cevaplamak zahmetlidir. Ama zahmetten kaçmanın faturası, bir sabah uyandığında 4.000 adet kullanılmamış kodun forumlarda dolaşması olarak geliyor. Bu yazıda sana şifrelemenin hangi katmanda yapılacağını, anahtarın nerede duracağını, anahtar rotasyonunun gerçekte nasıl işlediğini ve bir e-pin satış yazılımı değerlendirirken hangi soruları sormanı gerektiğini anlatacağım.
Neden "sunucum güvenli" demek artık bir güvenlik önlemi sayılmıyor?
Güvenlikte tek bir duvara yaslanmak, o duvarın arkasındaki her şeyi tek bir olaya bağlamak demektir. Sunucu erişiminin güvenli olduğu varsayımı, kodların düz metin durmasını haklı çıkarmaz; sadece riski görünmez kılar. Doğru soru "sunucuma girilebilir mi" değil, "girildiğinde saldırganın eline ne geçer" sorusudur. Kodlar şifreliyse ve anahtar veritabanının yanında durmuyorsa, çalınan bir döküm dosyası saldırgan için işe yaramaz bir karakter yığınıdır. Şifreleme, saldırıyı engellemez; saldırının değerini sıfıra indirir. Bu ayrımı kavradığın gün stok yönetimine bakışın değişir.
Hangi katmanda şifrelemek gerçekten işe yarıyor?
Burada üç seçenek var ve üçü aynı şey değil. Disk şifreleme, sunucu çalışırken her şeyi açık gösterdiği için sızıntıya karşı neredeyse hiçbir şey yapmaz. Veritabanı seviyesindeki şifreleme, bağlantıyı ele geçiren birine karşı yine açık kalır. Gerçekten koruyan tek yaklaşım uygulama seviyesinde şifrelemedir: kod, veritabanına yazılmadan önce uygulama tarafında şifrelenir ve yalnızca müşteriye teslim edileceği o tek anda çözülür. Bu yüzden ciddi bir dijital ürün satış scripti değerlendirirken "şifreleme var mı" diye değil, "şifreleme hangi katmanda" diye sormalısın.
Algoritma tarafında da kafa karışıklığı büyük. Basit XOR, base64 veya geri döndürülebilir bir hash "şifreleme" değildir. İhtiyacın olan şey, hem gizlilik hem bütünlük sağlayan kimlik doğrulamalı bir şifrelemedir: pratikte AES-256-GCM. Her kayıt için ayrı ve rastgele bir IV üretilir, çıktının yanında kimlik doğrulama etiketi saklanır. Böylece biri veritabanındaki şifreli metni elle oynayıp bozmaya kalkarsa, çözme işlemi sessizce yanlış sonuç vermez, doğrudan hata verir. Bu davranış, teslimat hatalarını sessiz kalmadan yakalamanı sağlar.
| Yaklaşım | Döküm sızarsa | Panel ele geçerse | Arama/filtre | Kurulum yükü |
|---|---|---|---|---|
| Düz metin kolon | Tüm stok açık | Tüm stok açık | Çok kolay | Yok |
| Geri döndürülebilir basit maskeleme | Birkaç saatte açılır | Tüm stok açık | Kolay | Çok düşük |
| Disk / dosya sistemi şifreleme | Yedek açıksa etkisiz | Tüm stok açık | Değişmez | Düşük |
| AES-256-GCM, anahtar aynı sunucuda | Anahtar da sızarsa açık | Sınırlı koruma | Parmak izi kolonu gerekir | Orta |
| AES-256-GCM + webroot dışı anahtar + sürümleme | Anlamsız veri | Yalnızca görülen kayıtlar | Parmak izi + indeks | Orta-yüksek |
| Zarf şifreleme (ana anahtar ayrı serviste) | Anlamsız veri | Hız sınırıyla frenlenir | Aynı | Yüksek |
Anahtarı nereye koyduğun, algoritmadan daha önemli değil mi?
Doğru algoritmayı seçip anahtarı kodun içine gömmek, çelik kapı taktırıp anahtarı kapının üstündeki saksıya bırakmaktır. Anahtar asla sürüm kontrolüne, asla web kök dizinine, asla veritabanına girmez. Doğru yer, web erişimi olmayan üst bir dizindeki dosya veya işletim sistemi seviyesinde tanımlı bir ortam değişkenidir. Dosya izinleri yalnızca uygulama kullanıcısına okuma verecek şekilde daraltılır. Bir adım ötesi zarf şifrelemedir: her stok partisi kendi veri anahtarıyla şifrelenir, o veri anahtarı da ayrı tutulan bir ana anahtarla şifrelenir. Böylece ana anahtarı değiştirmek için milyonlarca kaydı yeniden şifrelemek zorunda kalmazsın.
Gerçek stok sızıntılarının kaynak dağılımı
- Korumasız yedek / veritabanı dökümü 45%
- Fazla yetkili panel ve eski personel erişimi 25%
- Uygulama açığı ve zayıf oturum yönetimi 20%
- Tedarikçi tarafı ve diğer 10%
Anahtar rotasyonu tam olarak nasıl yapılır, sistemi durdurmak gerekir mi?
Rotasyon, "anahtarı değiştirdim" demek değildir. Eski anahtarla şifrelenmiş binlerce kayıt hâlâ ortada olduğu için, tek anahtarla çalışan bir kurulumda anahtar değiştirmek doğrudan veri kaybıdır. Çözüm şaşırtıcı derecede basit: her şifreli kaydın yanına bir anahtar sürümü alanı koymak. Uygulama çözerken kaydın sürümüne bakar, o sürümün anahtarını kullanır; şifrelerken ise her zaman en güncel sürümü kullanır. Böylece iki anahtar bir süre yan yana yaşar ve sistem tek saniye durmaz.
Bundan sonrası kademeli geçiştir. Yeni gelen stok doğrudan yeni sürümle yazılır. Eski kayıtlar ise arka planda küçük partiler hâlinde okunup yeniden şifrelenir; genellikle gece saatlerinde çalışan bir görevle, her seferinde birkaç bin kayıt. Tüm kayıtlar yeni sürüme geçtiğinde eski anahtar devre dışı bırakılır ama en az bir rotasyon dönemi boyunca çevrimdışı bir yerde saklanır; çünkü göçün gözden kaçan bir tablosu çıkabilir. Acil rotasyon, yani anahtarın sızdığından şüphelendiğin durum, aynı mekanizmanın hızlandırılmış hâlidir: yeni sürüm devreye alınır, göç beklemeye alınmadan başlatılır ve etkilenen partiler tedarikçiyle iptal-yenileme sürecine sokulur.
Aynı kodun iki kez yüklenmesini engellemek için kodun kendisini aramaya çalışma. Kodun tuzlu bir HMAC özetini ayrı bir kolona yaz ve o kolona tekil indeks koy. Böylece mükerrer kontrolünü şifreyi hiç çözmeden yaparsın; hız da kaybolmaz.
Şifreleme kimin kodu gördüğünü nasıl kayda geçirir?
Şifrelemenin en az bilinen faydası şudur: çözme işlemini tek bir fonksiyona hapsettiğin anda, kodu kimin ne zaman gördüğünü ölçebilir hâle gelirsin. Her çözme çağrısı; hangi yönetici, hangi sipariş, hangi IP ve hangi oturumla yapıldığı bilgisiyle loglanır. Bir hafta sonra "bu 120 kod nasıl sızdı" sorusunun cevabı tahmin değil, kayıt olur. Üstüne bir de hız sınırı koyarsın: normal bir gün içinde bir yönetici hesabının kaç kodu açtığı bellidir; bu eşik aşıldığında hesap otomatik olarak dondurulur ve sana bildirim gider.
Pinova bu noktada tam olarak bunu yapıyor. Pinova bir e-pin satış yazılımıdır; yani kendisi kod satmaz, kodu satan işletmenin altyapısını kurar. Stok kodları kimlik doğrulamalı şifrelemeyle saklanır, anahtar web kökünün dışında tutulur, kayıt başına anahtar sürümü yazılır ve rotasyon göçü arka planda kademeli yürür. Çözme erişimi rol bazlı sınırlanır, her çözme denetim kaydına düşer. Bu düzeneği sıfırdan yazmak aylar alır; hazır bir epin yazılım altyapısında ilk günden çalışır durumda gelir.
Yedekler, dışa aktarımlar ve tedarikçi dosyaları ne olacak?
Şifrelemenin en sık atlanan kör noktası, veritabanının dışına çıkan kopyalardır. Tedarikçiden gelen Excel dosyası indirdiğin klasörde kalır; panelden aldığın "stok raporu" CSV'si düz metin kodları içerir; otomatik yedek, anahtar dosyasıyla aynı arşive girer. Bu üç alışkanlık, ne kadar iyi şifrelersen şifrele koruma seviyesini düz metne geri düşürür. Kural nettir: dışa aktarım çıktılarında kod alanı varsayılan olarak maskelenir, tam kod yalnızca özel yetkiyle ve loglanarak alınır; yedek arşivi anahtardan ayrı yerde tutulur; içe aktardığın kaynak dosya, işlem tamamlanınca sunucudan silinir.
| Kontrol maddesi | Ne aramalısın | Durum |
|---|---|---|
| Şifreleme katmanı | Uygulama seviyesinde, AES-256-GCM | Zorunlu |
| Anahtar konumu | Web kökü dışında dosya veya ortam değişkeni | Zorunlu |
| Anahtar sürümü kolonu | Her şifreli kayıtta sürüm numarası | Zorunlu |
| Mükerrer kontrolü | Tuzlu HMAC parmak izi + tekil indeks | Zorunlu |
| Kademeli rotasyon görevi | Partili yeniden şifreleme, kesintisiz | Önerilir |
| Çözme denetim kaydı | Kullanıcı, IP, sipariş, zaman | Zorunlu |
| Çözme hız sınırı | Eşik aşımında otomatik dondurma | Önerilir |
| Dışa aktarımda maskeleme | Varsayılan kapalı, yetkiyle açık | Zorunlu |
| Yedek ayrımı | Anahtar ve veri farklı konumda | Zorunlu |
| Acil rotasyon prosedürü | Yazılı, denenmiş, tek komutla | Önerilir |
Stok kodlarını ilk günden şifreli tut
Şifreleme, anahtar sürümleme ve kademeli rotasyon hazır gelen bir altyapıyla başla; bunları sonradan eklemek çok daha pahalı.
Şifreleme sistemi yavaşlatır mı?
Pratikte hayır. AES işlemleri modern işlemcilerde donanım destekli çalışır ve bir kodun çözülmesi mikrosaniyelerle ölçülür. Yavaşlama hissi, kodun kendisi üzerinde arama yapmaya çalışan kötü tasarımdan doğar; parmak izi kolonu kullanıldığında sorgu hızı değişmez.
Anahtarı kaybedersem kodlar tamamen gider mi?
Evet, doğru kurulmuş bir sistemde kaybedilen anahtar geri dönüşü olmayan veri kaybı anlamına gelir. Bu yüzden anahtarın çevrimdışı, şifreli ve en az iki ayrı fiziksel konumda yedeği tutulur; yedek geri yükleme tatbikatı yılda bir denenir.
Rotasyon sırasında satış durur mu?
Durmaz. Kayıt başına anahtar sürümü tutulduğu için eski ve yeni anahtar bir süre birlikte çalışır. Yeni stok yeni sürümle yazılırken eski kayıtlar arka planda partiler hâlinde geçirilir, müşteri tarafında hiçbir fark görünmez.
Küçük ölçekli satıcı için bu fazla karmaşık değil mi?
Karmaşıklık senin tarafında olmamalı. Bu mekanizmalar altyapının içinde hazır çalışıyorsa sen yalnızca stok yüklüyor ve satıyorsun. Sızıntı riski küçük ölçekte de aynıdır; fark, küçük işletmenin bir sızıntının maliyetini karşılamasının daha zor olmasıdır.
Stok kodlarının şifrelenmesi bir "ileri seviye özellik" değil, bu işin asgari şartıdır; anahtar rotasyonu ise o şifrelemenin zamanla çürümesini engelleyen bakım işidir. İkisini birlikte kuran bir e-pin scripti seni hem sızıntı anında hem de büyüme anında korur. Altyapının bunları nasıl yaptığını okumak yerine çalışırken görmek istersen özellik listesine ve fiyat tablosuna göz at, ardından canlı demo üzerinden stok yükleme, teslimat ve denetim kaydı akışını kendi elinle dene.