PCI‑DSS Uyumlu E‑Ticaret Hosting Mimarisi: Kart Verisini Sunucudan Uzak Tutmak

PCI‑DSS’te Asıl Oyun: Kart Verisini Sunucudan Uzak Tutmak

E‑ticaret tarafında PCI‑DSS konuşulmaya başlandığında tartışma çoğu zaman yanlış yerden açılıyor: “Sunucuyu nasıl sertleştiririz?”, “Hangi antivirüs?”, “Hangi WAF?” gibi başlıklar öne çıkıyor. Oysa PCI‑DSS’in en güçlü tarafı, daha ilk adımda şu soruyu sordurmasıdır: “Kart verisi gerçekten bu sunucudan geçmek zorunda mı?”

Biz DCHost’ta yeni bir e‑ticaret projesi için mimari tasarım toplantısına girdiğimizde, özellikle küçük ve orta ölçekli işletmelerde, kapsamı gereksiz yere büyüten kararlar görüyoruz. Uygulama sunucusundan kart bilgisi geçirildiği için SAQ A yerine SAQ A‑EP kapsamına giren, buna bağlı olarak da hem operasyonel yükü hem de denetim maliyetini gereksiz yere artıran çok proje var.

Bu yazıda odak noktamız şu olacak: Uygulama sunucusunu kart verisi kapsamı dışına nasıl çıkarırsınız? Başka bir deyişle, PCI‑DSS uyumlu bir e‑ticaret hosting mimarisini; kart numarası, CVV ve manyetik şerit eşdeğeri hiçbir verinin DCHost üzerindeki web, API veya veritabanı sunucularınızdan geçmeyeceği şekilde nasıl kurarsınız, bunu adım adım anlatacağız. Ödeme servis sağlayıcısı (PSP) ile entegrasyon modellerini karşılaştıracak, SAQ türlerine etkisini konuşacak ve pratik bir WooCommerce senaryosu üzerinden somut bir mimari çizeceğiz.

Temelleri Netleştirelim: PCI‑DSS ve Kart Verisi Neyi Kapsar?

Önce kavramları netleştirmek önemli. PCI‑DSS’in odaklandığı veri tipi kısaca kart sahibi verisi (Cardholder Data – CHD) ve hassas yetkilendirme verisi (Sensitive Authentication Data – SAD)dir.

• CHD (Kart Sahibi Verisi): Tam kart numarası (PAN), kart sahibi adı, son kullanma tarihi, servis kodu.
• SAD (Hassas Yetkilendirme Verisi): CVV/CVC, PIN/PIN block, manyetik şerit verisi.

PCI‑DSS açısından asıl belirleyici olan PAN’dir. Bir sistemde tam kart numarası işleniyor, iletiliyor veya saklanıyorsa o sistem PCI kapsamına girer. CVV gibi veriler ise zaten saklanmamalıdır; sadece işlem esnasında, çok kısa süreli kullanılabilir.

Buradan çıkarılacak en kritik ders şudur: Uygulama veya veritabanı sunucunuza PAN hiç uğramazsa, o sunucular PCI kapsamının dışına doğru itilmiş olur. Bu da doğrudan daha hafif bir SAQ türüne, daha küçük denetim kapsamına ve daha düşük operasyonel maliyete dönüşür. Detaylı kapsam konusunu daha önce genel olarak PCI‑DSS uyumlu e‑ticaret hosting rehberimizde anlatmıştık; burada özellikle kart verisini sunucuya hiç dokundurmayan mimarilere odaklanacağız.

Amaç: Uygulama Sunucusunu Kapsam Dışına Çıkarmak (Scope Reduction)

PCI dünyasında en sevdiğimiz kavramlardan biri scope reduction, yani kapsam küçültmedir. Temel prensip şudur:

• Ne kadar az sistem kart verisiyle temas ederse,
• O kadar az bileşen PCI‑DSS’in sıkı gerekliliklerine tabi olur.

E‑ticaret siteleri için pratik hedef genellikle SAQ A kapsamına inebilmektir. SAQ A, kart verisiyle sadece dıştaki ödeme sağlayıcısının ilgilendiği, sizin sistemlerinizde kart bilgisinin işlenmediği/iletilmediği senaryolara yöneliktir. Eğer kart formu sizin sitenizde render ediliyor, sadece arka planda PSP’ye post ediliyorsa, çoğu zaman SAQ A‑EP gündeme gelir; bu da çok daha fazla teknik kontrol ve denetim demektir.

