Am 21. Oktober, als PHP2Shell öffentlich wurde, veröffentlichte das Threat-Intelligence-Team von Amazon eine Zeile, die jeder Incident Responder zweimal hätte lesen sollen: Untersuchen Sie mindestens ab dem 17. Oktober. Vier Tage vor der Offenlegung.
Eine Frage an Ihr Team: Haben Sie noch Ihre Web-Server-Logs vom 17. Oktober?
If they rotate every seven days, the honest answer to "were we hit before anyone knew about this?" is "we'll never find out".
Fragen Sie nun Ihren DPO, wie lange Sie diese Logs aufbewahren sollten. Eine andere Antwort. Sie enthalten IP-Adressen, Benutzer-IDs, Session-Daten, manchmal ganze Request-Bodies. Personenbezogene Daten, für einen Sicherheitszweck aufbewahrt, den niemand schriftlich festgehalten hat, für einen Zeitraum, den niemand bewusst gewählt hat.
Dieselben Logs, zwei Personen, zwei Bedenken. Beide berechtigt.
Zwei Dogmen an einem Tisch
Das Sicherheitsdogma: alles loggen, unbegrenzt aufbewahren, Speicher ist günstig und man weiß nie. Es entstammt einer echten Erfahrung. Jeder Incident Responder hat die Sackgasse erlebt, an der die Spur abbricht, weil die Logs eine Woche zuvor überschrieben wurden.
Das Datenschutzdogma: so wenig wie möglich loggen, so kurz wie möglich aufbewahren. Ebenfalls aus einer echten Erfahrung. Ein Log-Speicher, der unbegrenzt alles über jeden festhält, wird zur Überwachungsdatenbank und zu einem der attraktivsten Angriffsziele im Unternehmen. Die CNIL hat genau dieses Risiko in ihrer eigenen Leitlinie benannt: Log-Datenmengen, die groß genug sind, um angegriffen oder für nicht vorgesehene Zwecke genutzt zu werden.
Each side is right about its own risk. Neither works as a default. "Forever" isn't a retention period, and "as short as possible" isn't one either.
Anmerkung aus der Praxis: In practice, there's rarely a second person at that table. In the ISO 27001 audits I run, the DPO is almost never consulted on logging. It surprises me every time, and it's one of the minor nonconformities I raise most often. The security team picks a retention period, the tool applies it, and the person whose job is to ask "why do we keep this?" finds out during the audit. GDPR Article 38 already requires the DPO to be involved, properly and in good time, in every issue relating to personal data. Logs are one of them.
Was die Regelwerke tatsächlich sagen
Hier liegt der Schlüssel zur Auflösung der Blockade. Keine Regelung nennt eine universelle Zahl. Und alle stellen dieselbe Anforderung.
GDPR verlangt Datenminimierung und Speicherbegrenzung. Gleichzeitig fordert Article 32 geeignete Sicherheitsmaßnahmen, und Recital 49 anerkennt eine Verarbeitung, die für die Netz- und Informationssicherheit strikt erforderlich und verhältnismäßig ist, als berechtigtes Interesse. Logging ist also rechtmäßig. Logging ohne definierten Zweck ist der Punkt, an dem es problematisch wird.
Die CNIL-Empfehlung von 2021, one of the most detailed pieces of regulator guidance on the subject, gives six months to a year for application logs that trace who accessed and changed what. Longer is possible with a justification, up to three years in the common cases. Where the underlying data lives for less than six months, the logs shouldn't carry that personal data at all. And it explicitly leaves perimeter logs, from firewalls and network equipment, outside its scope. Almost everyone quoting "six months" misses that part.
NIS2's Implementing Regulation 2024/2690, für die abgedeckten Anbieter digitaler Infrastruktur und Dienste, verlangt eine risikobasierte Liste der zu protokollierenden Assets, regelmäßige Überprüfung, Schutz vor Manipulation und Aufbewahrung für einen vordefinierten Zeitraum. Kein Minimum. Die Umsetzungsleitlinien von ENISA ergänzen zwei Hinweise: Daten nach Ablauf des Aufbewahrungszeitraums löschen und keine Daten in Logs vorhalten, deren eigener Aufbewahrungszeitraum bereits abgelaufen ist.
Lesen Sie das nochmals. Der Sicherheitsregulator sagt dasselbe wie der Datenschutzregulator.
Der AI Act legt eine Untergrenze statt einer Obergrenze fest. Betreiber von Hochrisikosystemen müssen die von diesen Systemen erzeugten Logs mindestens sechs Monate lang aufbewahren.
PCI DSS verlangt zwölf Monate Aufbewahrung, davon drei sofort verfügbar. Eine vertragliche Vorgabe, keine gesetzliche.
Fünf Quellen, fünf Antworten, eine gemeinsame Anforderung: ein definierter Zeitraum, an einen Zweck geknüpft, schriftlich festgehalten.
Entscheidung nach Zweck
The usual mistake is setting retention per tool. "The SIEM keeps 90 days" is a licence decision dressed up as a security one.
Legen Sie sie pro Zweck fest.
Detection benötigt aktuelle, durchsuchbare Daten. Wochen, direkt verfügbar.
Investigation benötigt genügend Verlauf, um abzudecken, wie lange es realistisch dauert, einen Angriff zu entdecken, zuzüglich des Pre-Disclosure-Fensters, das PHP2Shell gerade gezeigt hat. Langsame Erkennung bedeutet längere Aufbewahrung. Das ist der ehrliche Kompromiss.
Accountability für privilegierten Zugriff needs a longer trail, because "who did this, and were they allowed to?" usually comes up months later.
Gesetzliche und vertragliche Verpflichtungen legen ihre eigene Untergrenze fest. Diese halten Sie ein.
Ein Log kann mehrere Zwecke erfüllen. Die Aufbewahrungsdauer richtet sich nach dem anspruchsvollsten Zweck, den Sie tatsächlich begründen können, nicht nach dem, den Sie sich wünschen würden.
Drei Stellschrauben, die den Großteil des Konflikts auflösen
Aufbewahrungsdauer ist eine Stellschraube. Der Großteil des Konflikts verschwindet, sobald Sie die anderen beiden nutzen.
Inhalt. Loggen Sie das Ereignis, lassen Sie die Daten weg. Wer, welche Aktion, wann, welche Datensatz-Referenz. Nicht den Datensatz selbst, den Request-Body, das Formularfeld, in das jemand versehentlich ein Passwort eingegeben hat. Verbose- und Debug-Logs sind die Orte, an denen personenbezogene Daten in unbeaufsichtigte Bereiche gelangen. Geben Sie ihnen eine Lebensdauer von Tagen.
Tier-Struktur. Ein kurzes Hot-Tier für die Erkennung. Ein längeres Cold-Tier für die Untersuchung, verschlüsselt und schwerer zugänglich. Ein eng begrenztes Archiv für die Verläufe, die Sie begründet über Jahre aufbewahren. Auf jeder Stufe nach unten können weniger Personen darauf zugreifen.
Zugriff. Ihr Log-Speicher ist möglicherweise die vollständigste Aufzeichnung personenbezogener Aktivitäten im Unternehmen. Behandeln Sie ihn entsprechend. Benannte Rollen, protokollierter Zugriff auf die Logs selbst, und Administratoren, die ihren eigenen Verlauf nicht unbemerkt bearbeiten können.
Und eine Leitplanke. Ein Sicherheitslog wird für Sicherheitszwecke erhoben. Sobald er ohne separate Rechtsgrundlage und ohne angemessene Transparenz in einen HR-Streit eingebracht wird, haben Sie seinen Zweck geändert, und in mehreren Ländern haben Sie damit auch den Betriebsrat mit an den Tisch geholt.
Beispielhafte Aufbewahrungstabelle
Passen Sie diese an Ihre Risikobeurteilung und Ihr nationales Recht an. Sie ist ein Ausgangspunkt und zeigt die Begründungslogik, die Sie dokumentieren müssen.
| Log-Typ | Zweck | Beispiel-Aufbewahrung | Begründung |
|---|---|---|---|
| Firewall, Proxy, DNS, VPN | Erkennung, Untersuchung | 12 Monate, 90 Tage hot | Deckt späte Erkennung und Pre-Disclosure-Ausnutzungsfenster ab |
| Authentifizierung (SSO, Verzeichnis, MFA) | Erkennung, Kompromittierungsuntersuchung | 12 Monate | Kontokompromittierung kündigt sich selten am ersten Tag an |
| Privilegierte und administrative Aktionen | Accountability, interne Kontrolle | Bis zu 3 Jahre, eingeschränkter Zugriff | Dokumentierter interner Kontrollbedarf, innerhalb der Obergrenze der CNIL |
| Anwendungszugriff auf personenbezogene Daten | Nachvollziehbarkeit | 6 bis 12 Monate | Referenzrahmen der CNIL |
| Anwendungen mit kurzlebigen Daten | Nachvollziehbarkeit | 6 bis 12 Monate, ohne die personenbezogenen Daten selbst | Logs dürfen die Daten, die sie beschreiben, nicht überleben |
| Debug- und Verbose-Anwendungslogs | Fehlerbehebung | Tage bis Wochen | Kein Zweck über die Fehlerbehebung hinaus |
| Zahlungskartenumgebung | PCI DSS | 12 Monate, 3 online | Vertragliche Anforderung |
Halten Sie die Entscheidung schriftlich fest
Zu A.8.15 wird der Auditor fragen, wie lange Sie Ihre Logs aufbewahren. Die besseren Auditoren fragen dann: warum.
Die Antwort muss existieren, bevor die Frage gestellt wird. Eine Logging-Richtlinie mit der Aufbewahrungstabelle und ihrer Begründung. Eine Beurteilung des berechtigten Interesses für das Logging selbst. Das Logging eingetragen in Ihr Verzeichnis der Verarbeitungstätigkeiten, weil es eine Verarbeitungstätigkeit ist. Die Stellungnahme des DPO in den Akten. Ein benannter Verantwortlicher. Ein Überprüfungsdatum.
Dieses Dokumentenpaket ist es, das ein Dogma in eine Entscheidung verwandelt. Die Sicherheitsseite erhält den Nachweisverlauf, den sie braucht. Die Datenschutzseite erhält einen Zweck, eine Grenze und ein Löschdatum. Und wenn jemand eine der beiden Seiten in Frage stellt, steht unten eine Unterschrift.
Abschließende Überlegung
The fight between "keep everything" and "keep nothing" usually ends with whoever argues loudest, and the retention period ends up being whatever the tool shipped with.
Keines der Regelwerke lässt Sie so einfach davonkommen. Beide wollen sehen, dass jemand den Zweck geprüft, eine Zahl gewählt und begründet hat, warum.
Das kostet einen Nachmittag. Es erspart Ihnen zwei Gespräche: einem Incident-Response-Unternehmen zu erklären, dass die benötigten Logs standardmäßig gelöscht wurden, und einer Datenschutzbehörde zu erklären, warum Sie sieben Jahre lang alles aufbewahrt haben.
Beide Seiten dieses Themas werden in zwei unserer Kurse behandelt. ISO 27001 Lead Implementer behandelt Logging und Monitoring als Maßnahmen, die Sie im Audit nachweisen können. ISO 27701 Lead Implementer behandelt die Datenschutzseite: Zweck, Aufbewahrung und die Nachweise, die sie begründen.