Einführung: Das Dilemma zwischen Sicherheit und Datenschutz
Als CTO einer SaaS-Plattform habe ich zwei Prioritäten, die oft in Konflikt stehen: die Sicherheit unseres Systems und der Schutz der Nutzerdaten. Logging und Monitoring sind essentiell, um Angriffe abzuwehren, Fehler zu finden und die Performance zu optimieren. Gleichzeitig enthalten Logs oft personenbezogene Daten wie IP-Adressen, Benutzernamen oder E-Mail-Adressen.
In diesem Artikel klären wir auf, wie viel Logging aus Sicht der DSGVO erlaubt ist, welche Daten Sie problemlos speichern dürfen und wo Sie vorsichtig sein müssen. Wir betrachten technische Best Practices im Kontext von SecureLogical und der neuen NIS2-Richtlinie.
Rechtsgrundlage für Logging (Art. 6 DSGVO)
Logging erfolgt meist auf Basis des berechtigten Interesses (Art. 6 Abs. 1 lit. f DSGVO). Das Interesse des Anbieters, ein sicheres und funktionsfähiges System zu betreiben, überwiegt in der Regel das Interesse des Nutzers am Schutz seiner (Meta-)Daten – solange die Verarbeitung verhältnismäßig ist. In einigen Fällen, insbesondere bei kritischen Infrastrukturen, ist Logging durch Art. 32 DSGVO (Sicherheit der Verarbeitung) sogar rechtlich vorgeschrieben.
Was darf geloggt werden? Ein technischer Überblick
Wir unterscheiden drei Arten von Logs mit unterschiedlichen rechtlichen Anforderungen:
1. Security Logs (Sicherheits-relevante Ereignisse)
Hier ist die Speicherung von IP-Adressen meist unproblematisch, um Brute-Force-Angriffe oder SQL-Injections nachverfolgen zu können. Aber Achtung: IP-Adressen sind personenbezogene Daten! Eine Speicherdauer von 7 bis 14 Tagen gilt oft als verhältnismäßig, längere Zeiträume benötigen eine starke Begründung.
2. Error Logs (Fehleranalyse)
Error Logs sollten idealerweise keine personenbezogenen Daten enthalten. Nutzen Sie IDs statt Klarnamen. Vermeiden Sie das Mitloggen von Request-Bodies, die Passwörter oder persönliche Nachrichten enthalten könnten.
3. Audit Logs (Wer hat was wann getan?)
Besonders in der ISO 27001-Zertifizierung sind lückenlose Audit-Logs Pflicht. Hier müssen wir den Spagat schaffen: Die Identität des Handelnden muss nachvollziehbar sein, aber die Daten müssen vor unberechtigtem Zugriff geschützt werden.
Best Practices für DSGVO-konformes Logging
Als CTO empfehle ich folgende technische Strategien:
- Hashing & Maskierung: Speichern Sie keine E-Mails, sondern nur deren Hashes. Maskieren Sie IP-Adressen (z.B. 192.168.xxx.xxx) in Analytics-Logs.
- Strenge Aufbewahrungsfristen: Implementieren Sie automatisierte Löschroutinen. Was nicht mehr für die Sicherheit nötig ist, muss weg.
- Access Control: Wer darf die Logs lesen? Audit-Logs sollten nur für Sicherheits-Verantwortliche zugänglich sein.
- Separierung: Trennen Sie technische Logs von User-Content.
Monitoring und das Problem der Verhaltenskontrolle
Beim Monitoring (z.B. User-Tracking) wird es kritisch. Wenn Monitoring zur Leistungs- oder Verhaltenskontrolle von Mitarbeitern (auf Kundenseite) eingesetzt wird, ist dies mitbestimmungspflichtig und erfordert oft eine explizite Einwilligung. Als SaaS-Anbieter stellen wir die Werkzeuge bereit, müssen aber in unserem AVV darauf hinweisen, dass der Kunde für die rechtmäßige Nutzung der Monitoring-Features verantwortlich ist.
Fazit: Logging als Compliance-Baustein
Sicherheit ohne Logging ist unmöglich. Datenschutzkonformes Logging ist hingegen ein Zeichen von Reife. Durch Techniken wie Anonymisierung (siehe auch unser Deep-Dive zu Anonymisierung) können wir wertvolle System-Insights gewinnen, ohne die Privatsphäre der Nutzer zu gefährden.
Transparenz in der Datenschutzerklärung darüber, was geloggt wird, schafft Vertrauen bei Ihren B2B-Kunden und schützt Sie vor rechtlichen Risiken.
Die Realität des Loggings
Logging ist nicht optional – es ist notwendig für Sicherheit, Compliance und Debugging. Gleichzeitig birgt es Risiken, weil Logs personenbezogene Daten enthalten, die technisch und rechtlich geschützt werden müssen. Die meisten Unternehmen machen es falsch: Sie loggen alles, speichern alles und löschen nie. Logs sind nicht für die Ewigkeit gedacht, sondern für den Moment der Analyse und Sicherheitsüberprüfung. Danach müssen sie weg, sonst werden sie selbst zum Sicherheitsrisiko.
Die Aufbewahrungsfrist-Falle
Viele Unternehmen speichern Logs zu lange mit der Begründung "Vielleicht brauchen wir sie noch". Das ist die falsche Logik. Logs sind nicht für "vielleicht" gedacht, sondern für "jetzt". Wenn ein Sicherheitsvorfall passiert, braucht ihr die Logs sofort, nicht in einem Jahr. In einem Jahr sind sie wertlos oder schlimmer: Sie werden selbst zum Risiko, weil sie personenbezogene Daten enthalten, die längst hätten gelöscht werden müssen.
Implementiert automatisierte Löschroutinen. Was nicht mehr für die Sicherheit nötig ist, muss weg – nicht "vielleicht weg", sondern weg. Das schützt nicht nur den Datenschutz, sondern verbessert auch Performance und senkt Kosten. Alte Logs kosten Geld, viel Geld, und sie bringen keinen Mehrwert mehr.
Die Zugriffskontrolle ist kritisch
Logs sind sensibel, weil sie Informationen über Nutzer, Systeme und Fehler enthalten. Nicht jeder sollte sie sehen, lesen oder exportieren können. Die Zugriffskontrolle ist nicht optional, sie ist überlebenswichtig für die Compliance und den Datenschutz.
Implementiert strikte Zugriffskontrollen: Nur Sicherheits-Verantwortliche, nur mit Berechtigung, nur mit Audit-Trail. Jeder Zugriff muss protokolliert, jeder Export genehmigt und jede Löschung dokumentiert werden. Das ist nicht Bürokratie, das ist Sicherheit und Compliance in einem.
Die Separierung, die jeder braucht
Trennt technische Logs von User-Content. Das ist notwendig. Nicht optional. Technische Logs sind für Debugging. User-Content ist für Funktionen. Beides zusammen ist gefährlich. Für Datenschutz. Für Sicherheit. Für Compliance.
Ich habe Systeme gesehen. Systeme ohne Separierung. Systeme, die alles zusammen speichern. Systeme, die Probleme haben. Nicht weil die Technik schlecht ist. Sondern weil die Separierung fehlt.
Separiert Logs. Technisch. Organisatorisch. Rechtlich. Das ist notwendig. Nicht optional. Notwendig. Ohne Separierung ist es riskant. Sehr riskant.
Die Monitoring-Verantwortung
Monitoring ist nicht nur technisch. Es ist auch rechtlich. Wenn Monitoring zur Verhaltenskontrolle genutzt wird, ist es mitbestimmungspflichtig. Das ist die Realität. Die Realität, die jeder ignoriert.
Ich habe Projekte gesehen. Projekte mit Monitoring. Projekte ohne Mitbestimmung. Projekte, die abgemahnt werden. Nicht weil die Technik schlecht ist. Sondern weil die Mitbestimmung fehlt.
Kommuniziert Monitoring. Transparent. Vollständig. Rechtlich. Das ist notwendig. Nicht optional. Notwendig. Ohne Kommunikation ist es rechtswidrig. Egal wie gut die Technik ist.
