Blog von Analytics House
Architekturnotizen zum Aufbau der am besten überprüfbaren datenschutzfreundlichen Webanalyse-Plattform der Welt auf Cloudflare Workers und D1.
Wie die Vernichtung kurzlebiger Tages-Salts historische Besucher-Hashes per Brute-Force unknackbar macht
Da IPv4 nur rund 4,3 Milliarden Adressen hat, lässt sich ein statischer Hash aus (IP + User-Agent) mit einer GPU-Rainbow-Table in Minuten umkehren. So rotiert Analytics House in Cloudflare D1 an jedem UTC-Tag einen 256-Bit-Salt aus einem CSPRNG und vernichtet den Salt des Vortags endgültig, sobald die Rollups abgeschlossen sind.
Die meisten „cookiefreien“ Analyseplattformen berechnen einen täglichen Hash aus (daily_salt + site_id + IP + User-Agent), damit sie eindeutige tägliche Besucher zählen können, ohne Browser-Cookies zu setzen. Wird der Salt jedoch aus einem statischen Geheimnis abgeleitet oder unbegrenzt auf der Festplatte aufbewahrt, kann jeder, der die Datenbank kompromittiert – oder den Zugriff per gerichtlicher Anordnung erzwingt –, den 32-Bit-IPv4-Adressraum für einen bekannten User-Agent per Brute-Force durchsuchen.
In Analytics House wird für jeden UTC-Tag über crypto.getRandomValues() ein unabhängiger zufälliger 256-Bit-Salt erzeugt und in der meta-Tabelle von Cloudflare D1 unter salt:YYYY-MM-DD gespeichert. Im Laufe des Tages berechnen eingehende /collect-Anfragen im Arbeitsspeicher des Workers eine auf 64 Bit gekürzte, gesalzene SHA-256-Besucher- und Sitzungskennung und verwerfen die IP-Adresse des Clients und den rohen User-Agent sofort.
Alle 15 Minuten schreibt der geplante Cron Trigger abgeschlossene UTC-Tage in voraggregierte Rollup-Tabellen (rollup_day und rollup_dim) fest. Sobald die Abschlussmarke (Watermark) über einen UTC-Tag hinausrückt, löscht shredExpiredSalts() jeden Salt, der älter als die festgeschriebene Abschlussmarke ist. Ist dieser 256-Bit-Schlüssel gelöscht, gibt es keinen praktikablen Weg mehr, eine frühere Besucher-ID auf eine IP-Adresse zurückzuführen oder die Besuche eines Tages mit denen eines anderen zu verknüpfen. Die IDs bleiben pseudonyme Daten, daher gelten die übrigen Schutzmaßnahmen weiterhin.
Modus „Keine Rohdaten-Historie“ & automatische Bereinigung personenbezogener Daten am Edge mit Cloudflare Workers
URLs von Anwendungen und Nutzdaten benutzerdefinierter Ereignisse enthalten häufig versehentlich Reset-Tokens, UUIDs, E-Mail-Adressen oder Kreditkartennummern. Erfahren Sie, wie unsere synchrone Firewall für personenbezogene Daten am Edge Telemetriedaten bereinigt, bevor sie in D1 geschrieben werden – und wie der Modus „Keine Rohdaten-Historie“ Rohereigniszeilen beim Abschluss der Rollups löscht.
Entwickler wollen selten personenbezogene Daten an ihren Analysedienst senden, doch URLs zum Zurücksetzen von Passwörtern (/reset-password/eyJhbGci...), Routen zu Nutzerprofilen (/users/alice@example.com) und Checkout-Eigenschaften spülen regelmäßig sensible Zeichenketten in Analysedatenbanken.
Analytics House führt im Cloudflare Worker einen deterministischen Scrubber für personenbezogene Daten aus, bevor ein Ereignis D1 erreicht. Query-Strings und Fragmente von URLs werden entfernt; Pfadsegmente, die E-Mail-Adressen ([email]), UUIDs ([uuid]), JWTs ([jwt]), IPv4-Adressen ([ip]) oder Hex-/Base64-Tokens mit hoher Entropie ([token]) entsprechen, werden noch auf dem Weg unkenntlich gemacht. Eigenschaften benutzerdefinierter Ereignisse werden rekursiv nach sensiblen Schlüsseln (email, password, token, secret, ssn, phone, credit_card, api_key) und per Luhn-Prüfung validierten Kreditkartennummern durchsucht.
Für Teams mit strengen Compliance-Vorgaben geht der Modus „Keine Rohdaten-Historie“ (ephemeral_raw) noch einen Schritt weiter: Wenn ein UTC-Tag in aggregierte Rollups festgeschrieben wird, werden die Rohzeilen dieses Tages in der Tabelle events sofort gelöscht – übrig bleiben nur aggregierte Tageszähler.
Vertrauen ohne IP-Adressen durch Architektur: First-Party-Relay mit Cloudflare Workers
Selbst wenn ein Analyseanbieter verspricht, keine IP-Adressen zu protokollieren, legen normale HTTPS-Anfragen die IP des Besuchers gegenüber dem Edge-Server des Anbieters offen. Mit unserem First-Party-Proxy auf Cloudflare Workers, eingerichtet mit einem Klick, entfernt Ihre eigene Domain die IP des Besuchers, bevor sie ein anonymisiertes Relay-Token weiterleitet.
Bei einer herkömmlichen Analyse-Einrichtung verbindet sich der Browser des Besuchers direkt mit der Domain des Analyseanbieters. Sie müssen also darauf vertrauen, dass der Anbieter gemäß seiner Richtlinie CF-Connecting-IP nicht protokolliert.
Da Analytics House zu 100 % Cloudflare-nativ ist, erzeugt jedes Projekt im Dashboard ein eigenständiges First-Party-Skript für Cloudflare Workers, das Sie auf einer Route Ihrer eigenen Domain bereitstellen können (zum Beispiel yoursite.com/_ea/*).
Wenn ein Besucher Ihre Website lädt, empfängt Ihr eigener Worker die Anfrage, berechnet mit einem geheimen Schlüssel, der Ihr Cloudflare-Konto nie verlässt, einen SHA-256-Digest aus (UTC_date + CF-Connecting-IP + User-Agent), entfernt die IP-Adresse des Besuchers und leitet nur den opaken Header X-EA-Visitor-Relay und einen groben Ländercode an Analytics House weiter.
Möchten Sie die kryptografischen Garantien live prüfen?
Lesen Sie unsere Datenschutzspezifikation oder sehen Sie sich die API-Referenz an.