Dolayısıyla mimari hedefi şöyle özetleyebiliriz:

• Kart formu ve ödeme akışı teknik olarak PSP’nin alan adı ve altyapısında çalışmalı,
• Web sunucunuz, kart verisine yalnızca token veya işlem referansı düzeyinde temas etmeli,
• Login, ürün kataloğu, sepet ve sipariş yönetimi gibi işlevler ise DCHost üzerindeki sunucularınızda kalmaya devam etmelidir.

Bu hedef doğru belirlendiğinde, geri kalan tüm hosting kararlarını (network segmentasyonu, WAF, loglama, yedekler vb.) bu çerçeveye oturtmak çok daha kolay hale gelir.

Kart Verisini Sunucudan Uzak Tutmak İçin 3 Yaygın Ödeme Mimarisi

Pratikte bir e‑ticaret sitesinin PSP ile konuşurken kullanabileceği birkaç temel entegrasyon modeli var. Bunların hepsi aynı derecede PCI‑dostu değil. Burada üç yaygın yaklaşımı, özellikle de kart verisinin uygulama sunucusuna uğrayıp uğramadığı açısından değerlendirelim.

1) Tam Yönlendirmeli Ödeme Sayfası (Hosted Payment Page – HPP)

Bu modelde kullanıcı, ödeme aşamasında tamamen PSP’nin barındırdığı bir sayfaya yönlendirilir. Adımlar kısaca şöyledir:

1. Müşteri sepeti onaylar, sizin sitenizde “Ödemeye geç” butonuna basar.
2. Sunucunuz PSP’ye bir “işlem başlat” isteği gönderir; tutar, sipariş numarası vb. parametreler paylaşılır.
3. PSP, müşteriyi kendi alan adındaki (örneğin pay.examplepsp.com gibi) hosted payment page’e yönlendirmenizi sağlayacak bir URL üretir.
4. Müşteri kart bilgisini doğrudan bu sayfaya yazar; form submit edildiğinde veri doğrudan PSP’nin altyapısına gider.
5. İşlem sonucu size sunucu‑sunucu (server‑to‑server) callback veya kullanıcı tarayıcı yönlendirmesiyle (success/fail URL) geri bildirilir.

Bu modelde kart formu, HTML, JavaScript ve POST isteği tamamen PSP alan adında gerçekleştiği için DCHost üzerindeki web veya API sunucularınız kart verisiyle temas etmez. Genellikle SAQ A kapsamına inmenin en temiz yoludur.

Tek dezavantajı, tasarımsal olarak kullanıcıyı sitenizden kısa süreliğine de olsa çıkarmasıdır. Bu deneyim iyi tasarlanmazsa güven duygusunu zedeleyebilir; ancak PSP birçok durumda sayfayı marka renklerinize göre özelleştirme imkanı sunar.

2) Güvenli iFrame veya JS SDK ile Kart Formunu PSP’den Enjekte Etmek

Bir diğer sık kullanılan modelde kart formu, sizin sayfanızın bir parçası gibi görünür; ama teknik olarak müşterinin tarayıcısı, kart alanlarını PSP’nin domain’inden yüklüyordur. Örnek akış:

• Checkout sayfanızdaki “Kart Bilgileri” bölümünde aslında bir <iframe> veya PSP tarafından sağlanan bir JS widget çalışır.
• Kullanıcı kart numarası, son kullanma tarihi, CVV gibi bilgileri bu bileşene yazar.
• Tarayıcı bu alanları doğrudan PSP’nin endpoint’ine POST eder; sizin domain’inizdeki uygulama sunucusu bu alanları hiç görmez.
• PSP, başarılı doğrulama sonrası size bir token döner; siz de veritabanınızda kartın kendisini değil bu token’ı saklarsınız.

Teknik açıdan kritik nokta şudur: Kart bilgilerini içeren form alanları sizin backend’inize değil, PSP’nin backend’ine gönderiliyor olmalıdır. Eğer form action’ı sizin sitenize post edip sizden PSP’ye server‑side forward ediyorsanız, kart verisi önce sizin sunucunuzdan geçmiş sayılır; bu da kapsamı dramatik şekilde büyütür.

