TR / EN

DLP Politikalarında Yönetici Parolaları ve API Anahtarları Nasıl Tespit Edilir?

DLP projeleri çoğunlukla kimlik numarası ve finansal veriyle başlar. Oysa bir yapılandırma dosyasındaki API anahtarı veya destek kaydındaki yönetici parolası kurum için en az bu veriler kadar kritik olabilir. Teknik sırların biçimi değişken olduğu için hazır bir desen her ortamda yeterli olmaz.

14 Temmuz 2026 tarihli çalışmada amaç gerçek sır örneklerini merkezi bir dosyada toplamak değildi. Güvenli sentetik verilerle özel bilgi türünü geliştirdik; önce yalnızca görünürlük sağladık, yanlış pozitifleri azalttıktan sonra kullanıcı uyarısı ve olay akışını devreye aldık.

Bu tür bir kontrolün sosyal boyutu da var. Teknik ekipler hızlı çözüm için bazen bir değeri sohbet kanalına veya destek kaydına bırakabiliyor; yalnızca engelleyici politika koymak çalışma alışkanlığını ortadan kaldırmıyor. Kullanıcıya güvenli sır paylaşım kanalını göstermeden üretilen uyarı, kısa sürede geçilmesi gereken bir engel gibi görülür. Bu nedenle DLP olaylarından süreç iyileştirme verisi çıkardık: hangi uygulama güvenli entegrasyonu zorlaştırıyor, hangi ekipte sır kasası kullanımı eksik ve hangi şablon yanlış pozitif üretiyor? Politika böylece yalnız ihlal arayan değil, kötü iş akışını görünür kılan bir kontrol oldu.

Sorunun ortaya çıkışı

Yönetici parolası, root hesabı, private key, recovery key, API token ve VPN secret ifadelerinin e-posta ve belgelerde dolaşabildiği görüldü. Mevcut DLP yalnızca klasik kişisel veri türlerini izliyordu; teknik sırlar olay müdahalesinde tesadüfen fark ediliyordu.

İhtiyaç bütün kod parçalarını engellemek değil, geçerli sır olma olasılığı yüksek içerikleri doğru ekibe yönlendirmekti. Kapsam e-posta, iş birliği alanı ve yönetilen uç nokta kanalları için veri sınıfına göre ayrıldı.

İlk belirtiler ve yanlış varsayımlar

“password” veya “token” kelimesini arayan ilk kural dokümantasyon, eğitim ve boş şablonlarda alarm üretti. Uzun rastgele karakter dizileri de dosya özeti ve örnek kodlarla karıştı. Çok gürültülü kural, analistin gerçek olayı kaçırmasına neden olur.

Bir başka hata, yakalanan içeriği olay kaydına açık biçimde kopyalamaktı. DLP kanıtı erişimi sınırlı ve maskeli olmalıdır. Kural, sır kasasının alternatifi değildir; asıl hedef sırların güvenli üretim, saklama ve rotasyon sürecine taşınmasıdır.

Teknik analiz

Özel bilgi türünde ana örüntüye yakın mesafede “admin”, “secret”, “private key”, “recovery” veya yapılandırma alanı gibi destekleyici bağlam arandı. Belirgin başlık ve biçime sahip anahtarlar yüksek güven, genel karakter dizileri daha düşük güven aldı. Türkçe ve İngilizce iş bağlamları ayrı test edildi.

Sentetik pozitif örnekler ile sözleşme, kaynak kodu şablonu ve eğitim dokümanı gibi negatif örneklerden test seti hazırlandı. Hassas değerlerin kendisi loglanmadı. Sonuçlar kanal, kullanıcı grubu, dosya türü ve eşleşme gerekçesine göre incelendi.

# Savunmacı kural mantığı (temsili)
if pattern_matches and context_within_300_chars:
    classify(confidence='high')
elif pattern_matches:
    classify(confidence='low', action='audit')

Uygulanan çözüm veya önerilen mimari

Politika önce seçili teknik ekipte audit-only çalıştı. Haftalık örnekleme ile gerçek pozitif, kabul edilebilir iş kullanımı ve yanlış pozitif sınıfları çıkarıldı. Eşik ve yakınlık ayarları oturduktan sonra kullanıcıya açıklayıcı uyarı gösterildi; yalnızca yüksek riskli kanallarda engelleme değerlendirildi.

Doğrulanan olay güvenlik ekibi ile sır sahibine yönlendirildi. Paylaşım kaldırma yeterli sayılmadı; anahtar iptali veya parola rotasyonu, erişim logu incelemesi ve kök neden düzeltmesi kapanış kriteri oldu.

Alternatifler ve karar gerekçesi

Kaynak kodu secret scanning araçları depo bağlamında daha kesin sonuç verebilir; DLP e-posta ve doküman kanallarını kapsar. Sır kasası güvenli saklama sağlar fakat yanlış paylaşımı tek başına önlemez. Bu kontroller birbirini tamamlar.

Tam engelleme hızlı görünür ancak iş akışını bozup kontrol dışı kanalları teşvik edebilir. Kademeli görünürlük, kullanıcı eğitimi ve seçici engelleme tercih edildi. Ürün hazır sınıflandırıcıları pilot sonuçlarıyla doğrulanmadan güvenilir kabul edilmedi.

Güvenlik ve operasyonel riskler

DLP analistleri son derece hassas içeriğe erişebilir. Rol ayrımı, gerekçeli görüntüleme, denetim izi ve sınırlı saklama uygulanmalıdır. Test için gerçek parola veya token kullanılmamalı; olay kayıtları sır değerini tekrar yaymamalıdır.

Yanlış negatifler kaçınılmazdır; DLP mutlak garanti olarak sunulmamalıdır. Şifreli arşivler, görseller ve yeni token biçimleri görünürlüğü etkiler. Kural performansı ve ürün formatları düzenli gözden geçirilmeli, olay sonrası rotasyon prosedürü tatbik edilmelidir.

Çıkarılan Dersler

Kontrol Listesi