Sitzungsverfolgung von Mandanten und Missbrauchszuordnung in MDU WiFi: Zuordnung von Meraki-Flows zur Purple iPSK-Identität

Um Missbrauch in einem MDU-Netzwerk mit einer einzigen öffentlichen IP-Adresse zuzuordnen, führen Sie zwei Datensätze zusammen. Der Meraki MX-Flow-Export ordnet die öffentliche IP-Adresse, den übersetzten Quellport und den Zeitstempel einer internen IP, MAC und einem VLAN zu. Die iPSK-Identitäts- und RADIUS-Accounting-Einträge von Purple ordnen diese MAC und dieses VLAN einer Wohnung zu. Bewahren Sie beide Datensätze unter Berücksichtigung rechtlicher Beratung 365 Tage lang auf.

Was bewirkt die Missbrauchszuordnung in einem MDU-Netzwerk tatsächlich?

Purple Multi-Tenant WiFi bietet jedem Bewohner in einem Mehrfamilienhaus (MDU), einem Build-to-Rent-Block (BTR) oder einem Studentenwohnheim ein privates Netzwerk, das sich wie das eigene Breitbandnetz zu Hause anfühlt. Hinter diesem Erlebnis steht eine harte architektonische Tatsache: Jeder Bewohner verlässt das Gebäude über dieselbe öffentliche WAN-Adresse und nutzt dabei die Port-Adressübersetzung (PAT). PAT ist eine Form von NAT, bei der sich viele interne Hosts eine einzige öffentliche IP-Adresse teilen, die sich nur durch den vom Gateway zugewiesenen Quellport unterscheidet. Wenn ein Urheberrechtsinhaber, eine Missbrauchsstelle oder ein Polizeibeamter nach Ihnen sucht, sehen sie eine einzige IP-Adresse. Sie erwarten einen einzigen Abonnenten dahinter. Sie haben jedoch Hunderte.

Die Missbrauchszuordnung stellt diese verloren gegangene Zuordnung wieder her. Dies geschieht auf Basis von zwei unabhängigen Datenebenen: den Netzwerk-Flows des Gateways und den Identitätsdaten von Purple. Keine der beiden Ebenen reicht alleine aus. Zusammengeführt über MAC-Adresse, VLAN und Zeit führen sie Sie von einer öffentlichen IP-Adresse und einem Port direkt zu einer bestimmten Wohnung.

Warum eine einzige öffentliche IP-Adresse die Zuordnung unmöglich macht

Eine typische Meldung nach dem US-amerikanischen Digital Millennium Copyright Act (DMCA), 17 U.S.C. § 512, enthält drei Felder: öffentliche IP-Adresse, Quellport und Zeitstempel. RFC 6302, die Richtlinie der IETF für Server mit Internetverbindung, empfiehlt die Protokollierung des Quellports und eines genauen Zeitstempels, eben weil eine gemeinsame Adressierung die IP-Adresse allein mehrdeutig macht. Ihre Aufgabe ist es, dieses Design zu berücksichtigen. Wenn Ihre Protokolle den übersetzten Port und eine präzise Uhrzeit enthalten, lässt sich die Meldung beantworten. Wenn nicht, können Sie das Gebäude identifizieren und mehr nicht.

Was iPSK dazu beiträgt

Diese Anleitung setzt voraus, dass Sie bereits wissen, was iPSK (Identity Pre-Shared Key) ist. Die Leitfäden von Purple "Implementing iPSK for secure IoT" und "iPSK vs 802.1X: a comparison" behandeln die Voraussetzungen. Kurz gesagt: iPSK weist jedem Mieter eine eindeutige Passphrase auf einer gemeinsam genutzten SSID zu, und der RADIUS-Server verknüpft diesen Schlüssel mit einer Identität. RADIUS (Remote Authentication Dial-In User Service, RFC 2865) authentifiziert die Sitzung. RADIUS Accounting (RFC 2866) protokolliert, wann sie beginnt, wie lange sie dauert und wann sie endet. Diese Anleitung befasst sich mit der operativen Ebene darüber: wie Sie diese Identitätseinträge in Beweise umwandeln, die Sie Ihrem Rechtsberater vorlegen können.

Was benötigen Sie, bevor Sie beginnen?

Sie müssen vier Dinge eingerichtet haben, bevor die erste Meldung eingeht. Ein nachträglicher Aufbau funktioniert nicht, da die benötigten Beweise dann bereits gelöscht sind.

