Uygulama Loglarında Kişisel Veri: Maskeleme ve Saklama Politikası

Görünmeyen Veri Deposu: Loglar

Bir yazılım ekibinde hata ayıklarken “şimdilik tüm isteği loglayalım” kararı sık verilir. Aylar sonra log platformunda müşteri telefonları, açık metin parolalar ya da kimlik numaraları bulunur. Log maskeleme KVKK uyumunda bu yüzden sık atlanan ama etkisi büyük bir tedbirdir: veri tabanını koruyup logu açık bırakmak, ön kapıyı kilitleyip arka kapıyı açık unutmaya benzer.

Bu yazıda uygulama loglarına sızan kişisel veri türlerini, maskeleme ve alan filtreleme yöntemlerini, hata izleme araçlarının yurt dışı boyutunu, saklama süresi ve erişim yetkisini ele alıyor; sonunda ekibinize uyarlayabileceğiniz bir politika iskeleti paylaşıyoruz.

Loglara Sızan Kişisel Veri Türleri

6698 sayılı Kanun'a göre kişisel veri, kimliği belirli veya belirlenebilir gerçek kişiye ilişkin her türlü bilgidir. Bir log satırı tek başına bir adı içermese bile, kullanıcı kimliği veya IP adresiyle başka bir kayda bağlanabiliyorsa kişisel veri niteliği taşır. Uygulamada en sık rastlanan sızıntılar şunlardır:

İstek ve yanıt gövdeleri: Kayıt ve ödeme formlarının tamamının loglanması; ad, adres, telefon ve bazen kimlik numarasının loga düşmesi.

URL ve sorgu parametreleri: E-posta adresi, sıfırlama bağlantısı veya arama terimi gibi değerlerin erişim loglarına yazılması.

Kimlik doğrulama bilgileri: Hatalı yapılandırılmış hata ayıklama kodunun parola, oturum çerezi, erişim anahtarı (token) veya tek kullanımlık kodu kaydetmesi.

Hata mesajları ve yığın izleri: Veri tabanı hatalarında sorgunun parametreleriyle birlikte yazılması.

Teknik tanımlayıcılar: IP adresi, cihaz kimliği, konum ve kullanıcı ajanı bilgisi.

Sağlık, biyometrik veya ceza mahkûmiyeti gibi özel nitelikli kişisel veriler loga düştüğünde risk daha da artar. Kurul'un 31.01.2018 tarihli ve 2018/10 sayılı kararı, bu verilerin elektronik ortamda kriptografik yöntemlerle korunmasını ve veriler üzerindeki tüm hareketlerin güvenli biçimde loglanmasını ister. Log, koruma aracı olmalı; korunması gereken verinin kopyası değil.

Maskeleme ve Alan Filtreleme

Kurul'un Kişisel Veri Güvenliği Rehberi, teknik tedbirler arasında veri maskelemeyi ve log kayıtlarını ayrı başlıklar olarak sayar. Yazılım ekipleri açısından en etkili yaklaşım, kişisel veriyi log hattına girmeden durdurmaktır. Bunun için birbirini tamamlayan birkaç yöntem vardır:

Engelleme listesi tek başına yetersiz kalır, çünkü yeni eklenen bir alan listede yoktur. Bu nedenle olgun ekipler izin listesini temel alır, örüntü tabanlı temizliği ikinci bir güvenlik ağı olarak kullanır. Maskeleme kuralı kod incelemesinde kontrol edilen bir standart haline geldiğinde, sızıntılar geliştirme aşamasında yakalanır.

Takma ad kullanmanın veriyi anonim hale getirmediğini unutmamak gerekir: anahtara erişen kişi eşleştirme yapabildiği için veri kişisel veri olmaya devam eder, yalnızca riski azaltılmış olur.

Maskeleme Yöntemleri Karşılaştırması

Hata İzleme Araçları ve Yurt Dışı

Hata izleme (error tracking), uygulama performans izleme (APM) ve merkezi log yönetimi hizmetlerinin önemli bir kısmı yurt dışındaki veri merkezlerinde çalışır. Bu araçlara gönderilen bir hata kaydında kullanıcı e-postası veya IP adresi varsa, bu gönderim KVKK'nın 9. maddesi kapsamında yurt dışına kişisel veri aktarımı olarak değerlendirilir.

7499 sayılı Kanun'la değişen 9. madde ve 10.07.2024 tarihli Kişisel Verilerin Yurt Dışına Aktarılmasına İlişkin Usul ve Esaslar Hakkında Yönetmelik, aktarımın yeterlilik kararı, uygun güvenceler (ör. standart sözleşme) veya sınırlı istisnalardan birine dayanmasını ister. Standart sözleşme kullanılıyorsa, imzadan itibaren beş iş günü içinde Kurum'a bildirilmesi gerekir. Konunun ayrıntılarını yurt dışına veri aktarımı uygulama rehberi yazımızda bulabilirsiniz.

