PCI-DSS Kapsamını Daraltmak: E-Ticarette Doğru Altyapı Seçimi

E-ticaret sitenizde ödeme alıyorsanız PCI-DSS (Payment Card Industry Data Security Standard) kaçınılmaz bir gerçektir. Ancak çoğu geliştirici ve site sahibi, hosting altyapısı kararlarının bu uyumluluğu doğrudan etkilediğini fark etmez. Yanlış bir sunucu yapılandırması sizi tam kapsamlı denetime, on binlerce dolara ve ciddi bir iş yüküne sürüklerken, doğru teknik tercihlerle kapsam o kadar daraltılabilir ki yılda bir kez doldurduğunuz tek sayfalık bir form yeterli olur. Bu rehber, hangi altyapı kararlarının PCI-DSS yükünüzü hafiflettiğini teknik düzeyde açıklar.

PCI-DSS Nedir ve Hangi Seviyelerde Geçerlidir?

PCI-DSS, Visa, Mastercard, Amex gibi kart şemalarının oluşturduğu bir güvenlik standardıdır. Kart verisi işleyen, depolayan veya ileten her sistemi kapsar. "İşlemek" kelimesinin geniş yorumlandığına dikkat edin: ödeme formunun yüklendiği sayfa bile kapsama girebilir.

Dört seviye vardır ve yıllık işlem hacmiyle belirlenir:

Türkiye'deki e-ticaret sitelerinin büyük çoğunluğu Seviye 3 veya 4'e girer. Bu seviyelerde SAQ (Self-Assessment Questionnaire — öz değerlendirme anketi) doldurmak yeterlidir; ancak hangi SAQ formunu doldurduğunuz, altyapınıza doğrudan bağlıdır.

Kapsam Neden Bu Kadar Kritik?

PCI-DSS kapsamı, kart verisiyle temas eden veya temas edebilecek tüm sistemleri içerir. Kapsam büyüdükçe:

• Karşılamanız gereken kontrol sayısı artar (PCI-DSS 4.0'da 300'ün üzerinde gereksinim bulunur)
• Üçüncü taraf güvenlik açığı taraması (ASV scan) zorunlu hale gelir
• Penetrasyon testi yapmanız beklenir
• Yıllık uyumluluk maliyeti 5.000–50.000 USD aralığına çıkabilir

Kapsam küçüldükçe yük azalır. Hedef: kart verisinin kendi sunucularınıza hiç uğramamasını sağlamak.

Ödeme Entegrasyonu Türlerinin Kapsama Etkisi

Kart verisinin altyapınızla nasıl temas ettiği, kapsamınızı belirleyen en kritik faktördür. Dört ana yöntem vardır:

1. Redirect (Yönlendirme) Yöntemi

Kullanıcı, ödeme sırasında bankanın veya ödeme altyapısının sayfasına yönlendirilir. Kart verisi hiçbir zaman sizin sunucunuza uğramaz.

• SAQ türü: SAQ A (en kısa, yaklaşık 22 soru)
• Örnek: iyzico, PayTR, Stripe Checkout (yönlendirme modeli)
• Dezavantaj: Kullanıcı sitenizden çıkar; dönüşüm oranı düşebilir

2. iframe / JavaScript Embed Yöntemi

Ödeme formu, ödeme sağlayıcısının alan adından bir iframe ile sitenize yerleştirilir. Kart verisi iframe içinde yakalanır, sizin sunucunuza gelmez.

• SAQ türü: Sayfada başka harici script yoksa SAQ A; varsa SAQ A-EP
• Kritik nokta: Google Tag Manager veya reklam pikseli gibi üçüncü taraf JavaScript'ler sayfada çalışıyorsa kapsam genişler

3. Hosted Fields / Tokenization

Form görsel olarak sitenizde durur, ancak her alan kart sağlayıcısının SDK'sı tarafından kontrol edilir. Kart numarası hiçbir zaman DOM'a düz metin olarak girmez, direkt token'a dönüşür.

• SAQ türü: SAQ A-EP veya SAQ D (yapılandırmaya göre değişir)
• Avantaj: Tam görsel özelleştirme ve yüksek dönüşüm oranı
• Gereklilik: Sunucu tarafında PCI-uyumlu yapılandırma zorunludur

4. Kendi Formunuz + Direkt API

Kart verisini kendi HTML formunuzla toplayıp ödeme sağlayıcısının API'sine iletiyorsanız, veri sunucunuzdan geçiyor demektir.

