UU PPSK : comparaison des fonctionnalités et des modèles de déploiement

UU PPSK : comparaison des fonctionnalités et des modèles de déploiement Un podcast de briefing technique de Purple Durée approximative : 14 minutes Bienvenue dans ce briefing technique de Purple. Je vais vous guider à travers l'une des décisions les plus importantes que vous aurez à prendre lors de la conception du WiFi pour une propriété résidentielle ou commerciale multi-locataires : quel modèle de clé pré-partagée déployer. Et plus précisément, nous allons nous concentrer sur le UU PPSK, qui signifie Unique per-User Pre-Shared Key (clé pré-partagée unique par utilisateur), et pourquoi il est devenu l'architecture de choix pour les opérateurs de Build to Rent (BTR), les fournisseurs de logements étudiants et les propriétaires d'immeubles collectifs (MDU) à travers le Royaume-Uni. Commençons par le problème. Si vous êtes un promoteur immobilier ou un propriétaire, vous gérez un bâtiment où des dizaines ou des centaines de foyers distincts partagent la même infrastructure réseau physique. Vous devez offrir à chaque résident une expérience WiFi privée, comme à la maison. Leur Chromecast doit trouver leur téléphone. Leur enceinte connectée doit communiquer avec leurs ampoules. Et surtout, rien de tout cela ne doit être visible pour le résident de l'appartement d'à côté. La réponse traditionnelle à ce problème consistait soit à utiliser un mot de passe partagé - ce qui est une catastrophe de sécurité à grande échelle - soit à procéder à un déploiement d'entreprise 802.1X complet, ce qui nécessite une infrastructure à clés publiques, la gestion des certificats et un serveur RADIUS que la plupart des exploitants immobiliers n'ont tout simplement pas les ressources informatiques nécessaires pour gérer. Aucune de ces options n'est adaptée à un immeuble BTR de 200 unités. C'est là que le PPSK intervient. PPSK signifie Private Pre-Shared Key. Le concept est simple : au lieu d'un seul mot de passe WiFi partagé pour tout l'immeuble, chaque résident dispose de sa propre clé unique. Ils se connectent au même SSID, au même nom de réseau, mais leur clé est unique. S'ils déménagent, vous révoquez leur clé. Cela n'a aucun impact sur les autres résidents. Il existe en réalité trois modèles distincts, et il est essentiel de comprendre la différence entre eux pour prendre la bonne décision architecturale. Le premier modèle est le PSK partagé standard. Un seul mot de passe, tout le monde sur le même réseau. C'est ce que la plupart des bâtiments utilisent encore aujourd'hui. C'est simple à déployer, mais c'est un point de défaillance unique. Si un résident partage le mot de passe sur un forum, vous perdez le contrôle de votre réseau. Vous voulez supprimer l'accès d'un prestataire ? Vous devez changer le mot de passe pour tout le monde. À grande échelle, ce n'est tout simplement pas gérable. Le deuxième modèle est le Group PPSK. Ici, vous attribuez une clé unique à chaque groupe d'utilisateurs, par exemple une clé par étage ou une clé par type de bail. C'est mieux qu'un mot de passe partagé, mais cela pose toujours un problème de zone d'impact. Si une clé d'un groupe est compromise, tout le groupe est concerné. De plus, vous ne pouvez toujours pas isoler les résidents individuels les uns des autres au niveau de la couche réseau. Le troisième modèle, et celui sur lequel nous nous concentrons aujourd'hui, est le UU PPSK, Unique per-User Pre-Shared Key, également appelé iPSK par Cisco, DPSK par Ruckus et MPSK par HPE Aruba. La terminologie varie selon le fournisseur, mais le concept est identique. Chaque résident, chaque groupe d'appareils, obtient sa propre clé unique sur le plan cryptographique. Et cette clé est associée à son propre VLAN, son propre segment de réseau, complètement isolé de tous les autres résidents de l'immeuble. C'est cette architecture qui offre ce que j'appelle la bulle WiFi. Les appareils du résident A peuvent se voir, ils peuvent caster, s'associer, partager des fichiers, exactement comme ils le feraient sur un réseau domestique. Mais le résident A ne peut voir aucun appareil appartenant au résident B, même s'ils sont tous deux connectés au même point d'accès, sur le même SSID, en utilisant la même infrastructure de câblage physique. Laissez-moi vous présenter le flux d'authentification technique, car c'est là que la magie opère. Lorsqu'un appareil de résident se connecte au SSID, le contrôleur LAN sans fil intercepte la tentative de connexion et transmet l'adresse MAC de l'appareil à un serveur RADIUS. Le serveur RADIUS, qui peut être hébergé dans le cloud, comme l'est celui de Purple, recherche cette adresse MAC dans son annuaire d'identités. Il renvoie une réponse Access-Accept contenant la clé pré-partagée unique attribuée à ce résident. Le contrôleur valide la clé présentée par l'appareil par rapport à la clé renvoyée. Si elles correspondent, l'appareil est authentifié et placé sur le VLAN dédié du résident. De plus, cette réponse RADIUS transporte également l'attribution du VLAN. L'appareil n'est donc pas seulement authentifié. Il est automatiquement placé sur le bon segment de réseau, avec la bonne politique de bande passante, les bonnes règles de pare-feu, le tout à partir d'un seul SSID. Pas de prolifération de SSID. Pas de surcharge de balises. Un seul nom de réseau, des centaines de réseaux privés isolés en dessous. Un mot maintenant sur la randomisation des adresses MAC, car c'est le piège qui fait échouer la plupart des déploiements. Depuis iOS, Android et Windows, les appareils utilisent par défaut des adresses MAC randomisées pour des raisons de confidentialité. Si votre serveur RADIUS effectue une recherche MAC et que l'appareil présente une adresse randomisée, la recherche échoue et l'appareil ne peut pas se connecter. La solution consiste à configurer votre SSID pour demander aux clients d'utiliser leur adresse MAC matérielle permanente, ou à mettre en œuvre un flux de pré-enregistrement dans lequel les résidents enregistrent leur appareil avant de se connecter. La plateforme de Purple gère cela automatiquement dans le cadre du flux d'intégration des résidents. Parlons des modèles de déploiement, car le UU PPSK peut être déployé de trois manières distinctes, et le bon choix dépend de la taille de votre bâtiment, de vos ressources informatiques et de votre budget. Le premier est le PPSK local au contrôleur. Ici, les clés uniques sont stockées directement sur le contrôleur sans fil, sans qu'aucun serveur RADIUS externe ne soit requis. Cela fonctionne bien pour les petits déploiements, jusqu'à environ 200 unités, et c'est le plus simple à utiliser. Ubiquiti UniFi prend en charge cela nativement. La limite réside dans l'évolutivité. La plupart des contrôleurs sont limités à quelques centaines d'entrées PPSK locales, et vous perdez la gestion centralisée du cycle de vie qui rend l'exploitation du PPSK viable à grande échelle. Le deuxième modèle est le PPSK basé sur RADIUS. Ici, les clés sont stockées dans un serveur RADIUS externe, et le contrôleur interroge le serveur RADIUS à chaque nouvelle connexion. Ce modèle s'adapte à des milliers d'unités. TP-Link Omada prend en charge jusqu'à 4 000 PPSK avec un serveur RADIUS externe. Ruckus SmartZone, HPE Aruba ClearPass et Cisco ISE prennent tous en charge ce modèle. Les coûts opérationnels sont plus élevés, mais l'évolutivité et les capacités de gestion du cycle de vie sont nettement supérieures. Le troisième modèle, et celui que Purple recommande pour les opérateurs BTR et MDU, est le cloud RADIUS-as-a-Service. Ici, l'infrastructure RADIUS est hébergée et gérée par Purple, et vous y connectez vos points d'accès via une superposition cloud. Cela vous offre l'évolutivité du PPSK basé sur RADIUS sans les coûts opérationnels liés à la gestion de votre propre serveur RADIUS. La plateforme de Purple s'intègre au-dessus de votre matériel existant, qu'il s'agisse de Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme ou Fortinet, et fournit la couche d'orchestration pour le provisionnement des clés, la gestion du cycle de vie et l'intégration des résidents. Le cycle de vie des clés est entièrement automatisé. Un résident emménage, sa clé est provisionnée via l'intégration du système de gestion immobilière. Il déménage, sa clé est révoquée instantanément, sans aucun impact sur les autres résidents. Aucune intervention manuelle, aucune faille de sécurité, aucun problème de rotation des mots de passe. Laissez-moi vous présenter deux scénarios de déploiement concrets pour illustrer cela. Le premier est un développement Build to Rent de 250 unités. Le promoteur avait spécifié des points d'accès Cisco Meraki dans tout le bâtiment. Ils avaient besoin que chaque résident bénéficie d'une expérience WiFi privée avec une prise en charge complète de l'IoT, une disponibilité dès le premier jour de l'emménagement et la capacité de prendre en charge 15 à 25 appareils par foyer. Le foyer BTR moyen connecte désormais 18 appareils au WiFi, des téléphones et ordinateurs portables aux enceintes connectées, clés de streaming et appareils électroménagers connectés. L'architecture déployée consistait en un seul SSID sur l'ensemble du bâtiment, avec un PPSK via le service cloud RADIUS de Purple. Chaque résident a reçu une clé unique lors de son emménagement, fournie via l'application des résidents. La clé était associée à un VLAN dédié avec un sous-réseau privé, offrant à chaque foyer un segment de réseau entièrement isolé. La réflexion mDNS a été activée au sein de chaque VLAN, de sorte que Chromecast, Apple TV et Sonos fonctionnaient tous comme prévu. Le bâtiment a été mis en service avec 250 VLAN de résidents actifs dès le premier jour, avec zéro configuration RADIUS manuelle requise de la part de l'équipe sur site.Le deuxième scénario concerne une résidence étudiante de 400 lits construite à cet effet. Le défi réside ici dans le renouvellement annuel de la cohorte. Chaque mois d'août, 400 étudiants quittent les lieux et 400 nouveaux s'installent, souvent au cours de la même semaine. Avec un modèle PSK partagé, cela implique une rotation des mots de passe à l'échelle du bâtiment affectant chaque résident restant. Avec l'UU PPSK, cela signifie révoquer 400 clés et en provisionner 400 nouvelles, le tout automatisé via l'intégration du système de gestion des étudiants. Le déploiement a utilisé Ruckus SmartZone avec DPSK, soutenu par le service RADIUS de Purple. Chaque étudiant a reçu sa clé unique par e-mail lors de l'inscription préalable à son arrivée. La clé était valide pour la durée de leur bail et expirait automatiquement à la date de fin de leur contrat. L'équipe opérationnelle a constaté une réduction de 70 % des tickets d'assistance liés au WiFi au cours du premier trimestre, principalement parce que les problèmes d'association de Chromecast et de smart TV qui avaient perturbé le déploiement précédent de PSK partagé ont été complètement éliminés. Abordons maintenant l'aspect de la conformité, car cela importe pour les gestionnaires immobiliers de manière parfois sous-estimée. Le GDPR exige que vous puissiez démontrer votre responsabilité en matière de traitement des données. Dans le contexte du WiFi, cela signifie être capable d'identifier quel résident a généré quel trafic réseau, et d'être en mesure de répondre à une demande d'accès ou à une demande des forces de l'ordre avec des données précises et spécifiques au résident. Avec un PSK partagé, c'est impossible. Chaque appareil sur le réseau semble identique du point de vue du serveur RADIUS. Avec l'UU PPSK, chaque connexion est liée à une clé de résident spécifique, elle-même liée à un dossier de location spécifique. Votre piste d'audit est complète. Laissez-moi vous donner trois règles de base pratiques avant de passer aux questions rapides. Règle une : si votre bâtiment compte plus de 50 unités, utilisez l'UU PPSK soutenu par RADIUS, et non le PPSK local au contrôleur. Le plafond d'évolutivité du PPSK local au contrôleur vous posera des problèmes dans les 12 mois suivant la mise en service. Règle deux : planifiez la randomisation des adresses MAC dès le premier jour. Intégrez un flux de travail de pré-enregistrement dans votre processus d'intégration des résidents. Ne supposez pas que les appareils présenteront leur adresse MAC permanente par défaut. Règle trois : automatisez le cycle de vie des clés. La valeur opérationnelle de l'UU PPSK par rapport à un PSK partagé dépend entièrement du provisionnement et de la révocation automatiques des clés. La gestion manuelle des clés à grande échelle n'est pas viable. Intégrez-la dès le départ à votre système de gestion immobilière ou à votre système de gestion des étudiants. Passons maintenant à une session rapide sur les questions que l'on me pose le plus souvent. L'UU PPSK fonctionne-t-il avec WPA3 ? Oui, avec des nuances. Le WPA3-SAE modifie le mécanisme de handshake. La plupart des contrôleurs modernes prennent en charge l'UU PPSK en mode de transition WPA2 et WPA3 pour la compatibilité descendante. Vérifiez la documentation spécifique de votre fournisseur avant de spécifier un déploiement purement WPA3. Combien de clés uniques un seul SSID peut-il prendre en charge ? Cela dépend de votre plateforme de contrôleur. Avec un serveur RADIUS externe, la limite pratique est la capacité de votre base de données RADIUS. Le service de cloud RADIUS de Purple s'adapte à des dizaines de milliers de clés simultanées. Le UU PPSK remplace-t-il le 802.1X ? Non. Pour les parcs d'appareils d'entreprise entièrement gérés avec des terminaux enregistrés par MDM et une infrastructure de certificats déjà en place, WPA3-Enterprise avec 802.1X offre une posture de sécurité plus solide. Le UU PPSK est l'outil idéal pour les environnements où vous ne contrôlez pas les appareils qui se connectent à votre réseau, ce qui est exactement la situation dans les déploiements de BTR, de logements étudiants et de MDU. Sur quel matériel fonctionne-t-il ? La solution cloud de Purple prend en charge Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme et Fortinet. Vous n'avez pas besoin de remplacer vos points d'accès existants. Pour résumer : le UU PPSK est l'architecture d'authentification qui rend l'exploitation du WiFi multi-locataire viable sur le plan opérationnel à l'échelle résidentielle. Il offre une isolation réseau par résident, une prise en charge complète de l'IoT, une gestion automatisée du cycle de vie des clés et une piste d'audit conforme au GDPR, le tout à partir d'un seul SSID sur votre matériel existant. Les trois modèles de déploiement, contrôleur local, adossé à RADIUS et cloud RADIUS-as-a-Service, conviennent à différentes tailles de bâtiments et niveaux de ressources informatiques. Pour tout projet de plus de 50 unités, le cloud RADIUS-as-a-Service est le bon choix. Il élimine la charge opérationnelle liée à la gestion de votre propre infrastructure RADIUS tout en vous offrant l'évolutivité et les capacités de gestion du cycle de vie dont vous avez besoin. La plateforme de WiFi multi-locataire de Purple offre précisément cela. Fondée en 2012, notre solution est déployée dans 80 000 sites actifs et notre plateforme a traité 440 millions de connexions rien qu'en 2024. Nous sommes certifiés ISO 27001, conformes au GDPR et indépendants du matériel. Si vous planifiez un déploiement BTR, de logements étudiants ou de MDU et souhaitez comprendre comment le UU PPSK s'intègre dans votre architecture spécifique, les guides liés dans ce document constituent un bon point de départ. Merci pour votre écoute. À la prochaine.