E-ticarette PCI-DSS uyumluluğu: Kart bilgisi yönetimi rehberi

E-ticaret tarafında ödeme süreci güvenlik kadar uyumluluk gerektirir. PCI-DSS (Payment Card Industry Data Security Standard) kart verisinin nasıl işlendiğini, saklandığını ve aktarıldığını düzenler. Yanlış yapılandırılmış bir “kart bilgisi e-ticaret veritabanında duruyor” senaryosu hem risk hem de denetim maliyeti doğurur. Bu rehberde kart bilgisi akışını adım adım ele alacak; PCI kapsamını azaltmanın pratik yollarını, teknik kontrolleri ve sunucu tarafındaki sorumlulukları netleştireceksiniz.

PCI-DSS’te kart verisi neden kritik? (Kapsamın mantığı)

PCI-DSS, kart sahiplerinin ödeme verilerinin güvenliğini artırmak için belirlenmiş bir standarttır. Uyumluluk açısından en önemli nokta, “hangi verinin” sisteminizde işlendiği ve nerede tutulduğudur.

PCI-DSS kapsamında genellikle şu veri türleri ayrıştırılır: - CHD (Cardholder Data): Kart sahibine ait veriler. - PAN (Primary Account Number): Kart numarası. Genellikle en hassas alandır. - Son kullanma tarihi gibi ödeme bilgileri (PAN ile birlikte değerlendirilebilir). - CVV/CVC (genellikle saklanmaması gereken alandır).

E-ticaret altyapınızda iki temel senaryo olur: 1) Kart verisini sizde tutmuyorsunuz: Ödeme sayfası sağlayıcının (payment gateway/PSP) alanında çalışır, siz sadece ödeme sonucu alırsınız. 2) Kart verisini siz alıp işliyorsunuz: Kart numarası/son kullanma gibi alanlar sizin sisteminizden geçer; loglarda, uygulamada veya veritabanında iz kalabilir.

Net sonuç şudur: PCI kapsamını azaltmak için hedef, mümkün olan en fazla adımı “servis sağlayıcının alanında” bırakmaktır. Bu, sadece güvenliği değil denetim yükünü de ciddi şekilde etkiler.

PCI kapsamını azaltan mimari tercihleri

Şu mimari tercihleri pratikte PCI yükünü düşürür: - Hosted ödeme sayfası: Kart alanları doğrudan PSP’nin sayfasında alınır. - Tokenization: Kart numarası yerine sisteminizde yalnızca bir token saklanır. - 3D Secure (3DS2) entegrasyonu: Ödeme doğrulama adımı, sağlayıcı tarafında akıcı çalışır.

Bu tercihler, “kart bilgisi sistemimde nerede görünüyor?” sorusunun cevabını belirler.

E-ticarette kart bilgisi akışı: Doğru ve riskli tasarımlar

Kart bilgisinin akışını net çizmeden PCI-DSS’e yaklaşmak mümkün değildir. Aşağıdaki tablo, iki yaygın tasarımı hızlı görselleştirir.

Yanlış kurulumlara örnek: “Kayıt için log tuttuk”

Sık görülen hatalar şunlardır: - Uygulama hatasında kart alanlarını hata mesajına yazmak. - API request/response loglarında PAN veya CVV yakalanması. - Veritabanında kart numarasını masked (ör. 4111********1111) biçimde bile olsa saklamak. - Üretim ortamında debug logu açık bırakmak.

Bu hatalar, “PCI ile ilgili bir konu” gibi görünse de aslında sunucu yönetimi ve uygulama ayarlarının doğrudan sonucudur.

PCI-DSS uyumluluğunda hedef: PAN saklamamak, token kullanmak

Uyumluluk stratejisinin merkezinde kart verisini minimize etmek vardır. Uygulamada pratik hedefler: - PAN’ı sisteminizde saklamamak. - Mümkünse sadece token saklamak. - CVV/CVC’yi kesinlikle saklamamak (çoğu senaryoda “sisteminizde hiç bulunmaması” beklenir).

