DSGVO relevante Log Aufbewahrung unter Linux: Fristen technisch umsetzen

1. DSGVO und Server-Logs: Was als personenbezogenes Datum gilt

Eine DSGVO Log Aufbewahrung beginnt mit einer oft unterschätzten Feststellung: Praktisch jedes Server-Log auf einem Linux System enthält personenbezogene Daten. IP-Adressen gelten nach ständiger Rechtsprechung und Auffassung der Aufsichtsbehörden als personenbezogenes Datum, sobald der Betreiber theoretisch in der Lage ist, mit zumutbarem Aufwand einen Personenbezug herzustellen, etwa über den Provider. Damit unterliegen Webserver-Logs, SSH-Logs und Applikationslogs vollständig dem Regime der DSGVO.

Für die DSGVO Log Aufbewahrung bedeutet das konkret: Speicherung, Verarbeitung und irgendwann auch Löschung dieser Logs müssen einer Rechtsgrundlage nach Artikel 6 DSGVO folgen, meist dem berechtigten Interesse an IT-Sicherheit und Fehleranalyse. Diese Rechtsgrundlage trägt aber nicht unbegrenzt, sondern nur für eine Aufbewahrungsdauer, die dem Zweck angemessen ist. Eine unbegrenzte Aufbewahrung "nur für den Fall der Fälle" widerspricht dem Grundsatz der Speicherbegrenzung aus Artikel 5 Absatz 1 Buchstabe e DSGVO.

Wichtig für die technische Umsetzung der DSGVO Log Aufbewahrung ist die Unterscheidung zwischen operativen Logs für Debugging und Monitoring einerseits, und sicherheitsrelevanten Logs für Incident Response andererseits. Beide Kategorien haben typischerweise unterschiedliche, jeweils begründbare Aufbewahrungsfristen, die in der Logrotate- und Retention-Konfiguration getrennt abgebildet werden sollten.

2. Rechtsgrundlagen und Aufbewahrungsfristen für Zugriffslogs

Die DSGVO selbst nennt keine konkrete Zahl von Tagen für die DSGVO Log Aufbewahrung von Server-Zugriffslogs. Stattdessen gilt der Grundsatz, dass die Frist am tatsächlichen Zweck bemessen werden muss. In der Praxis und nach Orientierungshilfen deutscher Aufsichtsbehörden haben sich für reine Webserver-Zugriffslogs sieben bis vierzehn Tage als üblich etabliert, sofern kein konkreter Sicherheitsvorfall vorliegt, der eine längere Aufbewahrung rechtfertigt.

Für sicherheitsrelevante Logs wie Auditd-Protokolle, fehlgeschlagene Anmeldeversuche oder Firewall-Logs ist eine längere Frist von mehreren Monaten bis zu einem Jahr regelmäßig vertretbar, weil das berechtigte Interesse an der Aufklärung von Sicherheitsvorfällen eine intensivere Aufbewahrung rechtfertigt. Entscheidend für jede DSGVO Log Aufbewahrung ist, diese Fristen vorab festzulegen, zu dokumentieren und dann auch technisch konsequent durchzusetzen, statt Logs unbegrenzt anwachsen zu lassen.

#!/usr/bin/env bash
# Audit current log retention across common Linux log sources
set -euo pipefail

echo "== Nginx/Apache access log rotation config =="
grep -A2 "access.log" /etc/logrotate.d/nginx 2>/dev/null || echo "No explicit rotation found"

echo "== journald retention policy =="
grep -E '^(MaxRetentionSec|SystemMaxUse)' /etc/systemd/journald.conf

echo "== Oldest log entries currently on disk =="
find /var/log -name "*.log*" -printf '%T+ %p\n' 2>/dev/null | sort | head -5

3. Logrotate und Retention-Policies technisch umsetzen

Die einfachste technische Grundlage für DSGVO Log Aufbewahrung unter Linux ist logrotate, weil es Rotation, Komprimierung und automatisches Löschen nach einer definierten Anzahl von Zyklen in einer einzigen Konfigurationsdatei vereint. Der entscheidende Parameter ist maxage, der unabhängig von der Dateigröße erzwingt, dass Log-Dateien nach einer festen Anzahl von Tagen tatsächlich gelöscht werden, statt nur unbegrenzt weiter rotiert zu werden.

Ein häufiger Konfigurationsfehler bei der DSGVO Log Aufbewahrung ist, rotate ohne maxage zu setzen. Die Zahl bei rotate gibt nur die Anzahl der aufbewahrten Rotationsdateien an, nicht die Zeitspanne. Bei sehr geringem Log-Aufkommen kann eine Rotation über zwanzig Zyklen theoretisch Monate oder Jahre an Daten enthalten, ohne dass dies auf den ersten Blick erkennbar ist. maxage schließt diese Lücke zuverlässig.