1. Ein VLAN-pro-iPSK-Design. Der Schlüssel jedes Mieters platziert dessen Geräte in einem dedizierten Layer-3-Segment vor der NAT-Grenze.
2. Einen Flow-Export vom Meraki MX, der Pre-NAT- und Post-NAT-Adressierung mit Zeitstempeln enthält.3. Purple RADIUS Accounting aktiviert, plus ein regelmäßiger Export der iPSK-zu-Mandanten-Zuordnung.
3. Eine von der Rechtsabteilung freigegebene Aufbewahrungsrichtlinie sowie NTP auf jedem Gerät in der Kette.

Warum VLAN-pro-iPSK besser ist als eine flache, gemeinsam genutzte SSID

Ein VLAN (Virtual LAN) ist ein logisches Layer-2-Segment, definiert in IEEE 802.1Q, das eine Gruppe von Geräten von einer anderen isoliert. Die RADIUS-Antwort von Purple kann jeder iPSK ein VLAN zuweisen, sodass jede Wohnung in ihrem eigenen Subnetz landet. Dieses Subnetz wird zu einer zweiten, unabhängigen Kennung. Selbst wenn eine MAC-Adresse gefälscht oder zufällig generiert wird, identifiziert die interne Quell-IP immer noch das Segment der Wohnung.

Design	Zuordnungs-Granularität	Übersteht MAC-Zufallsgenerierung	Mandanten-Isolierung	Für wen geeignet
Flache, gemeinsam genutzte SSID, ein PSK	Nur Gebäude	Nein	Standardmäßig keine	Kleines Café oder Lobby-Gästenetzwerk, nicht für Wohnanlagen
Gemeinsam genutzte SSID, iPSK, keine VLANs	Geräte-MAC zu Mandant	Teilweise, über Accounting-Datensatz zur Sitzungszeit	Nur Client-Isolierung	Zwischenschritt während der Migration
iPSK mit VLAN pro Mandant	Wohnungs-Subnetz und MAC	Ja, das Subnetz identifiziert weiterhin die Wohnung	Layer-3-Segmentierung pro Wohnung	MDU, BTR, Studentenzimmer, Serviced Apartments
802.1X mit Zugangsdaten pro Person	Benannte Person	Ja	Richtlinie pro Benutzer	Corporate-Multi-Tenant-Büros mit verwalteten Geräten

Für Wohnanlagen ist VLAN-pro-iPSK der richtige Standard. Es bietet Ihnen zwei Kennungen, die übereinstimmen müssen: das VLAN und die MAC. 802.1X (der IEEE-Standard für portbasierte Zugriffskontrolle) erreicht das Individuum. Es hat jedoch Schwierigkeiten mit Spielekonsolen, Smart-TVs und anderen Geräten, die von Bewohnern mitgebracht werden.

Wie richten Sie die beiden Datenerfassungen ein?

Erfassung 1: Netzwerkflüsse von der Meraki MX

Die Meraki MX kann Ereignis- und Flussdaten per Syslog (RFC 5424) senden und Verkehrsdaten per NetFlow Version 9 (RFC 3954) exportieren. Konfigurieren Sie beides im Meraki Dashboard unter den Berichtseinstellungen des Geräts. Folgen Sie der Dokumentation von Cisco Meraki für die aktuellen Menüpfade.

Entscheidend ist, welche Felder Ihren Collector erreichen. Für jede übersetzte Verbindung benötigen Sie:

• Interne Quell-IP und Quell-Port
• Client-MAC-Adresse oder eine zuverlässige IP-zu-MAC-Bindung aus DHCP-Protokollen
• VLAN oder Quell-Subnetz
• Öffentliche IP nach NAT und übersetzter Quell-Port
• Start- und End-Zeitstempel in Millisekundenauflösung, sofern vom Exporter unterstützt

