PCI-DSS Uyumlu WooCommerce Hosting Kontrol Listesi: SAQ A mı A‑EP mi, TLS’te Nereden Başlamalıyız?

Ofiste Küçük Bir Telaş: WooCommerce ve PCI-DSS’le Yüzleşme Zamanı

Geçen hafta ofiste kahvemi almış, e-postalara göz gezdiriyordum. Bir müşteriden “Banka PCI uyumu istedi, SAQ A mı A‑EP mi anlamadım, TLS de bir şeyler diyorlar” diye bir mesaj düştü. Tam o an, yıllar önce ilk kez bir WooCommerce mağazasını PCI-DSS çizgisine çektiğim günü hatırladım. O günkü ben de aynı soruları sormuştum. Hiç başınıza geldi mi böyle, her şey çalışıyor ama bir anda “uyum” kelimesi bütün ritmi değiştiriyor?

İşin güzel tarafı, PCI-DSS korkutucu olmak zorunda değil. Birkaç net kavramı yerli yerine oturttuğunuzda, WooCommerce tarafında yol haritası kendini gösteriyor. Bu yazıda beraber adım adım gideceğiz; SAQ A ve SAQ A‑EP farkını sindire sindire konuşacağız. Sonra TLS ayarlarında nelere dikkat etmeliyiz, loglama nasıl bir alışkanlığa dönüşür, ağ segmentasyonu hangi kapıları kapatıp hangilerini aralar, hepsini gerçek örneklerle anlatacağım. En sonda da elde tutulur bir kontrol listesi hissi kalsın istiyorum, ama cümlelerin içinde, doğal akışta.

WooCommerce Dükkânını PCI-DSS Çizgisine Nasıl Sokarız? SAQ A mı, SAQ A‑EP mi?

İlk düğme doğru iliklenirse gerisi kolay

PCI-DSS’te işin başlangıç noktası şu soru: Kart verisi sizin altyapınıza uğruyor mu? Eğer kart numarası, son kullanma tarihi gibi bilgiler sizin sunucunuza değmiyorsa ve ödeme sayfası tamamen sağlayıcıda barınıyorsa, genellikle SAQ A size göz kırpar. Mesela müşteriyi ödeme için sağlayıcının barındırdığı sayfaya yönlendiriyorsunuz, ya da sayfa sağlayıcıdan gelen tam bir iFrame’le render ediliyor ve siz bu veriye izin olsun diye dokunmuyorsunuz. Bu senaryoda kapsam daha derli toplu kalır, iştah kabartan bir sadelik vardır.

Diğer tarafta SAQ A‑EP var. Burada ödeme sayfasının bir kısmı sizin sitenizden geliyor, ya da sayfanın güvenliği sizin düzenlediğiniz kod ve içeriklerden etkileniyor. Örneğin “hosted fields” veya sayfaya enjekte edilen bir JavaScript ile tokenize etseniz bile; o sayfayı sizin sunucunuz sunuyorsa, riskin bir ucu sizin tarafa bağlanıyor. İşte bu yüzden A‑EP biraz daha sıkı bir çerçeve ister. Web uygulaması güvenliği, düzenli taramalar ve daha disiplinli bir yama yönetimi devreye girer.

Mesela şöyle düşünün

WooCommerce’te bir müşterim vardı; önce tüm ödemeleri dış sağlayıcının sayfasına yeniden yönlendiriyordu. Yani kart verisi onun sitesine uğramıyordu, SAQ A ile yoluna devam etti. Zamanla kullanıcı deneyimini akış içinde tutmak, sepeti terketmeyi azaltmak istedi. Ödeme formunun bir kısmı kendi alan adında görünmeye başlayınca, SAQ A‑EP planına geçti. O geçişte ufak dokunuşlarla güvenliği sıkılaştırdık: uygulama yamalarını hızlandırdık, WAF devreye aldık, logları daha görünür topladık. Hızlıca şunu fark etti: kuralları bilince kararlar netleşiyor.

Eğer “Hangi SAQ bana uygun?” sorusuna hâlâ kaşlarınız çatık bakıyorsa, bir göz atın: SAQ formları ve kapsam açıklamaları. Dökümanların dili ağır gelebilir ama ana fikir basit: kart verisi sizin katınızdan geçiyorsa yahut sayfanın güvenliğini siz etkiliyorsanız, kapsam büyür; geçmiyorsa sadeleşir.

