Kredi Kartı Verisi — DLP ile PCI-DSS Uyumlu Tespit

Kredi kartı verisi tüm sektörlerde en yüksek hassasiyetli veridir. KVKK + PCI-DSS standardı birlikte uygulanır. Tek bir kart numarası sızıntısı bile şirkete 50k+ TL ceza + müşteri tazminat davası getirir.

E-ticaret, abonelik, banka iştirakı, hatta restoran zincirleri kart verisi işler. DLP bu veriyi nasıl yakalar?

Kredi kartı numarası yapısı

Visa/MasterCard/Amex standartları:

• Visa: 13 veya 16 hane, “4” ile başlar
• MasterCard: 16 hane, “51-55” veya “2221-2720” ile başlar
• American Express: 15 hane, “34” veya “37” ile başlar
• Discover: 16 hane, “6011” ile başlar
• Troy (Türk kartları): 16 hane, “9792” ile başlar

Her kart için Luhn algoritması check digit:

1. Sondan başla, çift hanelileri 2 ile çarp (>9 ise rakamları topla)
2. Tüm rakamları topla
3. Toplam mod-10 = 0 ise geçerli kart

Luhn olmadan her 16 hane rastgele kart sanılır — %30+ FP riski.

Tespit yaklaşımı

3 katman:

Katman 1 — Regex (BIN bazlı)

Card brand’a göre ayrı regex:

Visa:        \b4[0-9]{12}(?:[0-9]{3})?\b
MasterCard:  \b(?:5[1-5][0-9]{2}|222[1-9]|...)[0-9]{12}\b
Amex:        \b3[47][0-9]{13}\b
Troy:        \b9792[0-9]{12}\b

Katman 2 — Luhn algoritması

Regex sonrası check digit doğrula. %99+ kesinlik.

Katman 3 — Bağlam

“Kart no:” veya CVC/expiry pattern yakını varsa güven artar:

• “Kart no: 4111 … CVC: 123” → kesin kart bağlamı
• Tek başına 16 hane → orta güven

PCI-DSS maskeleme standardı

PCI-DSS Requirement 3.4: “Card numbers stored or displayed MUST be masked except for first 6 and last 4 digits.”

Ham:    4111 2222 3333 4444
Mask:   4111 22** **** 4444

İlk 6 hane (BIN — banka tanıma) + son 4 hane görünür. Orta 6 hane maskeli. Bu maskeleme PCI-DSS uyum için zorunlu.

DLP’nin tüm log/audit’te bu standardı uygulaması gerekir. Aksi durumda PCI-DSS uyumsuz işaretlenir.

Sızıntı senaryoları

Senaryo 1 — E-ticaret order export Sipariş raporu Excel’e export edildi, içinde 200 müşteri kart numarası. Müşteri tedariği yan firmaya e-postayla gönderildi.

Senaryo 2 — Müşteri hizmetleri kayıt CS temsilcisi telefonda müşteri kart bilgisi aldı, CRM’e yazdı. CRM şifresiz çıkış log’larında plain text yazılı.

Senaryo 3 — Test ortamı Geliştirici production veritabanı snapshot’ını test sunucuya kopyaladı. İçinde encrypted kart numaraları, ama test ortamı şifre yönetimi zayıf.

Senaryo 4 — Phishing yanıtı Sahte müşteri sayfasından “kart numaranızı gönderir misiniz” maili gelen müşteri yanıt verdi. CSR çalışanı bunu işledi, başka adrese forward etti.

DLP politikası örnekleri

P1 — Kart numarası sıfır tolerans
  Match: credit_card_count >= 1
  Action: block ANY channel
  Reason: "PCI-DSS — kart verisi şifresiz dışarı çıkamaz"

P2 — Test ortamı veri block
  Match: source contains "production_db" AND
         dest contains "staging|test|dev"
  Action: block + admin alert (DPA ihlali şüphesi)

P3 — E-posta kart numarası encryption
  Match: credit_card_count >= 1 AND channel == "email"
  Action: auto-encrypt (S/MIME) + audit

P4 — CSR ekranında kart watermark
  Match: active_window contains "CRM" AND credit_card displayed
  Action: ekran watermark "Kullanıcı + zaman" zorunlu

PCI-DSS uyum + DLP

PCI-DSS uyum gerektiren şirketler için DLP iki rol üstlenir:

Rol 1 — Network segmentation enforcement

PCI ortamı (CDE — Cardholder Data Environment) izole olmalı. DLP kart verisinin segment dışına çıkışını engeller.

Rol 2 — Audit log + denetim kanıt

QSA (PCI assessor) denetimde “kart verisi nereye gitti” sorar. DLP audit log’u bu sorunun cevabı.

PCI olmayan şirket — yine de DLP gerek

E-ticaret olmasanız bile, müşteri kart verisi tutuyorsanız:

• Otel ön ödeme formları (kağıt + sistem)
• Restoran rezervasyon (POS sistem)
• Sağlık kuruluşu peşin ödeme
• Hukuki danışmanlık

Bu sektörlerde kart verisi tutmak zaten risktir — mümkünse hiç tutmayın (3rd party payment processor kullanın). Tutuyorsanız DLP şart.

VeritaDLP kart yaklaşımı

3 katmanlı tespit:

1. Brand-aware regex (Visa/MC/Amex/Troy ayrı pattern)
2. Luhn algoritması doğrulama
3. Bağlam (CVC + expiry pattern proximity)

Mask: PCI-DSS standart 4111 22** **** 4444 (ilk 6 + son 4).

Default politika: sıfır tolerans — kart numarası tespit edilirse her zaman block + audit. Tenant Owner explicit olarak gevşetebilir (örn. PCI sertifikalı süreç için).

Troy kartları özel

Türkiye’nin yerli kart sistemi Troy:

• Prefix: 9792
• 16 hane
• Luhn geçerli

Yabancı DLP’lerin çoğu Troy’u tanımaz, FP veya FN üretir. Yerli DLP özel destek sağlar.

E-ticaret PCI senaryosu

E-ticaret sitenizde müşteri checkout sayfası kart numarası giriyor. DLP nereye girer?

Hayır, ön plan değil — kart kullanıcının browser’ından direkt ödeme gateway’ine (Stripe, iyzico, vs.) iletildiği için sunucunuza ulaşmaz. Bu durumda DLP’ye gerek yok.

Evet, arka plan — sipariş kayıtlarınızda kart maskeli ise, log dosyalarında, e-posta arşivinde kontrol gerek. DLP burada devreye girer.

Pratik test

3 test:

1. Fake card test verisi (4111111111111111 Visa test): Excel’e yaz, e-posta at. DLP block etmeli (Luhn geçer).
2. Sipariş Excel: 10 fake müşteri kartı, USB. Block.
3. CRM screenshot: tek kart numarası ekranda görünür, PrintScreen. Block.

Test verileri fake olmalı — gerçek kartla test yapmayın.

Sonuç

Kredi kartı verisi sıfır tolerans gerektiren PII kategorisi. PCI-DSS zorunlu maskeleme (ilk 6 + son 4) + Luhn doğrulama + sıfır tolerans politika kombinasyonu uyum için yeterli. Türk Troy kartları için yerli DLP avantajı net.

VeritaDLP’de kart politikası “sıfır tolerans” default ile gelir, Owner explicit gevşetme yapabilir.