Der Port nach NAT ist das Feld, das Betreiber am häufigsten vermissen. In IPFIX (RFC 7011) sind die relevanten Informationselemente postNATSourceIPv4Address und postNAPTSourceTransportPort, beide definiert im IANA-IPFIX-Register. Bevor Sie sich auf den Export verlassen, erfassen Sie ein Muster. Bestätigen Sie, dass Ihre Firmware den übersetzten Port ausfüllt. Wenn dies nicht der Fall ist, ist Ihr Ausweichverfahren das MX-Firewall- und Fluss-Syslog in Kombination mit einem NAT-Übersetzungsprotokoll von einem vorgelagerten Gerät, das dies aufzeichnet. Klären Sie dies, bevor Sie es benötigen. Verknüpfen Sie die Flow-Daten mit den DHCP-Lease-Protokollen. Leases liefern Ihnen eine zeitlich begrenzte IP-zu-MAC-Bindung. Diese Bindung ist Ihr Sicherheitsnetz, wenn ein Flow-Datensatz zwar die IP-, aber keine MAC-Adresse enthält.

Erfassung 2: Identität aus Purple

Purple liefert die Identitätshälfte für die Zusammenführung. RADIUS-Accounting-Datensätze enthalten die Client-MAC im Attribut Calling-Station-Id, den Access Point in Called-Station-Id sowie die Start- und Endzeiten der Sitzung. Accounting ist ein Standardbestandteil der RADIUS-Konfiguration von Purple bei jedem unterstützten Hersteller. Der Purple-Support-Artikel für Avaya zeigt eine typische Einrichtung mit aktiviertem Accounting und einem konfigurierten Intervall für Zwischenberichte (Interim Accounting Interval).

Derselbe Artikel weist auf ein Detail hin, das Ihre Zusammenführung stören kann. Hersteller formatieren MAC-Adressen unterschiedlich: bei dem einen in Großbuchstaben mit Bindestrichen, bei dem anderen in Kleinbuchstaben mit Doppelpunkten. Normalisieren Sie jede MAC-Adresse beim Import auf beiden Datenebenen in ein einheitliches Format.

Die zweite Identitätsquelle ist die iPSK-zu-Mandanten-Zuordnung: Welcher Schlüssel gehört zu welcher Wohnung und welches VLAN wird ihm zugewiesen. Exportieren Sie dies täglich aus Purple. So verfügen Sie über eine datierte Momentaufnahme, wer den jeweiligen Schlüssel am fraglichen Tag besaß, und nicht nur, wer ihn heute besitzt. Mietverhältnisse ändern sich. Ein Schlüssel, der heute zu Wohnung 4.12 gehört, gehörte vor sechs Monaten möglicherweise einem früheren Bewohner.

Die Pipeline selbst aufbauen

Wenn Sie Meraki-Syslog noch nicht zentralisieren, reicht eine schlanke Open-Source-Pipeline aus. Eine kleine virtuelle Linux-Maschine genügt für die meisten Standorte.

1. Collector. Führen Sie Fluentd oder Logstash aus. Lauschen Sie auf UDP 514, dem von der IANA zugewiesenen Syslog-Port, und auf dem von Ihnen gewählten NetFlow-Port; UDP 2055 ist die übliche Konvention. Logstash analysiert NetFlow v9 und IPFIX mit seinem NetFlow-Codec.
2. Beim Import normalisieren. Konvertieren Sie alle Zeitstempel in UTC. Konvertieren Sie alle MAC-Adressen in ein einheitliches Format. Kennzeichnen Sie jeden Datensatz mit Standort und VLAN.
3. Speichern. Leiten Sie die Daten an Elasticsearch oder Grafana Loki weiter. In Elasticsearch rolliert eine Index Lifecycle Management (ILM) Richtlinie die Indizes täglich und löscht sie bei Erreichen Ihrer Aufbewahrungsgrenze. In Loki erzwingt der Compactor eine Aufbewahrungsfrist. In beiden Fällen erfolgt die Löschung automatisch und ist prüfbar.
4. Identitäts-Momentaufnahme. Richten Sie einen täglichen Cron-Job ein, der die aktive iPSK-zu-Mandanten-Zuordnung von Purple abruft. Schreiben Sie diese in eine datierte lokale Nachschlagetabelle. Bewahren Sie die Momentaufnahmen nach demselben Aufbewahrungsplan auf wie die Flows.
5. Zugriffskontrolle. Beschränken Sie den Abfragezugriff auf namentlich genannte Mitarbeiter. Protokollieren Sie jede Suche. Da diese Datensätze Bewohner identifizieren, behandeln Sie sie als personenbezogene Daten gemäß GDPR.

Das Ergebnis: Im Falle einer rechtlichen Aufforderung führen Sie die Zusammenführung offline mit Ihren eigenen Daten durch, ohne auf Drittanbieter warten zu müssen.

