Serverprotokolle enthalten IP-Adressen, Benutzernamen, Zeitpunkte, manchmal ganze Anfragepfade. Damit sind sie personenbezogene Daten und unterliegen denselben Grundsätzen wie jede andere Verarbeitung: Zweckbindung, Datenminimierung, Speicherbegrenzung.
Es besteht ein echter Zielkonflikt: Sicherheit will lange Aufbewahrung, Datenschutz will kurze. Auflösbar ist er nur, wenn Zweck und Frist je Protokollart festgelegt sind und zwar bevor jemand fragt. Keine Rechtsberatung: Die maßgeblichen Grundlagen sind Art. 5, 6 und 32 DSGVO sowie die Hinweise der zuständigen Aufsichtsbehörde; die Bewertung des Einzelfalls gehört zu einer Anwältin oder einem Anwalt.
Zuerst: Welcher Zweck?#
Der Zweck bestimmt die Frist, nicht umgekehrt. Für Serverprotokolle sind in der Praxis zwei Zwecke tragfähig:
- Betrieb und Fehlersuche, kurzfristig, Tage bis wenige Wochen.
- Erkennung und Aufklärung von Angriffen, das ist der Zweck, der längere Fristen trägt; die Sicherheit der Verarbeitung ist selbst eine Pflicht (Art. 32).
Was nicht trägt: „könnte man mal brauchen“. Und was mit derselben Sorgfalt zu betrachten ist: Auswertungen, die aus Protokollen Nutzungsprofile machen, das ist ein anderer Zweck als Angriffserkennung.
Fristen, die sich begründen lassen#
| Protokollart | Übliche Größenordnung | Grund |
|---|---|---|
| Webserver-Zugriffe | 7-30 Tage | Fehlersuche, Missbrauchserkennung |
Anmeldungen und sudo | 30-90 Tage | Nachvollziehbarkeit bei Vorfällen |
| Firewall-Verwürfe | 7-30 Tage | Mustererkennung, viel Volumen |
| Zentrale Kopie beim Empfänger | 90 Tage | Vorfälle fallen oft erst spät auf |
| Ergebnisse eines Vorfalls | dauerhaft, getrennt | eigener Zweck, eigene Grundlage |
Die letzte Zeile ist wichtig: Was zu einem konkreten Vorfall gehört, wird herausgelöst und getrennt aufbewahrt, mit eigenem Zweck (Beweissicherung, Meldepflicht) und eigener Frist. Der Rest läuft weiter ab, wie vorgesehen.
Technisch erzwingen statt dokumentieren#
Eine Frist, die nur in einem Dokument steht, ist keine.
# /etc/systemd/journald.conf — Journal begrenzen
[Journal]
Storage=persistent
SystemMaxUse=1G
MaxRetentionSec=90day
# /etc/logrotate.d/nginx — 14 Tage, komprimiert
/var/log/nginx/*.log {
daily
rotate 14
compress
delaycompress
missingok
notifempty
create 0640 www-data adm
}
sudo systemctl restart systemd-journald
sudo logrotate -d /etc/logrotate.d/nginx # Trockenlauf zeigt, was passieren würdeGegenprobe, ob die Frist wirklich greift:
ls -l --time-style=long-iso /var/log/nginx/ | head
journalctl --list-boots | head -3
journalctl --disk-usageProtokolle wandern auf ein zweites System (Protokolle, die den Angreifer überleben) und dort laufen sie oft unbegrenzt weiter, weil die Rotation nur lokal eingerichtet wurde. Die Frist gehört an beide Stellen; die längere von beiden ist die, die zählt. Dasselbe gilt für Sicherungen, die Protokollverzeichnisse mitnehmen.
Weniger protokollieren ist auch eine Maßnahme#
Datenminimierung lässt sich technisch umsetzen, ohne die Erkennung zu verlieren:
# IP-Adresse gekürzt protokollieren (letztes Oktett bzw. Interface-Teil entfernt)
map $remote_addr $ip_gekuerzt {
~(?<v4>\d+\.\d+\.\d+)\. "$v4.0";
~(?<v6>[^:]+:[^:]+): "$v6::";
default "0.0.0.0";
}
log_format gekuerzt '$ip_gekuerzt - [$time_local] "$request" $status $body_bytes_sent';
access_log /var/log/nginx/access.log gekuerzt;Das reicht für Statistik und grobe Mustererkennung. Für die Angriffsaufklärung reicht es nicht, dort braucht man die vollständige Adresse. Ein gangbarer Mittelweg: vollständig im Sicherheitsprotokoll mit kurzer Frist, gekürzt im allgemeinen Zugriffsprotokoll mit längerer.
Was in die Datenschutzerklärung gehört#
Kurz, konkret, ohne Textbaustein-Nebel: welche Daten (IP-Adresse, Zeitpunkt, angefragte Ressource, Kennung des Programms), zu welchem Zweck, auf welcher Grundlage, wie lange, und wer sie sonst noch sieht (Anbieter, vorgelagerter Dienst, Überwachung).
Genau diese Angaben braucht auch der Auftragsverarbeitungsvertrag mit Kunden (Auftragsverarbeitung), es lohnt, beides in einem Zug zu schreiben.
Geschrieben aus dem laufenden Betrieb: MRMedia betreibt eigene Hosts, Kundendienste und deren Härtung in der EU. Eine veraltete Anleitung ist hier ein Sicherheitsproblem, kein Schönheitsfehler. Korrekturen bitte über Discord.
