DSGVO-konforme Logs und deren Backups – was, wie lange und wo

Dieser Artikel richtet sich an IT-Verantwortliche, Agenturen und Geschäftsführungen, die Linux-Infrastrukturen betreiben – von einzelnen Debian-Servern in der Cloud bis zu komplexeren Setups im Managed Hosting. Wir erklären verständlich, wie Sie Server-Logs so planen und konfigurieren, dass sie im täglichen Betrieb wirklich helfen und zugleich DSGVO-konform bleiben. Zuerst klären wir die Grundlagen und organisatorischen Fragen. Am Ende folgen zwei häufig genutzte Praxisbeispiele (Debian systemd-journald und Nginx) als direkt einsetzbare Referenz.

Inhaltsverzeichnis

1) Warum Logs (oft) personenbezogene Daten sind – und was daraus folgt

In Logdateien stehen typischerweise IP-Adressen, Zeitstempel, aufgerufene Pfade und User-Agent-Strings. IP-Adressen gelten als Online-Kennungen und sind damit grundsätzlich personenbezogene Daten im Sinne der DSGVO. Daraus folgen die Grundsätze Datenminimierung und Speicherbegrenzung sowie Anforderungen an die Sicherheit der Verarbeitung. Für die Praxis heißt das: Definieren Sie vorab, wofür Sie Logs wirklich benötigen – etwa Betriebssicherheit, Fehleranalyse und Angriffserkennung – und beschränken Sie Umfang sowie Dauer der Speicherung auf das Notwendige. Ergänzen Sie das um technische und organisatorische Maßnahmen, damit die Vorgaben nicht nur auf Papier, sondern im System wirken.

Transparenz ist Teil der Compliance und schadet der Operativität nicht. Beschreiben Sie in Ihrer Datenschutzerklärung in klarer Sprache, dass und wozu Sie Server-Zugriffe protokollieren, welche Datenkategorien dabei anfallen, wie lange Sie speichern und wer Zugriff hat. Damit sind Sie in der Lage, auf Kund:innen- und Behördenfragen präzise zu antworten – ohne Hektik im Incident.

2) Zwecke, Rechtsgrundlagen und Verständlichkeit statt Juristendeutsch

Bevor Sie Konfigurationsdateien anfassen, legen Sie die Zwecke in verständlichen Sätzen fest. Ein Beispiel: „Wir speichern Webserver-Zugriffe, um Fehler schneller zu finden, Angriffe abzuwehren und die Verfügbarkeit unserer Dienste nachzuweisen.“ Diese Zwecke stützen sich in vielen Fällen auf berechtigte Interessen (Art. 6 Abs. 1 lit. f DSGVO). Wenn Gesetze oder Verträge eine Aufbewahrung erfordern, kann zusätzlich Art. 6 Abs. 1 lit. c greifen. Entscheidend ist die Begründung: Welcher konkrete Nutzen entsteht aus der Speicherung? Welche Risiken mindern Sie? Welche Alternativen wurden verworfen und warum? Wenn Sie das sauber dokumentieren, wird die spätere technische Umsetzung deutlich leichter – auch, weil alle Beteiligten dasselbe Zielbild haben.

Siehe auch Freche und verrückte Guten-Morgen-Sprüche

Zur Verständlichkeit gehört, dass Sie intern Rollen und Zugriffe benennen. Wer darf Logs im Volltext einsehen? Wer erhält nur aggregierte Ansichten? Wer entscheidet über Freigaben nach außen? Diese Fragen sind nicht juristisch, sondern betriebspraktisch – und sie verhindern später Diskussionen im Betrieb.

3) Speicherbegrenzung greifbar machen: Retention als technischer Standard

Die DSGVO nennt keine fixen Aufbewahrungszahlen. Sie verlangt, dass personenbezogene Daten nicht länger als notwendig gespeichert werden und dass es Löschfristen beziehungsweise regelmäßige Überprüfungen gibt. In vielen Organisationen hat sich ein zweistufiger Ansatz bewährt: Für Web-Access-Logs reicht oft eine kurze Vollhaltezeit von sieben bis dreißig Tagen; für System-/SSH-Logs – abhängig von Risiko, Audit-Bedarf und SLA – eher vierzehn bis neunzig Tage. Für längerfristige Auswertungen (Trends, Kapazitätsplanung) arbeiten Sie anschließend mit anonymisierten oder pseudonymisierten Daten, z. B. IP-Kürzung.

Wichtig ist nicht die „richtige Zahl“, sondern Kohärenz: Wie lange treten typische Vorfälle unentdeckt auf? Wie weit müssen Sie forensisch zurückschauen können? Welche Wiederherstellungs- und Nachweispflichten haben Sie intern bzw. gegenüber Kundschaft? Wenn Sie diese Fragen beantworten, ergibt sich die Retention häufig „von selbst“. Technische Limits (zeit- und größenbasiert) stellen anschließend sicher, dass Entscheidungen auch bei Personalwechseln und Stresssituationen eingehalten werden.

4) Zentrale Logablage, Rollen und Zugriff – die organisatorische Seite der Sicherheit

Technik allein genügt nicht. Legen Sie fest, wer worauf zugreifen darf, und ordnen Sie Rechte Rollen zu. In kleineren Teams reicht oft die Regel „Administrator:innen nach Bedarf“, in größeren Setups empfehlen sich sauber getrennte Rollen für Betrieb, Security und Auditing samt Vier-Augen-Prinzip für sensible Bereiche. Wenn Sie Logs zentral sammeln – etwa in ELK/Opensearch oder einem SIEM – definieren Sie Maskierungs- und Anonymisierungsregeln bereits beim Ingest, damit sensible Felder gar nicht erst ungefiltert in nachgelagerte Systeme gelangen. Pro Index bzw. Bucket sollten dokumentierte Retention-Regeln gelten, die zu Ihren oben beschriebenen Zeitfenstern passen.

Auf vertraglicher Ebene gehören Auftragsverarbeitungsverträge (AVV/DPA) mit Dienstleistern dazu. Darin regeln Sie Zwecke, Kategorien, technische und organisatorische Maßnahmen (TOMs), Unterauftragsverarbeiter sowie Rückgabe- und Löschkonzepte. Wenn Daten außerhalb der EU/EWR verarbeitet werden müssen, sorgen geeignete Garantien und eine klare Technikstrategie (z. B. clientseitige Verschlüsselung, Key-Trennung) dafür, dass die Anforderungen der DSGVO erfüllt werden, ohne Ihren Betrieb zu lähmen.

Siehe auch Erfolgreiche Strategien für den Einstieg im neuen Job

5) DSGVO-konforme Backups von Logdateien – Anforderungen ohne Tool-Dogma

Dieser Abschnitt dreht sich ausschließlich um Backups von Logdateien (nicht um generische Datenbackups). Unterschiedliche Umgebungen nutzen unterschiedliche Werkzeuge; maßgeblich sind die Anforderungen – nicht ein bestimmtes Tool.

Verschlüsselung: Legen Sie Log-Backups verschlüsselt ab, idealerweise clientseitig, sodass der Speicheranbieter ohne Schlüssel nichts lesen kann. Bewahren Sie Schlüssel getrennt auf, mit geregeltem Zugriff und dokumentiertem Recovery-Prozess. Das ist unmittelbar aus Art. 32 ableitbar (angemessene technische und organisatorische Maßnahmen, u. a. Verschlüsselung und die Fähigkeit zur Wiederherstellung).

Retention der Backups: Richten Sie die Lebensdauer der Log-Backups am Lebenszyklus der Logs aus. Wenn Sie Access-Logs im aktiven System 30 Tage vollständig halten und danach anonymisieren, ist es inkonsistent, volle Log-Backups sechs Monate zu bewahren. Besser ist eine abgestufte Strategie: kurze Vollhaltezeit im Backup (z. B. 30–60 Tage), anschließend anonymisierte oder stärker aggregierte Logstände für Analysen über längere Zeiträume. Wichtig ist die Konsistenz: Was im Live-System anonymisiert ist, sollte nicht in Backups jahrelang in voller Form überleben.

Speicherort & Verträge: Speichern Sie Log-Backups vorzugsweise in der EU/EWR oder treffen Sie bei Drittlandübermittlungen geeignete Garantien. Schließen Sie mit Providern AVV/DPA, die Zweck, Kategorien, TOMs, Unterauftragsverarbeiter, Rückgabe-/Löschkonzepte und Audit-Rechte regeln. Lifecycle-Policies (z. B. auf Object-Storage) helfen, Löschfristen technisch umzusetzen.