Wie reagieren Sie auf eine Missbrauchsmeldung?

Wenn eine Meldung eingeht, führen Sie jedes Mal denselben Workflow aus.

Missbrauchsmeldung
(öffentliche IP, Quell-Port, Zeitstempel)
        |
        v
[1] Meraki Flow-Protokoll
    Abgleich von Post-NAT-IP + übersetztem Port
    innerhalb von +/- Uhrentoleranz
        |
        v
(interne IP, MAC, VLAN)
        |
        v
[2] Purple RADIUS Accounting
    MAC mit aktiver Sitzung am Zeitstempel abgleichen
        |
        v
[3] Datiertes iPSK-zu-Tenant-Snapshot
    iPSK + VLAN an diesem Datum abgleichen
        |
        v
Apartment / registrierter Bewohner

Drei Prüfungen halten das Ergebnis vertretbar:

• Disziplin bei der Zeitzone. Konvertieren Sie den Zeitstempel des Hinweises zuerst in UTC. Viele Hinweise kommen in der lokalen Zeitzone des Absenders an.
• Übereinstimmung zwischen Identifikatoren. Das VLAN aus dem Flow-Datensatz muss mit dem vom iPSK zugewiesenen VLAN übereinstimmen. Eine Abweichung bedeutet, dass etwas nicht stimmt. Halten Sie inne und untersuchen Sie den Fall, bevor Sie jemanden benennen.
• Rechtsberatung entscheidet über Offenlegung. Ihre Ausgabe ist ein interner Zuordnungsdatensatz. Ob und wie offengelegt, der Bewohner benachrichtigt oder widersprochen wird, ist eine rechtliche Entscheidung.

Praxisbeispiel: vom Hinweis zum Apartment

Diese Kette verwendet Dokumentationsadressen (RFC 5737) und fiktive Werte.

1. Hinweis. Ein Rechteinhaber meldet ein File-Sharing-Ereignis von 203.0.113.10, Quellport 41822, um 22:17:05 UTC am 14. März.
2. Flow-Abfrage. Sie durchsuchen den MX-Flow-Index nach der Post-NAT IP 203.0.113.10 und dem übersetzten Port 41822 zwischen 22:17:03 und 22:17:07. Ein Datensatz stimmt überein. Interne Quelle 10.40.12.37, Port 51544, VLAN 412.
3. IP zu MAC. Das DHCP-Lease-Protokoll zeigt, dass 10.40.12.37 an diesem Tag von 19:02 bis 23:58 Uhr an die MAC 3C-22-FB-1A-7E-09 gebunden war.
4. Identitätsabfrage. Purple RADIUS Accounting zeigt diese MAC mit einer aktiven Sitzung von 19:02 bis 00:41 Uhr. Die Sitzung wurde mit dem dem VLAN 412 zugewiesenen iPSK authentifiziert.
5. Tenant-Suche. Der iPSK-Snapshot vom 14. März ordnet diesen Schlüssel und VLAN 412 dem Apartment 4.12 zu. Sie übergeben die Kette an die Rechtsabteilung.

Jeder Schritt ist ein zeitgestempelter Datensatz aus einem unabhängigen System. Diese Unabhängigkeit macht die Kette glaubwürdig.

Wie überprüfen Sie, ob die Kette funktioniert?

Warten Sie nicht auf einen echten Hinweis, um eine Lücke zu entdecken. Führen Sie eine vierteljährliche Übung durch:

• Öffnen Sie von einem Testgerät mit einem bekannten iPSK aus eine Verbindung zu einem externen Server, den Sie kontrollieren. Erfassen Sie die öffentliche IP, den Port und die Zeit aus den Protokollen dieses Servers.
• Führen Sie den gesamten Workflow blind aus, beginnend nur mit dem serverseitigen Datensatz.
• Bestätigen Sie, dass Sie beim richtigen Test-Apartment landen. Notieren Sie, wie lange es gedauert hat.
• Überprüfen Sie, ob der älteste Datensatz in jedem Index genau an Ihrer Aufbewahrungsgrenze liegt und nicht darüber hinaus. Eine zu lange Aufbewahrung ist an sich schon ein GDPR-Problem.

Wenn die Übung fehlschlägt, ist die häufigste Ursache ein fehlender Post-NAT-Port oder ein Zeitversatz. Beide Fälle werden unten behandelt.

Was unterbricht die Zuordnungskette und wie beheben Sie das?

