Suivi des sessions de locataires et attribution d'abus dans le WiFi MDU : associer les flux Meraki à l'identité iPSK Purple

Pour attribuer un abus sur un réseau MDU avec une adresse IP publique unique, vous devez associer deux enregistrements. L'exportation de flux du Meraki MX associe l'IP publique, le port source traduit et l'horodatage à une IP interne, une adresse MAC et un VLAN. L'identité iPSK de Purple et les enregistrements d'authentification RADIUS associent cette adresse MAC et ce VLAN à un appartement. Conservez ces deux éléments pendant 365 jours, sous réserve de conseils juridiques.

À quoi sert réellement l'attribution d'abus sur un réseau MDU ?

Purple Multi-Tenant WiFi offre à chaque résident d'un immeuble collectif (MDU), d'un complexe résidentiel locatif (BTR) ou d'une résidence étudiante un réseau privé similaire à une connexion haut débit à domicile. Derrière cette expérience se cache une réalité architecturale incontournable : chaque résident quitte le bâtiment via la même adresse WAN publique, en utilisant la traduction d'adresse par port (PAT). Le PAT est une forme de NAT où plusieurs hôtes internes partagent une seule IP publique, différenciés uniquement par le port source attribué par la passerelle. Lorsqu'un titulaire de droits d'auteur, un service de lutte contre les abus ou un officier de police effectue une recherche, ils voient une seule IP. Ils s'attendent à trouver un seul abonné derrière celle-ci. Vous en avez des centaines.

L'attribution d'abus reconstruit cette correspondance perdue. Elle le fait à partir de deux plans de données indépendants : les flux réseau de la passerelle et les enregistrements d'identité de Purple. Aucun d'eux ne suffit à lui seul. Associés par l'adresse MAC, le VLAN et l'heure, ils vous permettent de remonter d'une IP publique et d'un port jusqu'à un appartement identifié.

Pourquoi une seule IP publique empêche l'attribution

Un avis typique en vertu de la loi américaine sur le droit d'auteur, le Digital Millennium Copyright Act (DMCA), 17 U.S.C. § 512, comporte trois champs : l'IP publique, le port source et l'horodatage. La RFC 6302, la directive de l'IETF pour les serveurs connectés à Internet, recommande d'enregistrer le port source et un horodatage précis, car l'adressage partagé rend l'IP seule ambiguë. Votre rôle est de respecter cette conception. Si vos journaux contiennent le port traduit et une horloge bien synchronisée, vous pouvez répondre à l'avis. Si ce n'est pas le cas, vous ne pourrez identifier que l'immeuble, et rien d'autre.

Ce que l'iPSK apporte

Ce guide part du principe que vous savez déjà ce qu'est l'iPSK (Identity Pre-Shared Key). Les guides de Purple "Implementing iPSK for secure IoT" et "iPSK vs 802.1X: a comparison" couvrent les prérequis. En résumé, l'iPSK attribue à chaque locataire un mot de passe unique sur un SSID partagé, et le serveur RADIUS associe cette clé à une identité. Le protocole RADIUS (Remote Authentication Dial-In User Service, RFC 2865) authentifie la session. La comptabilisation RADIUS (RFC 2866) enregistre son début, sa durée et sa fin. Ce guide traite de la couche opérationnelle supérieure : transformer ces enregistrements d'identité en preuves que vous pouvez transmettre à un conseiller juridique.

De quoi avez-vous besoin avant de commencer ?

Vous devez mettre en place quatre éléments avant de recevoir le premier avis. Les configurer après coup ne fonctionnera pas, car les preuves dont vous avez besoin auront déjà disparu.

1. Une architecture un VLAN par iPSK. La clé de chaque locataire dirige ses appareils dans un segment de couche 3 dédié avant la limite du NAT.
2. Un export de flux depuis le Meraki MX contenant l'adressage pré-NAT et post-NAT avec les horodatages.3. L'activation de Purple RADIUS Accounting, plus un export régulier de la correspondance iPSK-locataire.
3. Une politique de rétention validée par votre service juridique, et NTP actif sur chaque équipement de la chaîne.

Pourquoi le VLAN-par-iPSK l'emporte sur un SSID partagé classique

