Server-Logs im Shop: Wie lange IP-Adressen bleiben dürfen

Die DSGVO regelt Speicherdauern über einen Grundsatz, nicht über Tage. Nach Art. 5 Abs. 1 lit. e DSGVO dürfen personenbezogene Daten nur so lange in einer Form gespeichert werden, die die Identifizierung ermöglicht, wie es für die Zwecke erforderlich ist (DSGVO). Erwägungsgrund 39 wird konkreter: Damit Daten nicht länger als nötig gespeichert werden, soll der Verantwortliche Fristen für ihre Löschung oder regelmäßige Überprüfung vorsehen (DSGVO). Eine Frist festzulegen, ist damit Aufgabe des Verantwortlichen. Ihre Länge bestimmt der Shopbetreiber, und er muss sie begründen können.

Rechtsgrundlage für Server-Logs ist im Shop in der Regel Art. 6 Abs. 1 lit. f DSGVO, das berechtigte Interesse. Die Datenschutzkonferenz beschreibt die Prüfung in drei Stufen (Datenschutzkonferenz): ein berechtigtes Interesse, die Erforderlichkeit der Verarbeitung zu seiner Wahrung und die Abwägung mit den Interessen der Betroffenen im Einzelfall. Für den Sicherheitszweck gibt Erwägungsgrund 49 die Richtung vor: Er nennt die Verarbeitung zur Gewährleistung der Netz- und Informationssicherheit, etwa durch Betreiber von Kommunikationsnetzen und Anbieter von Sicherheitsdiensten, ein berechtigtes Interesse, soweit sie unbedingt notwendig und verhältnismäßig ist (DSGVO). Für den eigenen Shop zeigt das die Richtung, ersetzt aber nicht die eigene Abwägung. Der EuGH hat im selben Verfahren anerkannt, dass ein Betreiber, dort Einrichtungen des Bundes, ein berechtigtes Interesse daran haben kann, die Funktionsfähigkeit seiner Websites über die konkrete Nutzung hinaus zu gewährleisten (EuGH).

Dieser Satz wird gern als Frist für alle Logs zitiert. Er trägt das nicht. Der BfDI bewertet die Verarbeitung durch öffentliche Stellen des Bundes, stützt sie auf Art. 6 Abs. 1 lit. e DSGVO in Verbindung mit dem Bundesdatenschutzgesetz und meint den Zweck „Optimierung der Webseite“ (BfDI). Für diesen Zweck hält er die vollständige IP-Adresse in der Regel nicht für notwendig (BfDI). Eine Frist in Tagen für die Angriffserkennung nennt die Seite nicht. Für einen Shop ist der Wert deshalb eine Orientierung für Auswertungen, keine Vorgabe für das Rohlog, und die Rechtsgrundlage bleibt das berechtigte Interesse mit eigener Abwägung.

Kürzen heißt, den hinteren Teil der Adresse zu verwerfen. Eine IPv4-Adresse ist 32 Bit (RFC 791) lang, üblich ist das Entfernen des letzten Bytes. Die Hilfsfunktion IpUtils::anonymize des Symfony-Frameworks, auf dem auch Shopware aufbaut, entfernt in der Voreinstellung 1 Byte bei IPv4 und 8 Byte bei IPv6 (Symfony). Für IPv4 ist das ein gängiger Kompromiss: Das Netz bleibt für Auswertungen erkennbar, der einzelne Anschluss nicht mehr ohne Weiteres.

Bei IPv6 reicht dieselbe Regel nicht. Eine IPv6-Adresse ist 128 Bit (RFC 4291) lang, und die hinteren 64 Bit (RFC 4291) bilden bei den üblichen Adressen die Schnittstellenkennung. Wer genau diesen Teil entfernt, behält das Netzpräfix, und das gehört häufig zu einem einzelnen Anschluss. Die Empfehlung für die Adressvergabe sieht für Heimanschlüsse deutlich mehr als ein einzelnes /64-Netz (RFC 6177) vor. Die Beispielkonfiguration unten behält deshalb bei IPv6 nur die ersten drei Gruppen. Ob das genug Abstand schafft, hängt von der Vergabepraxis der Zugangsanbieter ab; wer es enger braucht, behält nur zwei Gruppen und hält die Entscheidung schriftlich fest.

