PCI DSS Uyumlu E‑Ticaret Hosting Rehberi

PCI DSS ve E‑Ticaret Hosting İlişkisini Doğru Kurmak

Ödeme sayfanızda kart bilgisi girildiği anda, sadece yazılımınız değil, altında çalışan sunucu, ağ, SSL ayarları, loglama ve yedekleme mimariniz de denklemin parçası olur. PCI DSS tam olarak bu noktada devreye girer. Standart, kart verisinin işlendiği, iletildiği veya saklandığı her bileşeni kapsar ve e‑ticaret sitenizin hosting katmanı bu bileşenlerin kalbidir.

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? DCHost tarafında onlarca e‑ticaret müşterisiyle çalışırken en sık gördüğümüz hataları ve işe yarayan çözümleri sahadaki deneyimle birleştirerek anlatacağız.

PCI DSS uyumu çoğu zaman sadece bir denetim dosyası gibi algılanıyor; oysa doğru kurulduğunda saldırı yüzeyini küçültür, veri ihlali riskini azaltır ve güvenilir bir marka algısı oluşturur. Hedefimiz, e‑ticaret hosting ortamınızı hem performanslı hem de denetime hazır hale getirmek. Yazıda özellikle dört başlığa odaklanacağız: sunucu ve ağ güvenliği, SSL/TLS yapılandırması, loglama stratejisi ve yedekleme ile felaket kurtarma mimarisi.

PCI DSS Temelleri: Scope, SAQ ve Hostingin Rolü

PCI DSS, kartlı ödeme alan tüm işletmeler için geçerli bir güvenlik standardıdır. Ancak herkesin yükümlülüğü aynı değildir. Hangi sorumlulukların sizde, hangilerinin ödeme sağlayıcısında veya hosting tarafında olduğunu anlamak için iki temel kavramı netleştirmek gerekir: scope ve SAQ.

Scope (Kapsam) Nedir?

Scope, kart verisi ile doğrudan veya dolaylı temas eden tüm sistemleri ifade eder. Örneğin:

• Ödeme formunuz doğrudan sitenizde ve kart verisi sizin sunucunuzdan geçiyorsa, web sunucusu, veritabanı, loglama sistemi, yedekler ve hatta ilgili yönetim panelleri PCI scope içindedir.
• Hosted payment page kullanıyor, yani kullanıcıyı ödeme sayfası için ödeme sağlayıcısına yönlendiriyorsanız; scope daralır ama sunucunuzun ve loglarınızın tamamen kapsam dışı olduğu anlamına gelmez.

Scope’u küçültmek; hem denetim maliyetini hem de teknik gereksinimleri azaltır. DCHost olarak e‑ticaret müşterileriyle çalışırken ilk adımda hosting mimarisi üzerinden scope’u olabildiğince sadeleştirmeye odaklanıyoruz. 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

PCI DSS öz değerlendirme formları (SAQ) türleri, teknik mimarinize göre seçilir. E‑ticaret tarafında en sık görülenler:

• SAQ A: Kart verisi tamamen üçüncü taraf ödeme sayfasında işlenir. Sitenizde gömülü iframe dahi yoktur ya da hassas kısım tam anlamıyla sağlayıcıya aittir. Hosting tarafındaki yükümlülükler daha sınırlıdır ama güvenlik sorumluluğu bitmez.
• SAQ A‑EP: Ödeme sayfası üçüncü tarafta olsa bile, sizin siteniz ödeme akışını etkileyebilen bir rol oynuyorsa (örneğin gömülü form, JavaScript vb.). Sunucu, SSL, loglama ve yedekleme tarafında daha sıkı PCI DSS gereksinimleri devreye girer.

WooCommerce ve benzeri platformlarda neredeyse her zaman SAQ A‑EP senaryoları ile karşılaşıyoruz. 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.

PCI DSS İçin Doğru Hosting Mimarisi: Paylaşımlı, VPS, Dedicated, Colocation

PCI DSS tarafında kullandığınız altyapı türü, karşınıza çıkacak gereksinimleri ve esnekliği doğrudan etkiler. DCHost portföyünde yer alan paylaşımlı hosting, VPS, dedicated sunucu ve colocation çözümlerinin her biri e‑ticaret için kullanılabilir; ancak PCI kapsamı düşünüldüğünde tercihler değişir.

Paylaşımlı Hosting Ne Zaman Yeterli?

Scope’u maksimum düzeyde küçültebildiğiniz, kart verisinin hiçbir aşamada sunucunuzdan geçmediği SAQ A senaryolarında, sıkı izole edilmiş ve güvenlik kontrolleri iyi yapılandırılmış paylaşımlı hosting kullanılabilir. Ancak:

