Was das Kürzen einer IP-Adresse wirklich anonymisiert

Das Kürzen einer IP-Adresse verringert die gespeicherte Genauigkeit. Aus 203.0.113.45 wird beispielsweise 203.0.113.0/24. Damit verschwindet die Unterscheidung zwischen 256 möglichen IPv4-Adressen. Daraus folgt jedoch weder eine Gruppe von 256 Personen noch automatisch ein anonymer Datensatz.

Für die Bewertung sind drei Fragen entscheidend: Welche Bits bleiben erhalten? Welche weiteren Merkmale enthält der Datensatz? Welche realistischen Möglichkeiten zur Zuordnung bestehen beim jeweiligen Empfänger? Eine Maskenlänge beantwortet nur die erste Frage.

Adressraum und Personengruppe sind unterschiedliche Größen

IPv4-Adressen bestehen aus 32 Bit. Die Schreibweise /24 bedeutet, dass die ersten 24 Bit erhalten bleiben und die letzten acht Bit auf null gesetzt werden. Die Zahl möglicher Ausgangsadressen beträgt dann 2⁸ = 256. Die folgenden Werte dienen als Dokumentationsbeispiele, nicht als Geolokalisierungsnachweis.

NAT kann viele Geräte hinter einer öffentlichen Adresse bündeln. Bei Carrier-Grade NAT können auch mehrere Kundenanschlüsse dieselbe öffentliche Adresse nutzen. Umgekehrt kann ein Anschluss im Zeitverlauf unterschiedliche Adressen erhalten. Die Zahl mathematisch möglicher Adressen beschreibt deshalb weder die tatsächlich belegten Adressen noch die Anzahl unterschiedlicher Personen im Datensatz.

Auch Geolokalisierung liefert keine feste Beziehung zwischen Präfixlänge und Wohnort. Betreiberzuweisungen, Mobilfunk, VPNs und Datenbankqualität beeinflussen das Ergebnis. MaxMind weist ausdrücklich darauf hin, dass GeoIP-Daten keinen bestimmten Haushalt oder eine Straßenadresse zuverlässig bestimmen. Eine Kürzung kann die Ortsauswertung verändern; „Stadt bleibt nahezu unverändert“ muss am konkreten Datenbestand geprüft werden.

Ein einfacher Hash beseitigt das Zuordnungsrisiko nicht

SHA-256 erzeugt aus einer Adresse einen schwer lesbaren, aber deterministischen Wert. Bei gleicher Eingabe entsteht derselbe Hash. Für IPv4 gibt es nur 2³² = 4 294 967 296 mögliche Adressen. Eine systematische Kandidatensuche ist daher wesentlich leichter als bei einem zufälligen, langen Geheimnis.

ENISA dokumentiert bereits 2019 praktische Angriffe auf SHA-256-pseudonymisierte IPv4-Adressen. Die benötigte Zeit hängt von Hardware, Implementierung und bekanntem Suchbereich ab; eine allgemeine Zusage „jede Maschine schafft die vollständige Tabelle in Minuten“ ist daraus nicht ableitbar. Der relevante Befund bleibt: Ein ungeschützter Hash ist keine verlässliche Anonymisierung.

Ein öffentlich gespeichertes Salz verändert die Hashwerte, ist aber kein geheimer Schlüssel. Ein festes Salz verhindert die Wiederverwendung einer fremden Standardtabelle, erlaubt aber eine neue Tabelle für diesen Datenbestand. Ein zufälliges Salz je Ereignis erschwert Vorberechnung und direkte Verknüpfung; bei bekanntem Salz bleibt eine Kandidatensuche je Ereignis möglich. Ein Hash über einen bereits gekürzten Präfix verbirgt den Präfix ebenfalls nicht zuverlässig: Der mögliche Eingaberaum wird durch die Kürzung sogar kleiner.

IPv6: Netzpräfix ist nicht gleich Personengruppe

IPv6-Adressen haben 128 Bit. Ein /64 ist eine verbreitete Größe für ein einzelnes Subnetz. Ein Anschluss oder Standort kann mehrere solche Subnetze erhalten, etwa innerhalb eines /56 oder /48. RFC 6177 legt keine universelle Präfixlänge für alle Standorte fest. Auch die Bildung des Geräteanteils variiert; „jedes Gerät erfindet den Rest selbst“ ist keine allgemeine Regel.

Das Entfernen der unteren 64 Bit beseitigt den darin enthaltenen Interface-Anteil, lässt aber den Subnetzpräfix stehen. Ein /56 oder /48 kann weiterhin einen einzigen Kundenstandort kennzeichnen. Eine stärkere Kürzung kann mehrere Zuweisungen zusammenfassen; die tatsächliche Wirkung hängt von der Vergabepraxis und zusätzlichen Daten ab.

