DLP Nasıl Çalışır? PII Tespitinden Engellemeye Pipeline
Bir DLP yazılımının kararı nasıl verdiği — regex, NER, sözlük, risk skoru ve enforcement zinciri adım adım açıklanır.
Yazar: Mehmet Özbakır
“DLP engelliyor” derken arka planda 5 aşamalı bir karar zinciri çalışır. Bu yazıda VeritaDLP pipeline’ı üzerinden bir DLP yazılımının “olay algılayıp engelleme” sürecini somut olarak gösteriyoruz.
Aşama 1 — Olay yakalama (Capture)
Endpoint agent her saniye olası veri çıkış kanallarını dinler:
- USB cihaz takıldı mı?
- Outlook gönder butonuna basıldı mı?
- Yazıcı kuyruğuna iş eklendi mi?
- Print Screen tuşuna basıldı mı?
- Kopyala-yapıştır işlemi yapıldı mı?
- Browser’da dosya upload başladı mı?
Olay tespit edildiğinde agent dosya/içerik referansını alır, RAM’de tarama için pipeline’a yönlendirir.
Önemli not: ham içerik hiçbir zaman diske yazılmaz. RAM’de işlenir, işlem bitince zeroize edilir (bytearray overwrite). Bu KVKK Madde 4 “veri minimumda” prensibine uyum sağlar.
Aşama 2 — Tarama (Detection) — 3 katman
Katman 2.1 — Regex pass
Hızlı ve %99+ doğru. Şu pattern’leri yakalar:
- TC kimlik numarası (11 hane + mod-10 check digit doğrulama)
- VKN (10 hane)
- Türkiye IBAN (TR + 24 hane + banka kodu)
- Kredi kartı (Luhn algoritması ile)
- Türkiye telefon (0 5XX XXX XX XX)
- Plaka (XX YYY ZZ, XX YYYY)
- E-posta adresleri
Çıktı: tespit edilen PII listesi + konum (offset).
Katman 2.2 — NER pass (Türkçe BERT)
Regex’in yakalayamadığı serbest metin entityleri için:
- Ad/soyad
- Adres (sokak, mahalle, ilçe)
- Organizasyon ismi
- Yer/şehir
Türkçe BERT modeli (savasy/bert-base-turkish-ner-cased veya benzeri)
~%90 F1 skor ile çalışır.
Katman 2.3 — Sözlük pass (safety net)
NER’in atladıkları için:
- TÜİK en yaygın 1000 ad + 1000 soyad
- 81 il + ~970 ilçe + yaygın mahalle/sokak listeleri
- Tenant özel sözlük (proje kodları, müşteri isimleri)
Katman 2.4 — Safety net check
Tanımsız büyük harfli kelime oranı %10’u aşarsa (yabancı dil, exotic
format senaryosu), özet [icerik_analiz_edilemedi] ile değiştirilir
— ham metin yine saklanmaz.
Aşama 3 — Maskeleme (Masking)
Tespit edilen her PII, deterministic mask kuralları ile değiştirilir:
| Ham | Mask |
|---|---|
| TC: 12345678901 | TC: 123******01 |
| IBAN: TR33 0006 1005 1978 6457 8413 26 | TR33 0006 **** **** **** **** 26 |
| Kart: 4111 2222 3333 4444 | 4111 22** **** 4444 (PCI-DSS) |
| Telefon: 0532 555 33 22 | 0532 *** ** 22 |
| Mehmet Özbakır | Mehmet Ö*****r |
Deterministic özellik: aynı TC her seferinde aynı mask sonuç verir. Bu sayede forensic analist iki ayrı olayda aynı kişinin verisi olduğunu anlayabilir. Kimlik kullanıcı seviyesinde takip edilebilir ama detay maskelidir.
Mask sonucu en fazla 300 karakter içerik özeti üretilir.
Aşama 4 — Risk skorlama
Tespit edilen PII’ler ve bağlam bilgileri risk skoru hesaplanır (0-100):
| Faktör | Ağırlık |
|---|---|
| Kritik PII sayısı (TC, IBAN, kart) | +5 / her tespit |
| Kanal hassasiyeti (USB > Print > Email) | +5-20 |
| Hedef domain (kişisel webmail) | +15 |
| Mesai dışı saat | +10 |
| Anomaly: yeni hedef adres | +20 |
| Kullanıcı geçmişi (offboarding flag) | +15 |
| Dosya boyut (büyük transfer) | +5 |
Toplam 0-100 arasına normalize edilir.
Aşama 5 — Politika değerlendirme + karar
Tenant’ın aktif politikaları sırayla denenir. Her politika:
- Eşleşme koşulu: hangi PII tipi + hangi kanal + hangi rol
- Eylem: allow / monitor / warn / block
- Risk eşiği: skor X üzeri ise eylem değişir
Örnek politika:
P1 — Müşteri TC USB engelleme
Koşul: tc_kimlik_count >= 10 AND channel == "usb"
Risk eşiği: 60
Eylem: block (risk >= 60), warn (40-59), monitor (\< 40)
İlk eşleşen politikaya göre karar verilir.
Aşama 6 — Enforcement
Karara göre aksiyon:
Allow: işlem normalde devam eder. Audit log’a yazılır.
Monitor: kullanıcı görmez. Olay arka planda loglanır.
Warn: kullanıcıya toast bildirim çıkar — “Bu dosyada 47 TC kimlik var. Devam etmek istiyor musunuz? Gerekçenizi yazın.” Kullanıcı 20+ karakter gerekçe yazarsa devam eder; eylem audit log’a “justification” ile yazılır.
Block: işlem durdurulur. USB transferi iptal, Outlook gönderim engellenir, yazıcı kuyruğu silinir. Kullanıcıya kırmızı toast: “Bu işlem KVKK politikası gereği engellendi.” Olay audit log’a yazılır, admin paneline anlık bildirim gider.
Aşama 7 — Audit + Cloud sync
Her olay:
- Agent local SQLite’a yazılır (DPAPI şifreli)
- mTLS ile cloud’a gönderilir (gRPC over TLS 1.3)
- ClickHouse’a event olarak insert edilir (sıkıştırılmış)
- Audit log’a Postgres’e yazılır (immutable trigger)
- Webhook varsa SIEM/Slack’e iletilir
- Anlık bildirim Dashboard’da SSE ile push edilir
Toplam pipeline süresi: 50-200 ms (USB takılmadan kararın verilmesine).
KVKK uyum garantileri
Pipeline boyunca:
- ✗ Ham metin diske yazılmaz
- ✗ Ham metin cloud’a gönderilmez
- ✓ Sadece masked özet (≤300 char) cloud’a iletilir
- ✓ Audit log’da PII içerik yok, sadece sayım + risk skoru
- ✓ Memory hijyeni: ham metin işlem sonu zeroize
Sonuç
Bir DLP yazılımı “tek tıkla” engelleme değildir — 7 aşamalı bir karar zinciridir. Her aşama bir kalite seviyesi ekler: regex hız, NER bağlam, sözlük güvenlik ağı, risk skor nuans, politika esneklik, enforcement etkili eylem, audit yasal kanıt.
VeritaDLP bu pipeline’ı Rust agent + Python cloud kombinasyonu ile gerçekler — agent 30 MB RAM, pipeline 100 ms ortalama.
Etiketler: #dlp #pii-tespit #pipeline #teknik