• Sunucu seviyesinde özelleştirilmiş güvenlik duvarı kuralları
• Dosya bütünlüğü izleme (FIM) ajanları
• Özel log saklama politikaları ve merkezi loglama

gibi PCI DSS’in daha ileri gereksinimlerini uygulamak istediğinizde paylaşımlı hosting kaçınılmaz olarak sınırlı kalır.

VPS ve Dedicated Sunucuların Avantajı

VPS veya dedicated sunucu, PCI DSS uyumlu bir e‑ticaret altyapısı kurarken en sık tercih ettiğimiz iki modeldir. Çünkü:

• İşletim sistemi ve güvenlik duvarı kurallarını tamamen kontrol edebilirsiniz.
• 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.

Daha yüksek trafik ve kritik iş yüklerinde, PCI scope içindeki sistemlerin fiziksel olarak da izole olması isteniyorsa dedicated sunucu veya colocation tercih edilir. Burada önemli olan, seçtiğiniz model ne olursa olsun güvenlik ve uyumluluk sorumluluğunun önemli kısmının sizde olduğunun farkında olmanızdır. Bu sorumluluğu pratik ve uygulanabilir şekilde ele almak için VPS sunucu güvenliği için pratik yaklaşımlar başlıklı rehberimizden de yararlanabilirsiniz.

Sunucu ve Ağ Güvenliği: PCI DSS Gereksinimlerini Somutlaştırmak

PCI DSS dökümanındaki 1, 2, 6, 7 ve 8 numaralı maddeler ağırlıklı olarak ağ ve sunucu güvenliğini ilgilendirir. Bunları e‑ticaret hosting bağlamında daha elle tutulur hale getirelim.

Ağ Segmentasyonu ve Güvenlik Duvarı Kuralları

İyi bir PCI DSS mimarisinin temelinde ağ segmentasyonu vardır. Tüm servisleri tek bir düz ağda koşturmak, hem performans hem de güvenlik açısından zayıf bir yaklaşımdı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ı: Bu sunucular yalnızca DMZ içinden gelen belirli portlara (örn. 3306, 5432) izin verir. Dışarıya doğrudan açık olmaz.
• 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. PCI DSS’in konfigürasyon yönetimi maddeleri pratikte şunları gerektirir:

• Gereksiz servislerin kapatılması (örneğin kullanılmayan FTP, Telnet, eski HTTP protokolleri).
• Ş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 erişiminin sadece anahtar tabanlı kimlik doğrulama ile sınırlandırılması, 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

PCI DSS, her kullanıcı için benzersiz kimlik, yetkilerin iş ihtiyacına göre sınırlandırılması ve erişimlerin kaydedilmesini şart koşar:

• Paylaşılan hesaplar (tek kullanıcı adı ile tüm ekibin giriş yapması) kabul edilemez; 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 veya görev değişikliği yapan personelin erişimlerini belirli bir süreç içinde kaldıran, dokümante bir prosedürünüz olsun.

Zafiyet Yönetimi ve Dosya Bütünlüğü İzleme

PCI DSS, düzenli zafiyet taramaları ve kritik yamaların belirli süreler içinde uygulanmasını ister. Pratikte:

• İşletim sistemi ve yazılım bileşenleri için düzenli otomatik güncelleme veya onaylı yama süreçleri kurun.
• Web sunucusu, PHP, veritabanı, panel yazılımları gibi bileşenler için minimum desteklenen sürümleri politikaya bağlayın.
• Dosya bütünlüğü izleme (FIM) çözümü ile web kök dizininde ve kritik konfigürasyonlarda beklenmedik değişiklikleri tespit edin.

SSL/TLS ve Şifreleme: Sadece Sertifika Almak Yetmez

PCI DSS, kart verisinin iletimi sırasında güçlü şifreleme kullanılmasını zorunlu kılar. Bu da doğrudan SSL/TLS yapılandırmasına dokunur. Sadece herhangi bir sertifikayı kurmak yeterli değildir; kullanılan protokol ve şifre setleri de önemlidir.

TLS Sürümleri ve Şifre Setleri

PCI DSS’e göre:

• TLS 1.0 ve SSLv3 kesinlikle devre dışı bırakılmalıdır.
• Yeni kurulumlarda en az TLS 1.2, tercihen TLS 1.3 etkin olmalıdır.
• Zayıf şifre setleri (RC4, 3DES, anonim key exchange içerenler) kapatılmalı; modern, ileri gizlilik sağlayan (PFS) şifreler tercih edilmelidir.

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.

