Anasayfa›Hizmetler›Bilgi Güvenliği ve Sağlık›ISO 27001 Veri Sızıntısını Önleme (DLP): Ek A 8.12 Uygulaması
Şirket verilerinin dışarı sızmasını nasıl engellerim?
Önce hangi verinin kritik olduğu sınıflandırmayla belirlenir. Sonra bu verinin çıkabileceği kanallar tanımlanır: e-posta, bulut depolama, USB, yazıcı, ekran görüntüsü. Her kanal için izleme veya engelleme kuralı yazılır, istisnalar onaya bağlanır ve ihlal alarmları düzenli olarak gözden geçirilir.
Veri sızıntısı vakalarının büyük bölümü bir saldırganla değil, iyi niyetli bir çalışanla başlar: dosyayı kişisel e-postasına atan, müşteri listesini kendi bulut hesabına yedekleyen, sunumu USB’ye kopyalayan biri. ISO 27001:2022 bu gerçeği Ek A 8.12 ile ayrı bir kontrol başlığına taşıdı. Denetimde de artık ayrı ayrı soruluyor.
Kontrol, hassas bilgiyi işleyen sistem, ağ ve cihazlarda veri sızıntısını önleyecek tedbirlerin uygulanmasını ister. Denetçi teknik ürün adı aramaz; sızıntı kanallarının tanımlı olup olmadığını, her kanalda ne yapıldığını ve alarmların kim tarafından ne sıklıkla incelendiğini arar.
Buradaki ayrım önemli: DLP bir ürün değil, bir yetenektir. Küçük bir işletme bunu e-posta ağ geçidi kuralları, uç nokta politikaları ve bulut uygulama ayarlarıyla da karşılayabilir. Yeter ki kararlar yazılı ve izlenebilir olsun.
Kanal envanteri, verinin kurumdan çıkabileceği her yolun listesidir. Uygulamada beş ana başlık kapsayıcıdır: e-posta ve mesajlaşma, taşınabilir ortam, bulut/senkronizasyon istemcileri, yazdırma-fiziksel çıktı ve uzaktan erişim oturumları. Her kanal için “izle”, “uyar” veya “engelle” kararı verilir.
Sınırlı biçimde çalışır. Sınıflandırma yoksa kurallar yalnız desen tanımaya dayanır: kimlik numarası, kart numarası, sözleşme şablonu gibi. Bu, yapılandırılmış veriyi yakalar ama fikri mülkiyet ve müşteri stratejisi gibi serbest metinleri kaçırır. Ek A 5.12 ile 8.12 bu yüzden birlikte kurulur.
Pratik mini karar kuralı: bir kural yazmadan önce “bu kural hangi sınıflandırma etiketini koruyor?” sorusunu sorun. Cevap yoksa kural muhtemelen gereksiz alarm üretecektir.
Her alarm bir olay değildir. Önce triyaj yapılır: kural eşleşmesi doğru mu, veri gerçekten hassas mı, aktarım iş gereği mi? Doğrulanan vakalar Ek A 5.24-5.26 kapsamında olay yönetimine devredilir. Triyaj kararları kayda geçirilmezse kontrol denetimde kanıtşız kalır.
Yaygın bir eksik: alarmı inceleyen kişinin, incelediği veriyi görme yetkisinin olup olmadığı hiç düşünülmez. Sızıntıyı önleyen sürecin kendisi bir erişim riskine dönüşebilir; inceleme yetkileri ayrı tanımlanmalıdır.
Durumunuzu birkaç dakikada konuşalım; size özel süre ve yol haritası çıkaralım.
Hayır. Standart ürün adı belirtmez, sonuç ister. Mevcut e-posta, uç nokta ve bulut platformlarınızın yerleşik özellikleriyle kontrol karşılanabiliyorsa bu da kabul edilir; önemli olan risk değerlendirmesinde bu kararın gerekçelendirilmesidir.
İzleme yapılacaksa çalışan önceden açık ve anlaşılır biçimde bilgilendirilmeli, izlemenin kapsamı ve amacı sınırlı tutulmalıdır. Aydınlatma metni ve politika güncellemesi olmadan kurulan izleme, uyum açısından ayrı bir risk doğurur.
Teorik olarak evet, ancak hassas veri işleyen bir kurumda bu hariç tutmayı savunmak zordur. Hariç tutma tercih edilirse gerekçe, risk değerlendirmesindeki somut bulgulara dayanmalıdır.
Cihazı değil veriyi kontrol etmek daha uygulanabilirdir: konteynerleştirme, tarayıcı üzerinden erişim, indirme ve pano kısıtı. Bu yaklaşım Ek A 8.1 ile birlikte değerlendirilir.
Maliyet; korunacak kanal sayısı, kullanıcı birimi ve mevcut altyapının yetenekleriyle değişir. Hesaplama birim başına kurulur. Sizin için en ideal çözüm, danışmanlarımızla doğrudan görüşmenizdir.