PCI-DSS Uyumlu E-ticaret: Kart Bilgisi Saklama ve Sunucu Planı

E-ticarette kart bilgisi (PAN), ödeme altyapısının en kritik parçasıdır. Yanlış tasarım sadece güvenlik riskini artırmaz; PCI-DSS (Payment Card Industry Data Security Standard) kapsamını genişleterek denetim maliyetini de yükseltir. Bu rehberde, kart bilgisi nerede tutulmalı, nerede tutulmamalı ve PCI-DSS kapsamını nasıl daraltacağınızı sunucu ve hosting perspektifiyle adım adım ele alacağız. Hedefimiz: Kapsamı somut şekilde azaltan bir mimari kurup, kontrol listelerini hangi teknik noktada doğrulayacağınızı netleştirmek.

PCI-DSS kapsamını belirleyen ana kural: Kart bilgisi nerede duruyor?

PCI-DSS denetiminin “kapsam” (scope) tarafı, kart bilgisiyle doğrudan temas eden sistemlerin sayısını belirler. Kapsamı artıran en yaygın senaryolar şunlardır: - Kart numarasını (PAN) uygulama sunucusunda saklamak (ör. veritabanı alanında) - Tam kart verisini log’lara yazmak - Kart verisini iletirken yanlış TLS ayarıyla “zayıf şifre paketleri” kullanmak - Erişim yetkilerini geniş tutmak (her geliştiricinin her sunucuya tam yetkiyle erişmesi gibi)

Kapsamı daraltan yaklaşım ise “kart verisini hiç tutmamak”tır. Pratikte iki yol vardır: 1. 3D Secure + ödeme sayfası (hosted payment page): Kart girişi sağlayıcının sayfasında olur; sizin sistemlerinize PAN gelmez. 2. Tokenizasyon: Kart bilgisi yerine sağlayıcının verdiği token saklanır. Bu token genellikle PCI kapsamını ciddi biçimde daraltır (detay token türüne ve sağlayıcı sözleşmesine göre değişir).

Kapsam daraltma hedefi

Aşağıdaki hedef, teknik mimaride “başlangıç kriteri” gibi düşünülmelidir: - Uygulama sunucusu PAN almamalı. - PAN saklanmamalı. - Log’larda PAN görüntülenmemeli. - Kart verisiyle ilişkili alanlar (uç nokta → uygulama → veritabanı) ayrıştırılmalı.

Kart bilgisi saklama seçenekleri: Ne kadar PCI kapsam yaratır?

Aşağıdaki tablo, e-ticaret mimarilerinde kart verisi akışına göre PCI-DSS kapsamının pratikte nasıl değiştiğini özetler. (Not: Kesin sınıflandırma sağlayıcıyla yapılan sözleşme ve ödeme akışına göre değişebilir; ancak teknik tasarımın etkisi genellikle bu yöndedir.)

Tasarım seçeneği	Kart verisi sizin sisteminize gelir mi?	PCI kapsam etkisi (genel yön)	Tipik teknik karşılık
Hosted payment page (sağlayıcı sayfası)	Hayır (PAN sizde olmaz)	En düşük	Uygulama sadece ödeme isteği gönderir, kart girişi sağlayıcıda olur
Tokenizasyon (sadece token saklama)	PAN sizde olmaz, token saklanır	Düşük-orta	Veritabanında token + işlem referansı saklanır
Kendi ödeme formunuzda kart girişi	Evet (PAN uygulamaya gelir)	Yüksek	PAN’yi uygulama katmanı görür; izolasyon ve denetim gerekir
Kart verisini veritabanında saklama	Evet	En yüksek	Düzeltme maliyeti de en yüksek

Net karar kılavuzu

E-ticaret için hedefiniz “PCI kapsamını küçültmek” ise şu öncelik sırasını kullanın: 1. Hosted payment page (mümkünse) 2. Tokenizasyon 3. Kart girişini kendi formunuzdan almanız gerekiyorsa: ağ izolasyonu + sıkı denetimler 4. Asla PAN saklamayın; istisna oluşturmaya çalışmayın