Güvenli iFrame/JS SDK yaklaşımı doğru kurgulandığında birçok durumda yine SAQ A ile uyumlu olacak şekilde tasarlanabilir. Ancak HTML/JS bütünlüğünüz, CSP gibi HTTP güvenlik başlıkları ve TLS yapılandırmanızın sağlam olması gerekir; bunlara aşağıda ayrıca değineceğiz.

3) Kart Verisinin Geçici Olarak Sunucudan Geçtiği Senaryolar (SAQ A‑EP)

Bazı teknik ekipler, “tam kontrol” isteğiyle kart formunu tamamen kendi sayfasında host etmeyi tercih ediyor; ardından backend bu veriyi PSP’ye server‑side API ile iletiyor. Bu modelde:

• Form action’ı sizin domain’inizdeki bir endpoint’e post edilir.
• Backend, gelen kart bilgisini geçici olarak bellekte işler ve PSP’nin API’sine gönderir.
• Kart verisini disk veya loglara yazmamaya çok dikkat edilse bile, sunucunuz kart verisini işlemiş olur.

Bu durumda uygulama, veritabanı ve log sunucularınız PCI kapsamına girer; SAQ A yerine SAQ A‑EP gündeme gelir. Güvenli şekilde yapılabilir, fakat:

• Daha fazla teknik kontrol (dosya bütünlüğü izleme, antivirüs, detaylı loglama, erişim kontrolleri vb.),
• Daha geniş denetim alanı,
• Ve daha yüksek operasyon maliyeti

anlamına gelir. Bu yazının konusu ise tam tersine, kart verisini sunucudan tamamen uzak tutan A tipi mimariler olduğu için, bu yaklaşımı çoğu işletme için gereksiz karmaşık buluyoruz.

SAQ A Hedefi İçin Gerekli Hosting ve Uygulama Bileşenleri

Kart verisini sunucudan uzak tutmak için PSP tarafında doğru entegrasyon modelini seçmek ilk adım; ancak hosting katmanında da bunu destekleyen bir mimari kurmanız gerekiyor. DCHost’ta tipik bir SAQ A hedefli e‑ticaret kurulumunu şu bileşenlerle tasarlıyoruz:

• Uygulama Sunucusu: WooCommerce/Magento/Laravel vb. çalışan web sunucusu (Apache, Nginx, LiteSpeed).
• Veritabanı Sunucusu: Sipariş ve müşteri verilerini tutan MySQL/MariaDB/PostgreSQL.
• WAF Katmanı: Origin WAF (ModSecurity) veya CDN WAF ile temel OWASP Top 10 koruması.
• Ödeme Servis Sağlayıcısı: Kart verisini doğrudan işleyen harici PSP.

Burada kritik ayrım şu:

• Uygulama ve veritabanı sunucuları, kart verisini değil, sipariş ve müşteri verisini işler.
• PSP altyapısı ise kart verisini işler, saklar ve PCI‑DSS sertifikasyonunu üstlenir.

Böylece DCHost üzerindeki altyapınız hem PCI kapsamı dışında tutulur hem de KVKK/GDPR gibi diğer regülasyonlara uyumlu şekilde yönetilir. Veri yerelleştirme ve kişisel veri tarafındaki gereklilikleri daha geniş perspektiften ele almak isterseniz, KVKK ve GDPR uyumlu hosting mimarisi rehberimize de göz atabilirsiniz.

TLS, HTTP Güvenlik Başlıkları ve Tarayıcı Katmanı

“Kart verisi sunucuya gelmiyor” demek, tarayıcı ile PSP arasındaki trafiği de çok iyi korumanız gerektiği gerçeğini değiştirmiyor. Kullanıcı deneyimi sizin siteniz üzerinden başladığı için, müşterinin güven algısını belirleyen de yine sizin alan adınız.

Bu nedenle aşağıdaki alanlara özel önem veriyoruz:

• Modern TLS konfigürasyonu: Zayıf protokollerin ve şifre paketlerinin kapatılması, TLS 1.2/1.3 zorunluluğu, OCSP stapling, güçlü sertifikalar. Bunun için modern HTTPS için SSL/TLS protokol güncellemeleri rehberini öneriyoruz.
• HTTP Güvenlik Başlıkları: HSTS, X‑Frame‑Options, X‑Content‑Type‑Options, Referrer‑Policy ve özellikle Content‑Security‑Policy (CSP). CSP ile hangi domain’lerden script ve iframe yüklenebileceğini net tanımlayarak kart formu iFrame’ini de kontrollü şekilde kabul edebilirsiniz.
• Mixed content hatalarından kaçınma: Özellikle checkout adımlarında tüm kaynakların HTTPS üzerinden çağrıldığından emin olmalısınız.

HTTP başlıklarını doğru kurmak sadece güvenlik değil, tarayıcı tarafındaki bütünlüğü korumak açısından da önemli. Bu konuyu hem paylaşımlı hosting hem de VPS tarafında detaylı ele aldığımız HTTP güvenlik başlıkları rehberinden teknik örneklerle takip edebilirsiniz.

Tokenizasyon: Sunucuda Ne Tutuyorsunuz?

Kart verisini sunucudan uzak tutarken bile, tekrarlayan ödemeler (subscription), “kartı kaydet” fonksiyonları veya tek tıkla ödeme gibi özellikler çoğu mağazada ihtiyaç haline geliyor. Burada devreye tokenizasyon giriyor.

Genel mantık şöyle:

• Kullanıcı ilk kart girişini PSP’nin hosted formunda yapar.
• PSP, kartı kendi kasasında saklar ve size o kartı temsil eden token döner (örneğin tok_abc123...).
• Siz veritabanınızda gerçek kart numarası yerine sadece bu token’ı ve son 4 hane gibi maskelemiş bilgileri saklarsınız.
• Sonraki ödemelerde sadece bu token’ı PSP’ye gönderirsiniz; kart bilgisi tekrar sorulmaz.

Bu modelde dikkat edilmesi gerekenler:

• Token’ın kendisi kart verisi değildir; fakat yetkisiz erişim durumunda kötüye kullanılabilir. Bu yüzden veritabanı ve API güvenliğiniz hayati önem taşır.
• Token’ları içeren veritabanı yedekleri de hassas kabul edilmelidir; yedek şifreleme ve anahtar yönetimi rehberimizde anlattığımız yaklaşımlar burada da geçerlidir.
• Loglarda asla tam kart numarası, CVV veya PSP’ye gönderdiğiniz ham isteklerin içeriği bulunmamalıdır.

Doğru kurgulandığında, tokenizasyon hem kullanıcı deneyimini iyileştirir hem de kart verisini sunucudan uzak tutma hedefiyle çelişmeden tekrarlayan ödemeleri mümkün kılar.

Ağ, WAF, Loglama ve Yedekler: Kart Verisi Olmasa da Ödev Bitmiyor

Kart verisini sunucudan uzak tutmak PCI kapsamını küçültür; ama “güvenlik bitti” anlamına gelmez. Uygulama ve veritabanı sunucularınızda hâlâ sipariş, adres, telefon, e‑posta gibi kişisel veriler tutuyorsunuz. Bu veriler hem yasal (KVKK/GDPR) hem de itibar açısından kritik.

DCHost’ta önerdiğimiz temel pratikler:

• Ağ Segmentasyonu: Web, veritabanı ve yönetim (SSH/panel) trafiğini mümkün olduğunca ayrı segmentlerde tutmak; veritabanına doğrudan internetten erişimi kapatmak.
• WAF Kullanımı: Hem uygulama güvenliği hem de PCI‑DSS’in “saldırı tespiti ve önleme” gerekliliklerine uyum açısından WAF önemli bir bileşen. Origin WAF (ModSecurity) veya CDN WAF çözümleri hakkında daha fazla fikir edinmek isterseniz WAF karşılaştırma yazımıza göz atabilirsiniz (not: URL’yi örneklerken gerçekteki yazı adını kullanmalısınız).
• Loglama ve İzleme: Özellikle login, parola reset, yönetim paneli erişimleri, başarısız ödeme geri dönüşleri gibi alanlarda merkezi loglama ve alarm kuralları kritik. Bunu e‑ticaret odaklı ele aldığımız e‑ticaret log analizi rehberinde detaylandırdık.
• Yedek ve Felaket Kurtarma: Yedeklerin şifreli, farklı lokasyonda, 3‑2‑1 prensibine uygun tutulması ve düzenli kurtarma testleri yapılması gerekir.

