- Logs wie auth.log und syslog gelten als personenbezogene Daten, sobald sie IP-Adressen oder Nutzernamen enthalten.
- Minimieren Sie Daten durch Maskierung von IP-Adressen und Anpassung der Log-Level.
- Beschränken Sie den Zugriff auf autorisierte Personen und verschlüsseln Sie Logs.
- Definieren Sie Aufbewahrungsfristen (6–12 Monate) und setzen Sie diese mit logrotate um.
- Dokumentieren Sie die Rechtsgrundlage (berechtigtes Interesse) im Verzeichnis von Verarbeitungstätigkeiten.
Bestandsaufnahme: Welche Logs sind betroffen?
Bevor Sie Maßnahmen ergreifen, müssen Sie wissen, welche Logdateien auf Ihren Systemen existieren und welche Daten sie enthalten. Dazu gehören typischerweise /var/log/auth.log, /var/log/syslog, Webserver-Logs (z.B. nginx access.log) und Datenbank-Logs (z.B. PostgreSQL).
Kurz gesagt :
- Logs mit IP-Adressen oder Nutzernamen gelten als personenbezogene Daten und unterliegen der DSGVO.
- Datenminimierung durch Maskierung von IP-Adressen (z.B. mit sed) und Reduzierung der Log-Level ist erforderlich.
- Zugriff auf Logs nur für autorisierte Personen (Unix-Gruppen, Berechtigung 640) und Verschlüsselung bei Übertragung/Speicherung.
- Aufbewahrungsfrist von 6–12 Monaten (CNIL-Empfehlung) wird technisch mit logrotate umgesetzt.
Ich empfehle, eine Inventarliste zu erstellen, die jede Logquelle, ihren Speicherort und die enthaltenen Datenfelder dokumentiert. Das ist die Grundlage für Ihr Verarbeitungsverzeichnis nach Art. 30 DSGVO.
- /var/log/auth.log: SSH-Anmeldungen, sudo-Befehle
- /var/log/syslog: allgemeine Systemmeldungen
- /var/log/nginx/access.log: IP-Adressen, User-Agent, angeforderte URLs
- /var/log/postgresql/: SQL-Abfragen, Fehlermeldungen
Diese Liste ist nicht abschließend – prüfen Sie auch Cron-Jobs, Firewall-Logs und Anwendungslogs. Je vollständiger Ihre Inventur, desto besser können Sie Risiken kontrollieren.
Pseudonymisierung und Minimierung: Datenmenge reduzieren
Der Grundsatz der Datenminimierung (Art. 5 DSGVO) verlangt, dass Sie nur die Daten speichern, die für den Zweck (z.B. Sicherheit) notwendig sind. Das bedeutet: Maskieren Sie IP-Adressen, reduzieren Sie die Log-Level und filtern Sie sensible Felder.
Eine einfache Methode ist die Maskierung der letzten Oktette einer IP-Adresse mit sed. So können Sie die Identität des Nutzers verschleiern, während Sie weiterhin Verkehrsmuster analysieren können.
# Beispiel: Nur die ersten 3 Oktette speichern
cat /var/log/nginx/access.log | sed -E 's/([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.)[0-9]{1,3}/\1XXX/g' > /var/log/nginx/anonymized.logZusätzlich sollten Sie die Log-Level anpassen: Stellen Sie von ‘debug’ auf ‘info’ oder ‘warn’ um, um unnötige Details zu vermeiden. Das reduziert nicht nur die Datenmenge, sondern auch den Speicherbedarf.
Ich rate dazu, diese Anonymisierung direkt in der Logverarbeitung zu implementieren, z.B. mit logstash oder fluentd, damit sie automatisch bei jeder Zeile angewendet wird.
Zugriffskontrolle und Verschlüsselung: Wer darf die Logs lesen?
Nur autorisierte Personen (z.B. Systemadministratoren, Sicherheitsteam) sollten Zugriff auf Logdateien haben. Das erreichen Sie durch Unix-Gruppen und restriktive Dateiberechtigungen.
- Erstellen Sie eine Gruppe ‘logreader’:
sudo groupadd logreader - Fügen Sie Benutzer hinzu:
sudo usermod -a -G logreader benutzername - Setzen Sie die Berechtigungen auf 640:
chmod 640 /var/log/auth.log
Verschlüsselung ist ebenfalls wichtig, insbesondere wenn Logs über Netzwerke übertragen oder in der Cloud gespeichert werden. Verwenden Sie bei der Übertragung TLS und bei der Speicherung Verschlüsselung auf Dateisystemebene (z.B. LUKS).
Vergessen Sie nicht, die Zugriffe auf die Logs selbst zu protokollieren (Audit Trail). So können Sie im Falle eines Vorfalls nachvollziehen, wer wann auf welche Daten zugegriffen hat.
Aufbewahrungsfristen definieren: Wie lange speichern?
Die DSGVO verlangt, dass personenbezogene Daten nicht länger als nötig gespeichert werden. Für Sicherheitslogs empfiehlt die CNIL eine Aufbewahrungsfrist von 6 bis 12 Monaten, sofern keine spezifischere gesetzliche Pflicht besteht.
Technisch setzen Sie das mit logrotate um, das tägliche Rotation und automatische Löschung alter Dateien übernimmt. Hier ist ein Beispiel für eine Konfiguration, die Logs 30 Tage lang aufbewahrt:
/var/log/auth.log { daily rotate 30 compress delaycompress postrotate find /var/log -name "*.gz" -mtime +30 -delete endscript
}Passen Sie die Fristen an Ihre Risikobewertung an. Wenn Sie länger speichern müssen (z.B. für forensische Analysen), dokumentieren Sie dies und begründen Sie es im Verzeichnis.
Ich empfehle, die Aufbewahrungsfristen regelmäßig zu überprüfen, da sich gesetzliche Anforderungen ändern können.
Rechtsgrundlage und Transparenz: Das “Warum” dokumentieren
Sie benötigen eine Rechtsgrundlage für die Verarbeitung von Logdaten. Für Sicherheitszwecke ist das berechtigte Interesse nach Art. 6 Abs. 1 lit. f DSGVO die passende Grundlage, sofern Ihre Interessen nicht die Rechte der Betroffenen überwiegen.
Diese Rechtsgrundlage müssen Sie in Ihrer Datenschutzerklärung und im Verzeichnis von Verarbeitungstätigkeiten dokumentieren. Die CNIL prüft bei Kontrollen genau diese Dokumentation.
Ein praktischer Tipp: Führen Sie eine Interessenabwägung durch, in der Sie darlegen, warum die Verarbeitung notwendig ist und wie Sie die Risiken für Betroffene minimieren.
Transparenz bedeutet auch, dass Sie die Betroffenen in Ihrer Datenschutzerklärung informieren, welche Logdaten Sie verarbeiten und zu welchem Zweck. Das ist eine Pflicht nach Art. 13 DSGVO.
Die 3 häufigsten Fehler, die Sie vermeiden sollten
Aus meiner Beratungspraxis kenne ich typische Fehler, die zu DSGVO-Verstößen führen. Vermeiden Sie diese, um Bußgelder zu vermeiden.
- Fehler 1: Klartext-Passwörter in Logs speichern – das ist ein schwerwiegender Verstoß, da Passwörter niemals im Klartext erscheinen dürfen.
- Fehler 2: Unbegrenzte Speicherung – Logs über Jahre hinweg aufzubewahren, ohne Fristen zu definieren, ist ein häufiger Verstoß.
- Fehler 3: Zugriff für alle Entwickler – zu weit gefasste Berechtigungen erhöhen das Risiko von Datenmissbrauch.
Diese Fehler lassen sich vermeiden, indem Sie klare Richtlinien implementieren und regelmäßige Schulungen durchführen.
Häufig gestellte Fragen (FAQ)
Sind IP-Adressen wirklich personenbezogene Daten?
Ja, nach Ansicht der CNIL und des EuGH sind IP-Adressen personenbezogene Daten, wenn sie einer identifizierbaren Person zugeordnet werden können.
Können wir Logs für Sicherheitsanalysen (SIEM) behalten, ohne gegen die DSGVO zu verstoßen?
Ja, wenn Sie die Daten pseudonymisieren und die Speicherdauer im SIEM auf das Nötigste begrenzen, z.B. auf 6 Monate.
Was tun bei einer Datenschutzverletzung in den Logs?
Sie müssen die CNIL innerhalb von 72 Stunden informieren, wenn ein Risiko für die Rechte der Betroffenen besteht.
Praktische Umsetzung: Ein Schritt-für-Schritt-Plan
Hier ist ein konkreter Plan, den Sie in Ihrem Unternehmen umsetzen können. Er basiert auf meinen Erfahrungen aus über 15 Jahren als Systemarchitekt.
- Inventarisieren Sie alle Logquellen.
- Implementieren Sie Anonymisierung für IP-Adressen.
- Richten Sie Zugriffskontrollen ein.
- Definieren Sie Aufbewahrungsfristen und automatisieren Sie die Löschung.
- Dokumentieren Sie die Rechtsgrundlage.
- Schulen Sie Ihr Team.
Dieser Plan ist nicht in Stein gemeißelt – passen Sie ihn an Ihre Infrastruktur an.
Vergleich: Anonymisierung vs. Pseudonymisierung
Beide Begriffe werden oft verwechselt, haben aber unterschiedliche rechtliche Konsequenzen. Hier ist eine Übersicht:
| Kriterium | Anonymisierung | Pseudonymisierung |
|---|---|---|
| Definition | Daten können nicht mehr einer Person zugeordnet werden | Daten können nur mit zusätzlichem Schlüssel zugeordnet werden |
| DSGVO-Anwendung | Nicht mehr anwendbar | Weiterhin anwendbar |
| Beispiel | IP-Adresse vollständig entfernen | IP-Adresse maskieren, Schlüssel separat speichern |
| Risiko | Gering | Mittel, wenn Schlüssel kompromittiert wird |
In der Praxis empfehle ich eine Kombination: Maskieren Sie IP-Adressen (Pseudonymisierung) und speichern Sie die vollständigen Daten nur für kurze Zeit auf einem separaten System.
Wie viel Speicherplatz benötigen Sie für Logs?
Die Größe der Logdateien hängt stark von der Systemlast ab. Ein durchschnittlicher Webserver erzeugt etwa 100 MB pro Tag an Logs, während ein stark frequentierter Server mehrere GB pro Tag erreichen kann.
Bei einer Aufbewahrungsfrist von 30 Tagen benötigen Sie also zwischen 3 GB und 90 GB Speicherplatz. Planen Sie zusätzlich Platz für komprimierte Archive ein.
Ich rate dazu, den Speicherbedarf zu überwachen und bei Bedarf die Log-Level zu reduzieren oder die Aufbewahrungsfrist zu verkürzen.
Meine Meinung: Warum die DSGVO-Konformität bei Logs oft vernachlässigt wird
Aus meiner Erfahrung wird das Thema Logs häufig unterschätzt, weil es technisch komplex erscheint. Viele Unternehmen fokussieren sich auf die offensichtlichen Datenbanken, vergessen aber die Logs, die ebenso sensible Daten enthalten.
Dabei ist die Umsetzung gar nicht so schwierig, wenn man systematisch vorgeht. Die Investition in Anonymisierungswerkzeuge und klare Prozesse zahlt sich aus – nicht nur rechtlich, sondern auch im Hinblick auf das Vertrauen der Kunden.
Wenn Sie Fragen haben oder Unterstützung benötigen, zögern Sie nicht, mich zu kontaktieren.
Schon als Kind war ich fasziniert von der Logik hinter Computern und der unendlichen Welt der Daten. Was als spielerische Neugier mit dem Zerlegen alter PCs begann, entwickelte sich schnell zu einer tiefen Leidenschaft für die Informatik. Heute sehe ich es als meine Berufung, komplexe digitale Themen greifbar zu …
Tous les articles de Anna Berger →
