Ana içeriğe geç

Bölüm 5 · IT yöneticisi + Analyst · 15 dk

Olay yönetimi — neyi nasıl inceler, ne karar verirsin?

Politika tetiklendiğinde bir olay oluşur. Bu bölüm olay panelini nasıl kullanacağınızı, hangi soruyu sormanız gerektiğini, gerekçe (justification) akışını ve KVKK uyumlu denetim raporu çıkarmayı anlatır.

Olay nedir? Ne içerir?

Bir olay (event) politika tetiklendiğinde otomatik oluşturulan kayıttır. Saklanan bilgiler:

  • Ne zaman: Olayın tam zaman damgası (UTC + tenant timezone)
  • Kim: Hangi kullanıcı (AD username + email)
  • Nerede: Hangi bilgisayar (hostname + IP)
  • Ne: Dosya adı, boyut, MIME tipi, SHA256 hash
  • Hangi kanal: USB / E-posta / Bulut / Yazıcı / Ekran görüntüsü
  • Hedef: USB cihaz adı, alıcı email adresi, bulut servisi adı
  • Tespit edilen PII: "TC: 47, IBAN: 12, Telefon: 28" (sayım, maskeli özet)
  • Risk skoru: 0-100 arası, otomatik hesaplanır
  • Karar: ALLOWED / MONITORED / WARNED / BLOCKED
  • Politika referansı: Hangi politika versiyonu tetikledi
⚠️ Dosyanın kendisi saklanmaz
Ham dosya içeriği asla bulut sunucumuza inmez. Sadece metadata + maskeli özet saklanır. Bu KVKK mimari kararı (Bölüm 1 § "Ne YAPMAZ" hatırlayın).

Olay panelini kullanma

1

Olaylar sayfasına gidin

Sol menü → Olaylar. Varsayılan görünüm: son 24 saatin tüm olayları, en yeniler üstte. Sayfanın üstünde özet kartlar:

  • Bugün toplam olay sayısı
  • Bugün BLOCKED (engellenen)
  • Yüksek riskli (skor > 80)
  • Bekleyen gerekçe (justification) talepleri
2

Filtreleyin — bulmak istediğinizi daraltın

Sağ üstte filtre paneli:

  • Tarih aralığı: Son 24 saat / 7 gün / 30 gün / Özel aralık
  • Karar: BLOCKED / WARNED / MONITORED / ALLOWED
  • Kanal: USB, E-posta, Bulut, vs.
  • Kullanıcı: Belirli çalışan veya departman (AD grubu)
  • Politika: Belirli politika tarafından tetiklenenler
  • Risk skoru: Minimum eşik (örn. 70+)

Filtreler URL'e yansır — sıkça kullandığınız sorguları yer imine ekleyin.

3

Tek olay detayı

Bir satıra tıklayın → sağdan slide-out panel açılır:

  • Üst: Olay özeti, kim/nerede/ne/karar
  • Orta: Tespit edilen PII'lar (maskeli görüntüleme: TC: 123******01)
  • İçerik özeti (max 300 karakter): "Mehmet Ö*****r 0532 *** ** 22 numarasından aradı..."
  • Politika: Hangi politika versiyonu, link ile detaya
  • İlgili olaylar: Aynı kullanıcının son 7 gün benzer olayları
  • Aksiyonlar: "Yorum ekle", "Eskale et", "Politika ayarla"

Hangi soruları sorarsınız — analizci bakış açısı

Bir olayı incelerken kendinize 5 soru sorun:

1

Bu olay beklenen mi?

Kullanıcının iş tanımına uyuyor mu? Pazarlama'daki Ayşe müşteri listesi gönderdi — bu işi gereği yaptığı bir şey. Aynı işi gece 02:00'de yapıyorsa anormal.

2

Risk skoru gerçekten doğru mu?

Risk skoru 95 ama dosya adına bakınca "test-verisi.csv" — synthetic veri olabilir. Tersine: risk 30 ama 50 TC ve IBAN var, çıkış USB'ye → daha kritik. Otomatik skoru bağlam ile birleştirin.

3

Tekrar eden bir desen mi?