Ersetzen statt kürzen ist der zweite Weg. Der BfDI nennt eine Änderung der IP-Adresse, gegebenenfalls per Hash-Verfahren, als Maßnahme, die das Risiko angemessen mindern kann, ohne den Zweck zu beeinträchtigen (BfDI). Ein einfacher Hashwert über eine IPv4-Adresse leistet das allerdings kaum: Bei 32 Bit lässt sich der gesamte Adressraum durchrechnen und jedem Hashwert seine Adresse wieder zuordnen. Wirksam wird das Ersetzen erst mit einem geheimen Schlüssel, der regelmäßig gewechselt und danach vernichtet wird. Art. 32 DSGVO nennt die Pseudonymisierung ausdrücklich als technische Maßnahme (DSGVO). In nginx lässt sich das Kürzen ohne Zusatzmodul abbilden:

Die Zeilen gehören in den http-Kontext. Führt ein server-Block eigene access_log-Anweisungen, gilt die äußere Angabe dort nicht, und die Zeile für das Auswertungsprotokoll wird in diesem Block ergänzt. Das Rohlog läuft daneben unverändert weiter und behält seine kurze Frist. Das Verzeichnis für das Auswertungsprotokoll wird vor dem Neuladen angelegt. Ein eigenes Verzeichnis ist nötig, weil die Rotationsregel des Pakets alle Dateien nach dem Muster /var/log/nginx/*.log erfasst und logrotate eine Datei, die in zwei Regeln steht, mit einem Fehler quittiert.

Die sauberste Logrotation endet am Rand des Servers. Eine Sicherung, die /var/log mitnimmt, hält jede Logzeile so lange vor wie die Sicherung selbst, bei einer Aufbewahrung über Monate also Monate. Dasselbe gilt für Staging-Systeme, die als vollständige Kopie der Produktion entstehen, und für Logauszüge, die in Tickets, Chats oder E-Mails an Dienstleister landen. Für die Frist zählt nicht, wann das Original rotiert, sondern wann die letzte Kopie verschwindet.

Für Sicherungen gibt es zwei saubere Wege: Logverzeichnisse von der Sicherung ausnehmen, wenn die Logs für die Wiederherstellung keine Rolle spielen, oder die Aufbewahrung der Sicherung an der kürzesten enthaltenen Frist ausrichten. Wie Löschpflichten und Sicherungen allgemein zusammenpassen, behandelt der Beitrag zur DSGVO-konformen Datensicherung. Für Staging-Systeme gilt: Logs werden beim Kopieren ausgelassen oder geleert, und das Testsystem bekommt eine eigene, kurze Rotation. Wie Testumgebungen ohne unnötige Echtdaten auskommen, zeigt der Beitrag zu Staging-Umgebungen.

Der Vergleich mit dem ältesten vorhandenen Log ist die einfachste Messung, ob die Frist tatsächlich gilt. Das folgende Skript nennt je Verzeichnis die älteste Zugriffsdatei und ihr Alter nach Änderungszeit; Rohlog und Auswertungslog misst es getrennt, damit die längere Frist des einen die kürzere des anderen nicht verdeckt. Das ist der Zeitpunkt des letzten Eintrags, denn logrotate übernimmt ihn beim Komprimieren; der älteste Eintrag der Datei kann bis zu einem Rotationsintervall früher liegen:

Gerade der letzte Schritt fällt in der Praxis leicht weg, weil die Einstellung einmal stimmt und danach selten jemand nachsieht. Ein Paketupdate, ein Serverumzug oder eine neue Schutzschicht vor dem Shop bringt eigene Logs und eigene Vorgaben mit. Neben Festplattenbelegung und Fehlerlogs, die das Monitoring überwacht, gehört deshalb auch das Alter des ältesten Logs zu den Werten, die regelmäßig geprüft werden sollten. Wie Protokolle mit ihren Voreinstellungen eine Partition füllen, beschreibt der Beitrag zum Speicherplatz im Shop.

Im Wartungsvertrag laufen diese Punkte zusammen. Die DSGVO-Updates umfassen die Pflege der Datenschutzerklärung mit ihren Speicherdauern und des Verzeichnisses der Verarbeitungstätigkeiten. Webserver-Konfiguration und Sicherungen gehören zur technischen Betreuung, die unter Leistungen beschrieben ist. Welche Reaktionszeiten und Pakete gelten, regelt der SLA-Wartungsvertrag. So stehen Frist, Konfiguration und Dokumentation an einer Stelle und laufen nicht auseinander.