# /etc/logrotate.d/nginx-dsgvo
# GDPR compliant retention: rotate daily, delete after 14 days regardless of count

/var/log/nginx/access.log {
    daily
    rotate 14
    maxage 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        systemctl reload nginx > /dev/null 2>&1 || true
    endscript
}

# Security relevant logs: longer retention justified by legitimate interest
/var/log/auth.log {
    weekly
    rotate 26
    maxage 180
    compress
    delaycompress
    missingok
}

4. Pseudonymisierung und IP-Kürzung in Logs

Ein zentraler technischer Baustein jeder DSGVO Log Aufbewahrung ist die Pseudonymisierung von IP-Adressen direkt beim Schreiben des Logs, statt sie im Klartext über die gesamte Aufbewahrungsdauer zu speichern. Die verbreitetste Methode ist die IP-Kürzung: Bei IPv4 wird das letzte Oktett entfernt, bei IPv6 die letzten 80 Bit. Dieses Verfahren wird von deutschen Aufsichtsbehörden explizit als datenschutzfreundliche Praxis anerkannt.

Alternativ kann eine kryptografische Pseudonymisierung mit einem geheimen Salt und Hash-Funktion eingesetzt werden, wenn Analysezwecke eine eindeutige, aber nicht direkt zuordenbare Wiedererkennung derselben IP über mehrere Log-Einträge hinweg benötigen, etwa zur Erkennung von Brute-Force-Mustern. Für die DSGVO Log Aufbewahrung gilt: Je früher im Verarbeitungsprozess die Pseudonymisierung stattfindet, desto geringer das Risiko, dass unpseudonymisierte Rohdaten versehentlich über die reguläre Frist hinaus liegen bleiben.

#!/usr/bin/env bash
# Anonymize IPv4 last octet and IPv6 last 80 bits in an existing access log
set -euo pipefail

INPUT="/var/log/nginx/access.log"
OUTPUT="/var/log/nginx/access-anonymized.log"

awk '{
  ip = $1
  if (ip ~ /^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$/) {
    n = split(ip, octets, ".")
    ip = octets[1] "." octets[2] "." octets[3] ".0"
  } else if (ip ~ /:/) {
    split(ip, groups, ":")
    ip = groups[1] ":" groups[2] ":" groups[3] "::0"
  }
  $1 = ip
  print
}' "$INPUT" > "$OUTPUT"

echo "Anonymized log written to $OUTPUT"

5. Zentralisiertes Logging mit rsyslog/journald absichern

Sobald Logs zentral gesammelt werden, etwa über rsyslog an einen zentralen Log-Server, wird die DSGVO Log Aufbewahrung zusätzlich komplexer, weil nun auch Übertragung und Zugriffskontrolle auf dem zentralen System berücksichtigt werden müssen. Verschlüsselte Übertragung per TLS zwischen Quellsystem und Log-Server ist Pflicht, sobald personenbezogene Daten das lokale System verlassen, weil sonst ein zusätzliches Risiko unbefugter Kenntnisnahme entsteht.

Zugriffskontrolle auf zentral gesammelte Logs muss dem Prinzip der Datenminimierung folgen: Nur Personen mit tatsächlichem betrieblichem Bedarf, etwa Incident-Response-Verantwortliche, sollten Zugriff auf unpseudonymisierte Rohdaten haben. Ein Vier-Augen-Prinzip oder zumindest eine protokollierte Zugriffskontrolle auf den zentralen Log-Server unterstützt die Nachweispflicht der DSGVO Log Aufbewahrung gegenüber der Aufsichtsbehörde erheblich.

6. Löschkonzepte und automatisierte Log-Vernichtung

Ein schriftliches Löschkonzept ist für eine belastbare DSGVO Log Aufbewahrung unverzichtbar und sollte für jede Log-Kategorie festhalten: welcher Log-Typ, welche Aufbewahrungsfrist, welche Rechtsgrundlage, welcher technische Löschmechanismus und wer die Löschung verantwortet. Die technische Umsetzung sollte automatisiert erfolgen, weil manuelles Löschen erfahrungsgemäß vergessen wird, sobald der ursprüngliche Anlass in Vergessenheit gerät.

# ansible/roles/gdpr-log-retention/tasks/main.yml
# Enforce documented GDPR retention periods per log category

- name: Deploy retention config for standard access logs (14 days)
  template:
    src: logrotate-access.j2
    dest: /etc/logrotate.d/access-dsgvo
  vars:
    max_age_days: 14

- name: Deploy retention config for security relevant logs (180 days)
  template:
    src: logrotate-security.j2
    dest: /etc/logrotate.d/security-dsgvo
  vars:
    max_age_days: 180

