Dijital Ürün Satış Scriptinde Veri Şifreleme Katmanları: Panelinde Bekleyen O E-Pin Kodları Gerçekte Kaç Kişinin Gözü Önünde Duruyor?

Panelinde bekleyen stok listesine bir bak. Oyun kodları, lisans anahtarları, hesap bilgileri, bakiye yükleme pinleri. Bunların hepsi tek bir SELECT sorgusuyla okunabilecek düz metin halinde mi duruyor? Çoğu işletme sahibi bu soruya "hayır, benim sistemim şifreli" diye cevap veriyor. Sonra biraz kazıyınca ortaya çıkan tablo şu oluyor: sitede HTTPS var, veritabanı parolası uzun, admin paneline 2FA eklenmiş. Bunlar güzel şeyler ama hiçbiri stok verisinin şifreli olduğu anlamına gelmiyor.

Şifreleme, tek satırlık bir ayar değil; üst üste binen katmanlardan oluşan bir mimari. Ve bu katmanların hangisinin eksik olduğunu genellikle iş işten geçtikten sonra öğreniyorsun: bir hosting sızıntısı, işten ayrılan bir çalışan, yanlış yapılandırılmış bir yedek dosyası. Bu yazıda bir dijital ürün satış scriptinin veri güvenliğini dört katmana ayırıp her birinde nerede açık kaldığını, hangi soruyu sorman gerektiğini ve sağlam bir e-pin yazılımının bunu nasıl çözdüğünü anlatıyorum.

Çoğu e-pin scripti "şifreli" derken aslında neyi kastediyor?

Piyasada dolaşan pek çok e-pin satış scripti için şifreleme kelimesi, kullanıcı parolalarının hash'lenmesinden ibaret. Yani müşterinin parolası bcrypt ile saklanıyor, dolayısıyla "veriler şifreli" cümlesi teknik olarak yanlış olmuyor. Ama senin işinin can damarı müşteri parolası değil; satılabilir değeri olan stok kodu. Parola sızarsa müşteri parolasını değiştirir. Stok kodu sızarsa o kod bir başkası tarafından kullanılır ve sen hem ürünü hem parayı hem de müşterinin güvenini aynı anda kaybedersin.

Bu yüzden ilk yapman gereken şey, satıcıdan "şifreleme var mı" değil, "stok tablosundaki kod alanı diskte hangi biçimde duruyor" diye sormak. Cevap "düz metin ama panel yetkisi olmayan göremiyor" ise elinde şifreleme yok, sadece erişim denetimi var. İkisi farklı şeyler: erişim denetimi uygulama katmanında çalışır, uygulamayı atlayan biri için hiçbir anlamı kalmaz.

Katman 1: Diskte duran kod, yani at-rest şifreleme neden tek başına yetmez?

İlk katman, verinin diskte şifreli durması. Burada iki farklı yaklaşım var ve aralarındaki fark hayati. Birincisi disk veya veritabanı seviyesinde şifreleme: sunucunun diski şifreli, veritabanı dosyaları şifreli. Bu, sunucu fiziksel olarak çalınırsa veya bir imaj kopyalanırsa işe yarar. Ama veritabanı ayakta ve bağlantı kurulabiliyorsa, sorgu atan herkes veriyi düz metin görür. Yani en sık yaşanan senaryoda, sızdırılmış bir veritabanı parolası veya bir SQL enjeksiyonunda, disk şifrelemesi hiçbir şeye engel olmaz.

İkinci yaklaşım alan bazlı şifreleme: kod, veritabanına yazılmadan önce uygulama tarafında şifrelenir. AES-256-GCM gibi kimliği doğrulanmış bir şifreleme kullanılır, her kayıt için ayrı bir başlangıç vektörü üretilir ve veritabanına giden şey anlamsız bir bayt dizisi olur. Bu durumda veritabanını ele geçiren biri elinde işe yaramayan bir liste taşır. Doğru kurulmuş bir dijital ürün satış yazılımında stok kodu, teslimat anına kadar hiçbir yerde çözülmüş halde durmaz; teslimat sırasında bellekte çözülür, müşteriye gösterilir ve kayıt "kullanıldı" olarak işaretlenir.

Katman 2: Anahtar nerede duruyor? Asıl açık kapı tam burası

Şifrelemenin en çok yanlış yapılan tarafı algoritma seçimi değil, anahtar yönetimi. Kodu AES ile şifreleyip anahtarı aynı veritabanındaki bir settings tablosuna yazan sistemler gördüm. Bu, kasayı kilitleyip anahtarı kasanın üstüne bırakmak. Aynı şekilde anahtarı config.php içine yazmak da riskli: bir dizin listeleme hatası, yanlış izinli bir yedek dosyası veya .php.bak uzantılı bir artık dosya her şeyi ifşa eder.