Tokenization nasıl çalışır? - Kullanıcı ödeme yapar. - PSP, kart bilgisini işler. - Siz, PSP’den bir token alırsınız. - İleride ödeme gerektiğinde “token” kullanılır; kart numarası sizde tekrar görülmez.

Token’ın güvenliği de PCI’nin parçasıdır

Token saklamak PCI’yi “sıfır risk” yapmaz. Token, kendi başına hassas olabilir. Bu nedenle token yönetiminde şunlar net olmalıdır: - Token’ların erişimi sadece ödeme servis katmanıyla sınırlandırılmalı. - Token’lar şifrelenerek saklanmalı (uygulama katmanı ve/veya veritabanı düzeyi). - Token’ların loglara düşmesi engellenmeli.

Sunucu ve altyapı tarafında PCI-DSS’e hazırlık kontrol listesi

Birçok e-ticaret ekibi uyumluluğu sadece ödeme sağlayıcısına bağlar. Oysa PCI-DSS denetimi, kart verisinin işlendiği sistemleri ve çevreyi kapsar. Bu nedenle sunucu/hosting tarafında net hazırlık gerekir.

1) Erişim kontrolü: least privilege (en az yetki)

Aşağıdaki prensip teknik olarak doğrulanabilir olmalıdır: - Uygulama servis hesabı yalnızca gerekli yetkileri alır. - Veritabanı kullanıcıları ayrı yetki seviyeleriyle ayrılır. - Yönetim erişimleri (SSH/console) MFA (çok faktörlü doğrulama) ile korunur.

2) Güncellemeler ve yamalar (patch management)

PCI uyumluluğu, “yama yoksa güvenlik de yok” yaklaşımına dayanır. Somut olarak: - İşletim sistemi ve uygulama bağımlılıkları için güncelleme periyodu tanımlanır. - Üretim ortamında kritik güvenlik yamaları belirli süre içinde uygulanır.

3) Şifreleme: transit ve at rest

Minimum beklenti seti şunlardır: - Kullanıcı tarayıcıdan servis uçlarına TLS ile şifreli iletişim. - Veritabanında hassas bilgilerin şifrelenerek saklanması. - Anahtar yönetimi: anahtarların erişimi ve saklama biçimi net olmalı.

4) Log yönetimi: kart verisi ve maskeleme

PCI açısından loglar en sık sızma kaynağıdır. - Uygulama loglarında PAN/CVV görünmemeli. - Hata durumlarında request body veya header’lar otomatik yazdırılmamalı. - Token dahil tüm hassas alanlar maskeleme kuralına tabi olmalı.

5) Güvenlik duvarı ve ağ segmentasyonu

Kart verisinin işlendiği bileşenler, genel internete açık olmamalıdır. - Yönetim arayüzleri (panel/SSH) kısıtlı IP veya VPN üzerinden erişilebilir olmalı. - Uygulama sunucusu ile veritabanı arasında segmentasyon yapılmalı.

6) Yedekleme ve geri dönüş (backup & restore) testleri

Uyumluluk sadece “yedek var” demek değildir; geri dönüş testleri beklenir. - Yedekler şifrelenmeli. - Yedek erişim yetkileri sınırlı olmalı. - En azından aylık periyotlarla geri yükleme testi yapılmalı.

Bu adımlar, hem PCI denetiminde hem de operasyonel risk yönetiminde somut veri üretir.

PCI-DSS’te sunucu seçimi: tek kiracı mı, paylaşımlı mı?

Net bir karar vermek için şu ayrımı yapın: PCI kapsamı “kartın işlendiği sistemler” üzerindedir. Bu kapsamı azaltan mimari tercih ediyorsanız paylaşımlı alanlarda risk düşer; ancak kart verisi sizde işleniyorsa daha sıkı izolasyon gerekir.