- name: Verify no log file exceeds the documented retention window
  find:
    paths: /var/log
    age: 190d
    recurse: yes
  register: overdue_logs

- name: Alert if logs beyond documented retention are found
  debug:
    msg: "GDPR retention violation: {{ overdue_logs.files | map(attribute='path') | list }}"
  when: overdue_logs.matched > 0

7. Auskunftsrecht: Betroffene Logeinträge auffindbar machen

Artikel 15 DSGVO gibt betroffenen Personen ein Auskunftsrecht über gespeicherte personenbezogene Daten, was auch für Log-Einträge gilt, sofern der Personenbezug nicht durch Pseudonymisierung ausreichend erschwert wurde. Für die DSGVO Log Aufbewahrung bedeutet das, dass ein Server-Betreiber theoretisch in der Lage sein muss, Log-Einträge zu einer bestimmten IP-Adresse innerhalb eines angemessenen Zeitraums aufzufinden.

In der Praxis wird diese Anforderung meist durch die kurze Aufbewahrungsfrist selbst entschärft: Wenn Rohdaten nur vierzehn Tage vorgehalten werden und danach pseudonymisiert oder gelöscht sind, reduziert sich der Umfang möglicher Auskunftsanfragen erheblich. Zentrale Suchwerkzeuge wie journalctl mit Zeitfilter oder grep über rotierte, noch nicht gelöschte Logs genügen für die meisten praktischen Auskunftsfälle innerhalb dieser Frist.

8. Dokumentationspflichten und Verarbeitungsverzeichnis

Artikel 30 DSGVO verlangt ein Verzeichnis von Verarbeitungstätigkeiten, in das auch die DSGVO Log Aufbewahrung als eigener Verarbeitungsvorgang gehört. Der Eintrag sollte Zweck der Verarbeitung, Kategorien betroffener Daten, Aufbewahrungsfrist, Rechtsgrundlage und technische sowie organisatorische Maßnahmen wie Verschlüsselung und Zugriffskontrolle enthalten.

{
  "verarbeitungstaetigkeit": "Server-Zugriffsprotokollierung (Webserver, SSH, Applikation)",
  "zweck": "IT-Sicherheit, Fehleranalyse, Missbrauchserkennung",
  "rechtsgrundlage": "Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse)",
  "kategorien_betroffener_daten": ["IP-Adresse", "Zeitstempel", "angeforderte URL", "User-Agent"],
  "aufbewahrungsfrist": {
    "standard_zugriffslogs": "14 Tage, danach Loeschung",
    "sicherheitsrelevante_logs": "180 Tage, danach Loeschung"
  },
  "technische_massnahmen": ["IP-Kuerzung nach Schreibvorgang", "TLS-Uebertragung an zentralen Log-Server", "automatisierte Loeschung via logrotate maxage"],
  "verantwortlich": "IT-Betrieb",
  "letzte_pruefung": "2026-07-30"
}

9. Aufbewahrungsfristen im Vergleich

Die folgende Tabelle ordnet gängige Log-Typen nach typischer DSGVO Log Aufbewahrung, wie sie sich aus Praxis und Orientierungshilfen der Aufsichtsbehörden ergibt.

Die letzte Zeile der Tabelle zeigt eine wichtige Ausnahme: Nicht jede längere Aufbewahrung verstößt gegen die DSGVO Log Aufbewahrung, wenn eine eigene gesetzliche Aufbewahrungspflicht wie bei steuerrelevanten Daten greift. Entscheidend ist, diese Kategorien technisch und organisatorisch klar von den üblichen kurzfristigen Zugriffslogs zu trennen.

10. Zusammenfassung

Eine rechtssichere DSGVO Log Aufbewahrung unter Linux beginnt mit der Erkenntnis, dass IP-Adressen und andere Log-Inhalte personenbezogene Daten sind, gefolgt von klar definierten, dokumentierten Aufbewahrungsfristen pro Log-Kategorie. logrotate mit dem Parameter maxage setzt diese Fristen technisch zuverlässig durch, während IP-Kürzung oder kryptografische Pseudonymisierung das Risiko während der Aufbewahrungsdauer selbst reduzieren.

Zentralisiertes Logging erfordert zusätzlich verschlüsselte Übertragung und restriktive Zugriffskontrolle, während ein schriftliches Löschkonzept und ein aktueller Verarbeitungsverzeichnis-Eintrag die Nachweispflicht gegenüber der Aufsichtsbehörde erfüllen. Wer diese Elemente kombiniert, betreibt DSGVO Log Aufbewahrung, die forensisch nützlich bleibt, ohne unnötige rechtliche Risiken durch überlange Speicherung einzugehen.

11. FAQ: DSGVO relevante Log Aufbewahrung unter Linux