„Löschen aus Backups“ / „Beyond Use“: In der Praxis akzeptieren Aufsichtsbehörden häufig, dass Daten nach einem Löschersuchen im Live-System sofort entfernt und in Backups bis zum Ablauf der definierten Retention „beyond use“ gehalten werden – also verschlüsselt, ohne produktiven Zugriff, ausschließlich zur Desaster-Wiederherstellung. Entscheid end ist, dass das Verfahren dokumentiert ist und Backups nicht für andere Zwecke genutzt werden.

Regelmäßige Restores: Ein Backup ist nur so gut wie der Restore. Planen Sie mindestens halbjährlich Tests, in denen Sie stichprobenartig Log-Backups wiederherstellen, Integrität und Lesbarkeit prüfen und nachvollziehen, ob die Anonymisierung wie vorgesehen umgesetzt wurde. Das ist gelebte IT-Sicherheit und reduziert Risiken im Incident.

6) Schrittweise Umsetzung: von der Policy zur Config

Beginnen Sie mit einem kurzen Policy-Dokument „Server-Logging“: Zweck(e), Rechtsgrundlage, Datentypen, Retention (aktiv/anonymisiert), Verantwortlichkeiten, Zugriffsrollen, Speicherorte, Backup-Regeln, Verfahren bei Löschersuchen (inkl. „beyond use“). Dieses Dokument ist Ihr roter Faden für technische Defaults und Audits.

Siehe auch Warum professionelles Webdesign über Optik hinausgeht

Übertragen Sie die Policy anschließend in technische Einstellungen. Auf Systemebene setzen Sie die Retention hart durch (zeit- und größenbasiert). Auf Webebene sorgen Sie dafür, dass IP-Adressen im Access-Log gekürzt werden und – sofern Nginx hinter einem Proxy steht – die echte Client-IP vor der Kürzung korrekt ermittelt wird. Testen Sie Änderungen in einer Staging-Umgebung und arbeiten Sie bei Basisdiensten mit zwei parallelen SSH-Sessions, um sich nicht auszusperren. Binden Sie Ihr zentrales Logging an die neuen Regeln: Maskierung beim Ingest, konsistente Index-/Bucket-Policies, durchgängige Zugriffsrollen und klare Regeln für Export/Teilen von Logs.

Für viele Unternehmen ist es sinnvoll, diese Standards anschließend in Ansible-Rollen zu gießen und damit auf allen Systemen reproduzierbar zu machen. Das reduziert manuellen Aufwand, erleichtert Audits und sorgt für konsistente Linux Systemadministration in heterogenen Umgebungen.

Wenn Sie Unterstützung beim DSGVO-konformen Debian Linux Hosting suchen, steht Ihnen der deutsche Linux Support der Blunix GmbH aus Berlin 24 Stunden am Tag, auch kurzfristig in Notfällen, zur Verfügung.

7) Zwei häufige Praxisbeispiele – zuerst die Theorie, jetzt die bewährten Defaults

Zum Schluss zwei kompakte Beispiele, die Sie in vielen Debian-/Nginx-Setups nahezu unverändert verwenden können. Sie sind bewusst minimal gehalten und lassen sich in Managed Linux Hosting, Eigenbetrieb oder Cloud-Instanzen gleichermaßen nutzen.

Beispiel A: Journald-Drop-in für feste Retention unter Debian

# /etc/systemd/journald.conf.d/90-retention.conf
[Journal]
Storage=persistent
SystemMaxUse=1G
SystemKeepFree=500M
MaxFileSec=1w
MaxRetentionSec=30day

Aktivieren Sie die Änderung mit „systemctl restart systemd-journald“. Für Ad-hoc-Bereinigungen stehen „journalctl –vacuum-time=“ und „–vacuum-size=“ bereit; sie sind nützlich, ersetzen aber keine feste Policy.

Beispiel B: Nginx-Access-Logs mit IP-Kürzung (map + eigenes log_format)

# /etc/nginx/conf.d/anonymize.conf (http{}-Kontext)
map $remote_addr $anon_ip {
~^(?<a>\d+\.\d+\.\d+)\.\d+$ $a.0; # IPv4: letztes Oktett maskieren
~^(?<p>[^:]+:[^:]+:[^:]+):.+$ $p::; # IPv6: hintere Hextets kappen
default 0.0.0.0;
}

log_format anon '$anon_ip - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent"';

access_log /var/log/nginx/access.log anon;

Steht Nginx hinter einem Load-Balancer/CDN, stellen Sie vor der Kürzung die korrekte Client-IP via „set_real_ip_from“, „real_ip_header“ und „real_ip_recursive“ sicher.