IP-Hashing für Tracking: warum DSGVO Anonymisierung verlangt

Worum es geht

Jeder Tracking-Request, der eine Website verlässt, enthält die IP-Adresse des Endgeräts. Sie ist nötig, damit die Antwort des Servers überhaupt am richtigen Punkt ankommt. In Tracking-Logs landet diese IP automatisch, wenn der Server sie nicht aktiv entfernt oder verschleiert.

Aus DSGVO-Sicht ist die IP nicht harmlos. Der Europäische Gerichtshof hat 2016 und 2024 mehrfach entschieden, dass eine IP-Adresse, auch wenn sie ohne Namen gespeichert wird, ein personenbezogenes Datum sein kann, weil die Möglichkeit besteht, sie über den jeweiligen Internet-Provider einer natürlichen Person zuzuordnen. Die deutschen Aufsichtsbehörden folgen dieser Linie streng.

Wer also IPs ungeprüft speichert, betreibt Verarbeitung personenbezogener Daten. Dafür braucht es eine Rechtsgrundlage nach Art. 6 DSGVO, eine Datenschutz-Folgenabschätzung bei hoher Verarbeitungsmenge, und alle weiteren Compliance-Pflichten. Die Antwort der Branche heißt IP-Hashing: Die identifizierende IP wird in einen kryptografischen Hash überführt, der die Funktion (Frequency-Capping, Session-Zuordnung, Bot-Schutz) erhält, aber die Rückverfolgbarkeit zur Person erschwert.

Zurück zum Überblick: DSGVO-konformes Tracking, der vollständige Leitfaden.

Pseudonymisierung versus Anonymisierung

Die DSGVO unterscheidet beide Konzepte juristisch klar.

Pseudonymisierung nach Art. 4 Nr. 5 bedeutet, dass die identifizierenden Merkmale durch einen Schlüssel ersetzt werden, der den Personenbezug grundsätzlich wiederherstellen könnte, wenn man Zugriff auf zusätzliche Informationen hätte. Eine IP, die als Hash gespeichert wird, ist pseudonym: Wer den Hash und den verwendeten Algorithmus plus Salt kennt, könnte bei bekannter IP-Liste die Zuordnung rekonstruieren. Pseudonymisierte Daten gelten weiterhin als personenbezogen, brauchen also Rechtsgrundlage, AVV und Konsent.

Anonymisierung bedeutet, dass jeder Personenbezug irreversibel entfernt wurde. Die Hürde dafür ist hoch: Ein anonymisiertes Datenset darf auch unter Einbeziehung externer Quellen und mit zumutbarem Aufwand nicht mehr zu einer konkreten Person zurückgeführt werden können. Anonymisierte Daten fallen nicht mehr unter die DSGVO.

Praktisch ist Anonymisierung mit IP-Daten ohne weitere Maßnahmen schwer zu erreichen, weil schon die Kombination aus IP-Hash, User-Agent und Zugriffs-Zeitstempel oft ausreicht, um eine Person zu re-identifizieren. Die Aufsichtsbehörden gehen davon aus, dass IP-Hashing eine Pseudonymisierung darstellt, keine Anonymisierung. Wer mit anonymen Daten arbeiten will, muss zusätzlich IP-Truncation, K-Anonymisierung oder differenzielle Privacy einsetzen.

Wie SHA-256-Hashing technisch funktioniert

SHA-256 ist eine kryptografische Hash-Funktion aus der SHA-2-Familie. Sie nimmt beliebige Eingabe-Daten und gibt einen 256-Bit-langen Hash-Wert zurück, der in Hex-Darstellung 64 Zeichen lang ist. Die wichtigste Eigenschaft: Aus dem Hash lässt sich die Eingabe nicht rückrechnen, und kleine Änderungen in der Eingabe führen zu komplett anderen Hashes.

Für IPs sieht das so aus:

// Eingabe
"192.168.1.42"

// SHA-256-Hash (nur als Beispiel)
"3a7bd3e2360a3d29eea436fcfb7e44c735d117c42d1c1835420b6b9942dd4f1b"

Wenn dieselbe IP nochmal kommt, ergibt sich derselbe Hash. Damit lässt sich die Funktionalität, die normalerweise auf der IP basiert, weiterhin nutzen, ohne die ursprüngliche IP zu speichern.

Das alleinige Hashing hat ein Problem: Da SHA-256 deterministisch ist, lässt sich aus einer Liste aller möglichen IPv4-Adressen, etwa vier Milliarden, eine sogenannte Rainbow-Table vorausberechnen. Damit könnte ein Angreifer aus einem SHA-256-IP-Hash die ursprüngliche IP wieder ableiten. Dieses Problem löst das Salt.

Die Rolle des Salts

Ein Salt ist ein zufälliger String, der vor dem Hashing an die IP angehängt wird. Dadurch ergeben sich für dieselbe IP unterschiedliche Hashes, je nachdem welches Salt verwendet wird, und Rainbow-Tables werden nutzlos.

