E-pin satan neredeyse her işletme sahibi aynı cümleyi kurar: "Ben kart bilgisi tutmuyorum, ödeme bankada oluyor, PCI DSS beni ilgilendirmez." Bu cümlenin ilk yarısı çoğu zaman doğrudur, ikinci yarısı ise büyük ölçüde yanlış. Standardın kapsamı, veriyi sakladığın yere göre değil, veriye dokunabildiğin her yere göre belirlenir. Yani veriyi bir saniye elinde tutup hemen iletsen bile o an kapsam içine girmişsin demektir.
İşin sessiz tarafı burada. Kart numarasını veritabanına yazmıyor olabilirsin ama hata kayıtlarında ödeme isteğinin tüm gövdesi duruyor olabilir; destek talebine müşterinin gönderdiği ekran görüntüsü sunucundaki bir klasörde bekliyor olabilir; ödeme sayfana yüklediğin üçüncü parti bir takip kodu formdaki alanları okuyabiliyor olabilir. Bu makale, kullandığın e-pin satış scriptinin kapsamı gereksiz yere büyütmesini engellemek ve mümkün olan en küçük yükümlülük setinde kalmak üzerine. Amaç sorumluluktan kaçmak değil, üstlenmediğin riski taşımamak.
PCI DSS'i "bankanın işi" sanmak nereden çıktı?
Bu yanılgının kaynağı, Türkiye'de ödeme altyapısının büyük ölçüde banka ve ödeme kuruluşları tarafından sunulması. Sanal POS anlaşmasını yaptığın kurum kendi uyumluluğunu belgeliyor, sen de bu belgeyi görünce kendini kapsamın dışında sanıyorsun. Oysa kart şemalarının kural setinde sen "satıcı" (merchant) konumundasın ve satıcının da bir öz değerlendirme yükümlülüğü var. Yükümlülüğün büyüklüğü ise tamamen mimariye bağlı.
Basitleştirelim: kart verisi hiç senin sistemine uğramadan doğrudan ödeme kuruluşuna gidiyorsa yükümlülüğün en küçük sette kalır. Veri senin sayfanda toplanıp senin sunucun üzerinden iletiliyorsa kapsam bir anda yüzlerce kontrol maddesini, penetrasyon testlerini ve segmentasyon kanıtlarını içerecek şekilde büyür. İkisi arasındaki maliyet farkı küçük bir işletme için yıllık bazda karşılaştırılamayacak kadar yüksektir. Dolayısıyla mimari kararı bir güvenlik kararı değil, doğrudan bir maliyet kararıdır.
Kapsam neyle başlar: dokunmak mı, dokunabilir olmak mı?
Kapsamı belirleyen soru şudur: bu bileşen kart verisini görebilir, iletebilir veya etkileyebilir mi? Üç fiilin hepsi önemli. Görmek ve iletmek açıktır. "Etkilemek" ise en çok atlanan kısımdır; ödeme sayfasının HTML'ini üreten şablon, o sayfaya script enjekte edebilen bir eklenti, hatta sayfayı önbellekleyen ara katman bile ödeme akışını etkileyebildiği için kapsama girer.
Pratikte bu şu anlama gelir: ödeme sayfasını mümkün olduğunca sade tut. O sayfada reklam etiketi, ısı haritası aracı, sohbet balonu, yorum widget'ı gibi hiçbir dış bileşen bulunmasın. Bir dijital ürün satış yazılımı kurarken tema ve eklenti özgürlüğü caziptir, fakat ödeme adımı bu özgürlüğün dışında tutulmalıdır. Sepet sayfasında istediğin her aracı çalıştırabilirsin; ödeme adımında sadece ödeme olsun.
Hosted alan, iframe ve yönlendirme: üçü aynı şey değil
Ödeme kuruluşları genelde üç yöntem sunar ve satıcıların çoğu aralarındaki farkı bilmeden birini seçer. Tam yönlendirme, müşteriyi ödeme kuruluşunun kendi alan adına gönderir; kart verisi hiçbir aşamada senin alan adında bulunmaz. iframe yöntemi, kuruluşun formunu senin sayfanın içine gömer; veri yine sana uğramaz fakat çerçeveyi barındıran sayfa kapsama girer, çünkü o sayfa değiştirilirse çerçeve de değiştirilebilir. Üçüncü yol olan doğrudan API entegrasyonunda kart verisi senin sunucundan geçer ve kapsam en büyük hale gelir.
Seçim yaparken dönüşüm oranı ile kapsam büyüklüğü arasında bir denge kurman gerekir. Tam yönlendirme en güvenli ve en ucuz uyumluluk yoludur ama müşteri site dışına çıktığı için bir miktar terk yaşanır. Bu terki azaltmanın yolu API'ye geçmek değil, yönlendirme öncesi sayfayı netleştirmek, tutarı ve ürünü açıkça göstermek, dönüş sayfasını hızlı ve tanıdık yapmaktır. İyi kurulmuş bir e-pin scripti bu dönüş akışını sipariş durumuyla senkron tutar, böylece müşteri "param gitti mi" paniğine düşmez.
| Entegrasyon yöntemi | Kart verisi nereden geçer | Kapsam büyüklüğü | Kimin için uygun |
|---|---|---|---|
| Tam yönlendirme (hosted sayfa) | Yalnızca ödeme kuruluşu | En küçük, SAQ A hedeflenebilir | Küçük ve orta ölçekli e-pin satıcısı |
| iframe / gömülü form | Ödeme kuruluşu, barındıran sayfa etkiler | Küçük ama barındıran sayfa dahil | Dönüşüm hassasiyeti yüksek satıcı |
| Doğrudan API (sunucu üzerinden) | Senin sunucun | En büyük, tam kontrol seti | Kendi uyumluluk ekibi olan kurum |
| Tokenizasyon ile tekrar ödeme | Token senin tarafında, kart kuruluşta | Küçük, token yönetimi eklenir | Abonelik veya bakiye yükleyen bayi ağı |
Kapsamı büyüten sessiz kaçaklar: log, destek talebi, ekran görüntüsü
Doğru mimariyi seçtiğini varsayalım. Kapsam yine de dört yerden sızabilir. Birincisi hata ve erişim kayıtları: bir ödeme isteği başarısız olduğunda çoğu kurulum isteğin tüm gövdesini loglar; eğer ara katmanda bir alan kart numarası taşıyorsa o numara artık disk üzerindedir. Çözüm, ödeme uçlarında gövde loglamayı kapatmak ve kayıtlarda kart deseni maskelemesi uygulamaktır.
İkincisi destek kanalı. Müşteri "ödemem geçmedi" derken kart ekranının fotoğrafını gönderir, bu dosya destek sistemine ve oradan yedeklere düşer. Destek arayüzünde bu tür ekleri otomatik uyarıyla reddetmek ya da kısa sürede silmek gerekir. Üçüncüsü üçüncü parti scriptler; yukarıda anlattık. Dördüncüsü yedekler: bir kez sızan veri, yedekleme zincirinde aylarca yaşar. Yedek politikan kadar temizsin.
Kart verisinin sisteme sızdığı noktalar
- Hata ve istek logları 40%
- Destek talepleri ve ekran görüntüleri 30%
- Ödeme sayfasındaki üçüncü parti scriptler 20%
- Yedek dosyaları ve dışa aktarımlar 10%
En kısa öz değerlendirme setinde kalmak için scriptinde ne olmalı?
Hedef, ödeme akışını kendi kodundan tamamen soyutlamak. Bunun için e-pin satış yazılımının ödeme katmanı şu beş şeyi yapmalı. Bir: ödeme başlatma isteğinde yalnızca sipariş numarası, tutar ve dönüş adresi taşımalı; kart alanı hiç tanımlanmamış olmalı. İki: dönüş doğrulamasını imza veya hash ile yapmalı, tutarı kendi veritabanındaki sipariş tutarıyla karşılaştırmalı. Üç: ödeme sonucunu yalnızca sunucu tarafı bildirimden kesinleştirmeli, tarayıcıdan gelen parametreye güvenmemeli.
Dört: tekrarlayan ödeme gerekiyorsa kartı değil kuruluştan alınan token'ı saklamalı ve token'ı kendi tarafında şifreli tutmalı. Beş: tüm ödeme trafiğini ayrı bir log kanalına yazmalı, bu kanalda maskeleme zorunlu olmalı. Bu beş kural sağlandığında ödeme sayfan sadece bir kapı olur; arkasında kart verisi barındıran bir oda kalmaz. Kapsamı küçültmenin tek gerçek yolu, veriyi hiç almamaktır.
Yeni bir entegrasyon eklerken sor: bu bileşen kart verisini görebilir, iletebilir veya ödeme sayfasını değiştirebilir mi? Cevap "evet" ise kapsamı büyütüyorsun, "hayır" ise özgürsün.
Kapsam dışı kalmak sorumluluktan kurtulmak değildir
Kart verisini hiç almasan bile müşteri verisi, sipariş geçmişi ve teslim edilen kodlar sende. Bir sızıntı yaşandığında müşteri kart numarasının değil, satın aldığı kodların ve kişisel bilgilerinin peşine düşer. Bu yüzden ödeme kapsamını küçültmek, genel güvenlik disiplininin yerine geçmez; onun sadece en pahalı kısmını ortadan kaldırır.
Pratik öneri: yılda iki kez aşağıdaki kontrol listesini yürüt, bulguları tarih atarak kaydet. Bir sorun çıktığında en değerli varlığın, önlem aldığını gösteren bu kayıtlardır. Ayrıca ödeme kuruluşunun uyumluluk belgesini her yenilendiğinde arşivle; anlaşma yenilemelerinde ve olası itirazlarda işine yarar.
| Kontrol maddesi | Nasıl doğrularsın | Kabul ölçütü | Durum |
|---|---|---|---|
| Ödeme sayfasında üçüncü parti script yok | Sayfa kaynağını ve ağ isteklerini incele | Yalnızca kendi alan adın ve ödeme kuruluşu | Tamam / Eksik |
| Loglarda kart deseni bulunmuyor | Kayıtlarda numara deseni araması yap | Sıfır eşleşme | Tamam / Eksik |
| Ödeme sonucu sunucu bildirimiyle kesinleşiyor | Dönüş parametresini elle değiştirerek dene | Sipariş onaylanmıyor | Tamam / Eksik |
| Tutar sunucu tarafında karşılaştırılıyor | Sepet tutarını değiştirerek test et | Uyuşmazlıkta ödeme reddediliyor | Tamam / Eksik |
| Destek eklerinde kart görüntüsü tutulmuyor | Ek klasörünü ve saklama süresini gözden geçir | Otomatik uyarı ve kısa saklama | Tamam / Eksik |
| Token'lar şifreli saklanıyor | Veritabanı alanını ve anahtar yerini kontrol et | Anahtar web köküyle aynı yerde değil | Tamam / Eksik |
| Yönetim paneli erişimi iki adımlı | Giriş akışını dene | Tüm yöneticilerde etkin | Tamam / Eksik |
Ödeme katmanını sıfırdan doğru kurmak istiyorsan
Yönlendirmeli ödeme, imza doğrulama, sunucu tarafı sipariş kesinleştirme ve maskeli log, uyum maliyetini baştan küçültür. Pinova'nın ödeme ve güvenlik özelliklerini ve paket farklarını incele.
Kart bilgisi saklamıyorsam gerçekten hiç yükümlülüğüm yok mu?
Yükümlülük var ama en küçük sette kalır. Satıcı olarak bir öz değerlendirme sorumluluğun bulunur; kart verisi hiç sistemine uğramıyorsa bu değerlendirme çok daha kısa ve ucuz olur.
iframe kullanmak yönlendirme kadar güvenli sayılır mı?
Veri açısından benzerdir, kapsam açısından değil. Çerçeveyi barındıran sayfa da kapsama girer, çünkü o sayfa değiştirilirse çerçeve de yönlendirilebilir. Bu yüzden ödeme sayfasını dış scriptlerden tamamen arındırmak gerekir.
Ödeme sonucunu tarayıcıdan gelen parametreyle onaylamak neden riskli?
Adres çubuğundaki parametreler kullanıcı tarafından değiştirilebilir. Siparişi yalnızca ödeme kuruluşunun sunucudan gönderdiği, imzası doğrulanmış bildirimle kesinleştirmek gerekir; tutar da kendi kaydınla karşılaştırılmalıdır.
Logları tamamen kapatmak çözüm mü?
Hayır, log olmadan olay incelemesi yapamazsın. Doğru yaklaşım ödeme uçlarında gövde loglamayı kapatmak, genel kayıtlarda kart deseni maskelemesi uygulamak ve saklama süresini makul bir pencereyle sınırlamaktır.
Uyumluluk, bir kez alınıp rafa konulan bir belge değil; her yeni eklenti ve her tema değişikliğinde yeniden sorulması gereken bir soru. Ödeme akışının kapsamı küçük tutacak şekilde nasıl kurulduğunu kendi gözünle görmek istersen canlı demo içinde sipariş oluşturup yönlendirmeli ödeme adımını ve dönüş doğrulamasını takip et; ardından kurulum sayfasından kendi alan adında aynı akışı ayağa kaldırabilirsin.