Çalışan İzleme ve Veri Sızıntısı Önleme (DLP) için Davranış Politikaları: Sahadan Pratik Bir Rehber
Bu rehber, kurumsal İK/Bilgi Güvenliği/IT ekiplerinin Teramind, ActivTrak, DLP modülleri vb. "User Activity Monitoring" (UAM) platformlarında davranış politikası (behavior policy) kurgularken kullanabileceği, sahada test edilmiş ve genişletilmiş bir senaryo kataloğudur. Belirli bir ürüne bağlı kalmadan okunabilecek şekilde yazılmıştır; örnekler herhangi bir UAM/DLP aracında "tetikleyici (trigger) → koşul (condition) → eylem (action)" mantığıyla birebir uyarlanabilir.
1. Neden Davranış Politikası Mantığı Önemli?
Çoğu şirket UAM/DLP ürününü kurduktan sonra ya hiçbir politika çalıştırmaz (sadece "kayıt tutar") ya da internetten kopyaladığı 3-5 hazır şablonu açar ve unutur. İkisi de pratikte işe yaramaz:
- Politika yoksa, ürün sadece "olay sonrası inceleme" aracına dönüşür — bir veri sızıntısı olduktan sonra fark edilir.
- Hazır şablonlar şirketin gerçek iş akışına göre kalibre edilmediği için ya alarm yorgunluğu (false positive bombardımanı) yaratır ya da kritik bir senaryoyu hiç kapsamaz.
Doğru yaklaşım, politikaları üç katmanda düşünmektir:
- Engelleme (Block) — Geri dönüşü olmayan, net ihlal niteliğindeki eylemler (örn. müşteri veritabanı dump'ının kişisel e-postaya gönderilmesi).
- Uyarı + Loglama (Warn/Alert) — Şüpheli ama bağlama göre meşru olabilecek davranışlar (örn. büyük dosya transferi, mesai dışı erişim).
- Sessiz Loglama (Log only) — İleride analiz için işe yarayacak ama anlık aksiyon gerektirmeyen olaylar (örn. .zip dosyası oluşturma).
Bir politika yazarken önce bu üç katmandan hangisine girdiğini belirlemek, hem hukuki risk hem de çalışan deneyimi açısından kritik. "Her şeyi blokla" yaklaşımı genelde 2 hafta içinde IT'ye gelen şikayetler yüzünden devre dışı bırakılır.
Genel Politika Anatomisi
Hangi platformu kullanırsanız kullanın, bir davranış politikası şu bileşenlerden oluşur:
| Bileşen | Açıklama | Örnek |
|---|---|---|
| Tetikleyici (Trigger) | İzlenen olay türü | Dosya kopyalama, URL ziyareti, process başlatma, e-posta gönderimi |
| Koşul (Condition) | Tetikleyiciyi daraltan filtre | device = removable, recipient domain != company.com |
| Hedef (Target) | Politikanın uygulanacağı kullanıcı/grup | Tüm şirket, sadece Muhasebe, sadece yöneticiler |
| Eylem (Action) | Tetiklendiğinde ne olur | Block, Warn, Alert (e-posta/Slack), Log, Kill Process, Lock Screen |
| İstisna (Exception) | Yanlış pozitifleri önlemek için | "IT ekibi için PowerShell uyarısı verme" |
Şimdi bu mantığı kategoriler halinde, gerçek senaryolarla genişletelim.
2. Veri Sızıntısı (DLP) Politikaları
Bu kategori, "veri şirketten nasıl çıkar?" sorusuna odaklanır. Sızıntı kanalları genelde dörde ayrılır: çıkarılabilir medya, bulut depolama, e-posta, ekran görüntüsü/kayıt.
| Politika | Tetikleyici / Koşul | Aksiyon | Sahadan Not |
|---|---|---|---|
| Kişisel veri içeren e-posta | E-posta gövdesi/ekinde TC kimlik no, IBAN, kredi kartı deseni regex'i + alıcı domaini şirket dışı | Block + Alert (Bilgi Güvenliği) | Regex'i çok sıkı yazarsanız fatura numaralarını bile yakalar; üretime almadan 1 hafta "log only" modda çalıştırıp false positive oranını ölçün. |
| USB'ye toplu kopyalama | device = removable + file copy count > N (5 dk içinde) |
Alert + kullanıcıya uyarı mesajı | Tekil dosya kopyalamayı bloklamak yerine toplu kopyalamayı hedeflemek, meşru kullanım (örn. sunum dosyasını USB'ye atma) ile sızıntıyı ayırt etmenin pratik yolu. |
| Bulut depolamaya yükleme | URL contains (drive.google.com, dropbox.com, wetransfer.com, mega.nz) + upload event |
Warn (ilk seferde) → Block (tekrarında) | Kademeli aksiyon, "yanlışlıkla bir kez" ile "sistematik sızıntı" arasındaki farkı yönetilebilir kılar. |
| Hassas pencerede ekran görüntüsü | Process = SnippingTool.exe, obs64.exe, bandicam.exe + aktif pencere = ERP/CRM |
Alert + ekran kaydını ek olarak işaretle | Sadece process bazlı kontrol yetmez; "hangi pencere aktifken" bilgisi olmadan normal kullanım da yakalanır. |
| Şifreli arşiv oluşturma | .zip/.rar/.7z oluşturma + dosya boyutu > eşik |
Log only | Tek başına alarm üretmemeli; "veri sızıntısı zaman çizelgesi" oluştururken referans noktası olarak değerli. |
| (Yeni senaryo) Kurumsal dosyayı kişisel cihaza AirDrop/Nearby Share ile gönderme | Process = AirDrop/Nearby Share + dosya kurumsal paylaşım dizininden |
Alert | Hibrit çalışma ortamlarında giderek artan, çoğu DLP ürününün gözden kaçırdığı bir kanal. |
| (Yeni senaryo) Ekran paylaşımı sırasında hassas sekme açık | Video conferencing app (Zoom/Teams) ekran paylaşımı aktif + tarayıcıda Finance/HR etiketli sekme |
Warn (kullanıcıya "hassas içerik paylaşılıyor" bildirimi) | Toplantı kayıtları üzerinden oluşan sızıntılar genelde fark edilmez; gerçek zamanlı uyarı düşük maliyetli, yüksek etkili bir önlem. |
3. Şüpheli Davranış / İçeriden Tehdit (Insider Threat) Politikaları
Bu kategori "normalden sapma"yı yakalamaya çalışır. Tek bir olay genelde yetersizdir; örüntü (pattern) önemlidir.
| Politika | Tetikleyici / Koşul | Aksiyon | Sahadan Not |
|---|---|---|---|
| Mesai dışı erişim | Login zamanı çalışma saatleri dışında + erişilen kaynak "hassas" etiketli | Alert (sadece hassas kaynaklar için) | "Tüm mesai dışı girişleri" alarma bağlamak, esnek çalışan sayısı fazla şirketlerde anlamsızlaşır. Hedefi daraltmak şart. |
| Aşırı kopyala-yapıştır | Clipboard copy event sayısı > eşik / 5 dk | Alert | Geliştiriciler ve veri analistleri için bu eşik yüksek tutulmalı; aksi halde ekip sürekli "false positive" üretir. |
| Aynı hassas dosyaya tekrarlanan erişim | Aynı kullanıcı, aynı dosyaya 1 gün içinde N'den fazla erişim | Alert + günlük özet rapor | Bordro/maaş dosyaları gibi "neden tekrar tekrar açılıyor" sorusu sorulması gereken dosyalar için anlamlı. |
| VPN'siz uzaktan erişim | RDP/SSH oturumu + VPN process'i çalışmıyor | Block veya Alert (politikaya göre) | Sahada en sık karşılaşılan "false positive kaynağı" — bazı meşru üçüncü taraf erişimleri de bu şekilde görünür; istisna listesi mutlaka tutulmalı. |
| (Yeni senaryo) İşten ayrılma sürecindeki kullanıcı için geçici sıkı politika | Kullanıcı profili "Notice Period" grubuna eklendiğinde otomatik olarak DLP politikaları sıkılaştırılır (USB, bulut, e-posta dış domain → Block) | Block + Alert HR | İşten ayrılma öncesi/sonrası dönem, veri sızıntılarının istatistiksel olarak en yoğun olduğu zaman dilimidir. Bunu manuel değil, otomatik grup tabanlı yönetmek, unutulma riskini ortadan kaldırır. |
| (Yeni senaryo) Aynı kimlik bilgisiyle farklı coğrafi konumlardan eşzamanlı oturum | İki aktif oturum, GeoIP farkı > X km, zaman farkı < 1 saat | Alert + zorunlu re-auth | Klasik "impossible travel" senaryosu; UAM verisini kimlik/SSO loglarıyla çapraz okumak gerekir ama tek başına UAM tarafında da erken sinyal verir. |
4. Üretkenlik ve Performans Politikaları
Bu kategori hassas bir alan: amaç "polis devleti" yaratmak değil, örüntüleri görünür kılmak. Aksiyonun büyük kısmı "block" değil "rapor"dur.
| Politika | Tetikleyici / Koşul | Aksiyon | Sahadan Not |
|---|---|---|---|
| Kategori bazlı uygulama kullanımı | App category = Entertainment/Social, mesai saatleri içinde, toplam süre > eşik | Haftalık özet rapor | Bireysel "yakalama" yerine departman ortalaması üzerinden trend göstermek, İK ile çatışmayı azaltır. |
| Boşta kalma (idle) analizi | Idle time > 15 dk, tekrarlayan günlük örüntü | Flag (yöneticiye değil, kullanıcının kendisine "bugün X saat aktif değildiniz" özeti) | Kendine geri bildirim, yönetici şikayetinden çok daha az dirençle karşılanır ve davranışı daha hızlı değiştirir. |
| (Yeni senaryo) Toplantı yoğunluğu vs. "derin çalışma" süresi | Takvim entegrasyonu + uygulama kullanım verisi: günün %60'ından fazlası toplantıda + kalan sürede sık uygulama geçişi (context switching) | Haftalık "odaklanma skoru" raporu | Üretkenlik analizini "çalışan ne kadar çalışıyor" yerine "çalışana odaklanma fırsatı veriliyor mu" sorusuna çevirmek, raporu yönetim için çok daha değerli kılar. |
| (Yeni senaryo) Araç kullanım israfı tespiti | Aynı işlev için birden fazla araç (örn. hem Slack hem Teams hem e-posta ile aynı konunun konuşulması) | Aylık "araç konsolidasyonu" raporu | Bu, doğrudan bir "izleme" politikası değil ama UAM verisinin maliyet optimizasyonu için kullanılabileceğini gösteren güçlü bir örnek — yönetime sunarken işe yarar. |
5. Uyumluluk (KVKK/GDPR) Politikaları
Türkiye'deki şirketler için bu kategori artık "nice to have" değil, denetimlerde sorulan bir konu.
| Politika | Tetikleyici / Koşul | Aksiyon | Sahadan Not |
|---|---|---|---|
| Kişisel veri içeren dosyanın dış paylaşımı | Dosya içeriğinde TC kimlik/IBAN/telefon regex'i + alıcı @şirket.com değil |
Block + Alert (Veri Sorumlusu/DPO) | KVKK md. 12 kapsamında "veri güvenliğine ilişkin yükümlülükler" için somut bir teknik tedbir kanıtı oluşturur — denetimde işe yarar. |
| Politika okuma takibi | KVKK/Bilgi Güvenliği politikası dokümanı, atama tarihinden itibaren N gün içinde açılmadıysa | Otomatik hatırlatma | Basit ama denetimlerde sıkça istenen "farkındalık eğitimi kanıtı"nı otomatikleştirir. |
| (Yeni senaryo) Aydınlatma metni olmadan veri toplama riski | Yeni bir form/anket aracı (Google Forms, Typeform vb.) açıldığında ve içeriğinde "ad soyad", "telefon", "TC kimlik" gibi alan adları tespit edildiğinde | Alert (Hukuk/DPO'ya, kullanıcıyı bloklamadan) | Çalışanların iyi niyetle ama KVKK'ya aykırı şekilde oluşturduğu "gölge formlar" şirketlerde sık karşılaşılan, fark edilmesi zor bir risktir. |
| (Yeni senaryo) Saklama süresi dolmuş veri erişimi | Belirli bir klasördeki dosyalar, etiketlenen "imha tarihi"nden sonra hâlâ açılıyor/kopyalanıyorsa | Alert + otomatik imha iş akışına yönlendirme | KVKK'nın "veri minimizasyonu" ilkesini operasyonel hale getirir; çoğu şirket bunu sadece kağıt üzerinde bir politika olarak tutar. |
6. Yapay Zeka Araçları (ChatGPT, Copilot, Midjourney vb.) Politikaları
2023 sonrasında en hızlı büyüyen risk kategorisi budur ve çoğu şirketin politika setinde hâlâ hiç yer almaz.
| Politika | Tetikleyici / Koşul | Aksiyon | Sahadan Not |
|---|---|---|---|
| Kaynak kodun AI sohbet aracına yapıştırılması | Aktif uygulama = IDE (VS Code, JetBrains) + clipboard paste hedefi = chat.openai.com / claude.ai / gemini.google.com | Alert (Block değil — geliştirici deneyimini bozmamak için) | Tamamen bloklamak genelde "shadow AI" kullanımına (kişisel cihazdan, VPN'siz) yol açar. Alert + farkındalık daha sürdürülebilir. |
| Kurumsal doküman AI aracına yükleme | Dosya yükleme event'i + hedef domain AI araçları listesinde + dosya "Confidential" etiketli | Block + Alert | Etiketleme altyapısı yoksa (DLP sınıflandırması), bu politika dosya adı/uzantı bazlı basit kurallarla başlatılabilir. |
| (Yeni senaryo) Kurumsal API anahtarının prompt içinde paylaşımı | Metin alanına yapıştırma/yazma event'i + içerik regex'i (sk-, AKIA, ghp_, JWT formatı vb.) + hedef = tarayıcı/AI aracı |
Block + Alert DevSec | Geliştiricilerin "şu hatayı çöz" derken yanlışlıkla .env dosyasının tamamını yapıştırması, sahada en sık karşılaşılan AI kaynaklı sızıntı türlerinden biri. |
| (Yeni senaryo) Onaylanmamış AI tarayıcı eklentisi kurulumu | Tarayıcı eklenti mağazasından kurulum + eklenti adı/izinleri "tüm sekmeleri okuma" kapsıyor | Alert + IT onay iş akışı | AI tabanlı tarayıcı eklentileri (özetleyiciler, otomatik doldurma vb.) genelde tüm sayfa içeriğini üçüncü taraf sunuculara gönderir; çalışanlar bunu "üretkenlik aracı" sanıp fark etmeden kurar. |
| Onaylı AI kullanımı için "güvenli alan" tanımlama | Şirketin kendi barındırdığı/kurumsal lisanslı AI aracı (örn. Microsoft Copilot for Business, kurumsal ChatGPT Enterprise) | İstisna listesine ekle (politika tetiklemez) | Politikanın amacı "AI kullanımını engellemek" değil, "veri kurumsal sınırların dışına çıkmasın" olmalı — bu ayrımı netleştirmek kullanıcı direncini büyük ölçüde azaltır. |
7. Geliştirici / IT Güvenliği Politikaları
| Politika | Tetikleyici / Koşul | Aksiyon | Sahadan Not |
|---|---|---|---|
| SSH/özel anahtar dışa aktarımı | Dosya adı/uzantısı .pem, .ppk, id_rsa + USB/bulut/e-posta hedefi |
Block + Alert | Sahada gözlemlenen en yüksek etkili, en düşük false-positive'li kurallardan biri — neredeyse hiçbir meşru senaryoda bu dosyaların dışarı çıkması gerekmez. |
| Veritabanı dump işlemi | Process = mysqldump/pg_dump veya dosya adı dump.sql/backup.bak + sonrasında dış transfer |
Alert + Log | "Dump alma" başlı başına şüpheli değildir (yedekleme rutinleri vardır); asıl sinyal dump + dış transfer kombinasyonudur. |
| Yetkisiz PowerShell/CMD kullanımı | Process = powershell.exe/cmd.exe + kullanıcı grubu ≠ IT/Admin |
Alert | İlk haftalarda IT ekibinin kendi hesaplarını istisna listesine eklemeyi unutması, en sık görülen "kendi alarmını tetikleme" senaryosu. |
| (Yeni senaryo) Production ortam değişkenlerine erişim | .env dosyası açma/düzenleme + dosya yolu production/prod içeriyor + kullanıcı "DevOps" grubunda değil |
Block + Alert | Yetki matrisinin teoride doğru ama pratikte (paylaşılan sunucu, ortak kullanıcı hesabı vb. nedenlerle) delindiği durumları yakalamanın ucuz bir yolu. |
| (Yeni senaryo) CI/CD pipeline dışı deploy denemesi | git push veya deploy script çalıştırma, branch = main/production + kaynak makine CI runner değil |
Alert DevOps | "Acil durumda elle deploy" kültürü olan ekiplerde bu olayları tamamen engellemek yerine görünür kılmak, post-mortem'lerde çok işe yarar. |
8. Felaket Kurtarma / Anomali Tespiti Politikaları
| Politika | Tetikleyici / Koşul | Aksiyon | Sahadan Not |
|---|---|---|---|
| Toplu dosya silme | Dosya silme sayısı > eşik / 5 dk | Alert + (mümkünse) ilgili dizini salt-okunur yap | Ransomware'in ilk belirtilerinden biri genelde "dosya değiştirme" değil, dosya yeniden adlandırma + silme patlamasıdır. |
| Yedekleme klasörüne müdahale | Path contains /backup + delete/modify event |
Block | Ransomware saldırılarının önemli bir kısmı önce yedekleri hedef alır; bu klasörler için "salt okunur + immutable" snapshot stratejisiyle birlikte düşünülmeli. |
| (Yeni senaryo) Şifreleme imzası taşıyan dosya patlaması | Kısa sürede çok sayıda dosyanın uzantısının değişmesi (örn. .docx → .locked/.encrypted) |
Alert (kritik öncelik) + cihazı ağdan izole etme iş akışı tetikleme | Bu, klasik "entropy artışı" tespitinden daha basit ama yine de erken uyarı sağlayan bir yaklaşımdır; SOC ekibinin dakikalar içinde müdahale etmesini sağlar. |
9. Sektöre Özel Senaryolar
Çağrı Merkezi / Müşteri Hizmetleri
- Müşteri görüşmesi sırasında ekran kaydı yazılımı açılması → Block
- Müşteri kişisel verisinin onaylı CRM dışındaki bir uygulamaya (Notepad, Excel) kopyalanması → Alert
- (Yeni) Müşteri kart numarasının (PCI-DSS desenine uyan) sohbet/ticket sistemine düz metin olarak yazılması → Block + otomatik maskeleme önerisi
Üretim / SCADA / OT
- Yetkisiz kullanıcının SCADA terminaline erişimi → Block
- PLC konfigürasyon dosyalarının değiştirilmesi → Alert OT Admin
- (Yeni) Üretim hattı bilgisayarına USB üzerinden yazılım kurulum denemesi (air-gapped olması beklenen sistemlerde) → Block + fiziksel güvenlik ekibine bildirim
Sağlık
- Hasta verisi içeren dosyanın dışa aktarımı → Block
- DICOM/MRI dosyalarının e-posta ile gönderimi → Block
- (Yeni) Hasta dosyasına, ilgili hekim/departman dışından erişim (yetki dışı "merak" erişimleri) → Alert + aylık erişim denetim raporu
10. Politikaları Hayata Geçirirken Sahadan 5 Pratik Ders
-
Önce "log only" ile başlayın. Yeni bir politikayı doğrudan Block/Warn moduna almak, ilk haftada IT'yi şikayet seliyle boğar. 1-2 hafta sessiz loglama yaparak gerçek tetiklenme oranını görün, eşikleri ona göre kalibre edin.
-
İstisna listesini bir defalık değil, sürekli bir süreç olarak yönetin. IT ekibi, yöneticiler, dış denetçiler gibi gruplar zamanla değişir. Çeyreklik bir "istisna listesi gözden geçirme" takvimi koymak, hem güvenlik açığı hem de gereksiz alarmı önler.
-
Aksiyonu, riskle orantılı seçin. "Her şeyi blokla" yaklaşımı, çalışanların politika etrafında dolaşma yolları bulmasına (kişisel telefon ile fotoğraf çekme, kişisel cihaz kullanma vb.) yol açar — bu da görünürlüğü tamamen ortadan kaldırır. Orta riskli senaryolarda Warn/Alert, yalnızca net ihlallerde Block tercih edin.
-
Politikaları İK ve Hukuk ile birlikte tasarlayın, sadece IT ile değil. Özellikle "üretkenlik" ve "davranışsal anomali" kategorilerindeki politikalar, çalışan haklarıyla doğrudan kesişir. Bu politikaların varlığının çalışanlara şeffaf şekilde bildirilmesi (genelde bir "Kabul Edilebilir Kullanım Politikası" dokümanı ile), hem hukuki hem de etik açıdan zorunludur.
-
Raporlamayı "yakalama" değil "trend" odaklı kurgulayın. Yöneticilere "X kullanıcı Y'yi yaptı" listesi göndermek yerine, departman bazlı trendler (örn. "Finans departmanında bulut yükleme denemeleri bu ay %40 arttı") sunmak, hem daha az dirençle karşılanır hem de kök nedene (örn. yeni bir iş akışı ihtiyacı) işaret eder.
Kapanış
Bu kataloğu olduğu gibi kopyalayıp tek seferde devreye almak yerine, şirketinizin en yüksek riskli 3-5 senaryosunu seçip onları "log only → alert → block" olgunluk eğrisinden geçirerek başlamanızı öneririm. Davranış politikaları, kurulduktan sonra unutulan bir "ayar ekranı" değil, şirketin değişen iş akışlarına göre düzenli olarak gözden geçirilmesi gereken canlı bir doküman olarak ele alınmalı.
Bu rehber, 1500+ kullanıcılı bir kurumsal ortamda Teramind tabanlı bir UAM/DLP platformunun sahada yönetilmesi sürecinden edinilen deneyimlerin genelleştirilmiş bir özetidir. Belirtilen senaryolar herhangi bir spesifik kurum/yapılandırmayı yansıtmaz; eğitim ve referans amaçlıdır.