Es gibt zwei sinnvolle Salt-Strategien.

Konstantes Salt pro Domain

Ein einziger zufälliger String, der für die gesamte Domain verwendet wird. Vorteil: Dieselbe IP ergibt über mehrere Sessions denselben Hash, was für Session-Tracking und Frequency-Capping wichtig ist. Nachteil: Wenn das Salt geleakt wird, funktionieren wieder Rainbow-Tables.

Rotierendes Salt

Das Salt wird in regelmäßigen Abständen (etwa täglich) ausgetauscht. Vorteil: höchste Sicherheit, weil selbst geleakte Salts nur einen begrenzten Zeitraum kompromittieren. Nachteil: Session-Tracking über den Salt-Wechsel hinaus funktioniert nicht mehr. Für 30-Tage-Attribution-Modelle ist rotierendes Salt in dieser Form ungeeignet.

Ein guter Mittelweg ist ein domain-spezifisches Salt mit Salt-Refresh alle 30 oder 90 Tage, abgestimmt auf die Attribution-Lookback-Fenster. So bleiben die Hashes stabil innerhalb des relevanten Zeitfensters, alte Daten werden über das Salt-Update zusätzlich abgeschirmt.

Implementation in der Praxis

Die folgende Implementation ist serverseitig, weil das die DSGVO-rechtlich saubere Variante ist. Browser-Hashing ist möglich, aber das Salt wäre im Browser-Code sichtbar, was die Wirkung deutlich abschwächt.

Schritt 1: Salt generieren und sicher speichern

Ein zufälliger 32- bis 64-Zeichen-langer String, generiert mit OpenSSL oder einer äquivalenten CSPRNG-Library. Das Salt landet in einem Secret-Manager (AWS Secrets Manager, Google Secret Manager, HashiCorp Vault) und nicht im Code-Repository. Wer klein anfängt, kann das Salt auch in einer Umgebungsvariablen speichern, sollte aber Backups und Rotation einplanen.

Schritt 2: Hashing-Function im Tracking-Server

In Node.js sieht das so aus:

import crypto from 'crypto';

function hashIp(ip, salt) {
  return crypto
    .createHash('sha256')
    .update(ip + salt)
    .digest('hex');
}

Die Funktion wird bei jedem eingehenden Tracking-Request aufgerufen, bevor die IP in die Datenbank geschrieben wird. Die Original-IP existiert nur kurz im Speicher des Servers, niemals persistent.

Schritt 3: Datenmodell anpassen

In der Datenbank ist nur das Hash-Feld definiert, etwa als ip_hash CHAR(64). Ein Migrations-Script ersetzt bei der Umstellung alle bestehenden IPs durch Hashes, das Original-IP-Feld wird gelöscht. Wichtig: Backups vor der Migration sicherstellen und nach der Verifizierung die alten Backups DSGVO-konform vernichten.

Schritt 4: Salt-Rotation einplanen

Ein Cron-Job, der alle 30 oder 90 Tage ein neues Salt generiert und das alte archiviert. Daten, die vor dem Salt-Wechsel entstanden sind, werden über das alte Salt weiterhin nachvollziehbar, neue Daten nutzen das neue Salt. Nach Ablauf der Aufbewahrungsfrist wird das alte Salt unwiderruflich gelöscht.

Was reicht und was nicht

Eine korrekte SHA-256-Implementation mit ausreichend langem Salt erfüllt die Anforderungen an Pseudonymisierung nach DSGVO Art. 4 Nr. 5 und wird von Aufsichtsbehörden als angemessene technische Maßnahme nach Art. 32 anerkannt.

Was IP-Hashing nicht ersetzt:

• Einwilligung: Wenn das Tracking unter die Einwilligungspflicht fällt (was bei Cookies und Identifiern nach TTDSG fast immer der Fall ist), muss die Einwilligung trotzdem eingeholt werden. Hashing ist eine zusätzliche Schutzmaßnahme, kein Ersatz für die Rechtsgrundlage.
• Auftragsverarbeitung: Auch pseudonymisierte Daten sind personenbezogen. Wer einen externen Tracking-Anbieter nutzt, braucht weiterhin einen AVV.
• Datenminimierung: Wenn die IP für die Funktion nicht gebraucht wird, sollte sie auch nicht erhoben werden. Hashing ist die zweitbeste Option gegenüber dem vollständigen Verzicht auf die IP.

Für maximalen Schutz lässt sich IP-Hashing mit IP-Truncation kombinieren: Das letzte Oktett (bei IPv4) oder der Host-Teil (bei IPv6) wird verworfen, der Network-Prefix bleibt erhalten und wird gehasht. Damit ist die Re-Identifizierung eines Endgeräts praktisch ausgeschlossen, während grobe geografische Informationen für Tracking-Zwecke erhalten bleiben.