TLS, Sertifikalar ve Küçük Sırlar: Ziyaretçinin Tarayıcısından Kasaya Kadar Güvenli Yolculuk

“https” sadece yeşil kilit değil

Ödeme işine bulaşınca TLS düzeni işin omurgası oluyor. Dışarıdan bakınca “SSL sertifikası var mı?” diye soruluyor ama asıl hedef şudur: güncel protokoller, sağlam şifre takımları ve otomatik yenilenen sertifikalar ile trafiği tertemiz tutmak. Kural gibi düşünmeyin, daha çok alışkanlık gibi görün: TLS 1.2 ve 1.3 önde, eski sürümler kapıda beklemesin. Ziyaretçiyi HTTP’den HTTPS’e nazikçe ama kararlı bir yönlendirmeyle alın.

Sertifika tarafında kafa karışabiliyor. DV, OV, EV, bir de wildcard dünyası var. Hangisi ne zaman sorusunu epey konuşuyoruz. E-ticaret tarafında hangi sertifika ne zaman iş görür derseniz, pratikte şu ayrımı seviyorum: marka güvenini vitrine koymak istiyorsanız EV’nin hikâyesi farklı, alt alan adlarını tek kalkanla toplamak istiyorsanız wildcard pratik. Ama en önemlisi şu, sertifikayı doğru sunucu ayarıyla desteklemezseniz, güzel zırh üzerindeki zayıf toka gibi kalır.

İşin mutfağında, sunucu ayarlarını el yordamıyla değil, bilindik reçetelerle güçlendirmek iyi geliyor. “Hangi şifre paketleri, hangi politika?” diye düşünürseniz, Mozilla’nın SSL yapılandırma rehberi oldukça işlevsel. Bir de tarayıcıya “beni hep HTTPS’ten ziyaret et” demek için HSTS eklemeyi sevin. Böylece sitenizle ziyaretçi arasındaki yol çizgileri çok daha netleşir, küçük pürüzler büyümeden yoluna girer.

Loglama: Olanı Olduğu Gibi Kaydetmek ve Geriye Dönüp İz Bulabilmek

Bir gün önce olanı bugün bulabilmek

PCI-DSS’in belki de en insani tarafı loglar. Çünkü log olmadan “ne oldu?” sorusunun cevabı hep eksik kalıyor. Bir müşterimin sitesinde bir gece yarısı siparişler dalgalanmış, anormal birkaç istek göze çarpmıştı. Neyse ki erişim logları düzenli toplanıyor, kim oturum açtı, hangi eklenti güncellendi gibi izler de ayrı bir yere akıyordu. Sabah olduğunda olayı dakikasına kadar geriye sarabildik. O gün anladık ki loglar, alarm çaldırmaktan çok hikâyeyi düzgün anlatma işi görüyor.

WooCommerce tarafında ben şu alanlara dikkat ediyorum: web sunucusu erişim kayıtları, uygulama hataları, yönetici giriş-çıkışları ve yetkisiz denemeler, veritabanı bağlantı uyarıları, yedekleme ve güncelleme kayıtları. Bu kayıtları tek tek sunucularda tutmak yerine merkezi bir yere akıtmak işleri müthiş kolaylaştırıyor. Mesela merkezi loglama için pratik bir yol izlerseniz, hem tutma süreleri netleşir, hem de alarm kurallarıyla “olağan dışı ne var?” sorusuna otomatik cevap gelmeye başlar.

Güzel bir alışkanlık da logları bozulmaz şekilde saklamak. Sadece yazma yetkisi olan bir hedefe göndermek, erişimi sınırlamak, şifreli taşıma yapmak ufak ama etkisi büyük adımlar. Yani günlüklerde sadece satırlar yok; gelecekteki denetiminize, hatta kriz anındaki soğukkanlılığınıza giden yol var. Uygulama güncellemeleri, kullanıcı rolleri ve yetki değişimleri de mutlaka iz bıraksın ki, “kim, ne zaman, neyi değiştirdi?” sorusu kolayca yanıt bulsun.

Ağ Segmentasyonu: Her Odaya Ayrı Anahtar, Her Kapıya Doğru Kilit

Tek büyük oda yerine akıllı odacıklar