Kısacası kart verisini sunucudan uzak tutmak, güvenlik yükünüzü sıfırlamaz; ama odak noktanızı uçtan uca siber güvenlikten, daha yönetilebilir bir “müşteri verisi koruması” düzeyine indirir.

Örnek Senaryo: WooCommerce + DCHost Üzerinde PCI‑DSS Dostu Mimari

Bu anlattıklarımızı somutlaştırmak için sahada sık gördüğümüz bir senaryoyu birlikte tasarlayalım: WooCommerce ile çalışan bir e‑ticaret sitesi, DCHost üzerinde barındırılıyor ve kart verisini sunucudan tamamen uzak tutmak istiyor.

1) Altyapı Katmanı

• DCHost üzerinde NVMe diskli bir VPS veya yoğun trafiğe göre dedicated sunucu seçilir.
• Sunucu üzerinde Nginx + PHP‑FPM + MariaDB stack’i kurulur; WordPress + WooCommerce için gerekli PHP ayarları, PHP‑FPM konfigürasyonu gibi optimizasyonlar yapılır.
• Sunucuya sadece SSH anahtarı ile erişim, firewall (ufw/firewalld) ve fail2ban gibi temel sertleştirme adımları uygulanır.

2) Domain, DNS ve TLS

• Alan adınız DCHost veya farklı bir registrar’da olabilir; DNS tarafında A/AAAA kayıtları DCHost sunucunuza işaret eder.
• Let’s Encrypt veya kurumsal SSL sertifikası ile HTTPS etkinleştirilir. Sertifika yönetimini kolaylaştırmak için ACME otomasyonu tercih edilebilir.
• HTTP → HTTPS kalıcı 301 yönlendirmesi, HSTS ve diğer güvenlik başlıkları yapılandırılır.

3) Ödeme Entegrasyonu

• WooCommerce içinde PSP eklentisi kurulur; entegrasyon türü olarak hosted payment page veya güvenli iFrame/JS SDK modeli seçilir.
• Checkout sayfasında kart formu, sizin backend’inize post etmeyecek şekilde yapılandırılır; form action ve JavaScript endpoint’lerinin PSP domain’inde olduğundan emin olunur.
• PSP’den dönen işlem sonucu ve token bilgileri, WooCommerce’in sipariş meta alanlarına kaydedilir; kart numarası veya CVV hiçbir zaman veritabanına yazılmaz.

4) Güvenlik ve İzleme

• WordPress yönetim paneli için 2FA, IP kısıtlama, güçlü parola politikaları ve WAF kuralları devreye alınır.
• Sunucu tarafında CPU, RAM, disk IO, HTTP 4xx/5xx oranları ve ödeme adımlarındaki hata oranlarını izleyen bir monitoring seti kurulur.
• Güvenlik güncellemeleri için otomatik yama veya kontrollü manuel güncelleme süreçleri tanımlanır.

Bu mimaride WooCommerce sunucusu hiçbir zaman PAN veya CVV görmediği için, teorik olarak SAQ A kapsamına yaklaşan bir model elde edersiniz. WooCommerce özelinde SAQ A / A‑EP ayrımını ve kontrol listesini detaylı anlattığımız PCI‑DSS uyumlu WooCommerce hosting kontrol listesine mutlaka göz atmanızı öneririm.

API, Webhook ve Mikroservislerde PCI‑DSS’e Dikkat

Modern e‑ticaret projelerinde sadece klasik web tabanlı checkout yok; mobil uygulamalar, harici pazaryerleri, B2B entegrasyonlar ve mikroservis tabanlı mimariler de devrede. Kart verisini sunucudan uzak tutma prensibi burada da geçerli.

Özellikle dikkat edilmesi gereken başlıklar:

• Ödeme API’leri: Mobil uygulamanız ödeme almak için doğrudan PSP’nin mobil SDK’sını kullanmalı; backend API’niz sadece token ve işlem sonuçlarıyla ilgilenmeli.
• Webhook’lar: PSP, ödeme sonucunu size webhook ile bildirebilir. Webhook endpoint’iniz hiçbir zaman kart verisi içeren payload almamalı; gelen JSON’u log’lamadan önce maskeleme yapılmalı.
• API Güvenliği: JWT, rate limiting, IP kısıtlama ve WAF kuralları ödeme ile ilgili endpoint’lerde çok daha sıkı olmalı. Bu başlıkları detaylı şekilde ele aldığımız API güvenliği ve hosting mimarisi rehberine mutlaka göz atın.

