Bir e-pin sitesi kurduğunuzda genelde ilk aklınıza gelen şey "sipariş gelsin, kod otomatik gitsin" olur. Ama işin görünmeyen tarafında çok daha kırılgan bir katman var: müşterinizin adı, e-postası, telefon numarası, IP adresi, ödeme geçmişi ve bazen kimlik bilgileri sizin sunucunuzda, sizin veritabanınızda oturuyor. Bir e-pin scripti aslında küçük bir bankacılık uygulaması kadar hassas veri taşır — sadece kimse bunu böyle düşünmez, ta ki bir sızıntı yaşanana kadar. Bu yazıda "güvenli e-pin scripti" ifadesinin arkasında gerçekte hangi standartların olması gerektiğini, neyin süs neyin zorunluluk olduğunu anlatıyoruz.
Neden bir e-pin scripti "sadece çalışsın" yeterli değildir?
Dijital ürün satan bir site, klasik bir e-ticaret sitesine göre daha çekici bir hedeftir. Çünkü elde edilecek şey sadece kart bilgisi değildir; stok bakiyesi, bayi cüzdanı, tedarikçi API anahtarı gibi doğrudan paraya çevrilebilen varlıklar da veritabanında durur. Bir saldırgan bayi panelinize sızarsa, sadece müşteri verisini değil, sizin cüzdan bakiyenizi de hedef alır.
Bu yüzden "site açık, ödeme alıyor, kod gönderiyor" seviyesinde bir script, güvenlik açısından yeterli değildir. Aşağıdaki başlıklar tam olarak nerede risk oluştuğunu ve bir scriptin bu riski nasıl kapatması gerektiğini gösteriyor.
- Müşteri verisi (isim, e-posta, sipariş geçmişi)
- Ödeme akışı ve işlem kayıtları
- Tedarikçi/API bağlantı bilgileri
- Admin ve bayi yetkilendirme katmanı
Müşteri verileri script içinde tam olarak nerede saklanır?
Çoğu satıcı bunu hiç sormaz ama sormalı: parolalar düz metin mi tutuluyor, yoksa hash'leniyor mu? Bir e-pin scriptinde kullanıcı parolaları asla okunabilir biçimde saklanmamalı; bcrypt veya argon2 gibi tek yönlü hash algoritmalarıyla saklanmalı, üstüne salt eklenmelidir. Pinova alt yapısında parolalar bu şekilde tutulur — veritabanı bir şekilde ele geçirilse bile parolalar doğrudan kullanılabilir hâlde çıkmaz.
İkinci mesele veri minimizasyonudur. Bir e-pin sitesinin kimlik fotoğrafı, adres detayı gibi ihtiyaç dışı veriyi toplamasının hiçbir anlamı yoktur; toplanan her fazla alan, sızıntı anında kaybedilecek fazladan bir varlıktır. İyi bir script sadece işlemi tamamlamak için gerekli alanları tutar.
- Parolalar: hash + salt, asla düz metin
- Oturum (session) token'ları: süreli, IP/User-Agent doğrulamalı
- Kişisel veri alanları: sadece işlem için zorunlu olanlar
- Veritabanı bağlantı bilgileri: config dosyasında, web kök dizini dışında
Ödeme bilgileri gerçekten güvende mi, yoksa sadece öyle mi görünüyor?
Burada net bir kural var: bir e-pin scripti asla kart numarasını kendi veritabanında saklamamalı. Bu hem güvenlik hem yasal bir zorunluluktur — kart verisi tutan her sistem PCI DSS kapsamına girer ve bu, küçük bir satıcı için yönetilmesi neredeyse imkânsız bir yüktür. Doğru yaklaşım, ödeme adımını PayTR veya Shopier gibi lisanslı bir ödeme kuruluşunun iframe'ine veya yönlendirmesine devretmek, kendi sisteminizde sadece işlem sonucunu (başarılı/başarısız, tutar, işlem no) tutmaktır.
Pinova bu mantıkla çalışır: kart bilgisi hiçbir zaman sizin sunucunuza dokunmaz, sadece ödeme kuruluşunun bildirim (callback) sonucu işlenir ve teslimat ona göre tetiklenir. Böylece hem PCI DSS yükünden kurtulursunuz hem de "kart verisi sızdı" riskini tamamen dışarıda bırakırsınız.
Havale/EFT gibi manuel yöntemlerde ise dekont ekran görüntülerinin nerede saklandığı, kimin erişebildiği ayrı bir konu. Bu dosyalar da rastgele isimlendirilip yetkisiz erişime kapalı bir klasörde tutulmalı.
API anahtarları ve tedarikçi bağlantıları en zayıf halka mı?
Turkpin, Pinabi gibi tedarikçi API'lerine bağlanan her script, aslında sizin adınıza para harcayabilen bir anahtar taşır. Bu anahtar bir şekilde ele geçirilirse saldırgan sizin bakiyenizle gerçek e-pin kodu çekebilir. Buna rağmen birçok özel yazım scriptte API anahtarları düz metin olarak kod içine gömülür, hatta bazen GitHub'a yanlışlıkla public repo olarak yüklenir.
Doğru yöntem: anahtarların ortam değişkeninde veya şifrelenmiş bir config katmanında tutulması, kod deposuna asla çıplak yazılmaması ve tedarikçi tarafında mümkünse IP kısıtlaması yapılmasıdır. Ayrıca panel üzerinden API anahtarını "kim, ne zaman değiştirdi" bilgisinin loglanması, bir çalışanın veya sızan bir oturumun anahtarı değiştirip değiştirmediğini anlamanızı sağlar.
- API anahtarları koddan ayrı, şifrelenmiş saklanmalı
- Tedarikçi tarafında IP kısıtlaması aktif olmalı
- Anahtar değişiklikleri loglanmalı
- Test ve canlı anahtarlar birbirine karışmamalı
Bir sızıntı yaşandığında ne kadar hızlı fark edersiniz?
Güvenlik sadece "girilmesin" diye değil, "girilirse hemen anlaşılsın" diye de kurulur. Çoğu küçük ölçekli e-pin sitesinde hiçbir log mekanizması yoktur; admin paneline kimin, hangi IP'den, kaç kez başarısız girdiği hiçbir yerde tutulmaz. Bu durumda bir saldırgan haftalarca sistemde dolaşabilir, siz farkına bile varmazsınız.
Asgari düzeyde olması gerekenler: admin giriş denemelerinin loglanması, art arda başarısız girişlerde geçici kilitleme (brute-force koruması), kritik işlemlerde (bakiye değişikliği, bayi limiti artırma, ürün fiyatı değişikliği) kim-ne-ne zaman kaydı tutan bir audit log. Pinova admin panelinde bu tür kritik hareketler kayıt altına alınır; böylece "bu değişikliği kim yaptı" sorusu her zaman cevaplanabilir durumda kalır.
- Başarısız giriş denemesi limiti + geçici kilitleme
- Admin/bayi panelinde işlem geçmişi (audit log)
- Şüpheli IP'lerden gelen çoklu siparişlerde otomatik uyarı
- Düzenli, dışarıda saklanan yedekleme (backup)
Admin panelinize giriş için mutlaka iki adımlı doğrulama (2FA) açın ve mümkünse panel erişimini sabit IP'lerle sınırlayın. Bu iki basit adım, çalınmış bir parolanın işe yaramasını büyük ölçüde engeller.
KVKK ve yasal sorumluluk: script sahibi olarak asıl muhatap siz misiniz?
Türkiye'de kişisel veri işleyen her site, büyüklüğüne bakılmaksızın KVKK kapsamındadır. E-pin satan bir işletme sahibi olarak "ben sadece scripti kullanıyorum, sorumluluk yazılımcıda" demek yasal olarak sizi korumaz — veri sorumlusu sizsiniz. Bu yüzden scriptin teknik altyapısı kadar, sitenizde bulunması gereken aydınlatma metni, açık rıza mekanizması ve veri saklama/silme politikası da güvenlik zincirinin bir parçasıdır.
Pratikte dikkat edilmesi gerekenler şunlardır: kullanıcı hesabını sildiğinde verilerinin gerçekten silinip silinmediği, sipariş kayıtlarının hangi süre boyunca tutulacağının belirlenmesi ve üçüncü taraf (ödeme kuruluşu, kargo/teslimat sistemi) ile paylaşılan verinin sözleşmeyle güvence altına alınması. İyi kurgulanmış bir script bu alanları admin panelinden yönetilebilir hâle getirir; her satıcı sıfırdan hukuki metin yazmak zorunda kalmaz.
| Güvenlik Alanı | Manuel / Elle | Pinova ile |
|---|---|---|
| Parola saklama | Genelde düz metin veya zayıf hash, geliştiriciye bağlı | bcrypt/argon2 + salt, standart olarak kurulu |
| Kart verisi işleme | Bazı özel scriptlerde sunucuda tutulur, PCI DSS riski | Kart verisi hiç dokunmaz, PayTR/Shopier üzerinden geçer |
| Admin giriş güvenliği | Tek parola, brute-force koruması yok | 2FA desteği + başarısız deneme kilitleme |
| İşlem takibi (audit log) | Genelde yok, "kim yaptı" sorusu cevapsız kalır | Bayi/admin işlemleri kayıt altında |
| API anahtarı yönetimi | Kod içine gömülü, değişim izlenemez | Ayrı, şifreli saklama + değişiklik logu |
Kendi scriptinizin güvenlik seviyesini gerçekten biliyor musunuz?
Pinova ile bu sorunun cevabı belirsiz kalmaz: parola hash'leme, ödeme verisinin sunucunuza hiç dokunmaması, admin audit log ve bayi yetkilendirme katmanları hazır gelir, siz sadece işinize odaklanırsınız.
E-pin scriptimde müşteri parolalarını nasıl kontrol edebilirim, hash'li mi saklanıyor?
Veritabanınızdaki kullanıcı tablosuna baktığınızda parola alanı okunabilir bir kelime yerine uzun, rastgele görünen bir karakter dizisi (örneğin $2y$ ile başlayan bir bcrypt çıktısı) olmalı. Eğer parolanızı düz metin olarak görebiliyorsanız, script acilen güncellenmeli.
Kart bilgilerini kendi sunucumda saklamak yasal mı?
Teknik olarak mümkün olsa da PCI DSS uyum yükümlülüğü doğurur ve küçük ölçekli bir satıcı için bu maliyet ve risk çok yüksektir. Kart verisini hiç saklamayıp ödeme kuruluşuna (PayTR, Shopier gibi) devretmek hem daha güvenli hem daha az yük getirir.
Bayi sistemi olan bir scriptte ekstra hangi risk vardır?
Bayiler kendi panellerinden bakiye ve fiyatlandırma işlemleri yapabildiği için, yetkilendirme (rol bazlı erişim) doğru kurulmazsa bir bayi hesabı diğer bayilerin verisine veya sistem ayarlarına erişebilir. Her bayinin sadece kendi verisini görebildiği izole bir yapı şarttır.
Pinova bu güvenlik standartlarının hepsini kurulumda otomatik mi getiriyor?
Evet, parola hash'leme, ödeme verisinin sunucuya dokunmaması, admin işlem logu ve bayi yetkilendirme katmanı kurulumla birlikte gelir; ek bir güvenlik yazılımı geliştirmeniz gerekmez.