Sertifika Türü: DV, OV, EV ve Wildcard Seçimi

PCI DSS doğrudan sertifika türü dayatmaz; ancak güven algısı, tarayıcı uyumluluğu ve operasyonel süreçler açısından doğru seçimi yapmak önemlidir.

• DV SSL: Teknik olarak kart verisini TLS ile korumak için yeterlidir. Küçük ve orta ölçekli e‑ticaret sitelerinde sıkça kullanılır.
• OV/EV SSL: Organizasyon doğrulaması sağlar, marka güvenini artırabilir. Bazı bankalar veya entegratörler bu seviyeyi tercih edebilir.
• Wildcard SSL: Aynı alan adının birden çok alt alanı için tek sertifika. Yönetimi kolaylaştırır ama özel anahtarın korunması daha kritik hale gelir.

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:

• Strict-Transport-Security (HSTS): Tarayıcıya sitenize her zaman HTTPS üzerinden bağlanmasını söyler.
• Content-Security-Policy (CSP): XSS ve veri sızdırma risklerini ciddi oranda azaltır.
• X-Frame-Options, X-Content-Type-Options, Referrer-Policy gibi ek başlıklar, phishing ve tıklama kaçırma saldırılarına karşı koruma sağlar.

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

PCI DSS, kullanıcı aktivitelerinin, güvenlik olaylarının ve sistem erişimlerinin kaydedilmesini ve bu logların manipülasyona karşı korunmasını zorunlu kılar. E‑ticaret hosting tarafında bu, yalnızca web sunucusu erişim loglarını aktifleştirmekten çok daha fazlasını gerektirir.

Hangi Loglar Tutulmalı?

Minimum seviyede şu logları toplamanızı öneririz:

• 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üğü

PCI DSS, logların en az bir yıl erişilebilir ve ilk üç ayının hızlı erişilebilir olmasını ister. Bu, sadece disk alanı ayırmak anlamına gelmez; aynı zamanda:

• Logların bütünlüğünü korumak için salt okunur depolama veya WORM benzeri çözümler kullanmayı,
• Loglara erişimin kimler tarafından ve ne zaman yapıldığının da kaydedilmesini,
• Log döndürme (rotation) ve arşiv süreçlerinin dokümante edilmesini

gerektirir. Farklı sistemler için hangi logların ne kadar süre saklanmasının mantıklı olduğu konusunda daha detaylı yaklaşımı hosting ve e‑posta altyapısında log saklama süreleri rehberimizde anlattık.

Merkezi Loglama ve Alarm Mekanizmaları

Birden çok sunucu veya servis kullanıyorsanız, PCI DSS açısından logları tek tek sunucularda tutmak yeterli değildir. Merkezi loglama çözümleri (syslog, ELK, Loki vb.) kullanarak:

• 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.

DCHost altyapısında, PCI DSS hedefi olan projelerde genellikle merkezi loglama ve olay yönetimini en baştan mimarinin bir parçası olarak ele alıyoruz. Böylece hem operasyonel görünürlük artıyor hem de denetim sürecinde loglarla ilgili sorulara hızlı yanıt verebiliyorsunuz.

Yedekleme, Şifreleme ve Felaket Kurtarma: PCI DSS’in Görmezden Gelinmemesi Gereken Yüzü

PCI DSS, kart verisini korumanızı ister; bu, yedeklerdeki veriyi de kapsar. Çoğu e‑ticaret projesinde canlı veritabanı için şifreleme planlanırken, yedeklerin düz metin olarak bir yerlerde saklandığını görmek ne yazık ki çok yaygın.

3‑2‑1 Yedekleme Stratejisinin PCI DSS ile Kesişimi

Sağlam bir PCI DSS uyumlu e‑ticaret ortamında, yedekleme stratejinizin en azından 3‑2‑1 prensibini karşılamasını öneriyoruz:

• 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).

Bu yaklaşımı hem teknik hem operasyonel açıdan nasıl kuracağınızı adım adım anlattığımız 3‑2‑1 yedekleme stratejisi rehberimiz, PCI DSS uyumlu projelerde de doğrudan uygulanabilir.

Yedeklerin Şifrelenmesi ve Erişim Kontrolü

Yedekler, genellikle en çok ihmal edilen ama en kritik varlıklardır. PCI DSS açısından bakıldığında:

• Yedeklerde kart verisi bulunuyorsa, bu veriler güçlü algoritmalarla (AES‑256 gibi) şifrelenmelidir.
• Şifreleme anahtarları, yedeklerden ayrı tutulmalı; erişim hakları sıkı şekilde sınırlanmalıdır.
• Yedeklere erişen kullanıcılar ve işlemler loglanmalı; düzenli olarak gözden geçirilmelidir.