• SAQ türü: SAQ D (en uzun, 300'ün üzerinde soru)
• Kapsam: Sunucunuz, ağınız, veritabanınız ve bağlı sistemlerin tamamı dahil
• Tavsiye: Kaçınılabildiği her durumda bu yöntemden uzak durun

Hosting Altyapısının Kapsama Direkt Etkisi

Entegrasyon türünü belirledikten sonra altyapı kararları devreye girer.

Paylaşımlı Hosting: PCI-DSS açısından risklidir. Aynı sunucuda başka siteler çalışır; izolasyon eksikliği kapsam değerlendirmelerinde sorun yaratır. SAQ A için bile bazı banka ve acquirer'lar paylaşımlı hostingde çalışan siteleri kabul etmez. Ödeme alan bir site için paylaşımlı hosting kullanmayın.

VPS / VDS: Sanal özel sunucu, izolasyon sağlar ve PCI-DSS kapsam küçültme için uygun başlangıç noktasıdır. Ancak işletim sistemi güncelleme ve güvenlik duvarı (firewall) konfigürasyonu sorumluluğu size aittir. SAQ A ve SAQ A-EP için iyi yapılandırılmış bir VPS yeterlidir.

Yönetilen Bulut: AWS, Azure veya Google Cloud gibi platformlarda PCI-uyumlu ortam kiralayabilirsiniz. Fiziksel güvenlik ve altyapı uyumu sağlayıcı sorumluluğundadır; işletim sistemi ve uygulama güvenliği sizin sorumluluğunuzdadır. Bu model kapsamı küçültür ama ortadan kaldırmaz.

Sunucu Tarafında Yapılması Gereken Minimum Teknik Adımlar

SAQ A dışında kalan entegrasyonlar için sunucu yapılandırması kritiktir. PCI-DSS 4.0'ın temel gereksinimleri:

Ağ Güvenliği - Gelen trafiği kısıtlayan güvenlik duvarı kuralları (yalnızca 80 ve 443 portları dışarıya açık olmalı) - SSH erişimi IP kısıtlamasıyla sınırlanmalı; 0.0.0.0/0 kabul edilemez - Ödeme bileşenleri diğer sistemlerden ağ düzeyinde ayrılmalı

TLS Zorunluluğu

TLS 1.0 ve 1.1 devre dışı bırakılmalıdır — PCI-DSS 4.0 bunu zorunlu kılmaktadır. Hızlı test için:

openssl s_client -connect siteniz.com:443 -tls1

Bu komut bağlantı kuruyorsa uyumsuzluk var demektir. Sunucunuzda yalnızca TLS 1.2 ve TLS 1.3 etkin olmalıdır.

Günlük (Log) Yönetimi - Tüm erişim günlükleri en az 12 ay saklanmalı, 3 ay hızlı erişilebilir olmalı - Günlük bütünlüğü korunmalı (değiştirme tespiti aktif olmalı)

Yama Yönetimi - Kritik yamalar 1 ay içinde uygulanmalı - PCI-DSS 4.0 Gereksinim 6.3: Tüm sistem bileşenleri desteklenen ve güncel yamalar içermeli

SAQ Türünü Belirlemek: Hangi Altyapı Hangi Formu Getirir?

SAQ A'da yaklaşık 22, SAQ A-EP'de 191, SAQ D'de 300'ün üzerinde soru vardır. Bu sayılar aynı zamanda karşılamanız gereken kontrol sayısını gösterir.

Yanlış Altyapı Seçiminin Gerçek Maliyeti

Bir e-ticaret sitesinin yanlış yapılandırma nedeniyle SAQ A yerine SAQ D kapsamına girmesi, yıllık ek maliyeti şu şekilde değiştirir:

• ASV tarama (harici güvenlik açığı taraması): 500–2.000 USD/yıl
• Penetrasyon testi: 3.000–15.000 USD/yıl
• Uyum danışmanlığı: 2.000–10.000 USD
• Veri ihlali sonrası ceza (Visa/Mastercard): 5.000–100.000 USD ve üzeri, artı kart değişim maliyeti

Karşılaştırma için: redirect modelini kullanan, SAQ A kapsamındaki bir site için yıllık uyumluluk yükü neredeyse sıfırdır — yılda bir kez form doldurmak dışında.

Sonuç: Doğru Kararı Baştan Verin

PCI-DSS uyumluluğu bir hosting sorunu değil, mimari bir karardır — ama hosting kararları bu mimariyi doğrudan şekillendirir. Beş somut tavsiye:

1. Entegrasyonu seçerken önce kapsamı düşünün. Mümkünse redirect veya iframe yöntemi kullanın; kart verisini kendi formunuzdan geçirmeyin.
2. Paylaşımlı hostingden uzak durun. Ödeme alan her site VPS/VDS ya da yönetilen bulut üzerinde çalışmalı.
3. TLS 1.0 ve 1.1'i devre dışı bırakın. 10 dakikalık bir yapılandırma değişikliği, PCI-DSS 4.0 uyumu açısından zorunludur.
4. SAQ türünüzü geliştirme başlamadan belirleyin. Hangi entegrasyonun hangi formu gerektirdiğini önceden netleştirin; geliştirme bittikten sonra değiştirmek pahalıdır.
5. Log saklama politikasını hosting seçerken sorun. 12 aylık günlük saklama, dar disk kotalarıyla gelen ucuz VPS paketlerinde sorun yaratabilir.

Teknik altyapıyı doğru kurmak, PCI-DSS'i her yıl uğraşılan bir yük olmaktan çıkarır ve bir kez kurulup yılda bir kontrol edilen bir sisteme dönüştürür.