Paylaşımlı hosting (shared) ile yaklaşım

Eğer ödeme hosted page/token ile yönetiliyorsa, kart verisi paylaşımlı ortamda bulunmayabilir. Bu durumda PCI kapsamının kapsam sınırları PSP’nin tasarımına bağlı olur.

Risk artışı şu durumda olur: - Kart verisi sizde API üzerinden işleniyor. - Uygulama logları yanlış yapılandırılmış. - Sunucuda süreç ayrımı zayıf.

VPS/VDS ve dedicated: neden tercih ediliyor?

• Kaynaklar ve süreçler daha izole olur.
• Güvenlik duvarı, erişim politikaları ve güncelleme disiplini daha kontrollü yürütülür.
• Log/konfigürasyon doğrulaması daha kolaydır.

Özet olarak: Kart verisini sizde işliyorsanız VPS/VDS veya dedicated üzerinde kontrol daha sağlam kurulur. Kart verisini tamamen PSP alıyorsa, kaynak türü kadar “veri akışı mimarisi” belirleyicidir.

PCI-DSS uyumluluğunu doğrulamak için pratik test senaryoları

Uyumluluğu doküman okutarak değil, sistem davranışını ölçerek yönetmek daha verimli olur.

Test 1: Hata loglarına kart verisi düşüyor mu?

• Ödeme sırasında bilerek hatalı bir senaryo oluşturun.
• Uygulama ve reverse proxy (varsa) loglarında PAN/CVV araması yapın.
• Token dışında hassas veri bulunmadığını doğrulayın.

Test 2: Network trafiği doğru uçlara gidiyor mu?

• Ödeme formu gönderimi ilgili PSP domainlerine mi gidiyor?
• Kendi sunucunuzda PAN/CVV içeren POST body oluşuyor mu?

Test 3: Veritabanında beklenmeyen alanlar var mı?

• Veritabanı şemasında kart numarası/son kullanma/CVV alanı bulunmadığını kontrol edin.
• Migration ve eski kayıtlar varsa maskeleyip temizleyin.

Test 4: Yedekten geri dönüş çalışıyor mu?

• Son yedekten küçük bir staging kurun.
• Uygulamanın token ile ödeme akışına kadar erişebildiğini test edin.

Sık yapılan 7 hata ve net düzeltme

1) Debug log açık: Üretimde debug kapatın, request body loglamasını devre dışı bırakın. 2) PAN maskelemesi yeter sanmak: Maskelenmiş PAN bile PCI riskini artırabilir; token stratejisine geçin. 3) CVV saklama: CVV/CVC saklamayın, PSP’nin kurallarına uyun. 4) Hatalarda kart verisi yazmak: Exception handler içinde request parametrelerini filtreleyin. 5) Yetkisiz panel erişimi: Admin panel ve veritabanı erişimini IP/VPN ile kısıtlayın. 6) Güncelleme disiplini yok: OS, runtime ve bağımlılıkları takvimli güncelleyin. 7) Yedek testi yok: Restore testi yapmadan “yedek var” demeyin.

Sonuç: Hemen bugün yapılacak aksiyon planı

PCI-DSS uyumluluğunda en hızlı kazanım, kart verisi akışını sadeleştirmektir: hosted ödeme veya tokenization ile PAN/CVV’yi sisteminizden çıkarmaya odaklanın. Ardından sunucu tarafında erişim kontrolü, log filtreleme, şifreleme ve yedekten geri dönüş testlerini yazılı kontrol listesine bağlayın. Bugün atacağınız net adım şudur: ödeme sağlayıcınızın sunduğu entegrasyon türünü (hosted/API+token) doğrulayın; uygulama ve loglarınızda PAN/CVV izi olmadığını test edin. Bu iki doğrulama, sonraki uyumluluk çalışmalarını somut ve ölçülebilir hale getirir.