Zeitversatz

Die Verknüpfung hängt von der Zeit ab. Übersetzte Ports werden auf einem ausgelasteten Gateway innerhalb von Sekunden wiederverwendet, sodass ein Versatz von wenigen Sekunden bereits zu einer falschen Flow-Zuordnung führen kann. Richten Sie den MX, Ihre Access Points, den Collector und alle vorgeschalteten NAT-Geräte auf dieselben NTP-Quellen (Network Time Protocol, RFC 5905) aus. Protokollieren Sie überall in UTC. Erstellen Sie eine Warnmeldung, wenn der Versatz eines Geräts eine Sekunde überschreitet. Wenn zwei Flows innerhalb Ihres Toleranzfensters übereinstimmen, melden Sie die Unklarheit an die Rechtsabteilung, anstatt sich für eine Option zu entscheiden.

Vorgeschaltetes Carrier-grade NAT

Einige ISPs platzieren Ihr WAN hinter einem Carrier-Grade NAT (CGNAT, beschrieben in RFC 6888). Die öffentliche Adresse Ihrer MX ist dann selbst privat. Der Hinweis enthält die gemeinsam genutzte Adresse und den Port des ISP. Nur der ISP kann dies Ihrem WAN zuweisen, und nur Ihre Protokolle können Ihr WAN einer Wohnung zuordnen. Ihre Aufzeichnungen werden zum einzigen Zuordnungsnachweis innerhalb des Gebäudes. Fragen Sie Ihren ISP, ob Sie sich hinter einem CGNAT befinden, und fordern Sie nach Möglichkeit eine dedizierte öffentliche IP an.

iPSK-Freigabe zwischen Mietern

Wenn ein Bewohner seinen iPSK an einen Nachbarn weitergibt, erscheinen beide Haushalte als eine einzige Wohnung. Setzen Sie die Geräteregistrierung durch: Begrenzen Sie die Anzahl der Geräte pro iPSK und verlangen Sie von den Bewohnern, neue Geräte über Purple zu registrieren. Überprüfen Sie Schlüssel, bei denen die Anzahl der Geräte oder gleichzeitigen Sitzungen plötzlich ansteigt. Ändern Sie einen Schlüssel am Tag des Auszugs im Rahmen Ihres Prozesses für Eintritte, Wechsel und Austritte.

MAC-Randomisierung

Aktuelle iOS- und Android-Versionen weisen standardmäßig eine private MAC pro Netzwerk auf, und einige Einstellungen rotieren diese. Aus diesem Grund erfolgt die Zuordnung über den zum Zeitstempel aktiven RADIUS-Accounting-Eintrag und nicht über ein statisches Register registrierter Geräte. Bei einem VLAN-pro-iPSK benennt das Subnetz die Wohnung auch dann, wenn eine MAC neu ist.

Wie lange sollten Sie die Protokolle aufbewahren?

Die Aufbewahrung ist eine rechtliche Frage. Klären Sie diese mit Ihrem lokalen Rechtsbeistand ab, bevor Sie Einstellungen konfigurieren. Als Mindestmaß bewahren die meisten Betreiber Flow- und Identitätsdatensätze für 365 Tage auf. Dies deckt den Zeitraum ab, den eine zivilrechtliche Vorladung oder eine polizeiliche Anfrage in der Regel benötigt, um einzutreffen.

Zwei Anforderungen wirken in entgegengesetzte Richtungen. Gemäß GDPR Artikel 5(1)(e) dürfen Sie personenbezogene Daten nur so lange aufbewahren, wie es der Zweck erfordert. Im Vereinigten Königreich begrenzt der Investigatory Powers Act 2016 die Aufbewahrungsfristen für Daten auf 12 Monate. In den USA können Vorladungen gemäß DMCA § 512(h) lange nach dem Ereignis eingehen. Halten Sie den vereinbarten Zeitraum in Ihren Datenschutzhinweisen und Mietbedingungen fest. Lassen Sie ihn dann automatisch durch ILM- oder Loki-Aufbewahrungsfristen durchsetzen.

Was kostet es und was erhalten Sie zurück?