Googles bekannte Regel „letzte 80 IPv6-Bit auf null“ gehört zur alten IP-Maskierung von Universal Analytics und ergibt einen /48. GA4 ist davon zu unterscheiden: Laut Google werden IP-Adressen bei der Erfassung zur Ortsbestimmung verwendet und vor der Protokollierung oder Speicherung verworfen. Daraus folgt keine Anonymität sämtlicher übriger GA4-Daten.

IPv4-mapped IPv6 richtig erkennen

Ein Dual-Stack-Server kann eine IPv4-Verbindung als ::ffff:203.0.113.45 darstellen. Die IPv4-Adresse liegt dabei in den unteren 32 Bit. Eine echte binäre Kürzung auf IPv6-/48 würde diese Bits vollständig entfernen; die eingebettete Adresse bleibt dabei gerade nicht vollständig erhalten.

Problematisch sind vielmehr Textoperationen oder unterschiedliche Regeln für gleichwertige Schreibweisen. Auch ::ffff:cb00:712d und 0:0:0:0:0:ffff:cb00:712d beschreiben dieselbe gemappte Adresse. Ein Test auf den Textanfang ::ffff: reicht deshalb nicht. Ein Parser erkennt zunächst den Adresstyp und wendet anschließend die passende Regel an:

import ipaddress

def mask_ip(text, ipv4_prefix=24, ipv6_prefix=48):
    address = ipaddress.ip_address(text.strip())
    if isinstance(address, ipaddress.IPv6Address):
        if address.scope_id is not None:
            raise ValueError('Scoped addresses are outside this example')
        address = address.ipv4_mapped or address
    prefix = ipv4_prefix if address.version == 4 else ipv6_prefix
    network = ipaddress.ip_network((address, prefix), strict=False)
    return network.with_prefixlen

Das Beispiel gibt für alle drei Schreibweisen sowie für 203.0.113.45 denselben Wert 203.0.113.0/24 zurück. Ungültige Eingaben werden abgewiesen. Die Standardwerte /24 und /48 dienen zur Demonstration und sind keine pauschale Datenschutzempfehlung. Der Baustein erwartet eine einzelne Adresse aus einer vertrauenswürdigen Quelle, keine ungeprüfte Liste aus X-Forwarded-For.

Die Stelle im Datenfluss bestimmt die Reichweite

Eine Kürzung beim Empfänger kann die spätere Speicherung minimieren, obwohl die vollständige Adresse zuvor für die Verbindung verarbeitet wurde. Soll bereits die Weitergabe der vollständigen Besucheradresse verhindert werden, muss die Kürzung vor dieser Weitergabe stattfinden.

Bei einer echten Server-zu-Server-Anfrage ist auf Verbindungsebene normalerweise die öffentliche Ausgangsadresse des Servers beziehungsweise dessen Proxys sichtbar. Besucheradressen können trotzdem zusätzlich in Payloads, URL-Parametern oder Headern übertragen werden. Das Kürzen eines einzelnen Feldes wie client_ip_address genügt nur, wenn keine ungekürzte Kopie auf einem anderen Weg mitgeht. Außerdem muss das jeweilige API-Schema gekürzte Werte überhaupt sinnvoll unterstützen.

Ein direkt geladenes Browser-Tag kontaktiert den Anbieter über die Netzwerkverbindung des Browsers beziehungsweise des verwendeten VPNs oder Proxys. Ein gekürzter Payload-Parameter versteckt diese Verbindungsadresse nicht. Eine eigene Domain allein ändert daran nichts: Auch hinter einem CNAME kann weiterhin der externe Anbieter die Verbindung entgegennehmen. Entscheidend ist eine tatsächlich kontrollierte Zwischenstation und deren Weitergabeverhalten.

Anonymität braucht eine Bewertung des ganzen Datensatzes

Eine gekürzte IP zusammen mit Zeitstempel, Konto-ID, Cookie-Kennung oder seltenem Nutzungsmuster kann weiterhin zuordenbar sein. Umgekehrt lässt sich der Personenbezug nicht allein aus einer bestimmten Präfixlänge pauschal für jeden Empfänger feststellen. Maßgeblich sind die verfügbaren Zusatzinformationen und realistisch nutzbaren Identifizierungsmittel.

Der EuGH hat 2025 in der Rechtssache C-413/23 P für die Verordnung (EU) 2018/1725 hervorgehoben, dass pseudonymisierte Daten nicht automatisch für jede Person personenbezogen sind. Die Prüfung hängt vom Verarbeitungskontext ab; bestehende Informationspflichten bei der Erhebung verschwinden dadurch nicht. Eine IP-Maske ersetzt diese Bewertung nicht.

Eine überprüfbare Dokumentation benennt Zweck, Maskenlänge, Zeitpunkt der Kürzung, verbleibende Kennungen, Empfänger und Löschfristen. Dabei ist die Zahl möglicher Adressen als mathematische Größe auszuweisen, nicht als nachgewiesene Zahl anonymer Personen. Je nach Zweck können zusätzliche Aggregation, kürzere Aufbewahrung oder das vollständige Weglassen der Adresse sinnvoll sein.