Gözlemlenebilirlik Yığınınızdaki Sessiz GDPR İhlali
Çoğu mühendislik ekibi, uygulama veritabanlarında kişisel verileri işlediklerini bilir. Ancak, log yönetim sistemlerini aynı titizlikle denetleyenlerin sayısı daha azdır.
GDPR Madde 5(1)(e), kişisel verilerin "işlenme amaçları için gerekli olandan daha uzun süre saklanmamasını" gerektirir — bu, saklama sınırlama ilkesidir. Uygulama veritabanları için, organizasyonların saklama politikaları, silme işlemleri ve veri minimizasyon süreçleri vardır.
Uygulama logları için tipik politika çok daha basittir: operasyonel ve güvenlik nedenleriyle her şeyi 90 gün (veya 6 ay, veya 1 yıl) saklamak. Saklama süresi, kişisel veri analizinden ziyade hata ayıklama ve denetim ihtiyaçları tarafından belirlenir.
Sorun: bu loglar kişisel veriler içerir. Bir kullanıcının e-posta adresini içeren her istek logu, bir doğrulama girdisini yakalayan her hata logu, bir IP adresini kaydeden her erişim logu — bunlar GDPR Madde 4(1) kişisel verileridir. Organizasyon, her saklama süresi için bir GDPR yasal dayanağı sorusunu yanıtlamak zorundadır.
Uygulama Loglarında Gerçekte Ne Oluyor
Yaygın web uygulama log formatlarının bir anketi, biriken PII'nin genişliğini ortaya koymaktadır:
Erişim logları (nginx/Apache):
- IP adresleri (EDPB rehberliğine göre doğrudan GDPR kişisel verisi)
- Kullanıcı ajanı dizeleri (parmak izi oluşturmaya katkıda bulunabilir)
- Oturum belirteçleri (eğer kaydedilmişse)
Uygulama logları (yapılandırılmış JSON):
- Kullanıcı tanımlayıcıları (e-posta adresleri, profillere bağlı kullanıcı kimlikleri)
- Girdi doğrulama hataları (genellikle geçersiz girdi içerir — bu, bir kullanıcının gerçek verisi olabilir)
- İş olayı logları (müşteri hesaplarına bağlı sipariş kimlikleri, destek talebi referansları)
- Arama sorguları (kişisel isimler, adresler içerebilir)
API geçidi logları:
- Yetkilendirme başlıkları (bazı yapılandırmalarda kısmen kaydedilir)
- Sorgu parametreleri (kullanıcı kimlikleri, isimler, e-postalar içerebilir)
- İstek/yanıt gövdesi (hata ayıklama loglama yapılandırmalarında)
Veritabanı sorgu logları (yavaş sorgu logları, denetim logları):
- e-posta = 'user@example.com' içeren SQL sorguları
- Sorgu parametrelerinde yer alan literal kişisel veri değerleri
Biriken veriler kasıtlı değildir. Bu, hata ayıklama için tasarlanmış standart loglama uygulamalarının bir yan ürünüdür, GDPR uyumluluğu düşünülerek tasarlanmamıştır.
Loglardaki IP Adresleri Üzerine EDPB Pozisyonu
Avrupa Veri Koruma Kurulu, IP adreslerinin GDPR kapsamında kişisel veri olduğunu sürekli olarak savunmuştur — çünkü internet servis sağlayıcıları bunları abonelere bağlayabilir ve kurumsal bağlamlarda belirli kullanıcıları tanımlayabilirler.
Bu, log saklama için doğrudan bir sonuç doğurur: IP adreslerini içeren erişim logları kişisel veri loglarıdır. Nginx erişim loglarını 12 ay saklamak, kişisel verileri 12 ay saklamak demektir. 12 aylık saklama, Madde 6 altında yasal bir dayanak gerektirir ve saklama sınırlama ilkesi, saklama süresinin belirli amaç için gerekli olmasını gerektirir.
Çoğu organizasyon, log saklama sürelerini bu çerçeveye karşı açıkça analiz etmemiştir. "Logları 90 gün saklıyoruz çünkü güvenlik ekibi böyle diyor" ifadesi, operasyonel uygulama hakkında bir beyan olup, GDPR Madde 5(1)(e) analizi değildir.
Uyumluluk İçin Anonimleştirme Yolu
Çoğu mühendislik ekibi için logların GDPR uyumluluğu için pratik yol, log saklama süresini azaltmak (operasyonel güvenlik gerekçeleri vardır) değil, uzun vadeli saklamadan önce logları anonimleştirmektir.
Aşamalı saklama modeli:
0-7 gün: Aktif hata ayıklama için tam ham loglar saklanır. Operasyonel gerekçe açıktır; saklama süresi, çoğu organizasyon için saklama sınırlama sorunlarından kaçınmak için yeterince kısadır.
7-90 gün: Eğilim analizi ve güvenlik izleme için anonimleştirilmiş loglar saklanır. IP adresleri anonimleştirilmiş IP'lerle değiştirilir; kullanıcı e-postaları tutarlı belirteçlerle değiştirilir; hesap numaraları maskelemeye tabi tutulur. Teknik meta veriler (zaman damgaları, hata kodları, gecikme, uç noktalar) operasyonel analiz için korunur.
90+ gün (gerekirse): Sadece toplanmış log verileri (olay sayıları, hata oranları, gecikme dağılımları) — bireysel düzeyde kayıt yoktur.
Bu model, her saklama katmanında operasyonel faydayı korurken saklama sınırlama ilkesini de karşılar: kişisel veri saklama süresi 7 gündür; toplanmış operasyonel veriler, kişisel veri ifşası olmadan daha uzun süre saklanır.
Gözlemlenebilirlik Kullanım Durumları İçin Yapıyı Koruma
Log anonimleştirmenin gözlemlenebilirlik faydasını koruyan temel teknik gereksinimi, içerik değiştirme ile yapısal korumadır:
Korunan:
- JSON yapısı ve anahtar adları
- Zaman damgaları ve zaman dizileri
- Hata türleri ve kodları
- HTTP yöntemleri, yollar, durum kodları
- Gecikme değerleri ve performans metrikleri
- İş olayı türleri (sipariş verildi, ödeme alındı)
Değiştirilen:
- E-posta adresleri → user1@example.com (log dosyası içindeki orijinal e-posta için tutarlı belirteç)
- IP adresleri → RFC 5737 belgelerine göre adresler (192.0.2.x, 198.51.100.x)
- Hesap numaraları → ACCT_XXXXX
- Telefon numaraları → +XX XXX XXX XXXX
- Hata bağlamlarından isimler → [PERSON]
Tutarlı belirteç değişimi ile operasyonel analiz korunur: user1@example.com izini takip eden bir istek izleme, 40 log kaydında hata ayıklama için orijinal e-posta ile aynı şekilde çalışır — çünkü belirteç log dosyası boyunca tutarlıdır.
Toplanmış metrikler etkilenmez: uç nokta başına hata oranları, gecikme yüzdelikleri, throughput hesaplamaları — bunların hiçbiri isteği tetikleyen kullanıcının gerçek e-posta adresini bilmeyi gerektirmez.
Mühendislik Ekipleri İçin Pratik Entegrasyon
Bir Django veya Node.js uygulama ekibi için log anonimleştirme entegrasyonu şöyle görünür:
Seçenek 1: Log boru hattı entegrasyonu
- Fluentd/Logstash log göndericisi logları yakalar
- Anonimleştirme adımı, iletmeden önce her log satırında çalışır
- Gözlemlenebilirlik platformu (Elastic/Datadog) anonimleştirilmiş logları alır
- Uygulama loglama kodunda değişiklik gerekmez
Seçenek 2: Gece yarısı toplu anonimleştirme
- Ham loglar yerel depolamaya yazılır
- Gece yarısı cron: dünkü logları anonimleştir, ham versiyonu sil
- Anonimleştirilmiş loglar uzun vadeli depolamaya gönderilir
- Ham loglar sadece 7 gün saklanır
Seçenek 3: Ön paylaşım anonimleştirmesi
- Ham loglar uygun erişim kontrolleri ile dahili olarak saklanır
- Dışa paylaşırken (sızma testçileri, yükleniciler): erişim sağlamadan önce anonimleştirme işlemi yapılır
- Dış taraflar her zaman anonimleştirilmiş versiyonları alır
GDPR uyumluluğu belgeleri için: log anonimleştirme, GDPR Madde 32 altında bir "teknik önlem"dir. Anonimleştirme adımını belgelemek — araç, yapılandırma, saklama politikası — Madde 30 altında gerekli olan İşleme Faaliyetleri Kayıtları (RoPA) parçasıdır.
Kaynaklar: