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

Bienvenue dans cette fiche technique de Purple. Aujourd'hui, nous abordons le PPSK de Ruckus. Il s'agit de l'architecture WiFi Private Pre-Shared Key, et plus particulièrement de son application aux déploiements résidentiels et commerciaux multi-locataires. Je vais vous expliquer en quoi cela consiste, comment cette solution se compare aux autres options, quel modèle de déploiement convient à votre situation et quels sont les pièges à éviter pour mener à bien votre projet. C'est parti. Tout d'abord, abordons le problème. Si vous gérez un programme immobilier locatif, une résidence étudiante ou tout autre type d'immeuble collectif, vous êtes confronté à un défi WiFi spécifique que les réseaux d'entreprise standards ne résolvent pas de manière simple. Dans un réseau WPA2 Personnel traditionnel, tous les appareils du bâtiment partagent le même mot de passe. Lorsqu'un résident déménage, vous n'avez que deux options. Soit vous modifiez le mot de passe, ce qui coupe le WiFi de tous les autres résidents de l'immeuble. Soit vous laissez l'ancien résident conserver son accès. Aucune de ces solutions n'est acceptable. Et à l'échelle de 200 logements, aucune n'est viable sur le plan opérationnel. C'est précisément le problème que résout le PPSK. La clé privée pré-partagée (Private Pre-Shared Key) attribue à chaque résident, à chaque appartement ou à chaque groupe d'appareils sa propre clé WiFi unique. Ils se connectent tous au même SSID, c'est-à-dire au même nom de réseau, mais chaque clé est associée à un VLAN distinct - un réseau local virtuel. L'appartement 12 est sur le VLAN 10. L'appartement 13 est sur le VLAN 20. Les appareils IoT sont sur le VLAN 99. Le point d'accès gère automatiquement l'association entre la clé et le VLAN. Aucun serveur RADIUS n'est requis dans le modèle de base. Pas d'infrastructure de certificats. Pas de demandeur 802.1X sur l'appareil. Un mot maintenant sur la terminologie, car c'est là que réside une réelle confusion sur le marché. Aruba l'appelle PPSK. Cisco Meraki l'appelle iPSK, ou Identity PSK. Juniper Mist utilise le terme ePSK. Extreme Networks, qui a initialement développé le concept sous la marque Aerohive, l'appelle Private PSK. Ubiquiti UniFi l'appelle simplement PPSK. Cambium utilise également le terme ePSK. Le mécanisme sous-jacent est identique pour tous : un seul SSID, plusieurs clés uniques, chaque clé étant liée à un VLAN ou à un groupe de politiques. Les appellations des constructeurs relèvent du marketing et non d'une distinction technique. Laissez-moi vous expliquer ce qui se passe réellement au niveau de la couche d'association, car c'est là que cette architecture prend tout son sens. Lorsqu'un appareil d'un résident se connecte au SSID, il présente sa clé pré-partagée lors de la poignée de main à quatre voies WPA2. Le point d'accès, ou le contrôleur cloud sous-jacent, recherche cette clé dans la base de données PPSK, identifie le VLAN auquel elle est associée et marque le trafic de l'appareil en conséquence à partir de ce moment-là. L'appareil détecte une connexion WiFi tout à fait normale. Il n'a aucune idée qu'il a été placé dans un segment isolé. Son Chromecast fonctionne. Son enceinte connectée s'associe. Sa console de jeux obtient le bon type de NAT. Tout fonctionne exactement comme sur une connexion haut débit domestique, car du point de vue de l'appareil, c'est le cas.C'est la distinction essentielle avec le 802.1X, qui est la norme d'entreprise pour les réseaux du personnel et les environnements d'entreprise. Le 802.1X nécessite un serveur RADIUS, un fournisseur d'identité et un supplicant sur chaque appareil. Le supplicant est le composant logiciel qui gère l'échange d'authentification EAP. Chaque ordinateur portable géré et chaque téléphone d'entreprise en possède un. Le réfrigérateur intelligent de votre résident n'en a pas. Le contrôleur CVC de votre bâtiment n'en a pas. Vos capteurs IoT n'en ont pas. Le PPSK fonctionne avec chacun d'eux car il opère au niveau de la couche WPA Personal, et non de la couche WPA Enterprise. Ceci étant dit, le PPSK ne remplace pas le 802.1X dans les environnements d'entreprise. C'est un outil différent pour un problème différent. Si vous gérez un réseau pour le personnel où la responsabilité individuelle est importante, où vous devez savoir qu'une personne spécifique s'est authentifiée à un moment précis et que vous devez révoquer son accès dès qu'elle quitte l'organisation, le 802.1X est la bonne réponse. Si vous gérez un réseau résidentiel où vous avez besoin d'une isolation par foyer, d'un support IoT et d'une simplicité opérationnelle à grande échelle, le PPSK est la bonne réponse. Examinons les trois modèles de déploiement, car c'est là que se prend la décision architecturale. Le premier modèle est le modèle de contrôleur cloud. C'est le schéma le plus courant pour les nouveaux déploiements. Vos points d'accès se connectent à une plateforme de gestion cloud. Le magasin de clés PPSK réside dans le contrôleur cloud. Lorsque vous configurez un nouveau résident, vous créez une clé dans le portail, vous l'attribuez à un VLAN et le contrôleur pousse la politique vers chaque point d'accès du bâtiment. Le résident reçoit sa clé par e-mail, SMS ou via un code QR dans son pack d'accueil. Ils le scannent, tous leurs appareils se connectent, et leur Chromecast, enceinte intelligente et console fonctionnent tous immédiatement. Lorsqu'ils déménagent, vous supprimez la clé. Leurs appareils cessent de se connecter. Personne d'autre n'est affecté. Ce modèle fonctionne bien pour les déploiements allant jusqu'à environ 200 unités. C'est le plus simple à exploiter et il ne nécessite aucune infrastructure supplémentaire. Le deuxième modèle est le PPSK avec un backend RADIUS. Certains déploiements d'entreprise utilisent un serveur RADIUS pour stocker et valider les identifiants PPSK. Cela vous permet d'obtenir une journalisation centralisée, des pistes d'audit et une intégration avec votre plateforme de gestion des identités. Cela ajoute des frais d'infrastructure mais vous offre la responsabilité du 802.1X avec la compatibilité d'appareil du PPSK. C'est le bon modèle pour les environnements mixtes, par exemple un espace de coworking où vous avez à la fois des appareils d'entreprise gérés et des équipements IoT appartenant aux membres, ou un développement BTR où l'opérateur a des obligations de conformité qui nécessitent des pistes d'audit par résident. Le troisième modèle est l'architecture hybride. Les résidents utilisent le PPSK pour leurs ordinateurs portables et leurs appareils IoT. Le personnel de l'immeuble utilise le 802.1X pour les appareils de l'entreprise. Les deux groupes se connectent à la même infrastructure physique mais sont associés à des segments logiques différents. Purple recommande cette architecture pour les déploiements complets de type Build to Rent et d'unités d'habitation multiples. Trois modèles d'authentification distincts, trois VLANs distincts, une infrastructure physique. C'est l'architecture qui vous offre la simplicité grand public pour les résidents et la responsabilité d'entreprise pour le personnel, sans avoir à gérer deux réseaux distincts. Entrons maintenant dans les détails de l'implémentation. Si vous déployez le PPSK pour un projet BTR ou une propriété MDU, voici la séquence qui fonctionne. Commencez par votre conception logique avant de toucher au matériel. Cartographiez votre nombre de résidents, vos catégories d'appareils IoT et tous les systèmes du personnel ou de gestion. Attribuez les VLANs. Un déploiement BTR classique ressemble à ceci : les VLANs 10 jusqu'au nombre total de vos unités pour les résidents, un VLAN par appartement ou un VLAN par étage selon la densité. Le VLAN 99 pour l'IoT. Le VLAN 100 pour la gestion du bâtiment. Le VLAN 200 pour le WiFi invité dans les espaces communs. Documentez ensuite votre plan d'adressage IP. Dans un immeuble de 200 unités, vous envisagez de 3 000 à 5 000 appareils connectés au réseau à tout moment. C'est le chiffre de 15 à 25 appareils par foyer issu des recherches de la British Property Federation. Vos plages DHCP doivent s'adapter à cela. Utilisez l'adressage privé RFC 1918 avec des tailles de sous-réseau suffisantes par VLAN. Un slash 24 vous donne 254 adresses utilisables. Un slash 23 vous en donne 510. Adaptez la taille en conséquence. Concernant le choix du matériel, le PPSK est pris en charge par toutes les principales plateformes de points d'accès d'entreprise. Cisco Meraki l'appelle iPSK et le gère via le tableau de bord Meraki. HPE Aruba l'implémente nativement dans ArubaOS et Aruba Central. Ruckus le prend en charge via SmartZone et la plateforme Ruckus Cloud. Juniper Mist utilise l'ePSK avec une gestion RF optimisée par l'IA. Ubiquiti UniFi propose le PPSK depuis 2023, bien qu'il faille noter qu'il est actuellement limité au WPA2 et ne fonctionnera pas sur la bande 6 gigahertz. Cambium et Extreme le prennent tous deux en charge via leurs plateformes cloud respectives. Une contrainte critique à signaler : l'implémentation PPSK d'UniFi est limitée au WPA2. Si vous spécifiez des points d'accès WiFi 6E et souhaitez utiliser la bande 6 gigahertz pour les clients PPSK, vous aurez besoin d'une plateforme qui prend en charge le WPA3-SAE avec PPSK, ou vous devrez limiter les clients PPSK aux bandes 2,4 et 5 gigahertz. Aruba, Ruckus et Meraki prennent tous en charge le PPSK sur les configurations WPA3. Passons maintenant aux pièges. Ce sont les modes de défaillance que je constate à plusieurs reprises dans les déploiements de production. Premier piège : la prolifération des SSID. Chaque SSID que vous diffusez consomme du temps d'antenne pour les trames de balise. Dans un immeuble résidentiel dense, si vous diffusez six ou huit SSIDs par point d'accès, vous dégradez les performances pour tout le monde. Limitez-vous à un maximum de quatre SSIDs par radio. Utilisez le PPSK pour desservir plusieurs segments de résidents à partir d'un seul SSID plutôt que de créer un SSID distinct par appartement ou par étage. Deuxième piège : une configuration insuffisante des ports trunk. Vous concevez un schéma VLAN propre, vous déployez les points d'accès, puis le trafic est discrètement interrompu parce que quelqu'un a oublié d'autoriser les VLANs concernés sur une liaison trunk entre le commutateur de distribution et la couche d'accès. Validez chaque port trunk lors de la mise en service. Documentez-le. Testez-le avec un appareil sur chaque VLAN avant l'arrivée des résidents. Troisième piège : la distribution des clés. Générer des clés est facile. Les transmettre aux résidents de manière sécurisée et gérable sur le plan opérationnel est plus difficile. Un code QR dans le livret d'accueil fonctionne bien pour le jour de l'emménagement. Un portail résidentiel où ils peuvent récupérer leur clé et ajouter de nouveaux appareils est préférable pour les opérations courantes. Créez le flux de travail de distribution des clés avant de déployer, pas après. Quatrième piège : la randomisation des adresses MAC. Depuis iOS 14, Android 10 et Windows 11, 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. Configurez votre SSID pour demander aux clients d'utiliser leur adresse MAC matérielle permanente, ou mettez en œuvre un flux de travail de pré-enregistrement. La plateforme de Purple gère cela automatiquement dans le cadre du flux d'intégration des résidents. Laissez-moi vous présenter deux scénarios réels pour rendre cela concret. Scénario un : un complexe résidentiel Build to Rent de 180 logements en centre-ville. L'opérateur souhaitait que le WiFi soit inclus dans le loyer comme un service, avec une activation le jour de l'emménagement et une prise en charge complète de la maison intelligente. Ils ont déployé des points d'accès HPE Aruba gérés via Aruba Central. Chaque appartement reçoit une clé PPSK unique générée lors de la signature du bail. La clé est envoyée par e-mail au résident avec un code QR. Ils le scanne, tous leurs appareils se connectent, et leur Chromecast, enceinte connectée et console fonctionnent immédiatement. Lorsqu'un résident déménage, le gestionnaire de la propriété supprime la clé dans le portail. Le nouveau résident reçoit une nouvelle clé lors de son emménagement. Aucun problème de rotation de mot de passe. L'opérateur a constaté une réduction de 30 % des tickets d'assistance liés au WiFi par rapport à son déploiement précédent de mot de passe partagé. Scénario deux : une résidence étudiante de 400 lits construite à cet effet. Le défi ici est la semaine d'emménagement de la cohorte, avec des centaines d'étudiants arrivant simultanément, essayant tous de connecter des dizaines d'appareils à la fois. L'opérateur a utilisé des points d'accès Ruckus avec SmartZone, déployant PPSK avec une clé par chambre. Les clés ont été pré-générées et incluses dans le pack d'accueil envoyé avant l'arrivée. Les étudiants ont scanné le code QR à l'arrivée et ont été connectés en quelques secondes. Le réseau a géré le pic d'emménagement sans dégradation car le trafic de chaque étudiant était isolé dans son propre segment VLAN. Passons maintenant à une série de questions-réponses rapides sur les sujets qui reviennent le plus souvent. Combien de clés PPSK un seul point d'accès peut-il gérer ? La plupart des plateformes d'entreprise prennent en charge des milliers de clés par SSID. Cisco Meraki prend en charge jusqu'à 5 000 entrées iPSK par réseau. Aruba propose une évolutivité similaire. Ubiquiti UniFi prend en charge jusqu'à 1 000 entrées PPSK par réseau. Pour un bâtiment de 200 unités, vous êtes largement dans les limites sur n'importe quelle plateforme. Est-ce que le PPSK fonctionne avec WPA3 ? Oui, sur la plupart des plateformes d'entreprise. WPA3-SAE offre une protection plus forte contre les attaques par dictionnaire hors ligne par rapport à WPA2-PSK. L'exception est UniFi, qui est actuellement en WPA2 uniquement pour le PPSK. Puis-je intégrer le PPSK à mon système de gestion immobilière ? Oui, via l'API du fournisseur. Aruba Central, Meraki, Ruckus et Mist exposent tous des API REST pour la gestion des clés PPSK. La plateforme de Purple fournit une couche d'intégration pré-intégrée qui connecte automatiquement votre système de gestion immobilière au cycle de vie des clés PPSK. Le PPSK est-il conforme au GDPR ? Oui, lorsqu'il est déployé correctement. Le PPSK avec des clés par résident vous donne la piste d'audit dont vous avez besoin pour répondre aux demandes d'accès aux données et aux demandes des forces de l'ordre avec des données spécifiques aux résidents. Avec une clé PSK partagée, c'est impossible. Chaque appareil semble identique du point de vue du réseau. En résumé. Le PPSK est l'architecture correcte pour le WiFi multi-locataires dans le résidentiel locatif (BTR), les résidences étudiantes et les environnements d'immeubles collectifs (MDU). Il offre une isolation par unité, une compatibilité IoT et une simplicité opérationnelle que ni le PSK standard ni le 802.1X ne peuvent égaler dans un contexte résidentiel. Concevez vos VLAN avant de toucher au matériel. Sécurisez vos liaisons trunk. Automatisez la distribution de vos clés. Vérifiez la prise en charge WPA3 de votre fournisseur si vous déployez du WiFi 6E. Et intégrez-le à votre système de gestion immobilière dès le premier jour, et non après coup. Purple opère dans 80 000 sites actifs et s'intègre en tant qu'overlay cloud sur Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme et Fortinet. Si vous souhaitez voir comment cela fonctionne en pratique pour votre projet, la prochaine étape est un appel de cadrage technique avec notre équipe de conception réseau. Merci d'avoir écouté ce briefing technique Purple.