PCI-DSS uyumluluğu için hosting ve sunucu mimarisi

PCI-DSS, sadece uygulama kodunu değil; hosting seçimini, ağ segmentasyonunu, erişimi ve log yönetimini de kapsar. E-ticaret tarafında “kart verisiyle teması olan alanlar”ı ayrıştırmak, uyumluluğu hızlandıran en somut adımdır.

Ağ ayırımı: Kart akışını diğer sistemlerden izole edin

Kart verisinin geldiği senaryolarda (ör. kendi ödeme formunuz) en kritik teknik nokta, sistemleri katmanlara ayırmaktır: - Genel web sunucusu (müşteri, admin panel, site içerikleri) - Ödeme işlemlerinin yürütüldüğü ayrı uygulama/endpoint - Veritabanı (en az erişim ilkesine uygun) - Admin erişim ağı (VPN veya bastion üzerinden)

Önerilen yaklaşım: - Ödeme endpoint’i için ayrı sanal makine (veya ayrı container/namespace) - Veritabanına sadece uygulama katmanından erişim - Genel web sunucusundan veritabanına doğrudan bağlantıyı engelleme

Erişim kontrolü: “Kim nereden neyi yapıyor?” sorusunu kapatın

PCI-DSS uyumluluğunda denetçiler genellikle şu kontrolleri sorar: - Yönetici erişimi için MFA kullanımı - En az ayrıcalık (least privilege) - Şifre tabanlı zayıf uygulama erişimlerinin kısıtlanması - Ayrıcalıklı işlemlerin izlenmesi

Teknik uygulama örnekleri: - SSH erişiminde anahtar (SSH key) tabanlı giriş, şifreyi kapatma - Admin panellerine IP kısıtı veya VPN/bastion ile erişim - CI/CD üzerinden değişikliklerin loglanması

Şifreleme (encryption): Aktarım ve saklama

PCI-DSS’te şifreleme iki eksende ele alınır: - İletim sırasında: TLS ile veri yolunun korunması - Saklama sırasında: diskte ve uygulama katmanında koruma

Net teknik hedefler: - İstemci → web/payload endpoint arasında güncel TLS ayarı - Şifreleme at rest: veritabanı diski ve hassas alanlar için uygun mekanizmalar - Anahtar yönetimi: anahtarların uygulama kodu içinde sabitlenmemesi

Uyumlu bir ödeme akışı nasıl tasarlanır? (Adım adım plan)

Aşağıdaki plan, bir e-ticaret sisteminde kart verisinin nerede olacağını belirleyerek başlayıp sunucu konfigürasyonlarına iner. Bu sırayla ilerlemek, “sonradan kapsam büyümesi” sorununu azaltır.

1) Önce ödeme sağlayıcısı akışını netleştirin

Hosted payment page kullanıyorsanız: kart girişi sağlayıcının sayfasında olur, siz sadece işlem referansını alırsınız.
Tokenizasyon kullanıyorsanız: token saklanır, tekrar ödeme akışında token kullanılır.
Kendi ödeme formunuz varsa: PAN’in sizin sunucunuza gelip gelmediğini ve hangi bileşende işlendiğini yazılı olarak netleştirin.

2) “Kapsama giren” sistemleri listeleyin

Denetim hazırlığı için pratik yöntem: - Uygulama sunucularınızı rollerine göre ayırın - PAN görme ihtimali olan bileşenleri etiketleyin - Veritabanında saklanan alanları tarayın (token mı, PAN mi?) - Log’larda hassas veri maskeleniyor mu kontrol edin

3) Sistemleri segmentlere ayırın

Public web katmanı: sadece web trafiğini alsın
Payment işlemleri katmanı: özel ağ kurallarıyla kısıtlı erişim alsın
Database: sadece ilgili uygulama katmanından erişsin

4) Log ve izleme standardını kurun

PCI-DSS uyumluluğu için log konusu sadece “log var mı?” değil; “log’larda hassas veri var mı?” ve “loglar doğru tutuluyor mu?” sorusudur.