Ayrıca, veritabanı veya dosya sisteminin yedek alma anında tutarlı olması önemlidir. Özellikle büyük veritabanlarında uygulama‑tutarlı yedeklerin nasıl alınacağını merak ediyorsanız, uygulama tutarlı yedekler için hazırladığımız rehber size teknik bir yol haritası sunar.

RPO, RTO ve Felaket Kurtarma Senaryoları

PCI DSS, felaket kurtarma planlarını doğrudan detaylandırmaz; ancak iş sürekliliği ve veri bütünlüğü gereksinimleri nedeniyle bu planların var olmasını ve test edilmesini bekler. Burada iki kavram kritik:

• 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.

DCHost ile PCI DSS Uyumlu E‑Ticaret Ortamını Adım Adım Tasarlamak

Teoriyi pratikle birleştirelim. DCHost tarafında tipik bir PCI DSS hedefli e‑ticaret projesinde aşağı yukarı şu adımlarla ilerliyoruz:

1. Scope ve SAQ tipini netleştirme
   Ödeme sağlayıcınız, entegrasyon şekliniz (redirect, iframe, API), kart verisinin nereden geçtiği ve hangi sistemlerin bu akışı etkilediğini birlikte analiz ediyoruz. Böylece SAQ A mı, SAQ A‑EP mi gibi temel sorulara net bir yanıt çıkıyor.
2. Altyapı seçimi ve segmentasyon
   Trafik, büyüme tahmini ve güvenlik gereksinimlerine göre paylaşımlı hosting, VPS, dedicated veya colocation arasından seçim yapıyoruz. PCI scope içindeki sistemleri mümkün olduğunca ayrı ağ segmentlerinde konumlandırıyoruz.
3. Sunucu sertleştirme ve erişim politikaları
   İşletim sistemi bazlı hardening, güvenlik duvarı kuralları, SSH ve panel erişimi, yetki yönetimi ve MFA kurulumunu yapıyoruz. Bu aşamada loglama ve izleme ajanları da devreye giriyor.
4. SSL/TLS ve HTTP güvenlik başlıkları
   Doğru sertifika türü, TLS sürümleri, şifre setleri ve HTTP güvenlik başlıkları ile hem tarayıcı tarafını hem de denetim tarafını tatmin eden bir HTTPS politikası oluşturuyoruz.
5. Loglama, saklama ve alarm kuralları
   Web, uygulama, veritabanı, sistem ve güvenlik loglarını PCI DSS gereksinimlerine uygun şekilde topluyor, saklama sürelerini ve erişim politikalarını belirliyoruz. Kritik olaylar için alarm senaryoları yazıyoruz.
6. Yedekleme ve felaket kurtarma planı
   RPO/RTO hedeflerine göre yedekleme periyotları, şifreleme politikaları, offsite kopyalar ve düzenli geri yükleme testleri içeren bir plan hazırlıyoruz. Planı belgeleyip sorumlu kişileri netleştiriyoruz.

Bu adımların her biri, PCI DSS dokümanındaki onlarca madde ve alt maddeyi daha yönetilebilir parçalara bölmemizi sağlıyor. Sonuçta ortaya çıkan şey, sadece bir denetimi geçmek için kurulmuş bir ortam değil; gerçekten güvenli, izlenebilir ve felaketlere karşı hazırlıklı bir e‑ticaret altyapısı oluyor.

Özet ve Yol Haritanızı Netleştirmek

PCI DSS uyumlu e‑ticaret hosting, salt bir sertifika veya tek bir güvenlik ürünü ile çözülecek bir konu değil. Sunucu mimariniz, ağ segmentasyonunuz, SSL/TLS yapılandırmanız, log ve yedek stratejiniz; hepsi bir arada düşünülmesi gereken bileşenler. Üstelik bu bileşenlerin her biri hem günlük operasyonu hem de olası bir denetimi doğrudan etkiliyor.

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 bir proje planlıyorsanız, mimari tasarım aşamasında PCI DSS gereksinimlerini hesaba katmak, ileride geri dönüş maliyetlerini ciddi biçimde azaltır. DCHost ekibi olarak, ister mevcut altyapınızı güçlendirmek, ister sıfırdan PCI DSS hedefli bir e‑ticaret ortamı kurmak isteyin, hem teknik hem stratejik tarafta yanınızda olabiliriz. Sorularınızı ve senaryolarınızı netleştirmek için dchost.com üzerinden bize ulaşmanız yeterli.