Un VLAN (LAN virtuel) est un segment logique de couche 2, défini par la norme IEEE 802.1Q, qui isole un groupe d'équipements d'un autre. La réponse RADIUS de Purple peut attribuer un VLAN par iPSK, de sorte que chaque appartement se retrouve dans son propre sous-réseau. Ce sous-réseau devient un second identifiant indépendant. Même si une adresse MAC est usurpée ou aléatoire, l'IP source interne identifie toujours le segment de l'appartement.

Conception	Finesse de l'attribution	Survit à l'adresse MAC aléatoire	Isolation des locataires	À qui cela convient-il
SSID partagé classique, une seule PSK	Bâtiment uniquement	Non	Aucune par défaut	Petit café ou réseau invité de hall d'accueil, pas de résidentiel
SSID partagé, iPSK, sans VLAN	Adresse MAC de l'équipement liée au locataire	Partiellement, via le journal d'accounting au moment de la session	Isolation client uniquement	Étape intermédiaire lors d'une migration
iPSK avec VLAN par locataire	Sous-réseau de l'appartement et adresse MAC	Oui, le sous-réseau identifie toujours l'appartement	Segmentation de couche 3 par appartement	MDU, BTR, logements étudiants, appartements de services
802.1X avec identifiants individuels	Personne nommée	Oui	Politique par utilisateur	Bureaux d'entreprise multi-locataires avec équipements gérés

Pour les résidences, le VLAN-par-iPSK est le choix par défaut idéal. Il vous offre deux identifiants qui doivent concorder : le VLAN et l'adresse MAC. La norme 802.1X (la norme de contrôle d'accès réseau basée sur les ports de l'IEEE) identifie l'individu. Cependant, elle s'avère complexe avec les consoles de jeux, les smart TV et autres équipements connectés que les résidents apportent.

Comment configurer les deux captures de données ?

Capture 1 : flux réseau depuis le Meraki MX

Le Meraki MX peut envoyer des données d'événements et de flux par Syslog (RFC 5424) et exporter les enregistrements de trafic via NetFlow version 9 (RFC 3954). Configurez ces deux options dans le Dashboard Meraki sous les paramètres de rapport de l'appareil. Suivez la documentation de Cisco Meraki pour connaître les chemins d'accès actuels des menus.

Ce qui importe est l'ensemble des champs qui parviennent à votre collecteur. Pour chaque connexion traduite, vous avez besoin de :

• L'IP source interne et le port source
• L'adresse MAC du client, ou une liaison IP-MAC fiable issue des journaux DHCP
• Le VLAN ou le sous-réseau source
• L'IP publique post-NAT et le port source traduit
• Les horodatages de début et de fin, à la milliseconde près lorsque l'exportateur le permet

Le port post-NAT est le champ qui manque le plus souvent aux opérateurs. En IPFIX (RFC 7011), les éléments d'information pertinents sont postNATSourceIPv4Address et postNAPTSourceTransportPort, tous deux définis dans le registre IANA IPFIX. Avant de vous fier à l'export, capturez un échantillon. Confirmez que votre firmware renseigne bien le port traduit. Si ce n'est pas le cas, votre solution de repli consiste à combiner les journaux Syslog du pare-feu et des flux du MX avec un journal de traduction NAT provenant d'un équipement en amont qui l'enregistre. Réglez ce point avant d'en avoir besoin.

Associez les données de flux aux journaux de baux DHCP. Les baux vous fournissent une liaison IP-vers-MAC limitée dans le temps. Cette liaison est votre filet de sécurité lorsqu'un enregistrement de flux contient l'IP mais pas l'adresse MAC.

Capture 2 : l'identité provenant de Purple

Purple fournit la moitié « identité » de la jointure. Les enregistrements RADIUS Accounting contiennent l'adresse MAC du client dans l'attribut Calling-Station-Id, le point d'accès dans Called-Station-Id, ainsi que les heures de début et de fin de session. L'accounting fait partie intégrante de la configuration RADIUS standard de Purple pour chaque constructeur pris en charge. L'article d'assistance Purple pour Avaya présente une configuration type, avec l'accounting activé et un intervalle d'accounting intermédiaire défini.