Doğru kurgu şu: ana anahtar webroot dışında, web sunucusunun servis edemeyeceği bir yolda veya ortam değişkeninde tutulur. Tercihen iki kademeli çalışılır. Ana anahtar yalnızca veri anahtarlarını şifreler, veri anahtarları da kayıtları şifreler. Böylece anahtar değiştirmek istediğinde milyonlarca kaydı yeniden şifrelemek zorunda kalmazsın, sadece veri anahtarlarını yeniden sarmalarsın. Rotasyon planı olmayan bir şifreleme, ilk şüpheli olayda seni çaresiz bırakır çünkü "anahtarı değiştirelim" demek tüm stoku yeniden işlemek anlamına gelir.

Katman 3: Taşıma, oturum ve panel içi görünürlük

Veri diskte şifreli olsa bile bir noktada ekrana çıkacak. Bu "çıkış" noktasını kim, ne kadar görebiliyor? Pratikte en büyük veri kaybı dramatik bir saldırıdan değil, panelde stok listesini açıp tüm kodları ekranda görebilen bir operatör hesabından kaynaklanıyor. Bu yüzden üçüncü katman, teslimat anına kadar hiçbir arayüzde tam kodun görünmemesi. Liste ekranlarında kod maskelenir, yalnızca son dört karakter gösterilir. Tam kodu görmek ayrı bir yetki, ayrı bir onay ve mutlaka bir kayıt gerektirir.

Taşıma katmanında ise iş HTTPS ile bitmiyor. Bayi API'lerine giden yanıtlar, webhook çağrıları, e-posta ile gönderilen teslimat bildirimleri de birer taşıma kanalı. Kodu e-posta gövdesine düz metin yazan bir epin yazılım kurgusu, şifrelemenin tüm faydasını tek hamlede sıfırlıyor; çünkü e-posta sunucularında veri senin denetiminde olmayan bir yerde, uzun süre, arşivlenmiş halde durur. Doğrusu, mesajda tek kullanımlık ve süresi sınırlı bir görüntüleme bağlantısı göndermek.

Katman 4: Kim ne zaman gördü? Denetim izi olmadan şifreleme bir hikâyedir

Dördüncü katman, olay sonrası yanıt verebilme kabiliyeti. Bir stok kodu iki kere kullanıldığında veya müşteri "kodum çalışmıyor" dediğinde eline ne geliyor? Kaydın hangi personel tarafından, hangi saatte, hangi oturumdan görüntülendiğini gösteren değiştirilemez bir iz olmalı. Bu izler kullanıcıların silemeyeceği bir tabloda tutulmalı, ideal olarak her kayda önceki kaydın özetini karıştıran zincirleme bir yapıyla korunmalı; böylece bir satır silindiğinde zincir kırılır ve müdahale anlaşılır.

Denetim izi aynı zamanda caydırıcıdır. Operatörün her tam kod görüntülemesinin kayda geçtiğini bilmesi, uygulanabilir hiçbir teknik önlemin sağlamadığı bir disiplini getirir. Ekibe "sistem kim baktı kim bakmadı görüyor" diyebilmek, en pahalı güvenlik yatırımlarından daha hızlı sonuç verir.

Pinova bu katmanları nasıl diziyor?

Pinova, bir e-pin pazaryeri değil; bu işi yapan işletmelerin kullandığı e-pin satış yazılımı. Dolayısıyla tasarım önceliği, stokun senin kontrolünde ve şifreli durması. Stok kodları alan bazlı şifreleme ile saklanır, anahtar dosyası web kökünün dışında konumlanır, panelde kodlar maskeli listelenir ve tam görüntüleme ayrı yetkiye bağlıdır. Her görüntüleme, her teslimat ve her manuel müdahale kayıt altına alınır; bayi API'sine dönen yanıtlar da aynı maskeleme kurallarına tabidir.

Bunların hepsini kendi yazdığın bir altyapıda kurmak imkânsız değil ama zaman ve uzmanlık ister. Hazır bir sistemi değerlendirirken sorman gereken soruları bir kontrol listesine indirdim. Satıcıyla konuşurken bu listeyi tek tek geçirmen, hangi tarafın gerçekten hazırlıklı olduğunu ilk on dakikada gösterir. Özellik kıyasını özellikler bölümünden, paket farklarını fiyat tablosundan inceleyebilirsin.

Şifreleme bir ürün özelliği değil, işletme alışkanlığı. Katmanları tek tek kurduğunda kötü bir gün yaşamaya devam edersin ama o gün işini kaybetmezsin. Bu mimarinin hazır kurulu halini kendi gözünle görmek istersen canlı demo üzerinden panele girip maskeli stok listesini, denetim izini ve teslimat akışını test siparişiyle birlikte deneyebilir, ardından paket seçimine geçebilirsin.