PCI-DSS 4.0 standardı ile gelen yeni güvenlik kuralları: B2B tahsilat sistemleri, e-ticaret siteleri, kart verisi güvenliği ve denetim hazırlığı. İnceleyin.
Hızlı Özet (TL;DR)
PCI-DSS (Payment Card Industry Data Security Standard), Visa, Mastercard, American Express, Discover ve JCB tarafından kurulan PCI Güvenlik Standartları Konseyi’nin (PCI SSC) kartlı ödeme ekosistemini siber saldırılara karşı korumak amacıyla yayımladığı küresel bilgi güvenliği standardıdır. Mart 2025 itibarıyla tüm ileri tarihli gereksinimleri de tam zorunlu hale gelen PCI-DSS v4.0 / v4.0.1 sürümü, geleneksel “yılda bir kez denetimden geçme” anlayışını yıkarak Sürekli Güvenlik (Continuous Security), sıfır güven (Zero Trust) ve istemci tarafı (Tarayıcı/JavaScript) koruması ilkelerini zorunlu kılmıştır. Yalnızca perakende e-ticaret siteleri değil; bayilerinden ve kurumsal müşterilerinden B2B tahsilat portalları üzerinden kredi kartıyla ödeme alan tüm sanayi kuruluşları, toptancılar ve yazılım sağlayıcıları bu yeni kurallara doğrudan tabidir.
B2B Tahsilat Portalları ve İmalatçılar Neden PCI-DSS Kapsamındadır?
Türkiye’deki pek çok üretim firması, distribütör ve yedek parça tedarikçisi, bayilerinden cari hesap tahsilatı yapmak için web tabanlı B2B Bayi Tahsilat Sistemleri veya ERP’ye entegre sanal POS modülleri kullanmaktadır. İşletme yöneticileri arasında en yaygın yanılgı; “Biz kredi kartı numaralarını kendi veritabanımızda kaydetmiyoruz, doğrudan bankanın Sanal POS’una veya ödeme kuruluşuna (İyzico, PayTR, Param vb.) iletiyoruz; dolayısıyla sorumluluğumuz yok” düşüncesidir.
Oysa saldırganlar artık veritabanlarını hacklemekle uğraşmak yerine, doğrudan ödeme sayfasının çalıştığı web sunucusuna veya tarayıcıda yüklenen üçüncü parti bir JavaScript kütüphanesine zararlı kod (Magecart / E-Skimming / Formjacking) enjekte etmektedir. Bayiniz ödeme ekranında kart numarasını, son kullanma tarihini ve CVV kodunu tuşladığı anda, bu veriler bir yandan bankaya giderken bir yandan da arka planda saldırganın sunucusuna kopyalanır. Bu nedenle kart verisinin üzerinden geçtiği, yönlendirildiği (Redirect/iFrame) veya işlendiği her sunucu ve ağ katmanı CDE (Cardholder Data Environment - Kart Sahibi Veri Ortamı) kapsamına girer ve PCI-DSS uyumluluğu gerektirir.
PCI-DSS v3.2.1 ile PCI-DSS v4.0 Arasındaki Kritik Farklar
Yeni standart, modern bulut mimarilerini, API entegrasyonlarını ve tedarik zinciri saldırılarını kapsayacak şekilde köklü değişiklikler getirmiştir. Aşağıdaki tablo kurumsal BT ve yazılım ekiplerini doğrudan etkileyen teknik farkları özetlemektedir:
| Güvenlik Alanı ve Gereksinim | Eski Standart (PCI-DSS v3.2.1) | Yeni Zorunlu Standart (PCI-DSS v4.0 / v4.0.1) | Kurumsal Teknik Uygulama Karşılığı |
|---|---|---|---|
| Çok Faktörlü Kimlik Doğrulama (MFA - Madde 8.4.2) | Yalnızca uzaktan (VPN ile) CDE ağına bağlanan yöneticiler için zorunluydu. | CDE ortamına erişen herkes için (yerel ağdan bağlansa dahi) tüm erişimlerde MFA istisnasız zorunludur. | Sunucu, veritabanı, güvenlik duvarı ve B2B yönetim panellerinde TOTP/FIDO2 MFA zorunluluğu. |
| Parola Karmaşıklığı ve Uzunluğu (Madde 8.3.6) | En az 7 karakter uzunluk ve 90 günde bir zorunlu parola değişimi. | En az 12 karakter (desteklemiyorsa 8) uzunluk; MFA varsa sürekli şifre değiştirme yerine risk/ihlal bazlı yönetim. | Active Directory ve uygulama kullanıcı politikalarının 12+ karakter ve karmaşık diziye yükseltilmesi. |
| Ödeme Sayfası Script Bütünlüğü (Madde 6.4.3 & 11.6.1) | İstemci tarafında çalışan JavaScript kodları için özel bir denetim maddesi yoktu. | Ödeme sayfasındaki tüm scriptlerin envanteri tutulmalı, yetkisiz değişiklikler SRI / CSP ve kurcalama algılama ile önlenmelidir. | Content Security Policy (CSP), Subresource Integrity (SRI) hash doğrulaması ve HTTP başlık izleme. |
| Web Uygulama Güvenlik Duvarı (WAF - Madde 6.4.2) | Yıllık kaynak kod analizi VEYA WAF kullanımı seçmeliydi (birinden biri yeterliydi). | İnternete açık tüm ödeme ve tahsilat web uygulamalarının önünde otomatik çalışan WAF kullanımı artık zorunludur. | OWASP Top 10 ve bot saldırılarını bloklayan aktif WAF konumlandırılması. |
| Otomatik Log Analizi (Madde 10.4.1.1) | Güvenlik kayıtlarının (Log) günlük olarak manuel incelenmesi kabul ediliyordu. | Güvenlik olaylarının ve denetim kayıtlarının otomatik mekanizmalarla (SIEM / SOAR) sürekli analiz edilmesi şarttır. | Merkezi log toplama, korelasyon kuralları ve anlık anomali alarm üretimi. |
B2B Entegrasyon Modellerine Göre Öz Değerlendirme (SAQ) Seviyeleri
Bir işletmenin tabi olduğu denetim yükümlülüğü, kredi kartı verisinin kendi sunucularına değip değmediğine göre üç farklı SAQ (Self-Assessment Questionnaire - Öz Değerlendirme Anketi) kategorisinde sınıflandırılır:
1. SAQ A (Tamamen Dış Kaynaklı Ödeme Sayfası / iFrame veya Ortak Ödeme Sayfası)
Müşteri veya bayi B2B portalınızda “Ödeme Yap” butonuna bastığında, kart bilgilerini girdiği alan tamamen ödeme kuruluşunun (PCI-DSS Level 1 sertifikalı sanal POS sağlayıcısının) sunucusundan gelen bir iFrame içindeyse veya kullanıcı doğrudan banka sayfasına yönlendiriliyorsa işletmeniz SAQ A kapsamındadır. Kart verisi sizin sunucunuzun RAM’ine veya ağınıza hiç uğramaz. Ancak PCI-DSS 4.0 ile birlikte SAQ A kapsamındaki firmalar dahi iFrame’i barındıran ana web sayfasının JavaScript güvenliğini (Madde 6.4.3 ve 11.6.1) sağlamak ve harici ASV (Approved Scanning Vendor) zafiyet taramalarını yaptırmakla yükümlüdür.
2. SAQ A-EP (Doğrudan Post / JavaScript API Entegrasyonu)
Ödeme formu kendi B2B web sitenizin HTML kodları içinde yer alıyor, ancak kullanıcı “Öde” tuşuna bastığında kart verisi tarayıcıdan doğrudan banka/ödeme kuruluşu API’sine gönderiliyorsa SAQ A-EP kapsamına girersiniz. Bu modelde web sunucunuzun ele geçirilmesi ödeme formunun değiştirilmesi anlamına geldiği için; ağ segmentasyonu, WAF, dosya bütünlüğü izleme (FIM) ve yılda en az bir kez kapsamlı sızma testi (pentest) yaptırma zorunluluğu vardır.
3. SAQ D (Kart Verisinin Sunucu Üzerinden Geçmesi - API Relay / Saklama)
Kullanıcının girdiği kart numarası önce sizin kendi arka uç (Backend - .NET, Java, PHP, Node.js) sunucunuza geliyor ve sunucunuz bu veriyi XML/JSON ile bankanın Sanal POS API’sine iletiyorsa; kart numarasını veritabanına hiç kaydetmeseniz bile (yalnızca RAM’den geçse dahi) en ağır denetim sınıfı olan SAQ D kapsamına girersiniz. Bu durumda 300’den fazla güvenlik kontrolünün tamamını karşılamak zorunda kalırsınız.
Ağ Segmentasyonu, Şifreleme ve Sızma Testi Gereksinimleri
PCI-DSS 4.0 denetim maliyetini ve riskini düşürmenin en etkili mühendislik yöntemi Kapsam Daraltma (Scope Reduction) ve Ağ Segmentasyonudur (Network Segmentation). B2B tahsilat sunucusunun bulunduğu VLAN, fabrikadaki genel ofis bilgisayarlarından, misafir Wi-Fi ağından ve üretim makinelerinden kurumsal güvenlik duvarı kurallarıyla tamamen izole edilmelidir.
Ayrıca ödeme altyapısında şu teknik kontroller eksiksiz uygulanmalıdır:
- Güçlü Kriptografi (TLS 1.2 / TLS 1.3): Ödeme sayfasında eski SSL, TLS 1.0 ve TLS 1.1 protokolleri ile zayıf şifreleme kümeleri (Cipher Suites) tamamen kapatılmalıdır.
- Kart Saklama Yerine Tokenizasyon (Tokenization): Tekrarlayan bayi tahsilatlarında kredi kartı numarasını (PAN) kendi sisteminizde şifreli dahi olsa tutmak yerine, ödeme kuruluşunun sunduğu Token (Eşdeğer Anahtar) yapısı kullanılmalıdır.
- Yıllık ve Değişiklik Sonrası Sızma Testleri (Madde 11.4): Hem dış ağdan (External) hem de iç ağdan (Internal) yetkin güvenlik uzmanları tarafından yılda en az bir kez ve her önemli altyapı/kod değişikliği sonrasında uygulama ve ağ sızma testleri gerçekleştirilmelidir.
Kurumsal B2B tahsilat portallarınızın, ERP entegrasyonlarınızın ve sunucu altyapınızın PCI-DSS 4.0 uyumluluk denetimi için Sızma Testi (Pentest) Hizmetleri, güvenli yazılım mimarisi için Özel ERP ve CRM Çözümleri ve ağ izolasyonu için Güvenlik Duvarı Çözümleri sayfalarımızı inceleyebilirsiniz.
Sıkça Sorulan Sorular
Bayilerimizden aldığımız kredi kartı bilgilerini mail-order formu (PDF/Kağıt veya Excel) olarak saklamak PCI-DSS ihlali midir?
Evet, hem PCI-DSS 4.0 hem de 6698 sayılı KVKK kapsamında en yüksek riskli ihlallerden biridir. Kredi kartının arka yüzündeki CVV/CVC güvenlik kodunun işlem onaylandıktan sonra kağıt üzerinde, ses kaydında, e-postada veya Excel dosyasında saklanması (şifreli olsa dahi) kesinlikle yasaktır. Fiziksel mail-order formlarındaki CVV bölümleri işlem sonrasında derhal imha edilmeli; mümkünse kağıt form yerine müşterinin cep telefonuna gönderilen güvenli 3D Secure Ödeme Linki (Pay-by-Link) sistemine geçilmelidir.
PCI-DSS 4.0’daki yeni “Ödeme Sayfası Script Koruması (Madde 6.4.3)” teknik olarak nasıl uygulanır?
Tahsilat sayfasının çalıştığı web sunucusunda Content-Security-Policy (CSP) HTTP başlığı tanımlanarak sayfanın yalnızca beyaz listedeki (Whitelisted) güvenilir alan adlarından JavaScript çalıştırmasına ve yalnızca banka/ödeme kuruluşu adresine form verisi göndermesine (form-action, connect-src) izin verilir. Ayrıca sayfaya dahil edilen her harici script için Subresource Integrity (SRI - integrity="sha384-...") özeti eklenir; böylece üçüncü parti script kaynağında değiştirilirse tarayıcı kodu çalıştırmayı otomatik olarak reddeder.
Şirketimiz PCI-DSS kurallarına uymazsa ve bir kart sızıntısı yaşanırsa ne gibi yaptırımlarla karşılaşırız?
Bir veri ihlali sonucunda kart bilgilerinin sızdığı tespit edilirse; bankalar ve kart kuruluşları tarafından şirketinize Sanal POS kapatma yaptırımı uygulanabilir, zorunlu uluslararası Adli Bilişim İncelemesi (PFI - PCI Forensic Investigator) masrafları (on binlerce dolar) şirketinize fatura edilir, çalınan kartlarla yapılan tüm ters ibraz (Chargeback) bedelleri tahsil edilir ve ayrıca KVKK kapsamında milyonlarca liralık idari para cezası kesilir.