Die DIY-Pipeline läuft auf einer einzigen, bescheidenen virtuellen Maschine plus Speicher. Dimensionieren Sie den Speicher, indem Sie das Flow-Volumen einer Woche messen, mit 52 multiplizieren und einen Puffer hinzufügen. Der Beitrag von Purple - die iPSK-Identitätsebene und das RADIUS-Accounting - läuft auf den Access Points, die Sie bereits besitzen. Purple ist hardwareunabhängig bei Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet, ohne dass ein Austausch der Hardware erforderlich ist.

Der Ertrag wird an der vermiedenen Störung gemessen. Zwei illustrative Szenarien verdeutlichen den Unterschied.

Szenario 1: Serviced Apartments in einer Hospitality-Anlage

Ein Apartmenthaus mit 180 Serviced Apartments, das parallel zu einem Hotel-Betrieb geführt wird, erhielt wiederholt Urheberrechtswarnungen in einem flachen, gemeinsam genutzten Netzwerk. Da es keine Möglichkeit zur Zuordnung gab, verschickte der Betreiber eine Warnung per E-Mail an alle Bewohner. Beschwerden folgten, und der ISP drohte mit einer Sperrung. Der Betreiber stellte auf seinem bestehenden Meraki-Bestand auf VLAN-per-iPSK um und richtete die oben beschriebene Logstash-Pipeline ein. Die nächste Warnung konnte in weniger als 20 Minuten einer einzelnen Wohnung zugeordnet werden. Nur dieser Bewohner wurde kontaktiert, und weitere gebäudeweite Warnungen waren nicht mehr erforderlich.

Szenario 2: Wohnungen für systemrelevante Berufe im öffentlichen Sektor

Ein im Besitz der Stadt befindlicher Block mit 90 Wohnungen für systemrelevante Arbeitskräfte in der Nähe eines Krankenhausstandorts erhielt eine polizeiliche Datenabfrage zu einer öffentlichen IP und einem Port. Das Wohnheim-Team verfügte über iPSK und VLANs pro Wohnung, speicherte Protokolle jedoch nur für 30 Tage. Das Ereignis lag außerhalb dieses Zeitfensters. Nach rechtlicher Prüfung verlängerte das Team die Aufbewahrungsfrist auf 365 Tage, fügte den täglichen Identitäts-Snapshot hinzu und begann mit vierteljährlichen Übungen. Eine spätere Anfrage wurde innerhalb eines Arbeitstages beantwortet, wobei eine Wohnung benannt und jeder Hop für den Rechtsbeistand dokumentiert wurde.

Wo sich dies in Ihre gesamte Infrastruktur einfügt

Das gleiche Problem tritt in gemeinsam genutzten Bürogebäuden von Unternehmen auf. Ein Coworking-Betreiber oder ein SaaS-Anbieter, der eine gemeinsam genutzte Infrastruktur für verschiedene Kunden-Mandanten betreibt, steht vor dem Problem einer einzigen öffentlichen IP und vielen Organisationen dahinter. Purple Staff WiFi wendet dort dasselbe Identität-Zuerst-Modell an, typischerweise mit 802.1X und Microsoft Entra ID, Okta oder Google Workspace als Identitätsquelle. Die hier beschriebene Zusammenführung der Datenströme lässt sich unverändert übertragen. Das gleiche Muster eignet sich für gemischt genutzte Einzelhandelsobjekte mit Wohnungen über den Geschäften sowie für Gesundheitswesen-Einrichtungen, die Personalunterkünfte betreiben.

Weitere Hintergrundinformationen finden Sie in den Leitfäden Purple Multi-Tenant WiFi und Purple's iPSK "Implementing iPSK for secure IoT" sowie "iPSK vs 802.1X: a comparison". Wenn Sie Cloud-RADIUS-Anbieter für diese Aufgabe vergleichen, lesen Sie IronWiFi Alternatives for Enterprise Deployments.

Häufig gestellte Fragen

Müssen wir unsere Meraki-Hardware ersetzen, um eine Zuordnung auf Mandantenebene zu erhalten?

Nein. Purple setzt als Cloud-Overlay auf Ihren bestehenden Cisco Meraki Access Points und MX-Appliances auf. Sie aktivieren iPSK mit VLAN-Zuweisung über den RADIUS von Purple, schalten RADIUS-Accounting ein und konfigurieren den Flow-Export auf der MX. Derselbe Ansatz funktioniert mit HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet. Das Gateway muss lediglich die Pre-NAT- und Post-NAT-Adressierung mit Zeitstempeln exportieren.

Speichert Purple die Meraki-Flow-Logs für uns?

