Veri Sızıntısı Önleme (DLP): Asıl Tehlike İçeriden Geliyor
Bir veri ihlali dendiğinde aklınıza karanlık bir odada oturan, kapüşonlu bir saldırgan gelir. Oysa DSET olarak yıllardır gördüğümüz ihlal vakalarının çoğunda fail dışarıda değil, içeride. Veriniz çoğu zaman bir hacker tarafından değil, işten ayrılan bir çalışanın çantasındaki USB belleğiyle ya da "tümünü yanıtla" diye yanlış kişiye giden bir e-postayla sızar. Müşteri listesini kopyalayıp giden satışçı, fiyat tablosunu rakibe yanlışlıkla forward'layan asistan, hassas raporu kişisel Gmail'ine atan mühendis. İşte gerçek tehdit profili budur.
Data Loss Prevention, yani Veri Sızıntısı Önleme, tam olarak bu sessiz sızıntıları durdurmak için vardır. Güvenlik duvarınız dışarıdan geleni süzerken, DLP içeriden çıkanı izler. İkisi farklı dünyalardır ve birbirinin yerini tutmaz.
Veri sızıntısının gerçek anatomisi
Verizon yıllık veri ihlali raporlarının sürekli gösterdiği bir şey var: ihlallerin kayda değer bir kısmı kazara ya da içeriden kaynaklanıyor. Burada üç ayrı senaryoyu birbirinden ayırmak gerekir.
Birincisi, kötü niyetli içeriden tehdit (malicious insider). İşten kötü ayrılan bir çalışan, gitmeden önce erişebildiği her şeyi kopyalar. Müşteri veritabanı, fiyat politikası, kaynak kodu. Bunlar şirketin en değerli varlığıdır ve çoğu zaman hiçbir teknik engelle karşılaşmadan dışarı çıkar.
İkincisi, ihmalkar içeriden hata (negligent insider). Kimse kötü niyetli değildir ama biri tüm personel tablosunu yanlış dağıtım listesine e-postalar, ya da hassas bir Excel'i şifresiz bir bulut klasörüne koyar. İhlal gerçekleşir, çünkü dikkat dağıldı.
Üçüncüsü, dışarıdan saldırgan. Evet, bu da olur. Ama tek tehdit bu değildir ve DLP'nin asıl katma değeri, ilk iki senaryoda ortaya çıkar.
DLP üç durumdaki veriyi birden korur
Doğru kurgulanmış bir DLP çözümünün gücü, veriyi tek bir noktada değil, üç ayrı halinde birden korumasıdır. Bunu kavramadan kurulan DLP yarım kalır.
Durağan veri (data at rest), dosya sunucularında, veritabanlarında, SharePoint'te, bulut depolama alanlarında öylece duran veridir. Burada DLP'nin işi keşif ve sınıflandırmadır: hassas verinin nerede durduğunu bulmak. Çoğu kurum, kişisel veri içeren dosyaların yarısının nerede olduğunu bilmez.
Hareketli veri (data in motion), ağ üzerinden akan veridir. Gönderilen e-posta, web'e yüklenen dosya, dışarı giden trafik. DLP burada içeriği gerçek zamanlı tarar ve politikaya aykırı transferi durdurur ya da karantinaya alır.
Kullanımdaki veri (data in use), kullanıcının cihazında o an işlenen veridir. USB belleğe kopyalanan dosya, panoya alınan kopyala-yapıştır, yazıcıya gönderilen çıktı, ekran görüntüsü. Endpoint DLP burada devreye girer ve içeriden kaçışı tam bu noktada keser.
DLP kanalları ve kontrol noktaları
Bir veri sızıntısının çıkabileceği her kapı ayrı bir kontrol noktası ister. Aşağıdaki tablo, DSET'in DLP politikası tasarlarken kanal kanal ele aldığı çerçevedir.
| Sızıntı kanalı | Veri durumu | Tipik risk senaryosu | DLP kontrolü |
|---|---|---|---|
| E-posta | Hareketli | Hassas tablonun yanlış adrese gitmesi | İçerik taraması, otomatik karantina, şifreleme zorunluluğu |
| USB ve taşınabilir disk | Kullanımdaki | İşten ayrılan çalışanın veri kopyalaması | USB yazma engeli, sadece şifreli aygıt, kopyalama log'u |
| Bulut (kişisel) | Hareketli | Dosyanın kişisel Drive veya Dropbox'a atılması | Yetkisiz bulut yükleme engeli, CASB entegrasyonu |
| Yazıcı çıktısı | Kullanımdaki | Gizli belgenin kağıda dökülmesi | Etiketli belgede yazdırma kısıtı, filigran |
| Ekran görüntüsü ve pano | Kullanımdaki | Hassas ekranın kopyalanması | Pano kontrolü, etiketli pencerede screenshot engeli |
| Web ve mesajlaşma | Hareketli | Veriyi WhatsApp Web ya da forma yapıştırma | HTTPS içerik denetimi, yükleme filtresi |
DLP neden çoğu zaman başarısız olur
Bu kısım, satıcıların anlatmadığı gerçeğin ta kendisi. DSET olarak devraldığımız projelerin çoğunda DLP zaten kuruluydu, sadece çalışmıyordu. İki kök neden var.
Birincisi, aşırı yanlış pozitif (false positive). DLP veri sınıflandırması yapılmadan, "her yere kural koyalım" mantığıyla kurulursa, meşru iş akışlarını da engeller. Muhasebenin normal fatura e-postası bloklanır, satışçının rutin teklifi karantinaya düşer. Birkaç hafta içinde IT ekibi sürekli şikayet altında ezilir ve politikayı gevşete gevşete fiilen kapatır. DLP artık oradadır ama hiçbir şey yapmaz. Yanlış pozitif yönetimi bir lüks değil, projenin yaşaması için zorunluluktur.
İkincisi, veri keşfi ve sınıflandırma atlanır. Neyi koruduğunuzu bilmeden nasıl koruyabilirsiniz? Önce verinin nerede olduğunu bulan bir keşif taraması, sonra hassasiyet düzeyine göre etiketleme (gizli, dahili, genel) yapılmalıdır. Bu temel atılmadan kurulan DLP, kör bir bekçidir. Doğru sıra şudur: önce keşfet, sonra sınıflandır, sonra politika yaz, sonra önce sadece izle (monitor mode), en son engelle.
KVKK bağlantısı: DLP yasal bir teknik tedbirdir
Türkiye'de kişisel veri içeren bir sızıntı sadece itibar meselesi değildir, doğrudan hukuki sonuç doğurur. KVKK kapsamında bir veri ihlali gerçekleştiğinde, veri sorumlusunun bunu en kısa sürede ve makul olan en geç yetmiş iki saat içinde Kurula bildirmesi beklenir. Bildirim yapılmaması ya da yetersiz teknik tedbir, idari para cezasına yol açar.
İşte DLP'nin hukuki yüzü tam burada. KVKK madde 12, veri sorumlusunun uygun güvenlik düzeyini sağlamak için gerekli teknik ve idari tedbirleri almasını şart koşar. DLP, bu teknik tedbirin en somut hallerinden biridir. Kişisel verinin yetkisiz biçimde dışarı çıkmasını teknik olarak engellediğinizi belgeleyebilmek, hem ihlali önler hem de bir denetimde "gerekli tedbiri aldık" demenizi sağlar. KVKK uyum tarafını bütünsel ele aldığımız KVKK uyumluluk ve veri güvenliği çözümlerimizi inceleyebilirsiniz.
DSET'in DLP yaklaşımı
DSET olarak DLP'yi bir ürün kurulumu gibi değil, bir veri güvenliği programı gibi ele alıyoruz. Çünkü kutudan çıkan yazılım, sizin verinizi tanımıyor.
İlk adım veri keşfi ve sınıflandırmadır. Sunucularınızı, paylaşımlarınızı ve bulut alanlarınızı tarayıp kişisel ve hassas verinin nerede durduğunu çıkarırız. Sonra hassasiyet etiketleri tanımlarız.
İkinci adım kanal bazlı DLP politikasıdır. E-posta DLP, endpoint DLP ve bulut DLP'yi yukarıdaki tablodaki kanallara göre ayrı ayrı kurgularız. Her kanalın kendi eşiği ve kendi istisnaları olur.
Üçüncü adım yanlış pozitif yönetimidir. Politikaları önce sadece izleme modunda çalıştırır, gerçek trafikte ürettiği uyarıları haftalarca ayarlar, ancak gürültü kabul edilebilir düzeye indikten sonra engelleme moduna geçeriz. Bu sabır, projenin kapatılmamasını sağlayan şeydir.
Dördüncü adım içeriden tehdit (insider threat) odağıdır. İşten ayrılma sürecindeki çalışanlar için ayrı izleme profilleri, ayrıcalıklı hesaplar için ek kontroller tanımlarız. Kimin neye eriştiğini sağlamlaştırmak için kimlik ve erişim yönetimi çözümlerimizle entegre çalışırız. E-posta tarafındaki sızıntı vektörlerini ise şirket maillerinin güvenliği yazımızda ayrıntılı ele alıyoruz.
Beşinci adım, bir ihlal yaşandığında adli bilişimdir. Sızıntı gerçekleştiyse, neyin ne zaman ve kim tarafından dışarı çıktığını delil değeri taşıyacak biçimde tespit eder, KVKK bildirimi için gereken zaman çizelgesini hazırlarız. Yetmiş iki saatlik bildirim sürecini adım adım anlattığımız KVKK veri ihlali bildirimi rehberini de el altında bulundurmanızı öneririz.
Sık Sorulan Sorular (SSS)
DLP gerçekten içeriden veri kaçışını durdurabilir mi? Evet, doğru kurulduğunda durdurur. Endpoint DLP, USB'ye kopyalamayı, yazdırmayı ve kişisel buluta yüklemeyi engelleyebilir. Önemli olan, bu kontrolleri sınıflandırılmış veriye göre uygulamaktır. Hiçbir DLP kararlı ve teknik bilgili bir içeriden saldırganı yüzde yüz durduramaz, ama riski ve fırsat penceresini ciddi biçimde daraltır ve her denemeyi delil olarak kaydeder.
DLP çalışanları rahatsız eder, üretkenliği düşürmez mi? Yanlış kurulursa düşürür, doğru kurulursa fark edilmez. Sorunun kaynağı her zaman aşırı yanlış pozitiftir. Biz politikaları önce izleme modunda çalıştırıp ayarladığımız için, engelleme moduna geçildiğinde meşru iş akışları takılmaz. Çalışanın günlük işine değmeyen, sadece gerçek riskli transferi durduran bir DLP hedeflenir.
Bulut hizmetleri kullanıyoruz, DLP yine de gerekli mi? Kesinlikle. Bulut, sızıntı yüzeyini büyütür. Microsoft 365 ve Google Workspace gibi platformların kendi DLP yetenekleri vardır ama bunlar veri keşfi ve sınıflandırma yapılmadan etkin değildir. Üstelik kişisel bulut hesaplarına (kişisel Drive, Dropbox) yapılan yüklemeler ancak endpoint ve ağ DLP ile kontrol edilebilir.
KVKK için DLP zorunlu mu? KVKK doğrudan "DLP kurun" demez, ancak madde 12 uygun teknik tedbirleri zorunlu kılar. DLP, kişisel verinin yetkisiz aktarımını önleyen en somut teknik tedbirlerden biridir. Bir denetimde ya da ihlal sonrası incelemede, DLP ile bu riski yönettiğinizi belgeleyebilmek ciddi avantajdır.
Mevcut DLP'miz var ama çalışmıyor, sıfırdan mı başlamalıyız? Hayır. Çoğu vakada altyapı doğrudur, sorun yanlış konfigürasyon ve atlanmış veri sınıflandırmasıdır. Önce mevcut kurulumu denetler, yanlış pozitif kaynaklarını çıkarır, eksik sınıflandırmayı tamamlar ve politikaları yeniden kurgularız. Genellikle var olanı işler hale getirmek, sıfırdan kurmaktan hem hızlı hem ekonomiktir.
Kaynaklar
- NIST, veri güvenliği ve koruma rehberleri: https://csrc.nist.gov/
- KVKK, Kişisel Verileri Koruma Kurumu resmi sitesi: https://www.kvkk.gov.tr/
- ENISA, Avrupa Birliği Siber Güvenlik Ajansı: https://www.enisa.europa.eu/
- Microsoft Purview Data Loss Prevention dokümantasyonu: https://learn.microsoft.com/en-us/purview/dlp-learn-about-dlp
- Verizon Data Breach Investigations Report (DBIR): https://www.verizon.com/business/resources/reports/dbir/
DSET ile veri sızıntısını durdurun
Veri sızıntısı önleme, kutudan çıkan bir yazılım değil, verinizi tanıyan bir programdır. DSET, 2003'ten beri Ankara Hacettepe Teknokent Beytepe yerleşkesinde kurumsal güvenlik projeleri yürütüyor. Veri keşfi ve sınıflandırmadan başlayan, kanal bazlı, yanlış pozitifi yönetilen ve KVKK uyumlu bir DLP kurmak için bizimle konuşun.
DSET, Ankara Hacettepe Teknokent Beytepe. Telefon: +90 536 662 38 09.