Ce même article signale un détail qui peut faire échouer votre jointure. Les constructeurs formatent les adresses MAC différemment : majuscules séparées par des tirets chez l'un, minuscules séparées par des deux-points chez l'autre. Normalisez chaque adresse MAC dans un format unique dès l'ingestion, sur les deux plans de données.

La deuxième source d'identité est la correspondance iPSK-vers-locataire : quelle clé appartient à quel appartement, et quel VLAN elle attribue. Exportez cette liste quotidiennement depuis Purple. Vous disposerez ainsi d'un instantané daté de la personne qui détenait chaque clé le jour en question, et pas seulement de celle qui la détient aujourd'hui. Les locations changent. Une clé qui appartient à l'appartement 4.12 aujourd'hui pouvait appartenir à un ancien résident il y a six mois.

Construire le pipeline vous-même

Si vous ne centralisez pas encore le Syslog Meraki, un pipeline open-source léger fera l'affaire. Une petite machine virtuelle Linux suffit pour la plupart des parcs sur site unique.

1. Collecteur. Utilisez Fluentd ou Logstash. Écoutez sur le port UDP 514 (le port Syslog attribué par l'IANA) et sur le port NetFlow de votre choix (l'UDP 2055 étant la convention habituelle). Logstash analyse le NetFlow v9 et l'IPFIX grâce à son codec netflow.
2. Normaliser à l'ingestion. Convertissez tous les horodatages en UTC. Convertissez toutes les adresses MAC dans un format unique. Marquez chaque enregistrement avec le site et le VLAN.
3. Stocker. Orientez les flux vers Elasticsearch ou Grafana Loki. Dans Elasticsearch, une politique de gestion du cycle de vie des index (ILM) renouvelle les index quotidiennement et les supprime lorsque votre limite de rétention est atteinte. Dans Loki, le compacteur applique une période de rétention. Dans les deux cas, la suppression est automatique et vérifiable.
4. Instantané d'identité. Planifiez une tâche cron quotidienne qui extrait de Purple la correspondance active iPSK-vers-locataire. Écrivez-la dans une table de correspondance locale datée. Conservez les instantanés selon le même calendrier de rétention que les flux.
5. Contrôle d'accès. Limitez l'accès aux requêtes au personnel désigné. Journalisez chaque recherche. Ces enregistrements permettant d'identifier des résidents, traitez-les comme des données personnelles conformément au GDPR.

Résultat : en cas d'assignation, vous exécutez la jointure hors ligne, sur vos propres données, sans dépendre d'un tiers.

Comment répondre à un avis d'abus ?

Lorsqu'un avis arrive, appliquez à chaque fois le même flux de travail.

Avis d'abus
(IP publique, port source, horodatage)
        |
        v
[1] Journal de flux Meraki
    correspondance IP post-NAT + port traduit
    avec une tolérance d'horloge de +/- 
        |
        v
(IP interne, MAC, VLAN)
        |
        v
[2] Purple RADIUS Accounting
    correspondance de l'adresse MAC avec la session active au timestamp
        |
        v
[3] Capture instantanée datée de l'iPSK par rapport au locataire
    correspondance de l'iPSK + VLAN à cette date
        |
        v
Appartement / occupant enregistré

Trois vérifications permettent de garantir la solidité du résultat :

• Discipline du fuseau horaire. Convertissez d'abord le timestamp de la notification en UTC. De nombreuses notifications arrivent avec l'heure locale de l'expéditeur.
• Cohérence entre les identifiants. Le VLAN issu de l'enregistrement de flux doit correspondre au VLAN attribué par l'iPSK. Un écart indique un problème. Arrêtez-vous et analysez la situation avant de désigner qui que ce soit.
• Décision de divulgation par le service juridique. Vos résultats constituent un enregistrement d'attribution interne. La décision de divulguer, d'en informer le résident ou de contester relève du domaine juridique.

Exemple pratique : de la notification à l'appartement

Cet enchaînement utilise des adresses de documentation (RFC 5737) et des valeurs fictives.

