Microsoft Purview DLP Politikası: Simülasyondan Zorlamaya

Purview DLP politikası birkaç tıklamayla oluşur. Doğrudan engelleme modunda açılan politika ise ilk gün muhasebenin bordro gönderimini, İK’nın sigorta şirketiyle yazışmasını durdurur ve aynı hafta kapatılır. Sonra kimse yeniden açmaya cesaret edemez. Bu rehber Exchange, SharePoint, OneDrive, Teams ve uç noktalarda DLP politikasının nasıl tasarlanacağını; TCKN ve IBAN gibi yerel veri desenlerini, simülasyon modunu, geçersiz kılma seçeneklerini ve yanlış pozitif ayarını aşamalı bir zorlama planıyla anlatıyor.

DLP neyi önler, neyi önleyemez

Kurumsal siber güvenlik programında DLP’nin asıl işi iyi niyetli kullanıcının hatasını yakalamaktır: müşteri listesini kişisel adrese göndermek, kimlik numarası içeren dosyayı “bağlantıya sahip herkes” ile paylaşmak, kart numarasını Teams sohbetine yapıştırmak. Politika ipucu kullanıcıya işlem anında bilgi verir ve davranışı değiştirir. Çoğu ihlal kötü niyet değildir; dikkatsizliktir.

Sınırlarını da baştan bilin:

• Kararlı bir iç tehdidin ekran fotoğrafı çekmesini veya içeriği elle yeniden yazmasını engellemez.
• Parolayla şifrelenmiş arşivlerin ve dosyaların içeriğini inceleyemez; bu tür ekleri ayrıca yakalamak için kurallarda parola korumalı belge koşulu (-DocumentIsPasswordProtected) kullanılabilir.
• Görüntü içindeki metni ancak ilgili tarama özelliği yapılandırılmışsa inceler.
• Politika kapsamına alınmamış kanalları (yönetilmeyen cihazlar, kişisel bulut uygulamaları) kendiliğinden görmez.

DLP bu yüzden erişim kontrolü, paylaşım ayarları ve veri azaltma çalışmasıyla birlikte ele alınır. Hassas verinin nerede biriktiğini bilmeden yazılan politika en çok kullanılan kanalı değil, en kolay yapılandırılanı korur. Dosya sunucularındaki veri için hassas veri keşfi rehberine bakın.

Konumlar: e-posta, SharePoint, Teams, uç nokta

Microsoft 365 güvenliği kapsamındaki her konumda DLP’nin uygulayabildiği eylem farklıdır. Politikayı kurmadan önce hangi veri hareketini durdurmak istediğinizi konum konum yazın; kâğıt üzerinde netleşmeyen kural portalda da netleşmez.

Konum	Tipik eylem	Dikkat
Exchange e-posta	Dışarıya gönderimi engelleme, şifreleme, ipucu	İş ortağı alan adları için istisna
SharePoint siteleri	Dış kullanıcı erişimini kısıtlama	Mevcut paylaşımlar da değerlendirilir
OneDrive hesapları	Dış paylaşımı ve anonim bağlantıyı kısıtlama	Kapsam kullanıcı veya grup bazlı olabilir
Teams sohbet ve kanal	Mesajı engelleme	Teams’te paylaşılan dosyalar SharePoint/OneDrive’dadır
Cihazlar (Endpoint DLP)	USB’ye kopyalama, yazdırma, izinsiz buluta yükleme	Cihazların Purview’a eklenmesi gerekir

Teams sohbetinde paylaşılan dosya gönderenin OneDrive’ında, kanal dosyası ise ekibin SharePoint sitesinde durur. Dosya içeriğinin korunması bu konumların politikasıyla sağlanır; yalnız Teams konumunu seçip dosyaların da korunduğunu sanmak sahada sık yapılan hatadır. Dış paylaşımı sınırlayan kiracı ve site ayarları DLP’nin ön koşuludur; ayrıntılar SharePoint ve OneDrive dış paylaşım güvenliği rehberinde.

Hassas bilgi türleri ve özel desenler

Hassas bilgi türü (sensitive information type, SIT) bir desenden, isteğe bağlı doğrulama fonksiyonundan, yakınında aranan destekleyici anahtar kelimelerden ve güven düzeyinden oluşur. Purview’de kredi kartı numarası, IBAN ve Türkiye kimlik numarası için yerleşik türler var. Kullanmadan önce kiracınızdaki tam adlarına bakın:

Connect-IPPSSession
Get-DlpSensitiveInformationType | Where-Object { $_.Name -match "Turk|IBAN|Credit" } |
  Select-Object Name, Id, Publisher

