PCI DSS ve E‑Ticaret Hosting İlişkisini Doğru Kurmak
E-ticaret ödeme akışı, hosting mimarisinin güvenlik sorumluluklarını belirler. PCI DSS kapsamı; kart verisini saklayan, işleyen veya ileten sistemleri, bunlarla sınırsız bağlantısı olan bileşenleri ve verinin güvenliğini etkileyebilen sistemleri içerir. Ödeme sağlayıcısına yönlendirme kapsamı azaltabilir; mağazanın güvenlik sorumluluğunu tamamen ortadan kaldırmaz.
Bu rehberde, PCI DSS dokümanındaki madde madde gereksinimleri ezberletmek yerine, pratikten yola çıkıyoruz: E‑ticaret projeniz için hangi hosting mimarisi daha güvenli, hangi SSL/TLS ayarları gerçekten zorunlu, logları nasıl tutmalı ve saklamalı, yedekleri nasıl planlamalısınız? Hosting mimarisi, TLS, loglama ve yedekleme kararlarını uygulanabilir güvenlik örnekleriyle ele alacağız.
Bu rehber PCI DSS v4.0.1, Ocak 2025 tarihli SAQ A r1 ve güncel PCI SSC açıklamaları esas alınarak hazırlanmıştır. 31 Mart 2025 tarihinde zorunlu hale gelen kontrolleri güncel durumlarıyla ele alır. Sunucu/ağ güvenliği, TLS, loglama ve yedeklemeyi planlamanıza yardımcı olur; belirli bir hosting paketine uyumluluk belgesi vermez. Kapsamınıza uygulanacak maddeleri, raporlama yöntemini ve sorumlulukları ödeme kuruluşunuz veya üye işyeri bankanızla doğrulayın.
PCI DSS Temelleri: Scope, SAQ ve Hostingin Rolü
PCI DSS kart hesabı verilerinin güvenliğini ele alır. Account data, kart sahibi verisi (CHD) ve hassas kimlik doğrulama verisini (SAD) kapsar. Tam kart numarası PAN, CHD için belirleyici unsurdur; kart sahibi adı, son kullanma tarihi ve hizmet kodu PAN ile birlikte bulunduğunda veya başka şekilde CDE içinde mevcut olduğunda ilgili CHD korumalarına tabidir. CVV/CVC, PIN/PIN blokları ve tam manyetik iz veya eşdeğer çip verisi SAD kapsamındadır. Sıradan sipariş veya müşteri bilgisi tek başına CHD değildir; bu bilgilerin bulunduğu sistem yine de bağlantısı veya güvenlik etkisi nedeniyle kapsamda olabilir.
Scope (Kapsam) Nedir?
Kapsamı yalnızca kart numarasını gören sunucularla sınırlandırmayın. Veri akışı, ağ bağlantıları, yönetim yetkileri ve güvenlik bağımlılıklarını birlikte inceleyin:
- Kart verisini alan web/API/veritabanı bileşenleri ile bu veriyi içeren loglar ve yedekler kapsam değerlendirmesine girer. CDE ile sınırsız bağlantılı sistemleri de dahil edin.
- Kimlik doğrulama, DNS, yönlendirme, CI/CD, yönetim panelleri, yönetici iş istasyonları, segmentasyon ve güvenlik servisleri CDE’yi etkileyebiliyorsa kapsamda olabilir.
- Hosted payment page veya sağlayıcı iframe’i kullanıldığında mağaza sunucusunun kart verisini almaması kapsamı azaltabilir. Yönlendirme/gömme sayfasının ve ilgili erişimlerin hangi kontrolleri gerektirdiğini ayrıca değerlendirin.
Scope’u küçültmek; hem denetim maliyetini hem de teknik gereksinimleri azaltır. Kapsamı azaltmak için ilk adım, hosting mimarisindeki kart verisi akışlarını ve sistemler arasındaki bağlantıları belirlemektir. Bu konuyu daha detaylı olarak e‑ticarette PCI DSS uyumu hakkında detaylı rehberimizde adım adım ele aldık.
SAQ Tipleri ve E‑Ticaret
SAQ, uygun işletmelerin öz değerlendirme sonuçlarını bildirmesi için kullanılır. E-ticarette SAQ A ve A-EP seçimi; alan adına veya yalnızca “iframe/JavaScript” etiketine değil, tarayıcıya gelen ödeme formunun kaynağına, gerçek veri akışına ve formun bütün uygunluk koşullarına bağlıdır:
- SAQ A: İlgili kanalda yalnızca kartın fiziksel olarak bulunmadığı işlemler kabul edilir; tüm hesap verisi işlevleri PCI DSS uyumlu üçüncü tarafa devredilir. Satıcının sistemleri/tesisleri elektronik hesap verisi saklamaz, işlemez veya iletmez. Kullanılan hizmetler için sağlayıcının uyumu doğrulanır; tutulan hesap verisi varsa elektronik alınmamış kâğıt rapor/makbuzlarla sınırlıdır. E-ticarette ödeme sayfası/formunun bütün öğeleri yalnızca ve doğrudan uyumlu sağlayıcıdan gelmelidir. Sağlayıcıya yönlendirme veya sağlayıcının iframe’i bu koşullarla SAQ A’ya uygun olabilir.
- SAQ A-EP: Yalnızca e-ticaret kanalı içindir. Ödeme sayfası dışındaki hesap verisi işleme tamamen uyumlu sağlayıcıya devredilir; satıcının sitesi hesap verisini almaz fakat ödeme güvenliğini veya yönlendirmeyi etkiler. Form öğeleri satıcıdan ya da uyumlu sağlayıcıdan gelebilir; satıcı formunun veriyi tarayıcıdan doğrudan sağlayıcıya göndermesi örnektir. Satıcının sistemleri/tesisleri yine elektronik hesap verisi saklamaz, işlemez veya iletmez. Kullanılan hizmetlerin uyumu, varsa hosting sağlayıcısının ilgili PCI DSS ve çok kiracılı hosting yükümlülükleri ile elektronik alınmamış kâğıt kayıt koşulu da sağlanmalıdır.
- Satıcı uygulamasından geçen PAN: Kart numarasını sunucunuz aldıktan sonra token oluşturulması, bu akışı SAQ A-EP’ye uygun hale getirmez. Bütün uygunluk koşulları sağlanmıyorsa uygun SAQ’yu veya SAQ D/ROC gibi raporlama yolunu uyum bildiriminizi kabul eden kuruluşla belirleyin. SAQ A ve A-EP hizmet sağlayıcıların kendi değerlendirmesi için kullanılmaz.
WooCommerce ve benzeri platformlarda SAQ seçimini yalnızca platform adına göre değil, kullanılan ödeme entegrasyonuna göre değerlendirmek gerekir. Bu tip kurulumlar için hazırladığımız PCI DSS uyumlu WooCommerce hosting kontrol listesi yazısını da mutlaka gözden geçirmenizi öneririz. 2025 SAQ A değişikliği: 6.4.3, 11.6.1 ve 12.3.1 soruları SAQ A’dan çıkarıldı; bu değişiklik PCI DSS’in ilgili gereksinimlerini kaldırmadı. FAQ 1588’e göre script saldırılarına karşı uygunluk ölçütü, sağlayıcının gömülü ödeme formunu kullanan satıcı sayfaları içindir. Bunu uygun koruma teknikleriyle veya sağlayıcının doğru kurulan çözümünün satıcı ödeme sayfasını script saldırılarından koruduğuna ilişkin teyidiyle karşılayabilirsiniz. Bu özel ölçüt yönlendirme/ödeme bağlantısı modellerine uygulanmaz; diğer SAQ koşulları devam eder.
PCI DSS İçin Doğru Hosting Mimarisi
PCI DSS tarafında kullandığınız altyapı türü, karşınıza çıkacak gereksinimleri ve esnekliği doğrudan etkiler. Paylaşımlı hosting, VPS, dedicated sunucu ve colocation gibi modelleri değerlendirirken PCI kapsamını ve ihtiyaç duyulan güvenlik kontrollerini esas alın.
Paylaşımlı Hosting Ne Zaman Yeterli?
SAQ A’ya uygun bir ödeme akışında paylaşımlı hosting değerlendirilebilir. Bunun için yalnızca kart verisinin sunucudan geçmemesi yeterli değildir: bütün SAQ koşullarını, uygulanabilir kontrolleri, kiracı izolasyonunu ve hizmet sorumluluklarını doğrulayın. Şu işlevlerin planda kim tarafından sağlandığını kontrol edin:
- Sunucu seviyesinde özelleştirilmiş güvenlik duvarı kuralları
- Dosya bütünlüğü izleme (FIM) ajanları
- Özel log saklama politikaları ve merkezi loglama
Bu kontroller için sunucu düzeyinde yetki gerekebilir. Paylaşımlı hosting planında bu kontrolleri kimin uygulayabildiğini ve gerekli kayıtların nasıl sağlandığını belirleyin.
VPS ve Dedicated Sunucuların Avantajı
VPS veya dedicated sunucu, PCI DSS uyumunu hedefleyen bir e‑ticaret altyapısı için değerlendirilebilecek iki modeldir. Yönetim yetkileri ve hizmet kapsamı elverdiğinde:
- İşletim sistemi ayarlarını ve sunucu içindeki güvenlik duvarı kurallarını yönetebilirsiniz.
- Logları merkezi bir sisteme (örn. ELK, Loki, syslog) güvenli şekilde akıtabilirsiniz.
- Disk şifreleme, dosya izinleri, yedekleme ajanları gibi mekanizmaları kendinize göre şekillendirebilirsiniz.
Fiziksel ayrım, kapasite veya kurum politikası gerektiğinde dedicated sunucu ya da colocation değerlendirilebilir; bunlar PCI DSS’in her satıcı için zorunlu tuttuğu ürünler değildir. Sağlayıcıdan kullanılan hizmeti kapsayan güncel uyumluluk kanıtını (örneğin AOC), sorumluluk matrisini ve kontrol kayıtlarının nasıl sunulacağını isteyin. 12.8.5 kapsamındaki satıcı/sağlayıcı/ortak sorumlulukları yazılı belirleyin. VPS sunucu güvenliği için pratik yaklaşımlar bu teknik planın sunucu kısmına yardımcı olabilir.
Sunucu ve Ağ Güvenliği: PCI DSS Gereksinimlerini Somutlaştırmak
Aşağıdaki maddeler, kapsamınıza uygulanabildikleri ölçüde PCI DSS v4.0.1 gereksinimlerini ve bunları destekleyen uygulama önerilerini özetler. SAQ’nuzun kapsamı farklı olabilir; bir tavsiyeyi her kurulum için aynı zorunluluk gibi ele almayın.
Ağ Segmentasyonu ve Güvenlik Duvarı Kuralları
Ağ segmentasyonu, farklı güven düzeyindeki servisler arasında erişimi sınırlandırmak için kullanılabilir. Tüm servislerin aynı düz ağda bulunması, bir sistem ele geçirildiğinde diğer sistemlere erişimi kolaylaştırabilir. Segmentasyon tek başına zorunlu bir PCI DSS koşulu değildir; kapsamı azaltmak için kullanılıyorsa gerçekten izolasyon sağladığı doğrulanmalıdır. VLAN, container veya ayrı sunucu adı tek başına kanıt değildir. 11.4.5 uygulanıyorsa segmentasyon kontrollerine en az 12 ayda bir ve değişikliklerden sonra bağımsızlık koşulunu sağlayan yetkin kişilerce sızma testi yapılır.
- DMZ katmanı: İnternete açık web sunucularınız bu zoneda çalışır. Sadece HTTP(S) ve gerçekten gerekli az sayıda port dış dünyaya açılır.
- Uygulama ve veritabanı katmanı: Uygulama sunucuları yalnızca yetkili web sunucularından gerekli uygulama portlarına bağlantı kabul eder. Veritabanı sunucuları ise yalnızca belirli uygulama sunucularından gerekli veritabanı portlarına (örn. 3306, 5432) erişim verir. Bu katmanlar internete doğrudan açılmaz.
- Yönetim ve yedekleme ağı: SSH, RDP, yedekleme ajanları, izleme sistemleri gibi yönetsel trafiği mümkünse ayrı bir ağda veya en azından ayrı güvenlik politikaları ile yönetirsiniz.
Güvenlik duvarı kuralları minimum erişim prensibi ile yazılmalıdır. Örneğin, veritabanına sadece belirli uygulama sunucuları erişebilmeli, aynı VLAN’daki diğer makineler bile erişememelidir.
Sunucu Sertleştirme (Hardening)
Sunucu sertleştirme, işletim sistemini gereksiz servislerden ve zayıf ayarlardan arındırmak anlamına gelir. Bu amaçla uygulanabilecek sertleştirme ve bakım adımları şunlardır; liste, PCI DSS gereksinimlerinin birebir karşılığı değildir:
- Gereksiz servislerin kapatılması (örneğin kullanılmayan FTP ve Telnet servisleri).
- Şifreleme dışı protokollerin (örn. düz FTP) SFTP veya HTTPS ile değiştirilmesi.
- Düzenli güvenlik güncellemeleri ve kernel yamalarının planlı şekilde uygulanması.
- SSH için anahtar tabanlı kimlik doğrulamanın MFA ile birlikte planlanması, root ile doğrudan girişin kapatılması.
- Dosya izinlerinin minimum yetki prensibine göre düzenlenmesi, özellikle web kök dizini, konfigürasyon dosyaları ve loglar için.
Dosya izinleri tarafında nereden başlayacağınızı bilmiyorsanız, özellikle PHP tabanlı sitelerde Linux dosya izinleri için güvenli ayar rehberimiz iyi bir referans olacaktır.
Kullanıcı ve Erişim Yönetimi
Bireysel kullanıcı kimliği, iş ihtiyacına göre yetki ve izlenebilir erişim temel alınmalıdır. 8.4.1, CDE’ye konsol dışı yönetici erişiminde MFA ister; 8.4.2 CDE’ye tüm konsol dışı erişimi ele alır. İkinci maddenin otomatik uygulama/sistem hesapları, tek işlem için tek kart numarasına erişen POS kullanıcıları ve yalnızca phishing-resistant kimlik doğrulama kullanan hesaplara ilişkin özel uygulanabilirlik notlarını okuyun. 8.4.3, kurum ağı dışından başlayıp CDE’ye erişebilen veya onu etkileyebilen uzaktan erişim için MFA ister. SSH anahtarı tek başına otomatik olarak MFA sayılmaz.
- Paylaşılan hesapları (tek kullanıcı adı ile tüm ekibin giriş yapması) rutin erişim yöntemi olarak kullanmayın; her geliştirici, sistem yöneticisi ve destek personeli için ayrı hesap tanımlayın.
- Üretim ortamına erişimi gerçekten ihtiyacı olanlarla sınırlandırın; staging ve test ortamları üzerinden çalışmayı teşvik edin.
- SSH, panel, veritabanı ve yönetim araçları için çok faktörlü kimlik doğrulama (MFA/2FA) kullanın.
- İşten ayrılan personelin erişimlerini derhal kaldıran, görev değişikliğinde ise yetkileri yeni iş ihtiyacına göre güncelleyen dokümante bir prosedürünüz olsun.
Zafiyet Yönetimi ve Dosya Bütünlüğü İzleme
6.3.3 kapsamında kritik zafiyetlerin yamaları yayımlandıktan sonra bir ay içinde kurulmalıdır; diğer uygulanabilir yamaların süresi ortamın risk değerlendirmesine göre belirlenir. 11.3 kapsamındaki iç ve dış zafiyet taramaları için en az üç ayda bir tarama takvimi, giderme ve yeniden tarama süreçleri kurun; bu periyodik dış taramaları ASV gerçekleştirir. Önemli değişikliklerden sonraki taramaları da planlayın; 11.3.2.1 bu ek dış taramalar için ASV olma şartı yerine yetkinlik ve kurumsal bağımsızlık koşulunu belirtir. Bunlar yalnızca “yazılımı güncellemek” ile tamamlanmaz.
- Desteklenen işletim sistemi, web sunucusu, PHP, veritabanı ve panel sürümlerini envanterde tutun; yamayı önce uygun ortamda doğrulayıp kontrollü uygulayın.
- 11.5.2 kapsamında kritik dosyalarda yetkisiz değişiklikleri algılayan ve uyaran mekanizma kurun; kritik dosya karşılaştırmalarını en az haftalık çalıştırın.
- 6.4.2 uygulanıyorsa internete açık web uygulamasının önünde sürekli çalışan, güncel, log üreten ve saldırıyı engelleyecek veya derhal incelenen bir alarm üretecek şekilde yapılandırılmış otomatik koruma gerekir; WAF bu amaçla kullanılabilir. Sadece ürünün kurulu olması veya alarmın bir kuyruğa iletilmesi yeterli değildir.
- 6.4.3 kapsamında ödeme sayfası scriptlerinin yetkisini, bütünlüğünü ve gerekçeli envanterini yönetin. 11.6.1 kapsamında tarayıcıya ulaşan ödeme sayfasının script içeriği ve güvenliği etkileyen HTTP başlıklarındaki yetkisiz değişiklikleri izleyin; sıklık en az haftalık veya ilgili hedefli risk analiziyle belirlenen aralık olmalıdır. SAQ A r1’in ayrı uygunluk yaklaşımını yukarıdaki bölümle birlikte değerlendirin.
SSL/TLS ve Şifreleme: Sadece Sertifika Almak Yetmez
PCI DSS 4.2.1, PAN’ın açık ve kamusal ağlardan iletiminde güçlü kriptografi ve güvenli protokol yapılandırması ister. Güvenilir anahtar/sertifika, geçerlilik, iptal durumu ve güvensiz protokole geri dönüşün engellenmesi değerlendirilir. Bu maddeyi “her iç ağdaki her veri aynı kurala tabidir” diye genellemeyin; iç servis ve yedek bağlantılarında doğrulanan şifreli iletişim ayrıca güçlü bir güvenlik tercihidir.
TLS Sürümleri ve Şifre Setleri
PCI DSS’in güçlü kriptografi koşulunu, güncel TLS uygulama rehberi RFC 9325 ile birlikte karşılayın. Aşağıdakiler modern bir web TLS politikası için başlangıçtır; PCI DSS’in birebir sürüm listesi değildir:
- SSLv2/SSLv3 ile TLS 1.0/1.1’i kapatın; TLS 1.2 desteği ve uygun istemciler için TLS 1.3 kullanın.
- TLS 1.2 için ileri gizlilik sağlayan ECDHE ve AES-GCM/ChaCha20-Poly1305 gibi AEAD şifrelerini değerlendirin; RC4, NULL, EXPORT ve eski 3DES seçeneklerini kapatın. TLS 1.3 şifre ayarlarını kullanılan sunucunun ayrı yapılandırma kurallarına göre kontrol edin.
- Sertifika zinciri, alan adı eşleşmesi, geçerlilik ve iptal kontrolünü; TLS sonlandırıcıları, ödeme API istemcileri ve ilgili tüm bağlantı noktaları için test edin. Zayıf protokole geri dönüşe izin vermeyin.
Mevcut sitenizde hangi protokollerin açık olduğunu ve hangilerinin kapatılması gerektiğini görmek için ayrıntılı bir yol haritasını SSL/TLS güvenlik güncellemeleri rehberimizde bulabilirsiniz. İptal kontrolünü sertifika otoritesinin güncel desteğine göre planlayın: Let’s Encrypt, OCSP hizmetini 6 Ağustos 2025’te sonlandırdı ve iptal bilgisini artık yalnızca CRL üzerinden yayımlıyor. OCSP stapling her sertifika için uygulanabilir bir adım değildir.
Sertifika Türü: DV, OV, EV ve Wildcard Seçimi
DV, OV ve EV sertifikalarının doğrulama kapsamı farklıdır; aynı protokol/anahtar ayarlarında OV/EV etiketi şifrelemeyi kendiliğinden güçlendirmez. PCI DSS belirli bir ticari sertifika türü veya ücret şartı koymaz. Seçimi alan adları, kimlik doğrulama ihtiyacı, anahtar yönetimi ve doğrulanmış sözleşme koşullarıyla yapın.
- DV: Alan adı kontrolü doğrulanır. Uygun sertifika ve TLS yapılandırmasıyla ödeme bağlantılarında kullanılabilir; sertifikanın varlığı tek başına PCI uyumu değildir.
- OV/EV: Kurumsal kimlik doğrulaması ekler. Gerekliliğini kendi sözleşme/politikanızdan doğrulayın; checkout için evrensel zorunluluk veya daha güçlü şifreleme varsaymayın.
- Wildcard: Alan adı kapsamıyla ilgilidir; DV/OV gibi doğrulama sınıfıyla aynı eksende değildir. Paylaşılan özel anahtarın ele geçirilmesi birden çok kapsanan alt alanı etkileyebilir; anahtar dağıtımını ve erişimini sınırlayın.
Farklı sertifika türlerini hem güvenlik hem operasyonel açıdan kıyaslamak için DV, OV, EV ve wildcard SSL karşılaştırma rehberimize de göz atabilirsiniz.
HTTP Güvenlik Başlıkları ile TLS’i Desteklemek
TLS katmanını doğru kurduktan sonra, tarayıcıya bu güvenlik politikasını nasıl uygulayacağını söylemek için HTTP güvenlik başlıklarını kullanmalısınız:
- HSTS: Tarayıcıya sonraki bağlantıları HTTPS ile yapmasını bildirir. Kapsanan alanlarda HTTPS’i doğrulamadan includeSubDomains veya preload politikasını genişletmeyin.
- CSP: İzin verilen içerik kaynaklarını ve script çalışmasını sınırlar; uygun politika ve uygulamayla XSS riskini azaltmaya yardımcı olur. Tek başına script envanteri, bütünlük yönetimi ve değişiklik algılama süreçlerinin tamamı değildir.
- X-Frame-Options / CSP frame-ancestors: Sayfanın başka sitelerde çerçevelenmesini sınırlandırarak clickjacking riskine karşı yardımcı olur. X-Content-Type-Options: nosniff MIME türü yorumlamasını sınırlar; Referrer-Policy gönderilen referrer bilgisini düzenler. Bunları genel bir phishing engeli gibi sunmayın.
Bu başlıkların nasıl ayarlanacağı ve hangi senaryoda ne kadar agresif olmanız gerektiği konusunda, HTTP güvenlik başlıkları rehberimiz size ayrıntılı bir uygulama kılavuzu sunar.
Loglama ve İzleme: PCI DSS Madde 10’u Gerçek Hayata Uygulamak
Madde 10, kapsamındaki sistemler ve kart sahibi verisi için denetim izlerini ele alır. Web erişim logları tek başına yeterli değildir: bireysel kart verisi erişimi, yönetici işlemleri, başarısız mantıksal erişimler, hesap/kimlik değişiklikleri, loglara erişim, yeni logların ilk oluşturulması, mevcut logların başlatılması/durdurulması/duraklatılması ve sistem nesnesi oluşturma/silme olaylarının gereken kapsamını 10.2.1 ile eşleştirin. 10.2.2 uyarınca kullanıcı, olay türü, tarih/saat, başarı/başarısızlık, kaynak ve etkilenen bileşen gibi alanları kaydedin; saatleri senkronize edin.
Hangi Loglar Tutulmalı?
Aşağıdaki kaynaklar bu denetim izlerini üretmek için değerlendirilebilir; alışveriş/performans telemetrisi ile zorunlu güvenlik kayıtlarını ayrı amaçlarla yönetin:
- Web sunucusu logları: Nginx/Apache erişim ve hata logları, özellikle 4xx ve 5xx hataları ile login, sepet, ödeme adımlarının takibi.
- Uygulama logları: Ödeme akışı, kullanıcı oturumları, kritik konfigürasyon değişiklikleri.
- Veritabanı logları: Yetkisiz sorgular, şema değişiklikleri, başarısız login denemeleri.
- Sunucu ve sistem logları: SSH girişleri, sudo kullanımı, servis yeniden başlatmaları, paket kurulumları.
- Güvenlik cihazı logları: WAF, IDS/IPS, güvenlik duvarı, DDoS koruma sistemleri.
Bu logları anlamlandırmak için öncelikle temel okuma pratiği kazanmak faydalıdır. Başlangıç için hosting sunucu loglarını okumayı öğrenin rehberi iyi bir referans noktasıdır.
Log Saklama Süresi ve Bütünlüğü
10.5.1 uygulandığında denetim logu geçmişi en az 12 ay saklanmalı, en az son üç ayı analiz için hemen kullanılabilir olmalıdır. Bu bir tavsiye değildir; “ilk üç ay” anlamına da gelmez. Depolama sınıfından önce gerçek erişim süresini, bütünlüğü ve kayıt kapsamını doğrulayın:
- Okuma yetkisini iş ihtiyacıyla sınırlayın; kişilerin mevcut logları değiştirmesini önleyen kontroller kurun (10.3.1/10.3.2).
- Logları gecikmeden güvenli merkezi iç log sunucusuna veya değiştirilmesi güç başka medyaya yedekleyin (10.3.3); mevcut kayıt değişirse uyarı üreten mekanizma kullanın (10.3.4). WORM bir tasarım seçeneğidir; tek zorunlu ürün değildir.
- Rotation, arşiv, sorgulama, erişim ve saklama sonrası silmeyi test edip belgeleyin. PCI süresini karşılamak gereksiz kişisel verileri sınırsız saklama gerekçesi değildir.
Her log sınıfının amacını ve uygulanabilir güvenlik, yasal ve sözleşmesel yükümlülüklerini yazın. Hosting ve e‑posta altyapısında log saklama süreleri rehberimiz bu sınıflandırma için yardımcıdır; yazıdaki genel süre örneklerini PCI 10.5.1’in yerine kullanmayın.
Merkezi Loglama ve Alarm Mekanizmaları
syslog, ELK veya Loki gibi çözümler toplama ve incelemeyi kolaylaştırabilir. 10.3.3 güvenli merkezi iç sunucu veya değiştirilmesi güç başka medya seçeneklerini içerir; belirli bir ürün şartı koymaz. Gönderici/alıcı kimliğini, aktarım güvenliğini, teslimat kaybını ve saklama erişimini birlikte doğrulayın:
- Tüm logları tek noktada toplayabilir,
- Yetkisiz erişimler, başarısız oturum açma denemeleri, web saldırı kalıpları gibi olaylar için alarm kuralları yazabilir,
- Denetim anında ilgili zaman aralığındaki kayıtları hızlıca çıkarabilirsiniz.
10.4.1 kapsamındaki güvenlik olayları, CHD/SAD sistemleri, kritik bileşenler ve güvenlik işlevi sunan sistemlerin logları en az günlük incelenir; 10.4.1.1 otomatik inceleme mekanizmaları ister. Diğer kapsam içi sistemlerin periyodu ilgili risk analiziyle belirlenir. Alarmı kimin ne zaman ele alacağını ve kayıt gelmemesinin nasıl fark edileceğini test edin. SAD’yi yetkilendirme tamamlandıktan sonra şifreli bile olsa saklamayın; CVV/CVC, PIN/PIN bloğu ve tam iz/eşdeğer çip verisini uygulama, debug ve yedek akışlarına sokmayın. Gerekli PAN saklanıyorsa 3.5.1 uyarınca okunamaz kılınmalıdır; loglarda mümkün olduğunca hiç toplamayın.
Yedekleme, Şifreleme ve Felaket Kurtarma
Yedeklerin kapsamı içerdikleri hesap verisine ve CDE güvenliğini etkileyen sistemlerle ilişkilerine bağlıdır; her medya dosyası otomatik olarak kart verisi değildir. PAN içeren yedekler, güvenlik yapılandırmaları, sırlar ve kurtarma sistemleri kapsam analizinde ele alınmalıdır. Canlı ortamdan çıkarılan bir kopya, koruma gereksinimlerini ortadan kaldırmaz.
3‑2‑1 Yedekleme Stratejisinin PCI DSS ile Kesişimi
3-2-1, iş sürekliliği için değerlendirilebilecek bir yedekleme yaklaşımıdır; PCI DSS’in her işletme için birebir koyduğu kopya sayısı şartı değildir:
- En az 3 kopya (canlı veri dahil),
- En az 2 farklı ortamda (örneğin lokal disk + uzak depolama),
- En az 1 tanesi farklı lokasyonda (offsite).
3‑2‑1 yedekleme stratejisi rehberimiz kopya yerleşimini planlamaya yardımcı olur. Aynı disk üzerindeki snapshot bağımsız arıza alanı sağlamaz; offsite kopyanın erişim hesaplarını ve silinmeye karşı korumasını da ayrıca tasarlayın.
Yedeklerin Şifrelenmesi ve Erişim Kontrolü
Veri minimizasyonunu yedek politikasına da uygulayın. Kart numarası saklamamak kapsamı azaltabilir; şifreleme tek başına kapsamı ortadan kaldırmaz:
- 3.3.1 uyarınca satıcıların SAD’yi yetkilendirme sonrasında saklaması yasaktır; şifreli yedek bu yasağı değiştirmez.
- 3.5.1, saklanan PAN’ın her yerde okunamaz kılınmasını ister. Uygun kısaltma, indeks token veya anahtar yönetimiyle güçlü kriptografi seçenekleri bulunur. Hash kullanılıyorsa 3.5.1.1 uyarınca PAN’ın tamamının anahtarlı kriptografik hash’i ve ilgili anahtar yönetimi gerekir; yöntemlerin ek koşullarını izleyin. Şifreleme kullanıldığında 3.6/3.7 anahtar koruma ve yaşam döngüsünü ayrıca uygulayın.
- Uygulamada yedek arşivlerini şifrelemek, anahtar erişimini depolama erişiminden ayırmak ve kurtarma yetkisini sınırlamak faydalıdır. PAN’ın açık/kamusal ağdaki iletimi 4.2.1’e tabidir. HTTPS/S3 bağlantısında TLS, SSH/SFTP’de SSH’nin kendi şifreli taşımasını doğru kimlik doğrulamayla kullanın.
- Yedek alma, erişim ve geri yükleme izlerini kapsamınızdaki log politikasıyla eşleştirin; sırları ve özel anahtarları kontrolsüz arşivlere eklemeyin.
Yedekleri veritabanı ve uygulama açısından tutarlı üretin. uygulama tutarlı yedekler için hazırladığımız rehber uygulama tutarlılığı ve snapshot kavramlarını ele alır. Kullanacağınız komutları veritabanı sürümünün resmî yedekleme prosedürüyle doğrulayın; izolasyon, oturum/kilit ömrü, çözme adımı ve geri yükleme testini birlikte değerlendirin. Bir dosya sistemi snapshot’ı tek başına uygulama tutarlılığı kanıtı değildir.
RPO, RTO ve Felaket Kurtarma Senaryoları
12.10.1 olay müdahale planında iş kurtarma/süreklilik prosedürlerini ve veri yedekleme süreçlerini ister; 12.10.2 planın bütün unsurlarıyla en az 12 ayda bir gözden geçirilmesini ve testini kapsar. PCI DSS her işletme için sabit bir yedek sıklığı, RPO veya RTO değeri vermez. Bu hedefleri iş ihtiyacına göre belirleyin:
- RPO (Recovery Point Objective): En fazla ne kadar veri kaybına tahammül edebilirsiniz? Örneğin 15 dakikalık sipariş verisi kaybı kabul edilebilir mi?
- RTO (Recovery Time Objective): Bir felaket anında sistemi ne kadar sürede ayağa kaldırmanız gerekiyor?
E‑ticaret siteleri için RPO ve RTO hedeflerini belirleme ve buna göre yedekleme ile felaket kurtarma stratejisi kurma konusunu, örnek senaryolarla RPO/RTO odaklı yedekleme stratejisi rehberimizde detaylıca anlattık.
PCI DSS Hosting İçin Uygulama ve Kanıt Planı
Aşağıdaki adımları mağaza, ödeme sağlayıcısı ve hosting ekibi arasında sorumlu ve kabul kanıtı atayarak yürütün:
- Ödeme akışı ve kapsam: Tarayıcı, form öğeleri, API, log, yedek ve yönetim erişimlerini haritalayın. Tüm SAQ uygunluk koşullarını doğrulayın; raporlama yöntemini bankanızla netleştirin.
- Altyapı ve sorumluluk: Gereken yetkileri, sağlayıcının hizmet kapsamını ve AOC/sorumluluk matrisini inceleyin. Segmentasyon kullanılıyorsa etkinliğini test edin.
- Sertleştirme ve erişim: Destekli sürüm, yama takvimi, asgari erişim, uygulanabilir MFA ve güvenlik izlerini kurun. Kontrolleri yapılandırma ve erişim denemeleriyle doğrulayın.
- TLS ve ödeme sayfası: Sertifika/hostname/iptal kontrolü, güvenli protokol, HTTP başlıkları ve ilgili script kontrollerini test edin. Sertifika yenilenmesinin gerçekten devreye alındığını izleyin.
- Log ve inceleme: Test olaylarıyla gereken alanların geldiğini, SAD toplanmadığını, log değişikliğinin fark edildiğini, saklama/erişimin ve alarm müdahalesinin çalıştığını kanıtlayın.
- Yedek ve kurtarma: Veri kapsamı, kopya bağımsızlığı, anahtar yönetimi ve RPO/RTO hedefini yazın. İzole ve eşdeğer korumalı ortamda uygulama tutarlılığını, veri bütünlüğünü ve geri dönüş süresini ölçün.
Her kontrol için sorumlu kişi/kuruluş, yapılandırma kaydı, doğrulama sonucu ve tekrar tarihi belirleyin. Ürün satın almak, WAF açmak veya yedek almak tek başına bu kanıtı sağlamaz. Kontrollerin devamlı işletilmesi ve değişikliklerden sonra yeniden değerlendirilmesi gerekir.
Özet ve Yol Haritanızı Netleştirmek
PCI DSS hosting planı; ödeme akışının kapsamı, sunucu ve ağ kontrolleri, güvenli TLS, denetlenebilir loglar ve korunmuş kurtarma süreçlerini birlikte ele alır. Her bölümde önce gereksinimi ve sorumluyu belirleyin, sonra teknik çözümü ve doğrulama kanıtını seçin.
Eğer şu anda çalışan bir e‑ticaret siteniz varsa, ilk adım olarak mevcut hosting ortamınızı bu yazıda anlattığımız dört başlık üzerinden basit bir checklist ile değerlendirebilirsiniz: sunucu ve ağ güvenliği, SSL/TLS ve HTTP başlıkları, loglama ve log saklama, yedekleme ve felaket kurtarma. Eksikleri gördükçe, önceliklendirilmiş küçük adımlarla ilerlemek en sağlıklı yaklaşım olur.
Yeni projelerde bu kararları mimari tasarım sırasında verin. DCHost dahil değerlendirdiğiniz sağlayıcıya gereken erişimleri, kontrol sorumluluklarını ve hizmete özgü uyumluluk kanıtlarını sorun. Bir planın ihtiyacınızı karşıladığını yazılı doğrulamadan uyumlu olduğu varsayımıyla ödeme akışını devreye almayın.
