PII versteckt sich in Anwendungs-Logs
App-Logs sind eine der am häufigsten übersehenen DSGVO-Angriffsflächen in der Entwicklung. Nicht weil Entwickler das Gesetz ignorieren. Sondern weil Benutzerdaten versehentlich in Log-Dateien landen.
Ein einziger JSON-Request-Log kann vier PII-Felder enthalten:
{
"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"
}
Dieser eine Eintrag enthält eine E-Mail-Adresse, eine IP und eine Telefonnummer. Multipliziert mit Millionen von täglichen API-Aufrufen ergibt das eine bedeutende PII-Verarbeitungsaktivität. Sie benötigt eine Rechtsgrundlage, Fristen und Kontrollen.
Weitergabe an Dritte erhöht das DSGVO-Risiko
Teams teilen Log-Dateien ständig mit externen Parteien:
- Pen-Test-Firmen erhalten Aufzeichnungen zur Analyse des App-Verhaltens
- Externe Berater nutzen Log-Stichproben zur Diagnose von Leistungsproblemen
- Log-Plattformen (Elastic, Datadog, Splunk) empfangen vollständige Ausgabeströme
- SRE-Auftragnehmer greifen während Vorfällen auf Aufzeichnungen zu
- Entwicklungsteams in anderen Rechtspersönlichkeiten erhalten Dateien zum Debuggen
Jede Weitergabe wirft DSGVO-Artikel-28-Fragen auf. Ist der Empfänger ein Auftragsverarbeiter? Gibt es einen Auftragsverarbeitungsvertrag? Hat er eine Rechtsgrundlage, um Benutzerdaten in diesen Dateien einzusehen?
Log-Plattformen sind eine häufige Lücke. Das Senden von Ausgaben mit echten Benutzer-E-Mails und IPs an Elastic Cloud oder Datadog schafft eine Verarbeitungsbeziehung. Diese Beziehung erfordert einen AVV, Standardklauseln und ein Transferinstrument, wenn die Plattform außerhalb der EU sitzt. All das kostet Zeit und rechtliche Prüfung.
Der einfachere Weg: Benutzerdaten entfernen, bevor Dateien Ihr System verlassen. Lesen Sie unseren Compliance-Überblick für das vollständige Artikel-28-Rahmenwerk.
Warum JSON-Struktur die Erkennung erschwert
JSON-Log-Dateien variieren in ihrer Struktur. Generisches Text-Scanning reicht nicht aus.
Verschachtelungstiefe: Benutzerdaten können auf jeder Ebene erscheinen. Das Feld request.headers.x-forwarded-for enthält IP-Adressen. Das Feld response.body.errors[0].field_value kann Benutzereingaben aus Fehlern enthalten. Ein flaches Text-Scan übersieht Felder in verschachtelten Pfaden.
Inkonsistente Schemas: Jeder API-Endpunkt erzeugt eine eigene Ausgabeform. Auth-Dateien sehen anders aus als Zahlungsdateien. Profil-Update-Dateien sehen wieder anders aus. Ein fester Pfadansatz übersieht Benutzerdaten, die in Fehlerkontexten an unerwarteten Pfaden erscheinen.
Technische Werte gemischt mit PII: Stack-Traces, Fehlercodes und Zeitstempel müssen erhalten bleiben. Pauschales Entfernen löscht wichtige Felder und macht die Datei unbrauchbar.
Der richtige Ansatz ist die inhaltsbasierte Erkennung. Benutzerdaten anhand ihres Inhalts finden — E-Mail-Muster, IP-Format, benannte Entität — nicht anhand ihrer Position. Dies verarbeitet variable Schemas ohne Konfiguration pro Endpunkt.
Konsistentes Ersetzen hält Logs nutzbar
Die zentrale Anforderung ist referenzielle Integrität. Wenn sarah.johnson@company.com in 47 Einträgen einer Request-Kette erscheint, müssen alle 47 auf denselben Wert abgebildet werden.
Mapping-Regeln:
sarah.johnson@company.com→user1@example.com(gleicher Wert in der gesamten Datei)82.123.45.67→192.0.2.1(RFC-5737-Dokumentations-IP — eindeutig nicht real)+49 176 1234 5678→+49 XXX XXX XXXX(maskiert)
Mit diesem Mapping kann ein Entwickler user1@example.com durch 47 Einträge verfolgen, die Request-Kette rekonstruieren und den Fehler beheben — ohne echte Benutzerdaten zu sehen.
Diese Metadaten-Felder bleiben unverändert:
- Zeitstempel (keine Benutzerdaten)
- Fehlercodes und -typen (keine Benutzerdaten)
- Stack-Traces (können Tech-IDs enthalten, keine Benutzerdaten)
- HTTP-Methoden, Pfade, Statuscodes (keine Benutzerdaten)
- Metrikwerte und Latenzwerte (keine Benutzerdaten)
Das Ergebnis ist eine Datei, die für Debug-Arbeit funktioniert. Sie enthält keine echten Benutzerdaten. Lesen Sie unser Glossar für den Unterschied zwischen Anonymisierung und Pseudonymisierung gemäß DSGVO.
Anwendungsfall: Pen-Test-Log-Weitergabe
Eine SaaS-Firma führte eine vierteljährliche Sicherheitsüberprüfung mit einem externen Pen-Test-Team durch. Der Umfang erforderte 90 Tage Produktions-API-Ausgabe zur Analyse von Auth-Flows und Fehlermustern.
Rohvolumen: 180 MB JSON-Dateien. PII-Anzahl: 4.200 eindeutige Benutzer-E-Mails, 1.800 eindeutige IPs, 340 partielle Kontonummern in Fehlerkontexten.
Ohne vorheriges Entfernen der Benutzerdaten würde die Weitergabe dieser Dateien erfordern:
- Einen AVV mit der Pen-Test-Firma
- Ein DSGVO-Artikel-46-Transferinstrument (die Firma saß außerhalb der EU)
- Eine Benachrichtigungsprüfung für betroffene Personen
Jeder dieser Punkte bedeutet rechtlichen Aufwand und Zeit.
Mit PII-Entfernung angewendet:
- Verarbeitungszeit: 25 Minuten für 180 MB
- Ausgabe: 180 MB strukturidentische Dateien, alle E-Mails und IPs durch sichere Werte ersetzt
- Ergebnis: Das Pen-Test-Team erhielt den vollen Kontext; keine echten Benutzerdaten gelangten zu ihnen
- DSGVO-Ergebnis: Kein AVV erforderlich — bereinigte Ausgaben sind keine Benutzerdaten gemäß DSGVO
Lesen Sie unsere FAQ zu häufigen Fragen, was unter DSGVO als anonym gilt.
PII-Entfernung in CI/CD integrieren
Für Teams, die regelmäßig Ausgaben teilen, kann dieser Schritt in bestehende Pipelines integriert werden.
Log-Rotation:
- Rotationsskript läuft nächtlich
- Entfernungsschritt läuft vor der Archivierung oder dem Versand an Log-Plattformen
- Bereinigte Dateien gehen an externe Systeme
- Originaldateien verbleiben intern mit voller Aufbewahrung
Vor-Weitergabe-Skript:
- Entwickler muss ein Sample mit einem Auftragnehmer teilen
- Führt das Skript aus:
input=raw-logs/ output=clean-logs/ - Teilt den
clean-logs/-Ordner - Keine manuelle PII-Prüfung nötig
Sidecar-Ansatz:
- Sidecar bereinigt den Ausgabestrom vor der Weiterleitung
- Echtzeit-Bereinigung erhält die Nützlichkeit für die Log-Analyse
- Die Plattform erhält keine echten Benutzerdaten
Aufbewahrungsrichtlinien-Integration
DSGVO-Artikel 5(1)(e) erfordert Speicherbegrenzung. PII-Entfernung passt in jede Aufbewahrungsrichtlinie.
- Rohdaten 7 Tage aufbewahren (für tägliche Debug-Arbeit)
- Bereinigte Versionen 90 Tage aufbewahren (für Trendanalyse und Vorfallsüberprüfung)
- Entfernungsschritt läuft an Tag 7
Dies erfüllt die Speicherbegrenzung. Es beseitigt das Risiko, Rohdaten langfristig zu speichern.