Hukuki mekanizmanın yanında teknik önlem de önemlidir. Pek çok araç, veriyi göndermeden önce istemci tarafında temizleme (before-send kancası), IP adresini kaydetmeme ve veri bölgesi seçme imkânı sunar. Kişisel veri hiç gönderilmezse aktarım sorusu da büyük ölçüde ortadan kalkar.

Saklama Süreleri

KVKK'nın 4. maddesi, kişisel verilerin ilgili mevzuatta öngörülen veya işlendikleri amaç için gerekli olan süre kadar muhafaza edilmesini ister. Uygulama logları için tek bir yasal süre yoktur; süre, logun amacına göre belirlenmelidir:

Hata ayıklama logları: Genellikle kısa süre yeterlidir; hata çözüldükten sonra ayrıntılı kayıtları uzun süre tutmanın meşru bir gerekçesi zordur.

Güvenlik ve erişim logları: Olay incelemesi ve ihlal tespiti için daha uzun süre gerekebilir; bu süre risk değerlendirmesiyle gerekçelendirilmelidir.

Mevzuattan doğan kayıtlar: Hizmetinize göre 5651 sayılı Kanun gibi özel düzenlemeler belirli trafik bilgilerinin saklanmasını öngörebilir. Bu yükümlülüğün sizin için geçerli olup olmadığı ayrıca değerlendirilmelidir.

Belirlenen süreler kişisel veri saklama ve imha politikasına yazılmalı ve log platformunda otomatik silme kuralıyla uygulanmalıdır. Silme, Yok Etme veya Anonim Hale Getirme Yönetmeliği, periyodik imhanın politikada belirlenen aralıklarla ve her halde altı ayı geçmeyecek sürelerde yapılmasını ve imha işlemlerinin kayıt altına alınmasını öngörür. Yedeklenen log arşivleri de bu kapsama dahildir.

Erişim Yetkileri

Loglar, genellikle geliştiricilerin, destek ekibinin ve dış hizmet sağlayıcıların geniş biçimde eriştiği bir alandır. Bu da iyi niyetli bir sorgunun bile büyük miktarda kişisel veriyi görünür kılması anlamına gelir. Kişisel Veri Güvenliği Rehberi, çalışanlara yalnızca görevleri için gerekli ölçüde erişim yetkisi tanınmasını ve bir erişim yetki ve kontrol matrisi oluşturulmasını önerir.

Üretim loglarına erişim, rol bazlı ve isimlendirilmiş hesaplarla verilmeli; ortak hesap kullanılmamalıdır.

Ham loglara erişimi olan kişi sayısı az tutulmalı, diğer ekipler maskelenmiş görünümleri kullanmalıdır.

Log platformunda yapılan aramalar ve dışa aktarmalar da kayıt altına alınmalıdır; logun logu, yetkisiz merakı görünür kılar.

Erişim yetkileri düzenli aralıklarla gözden geçirilmeli, ekipten ayrılanların erişimi gecikmeden kapatılmalıdır.

Logların kendisinin bir hedef olduğunu da hatırlatalım: saldırganlar, parola ve oturum anahtarı barındıran log dosyalarını yetki yükseltmek için kullanır. Bu tür saldırıların hukuki sonuçlarını fidye yazılımı ve KVKK ihlali yazımızda ele aldık.

Politika Örneği

Aşağıdaki iskelet, bir yazılım ekibinin log politikasını hazırlarken başlangıç noktası olarak kullanılabilir. Değerler kurumun risk değerlendirmesine göre doldurulmalıdır.

Politika yazıldıktan sonra en kritik adım, mevcut loglarda bir kez tarama yapıp geçmişte biriken kişisel verileri tespit etmek ve temizlemektir. Bu tarama çoğu zaman beklenmedik sonuçlar verir.

Log Politikası İskeleti

Sonuç ve Sonraki Adım

Log maskeleme KVKK uyumunda küçük görünen ama büyük sonuç doğuran bir tedbirdir. Loglar kişisel veri içeren bir kayıt ortamı olarak ele alınmalı; hangi verinin yazılacağı izin listesiyle belirlenmeli, yurt dışındaki araçlara giden veri en aza indirilmeli, saklama süresi amaca göre sınırlanmalı ve erişim dar bir ekiple paylaşılmalıdır.

İlk adım olarak üretim loglarınızdan bir günlük örneklem alıp e-posta, telefon ve kimlik numarası kalıplarıyla taramayı deneyin. Sonuç, politikanın ne kadar acil olduğunu gösterecektir. Teknik tarafta destek gerekirse siber güvenlik hizmeti kapsamını inceleyebilirsiniz.

Sık Sorulan Sorular