Kısacası, ister klasik web checkout, ister mobil uygulama, ister mikroservis olsun; kart verisini her zaman doğrudan PSP’ye gönderen bir akış tasarlamak mümkün ve tercih edilmelidir.

Operasyonel Boyut: Değişiklik Yönetimi, Dokümantasyon ve Denetim Hazırlığı

Teknik mimariyi doğru kurduktan sonra, PCI‑DSS uyumlu kalmak için operasyon tarafını da ciddiye almak gerekiyor. Kart verisini sunucudan uzak tutsanız bile, denetimlerde şu sorular mutlaka sorulur:

• Checkout akışında yapılan değişiklikler nasıl test ediliyor?
• Kod değişiklikleri için onay ve geri alma (rollback) süreci var mı?
• Güvenlik olayları nasıl tespit ve rapor ediliyor?
• Loglar ne kadar süre saklanıyor, kimler erişebiliyor?

Biz DCHost’ta müşterilerle çalışırken, bu sorulara cevap verebilen basit ama uygulanabilir süreçler kurmaya odaklanıyoruz:

• Geliştirme → staging → canlı ortam ayrımını net yapmak,
• Kritik ödeme akışlarında mutlaka staging üzerinde test koşmak,
• Konfigürasyon değişikliklerini (Nginx, PHP‑FPM, WAF kuralları vb.) versiyonlamak,
• Yedek testlerini ve felaket senaryolarını yılda en az bir kez prova etmek.

Bunlar kağıt üzerinde “dokümantasyon” gibi görünse de, pratikte hem PCI‑DSS hem KVKK/GDPR hem de genel siber güvenlik hijyeni açısından en çok değer üreten adımlar oluyor.

Sonuç: Kart Verisini Sunucudan Uzak Tutmak En Büyük Kazanımınız

Özetle, PCI‑DSS ile uğraşırken kendinize soracağınız en kritik soru şu: “Bu kart verisi gerçekten benim sunucuma gelmek zorunda mı?” Çoğu e‑ticaret projesinde cevap net bir şekilde “Hayır”. Doğru PSP entegrasyon modeli (hosted payment page veya güvenli iFrame/JS SDK), sağlam TLS ve HTTP güvenlik başlıkları, bilinçli tokenizasyon ve iyi tasarlanmış bir hosting mimarisi ile, uygulama ve veritabanı sunucularınızı kart verisi kapsamının dışına itebilirsiniz.

Bu yaklaşım size üç büyük kazanım sağlar:

• Daha küçük PCI kapsamı: SAQ A tarafına yaklaşan bir mimari ile denetim ve uyum maliyetleri düşer.
• Daha yönetilebilir güvenlik: Odak noktanız kart numarası yerine müşteri verisi korumasına kayar; bu da KVKK/GDPR ile daha tutarlı bir çerçeve sunar.
• Daha az teknik risk: Sunucu tarafındaki bir açık, kart sızıntısı yerine “sadece” kişisel veri ihlaline dönüşür; bu bile başlı başına ciddi olsa da, finansal sonuçları çok daha yönetilebilir kalır.

Eğer mevcut e‑ticaret sitenizde kart formu hâlâ sizin domain’inizde render ediliyor, form action’ı doğrudan sunucunuza post ediyorsa veya entegrasyon modelinizin sizi SAQ A mı A‑EP mi tarafına ittiğinden emin değilseniz, DCHost ekibi olarak mimarinizi birlikte gözden geçirebiliriz. Hem mevcut altyapınızı PCI‑DSS dostu hale getirmek hem de yeni projelerinizi baştan doğru kurgulamak için, sunucu seçimi, ağ tasarımı, WAF, yedekleme ve denetim hazırlığı dahil uçtan uca bir yol haritası çıkarmak mümkün. Bir sonraki ödeme entegrasyonu kararınızı, kart verisini sunucudan tamamen uzak tutacak şekilde birlikte tasarlayalım.