1. Notification. Un détenteur de droits signale un événement de partage de fichiers depuis l'adresse 203.0.113.10, port source 41822, le 14 mars à 22:17:05 UTC.
2. Requête de flux. Vous recherchez dans l'index de flux du MX l'adresse IP post-NAT 203.0.113.10 et le port traduit 41822, entre 22:17:03 et 22:17:07. Un enregistrement correspond. Source interne 10.40.12.37, port 51544, VLAN 412.
3. De l'IP à la MAC. Le journal des baux DHCP indique que l'adresse 10.40.12.37 était associée à l'adresse MAC 3C-22-FB-1A-7E-09 ce jour-là de 19:02 à 23:58.
4. Requête d'identité. Le journal Purple RADIUS Accounting montre cette adresse MAC avec une session active de 19:02 à 00:41. La session s'est authentifiée avec l'iPSK attribué au VLAN 412.
5. Recherche du locataire. La capture instantanée de l'iPSK du 14 mars associe cette clé et le VLAN 412 à l'appartement 4.12. Vous transmettez l'historique au service juridique.

Chaque étape correspond à un enregistrement horodaté provenant d'un système indépendant. C'est cette indépendance qui rend l'enchaînement crédible.

Comment s'assurer du bon fonctionnement de l'enchaînement ?

N'attendez pas de recevoir une notification réelle pour découvrir une faille. Organisez une simulation trimestrielle :

• Depuis un appareil de test connecté à un iPSK connu, ouvrez une connexion vers un serveur externe que vous contrôlez. Enregistrez l'IP publique, le port et l'heure à partir des journaux de ce serveur.
• Exécutez l'intégralité du processus à l'aveugle, en partant uniquement de l'enregistrement côté serveur.
• Confirmez que vous arrivez bien au bon appartement de test. Notez le temps nécessaire.
• Vérifiez que l'enregistrement le plus ancien dans chaque index correspond à votre limite de rétention et rien de plus. Une rétention excessive constitue en soi un problème vis-à-vis du GDPR.

Si la simulation échoue, la cause la plus fréquente est l'absence de port post-NAT ou un décalage de l'horloge. Ces deux aspects sont traités ci-dessous.

Qu'est-ce qui peut rompre l'enchaînement d'attribution et comment y remédier ?

Dérive de l'horloge

La corrélation dépend de l'heure. Les ports traduits sont réutilisés en quelques secondes sur une passerelle active - un décalage de quelques secondes peut donc faire correspondre le mauvais flux. Synchronisez le MX, vos points d'accès, le collecteur et tout appareil NAT en amont sur les mêmes sources NTP (Network Time Protocol, RFC 5905). Enregistrez les données en UTC partout. Configurez une alerte lorsque l'écart d'un appareil dépasse une seconde. Si deux flux correspondent dans votre intervalle de tolérance, signalez l'ambiguïté au service juridique plutôt que d'en choisir un au hasard.

Carrier-grade NAT en amont

Certains FAI placent votre WAN derrière un NAT de classe opérateur (CGNAT, décrit dans le RFC 6888). L'adresse publique de votre MX est alors elle-même privée. La notification portera l'adresse et le port partagés du FAI. Seul le FAI peut faire correspondre cela à votre WAN, et seuls vos journaux peuvent associer votre WAN à un appartement. Vos données deviennent l'unique registre d'attribution au sein du bâtiment. Demandez à votre FAI si vous êtes derrière un CGNAT, et demandez une IP publique dédiée dans la mesure du possible.

Partage de clé PSK entre locataires

Si un résident donne sa clé iPSK à un voisin, les deux foyers apparaissent comme un seul et même appartement. Imposez l'enregistrement des appareils : limitez le nombre d'appareils par iPSK et exigez que les résidents enregistrent leurs nouveaux appareils via Purple. Surveillez les clés dont le nombre d'appareils ou de sessions simultanées augmente soudainement. Changez la clé le jour même du déménagement, dans le cadre de votre processus d'arrivée, de changement et de départ des résidents.

Randomisation des adresses MAC

Les versions actuelles de iOS et Android présentent par défaut une adresse MAC privée par réseau, et certains paramètres la modifient par rotation. C'est pourquoi vous devez vous baser sur l'enregistrement RADIUS Accounting actif à l'horodatage, et non sur un registre statique d'appareils enregistrés. Avec un VLAN par iPSK, le sous-réseau identifie toujours l'appartement même lorsqu'une adresse MAC est nouvelle.

