E-ticarette PCI-DSS: Kart bilgisi saklamadan uyumluluk

E-ticarette ödeme süreçleri, güvenlik ve mevzuat uyumluluğunun en hassas alanıdır. PCI-DSS (Payment Card Industry Data Security Standard), kart verisinin nasıl işlendiğini, taşındığını ve saklandığını belirleyen teknik bir çerçevedir. Bu yazıda, kart bilgisi saklamadan (ve mümkün olduğunca da akmayan veriyi kendi altyapınızdan geçirmeden) PCI-DSS uyumluluğunu nasıl tasarlayacağınızı öğreneceksiniz. Ayrıca hangi kontrol maddelerinin gerçekten kritik olduğunu, tipik yanlışları ve NetKıyas’taki hosting/VPS seçim mantığıyla güvenliği nasıl beraber kurgulayacağınızı netleştireceğiz.

PCI-DSS neyi zorlar: “Saklıyor musunuz?” sorusu

PCI-DSS uyumluluğu tek bir “güvenlik ürünü” ile sağlanmaz; kart verisinin yaşam döngüsünü (life cycle) kimin, nerede ve nasıl yönettiğine bağlıdır. Pratikte belirleyici soru şudur:

Kart numarası, son kullanma tarihi (exp), CVV/CVC gibi hassas veriler sizin sisteminizden geçiyor mu?
Bu veriler sizin sunucularınızda depolanıyor mu?
Sunucularınız, tarayıcıdan gelen kart verisini işleyip ödeme ağ geçidine (payment gateway) iletmeden önce bir noktada görünüyor mu?

Kart verisi sizin sisteminize hiç girmiyorsa, PCI-DSS kapsamı ciddi şekilde daralır. Bu yaklaşım “kart verisini dışarıda bırakma” stratejisi olarak düşünülür ve e-ticaret mimarisinde en fazla fark yaratan yöntemlerden biridir.

Kart verisini kendi sisteminizde tutmanın maliyeti

Kart bilgisi saklamak zorunda olduğunuzda uyumluluk maliyeti ve operasyon yükü hızla artar. Çünkü:

Ağ bölümlendirme (network segmentation) ve erişim kontrolü daha sıkı hale gelir.
Log tutma ve izleme (monitoring) standartları yükselir.
Yama yönetimi (patch management), konfigürasyon sabitleme ve güvenli yapılandırma doğrulaması daha düzenli yapılmalıdır.
İnceleme süreçleri için kanıt (evidence) üretmek gerekir.

Bu yüzden hedefiniz “PCI-DSS kapsamını daraltmak” olmalıdır. Bunu en net biçimde, kart verisini doğrudan sizin sisteminizin işlemesinden çıkararak yaparsınız.

Kart bilgisi saklamadan ödeme mimarisi: 3 doğru yol

PCI-DSS uyumluluğunu teknik olarak kolaylaştıran yaklaşım, kart verisinin sizde işlem görmediği akışları tasarlamaktır. E-ticaret senaryolarında üç yaygın mimari vardır.

1) Hosted Checkout / Redirect ile ödeme

Bu modelde ödeme formu, ödeme sağlayıcının (PSP) barındırdığı “hosted checkout” sayfasında görünür. Kullanıcı ödeme adımında sizin alan adınızdan çıksa da tasarım/brand uyumu sağlanabilir.

Artı: Kart verisi tarayıcıdan doğrudan PSP’ye gider; sizin sunucularınız “kart verisi görmez”.
Eksi: Kullanıcı akışı ve sayfa geçişleri UX tarafında iyi tasarlanmalıdır.

2) Payment Gateway tokenization (token üretimi)

Bazı sağlayıcılar, kart bilgisi sizde işlenmeden bir “token” ürettirir. Sizin sisteminiz yalnızca token’ı saklar.

Artı: Sonrasında ödeme işlemi token ile tetiklenir.
Eksi: Uygulama tarafında doğru şekilde “token’ı doğrulama” ve “loglara kart verisi yazmama” disiplin gerektirir.

3) PCI kapsamında olmayan bileşenleri kullanma: kart girişi olmayan UI