Bir e-ticaret sitesini tek bir büyük oda gibi düşünmeyin. Bazen en iyi güvenlik, odayı birkaç parçaya bölmektir. Ağ segmentasyonu dediğimizde hedef şu: web katmanı, uygulama katmanı ve veritabanı katmanı gibi bölmelerin birbiriyle sadece gerekli kapılardan konuşması. Örneğin web sunucusu herkesle konuşmasın, sadece önünde ters vekil var ise onunla konuşsun, veritabanıyla sadece belirli portlardan iletişime geçsin. Yönetim panelleri de herkese açık yollarda gezmesin; belirli ofis IP’leri veya VPN arkasından gelsin.

Bazen bir uygulama güvenlik duvarı ya da iyi ayarlı bir ters vekil araya koymak bile gidişatı değiştiriyor. Kimlik doğrulama sayfalarına nazik ama kararlı hız sınırlamaları koyduğunuzda, kaba kuvvet denemeleri kısa sürede boşa düşüyor. Bu noktada Nginx rate limiting ve Fail2ban ile akışı dizginlemek çok iş görüyor. Küçük bir kural, büyük bir sessizlik yaratabiliyor.

Uzak erişimi de es geçmeyin. SSH’ı herkese açık bir kapı gibi bırakmak yerine anahtar tabanlı erişime çekmek, mümkünse donanım anahtarlarıyla güçlendirmek iyi geliyor. Yönetici panellerini iki kat kapıyla korumak isterseniz, mTLS gibi yöntemler ayrı bir huzur veriyor. Ama en önemlisi, kim nereye erişebilir sorusunu yalın bir çizelgeyle kendinize anlatabilmek. Ayrı ayrı düşünün, sadece gerekli bağlantılara izin verin, gerisi zaten sessizleşiyor.

WooCommerce Tarafında Günlük Pratikler: Eklentiler, Güncellemeler ve Küçük Sertleştirmeler

Az ve öz eklenti, düzenli yama, sakin kalp

Gerçek hayat sahnesinde sorunların önemli bir kısmı eklentilerden geliyor. “Bir işi daha yapsın” diye kurduğumuz eklentiler, bazen arkadan kocaman kapılar açabiliyor. Bu yüzden az ve öz yaklaşımını seviyorum. Kullanmadığınız eklentileri kapatıp kaldırmak, temaları güncel tutmak, admin kullanıcısını güçlendirmek oyunun ilk hamleleri. Sıkı bir bakış için WordPress güvenlik sertleştirme adımlarını okumak güzel bir başlangıç veriyor. Ufak ayarlarla sitenin “temel dayanıklılığı” hissedilir şekilde artıyor.

Ödeme eklentileri tarafında tam sayfa yönlendirme ya da tamamen sağlayıcıda barınan iFrame kullanıyorsanız SAQ A çizgisine yakınsarsınız. Ödeme formu sizin alan adınızın içinde render olup, sayfa içeriği sizin kodunuzdan etkileniyorsa SAQ A‑EP size göz kırpar. İkisi arasında seçim yaparken müşteri deneyimini de düşünün ama güvenlikten ödün vermeden. Ufak bir ipucu: içerik güvenlik politikalarıyla (CSP) dışarıdan gelebilecek betikleri sadece ihtiyaç duyduğunuz sağlayıcılara sınırlarsanız, sayfa bütünlüğü daha kolay korunur.

Güncellemeleri bir ritme bağlamak da harikalar yaratıyor. Haftalık küçük bir bakım penceresi açın; eklenti ve çekirdek güncellemeleri kontrol edin, veritabanı yedeklerini deneyin. Bir şeyler ters giderse geriye dönüş planınız olsun. Bu kısım özünde operasyondur ama PCI-DSS’in ruhu da burada. Söz uçar, iz kalır; siz işletim ritmini kalıcı kılarsanız, uyum kendiliğinden akar.

Denetim, Dökümantasyon ve Kriz Provası: İşler Kızışmadan Önce

Sorulmadan önce cevapları hazır etmek

PCI-DSS’i gerçek hayatta taşır hale getiren şey, dökümantasyon ve küçük rutinler. Kim hangi hesaba sahip, parolalar nasıl değişiyor, yedekler nerede duruyor, olay olduğunda kim kimi arıyor? Bunların hepsi küçük yanıtlar gibi görünür ama krizde devleşir. Özellikle SAQ A‑EP kapsamındaysanız, web uygulaması taramaları, yama süreçleri ve değişiklik kayıtları çok daha kıymetli hale gelir. Burada amacınız kusursuzluk değil; izlenebilirlik ve tekrar edilebilirlik.

Bir müşterimle basit bir “ne olur” provası yapmıştık: ödeme sayfası yerine geçici bir bakım ekranı koyma, veritabanını salt okunur moda çekme, yönlendirmeyi sağlayıcıya kaydırma gibi adımları beş-on dakikada denedik. O küçük prova, bir ay sonra gerçekten işimize yaradı. Dönüp bakınca anladık ki, felaket hiç beklediğiniz gibi gelmiyor, ama siz hazır olursanız uğramadan geçiyor. Bu çizgiyi güçlendirmek isterseniz felaket kurtarma planını pratik hale getiren öneriler çok iş görüyor.

Son bir dokunuş da eğitim. Ekip arkadaşlarınıza düzenli olarak kısa notlar yollayın: şüpheli e-postalar nasıl anlaşılır, yönetim paneline nereden girilir, VPN kapalıyken ne yapılmaz gibi. Basit bir kültür, en iyi güvenlik araçlarını gölgede bırakabiliyor. OWASP taşıma katmanı koruma önerileri ve benzeri kaynakları iç rehberlerinize dönüştürüp paylaşın. Herkes aynı dili konuştuğunda, uyum bir zorunluluk değil, doğal davranışa dönüşüyor.

Pratik Kontrol Listesi Hissi: SAQ A/A‑EP, TLS, Log ve Ağ İçin Küçük Yol Taşları

Adımları cümlelerin içine serelim

“Kart verisi benim sunucuma uğruyor mu?” sorusunu netleştirin; tam yönlendirme veya sağlayıcı iFrame ile gidiyorsanız SAQ A, sayfa sizden bir şeyler alıyorsa SAQ A‑EP düşünün. TLS’te güncel protokollerle çalışın, eski sürümleri kapatın, otomatik yenilenen sertifikalarla işinizi hafifletin ve HSTS ile tarayıcıların sizi hep güvenli yoldan ziyaret etmesini isteyin. Sunucu ayarlarını el yordamıyla bırakmayın; Mozilla’nın SSL yapılandırma rehberi gibi kaynaklarla reçeteleyin.

Loglarda erişim, hata, yönetim ve yetki değişimlerine odaklanın; mümkünse merkezi log yönetimi kurup alarm eşikleri belirleyin. Ağ segmentasyonunda her katmanı ayrı düşünün; web sadece gerekli yerlere gitsin, veritabanı herkese açık olmasın, yönetim panellerini sadece yetkili adreslere verin. Kaba kuvvet denemelerini hız sınırlama ve akıllı engelleme ile sussun. WooCommerce tarafında az ve öz eklentiyle ilerleyin, düzenli yama için küçük bakım pencereleri oluşturun, tema ve çekirdeği güncel tutun. TLS sertifika seçimini bilinçle yapın; merak ettikleriniz için sertifika türlerine kısa bir tur iyi gelir.

SAQ formu seçiminde takıldığınız yerde, resmi SAQ açıklamalarına tek göz atmak bile fikir açıyor. Unutmayın, amaç kutucuk işaretlemek değil; müşterinizin kartını güvenle taşımak. Küçük bir alışkanlıklar demeti, büyük fotoğrafı tamamlıyor.

Kapanış: Sakin, Sıcak ve Kontrol Sizde

Şunu çok gördüm: PCI-DSS kelimesi ilk duyulduğunda yüzler gerilir, omuzlar kalkar. Oysa iyi yerleştirilmiş birkaç taşla yol dümdüz olur. SAQ A/A‑EP ayrımında doğru tarafa geçmek, TLS ayarlarını reçeteyle yapmak, logları tek yerde toplayıp anlamlı hale getirmek ve ağ segmentasyonuyla sadece gerekli kapıları açık tutmak size zihinsel bir rahatlık veriyor. Gerisi, düzenli güncellemeler ve ufak provalarla pekişiyor.

Eğer aklınızda “Nereden başlayayım?” diye bir soru asılı kaldıysa, bugünden üç küçük adım atın: ödeme akışınızı yazıyla çizin ve SAQ tarafını netleştirin, TLS ayarlarınızı gözden geçirip eski protokolleri kapatın, loglarınızı merkezi bir yerden görmeye başlayın. Bir de gönül rahatlığı için küçük bir felaket provası planlayın. Umarım bu yazı size iyi gelmiştir; dükkanınızın kasası güvenle çalsın, siz de geceleri daha derin uyuyun. Bir dahaki yazıda görüşmek üzere.