Combien de temps devez-vous conserver les journaux ?

La conservation est une question juridique. Validez-la avec votre conseiller juridique local avant de configurer quoi que ce soit. En pratique, la plupart des opérateurs conservent les données de flux et d'identité pendant 365 jours. Cela couvre le délai habituel de réception d'une assignation civile ou d'une réquisition policière.

Deux contraintes s'opposent. Selon l'article 5(1)(e) du GDPR, vous ne pouvez conserver les données personnelles que le temps requis par la finalité du traitement. Au Royaume-Uni, l'Investigatory Powers Act 2016 limite les obligations de conservation des données à 12 mois (conformément au UK GDPR). Aux États-Unis, les assignations DMCA § 512(h) peuvent arriver bien après l'événement. Inscrivez la période convenue dans votre politique de confidentialité et vos conditions de location. Laissez ensuite la politique de conservation de votre ILM ou de Loki l'appliquer automatiquement.

Combien cela coûte-t-il, et quel est le retour sur investissement ?

L'infrastructure fait maison fonctionne sur une seule machine virtuelle modeste et du stockage. Calculez la taille du stockage en mesurant le volume de flux d'une semaine, en le multipliant par 52 et en ajoutant une marge de sécurité. La contribution de Purple - la couche d'identité iPSK et le RADIUS Accounting - fonctionne sur les points d'accès que vous possédez déjà. Purple est compatible avec tous les types de matériel, notamment Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks et Fortinet, sans nécessiter de remplacement de matériel.

Le retour sur investissement se mesure en termes de perturbations évitées. Deux scénarios illustrent cette différence.

Scénario 1 : appartements meublés dans une résidence hôtelière

Un immeuble de 180 appartements meublés, géré en parallèle avec une activité hôtelière, recevait régulièrement des avis d'infraction au droit d'auteur sur un réseau partagé à plat. Sans moyen d'attribuer ces infractions, l'exploitant a envoyé un avertissement par e-mail à tous les résidents. Des plaintes ont suivi, et le fournisseur d'accès internet a menacé de suspendre la ligne. L'exploitant est passé à un système de VLAN par iPSK sur son parc Meraki existant et a mis en place le pipeline Logstash décrit ci-dessus. L'avis suivant a été attribué à un seul appartement en moins de 20 minutes. Seul ce résident a été contacté, et aucun autre avertissement collectif n'a été nécessaire.

Scénario 2 : logements pour travailleurs clés du secteur public

Un immeuble de 90 appartements géré par une municipalité pour des travailleurs clés à proximité d'un site hospitalier a reçu une réquisition judiciaire concernant une adresse IP publique et un port. L'équipe de gestion disposait de l'iPSK et de VLANs par appartement, mais ne conservait les logs que pendant 30 jours. L'événement s'est produit en dehors de cette période. Après avis juridique, l'équipe a prolongé la durée de conservation à 365 jours, a ajouté l'instantané d'identité quotidien et a commencé des exercices trimestriels. Une demande ultérieure a été traitée en un jour ouvrable, identifiant un appartement précis, avec chaque étape documentée pour le service juridique.

Intégration dans votre parc global

Le même problème se pose dans les bureaux d'entreprises multi-locataires. Un exploitant de coworking, ou un fournisseur SaaS exploitant une infrastructure partagée entre plusieurs clients, fait face à une seule IP publique derrière laquelle se trouvent de nombreuses organisations. Le WiFi pour le personnel de Purple applique le même modèle basé sur l'identité, généralement avec le protocole 802.1X et Microsoft Entra ID, Okta ou Google Workspace comme source d'identité. Le flux d'association décrit ici s'applique à l'identique. Le même modèle convient aux projets mixtes de commerce de détail surmontés d'appartements, ainsi qu'aux parcs de santé gérant des hébergements pour le personnel.

Pour plus d'informations, consultez les guides sur le WiFi multi-locataires de Purple et les guides iPSK de Purple, "Mise en œuvre de l'iPSK pour l'IoT sécurisé" et "iPSK vs 802.1X : une comparaison". Si vous comparez des fournisseurs de RADIUS cloud pour ce rôle, lisez Alternatives à IronWiFi pour les déploiements d'entreprise.

