KKB Uygulama Günlüklerinde Gizleniyor
Uygulama günlükleri, mühendislikteki en göz ardı edilen GDPR yüzeylerinden biridir. Mühendislerin kanunu görmezden gelmesi nedeniyle değil. Kullanıcı ayrıntıları log dosyalarına kazara girdiği için.
Tek bir JSON istek günlüğü dört KKB alanı içerebilir:
{
"timestamp": "2025-11-14T09:22:13Z",
"level": "ERROR",
"endpoint": "/api/users/profile",
"user_email": "sarah.johnson@company.com",
"client_ip": "82.123.45.67",
"user_agent": "Mozilla/5.0",
"error": "ValidationError: phone format",
"input_value": "+49 176 1234 5678"
}
Bu tek giriş bir e-posta, bir IP ve bir telefon numarası içeriyor. Bunu günde milyonlarca API çağrısıyla çarpın. Sonuç büyük ölçekli bir KKB etkinliğidir. Hukuki dayanak, sınırlar ve kontroller gerektirir.
Üçüncü Taraflarla Log Paylaşımı GDPR Riskini Artırıyor
Ekipler log dosyalarını dış taraflarla her zaman paylaşır:
- Sızma testi firmaları uygulama davranışını haritalamak için kayıtlar alır
- Dış danışmanlar yavaş noktaları bulmak için log örnekleri kullanır
- Log platformları (Elastic, Datadog, Splunk) tam çıktı akışları alır
- SRE yüklenicileri olaylar sırasında kayıtlara erişir
- Diğer yasal kuruluşlardaki geliştirici ekipleri hata ayıklama için dosyalar alır
Her paylaşım GDPR Madde 28 sorularını gündeme getirir. Alıcı bir veri işleyici midir? Bir Veri İşleme Sözleşmesi var mı? Bu dosyalardaki kullanıcı ayrıntılarını görmek için hukuki dayanakları var mı?
Log platformları yaygın bir açıktır. Gerçek kullanıcı e-postaları ve IP'leri içeren çıktıları Elastic Cloud veya Datadog'a göndermek bir işleme bağlantısı yaratır. Bu bağlantı, platform AB dışında yer alıyorsa bir VİS, standart maddeler ve bir transfer aracı gerektirir. Bunların her biri zaman ve hukuki inceleme gerektirir.
Daha basit yol: kullanıcı ayrıntılarını sisteminizden çıkmadan önce soyun. Tam Madde 28 kuralları için uyumluluk genel bakışımıza bakın.
JSON Yapısının Tespiti Neden Zorlaştırdığı
JSON log dosyaları yapı bakımından farklılık gösterir. Genel metin taraması yeterli değildir.
İç içe geçme derinliği: Kullanıcı ayrıntıları herhangi bir derinlikte görünür. request.headers.x-forwarded-for alanı IP adreslerini tutar. response.body.errors[0].field_value alanı kullanıcı girdisini içerebilir. Düz metin taraması iç içe yollarda gömülü alanları kaçırır.
Tutarsız şemalar: Her API uç noktası kendi çıktı şeklini üretir. Kimlik doğrulama dosyaları ödeme dosyalarına benzemez. Profil güncelleme dosyaları her ikisine de benzemez. Sabit yol yaklaşımı, hata bağlamlarındaki tuhaf yollarda görünen kullanıcı ayrıntılarını kaçırır.
KKB ile karışık teknik değerler: Yığın izleri, hata kodları ve zaman damgaları bozulmadan kalmalıdır. Kapsamlı silme, gerekli alanları da siler ve dosyayı işe yaramaz hale getirir.
Doğru yaklaşım içerik tabanlı tespittir. Kullanıcı ayrıntılarını yapı içindeki konumlarına göre değil, ne olduklarına göre — e-posta kalıbı, IP formatı, adlandırılmış varlık — bulun. Bu, uç nokta başına kurulum gerektirmeden değişken şemalarla başa çıkar.
Tutarlı Değiştirme Günlükleri Kullanışlı Tutar
Temel gereksinim referans bütünlüğüdür. sarah.johnson@company.com bir istek zinciri boyunca 47 girdide görünüyorsa, 47'sinin tamamı aynı değere eşlenmelidir.
Eşleme kuralları:
sarah.johnson@company.com→user1@example.com(dosya boyunca aynı değer)82.123.45.67→192.0.2.1(RFC 5737 dokümantasyon IP'si — açıkça gerçek değil)+49 176 1234 5678→+49 XXX XXX XXXX(maskelenmiş)
Bu eşlemeyle bir geliştirici, user1@example.com'u 47 girdide takip edebilir, istek zincirini yeniden oluşturabilir ve hatayı düzeltebilir — gerçek kullanıcı ayrıntılarını görmeden.
Bu meta veri alanları değişmeden kalır:
- Zaman damgaları (kullanıcı verisi değil)
- Hata kodları ve türleri (kullanıcı verisi değil)
- Yığın izleri (teknik kimlikler içerebilir, kullanıcı verisi değil)
- HTTP yöntemleri, yollar, durum kodları (kullanıcı verisi değil)
- Metrik değerler ve gecikme rakamları (kullanıcı verisi değil)
Sonuç hata ayıklama çalışmaları için işlevsel bir dosyadır. Gerçek kullanıcı ayrıntısı içermez. GDPR kapsamında anonimleştirme ile takma adlaştırma arasındaki fark için sözlüğümüze bakın.
Kullanım Durumu: Sızma Testi Log Paylaşımı
Bir SaaS firması, dış bir sızma testi ekibiyle üç aylık bir güvenlik incelemesi yürüttü. Kapsam, kimlik doğrulama akışlarını haritalamak ve hata kalıplarını analiz etmek için 90 günlük üretim API çıktısını gerektiriyordu.
Ham hacim: 180 MB JSON dosyası. KKB sayısı: 4.200 benzersiz kullanıcı e-postası, 1.800 benzersiz IP, hata bağlamlarında 340 kısmi hesap numarası.
Kullanıcı ayrıntılarını önce soymadan bu dosyaları paylaşmak şunları gerektirecekti:
- Sızma testi firmasıyla bir Veri İşleme Sözleşmesi
- Bir GDPR Madde 46 transfer aracı (firma AB dışında bulunuyordu)
- Veri öznesu bildirim incelemesi
Bunların her biri hukuki iş ve zaman ekler.
KKB soyma uygulandığında:
- İşlem süresi: 180 MB için 25 dakika
- Çıktı: Yapısal olarak özdeş 180 MB dosya, tüm e-postalar ve IP'ler güvenli değerlerle değiştirilmiş
- Sonuç: Sızma testi ekibi tam bağlamı aldı; hiçbir gerçek kullanıcı ayrıntısı onlara ulaşmadı
GDPR sonucu: Veri İşleme Sözleşmesi gerekmedi — soyulmuş çıktı GDPR kapsamında kullanıcı verisi değildir.
GDPR kapsamında anonim sayılan şeyle ilgili yaygın sorular için SSS sayfamıza bakın.
KKB Soymayı CI/CD'ye Entegre Etme
Düzenli olarak çıktı paylaşan ekipler için bu adım mevcut ardışık düzenlerin içinde çalışabilir.
Log döndürme:
- Döndürme betiği her gece çalışır
- Soyma adımı arşivlemeden veya herhangi bir log platformuna göndermeden önce çalışır
- Soyulmuş dosyalar dış sistemlere gider
- Orijinal dosyalar tam saklama süresiyle dahili kalır
Paylaşım öncesi betik:
- Mühendis bir yükleniciye örnek paylaşması gerekiyor
- Betiği çalıştırıyor:
input=raw-logs/ output=clean-logs/ clean-logs/klasörünü paylaşıyor- Elle KKB incelemesi gerekmiyor
Sidecar yaklaşımı:
- Sidecar çıktı akışını iletmeden önce soyar
- Gerçek zamanlı soyma, log analizi için kullanışlılığı korur
- Platform hiçbir gerçek kullanıcı ayrıntısı almaz
Saklama Politikası Entegrasyonu
GDPR Madde 5(1)(e) saklama sınırlamasını gerektirir. KKB soyma, herhangi bir saklama politikasına entegre olur.
- Ham çıktı 7 gün saklanır (günlük hata ayıklama çalışmaları için)
- Soyulmuş sürümler 90 gün saklanır (eğilim analizi ve olay incelemesi için)
- Soyma adımı 7. günde çalışır
Bu, saklama sınırlamasını karşılar. Ham çıktıyı uzun vadeli tutma riskini ortadan kaldırır.