DLP Politikası Nasıl Yazılır? 5 Hazır Şablon

Bir DLP yazılımı satın aldınız, agent’lar 200 PC’ye kuruldu. Şimdi ne yapacaksınız? Politika yazmak. Politika bir cümle yapısı:

“X verisi Y kanalından Z koşulu ile geçebilir / geçemez.”

Bu yazıda politika yapısını + 5 hazır KOBİ şablonu sunuyoruz.

Politika 4 unsurdan oluşur

1. Eşleşme kriteri (Match)

Politika hangi olayda devreye girer?

• Veri tipi (TC, IBAN, kart, vs.)
• Veri miktarı (örn. 10+ TC kimlik)
• Kanal (USB, e-posta, print, klipboard)
• Kaynak (kullanıcı rolü, departman)
• Hedef (domain, IP)
• Zaman (mesai içi/dışı)

2. Risk eşiği

Risk skoru hangi seviyede hangi eylem tetiklenir? Tipik üç eşik:

• 0-39: Düşük → log
• 40-69: Orta → uyarı
• 70-100: Yüksek → engelle

3. Eylem (Action)

Eylem	Davranış
allow	İşlem geçer, hiçbir şey yapılmaz
monitor	Sessizce loglanır, kullanıcı bilmez
warn	Kullanıcıya uyarı + gerekçe iste
block	İşlem durdurulur, hata mesajı

4. Bildirim + audit

• Kim bildirim alır (Owner, Admin)
• Webhook gider mi (Slack, SIEM)
• Audit log’a yazım detayı

Politika yazma kuralları

Kural 1 — Spesifik ol. “Tüm dosyalar engellensin” yerine “10+ TC kimlik içeren dosyalar USB’ye engellensin”.

Kural 2 — Risk eşiği koy. Sıfır tolerans politikası ofiste kaos yaratır. Skor 70+ block, 40-69 warn, altı monitor.

Kural 3 — Kademeli rollout. Yeni politika önce monitor mode’da 30 gün → warn 30 gün → block. Mevcut sistemde bu kademe otomatik yapılabilir.

Kural 4 — Departman bazlı. Pazarlama ekibi ile muhasebe ekibi aynı politikayla yönetilmez. Aktif Directory grupları ile bağlayın.

Kural 5 — Justification iste. Kullanıcı engellendiğinde “neden yapmak istiyorum” 20+ karakter gerekçe yazsın. Audit log’a düşer, denetimde işe yarar.

5 Hazır Şablon

Şablon 1 — KVKK Başlangıç (her şirket için)

P1 — Toplu TC kimlik USB engelleme
  Match: tc_kimlik_count >= 10 AND channel == "usb"
  Risk: skor 60+ block, 30-59 warn
  Justification: zorunlu (min 20 char)
  Audit: webhook (Slack, SIEM)

P2 — IBAN toplu e-posta dış domain
  Match: iban_count >= 5 AND channel == "email" AND
         dest_domain NOT IN tenant_allowlist
  Risk: 50+ block
  Audit: standart

P3 — Kredi kartı her kanal
  Match: credit_card_count >= 1
  Risk: 80+ block (her zaman), 50-79 warn
  Justification: zorunlu

P4 — Sağlık verisi (özel kategori) — block
  Match: kvkk_sensitive_keywords (sağlık, din, etnik, biyometrik)
  Risk: 70+ block (sıfır tolerans)
  Audit: webhook + e-posta DPO'ya

Şablon 2 — Finans / Muhasebe Ofisi

P1 — Müşteri TC + IBAN birlikte transfer
  Match: tc_count + iban_count >= 5 AND channel IN ["usb", "email", "print"]
  Risk: 70+ block
  Audit: yıllık denetim için tutulur

P2 — Vergi numarası (VKN) toplu listeleme
  Match: vkn_count >= 20
  Risk: 50+ warn (muhasebeci işlem yapıyor olabilir)
  Justification: zorunlu

P3 — Excel makro içeren dosya dışarı
  Match: file_extension IN [".xlsm", ".xlsb"] AND channel == "email"
  Risk: 60+ warn
  Audit: webhook (siber güvenlik)

P4 — Banka API key sızıntısı
  Match: regex r"sk_live_\w{16,}"
  Risk: 90+ block (her zaman)
  Audit: kritik, anlık bildirim

Şablon 3 — E-ticaret

P1 — Müşteri kart numarası (PCI-DSS)
  Match: credit_card_count >= 1 AND channel NOT IN ["pci_zone"]
  Risk: 80+ block
  Audit: PCI-DSS denetim için sakla 7 yıl

P2 — Sipariş listesi USB
  Match: keyword "siparis" OR "order" AND channel == "usb"
  Risk: 50+ warn
  Justification: zorunlu

P3 — Toplu müşteri e-postası (5000+)
  Match: email_count >= 5000 AND channel == "email"
  Risk: 60+ block (mass mail değil kaçak şüphesi)
  Audit: pazarlama ekibi onayı gerekli

Şablon 4 — Sağlık Sektörü

P1 — Hasta TC + sağlık raporu PDF
  Match: tc_count >= 1 AND file_type == "pdf" AND
         keyword_match("sağlık", "tanı", "icd", "ilaç")
  Risk: 70+ block
  Audit: 10 yıl saklama (Sağlık Bakanlığı kuralı)

P2 — Reçete PDF WhatsApp/Mobil
  Match: keyword "reçete" AND file_type == "pdf" AND
         dest_app IN ["whatsapp.exe", "telegram.exe"]
  Risk: 90+ block (sıfır tolerans)
  Audit: hasta gizliliği denetimi

P3 — Personel sağlık raporu paylaşım
  Match: keyword_match("rapor", "iş göremezlik") AND
         user_role != "IK_yonetici"
  Risk: 60+ block
  Audit: standart

Şablon 5 — Hukuk Bürosu

P1 — Dosya numarası + müvekkil adı birlikte
  Match: regex r"\d{4}/\d{1,5}" AND keyword "müvekkil"
  Risk: 60+ warn
  Justification: zorunlu (dava işlemi olabilir)

P2 — Mahkeme yazısı dışarı (case sensitive)
  Match: keyword_match("mahkeme", "kararı", "celpname") AND
         channel IN ["email", "usb", "print"]
  Risk: 60+ block (mahkeme dosyası gizli)
  Audit: avukatlık etik denetim

P3 — Karşı taraf bilgisi sızıntı
  Match: dest_domain == karşı_taraf_av_domain
  Risk: 80+ block (taraf değişimi engelle)
  Audit: kritik

Politika yazma checklist’i

• Eşleşme kriteri spesifik mi (overlap olmayacak şekilde)
• Risk eşiği 3 seviye (monitor/warn/block) tanımlı
• Kademeli rollout 90 gün (monitor → warn → block)
• Departman/rol bazlı bağlı
• Justification gerekiyor mu (kritik politikalarda evet)
• Audit log’a webhook bağlı
• Yıllık inceleme tarihi belirli (her politika 12 aydan eski olmasın)

Yaygın 3 hata

Hata 1 — Çok geniş eşleşme. “Tüm Excel dosyaları” deyince muhasebeci işini yapamaz, IT yöneticisi günde 50 destek bileti alır.

Hata 2 — Sadece block. Monitor + warn aşamalarını atlamak rollout şokuna yol açar. 3 ay kademeli geçiş şart.

Hata 3 — Politika yıllarca güncellenmiyor. Şirket büyüyor, yeni sistemler ekleniyor, eski politika güncel değil. Her 12 ayda 1 review yapılmalı.

Sonuç

DLP politikası yazılım değil, organizasyon kararıdır. 5 hazır şablonu kendi şirketinize uyarlayın, departman + rol bazlı incelte, kademeli devreye alın.

VeritaDLP yapısında bu 5 şablon hazır template olarak gelir — tek tıkla yüklersiniz, sonra ince ayar yaparsınız. Yeni bir politika yazımı 5-10 dakika alır.