Kart numarası, CVV gibi alanları sizde render etmeyip, tarayıcıdan gelen hassas veriyi sizin kontrol ettiğiniz UI katmanında toplamamayı hedeflersiniz.

Artı: PCI kapsam alanı daha da küçülür.
Eksi: Checkout tasarımı sağlayıcı entegrasyon kısıtlarına uyumlu olmalıdır.

PCI-DSS kapsamını daraltmak için net kontrol listesi

Aşağıdaki maddeler, “kart bilgisi saklamadan PCI-DSS uyumluluğu” hedefi için pratik bir kontrol listesi sunar.

Uygulama ve kod kontrolleri

Kart numarası/CVV/exp alanlarını sizin uygulama kodunuzda işlemeyin.
Form gönderiminde kart verisini backend’e almamaya odaklanın.
Hata loglarına (application logs) kart verisi yazmayın. Örneğin payment hatasında request body’nin tamamı loglanıyorsa bunu kapatın.
İstemci tarafı (frontend) doğrulamalarına güvenip “server tarafında kart verisini yine de almak” gibi yanlışlara düşmeyin.

Ağ (network) kontrolleri

Backend’in ödeme sağlayıcısı ile trafiğini yalnızca gerekli noktalara yönlendirin.
Public internet’ten erişimi azaltın. Ödeme bileşenleri ve veritabanı yalnızca gerekli ağ segmentlerinde erişilebilir olsun.
Admin arayüzleri için IP kısıtlama ve VPN/zerotrust tercih edin.

Sistem ve erişim kontrolleri

Sunucularda sadece gerekli servisler açık olsun (minimum exposure).
SSH erişimi için şifre yerine anahtar (SSH key) kullanın ve kök kullanıcı pratiklerini azaltın.
Yama yönetimini standartlaştırın: işletim sistemi, web sunucusu, runtime (ör. Node.js) ve kütüphaneler.

Hosting/VPS seçimi: PCI-DSS’i “sunucu” ile nasıl ilişkilendireceksiniz?

PCI-DSS doğrudan hosting sağlayıcısını tek başına belirlemez; ancak ödeme bileşenlerinin barındırıldığı sunucuların güvenliği ve yönetilebilirliği uyumluluğu etkiler. E-ticaret siteniz için doğru sunucu yaklaşımı şöyledir:

Hangi katmanı PCI kapsamından uzak tutarsınız?

Eğer ödeme sağlayıcısı hosted checkout veya tokenization sunuyorsa, sizde PCI kapsamına giren alanlar azalır. Bu durumda sizin sunucularınızın ana sorumluluğu şunlar olur:

Sepet/checkout sayfası dışındaki normal web uygulaması
Sipariş yönetimi ve ödeme sonucunu alma
Token’ı ve sipariş bilgisini saklama

Bu ayrım, sunucu güvenliğini uygulama güvenliği ve erişim kontrolüne daha çok odaklar.

VDS/VPS’te pratik güvenlik mimarisi

Kart verisi sizde olmadığı için “tam bir cardholder data environment” kurmak zorunda kalmazsınız; yine de saldırı yüzeyi küçülmelidir. Somut olarak:

Uygulama sunucusu ile veritabanını ayrı VDS/VPS veya en azından ayrı güvenlik grupları/segmentlerde konumlandırın.
Yönetim erişimini (SSH, kontrol paneli) minimuma indirin. Örneğin sadece ofis IP’lerinden veya bastion host üzerinden erişim.
Otomatik güvenlik güncellemelerini kontrol edin. Otomatik güncelleme + restart politikası olmadan “yedekli ama güncel olmayan” sistem risktir.

Not: Yedek (backup) stratejisi PCI’da dolaylı rol oynar. Token veya sipariş verisi yedeklerde kalabilir; dolayısıyla yedeklerin şifreli saklanması ve erişim kısıtları gereklidir.

Kanıt (evidence) üretimi: denetimde neye bakılır?

PCI-DSS’te denetim, “düzgün uygulandı” iddiasından çok kanıt ister. Kart verisini sizde tutmuyor olsanız bile şu kanıt setleri kritik olur:

Konfigürasyon kayıtları: sunucuda hangi servislerin çalıştığı, güvenlik duvarı kuralları
Erişim logları: yönetici erişimleri, yetki değişiklikleri
Yama yönetimi kayıtları: hangi tarihte hangi paket güncellendi
Uygulama loglama politikası: kart verisinin asla loglanmadığı
Yedekleme ve geri yükleme testi: “yedek var” değil, “yedekten geri dönebiliyoruz” kanıtı

Bu kanıtları düzenli üretmek için her şeyi tek bir “denetim günü” işine bırakmayın. E-ticaret operasyonu boyunca aylık rutinler oluşturun.

Yedekleme, saklama ve şifreleme

PCI-DSS doğrudan “yedekleme süresi” gibi parametreleri tek başına belirlemez; ancak kart verisi saklamasınız bile hassas olabilecek sipariş/ödeme ilişkili veriler yedeklerde olabilir. Net bir yaklaşım:

Uygulama/veritabanı yedeklerini şifreli saklayın (encryption).
Saklama süresini iş ihtiyacına bağlayın: ör. günlük + haftalık + aylık katmanlı model.
Geri yükleme testini en azından aylık yapın.

Yaygın yanlışlar (PCI-DSS sorununu büyüten 7 hata)

Aşağıdaki hatalar, kart verisi saklamasanız bile uyumluluk yolculuğunuzu uzatır.

Hosted checkout kullanırken yine de backend’e kart alanlarını göndermek
Ödeme hatası sırasında request body’yi loglamak
Token’ı saklarken token’ı doğrulama olmadan her isteğe uygulamak
Yama gecikmesi: işletim sistemi ve runtime bileşenlerini güncellememek
Admin panellerini internete açık bırakmak
Yedekleri şifrelemeden veya erişimi kısıtlamadan saklamak
“Biz PCI’ya uymuyoruz” deyip denetim kanıtlarını toplamamak

Bu hataların çoğu kod ve operasyon disiplininden kaynaklanır. Sunucuda doğru yapı kurmak şarttır ama tek başına yeterli değildir.

NetKıyas bakış açısıyla: ödeme mimarinizi planlarken sunucu hangi soruya yanıt vermeli?

E-ticaret için VDS/VPS seçerken “PCI uyumluluğunu” doğrudan ölçemezsiniz; ancak aşağıdaki sorulara net yanıt alabilirsiniz.

Yönetim erişimi ne kadar kontrollü (IP kısıtı, bastion, rol tabanlı erişim)?
Güncelleme ve yeniden başlatma politikası işletmeyi aksatmayacak mı?
Yedekleme altyapısı şifreleme ve geri yükleme süresi hedeflerine uyuyor mu?
Uygulama ve veritabanını ayırmak mümkün mü?
Log erişimi ve saklama süreleri yönetilebilir mi?

Bu sorulara “evet” diyebildiğinizde hem güvenlik hem de denetim hazırlığı belirgin şekilde kolaylaşır.

Sonuç: Kart verisini dışarıda tutun, sunucuyu kanıt üretmeye hazır hale getirin

PCI-DSS uyumluluğu e-ticarette çoğu zaman “kart bilgisi saklama zorunluluğu” ile büyür. En doğru aksiyon, hosted checkout veya tokenization gibi yöntemlerle kart verisinin sizin sunucunuza hiç girmediği bir mimari kurmaktır. Ardından uygulama loglama disiplinini, ağ segmentasyonunu, erişim kontrollerini ve şifreli yedek/geri yükleme testlerini düzenli hale getirin. Ödeme süreçlerinde kart verisi yaşam döngüsünü küçülttüğünüzde hem teknik kapsam hem de denetim yükü gerçek anlamda azalır.

Eğer mevcut altyapınızda kart form alanları backend’e gidiyorsa, ilk adım bunu kesmek olmalıdır. Eğer zaten tokenization/hosted checkout kullanıyorsanız ikinci adım, loglar ve yedeklerin kart verisi içermediğini doğrulamak ve denetim kanıtlarını düzenli toplamak olmalıdır.