Yalnız düzenli ifadeye dayanan desen yanlış pozitif üretir. 11 haneli her sayı TCKN değildir; sipariş numaraları, telefon numaraları, seri numaraları da eşleşir. TCKN’nin sağlama kuralı bu yüzden önemlidir: ilk hane 0 olamaz; 10. hane, tek sıradaki ilk beş hanenin toplamının 7 katından çift sıradaki dört hanenin toplamı çıkarılarak elde edilen değerin 10’a göre modudur; 11. hane ise ilk 10 hanenin toplamının 10’a göre modudur. Kredi kartı numaraları da Luhn algoritmasıyla doğrulanır. Yerleşik türler bu doğrulamaları içerir. Kendi düzenli ifadenizi yazmadan önce onları deneyin.

Kuruma özgü veri için özel SIT tanımlanır: personel sicil numarası, proje kodu, sözleşme numarası. İyi bir özel SIT’te:

• Desen olabildiğince dar tutulur (örneğin PRJ-[0-9]{5} gibi sabit önek içeren yapı).
• Yüksek güven düzeyi, desenin yakınında “sicil”, “personel no” gibi destekleyici anahtar kelime bulunmasına bağlanır.
• Gerçek veri kullanılmadan, test dosyalarıyla doğrulanır.

Müşteri veritabanındaki gerçek değerlerle eşleşme gerekiyorsa desen yerine kesin veri eşleşmesi (Exact Data Match, EDM) değerlendirilebilir. EDM yalnızca kurumun gerçek kayıtlarındaki değerleri yakalar ve yanlış pozitifi belirgin biçimde düşürür; karşılığında veri yükleme ve güncelleme süreci ister.

Simülasyon modunda başlamak

Her yeni politika simülasyonda başlar. İstisnası yok. Purview portalında politika oluşturulurken simülasyon seçilir; PowerShell’de karşılığı Mode parametresidir. Aşağıdaki örnek, dışarıyla paylaşılan ve yüksek güvenle en az 10 TCKN içeren içeriği hedefler; SIT adını bir önceki komutun çıktısındaki adla değiştirin:

New-DlpCompliancePolicy -Name "TR Kisisel Veri - Dis Aktarim" `
  -ExchangeLocation All -SharePointLocation All -OneDriveLocation All -TeamsLocation All `
  -Mode TestWithoutNotifications

New-DlpComplianceRule -Name "TCKN yuksek hacim - dis" -Policy "TR Kisisel Veri - Dis Aktarim" `
  -ContentContainsSensitiveInformation @{Name="<kiracidaki SIT adi>"; minCount="10"; confidencelevel="High"} `
  -AccessScope NotInOrganization -BlockAccess $true `
  -NotifyUser Owner -NotifyAllowOverride WithJustification `
  -ReportSeverityLevel High

TestWithoutNotifications modunda hiçbir eylem uygulanmaz, kullanıcıya bir şey gösterilmez; eşleşmeler simülasyon sonuçlarında ve etkinlik gezgininde (Activity explorer) görünür. Bu aşamada aranan cevaplar şunlar: Hangi birim, hangi kanaldan, kime, ne sıklıkla hassas veri gönderiyor? Eşleşmelerin hangisi meşru iş akışı, hangisi gerçek risk, hangisi yanlış pozitif? Bu soruları cevaplamadan bir sonraki aşamaya geçen ekip, engelleme modunda aynı soruları telefonda cevaplamak zorunda kalır.

Politika ipuçları ve geçersiz kılma

Simülasyonun ikinci aşaması TestWithNotifications modudur: kullanıcı Outlook’ta, SharePoint’te veya OneDrive’da politika ipucunu görür, ama işlem engellenmez. Bu aşama hem kullanıcıyı alıştırır hem de “bu uyarı neden çıktı?” sorularıyla yanlış pozitifleri ortaya döker. İpucu metni kurumun diliyle, kısa ve eyleme dönük yazılır: hangi veri tespit edildi, neden risk, doğru kanal hangisi. Uzun hukuk metni kimse okumaz.

Zorlamaya geçişte geçersiz kılma üç şekilde kullanılabilir:

Seçenek	Davranış	Uygun olduğu durum
Geçersiz kılma yok	İşlem doğrudan engellenir	Kart verisi gibi istisnası olmayan veri
Gerekçeyle geçersiz kılma	Kullanıcı iş gerekçesi yazarak devam eder	Geçiş dönemi, meşru akışı olan veri
Yanlış pozitif bildirimi	Kullanıcı eşleşmenin hatalı olduğunu bildirir	Desen ayarı devam eden kurallar

Gerekçeler denetim kaydına düşer. Haftalık incelemede aynı gerekçeyle tekrar eden akışlar (örneğin her ay aynı sigorta şirketine gönderilen çalışan listesi) belirlenir ve bu akış için daha güvenli bir kanal ya da kural istisnası tanımlanır. Bu akışlara uygun şifreleme seçenekleri e-posta şifreleme seçenekleri yazısında karşılaştırılıyor.

Yanlış pozitif ayarı

Yanlış pozitifin çaresi kuralı kapatmak değil, koşulu daraltmaktır. İşe yarayan ayar yöntemleri:

