PCI-DSS Nedir? Kart Ödemesi Alan Siteler İçin Rehber

Sitenizde bir "Kredi Kartıyla Öde" düğmesi varsa, farkında olsanız da olmasanız da global bir güvenlik standardının kapsamına girmişsiniz demektir. Bu standardın adı PCI-DSS, yani Payment Card Industry Data Security Standard. Visa, Mastercard, American Express, Discover ve JCB'nin kurduğu ortak bir konsey (PCI SSC) tarafından yönetilir ve amacı tek cümleyle özetlenebilir: kart sahibinin verisini, o veriyi bir şekilde eline alan herkesin koruması. "Ben küçük bir e-ticaret sitesiyim, bana kim bakar" düşüncesi burada işe yaramaz; standart, işlem hacminize değil, kart verisine dokunup dokunmadığınıza bakar.

Bu rehberde işi hukuk metni gibi ağırlaştırmadan, kıdemli bir sistem yöneticisinin müşterisine masada anlattığı sadelikte ilerleyeceğiz. PCI-DSS'in kimleri bağladığını, "kart verisi" derken tam olarak neyi kastettiğini, ağ güvenliğinden şifrelemeye ve erişim kontrolünden izlemeye kadar temel gereksinimlerini göreceğiz. En kritik kısım ise şu olacak: kart verisini hiç saklamadan, ödemeyi lisanslı bir ödeme geçidine devrederek uyum yükünüzü nasıl neredeyse sıfıra indirebileceğinizi anlatacağız. Baştan söyleyelim, PCI-DSS bir "SSL kur ve unut" işi değildir; ama doğru mimariyle çok daha az kalemlik bir sorumluluğa indirgenebilir.

PCI-DSS Nedir ve Kimleri Bağlar?#

PCI-DSS, kredi ve banka kartı verisi işleyen, ileten ya da saklayan her kuruluşa uygulanan teknik ve operasyonel bir güvenlik standardıdır. Bir yasa değildir; kartlı ödeme ağlarının sözleşmesel bir zorunluluğudur. Yani sizi bir devlet kurumu değil, çalıştığınız banka veya ödeme kuruluşu (edinen kurum / acquirer) denetler. Uyumsuzluğun bedeli de genellikle idari para cezasından çok, ödeme almanızın kısıtlanması ya da bir ihlal sonrası size kesilen ağır cezalar biçiminde ortaya çıkar.

Kapsama kimin girdiğini belirleyen tek soru şudur: kart verisiyle ilişkiniz nedir? Üç ana rol vardır. Üye iş yeri (merchant), yani kart kabul eden e-ticaret sitesi veya işletme. Hizmet sağlayıcı (service provider), kart verisini başkaları adına işleyen taraf; ödeme geçidi, hosting ve altyapı sağlayıcıları burada olabilir. Ödeme markaları ve edinen kurumlar ise zincirin en üstünde. Önemli nokta şudur: kart verisini kendi sunucunuzda hiç görmeseniz bile, ödeme sürecine dokunan sayfalarınız olduğu sürece belirli bir seviyede sorumlusunuz. İyi haber, o seviyenin ne kadar hafif olacağını büyük ölçüde sizin mimari tercihiniz belirler.

Yaygın bir yanılgı da şudur: "PCI-DSS sadece büyük şirketleri ilgilendirir." Gerçekte üye iş yerleri işlem hacmine göre seviyelere ayrılır, ancak en küçük iş yeri bile uyum beyanı vermek zorundadır. Aradaki fark, büyük işletmelerin bağımsız bir denetçi (QSA) tarafından yerinde denetlenmesi, küçük işletmelerin ise kendi beyanına dayanan bir anket (SAQ) doldurmasıdır. İkisi de "uyum" demektir; sadece ispat yükü farklıdır.

Kart Verisinin Kapsamı: Neyi Koruyoruz?#

