Das stille DSGVO-Risiko in Ihrem Log-Stack
Aktualisiert für 2026
Die meisten Teams prüfen ihre Datenbank auf personenbezogene Daten. Wenigere tun dasselbe für ihr Log-System.
Artikel 5 Abs. 1 lit. e DSGVO begrenzt die Speicherdauer personenbezogener Daten. Für Datenbanken legen Teams Aufbewahrungsfristen und Löschjobs fest. Für Log-Dateien lautet die Regel einfacher: alles 90 Tage zum Debuggen aufbewahren.
Das Problem? Diese Einträge enthalten personenbezogene Daten. Request-Einträge enthalten Nutzer-E-Mails. Fehlerprotokolle enthalten rohe Eingabewerte. Zugriffseinträge enthalten IP-Adressen. Jede dieser Angaben gilt nach der DSGVO als personenbezogenes Datum. Ihr Team braucht eine Rechtsgrundlage und einen Aufbewahrungsplan für jeden Fall.
Was in Ihren Log-Dateien landet
Standard-Web-App-Logging zieht eine breite Palette an personenbezogenen Daten (PII) aus verschiedenen Quellen.
Zugriffseinträge (nginx/Apache):
- IP-Adressen — personenbezogene Daten laut EDSA-Leitlinien
- User-Agent-Strings — können Geräte-Fingerprinting ermöglichen
- Session-Token — falls in der Ausgabe enthalten
App-Einträge (strukturiertes JSON):
- Nutzer-IDs und E-Mail-Adressen
- Eingabefehler — enthalten oft den rohen ungültigen Wert, der echte Nutzerdaten sein kann
- Geschäftsereignisse — Bestell-IDs verknüpft mit Kundenkonten
- Suchanfragen — können Namen oder Adressen enthalten
API-Gateway-Einträge:
- Auth-Header — in manchen Setups teilweise erfasst
- Query-Parameter — können Nutzer-IDs, Namen oder E-Mails enthalten
- Anfrage- und Antwortkörper — vorhanden in Debug-Level-Setups
Datenbank-Audit-Einträge:
- SQL-Abfragen mit WHERE-Klauseln wie
email = 'user@example.com' - Literale personenbezogene Werte in Query-Parametern
Das geschieht nicht absichtlich. Es ist ein Nebeneffekt von Logging-Praktiken, die zum Debuggen entwickelt wurden, nicht für die DSGVO.
EDSA-Leitlinien zu IP-Adressen
Der Europäische Datenschutzausschuss (EDSA) stuft IP-Adressen als personenbezogene Daten ein. Internetanbieter können sie Abonnenten zuordnen. Innerhalb einer Organisation können sie bestimmte Nutzer identifizieren.
Die Auswirkung ist direkt. Zugriffseinträge mit IP-Adressen sind personenbezogene Einträge. Nginx-Ausgabe 12 Monate zu behalten bedeutet, personenbezogene Daten 12 Monate zu speichern. Das erfordert eine Rechtsgrundlage nach Artikel 6. Es erfordert auch, dass die Aufbewahrungsfrist zum angegebenen Zweck passt.
Die meisten Teams überspringen diesen Schritt. „Wir behalten Einträge 90 Tage, weil Security das sagt" ist eine Faustregel. Es ist keine DSGVO-Prüfung nach Artikel 5 Abs. 1 lit. e. Sehen Sie unsere Übersicht zur Rechtskonformität für den Gesamtzusammenhang.
Der Weg zur Compliance
Der praktische Weg für die meisten Teams ist nicht, die Aufbewahrungsfristen zu kürzen. Operative und sicherheitsbezogene Gründe für längere Zeiträume sind real. Der bessere Weg ist, Einträge vor der Langzeitspeicherung zu maskieren.
Ein abgestuftes Modell funktioniert gut.
0–7 Tage: Vollständige Rohdaten für aktives Debugging. Sieben Tage sind kurz genug für die meisten Teams.
7–90 Tage: Maskierte Einträge für Trend-Analysen und Sicherheitsreviews. IP-Adressen werden ersetzt. Nutzer-E-Mails werden zu stabilen Token. Kontonummern werden maskiert. Schlüsselfelder — Zeitstempel, Fehlercodes, Latenz, Endpunkte — bleiben unverändert.
90+ Tage (falls nötig): Nur aggregierte Ausgabe. Ereigniszählungen, Fehlerraten, Latenzbereiche. Keine nutzerbezogenen Einträge verbleiben.
Personenbezogene Daten werden nach sieben Tagen nicht weiter verarbeitet. Aggregierte Ausgabe kann weitergegeben werden, ohne Personen zu exponieren. Siehe Sicherheit & Compliance für weitere Details.
JSON-Struktur für das Monitoring erhalten
Gutes Masking hält die JSON-Struktur intakt und ersetzt nur den Inhalt. Das hält die Ausgabe nützlich für Debugging und Alerts.
Unverändert:
- JSON-Schlüssel und Verschachtelung
- Zeitstempel und zeitliche Abfolge
- Fehlertypen und HTTP-Statuscodes
- HTTP-Methoden, Pfade und Latenzwerte
- Geschäftsereignistypen
Ersetzt:
- E-Mail-Adressen → stabiler Token pro Original (z. B.
user1@example.com) - IP-Adressen → RFC-5737-Bereiche (
192.0.2.x) - Kontonummern →
ACCT_XXXXX - Telefonnummern →
+XX XXX XXX XXXX - Namen in Fehlertext →
[PERSON]
Stabile Token halten Traces nutzbar. Eine Spur für user1@example.com über 40 Einträge funktioniert genauso wie das Original. Aggregierte Metriken — Fehlerraten, Latenz, Durchsatz — benötigen gar keine personenbezogenen Daten. Siehe das Glossar für die Begriffe Pseudonymisierung und Anonymisierung.
Drei Integrationsmöglichkeiten
Drei Muster decken die meisten Engineering-Teams ab.
Option 1 — Pipeline-Masking: Fluentd oder Logstash fängt jede Zeile vor dem Weiterleiten ab. Ein Masking-Schritt läuft inline. Elastic oder Datadog erhält nur bereinigte Einträge. Keine App-Code-Änderungen sind nötig.
Option 2 — Nächtlicher Batch: Rohdaten landen im lokalen Speicher. Ein nächtlicher Job maskiert die Ausgabe des Vortages und löscht die Rohversion. Maskierte Einträge gehen in den Langzeitspeicher. Rohdaten werden nur sieben Tage aufbewahrt.
Option 3 — Pre-Share-Masking: Rohdaten bleiben intern mit strengen Zugriffskontrollen. Vor der Weitergabe an Pen-Tester oder externe Auftragnehmer wird ein Masking-Durchgang ausgeführt. Externe Parteien erhalten immer bereinigte Versionen.
Für die DSGVO-Dokumentation ist Masking eine „technische Maßnahme" nach Artikel 32. Dokumentieren Sie das Tool, seine Konfiguration und Ihre Aufbewahrungsrichtlinie im Verzeichnis der Verarbeitungstätigkeiten (VVT) nach Artikel 30. Siehe unser FAQ für häufige VVT-Fragen.
Möchten Sie ein Praxisbeispiel? Sehen Sie die Fallstudien für konkrete Details. Unter Preise finden Sie, welcher Plan integrierte Masking-Pipelines enthält.
Quellen
- DSGVO Artikel 5: Grundsätze der Verarbeitung — VERIFIED-EXTERNAL
- EDSA Stellungnahme 5/2019 zur ePrivacy-Richtlinie und DSGVO — VERIFIED-EXTERNAL
- Sonra.io: PII-Masking in JSON- und XML-Daten — VERIFIED-EXTERNAL