Device-Graph-Analyse: Verbindungen über Sessions hinweg aufdecken
Wie Graphdatenbanken verborgene Verbindungen zwischen Geräten sichtbar machen und Multi-Account-Erkennung sowie die Identifizierung von Betrugsringen im großen Maßstab ermöglichen.
Wenn ein einzelner Betrüger Dutzende Accounts betreibt, wirken die einzelnen Accounts isoliert betrachtet legitim. Jeder hat eine eindeutige E-Mail-Adresse, eine plausible IP-Adresse, realistische Surfmuster. Die traditionelle regelbasierte Erkennung prüft jeden Account unabhängig und findet nichts Verdächtiges. Die Verbindungen zwischen den Accounts – die gemeinsam genutzten Geräte, überlappenden Sessions, gemeinsamen Netzwerk-Fingerprints – bleiben für Systeme unsichtbar, die Accounts einzeln verarbeiten.
Warum Graphen
Die Device-Graph-Analyse verändert das Modell. Statt Accounts unabhängig zu bewerten, bauen wir einen Graphen auf, in dem die Knoten Geräte, Accounts, IP-Adressen und Sessions sind und die Kanten beobachtete Verbindungen darstellen: „dieses Gerät wurde zum Anlegen dieses Accounts verwendet", „diese IP wurde zusammen mit diesem Gerät gesehen", „diese beiden Accounts teilten sich ein Session-Cookie". Der Graph offenbart eine Struktur, die flache Tabellen nicht zeigen können.
Ein Betrugsring, der 50 Accounts über 5 Geräte und 3 IP-Adressen nutzt, bildet im Graphen ein charakteristisches Cluster. Die Clusterdichte – viele Verbindungen innerhalb einer kleinen Gruppe von Knoten – ist ein starkes Signal. Legitime Nutzer teilen sich selten Geräte mit Fremden, und ihre Account-Geräte-Verbindungen bilden spärliche, baumartige Strukturen statt dichter Cluster.
Architektur der Graphdatenbank
Wir verwenden ein Property-Graph-Modell mit vier Knotentypen: Device (identifiziert über die Besucher-ID), Account (Ihre User-ID), Network (IP-Adresse + ASN) und Session (einzelnes Identifikationsereignis). Die Kanten tragen Metadaten: Zeitstempel, Konfidenzwert und Ereignistyp.
Der Graph wird in einem speziell entwickelten Adjazenzindex gespeichert, der für Zwei-Hop-Traversierungen optimiert ist. Wenn ein neues Identifikationsereignis eintrifft, fügen wir das Ereignis als Session-Knoten ein, verbinden es mit den Device- und Network-Knoten und prüfen, ob ein verknüpfter Account Verbindungen zu anderen Geräten hat. Diese Insert-and-Query-Operation ist bei Graphen mit bis zu 10 Millionen Knoten in unter 5ms abgeschlossen.
Wir haben tatsächlich zunächst Neo4j ausprobiert. In der Entwicklung mit 100K Knoten funktionierte es hervorragend. Dann luden wir Produktivdaten – 500M Knoten – und Cypher-Abfragen, die 2ms gedauert hatten, brauchten plötzlich 800ms. David verbrachte eine Woche mit Benchmarks von Alternativen, bevor wir unseren eigenen Adjazenzindex auf Basis von gesharded RocksDB bauten. Manchmal schlägt die unspektakuläre, maßgeschneiderte Lösung die elegante Standardlösung.
Clustering-Algorithmen
Wir wenden zwei Clustering-Algorithmen auf den Device Graph an:
Connected Components
Der einfachste Ansatz: alle Knoten finden, die von einem bestimmten Gerät aus erreichbar sind. Wenn Gerät A mit Account 1 und Account 2 verbunden ist und Gerät B ebenfalls mit Account 2 verbunden ist, dann befinden sich die Geräte A und B in derselben Connected Component. Dies identifiziert alle Accounts, die eine beliebige transitive Geräteverbindung teilen.
Connected Components lassen sich schnell berechnen, können aber sehr große Cluster erzeugen, wenn legitime gemeinsam genutzte Geräte (Familiencomputer, Bibliotheksterminals) Brücken zwischen nicht verwandten Accounts bilden. Wir begegnen dem mit einer Kantengewichtung – Verbindungen über bekannte gemeinsam genutzte Umgebungen erhalten ein geringeres Gewicht.
Community Detection
Für eine differenziertere Analyse führen wir Louvain-Community-Detection auf dem gewichteten Graphen aus. Dieser Algorithmus partitioniert den Graphen in Communitys, in denen die Verbindungen innerhalb der Community dicht und die Verbindungen zwischen Communitys spärlich sind. Betrugsringe bilden enge Communitys, selbst wenn sie über gemeinsam genutzte Infrastruktur mit dem übrigen Graphen verbunden sind.
Der Louvain-Algorithmus läuft in O(n log n) Zeit, was ihn für Graphen mit Millionen von Knoten praktikabel macht. Wir führen ihn inkrementell aus – wenn neue Kanten hinzugefügt werden, aktualisieren wir die Community-Zuordnungen lokal, statt die gesamte Partition neu zu berechnen.
Praxismuster: Erkennung von Betrugsringen
Eine Gaming-Plattform band unsere Device-Graph-API ein, um organisierte Betrugsringe zu erkennen. Bereits in der ersten Woche brachte der Graph ein Cluster von 127 Accounts zum Vorschein, die über 8 Geräte und 4 IP-Adressen verbunden waren. Die Accounts waren über einen Zeitraum von 3 Monaten angelegt worden, jeder mit einer eindeutigen E-Mail-Adresse und einem realistischen Profil. Die regelbasierte Erkennung hatte keinen einzigen davon markiert.
Die Graphstruktur war der verräterische Hinweis: 127 Accounts, die sich 8 Geräte teilen, ergeben durchschnittlich 15,8 Accounts pro Gerät. Legitime Nutzer kommen auf dieser Plattform im Schnitt auf 1,2 Accounts pro Gerät. Die Clusterdichte lag 47-mal über dem Basiswert – ein eindeutiges Betrugssignal.
Leistung im großen Maßstab
Unser produktiver Device Graph verarbeitet 2,3 Milliarden Knoten und 8,1 Milliarden Kanten. Die Insert-Latenz beträgt 2,4ms bei p99. Eine Zwei-Hop-Traversierung (alle Accounts finden, die über einen beliebigen Pfad der Länge 2 mit einem Gerät verbunden sind) ist in 4,1ms bei p99 abgeschlossen. Community-Detection-Updates verarbeiten 50.000 neue Kanten pro Sekunde.
Der Graph ist über einen Hash der Geräte-ID auf 12 Knoten gesharded, wobei jeder Shard etwa 190 Millionen Knoten enthält. Ein Replikationsfaktor von 3 gewährleistet die Verfügbarkeit. Wir erstellen stündlich Snapshots des Graphen für die Notfallwiederherstellung und führen täglich eine vollständige Neuberechnung der Community Detection als Konsistenzprüfung gegen die inkrementellen Updates durch.
Integration
Der Device Graph ist über zwei Schnittstellen zugänglich: eine Echtzeit-Query-API für einzelne Abfragen (ist dieses Gerät mit anderen Accounts verbunden?) und eine Batch-Export-API für Analysen (liefere mir alle Cluster mit mehr als N Accounts). Die Echtzeit-API ist für Inline-Betrugsentscheidungen ausgelegt – abfragen während der Account-Erstellung, um zu prüfen, ob das Gerät bereits andere Accounts gesehen hat. Die Batch-API speist die Untersuchungs-Workflows Ihres Datenteams.