Standardı doğru uygulamanın ilk şartı, "kart verisi" teriminin sınırlarını netleştirmektir. PCI-DSS iki kategori tanımlar ve bunların saklanma kuralları taban tabana zıttır. Birincisi kart sahibi verisi (Cardholder Data - CHD): kart numarası (PAN), kart sahibinin adı, son kullanma tarihi ve servis kodu. İkincisi hassas doğrulama verisi (Sensitive Authentication Data - SAD): kartın arkasındaki üç haneli güvenlik kodu (CVV2/CVC2), manyetik şerit / çip izi ve PIN bilgisi.

Aradaki fark hayati önemdedir. Kart sahibi verisini, güçlü şifrelemeyle ve iş gereği ölçüsünde saklayabilirsiniz. Hassas doğrulama verisini ise işlem onaylandıktan sonra hiçbir gerekçeyle saklayamazsınız — şifreli bile olsa. Yani CVV kodunu bir log dosyasına, bir veritabanı sütununa veya bir hata izleme aracının ekran görüntüsüne düşürmek doğrudan ihlaldir. Sahada en sık gördüğümüz sorun tam da budur: geliştirici, hata ayıklama için tüm istek gövdesini loglar ve farkında olmadan kart numaralarını düz metin olarak diske yazar.

Aşağıdaki tablo, hangi verinin saklanabileceğini özetliyor.

Bu tablonun pratik sonucu şudur: sisteminizde SAD'nin tutulmadığından emin olmak, uygulama loglarınızı maskelemek kadar temel bir hijyen kuralıdır. Bir uygulama katmanında istek gövdesini loglarken kart alanlarını gizlemek, birkaç satırlık bir tedbirdir ama denetimde en çok not kaybettiren yerlerden biridir.

PCI-DSS'in Temel Gereksinimleri#

PCI-DSS'in güncel sürümü (v4.0) toplam 12 ana gereksinimi altı hedef altında toplar. Hepsini ezberlemenize gerek yok; dört büyük başlıkta düşünmek pratikte yeterlidir: ağı güvene almak, veriyi şifrelemek, erişimi kısıtlamak ve her şeyi izlemek. Bu dört başlık, aslında sağlam bir sunucu güvenliği temelleri yaklaşımının kart verisine uyarlanmış hâlidir.

Ağ güvenliği. Kart verisinin bulunduğu ortam (CDE) ile dış dünya arasında bir güvenlik duvarı olmalı, gereksiz portlar kapalı tutulmalı ve üretici varsayılan parolaları/ayarları asla korunmamalı. Bir sunucuda ilk yapılacak iş, yalnızca ihtiyaç duyulan servisleri açık bırakmaktır. Basit bir örnek: veritabanı portunu yalnızca uygulama sunucusuna açmak, dışarıya tamamen kapatmak.

# Yalnizca gerekli portlari ac; kart verisi olan ortamda kural azligi tercih edilir
ufw default deny incoming
ufw allow 443/tcp          # HTTPS
ufw allow from 10.0.0.0/24 to any port 3306 proto tcp   # DB sadece ic agdan
ufw enable

Şifreleme. Kart verisi hem taşınırken hem de saklanırken (gerekiyorsa) güçlü kriptografiyle korunmalıdır. İnternet üzerinden giden her kart verisi mutlaka güncel TLS ile şifrelenmeli, eski protokoller kapatılmalıdır. Bu konuda temeli SSL sertifikası nedir yazımızda ayrıntısıyla ele aldık. Web sunucusu tarafında asgari, modern bir yapılandırma şöyle görünür:

server {
    listen 443 ssl http2;
    server_name magaza.ornek.com;

    ssl_certificate     /etc/ssl/ornek/fullchain.pem;
    ssl_certificate_key /etc/ssl/ornek/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;        # TLS 1.0/1.1 kapali
    ssl_ciphers         HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

Şifrelemeyi tamamlayan bir tedbir de, kartla ilgili bir DNS/sertifika zafiyetini azaltmak için hangi otoritelerin sertifika üretebileceğini sınırlamaktır. Bir CAA kaydı bu izni daraltır:

magaza.ornek.com.   IN   CAA   0 issue "letsencrypt.org"
magaza.ornek.com.   IN   CAA   0 iodef "mailto:[email protected]"

Erişim kontrolü. Kart verisine yalnızca işi gereği ihtiyaç duyanlar erişmeli, herkesin benzersiz bir kimliği olmalı ve yönetici erişimlerinde çok faktörlü doğrulama (MFA) zorunlu tutulmalıdır. Paylaşılan "admin" hesapları, kart verisi olan bir ortamda kabul edilemez. Veritabanı tarafında en az yetki ilkesi uygulanır; uygulama kullanıcısına yalnızca ihtiyacı olan yetki verilir.

-- Uygulama yalnizca ilgili tabloya, sadece ic agdan erisebilsin
CREATE USER 'odeme_app'@'10.0.0.%' IDENTIFIED BY 'uzun-ve-rastgele-parola';
GRANT SELECT, INSERT, UPDATE ON magaza.siparisler TO 'odeme_app'@'10.0.0.%';
-- DROP, GRANT, kart tablolarina genis yetki verilmez
FLUSH PRIVILEGES;

İzleme ve test. Kart verisine yapılan her erişim loglanmalı, loglar merkezi ve değiştirilemez biçimde saklanmalı, sistemler düzenli olarak zafiyet taramasından ve sızma testinden geçirilmelidir. Loglama olmadan bir ihlalin kapsamını dahi ölçemezsiniz; bu yüzden erişim ve hata logları PCI kapsamının görünmez ama en çok işe yarayan parçasıdır.

Ödeme Geçidi ile Uyum Yükünü Nasıl Azaltırsınız?#

Şimdi bu rehberin en değerli fikrine geldik. Yukarıdaki 12 gereksinimin tamamı, ancak kart verisi sizin sunucunuzdan geçiyorsa tüm ağırlığıyla omzunuza biner. Peki ya kart verisi hiçbir zaman sizin sisteminize uğramıyorsa? İşte PCI kapsamını küçültmenin altın kuralı budur: taşımadığın veriyi korumak zorunda kalmazsın.

Pratikte bunun yolu, ödemeyi lisanslı bir ödeme geçidine (payment gateway) devretmektir. Türkiye'de iyzico, PayTR, Param, Sipay gibi kuruluşların büyük çoğunluğu PCI-DSS'in en üst seviyesinde (Level 1) sertifikalıdır. Kart bilgisi, ziyaretçinin tarayıcısından doğrudan bu kuruluşun sunucularına gider; sizin sunucunuz kart numarasını hiç görmez. Size dönen tek şey bir işlem sonucu ve varsa bir token'dır. Bu mimaride kart verisini sıfır saklarsınız ve sorumluluğunuzun büyük kısmı sertifikalı sağlayıcının üzerine geçer.

Kart verisini sitenizden uzak tutmanın üç yaygın yöntemi vardır:

• Hosted ödeme sayfası (redirect): Kullanıcı, ödeme adımında geçidin kendi sayfasına yönlendirilir, kartı orada girer, işlem bitince sitenize geri döner. Kart verisi hiçbir aşamada sizin alan adınıza değmez. Kapsamı en küçük yöntem budur.
• iframe / gömülü alan: Ödeme formu bir iframe içinde geçit tarafından sunulur; görsel olarak sitenizin içindedir ama teknik olarak veri geçide gider.
• Sunucu-sunucu (server-to-server): Kart verisi sizin sunucunuza uğrar ve siz onu geçide iletirsiniz. Bu yöntem en yüksek kapsamı doğurur ve tam PCI denetimini gerektirir; çoğu işletme için gereksizdir.

Aşağıdaki tablo, mimarinin kapsam üzerindeki etkisini net gösteriyor.

Bu tablonun mesajı açık: mümkünse redirect veya iframe tabanlı bir çözüm seçin. Ödeme düğmesine bastığınızda kullanıcıyı geçide gönderen basit bir akış bile, PCI kapsamınızı yüzlerce maddelik SAQ D'den, birkaç düzine maddelik SAQ A'ya indirir. Bu, aylarca sürecek bir uyum projesini bir öğleden sonralık bir yapılandırmaya dönüştürmek demektir.

Clou.TR tarafında bu mimariyi güvenle kurmanız için gereken altyapı hazırdır: WordPress hosting ve web hosting paketleri ücretsiz SSL ile gelir, SSL çözümlerimiz ödeme sayfalarınızı uçtan uca şifreler, WAF ve DDoS koruma hizmetleri de OWASP tipi uygulama saldırılarını ödeme akışınıza ulaşmadan filtreler.

SAQ Seviyeleri: Hangisi Sizin İçin?#

Küçük ve orta ölçekli üye iş yerleri, uyumu genellikle bir bağımsız denetçiyle değil, öz değerlendirme anketi (Self-Assessment Questionnaire - SAQ) doldurarak beyan eder. Hangi SAQ formunu dolduracağınız, tamamen kart verisiyle kurduğunuz ilişkiye bağlıdır. Yani yukarıda anlattığımız mimari tercih, doğrudan hangi anketi dolduracağınızı belirler.

Çoğu online mağaza için hedef nettir: SAQ A. Bu formu doldurabilmenin şartı, ödeme sayfasını tümüyle sertifikalı bir geçide devretmiş olmanızdır. SAQ A'da sizden istenenler ağırlıklı olarak temel hijyen maddeleridir; kart verisi saklamamak, güçlü parolalar, üçüncü tarafların PCI durumunu takip etmek gibi. Buna karşılık SAQ D, üç yüz civarı maddesiyle tam kapsamlı bir güvenlik programı ister; ancak kart verisini gerçekten kendi sisteminizde işliyorsanız kaçınılmazdır.

Ölçek büyüdükçe (yılda milyonlarca işlem) beyan yerine bir QSA'nın (Qualified Security Assessor) yerinde denetimi ve resmi bir uyum raporu (ROC) devreye girer. Fakat KOBİ ölçeğindeki bir e-ticaret sitesinin buraya takılması nadirdir; doğru mimariyle çoğu işletme SAQ A çerçevesinde kalır.

Tokenizasyon ve 3D Secure ile Güvenliği Artırmak#

Kart verisini saklamamak en iyisidir; ama "tekrarlayan ödeme" veya "kartı hatırla" gibi bir ihtiyacınız varsa ne yaparsınız? Cevap tokenizasyon. Bu yöntemde kart numarasını siz saklamazsınız; onun yerine ödeme geçidi size, o karta karşılık gelen anlamsız bir kimlik (token) verir. İkinci bir çekim gerektiğinde geçide gerçek kart numarasını değil, bu token'ı gönderirsiniz. Sizin veritabanınızda duran şey, çalınsa bile hiçbir işe yaramayan bir dizedir.

-- Sizin sakladiginiz sey kart numarasi DEGIL, geride donen token'dir
CREATE TABLE kayitli_kartlar (
  id           BIGINT PRIMARY KEY AUTO_INCREMENT,
  musteri_id   BIGINT NOT NULL,
  gecit_token  VARCHAR(64) NOT NULL,   -- geciden donen anlamsiz kimlik
  kart_marka   VARCHAR(20),            -- ornek: 'visa'
  son_dort     CHAR(4),                -- yalnizca son 4 hane (gosterim icin)
  olusturma    DATETIME DEFAULT CURRENT_TIMESTAMP
  -- PAN, CVV, son kullanma tarihi burada ASLA tutulmaz
);

Bu tablonun tasarımına dikkat edin: ne kart numarası, ne güvenlik kodu, ne de tam son kullanma tarihi var. Yalnızca kullanıcıya "Visa ... 4242" gibi bir görsel ipucu sunmak için son dört hane ve geçitten dönen token duruyor. Bu yaklaşımla "kartı hatırla" özelliğini, PCI kapsamınızı büyütmeden sunabilirsiniz.

İkinci güçlü katman 3D Secure (Visa Secure, Mastercard Identity Check). Bu, ödeme sırasında kart sahibinin bankası tarafından ek bir doğrulama (SMS OTP veya banka uygulaması onayı) istenmesidir. Türkiye'de kartlı online ödemelerde zaten yaygın olarak zorunludur ve iki önemli faydası vardır: sahtecilik (fraud) riskini ciddi biçimde düşürür ve pek çok senaryoda işlemin sorumluluğunu (chargeback) bankaya kaydırır. Ödeme geçidiniz 3D Secure'ü sizin için yönetir; sizin işiniz sadece bu akışı devre dışı bırakmamaktır.

PCI-DSS İçin Uygulamalı Kontrol Listesi#

Teoriyi somut bir yapılacaklar listesine indirgeyelim. Küçük veya orta ölçekli bir e-ticaret sitesini "makul ölçüde güvenli ve düşük kapsamlı" hâle getirmek için izleyeceğiniz yol şudur. Önce mimariyi doğru kurun: ödemeyi sertifikalı bir geçide (redirect veya iframe) tamamen devredin ki kart verisi sunucunuza hiç uğramasın. Bu tek karar, uyum yükünüzün belki de yüzde sekseninı belirler.

Ardından temel güvenlik hijyenini oturtun. Tüm trafiği güncel TLS ile şifreleyin ve HTTP'yi HTTPS'e yönlendirin. Yönetim panellerine MFA zorunlu kılın, paylaşılan hesapları kaldırın, en az yetki ilkesini hem sunucuda hem veritabanında uygulayın. Uygulama loglarınızda kart alanlarının maskelendiğinden emin olun; hata izleme araçlarının istek gövdesini olduğu gibi kaydetmediğini test edin. Yazılımınızı ve bağımlılıklarınızı güncel tutun, düzenli zafiyet taraması çalıştırın.

Son olarak süreçleri belgeleyin ve dış bağımlılıkları takip edin. Kullandığınız ödeme geçidinin ve barındırma sağlayıcınızın PCI uyum belgelerini (AOC) dosyalayın; bunlar sizin SAQ'nuzda dayanacağınız kanıtlardır. Verinizi düzenli ve şifreli yedekleyin, sunucu güncellemelerini ihmal etmemek için sunucu yönetimi desteğinden yararlanın. Aşağıdaki liste, kısa bir gözden geçirme için elinizin altında dursun.

Sıkça Sorulan Sorular#

PCI-DSS bir yasa mı, uymazsam devlet ceza mı keser?#

Hayır, PCI-DSS bir devlet yasası değil, kartlı ödeme ağlarının koyduğu sözleşmesel bir standarttır. Denetimi ve yaptırımı devlet değil, çalıştığınız banka veya ödeme kuruluşu yapar. Uymamanın bedeli genellikle ödeme almanızın kısıtlanması, işlem başına daha yüksek ücretler ya da bir veri ihlali yaşandığında karşılaşacağınız ağır cezalardır. Ayrıca Türkiye'de kişisel veri boyutuyla KVKK yükümlülükleri de devreye girer; ikisini birlikte düşünmek gerekir.

Ödemeyi tamamen iyzico veya PayTR'a devredersem yine de sorumlu muyum?#

Ödemeyi lisanslı bir geçide tamamen devrettiğinizde sorumluluğunuzun büyük kısmı ortadan kalkar, ama tamamen sıfırlanmaz. Kart verisini saklamadığınız için en hafif seviyeye (genellikle SAQ A) düşersiniz; yine de o formu doldurmak, sitenizin temel güvenliğini sağlamak ve geçidin uyum belgelerini takip etmek sizin sorumluluğunuzdadır. Yani "geçit hallediyor, ben hiçbir şey yapmıyorum" doğru değil; ama yükünüz aylarca sürecek bir projeden birkaç saatlik bir işe iner.

Müşterinin kartını "kartı hatırla" özelliği için saklayabilir miyim?#

Kart numarasını ve güvenlik kodunu kendi veritabanınızda saklamak neredeyse her senaryoda kötü bir fikirdir ve CVV'yi saklamak zaten kesinlikle yasaktır. Bunun doğru yolu tokenizasyondur: geçit size kart yerine anlamsız bir token verir, siz de sadece onu ve gösterim için kartın son dört hanesini tutarsınız. Böylece "kartı hatırla" özelliğini, gerçek kart verisini hiç saklamadan sunabilir ve PCI kapsamınızı büyütmezsiniz.

CVV kodunu kısa süreliğine loglasam sorun olur mu?#

Evet, bu doğrudan bir ihlaldir ve sahada en sık rastladığımız hatalardan biridir. Hassas doğrulama verisi (CVV, manyetik şerit izi, PIN) işlem onaylandıktan sonra hiçbir gerekçeyle, ne kadar kısa süreliğine olursa olsun saklanamaz. Hata ayıklama amacıyla tüm istek gövdesini loglayan bir uygulama, farkında olmadan kart verisini diske yazabilir. Bu yüzden loglarınızda kart alanlarını maskelemek ve log dosyalarınızı bu açıdan test etmek şarttır.

Sadece SSL kurmak PCI-DSS için yeterli mi?#

Hayır, SSL/TLS gerekli ama tek başına yeterli değildir. TLS yalnızca veriyi iletim sırasında şifreler; oysa PCI-DSS ağ güvenliği, erişim kontrolü, MFA, loglama, güncel yazılım ve düzenli test gibi bir dizi başka gereksinim de ister. SSL'i uyumun olmazsa olmaz bir parçası olarak görün, ama tamamı olarak değil. Şifreleme temelini derinleştirmek isterseniz SSL sertifikası rehberimiz iyi bir başlangıç noktasıdır.

Küçük bir sitem var, çok az işlem yapıyorum; yine de PCI-DSS'e uymam gerekir mi?#

Evet. PCI-DSS işlem hacminize değil, kart verisine dokunup dokunmadığınıza bakar. İşlem sayınız az olduğu için muhtemelen en düşük denetim seviyesindesiniz (bağımsız denetim yerine öz beyan / SAQ), ama uyum beyanı verme zorunluluğunuz yine de vardır. İşin güzel yanı, düşük işlem hacimli bir sitede ödemeyi geçide devrederek uyumu çok basit tutabilirsiniz; büyük bir güvenlik ekibine ihtiyacınız yoktur.

Kapanış#

PCI-DSS ilk bakışta yüzlerce maddelik, korkutucu bir standart gibi görünür; ama işin sırrı, o maddelerin ne kadarının size uygulanacağını mimarinizle belirlediğinizi fark etmektir. Kart verisini kendi sunucunuzda toplarsanız tüm ağırlık omzunuza biner. Ödemeyi sertifikalı bir geçide devreder, kart verisini hiç saklamaz ve token/3D Secure ile ihtiyaçlarınızı karşılarsanız, sorumluluğunuz temel güvenlik hijyeni ve kısa bir öz değerlendirme anketiyle sınırlı kalır. En güvenli kart verisi, hiç sahip olmadığınız kart verisidir.

Clou.TR olarak bu mimarinin altyapı tarafını sizin için hazır hale getiriyoruz. Türkiye'de barındırılan web hosting ve WordPress hosting paketlerimiz ücretsiz SSL ve güncel yazılımla gelir; SSL çözümlerimiz ödeme akışınızı uçtan uca şifreler, WAF ve DDoS koruma hizmetlerimiz uygulama katmanındaki saldırıları filtreler, otomatik yedekleme ve sunucu yönetimi desteklerimiz de kontrol listesindeki teknik maddeleri sizin adınıza standartlaştırır. Daha fazla kontrol isteyen büyüyen projeler için VDS ve sanal sunucularımız tam erişim ve izolasyon sunar. Siz doğru ödeme geçidini seçip uyum beyanınızı tamamlayın; güvenli, hızlı ve güncel barındırma tarafını bize bırakın.