Somut kontrol listesi: - Uygulama loglarında PAN veya full kart detayları bulunmamalı - Hata durumlarında stack trace içinde kart verisi yazılmamalı - Erişim logları (admin ve ödeme endpoint) ayrı tutulmalı - Logların bütünlüğü: değiştirilemez depolama (WORM) gerekebilir; en azından erişim kontrolü ve saklama politikası şart

5) Yedekleme (backup) ve geri dönüş planı

Kart verisiyle ilgili sistemlerde yedekleme daha kritik hale gelir. Burada iki nokta belirleyicidir: - Yedeklerde hassas veri bulunmamalı (tasarım gereği token saklanıyorsa risk azalır) - Yedekler şifreli olmalı ve erişim yetkisi sınırlandırılmalı

PCI-DSS için pratik kontrol: Sunucu tarafında nelere bakmalısınız?

Aşağıdaki maddeler, e-ticarette kart bilgisiyle ilgili uyumluluğa doğrudan etki eden sunucu/hosting noktalarını özetler.

İyi bir “başlangıç kontrol listesi”

TLS: Ödeme endpoint’inde güncel TLS kullanımı
MFA: Admin erişimlerinde iki aşamalı doğrulama
Erişim: Sadece gerekli IP/kişiler yönetim arayüzlerine erişsin
Şifreleme: Veritabanı ve disk şifreleme (en azından at rest)
Log maskeleme: Kart verisinin asla log’a düşmemesi
Ayrım: Payment işlemleri için ayrı endpoint/katman
Yedekleme: Hassas veri yedekte yok veya şifreli ve erişimi kısıtlı
Güncelleme: OS ve middleware için düzenli patch

Denetimde en sık tartışılan 3 konu

Kart verisinin kapsam dışı kalıp kalmadığı
Log’larda hassas veri bulunup bulunmadığı
Erişim kontrolünün “en az ayrıcalık” ilkesine uygunluğu

Bu üç başlık netleşince, geri kalan maddeler daha hızlı kapanır.

Farklı hosting yaklaşımlarında PCI-DSS etkisi

Hosting türü, PCI-DSS uyumluluğunu belirleyen unsurlardan biridir. Çünkü platformun sorumluluk sınırı (müşteri mi sağlayıcı mı) kontrol listelerinde farklı görünür.

Managed vs unmanaged: Soruyu doğru sorun

E-ticarette PCI-DSS hazırlarken şu ayrımı yapın: - Managed servislerde: yamalama, bazı güvenlik katmanları sağlayıcı tarafından yürütülebilir - Unmanaged servislerde: yama ve güvenlik yapılandırmasını siz yürütürsünüz

Bu, teknik olarak “sizin sorumluluğunuz” ile “sağlayıcının sorumluluğu” arasındaki sınırı etkiler.

Sonuç: PCI kapsamını küçültmeye odaklanan aksiyon planı

PCI-DSS uyumluluğunu “tek seferlik bir doküman” gibi değil, mimari bir hedef gibi ele alın. En hızlı yol, kart verisini sizin sistemlerinizde tutmayan ödeme akışını seçmek ve kalan bileşenleri ağ, erişim ve loglama seviyesinde ayırmaktır. Bu yazıyı okuduktan sonra bugün yapmanız gerekenler: - Ödeme sağlayıcınızın hosted payment page veya tokenizasyon sunduğunu yazılı akış olarak belirleyin. - Veritabanınızda PAN aranışı (alan taraması) yapın: token dışında bir şey saklamadığınızı doğrulayın. - Ödeme endpoint’i ile genel web katmanını ayırın ve admin erişimini MFA + IP/VPN/bastion ile sınırlandırın. - Uygulama loglarında kart verisi maskelenmesini ve geri dönüş sürecinde yedeklerin şifreli olmasını kontrol edin.

Bu adımlar, hem güvenliği artırır hem de denetim kapsamını somut biçimde küçültür.