Questions fréquentes

Devons-nous remplacer notre matériel Meraki pour obtenir une attribution par locataire ?

Non. Purple s'intègre au-dessus de vos points d'accès Cisco Meraki et de vos équipements MX existants sous forme de couche cloud. Vous activez l'iPSK avec attribution de VLAN via le RADIUS de Purple, activez le RADIUS Accounting, et configurez l'exportation des flux sur le MX. La même approche fonctionne sur HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks et Fortinet. La passerelle doit seulement exporter l'adressage pré-NAT et post-NAT avec les horodatages.

Est-ce que Purple stocke les logs de flux Meraki pour nous ?

Non. Purple conserve la partie identité de la chaîne : les attributions iPSK, le mappage VLAN et les sessions RADIUS Accounting. Les enregistrements de flux et NAT Meraki restent dans un collecteur que vous contrôlez, qu'il s'agisse d'Elasticsearch, de Grafana Loki ou d'un SIEM existant. Ce partage vous permet de garder le contrôle sur la conservation, le contrôle d'accès et la divulgation. Ce sont des décisions qui doivent revenir à votre service juridique, et non à un tiers.### Combien de temps devons-nous conserver les journaux de flux et d'identité ?

La plupart des opérateurs conservent les deux pendant 365 jours, mais la rétention est une décision juridique qui relève de votre conseiller. L'article 5(1)(e) du GDPR limite la conservation à ce que l'objectif exige. Au Royaume-Uni, les avis de conservation des données en vertu de l'Investigatory Powers Act 2016 sont limités à 12 mois. Quelle que soit la période convenue, publiez-la dans votre avis de confidentialité et appliquez la suppression automatique avec la rétention ILM ou Loki.

L'enregistrement du trafic des résidents est-il compatible avec le GDPR ?

Oui, à condition de journaliser les métadonnées de connexion, et non le contenu, et de les traiter comme des données personnelles. Enregistrez une base légale, généralement les intérêts légitimes ou une obligation légale, et indiquez la finalité ainsi que la période de conservation dans votre avis de confidentialité. Limitez l'accès aux requêtes au personnel désigné et auditez chaque recherche. Purple est certifié ISO 27001 et conforme au GDPR, de sorte que la partie identité s'inscrit déjà dans un cadre de contrôle certifié.

Que se passe-t-il si un résident partage sa clé iPSK avec un voisin ?

Les clés partagées fusionnent deux foyers en un seul enregistrement d'appartement, vous devez donc les empêcher. Limitez le nombre d'appareils par iPSK et exigez des résidents qu'ils enregistrent leurs nouveaux appareils via Purple. Surveillez les augmentations soudaines du nombre d'appareils ou des sessions simultanées. Avec un VLAN-par-iPSK, la clé partagée correspond toujours au segment d'un seul appartement. Cela donne aux conseillers juridiques un point de départ défendable, avec une réserve documentée.

Pouvons-nous répondre à une assignation si notre FAI utilise un NAT de classe opérateur ?

Oui, mais seulement si vos propres journaux sont complets. Derrière un CGNAT, la notification porte l'adresse partagée du FAI. Le FAI associe cette adresse à votre WAN, et vos enregistrements doivent associer votre WAN à un appartement. Vos journaux sont alors le seul enregistrement d'attribution à l'intérieur du bâtiment. Demandez à votre FAI une IP publique dédiée dans la mesure du possible, et maintenez une discipline NTP stricte.

Quel effort le déploiement d'un pipeline de journalisation DIY nécessite-t-il ?

Un ingénieur réseau compétent peut mettre en place le pipeline open source sur une machine virtuelle Linux. Cela comprend un collecteur Fluentd ou Logstash, un stockage Elasticsearch ou Loki, une politique de rétention automatisée et un export quotidien des identités depuis Purple. L'effort le plus important réside dans la validation. Confirmez que le firmware de votre MX exporte le port source traduit, puis effectuez un exercice d'attribution à l'aveugle avant de vous fier au pipeline pour une notification réelle.