Aynı kullanıcı son 7 gün 12 kez aynı politikayı tetikledi mi? Bu yapısal bir şey — politikayı ince ayarlamak veya kullanıcıyla görüşmek gerekebilir.

4

Hangi kanal en kritik?

Aynı dosya hem e-posta hem USB üzerinden denenmişse: kasıtlı kaçırma girişimi. Tek seferde başarısız olunca farklı kanal denemiş — yüksek risk işareti.

5

Hukuki süreç başlamalı mı?

Sızıntı kanıtlanmışsa: olayı KVKK Kurulu'na 72 saat içinde bildirme yükümlülüğü doğabilir (Madde 12(5)). Bu kararı DPO + Owner birlikte verir, gerekirse hukuki danışman.

Forensic timeline (zaman çizelgesi)

Bir kullanıcının veya bilgisayarın belirli zaman aralığında tüm olaylarını sıralı görmek için Forensic sayfası:

  1. Sol menü → Forensic
  2. "Bilgisayar" veya "Kullanıcı" seç
  3. Tarih aralığı belirt
  4. Sistem sıralı bir timeline gösterir: hangi dakikada hangi aktivite
ℹ️ Forensic ne için faydalı?
Bir çalışan ayrılırken son haftası ne yaptı? Şüpheli aktivite tespit ettiniz, o gün başka ne yapmış? Mahkemede delil olarak kullanılabilecek formatta zaman çizelgesi çıkarır.

Gerekçe (justification) akışı

Bir politika "Warn" modunda tetiklendiğinde kullanıcı bir gerekçe yazar. Bu gerekçe Süpervisor onayı ister:

1

Çalışan tarafı — gerekçe yazma

Çalışanın bilgisayarında uyarı kutusu açılır: "Bu dosya 47 TC içeriyor. Devam etmek için iş gerekçesi yazın:". Çalışan en az 20 karakter yazar. "Gönder" tıklar, işlem askıya alınır, bekler.

2

Süpervisor tarafı — Bekleyen Onaylar

Dashboard → Bekleyen Onaylar sayfası (sol menüde rakam görünür, bekleyen sayısı). Her satırda:

  • Kim talep etti
  • Hangi dosya, hangi kanaldan
  • Tespit edilen PII özeti
  • Yazılan gerekçe (tam metin)
  • "Onayla" / "Reddet" / "Detayı gör"
3

Karar verin

  • Onayla: Çalışana bildirim gider ("Onaylandı, devam edebilirsiniz"), işlem 5 dakika içinde tekrarlanırsa geçer. Audit log: justification.approved.
  • Reddet: Çalışana bildirim ("Reddedildi"), işlem iptal edilir. Reddet sebebi yazılırsa şeffaflık artar. Audit log: justification.rejected.
  • Süre dolarsa (24 saat): otomatik "expired" olur, çalışana "süre doldu, tekrar talep" bildirimi gider.
⚠️ Onayların gecikmesi iş aksamasıdır
Çalışan acil bir dosya gönderecek ama Warn tetiklendi ve süpervisor 2 saat sonra gördü → çalışan beklemek zorunda. Bildirimler için WhatsApp/SMS/Slack entegrasyonu önerilir (Ayarlar → Bildirimler).

Olay raporları (yönetici brifingi için)

Yönetim brifingi veya KVKK denetimi için hazır raporlar:

  • Haftalık özet: "Bu hafta 248 olay, 12 block, 3 yüksek risk"
  • Kullanıcı sıralaması: "Bu ay en çok politika tetikleyen 10 kullanıcı"
  • Politika etkinlik: "Hangi politikalar en sık tetikleniyor"
  • Kanal dağılımı: "USB %42, E-posta %35, Bulut %18, ..."
  • Risk trendi: "Son 30 günde risk skoru ortalaması artıyor mu?"

Dashboard → Raporlar menüsü → Rapor tipi seçin → PDF veya Excel olarak indirin. Her ay otomatik mail olarak da gelebilir (Ayarlar → Raporlama).

Olay eskalasyon zinciri (sessiz saatler için)