• Örnek sayısı eşiği: Tek bir TCKN içeren e-posta ile 200 TCKN içeren tablo aynı risk değildir. Düşük hacme yalnızca ipucu, yüksek hacme engelleme kuralı yazın.
• Güven düzeyi: Engelleme kurallarını yüksek güven düzeyine bağlayın; orta güveni yalnızca izleme için kullanın.
• Alıcı ve konum istisnaları: Sözleşmeli bordro hizmet sağlayıcısının alan adı gibi onaylı alıcıları istisna olarak ekleyin; istisnaları belgeleyin ve dönemsel olarak gözden geçirin.
• Etiket koşulu: Etiket kullanılıyorsa “Gizli – Kişisel Veri” etiketli içeriği ayrıca hedefleyin; etiket altyapısı duyarlılık etiketleri tasarımı rehberinde ele alınıyor.
• Özel SIT iyileştirmesi: Destekleyici anahtar kelime ve yakınlık şartı ekleyin, desenin sınırlarını belirginleştirin.

Zorlamaya geçiş ve olay incelemesi

Zorlama takvime göre değil, ölçülebilir kritere göre ilerler. Örnek bir aşama planı:

Aşama	Mod	Çıkış kriteri
1. Gözlem	Bildirimsiz simülasyon	Meşru akışlar belirlendi, sahipleri onayladı
2. Farkındalık	İpuçlu simülasyon	Yanlış pozitif bildirimleri ayarlandı
3. Yumuşak zorlama	Etkin, gerekçeyle geçersiz kılma	Gerekçeler incelendi, istisnalar tanımlandı
4. Tam zorlama	Etkin, yüksek hacimde doğrudan engelleme	Olay inceleme süreci çalışıyor

Politikayı etkinleştirmek için:

Set-DlpCompliancePolicy -Identity "TR Kisisel Veri - Dis Aktarim" -Mode Enable

Zorlamanın değeri olay incelemesiyle ortaya çıkar. DLP uyarıları Purview portalında ve Microsoft Defender XDR olay kuyruğunda görüntülenebilir. İnceleme sürecinde şunlar önceden yazılır: uyarıyı kim, ne kadar sürede inceler; kullanıcıyla nasıl iletişim kurulur; tekrarlayan ihlal hangi noktada İK veya hukuka iletilir; uyarı içeriğindeki hassas veriyi kimler görebilir. Uyarı şiddet düzeylerini ekibin gerçekten inceleyebileceği hacimde tutun. İncelenmeyen yüzlerce uyarı, hiç uyarı olmamasından daha iyi değildir. Sadece daha gürültülüdür.

DLP’nin KVKK kapsamındaki teknik tedbirlerle nasıl eşleştiği KVKK teknik tedbirleri uygulama rehberinde anlatılıyor. Purview’in kavramsal çerçevesi için başvuru kaynağı Microsoft’un veri kaybı önleme dokümantasyonu. Politika tasarımı, simülasyon analizi ve olay inceleme sürecinin kurulumu için veri kaybı önleme ve DLP hizmetine bakılabilir.

Sık sorulan sorular

Purview DLP için duyarlılık etiketleri önkoşul mu?

Hayır. DLP politikaları yalnızca hassas bilgi türleriyle, yani içerikteki desenlerle çalışabilir. Etiket kullanılıyorsa koşul olarak eklenir ve politikayı daha isabetli yapar; ama ilk DLP politikalarını etiket altyapısını beklemeden simülasyonda başlatabilirsiniz.

Simülasyon modunda kullanıcılar etkilenir mi?

Bildirimsiz simülasyonda hiçbir eylem uygulanmaz, kullanıcı bir şey görmez; yalnızca eşleşmeler raporlanır. Politika ipuçlu simülasyonda kullanıcı uyarıyı görür, işlem yine engellenmez. Bu ikinci aşama kullanıcı davranışını ve geri bildirimini görmek için kullanılır.

Parolalı ZIP veya şifreli dosyalar DLP tarafından incelenebilir mi?

Parolayla şifrelenmiş arşivlerin içeriği incelenemez. Politika tasarımında şifreli ve incelenemeyen dosyalar için ayrı bir koşul veya kural ele alınmalı, en azından dışarıya gönderimleri izlenmelidir. Microsoft’un kendi şifrelemesiyle korunan içerikte durum farklıdır; desteklenen senaryoları güncel dokümantasyondan doğrulayın.

Kullanıcı geçersiz kılma (override) seçeneği güvenliği zayıflatmaz mı?

Gerekçesi zorunlu tutulan ve denetim kaydına düşen geçersiz kılma, geçiş döneminde meşru iş akışlarını durdurmadan veri toplamayı sağlar. Gerekçeler düzenli incelenir; tekrar eden meşru akışlar politikaya istisna olarak eklenir, kötüye kullanım görülen kurallarda geçersiz kılma kaldırılıp doğrudan engellemeye geçilir.