PCI DSS ve Hosting Güvenliği
PCI DSS yalnızca ödeme formuyla ilgili değildir; kart verisinin güvenliğini etkileyen hosting altyapısı ve işletim süreçleri de değerlendirilmelidir.
İlk iş, kart bilgisinin ödeme sırasında hangi sistemlerden geçtiğini belirlemektir. Bu yazı, PCI DSS v4.0.1’in Haziran 2024 sürümünü temel alarak e-ticaret hostinginde kapsam, erişim, web uygulaması koruması, kayıtlar ve bakım düzenini ele alır. Hangi gerekliliklerin uygulanacağı ödeme entegrasyonuna ve değerlendirme kapsamına bağlıdır; uygun SAQ’yu, yani öz değerlendirme anketini, anketi kabul eden kuruluşla birlikte belirleyin. Bu kuruluş genellikle üye işyeri bankası veya ödeme kartı markasıdır.
PCI DSS Kapsamı ve Hosting Sorumlulukları
PCI DSS, ödeme kartı verilerini korumaya yönelik teknik ve operasyonel bir güvenlik standardıdır. Kapsam yalnızca kart bilgisini saklayan, işleyen veya ileten uygulama değildir: bu sistemlere sınırsız erişimi olan veya kart verisinin güvenliğini etkileyebilen bileşenler de değerlendirilir. Örneğin ödeme sayfasını değiştirebilen yönetim hesabı, dağıtım sistemi veya yönlendirme sunucusu, kart numarası saklamasa da önemlidir. Ağ güvenliği, veri koruması, güncellemeler, erişim, loglama ve işletim süreçleri birlikte ele alınır.
Kart verisini kendi sunucunuzdan uzak tutan bir entegrasyon kapsamı azaltabilir; küçük işletme olmak veya bir hosting paketi satın almak tek başına muafiyet sağlamaz. İşletim sistemi yamaları, uygulama güvenliği, ağ kuralları, anahtarlar ve loglar için müşteri, sağlayıcı ve ortak sorumlulukları yazılı hale getirin. Sağlayıcının uyum beyanı varsa hangi hizmetleri kapsadığını kontrol edin. Bu belge, mağazanızın yapılandırmasını ve ödeme entegrasyonunu kendiliğinden uyumlu yapmaz.
Bu sorumlulukları işletim takvimine bağlayın. Yeni bir ödeme eklentisi, tema, yönetim aracı veya ağ değişikliği veri akışını ve mevcut kontrolleri etkileyebilir. Değişiklik kaydı; sorumluyu, gerekli testleri, geri dönüş planını ve üretilen kanıtı göstermelidir. Düzenli bakım, uygulanabilir gerekliliklerin sürelerine uyan bir plan içinde yürütülür.
Kart Verisi Akışı ve Kapsamı Daraltma: SAQ’lar, Token ve iFrame
Ödeme sağlayıcısının barındırdığı sayfaya yönlendirme veya sağlayıcının sunduğu gömülü form, doğru kurulduğunda kart verisinin doğrudan sağlayıcıya gitmesini sağlayabilir. Ancak iframe kullanmak tek başına SAQ A uygunluğu anlamına gelmez; kart giriş bileşenlerini kimin sunduğu, verinin izlediği yol ve anketin bütün uygunluk koşulları belirleyicidir. Tokenizasyon ise kart verisi yerine referans kullanılmasıdır; kapsam üzerindeki etkisi tokenın kullanımına ve kalan sistemlere bağlıdır.
Kart giriş alanlarını mağazanız oluşturup veriyi JavaScript ile sağlayıcıya gönderiyorsa, bu akışı sağlayıcının tamamen barındırdığı form ile aynı saymayın. Adres çubuğundaki alan adı tek başına kapsamı açıklamaz. Sağlayıcı formunu gömen bir sayfa için SAQ A v4.0.1 r1’in script saldırılarına ilişkin uygunluk koşulu ayrıca değerlendirilir. Bu özel koşul, tamamen sağlayıcıya yönlendiren sayfalara aynı şekilde uygulanmaz; yönlendirme yapan mağazanın diğer PCI sorumlulukları devam eder.
WooCommerce entegrasyon seçenekleri için PCI DSS uyumlu WooCommerce hosting kontrol listesini inceleyebilirsiniz. Gereklilik metni ve geçerli SAQ sürümleri için resmi PCI Security Standards Council dokümantasyonunu esas alın. Ödeme sağlayıcısının güvenli kurulum talimatlarını, kendi veri akışınız ve sorumluluk tablonuzla birlikte değerlendirin.
TLS, WAF, Ağ Ayrımı ve Ödeme Sayfası
TLS politikasını CDN, ters vekil ve origin sunucusu dahil veri yolunun tamamında inceleyin. Zayıf protokol ve şifre kümelerini kapatın; sertifika doğrulamasını, yenilemeyi ve ilgili bağlantıların güçlü kriptografiyle korunmasını kontrol edin. Mozilla SSL Configuration Generator kullanılan sunucu ve istemci uyumluluğuna göre bir başlangıç yapılandırması hazırlamaya yardımcı olur; çıktısı tek başına PCI uygunluk kanıtı değildir. Ayarları test ortamında ödeme akışıyla doğrulayın. HSTS’i ancak kapsayacağı alan adlarında HTTPS sürekliliği sağlandığında etkinleştirin.
PCI DSS 6.4.2, uygulanabilir halka açık web uygulamalarının önünde web saldırılarını sürekli tespit edip önleyen otomatik bir teknik çözüm gerektirir. 31 Mart 2025’te yürürlüğe giren bu gereklilik için doğru yapılandırılmış bir WAF kullanılabilir. Çözüm etkin ve güncel olmalı, denetim kayıtları üretmeli, saldırıları engellemeli veya hemen incelenen bir alarm oluşturmalıdır. Sıradan IP/port güvenlik duvarı ya da yalnızca rate limit bu işlevlerin yerine geçmez. Ters vekil veya CDN’deki korumanın doğrudan origin erişimiyle atlanmasını önleyin; yanlış pozitifler için geniş muafiyetler yerine dar kapsamlı, kayıtlı kural değişiklikleri uygulayın.
Web, uygulama, veritabanı ve yönetim erişimi arasındaki gerekli bağlantıları tanımlayın. Staging ve ilgisiz projeleri üretimden ayırın; kapsamı azaltmak için kullanılan segmentasyonun etkinliğini doğrulayın. Yönetim panelini sınırlı bir ağdan erişilebilir kılmak, SSH’da kişiye özel anahtarlar kullanmak, gereksiz servisleri kapatmak ve izinleri daraltmak saldırı yüzeyini azaltır. Port değiştirmek güvenlik kontrolünün yerini tutmaz. VPN, IP izin listesi ve SSH anahtarı kullanırken uygulanabilir çok faktörlü kimlik doğrulama (MFA) koşullarını ayrıca karşılayın.
Ödeme sayfasındaki gereksiz üçüncü taraf script’lerini kaldırın. Uygulanabilir 6.4.3 kapsamında kalan script’ler için yetkilendirme, bütünlük kontrolü ve gerekçeli envanter; 11.6.1 kapsamında tarayıcıya ulaşan sayfanın güvenliği etkileyen HTTP başlıkları ve script içeriği için değişiklik tespiti ve alarm gerekir. 11.6.1 kontrolü en az haftalık veya gerekliliğe uygun hedefli risk analiziyle belirlenen sıklıkta çalışır. SAQ A r1’deki gömülü form uygunluğu için bu tekniklerden yararlanılabilir; alternatif olarak uyumlu ödeme sağlayıcısı, talimatlarına göre kurulan çözümünün sayfayı script saldırılarına karşı koruduğunu teyit edebilir. Sağlayıcının iframe içindeki içeriğiyle mağazanın onu barındıran sayfasının sorumluluklarını ayırın.
Yamalar, Zafiyet Taramaları ve Sızma Testi
İşletim sistemi, web sunucusu, uygulama çekirdeği, eklentiler ve temalar için sürüm envanteri tutun. PCI DSS v4.0.1’in 6.3.3 maddesi, risk sınıflandırmasına göre kritik zafiyet yamalarının yayımlandıktan sonra bir ay içinde kurulmasını ister; diğer ilgili yamalar ortamın risk değerlendirmesine uygun sürelerde uygulanır. Acil risklerde daha erken müdahale gerekebilir. Otomasyon, test, bakım penceresi ve geri dönüş adımlarını birlikte planlayın. Bir gecikmeyi kaydetmek ya da geçici ağ kısıtı koymak, zorunlu süreyi kaldırmaz veya kendiliğinden kabul edilmiş telafi edici kontrol oluşturmaz.
Uygulanabilir 11.3.2 dış zafiyet taramaları en az üç ayda bir ASV tarafından yapılır. Bulgular giderilmeli, ASV Program Guide’ın başarılı tarama ölçütleri karşılanmalı ve gerekli yeniden taramalarla düzeltmeler doğrulanmalıdır. Sağlayıcıyı Approved Scanning Vendor listesinde kontrol edin. SAQ A kapsamındaki e-ticaret sayfalarında, ödeme başka sağlayıcıya yönlendirilse veya iframe içinde tamamlansa da bu tarama yükümlülüğü bulunur. Önemli değişikliklerden sonra 11.3.2.1 kapsamında etkilenen sistemler ayrıca dışarıdan taranır; CVSS puanı 4,0 ve üzerindeki açıklar giderilir ve gerektiğinde tekrar taranır. Bu değişiklik taramasını yetkin ve organizasyonel olarak bağımsız bir kişi yapabilir; mutlaka ASV olması gerekmez.
İç tarama da kapsamda uygulanıyorsa isteğe bağlı bir egzersiz değildir: 11.3.1 kapsamında en az üç ayda bir yapılır; kritik ve yüksek riskli açıklar giderilir, yeniden taramayla doğrulanır. Tarama aracını güncel tutun; taramaları yetkin ve organizasyonel olarak bağımsız kişilere yaptırın. Düzenli iç taramalar yeterli yetkilere sahip kimlik bilgileriyle yapılır; kimlik doğrulamalı taramayı desteklemeyen sistemler belgelenir. Daha düşük riskli bulgular hedefli risk analizine göre ele alınır. Önemli değişikliklerden sonra iç tarama ve gerekli tekrarlar da planlanır; kimlik doğrulamalı tarama koşulu bu değişiklik sonrası taramalar için özel olarak aranmaz. Kapsamı yalnızca DNS’te görünen alan adlarıyla sınırlamayın; internetten erişilebilir adresleri, servisleri ve ödeme güvenliğini etkileyen bağlantıları değerlendirin.
Zafiyet taraması ile sızma testi farklı çalışmalardır. Uygulanabilir 11.4 kapsamında iç ve dış sızma testleri en az yılda bir ve önemli altyapı veya uygulama değişikliklerinden sonra, yetkin ve organizasyonel olarak bağımsız kişilerce yapılır. Kapsamı daraltan segmentasyon kontrolleri de en az yılda bir ve bu kontrollerdeki değişikliklerden sonra sınanır; hizmet sağlayıcılar için daha sık test koşulları vardır. Ödeme adımı, yönetim paneli ve API uçları test planına uygun şekilde dahil edilir. Bulguları sorumlu, risk ve tarihle izleyin; düzeltmelerin etkisini tekrar testle doğrulayın.
Log Saklama, İnceleme ve Dosya Bütünlüğü
Hangi olayların kaydedileceğini, kim tarafından inceleneceğini ve hangi alarmın nasıl eskale edileceğini belirleyin. Uygulanabilir 10.4 kapsamında güvenlik olayları, kart verisi saklayan, işleyen veya ileten sistemler, kritik bileşenler ve güvenlik işlevi sunan sistemlerin logları en az günlük incelenir; otomatik inceleme mekanizmaları kullanılır. Diğer kapsam içi bileşenler için inceleme sıklığı hedefli risk analiziyle belirlenir. İstisna ve anormallikler araştırılıp ele alınmalıdır. Yalnızca birkaç e-posta veya Slack alarmı oluşturmak bu inceleme sürecinin yerine geçmez.
Dosya bütünlüğü izlemede kritik yapılandırmalar, sistem dosyaları ve ödeme entegrasyonu dosyaları için yetkisiz ekleme, silme ve değişikliklerde alarm üretin. Uygulanabilir 11.5.2, kritik dosya karşılaştırmalarını en az haftalık ister. Onaylı dağıtımlarla beklenmeyen değişiklikleri ayırın; tek seferlik hash almak yeterli değildir. Sistem saatlerini güvenilir bir zaman kaynağıyla eşitlemek, farklı sunuculardaki olayların aynı zaman çizgisinde incelenmesini sağlar.
Merkezi log toplama, kayıtların korunmasını ve aranmasını kolaylaştırabilir. Uygulanabilir 10.5.1 için en az 12 aylık denetim geçmişi saklanmalı, son üç ay analiz için hemen erişilebilir olmalıdır. Erişimi sınırlayın ve kayıtları yetkisiz değişiklikten koruyun. Loglama politikasını kart verisi saklama izni olarak yorumlamayın: ödeme isteğinin tüm gövdesini, gereksiz kart numaralarını veya hassas kimlik doğrulama verilerini loglara aktarmayın. Uygulama, ters vekil, WAF ve hata ayıklama kayıtlarının gerçekten ne topladığını doğrulayın.
Yedekler, Anahtarlar ve Kurtarma Provaları
Yedek ve önbellekleri veri envanterine dahil edin; yalnızca iş, yasal veya düzenleyici ihtiyaçla gerekçelendirilen kart verisini, tanımlı süre boyunca saklayın ve artık gerekmeyen veriyi güvenli biçimde kaldırın. CVV/CVC, tam iz verisi ve PIN/PIN bloğu gibi hassas kimlik doğrulama verileri, işlem yetkilendirmesi tamamlandıktan sonra şifreli olsa bile saklanamaz. Bu yasak log, cache ve yedek kopyaları için de geçerlidir. Şifreleme, gereksiz veya yasak veriyi tutmayı kabul edilebilir yapmaz.
Gerekli yedekleri aktarımda ve depoda koruyun; güçlü şifreleme, sınırlı erişim ve güvenli anahtar yönetimi uygulayın. Ayrı konumda ve sürümlü kopyalarla kurtarma ihtiyacını karşılayın. Değiştirilemez saklama kullanılacaksa önce veri içeriğiyle saklama/silme politikasının uyumunu doğrulayın. Yedeği test ortamına geri yükleyerek veri tutarlılığını, anahtarlara erişimi ve kurtarma süresini ölçün; dosyanın mevcut olması kurtarılabilirliğini kanıtlamaz.
Parolaları, ödeme sağlayıcısı API anahtarlarını ve yedek şifreleme anahtarlarını kontrollü bir kasada yönetin; erişimi görevle sınırlayın. Ayrılan personelin erişimini hemen kaldırın, bildiği ortak veya açığa çıkmış sırları yenileyin. Uygulanabilir MFA koşullarını yönetim ve kart verisi ortamına erişim yollarında uygulayın; SSH anahtarı veya IP kısıtı kullanılması bunların karşılandığını tek başına göstermez. Ödeme yapılandırması ve anahtar değişikliklerini yetkili kişilerce onaylanan kayıtlara bağlayın.
Kurtarma runbook’u; kimin kimi bilgilendireceğini, yedek ve anahtarlara nasıl erişileceğini, veritabanının ve uygulamanın hangi sırayla açılacağını, önbelleklerin nasıl yenileneceğini ve ödemenin nasıl doğrulanacağını açıklamalıdır. Bir ihlal şüphesinde sistemi izole edin ve ilgili kanıtları koruyun; kaynağı giderilmemiş bir sorunu yedekten geri getirmeyin. Provalarda bulunan eksik izinleri ve başarısız adımları plana işleyin.
Sürdürülebilir Bir PCI Hosting Planı
Başlangıç çıktınız üç parçadan oluşsun: doğrulanmış ödeme veri akışı, müşteri ve sağlayıcının sorumluluk tablosu, uygulanabilir kontroller için bakım ve kanıt takvimi. TLS, erişim, web uygulaması koruması, taramalar, log incelemesi ve kurtarma çalışmalarını bu planla ilişkilendirin. Önceliği aktif risklere ve zorunlu sürelere verin; işler tamamlandıkça kayıtlarını güncelleyin.
Her değişiklikten sonra yalnızca mağazanın açılmasını değil, ödeme yolunun ve koruyucu kontrollerin çalışmasını da doğrulayın. Başarılı bir tarama, tek bir güvenlik ürünü veya sağlıklı bir yedek bütün PCI DSS değerlendirmesinin yerine geçmez. İşletim düzeninin amacı, gereken kontrollerin sürekliliğini ve nasıl doğrulandığını görünür kılmaktır.