Yüksek riskli olaylar gece geldiğinde DPO'yu uyandırmak istemezsiniz, ama acil olanları kaçırmak da olmaz. Eskalasyon ayarı:

  1. İlk önce IT yöneticisine bildirim (1 dakika içinde)
  2. 15 dakika içinde okumadıysa Owner'a eskale et
  3. 1 saat içinde okumadıysa: WhatsApp + SMS açık çağrı

Sessiz saatler (gece 22:00-08:00) ayarlanırsa sadece "kritik" olaylar bildirilir, diğerleri ertesi gün özet olarak.

Olay arşivleme ve retention

Olay log'u 90 gün aktif saklanır (KVKK Madde 7 — minimum veri). 90 günden eski olaylar otomatik arşive iner (sadece metadata, daha az detay). Audit log ise 2 yıl saklanır (KVKK denetim zorunluluğu).

Sık sorulan sorular

Bir olayı silmek mümkün mü?

Hayır — olay kayıtları immutable (silinemez). Audit log mimarisinin gereği. Yanlış oluşturulmuş bir olay varsa "yorum ekle" ile not düşebilirsiniz, ama silemezsiniz. Bu KVKK denetiminde önemli.

False positive olduğunu nasıl işaretlerim?

Olayın detay panelinde "Bunu False Positive olarak işaretle" butonu var. Olay silinmez ama "ignored" durumuna geçer. Bu bilgi politikayı iyileştirmek için ML pipeline'ına gider (gelecek — Faz 9).

Çalışan benden 'olay nedir' diye sorarsa, ne göstereceğim?

Çalışana kendi olaylarını görme hakkı verebilirsiniz (KVKK Madde 11 — kişisel veriye erişim). Bu seçenek varsayılan kapalı — Ayarlar → Çalışan Self-Service. Açarsanız çalışan "Beni İlgilendiren Olaylar" sayfasından kendi olaylarını görür (başkalarınınkini değil).

Olay sayısı çok fazla — analiz yapamıyorum

Çok sayıda olay tipik olarak "Monitor modunda politika çok agresif" anlamına gelir. Eşiği yükseltin (5 TC yerine 20 TC), veya sadece belirli risk skorunun üstündekileri bildirin. Hedef: günlük olay sayısı 10-50 arası — her birine 1-2 dakika ayırabileceğiniz seviye.

Olay paneli bir SIEM'e gönderilebilir mi?

Evet — Webhook entegrasyonu ile (Bölüm 10 → Teknik referans). Her olay JSON olarak sizin endpoint'inize push edilir, Splunk/Graylog/ELK gibi sistemlere yönlendirebilirsiniz.

Vaka analizleri — gerçek senaryolar

Vaka 1: Pazarlama müdürü müşteri listesi sızıntısı

⚠️ Senaryo
Cuma akşamı 18:30. Yüksek risk bildirimi geldi: "Pazarlama Müdürü Ahmet K. → müşteri TC + IBAN listesi (2500 satır) → kişisel Gmail. Risk skoru: 96."
1

İlk inceleme (5 dakika)

Olay detayına bakıyorsunuz:

  • Dosya: musteri-2024-q4.xlsx, 1.2 MB, SHA256: a1b2c3...
  • Tespit: 2500 TC + 2500 IBAN + 2500 telefon
  • Hedef: ahmet.kilic.personal@gmail.com (kişisel email)
  • Politika: "Müşteri DB Listesi" — Block
  • Sonuç: BLOCKED (sistem engelledi)
2

Bağlam kontrolü

Forensic timeline → Ahmet'in son 30 günü:

  • Geçen hafta: aynı dosyaya 5 kez erişim (normal)
  • Dün: USB'ye kopyalama denemesi (BLOCKED, "yedek almak istedim")
  • Bugün 17:00: Pazarlama klasörünü kişisel cloud'a senkronize etme denemesi (BLOCKED)
  • Bugün 18:30: kişisel email'e gönderme (BLOCKED — şimdiki olay)

3 farklı kanaldan dışa çıkarma girişimi — desen var. Politika düzgün korudu ama niyet açık.

3

Karar verme — eskalasyon

İçeride değerlendirme:

  • İK ile konuşma — "Ahmet'in işten ayrılma planı var mı?" sorgu
  • İK: "Şubat'ta istifa ediyor, henüz duyurulmadı"
  • Şirket sahibi DPO + hukuki danışman ile durum değerlendirir