Nein. Purple speichert die Identitätshälfte der Kette: iPSK-Zuweisungen, VLAN-Mapping und RADIUS-Accounting-Sitzungen. Die Meraki-Flow- und NAT-Datensätze verbleiben in einem von Ihnen kontrollierten Kollektor, sei es Elasticsearch, Grafana Loki oder ein bestehendes SIEM. Durch diese Aufteilung behalten Sie die Kontrolle über Aufbewahrung, Zugriffskontrolle und Offenlegung. Diese Entscheidungen sollten bei Ihrem Rechtsbeistand liegen, nicht bei einem Dritten.

Wie lange sollten wir Flow- und Identity-Logs aufbewahren?

Die meisten Betreiber bewahren beide für 365 Tage auf, aber die Datenaufbewahrung ist eine rechtliche Entscheidung für Ihre Rechtsabteilung. GDPR Artikel 5(1)(e) beschränkt die Aufbewahrung auf das für den Zweck erforderliche Maß. Im Vereinigten Königreich sind Datenaufbewahrungsanordnungen gemäß dem Investigatory Powers Act 2016 auf maximal 12 Monate begrenzt. Welchen Zeitraum Sie auch immer vereinbaren, veröffentlichen Sie ihn in Ihren Datenschutzhinweisen und setzen Sie die automatische Löschung mittels ILM oder Loki-Retention durch.

Ist das Protokollieren des Datenverkehrs von Bewohnern mit der GDPR vereinbar?

Ja, vorausgesetzt, Sie protokollieren Verbindungsmetadaten, keine Inhalte, und behandeln diese als personenbezogene Daten. Erfassen Sie eine Rechtsgrundlage, in der Regel berechtigte Interessen oder eine rechtliche Verpflichtung, und geben Sie den Zweck sowie die Aufbewahrungsfrist in Ihren Datenschutzhinweisen an. Beschränken Sie den Abfragezugriff auf namentlich genannte Mitarbeiter und protokollieren Sie jede Suche. Purple ist ISO 27001-zertifiziert und GDPR-konform, sodass die Identitätsseite bereits innerhalb eines zertifizierten Kontrollrahmens liegt.

Was passiert, wenn ein Bewohner seinen iPSK mit einem Nachbarn teilt?

Gemeinsam genutzte Schlüssel führen dazu, dass zwei Haushalte in einem einzigen Wohnungseintrag zusammengefasst werden, daher müssen Sie dies verhindern. Begrenzen Sie die Anzahl der Geräte pro iPSK und verpflichten Sie die Bewohner, neue Geräte über Purple zu registrieren. Achten Sie auf plötzliche Sprünge bei der Geräteanzahl oder gleichzeitigen Sitzungen. Mit VLAN-per-iPSK ist der gemeinsam genutzte Schlüssel immer noch dem Segment einer einzelnen Wohnung zugeordnet. Das bietet der Rechtsabteilung einen vertretbaren Ausgangspunkt mit einem dokumentierten Vorbehalt.

Können wir eine Vorladung beantworten, wenn unser ISP Carrier-Grade NAT verwendet?

Ja, aber nur, wenn Ihre eigenen Protokolle vollständig sind. Hinter CGNAT enthält die Benachrichtigung die gemeinsam genutzte Adresse des ISP. Der ISP ordnet diese Ihrem WAN zu, und Ihre Aufzeichnungen müssen Ihr WAN einer Wohnung zuordnen. Ihre Protokolle sind dann der einzige Zuordnungsnachweis innerhalb des Gebäudes. Bitten Sie Ihren ISP nach Möglichkeit um eine dedizierte öffentliche IP und achten Sie auf eine präzise NTP-Disziplin.

Wie viel Aufwand erfordert die Bereitstellung einer DIY-Logging-Pipeline?

Ein kompetenter Netzwerktechniker kann die Open-Source-Pipeline auf einer einzelnen Linux-VM einrichten. Dies umfasst einen Fluentd- oder Logstash-Collector, einen Elasticsearch- oder Loki-Speicher, eine automatische Aufbewahrungsrichtlinie und einen täglichen Identitätsexport aus Purple. Der größere Aufwand liegt in der Validierung. Bestätigen Sie, dass Ihre MX-Firmware den übersetzten Quellport exportiert, und führen Sie eine Blind-Zuordnungsübung durch, bevor Sie sich im Ernstfall auf die Pipeline verlassen.