4

Hukuki adımlar

Avukat önerisi:

  1. VeritaDLP audit log + olay log'u ekran kayıt + PDF rapor
  2. Bilgisayarı geçici dondur (forensic image)
  3. İK iş akdini feshetme prosedürüne başla (Türk İş Kanunu Madde 25 — haklı sebep)
  4. Müvekkil bilgilerine dair gizlilik yükümlülüğü hatırlatma — yazılı
  5. Gerekirse Cumhuriyet Savcılığı'na şikayet (TCK Madde 136 — Kişisel verileri hukuka aykırı verme)
5

Sonradan değerlendirme

Politika başarı analizi:

  • Politika 3 farklı kanaldan saldırıyı engelledi — başarılı
  • Risk skoru 96 doğru: TC + IBAN birlikte = yüksek
  • Önceden tespit olabilir miydi? — desen 3 hafta önceden başlamış (USB denemeleri). Trend analizi yapan ML alarmı olsa daha erken yakalanırdı (Faz 9'da).

Vaka 2: Yeni çalışan eğitim eksikliği (false positive)

ℹ️ Senaryo
Yeni başlayan asistan Selin Y. ilk haftası boyunca 47 olay tetikledi. IT alarm verdi: "Yeni çalışan toplu sızıntı yapıyor mu?"
1

Detaylı inceleme

Olayların özelliklerine bakıyorsunuz:

  • Tetiklediği politikalar: "Müşteri TC Listesi", "Müşteri IBAN"
  • Kanallar: 100% e-posta (USB / bulut yok)
  • Hedefler: hepsi @firma.local domain (iç email)
  • Saatler: 09:00-18:00 arasında, mesai içinde
  • Dosyalar: Excel — fatura, sipariş, müşteri kayıtları

Aslında işini yapıyor — siparişleri muhasebeye e-mail ile iletmek. "Müşteri TC Listesi" politikası 5+ TC için Block — bu çalışanın günlük 30 müşteri kaydı işlemesi var, sürekli tetikleniyor.

2

Politika ayarlaması

İki seçenek:

  • Eşik artır: 5 TC yerine 50 TC. Selin'in tipik gönderimi 30 müşteri, artık tetiklenmez. Risk: gerçek sızıntı 49 TC ile yapılırsa kaçırılır.
  • Aynı domain hariç tut: @firma.local hedefli e-postalar Block yerine Monitor. Sadece dış email'ler engellenir. Bu daha mantıklı.

Tercih: 2. seçenek. Politika güncelleyin, 1 hafta sonra Selin'in olay sayısı %95 azalmalı.

3

Çalışan eğitimi

Selin'le 15 dakikalık görüşme:

  • "VeritaDLP nedir, ne yapar?" (Bölüm 1)
  • "Müşteri verisi göndereken nelere dikkat etmeli?" (KVKK 5 ilke)
  • "Politika tetiklenirse ne yap?" (gerekçe yazma)

Çalışan ekibine "policy etkinleştirildi, yeni başlayanlar 1 hafta eğitim alır" diye yarım saatlik onboarding seansı ekleyin.

Vaka 3: Çalışan ayrılış protokolü

ℹ️ Senaryo
Satış müdürü Hasan D. istifa etti, son haftası. İK + IT alarmda — geçmiş 30 gün davranış inceleme + iade protokolü başlatılacak.
1

Forensic timeline çek

Dashboard → Forensic → "Kullanıcı: Hasan D." → son 30 gün:

  • USB transfer sayısı: 47 (önceki ortalama 5/ay — anormal)
  • Engellenen: 12 (mostly müşteri listesi)
  • Yazılan gerekçeler: "kişisel proje" / "yedek" / "müşteri dosyaları"
  • Bulut sync girişimleri: 3 farklı klasör (BLOCKED hepsi)
2

Audit log incele

Olay log'undan ötesi — Hasan ne yaptı:

  • Politika görüntüleme: 8 kez (hangi kuralın engelleyeceğini araştırmış olabilir)
  • Dashboard'a giriş: anormal saatlerde (gece 23:00, hafta sonu)
  • Kendi olay listesini export ediyor: 3 kez (KVKK Madde 11 hakkı kullanımı)
3

Önlem alma — son hafta

  1. Hasan'ın role'unu "Auditor"a düşür (geçmişi görür ama değiştiremez)
  2. Politika ayarı: Hasan için "Tüm kanallar Block + audit log every action"
  3. Uzaktan destek yetkisi kaldır
  4. API key'leri varsa iptal
  5. Dashboard'a kendi laptop'undan girişe IP whitelist (sadece ofis IP)
4

Çıkış gününde

  1. Dashboard → Kullanıcılar → Hasan → "Suspended"
  2. İade edilen laptop'tan agent'ı revoke + decommission
  3. Forensic raporu PDF olarak arşive — sonraki 5 yıl saklanır (avukatlık kanunu / iş kanunu zorunluluk)
  4. 30 gün cooling-off, sonra anonymize
5

Sonradan değerlendirme

Hasan gerçek sızıntı yapmamış (tüm denemeler BLOCKED), ama davranış desenleri sızıntı niyetini gösteriyor. Veriler güvende. Ana kazanım: DLP olmadan bu davranış hiç görünmezdi.

Rapor oluşturma — yönetici brifingi

Aylık özet raporu

Dashboard → Raporlar → "Aylık Özet Raporu". Otomatik üretilen 1 sayfalık özet:

  • Olay sayısı: Bu ay 1247, geçen ay 1156 (+8%)
  • Engellenen: 89 (geçen ay 72)
  • En çok tetiklenen politikalar: top 5
  • En çok olay yaratan kullanıcılar: top 10 (departman + sayı)
  • Kanal dağılımı: USB %42, Email %35, Bulut %18, Yazıcı %4, Screenshot %1
  • Yüksek risk olaylar: sayım + örnek 3 tanesi (gerekçeli özet)
  • SLA uyum: Yüksek riskli olaylar ortalama 8 dakikada incelendi

Kullanıcı bazlı rapor (denetim için)

KVKK Kurulu denetiminde "Kullanıcı X'in geçen yıl tüm DLP aktivitesi" istenirse:

  1. Raporlar → "Kullanıcı Detay Raporu"
  2. Kullanıcı + tarih aralığı seç
  3. PDF üret: tüm olayları + audit aksiyonları + politika değişiklikleri
  4. İmzalı PDF → KVKK Kurulu'na sun

Politika etkinlik raporu

"Bu politika gerçekten işe yarıyor mu" sorusu için:

  • Politika başına: tetiklenme sayısı, false positive oranı, ortalama risk skoru
  • Bypass oranı (gerekçe yazılıp devam edilen %)
  • Reddedilen gerekçe oranı (supervisor yetkisinde)
  • Trend: son 3 ay artıyor mu, düşüyor mu

Sonuç: bazı politikaları emekliye ayır (artık tetiklenmiyorlar), bazılarını sıkılaştır (false positive %0, ama hâlâ block ediyor — eşik yüksek).

Custom rapor oluşturucu

1

Rapor şablonu oluştur

Raporlar → "Yeni Şablon" → drag-drop builder:

  • Hangi alanlar (tarih, kullanıcı, olay tipi, risk vb.)
  • Hangi filtreler (sadece BLOCKED, sadece USB, vb.)
  • Hangi gruplama (kullanıcı bazlı, gün bazlı, departman bazlı)
  • Hangi görselleştirme (tablo, bar chart, line chart, pie)
2

Şablonu kaydet + schedule

"Aylık Yönetim Brifingi" diye kaydet, her ayın 1'i 09:00'da otomatik üret + Owner mailine gönder. PDF + Excel formatlarında.

Eskalasyon zinciri yapılandırma

Yüksek riskli olay = anında müdahale gerek. Eskalasyon ayarları:

1

Risk seviyesine göre alıcı

Ayarlar → Bildirimler → "Eskalasyon Matrisi":

  • Risk 0-30 (düşük): Hiçbir bildirim, sadece log
  • Risk 31-60 (orta): Saatlik özet maili (1 mail = N olay)
  • Risk 61-80 (yüksek): Anında email, IT yöneticisine
  • Risk 81-95 (çok yüksek): Anında email + Slack/WhatsApp, IT + DPO
  • Risk 96-100 (kritik): Anında push + SMS, IT + DPO + Owner
2

Eskalasyon zinciri (bekleme süreleri)

Bir olay kritik seviyede ama IT yanıt vermiyor:

  • 0. dk: IT yöneticisine bildirim
  • 5. dk: IT okumadıysa DPO'ya eskale
  • 15. dk: DPO okumadıysa Owner'a eskale + acil arama
  • 30. dk: Owner okumadıysa yedek admin'lere genişlet
3

Sessiz saatler

Mesai dışı saatlerde:

  • 22:00-08:00 (gece): Sadece kritik (96+) bildirilir
  • Hafta sonu: Sadece yüksek+kritik (81+)
  • Resmi tatil: Sadece kritik

Kritik durumlar her zaman geçer — gece de WhatsApp gelir.

SIEM entegrasyonu (Splunk, Graylog, ELK)

Webhook ile entegrasyon

Tüm olaylarınızı SIEM'e push edip orada merkezi monitoring:

  1. SIEM'inizde HTTPS Event Collector aç (örn. Splunk HEC)
  2. VeritaDLP → Ayarlar → Webhook'lar → SIEM URL'i
  3. Olay tipi: event.created (tüm olaylar)
  4. Format: JSON, HMAC-SHA256 imzalı

Splunk için CIM mapping

VeritaDLP event JSON → Splunk Common Information Model:

# Splunk eklentisinde input config:
sourcetype=veritadlp:event
index=dlp_events

# Field mappings:
{user_email}     → user
{host}           → src_host
{event_type}     → action
{risk_score}     → severity
{detections}     → message

ELK Stack için Logstash config

input {
  http {
    port => 8085
    codec => json
  }
}

filter {
  if [event_type] == "event.created" {
    mutate {
      add_tag => ["dlp", "veritadlp"]
    }
    date {
      match => ["occurred_at", "ISO8601"]
    }
  }
}

output {
  elasticsearch {
    hosts => ["localhost:9200"]
    index => "dlp-%{+YYYY.MM.dd}"
  }
}

API ile olay sorgulama (otomasyon)

Tipik kullanım: gece hash bazlı backup

#!/usr/bin/env python3
"""Tüm olay metadata'sını gece arşivle (kendi sunucumuza)."""
import requests
from datetime import datetime, timedelta

API_KEY = "vt_live_a1b2c3d4..."
BASE = "https://api.veritadlp.com/v1"

# Son 24 saatin olayları
since = (datetime.utcnow() - timedelta(hours=24)).isoformat() + "Z"
resp = requests.get(
    f"{BASE}/events",
    headers={"Authorization": f"Bearer {API_KEY}"},
    params={"since": since, "limit": 1000},
)
events = resp.json()["results"]

# Kendi storage'ımıza yaz
with open(f"dlp-backup-{datetime.utcnow().date()}.json", "w") as f:
    json.dump(events, f, indent=2)

Pagination ve büyük sorgular

# 30 gün - 100.000 olay olabilir, pagination şart
def get_all_events(since, until):
    all_events = []
    cursor = None
    while True:
        params = {"since": since, "until": until, "limit": 1000}
        if cursor:
            params["cursor"] = cursor
        resp = requests.get(f"{BASE}/events", params=params, headers=headers).json()
        all_events.extend(resp["results"])
        cursor = resp.get("next_cursor")
        if not cursor:
            break
    return all_events

Olay etiketleme ve workflow

Büyük şirkette olay sayısı çok — etiketler ile organize edin:

  • Etiket: "review-needed", "false-positive", "escalated", "closed", "training-opportunity"
  • Atama: Olayı bir analyst'e ata, takip eder
  • Status: Open / In Progress / Resolved / Closed
  • Notlar: Yorumlar — analizler arası iletişim

Dashboard → Olaylar → "Toplu işlem" ile birden çok olaya tek tıkla etiket atayın (örn. 50 olay "false-positive" → politika ince ayarı yapın).