Sécurité du réseau invité : un guide pratique pour 2026
Published
Le conseil le plus répandu sur la sécurité des réseaux invités est également le plus simpliste. Définissez un mot de passe complexe, changez-le tous les mois, créez un SSID invité distinct, et le tour est joué. C'est faux. Un mot de passe contrôle uniquement qui se connecte. Il ne garantit rien sur la destination d'un appareil connecté, sur les autres équipements qu'il peut atteindre, ni sur la manière de déconnecter un seul invité sans couper l'accès de tous les autres.
Je partirais de l'hypothèse inverse. Chaque appareil invité est non géré et non approuvé, chaque identifiant partagé se propagera, et chaque page de connexion que vous affichez peut être copiée. Concevez votre réseau en tenant compte de ces trois faits et le reste de vos choix deviendra plus simple et plus réaliste.
Table des matières
- Pourquoi les réseaux invités ont besoin de leur propre modèle de sécurité
- Les contrôles clés et comment les vérifier
- Comment segmenter le trafic invité des opérations
- Choisir les méthodes d'accès et gérer les identifiants invités
- Isoler l'IoT et les équipements partagés sans créer le chaos
- Filtrage, surveillance et détection des abus
- Confirmez vos obligations de conformité avant le lancement
Pourquoi les réseaux invités nécessitent leur propre modèle de sécurité
Un hôtel qui donnerait à chaque client la même clé passe-partout ne se prétendrait pas sécurisé sous prétexte que la clé est longue et complexe. Une seule carte perdue permettrait d'ouvrir toutes les chambres. Un réseau plat utilisant un mot de passe invité partagé fonctionne exactement de la même manière. L'identifiant permet à un visiteur, à l'ordinateur portable infecté d'un prestataire ou à un inconnu sur le parking de se connecter au réseau, et l'architecture détermine ensuite s'il peut accéder à une caisse, une imprimante, une interface de gestion ou au téléphone d'un autre client.
Un SSID est une étiquette, pas une frontière. Le chiffrement de la liaison radio empêche l'écoute clandestine occasionnelle à proximité. Il ne définit pas qui peut être routé vers quel emplacement une fois que le trafic atteint vos commutateurs et votre pare-feu.
Ce que montre le schéma des violations
L'ampleur de cette erreur apparaît dans le rapport 2025 de Verizon sur les enquêtes relatives aux violations de données, qui a analysé 22 052 incidents de sécurité réels et identifié 12 195 violations de données confirmées survenues au sein d'organisations. L'utilisation frauduleuse d'identifiants est restée le principal vecteur d'accès initial à 22 %, tandis que l'exploitation des vulnérabilités a atteint 20 %, soit une augmentation de 34 % par rapport au rapport précédent.
Ce même rapport révèle que la politique d'implication des tiers dans les violations a doublé pour atteindre 30%. Les fournisseurs, sous-traitants, locataires et prestataires de services sont précisément les personnes qui se retrouvent souvent sur l'accès visiteurs, car personne ne souhaite les placer sur le réseau du personnel et aucun profil d'accès spécifique n'a été créé pour eux.
Trois sources d'exposition expliquent la plupart des défaillances liées aux accès invités :
- Identifiants partagés : Un mot de passe unique ne peut pas être attribué à une personne spécifique ni être révoqué pour un seul appareil.
- Appareils visiteurs non gérés : Vous ne contrôlez ni l'application de leurs correctifs, ni leur état de protection contre les logiciels malveillants, ni leurs paramètres de partage.
- Réseaux plats : Un appareil compromis peut sonder des systèmes opérationnels qui ne devaient jamais être accessibles.
Une bonne sécurité du réseau invité nécessite donc quatre propriétés fonctionnant ensemble. Vous avez besoin d'une séparation entre les appareils invités et les actifs opérationnels, d'un accès basé sur l'identité plutôt que d'une admission anonyme, d'une révocation rapide pour une personne ou un appareil spécifique, et d'une surveillance capable de détecter toute authentification ou tout trafic anormal. Omettez un seul de ces éléments et les autres porteront une charge plus lourde qu'ils ne le devraient.
Règle pratique : Traitez l'accès invité comme une zone non sécurisée qui s'avère être utile, et non comme un réseau de confiance avec un nom plus convivial.
Les contrôles clés et comment vérifier chacun d'eux
Évaluez votre configuration actuelle par rapport à ce tableau avant d'acheter quoi que ce soit de nouveau. Indiquez pour chaque ligne réussi, échoué ou non testé. "Non testé" est la réponse la plus honnête pour la plupart des établissements, et c'est celle que vous pouvez corriger le plus rapidement.
| Contrôle | Menace arrêtée | Paramètre minimum | Comment vérifier |
|---|---|---|---|
| VLAN invité dédié | Les invités accédant au personnel, aux points de vente et aux systèmes de gestion | VLAN et sous-réseau propres sans routage vers les plages internes | Tester un hôte du personnel à partir d'un appareil invité |
| Isolation des clients | Les invités accédant aux appareils des autres | Activée sur le SSID invité et les points d'accès | Deux appareils invités de test ne peuvent pas se pinguer |
| Règles de pare-feu de refus par défaut | Mouvement latéral depuis le réseau invité vers les hôtes internes | Seuls le DHCP, le DNS, l'authentification portail et la sortie internet sont autorisés | Test d'accessibilité automatisé depuis le VLAN invité |
| DNS invité filtré | Logiciels malveillants, hameçonnage et catégories de contenus indésirables | Résolveur dédié avec blocages par catégorie par VLAN | Interroger un domaine de test à partir d'une catégorie bloquée |
| Captive Portal HTTPS | Faux portails volant des identifiants | Certificat valide sur un domaine stable, aucun champ inutile | Vérifier le certificat et le domaine à partir d'un appareil sain |
| Identifiants invités uniques | Exposition des mots de passe partagés | Une clé ou un certificat par invité, appareil ou session, avec une date d'expiration | Révoquer un identifiant de test et confirmer que les autres se connectent toujours |
| Limites et délais d'expiration par client | Téléchargements massifs et saturation pour les autres utilisateurs | Plafonds par client, délais d'inactivité et de session | Lancer un test de débit pendant qu'un second client consulte du contenu en streaming |
| Limitation du débit d'authentification | Bourrage d'identifiants (credential stuffing) | Ralentir ou bloquer après des échecs répétés | Rejouer des connexions échouées et confirmer une entrée dans le journal |
| Journaux conservés | Zones d'ombre lors des incidents | Journaux d'authentification, DHCP, DNS et pare-feu conservés pendant une période définie | Tracer une session de test de la connexion à la déconnexion |
Un contrôle n'a de valeur que par son test
Une capture d'écran de la configuration prouve l'intention. Un test prouve l'application. Une seule règle de pare-feu permissive héritée d'une ancienne politique peut annuler un VLAN correctement nommé, et personne ne s'en rend compte jusqu'à ce qu'un scanner, un auditeur ou un attaquant tente d'emprunter la voie que vous pensiez fermée.
Exécutez à nouveau la colonne de vérification après chaque modification du pare-feu, du contrôleur ou du point d'accès. Cette discipline compte plus que l'ajout d'un outil supplémentaire. Pour obtenir une vue d'ensemble juridique et opérationnelle sur la protection des systèmes d'entreprise contre les cybermenaces, il est utile d'aligner vos preuves réseau avec les obligations que votre organisation assume déjà pour ses données et ses systèmes.
Je commencerais par les solutions les moins coûteuses. L'isolation des clients et les limites par client sont généralement de simples modifications de configuration sur les points d'accès dont vous disposez déjà. Vous pouvez donc les activer et les tester le jour même. Les règles de pare-feu prennent plus de temps car vous devez d'abord cartographier les dépendances, comme les imprimantes que le personnel s'attend à faire utiliser par les visiteurs ou un terminal de paiement installé par erreur sur le mauvais VLAN.
Traitez d'abord les étapes rapides, puis planifiez correctement le travail sur le pare-feu. Ne laissez pas un projet de segmentation parfait retarder l'activation de l'isolation dès ce soir.
Comment segmenter le trafic invité des opérations
La segmentation peut échouer sans avertissement. Le nom du VLAN semble correct, le SSID y est associé, mais une règle d'autorisation trop large permet toujours aux invités d'accéder au sous-réseau du personnel. Suivez les étapes dans l'ordre et terminez par un test visant à mettre à l'épreuve votre propre configuration.
Ces trois premières étapes posent la structure sur laquelle repose tout le reste.
- Créez un VLAN et un sous-réseau dédiés aux invités. Aucune route interne ne doit pouvoir l'atteindre, et il ne doit pas non plus pouvoir communiquer vers l'intérieur.
- Associez l'SSID invité à ce VLAN. Effectuez cette opération sur le contrôleur sans fil ou le tableau de bord cloud, et non par simple convention de nommage.
- Rédigez des règles de refus par défaut. Bloquez le trafic invité-vers-entreprise, invité-vers-gestion et invité-vers-équipement, à moins que vous ne puissiez justifier d'une raison de l'autoriser.
- Autorisez uniquement ce qui est nécessaire. Autorisez le DHCP, le DNS, l'authentification par Captive Portal et la sortie vers internet. Tout le reste est bloqué par défaut.
- Orientez les invités vers un résolveur DNS filtré. Les invités ne doivent pas hériter du résolveur interne ni être libres d'utiliser le résolveur de leur choix sans règle définie.
- Attribuez au trafic invité son propre adressage source. Les incidents peuvent ainsi être clairement tracés jusqu'à la zone invité au lieu de se confondre avec le trafic du personnel.
- Exécutez un test automatisé de d'accessibilité est-ouest. Depuis un appareil invité, sondez les adresses du personnel, de paiement, des caméras et de gestion, puis corrigez chaque accès ouvert détecté.
- Répétez le même modèle sur chaque site. Standardisez le VLAN, l'adressage, le DNS, la journalisation et les règles de refus afin qu'un site ne devienne pas une exception vulnérable.
Pourquoi la séparation logique des réseaux est essentielle
Cette séquence reflète les directives énoncées dans les conseils de mise en œuvre de la CISA sur la segmentation du trafic réseau invité et de la télémétrie, qui décrivent le trafic invité partageant l'infrastructure physique mais circulant en amont via des VLAN distincts avec un adressage source dédié. Le NIST adopte la même position pour la conception sans fil. Il recommande des WLAN logiques séparés dès que les utilisateurs ont des profils de sécurité différents, en incluant explicitement les réseaux invités externes et internes, et indique que les appareils d'un WLAN ne doivent pas pouvoir se connecter aux appareils d'un autre.
Partager des points d'accès et des commutateurs ne pose pas de problème. Partager la confiance en pose un.
La démonstration ci-dessous montre la logique de segmentation en pratique, ce qui s'avère utile lorsque vous vérifiez les paramètres de votre propre contrôleur par rapport aux étapes ci-dessus.
Planifiez l'adressage et la disposition des SSID comme un seul et même exercice, et non comme des tâches distinctes confiées à des personnes différentes. Une conception claire du réseau WiFi permet de faire concorder le plan VLAN, la couverture et les limites des politiques d'accès.
Le contrôle de réussite est sans appel. Le test de l'étape 7 doit échouer pour chaque adresse interne. Si un appareil de test invité reçoit une réponse d'une caisse, d'un serveur de fichiers ou d'une page de gestion de point d'accès, vous n'avez pas encore de segmentation. Vous avez simplement un schéma.
Choisir les méthodes d'accès et gérer les identifiants invités
Un Captive Portal a deux visages. C'est le moyen le plus simple d'accueillir un inconnu, et un portail copié est le moyen le plus simple de voler les identifiants de cet inconnu. Traitez le portail comme une limite de sécurité, et non comme un simple formulaire marketing avec un bouton de connexion.
| Méthode | Type d'identifiant | Effort requis de l'invité | Niveau de sécurité | Usage idéal |
|---|---|---|---|---|
| Phrase secrète partagée (WPA2 ou WPA3 Personal) | Un seul mot de passe pour tous les utilisateurs | Faible, mais le mot de passe se diffuse largement | Faible | Petits cafés sans personnel ni systèmes de paiement sur le même réseau |
| Captive Portal sur un SSID ouvert | Connexion via SSO, réseaux sociaux, code à usage unique par SMS ou coupon | Moyen, une page de connexion à chaque nouvelle session | Moyen, dépend de la confiance accordée au portail | Grand public et clients d'hôtels, avec HTTPS et consentement enregistré |
| OpenRoaming | Profil d'identité fédérée | Faible, fonctionne sur l'ensemble des réseaux participants | Élevé, contrôlé par le fournisseur d'identités | Voyageurs et visiteurs récurrents dans les sites participants |
| WPA3-Enterprise avec EAP-TLS | Certificat par équipement issu d'un MDM | Faible sur les équipements gérés, configuration requise | Très élevé | Personnel, caisses enregistreuses et équipements gérés |
| Clé prépartagée par équipement (xPSK) | Clé unique liée à un équipement, un utilisateur ou un résident | Faible, clé délivrée une seule fois | Élevé, révocable individuellement | IoT, locations, résidents et équipements ne supportant pas les certificats |
Vérifiez le portail avant de lui faire confiance
Exigez le HTTPS sur un domaine stable disposant d'un certificat valide, et conservez un domaine cohérent afin que les utilisateurs récurrents puissent reconnaître ce qui est authentique. Ne demandez pas de champs dont vous n'avez pas besoin, et n'affichez pas de champ de mot de passe à moins que les utilisateurs ne s'attendent à en voir un. Formez le personnel d'accueil et de terrain à remettre en question une page de connexion inattendue sur un réseau ouvert, car c'est à eux, et non à l'équipe informatique, que les invités demanderont si elle est authentique.
Cette mise en garde n'est pas théorique. Des recherches décrites dans une publication de l'Université de Münster sur les hotspots WiFi publics ont examiné 55 hotspots WiFi publics allemands et ont révélé des comportements continus à haut risque et des violations potentielles du GDPR, notamment une collecte excessive de données personnelles. Une étude distincte de 2025 a révélé que 66 % des participants ne s'inquiétaient pas de l'authenticité ou de la sécurité des Captive Portals. Si les utilisateurs ne peuvent pas faire la différence entre votre portail et une tentative d'usurpation d'identité, ajouter des champs supplémentaires au vôtre augmente les risques au lieu de les réduire.
Pour les visiteurs réguliers, Passpoint ou OpenRoaming supprime totalement le portail lors des visites ultérieures. Le compromis est pratique. Vous avez besoin de points d'accès compatibles et d'un fournisseur d'identité, alors confirmez la prise en charge matérielle avant de la promettre. Lorsque vous spécifiez ce matériel sur plusieurs sites, il est judicieux de nous orienter vers les équipes d'achats afin d'intégrer très tôt des contrôles dans le processus d'achat, de sorte que la capacité des points d'accès soit vérifiée avant la signature des contrats plutôt qu'après l'installation.
Accorder au personnel une classe d'accès différente
Le personnel, les caisses et les administrateurs ne doivent pas partager le chemin invité avec un niveau de privilège supérieur. Pour un accès à haute garantie, les recommandations de la Wi-Fi Alliance sur la sécurité WiFi précisent que le mode WPA3-Enterprise 192 bits autorise uniquement EAP-TLS, avec TLS_ECDHE_ECDSA utilisant AES-256-GCM et SHA-384, ainsi que la courbe elliptique P-384. Validez d'abord la compatibilité des clients, car chaque client sur ce réseau doit fonctionner dans le même mode 192 bits. Conservez un parcours d'intégration invité distinct pour les appareils qui ne peuvent pas le prendre en charge.
Gérer le cycle de vie des identifiants
La raison est mesurable. L'étude 2025 de Verizon sur le bourrage d'identifiants (credential stuffing) a révélé que les identifiants compromis étaient un vecteur d'accès initial dans 22 % des violations examinées, et l'activité de bourrage d'identifiants représentait une médiane de 19 % de toutes les tentatives d'authentification chaque jour. Ce taux s'est élevé à 25 % dans les grandes entreprises, contre 12 % dans les petites entreprises.
Délivrez des accès attribuables à une personne, un équipement, un locataire ou une session. Définissez une expiration dès la création de l'accès, afin qu'une clé d'accès visiteur prenne fin au moment du départ ou à la fin d'une réservation, sans avoir à la supprimer manuellement. Limitez le débit des tentatives d'authentification et enregistrez chaque événement d'authentification en fonction de la stratégie appliquée.
Admettons qu'une tablette visiteur soit signalée volée. Vous révoquez cette clé ou ce certificat spécifique, la tablette est déconnectée et tous les autres invités restent connectés. Avec un mot de passe partagé, les options sont bien pires : soit vous laissez l'équipement volé accéder au réseau, soit vous modifiez le mot de passe pour l'ensemble du bâtiment et devez le redistribuer à tout le monde.
Suivez ces quatre indicateurs pour vérifier si le système maintient ses performances en charge :
- Émission réussie des certificats : Les appareils gérés doivent s'inscrire sans nécessiter de correctifs manuels.
- Latence d'authentification : Des connexions lentes incitent le personnel à chercher des solutions de contournement.
- Taux d'échec d'authentification : Des pics soudains indiquent des attaques ou des profils corrompus.
- Délai de propagation de la révocation : Mesurez le temps pendant lequel un appareil révoqué reste connecté.
Isoler l'IoT et les appareils partagés sans chaos
Un téléviseur d'hôtel, le portable d'un locataire, un terminal de paiement et l'équipement d'un intervenant médical externe ne relèvent pas du même niveau de confiance. Ils ont des propriétaires différents, des processus de mise à jour différents, des besoins de disponibilité différents et des conséquences très différentes en cas de compromission. Qualifier l'ensemble de ces équipements d'« invités » masque ces différences fondamentales.
Regroupez plutôt par fonction. Placez les invités, le personnel, les sous-traitants, les résidents, les objets connectés (IoT) et les systèmes de paiement dans des catégories distinctes, chacune sur son propre VLAN avec des règles de refus par défaut entre eux. Une catégorie n'obtient un accès vers une autre catégorie que lorsqu'un service identifié le requiert.
Appareils ne pouvant pas prendre en charge de certificats
De nombreux équipements opérationnels ne prennent pas en charge EAP-TLS et ne le feront jamais. Ne résolvez pas ce problème en leur transmettant le mot de passe du personnel. Attribuez-leur une clé pré-partagée unique liée à leur adresse MAC, sur un VLAN dédié à leur catégorie d'équipement. Vous pourrez ainsi révoquer un téléviseur ou un capteur spécifique sans impacter le reste du parc.
Contrôlez ensuite ses destinations accessibles. Un thermostat ou une serrure connectée n'a généralement besoin que des points de terminaison cloud de son fabricant et de rien d'autre. Utilisez donc une liste d'autorisations de sortie et un DNS filtré plutôt qu'un accès Internet ouvert. Cela limite les dommages en cas de compromission de l'équipement et rend son comportement réseau habituel facile à identifier.
Prenons l'exemple d'une serrure connectée. Elle se trouve sur un VLAN dédié aux équipements, les invités ne peuvent pas l'atteindre, et sa clé appartient au matériel plutôt qu'à l'invité qui occupe la chambre cette semaine. La clé reste valide au fil des changements d'occupants et n'expire que lorsque vous remplacez l'équipement.
Cette approche est conforme au NIST IR 8350, le guide fondamental de l'IoT 2025 du NIST, qui se concentre fortement sur les scénarios d'équipements basés sur le WiFi et traite la connectivité IoT comme nécessitant des considérations de sécurité et de confiance dédiées plutôt qu'un VLAN invité générique. Le NIST indique également que la segmentation entre les enceintes connectées, les appareils biométriques et les autres systèmes de santé peut limiter la capacité d'un attaquant à passer d'un appareil vulnérable à des systèmes plus sensibles.
Une conception basée uniquement sur des VLAN peut sembler conforme sur un schéma alors que des identifiants partagés et des appareils non gérés restent totalement exposés en arrière-plan.
Surveillez le trafic inter-segments anormal, en particulier les tentatives refusées provenant des VLAN d'appareils. Un capteur de fuite essayant d'atteindre un serveur de fichiers n'est pas une simple curiosité. C'est votre avertissement le plus précoce.
Filtrage, surveillance et détection des abus
Le filtrage fonctionne le mieux sous la forme d'une politique par VLAN, et non comme un paramètre unique pour l'ensemble du bâtiment. Un VLAN invité bénéficie d'un filtrage de contenu, un VLAN personnel d'un blocage des menaces, et un VLAN étudiant d'une politique de protection. Une même infrastructure pour des fonctions différentes.
Pour les invités, le filtrage DNS joue un rôle majeur car vous ne pouvez pas installer de certificats ou d'agents sur leurs appareils, et vous ne devriez pas tenter de déchiffrer leur trafic. Une politique de DNS protecteur vous permet de bloquer les logiciels malveillants, le hameçonnage et les catégories indésirables dès la phase de résolution, tout en maintenant une connexion rapide.
Signaux nécessitant une alerte
- Échecs d'authentification supérieurs à un seuil : Par exemple, plus de cinq tentatives échouées depuis un seul client en dix minutes.
- Comportement DNS inhabituel : Un appareil effectuant beaucoup plus de requêtes que la normale, en particulier vers des domaines récents ou bloqués.
- Tentatives refusées entre le réseau invité et le réseau interne : Toute tentative provenant du VLAN invité vers une adresse interne doit déclencher une alerte, sans attendre un rapport hebdomadaire.
- Bande passante nettement supérieure à la limite par client : Le signe d'un téléchargement massif, d'un tunnelage ou d'une limite mal configurée.
- Modifications du portail : Toute modification apportée à la page du Captive Portal ou à son certificat qui n'était pas planifiée.
Établissez une référence avant de rechercher des anomalies
Enregistrez le nombre normal d'authentifications quotidiennes et les heures de pointe pour chaque site. Un samedi chargé dans un hôtel, un jour de match dans un stade ou la semaine des inscriptions dans un établissement scolaire ressembleront à une attaque si vous ne disposez d'aucune référence à laquelle comparer ces données. Les profils de référence évitent également l'erreur inverse, qui consisterait à ignorer un pic réel lors d'un mardi calme en le prenant pour une charge normale.
Conservez les journaux d'authentification, DHCP, DNS et de pare-feu liés par un identifiant d'appareil ou de session. Un analyste doit pouvoir suivre un visiteur depuis la connexion sur le Captive Portal, en passant par l'attribution d'adresse et l'activité DNS, jusqu'à la déconnexion, au sein d'une seule investigation. Si cela nécessite quatre exportations et un rapprochement manuel des horodatages, la procédure sera abandonnée en cas d'urgence.
Il y a une différence entre un journal existant et un journal exploitable. Testez le lien une fois par trimestre avec un appareil que vous contrôlez, et mesurez la durée du traçage.
Confirmez vos obligations de conformité avant le lancement
Un réseau invité entre généralement dans le champ d'application d'une réglementation en raison de son chemin d'accès vers d'autres systèmes, et non en raison de sa fonction initiale. Si des invités peuvent accéder à un système de cartes bancaires ou à un dossier médical, la réglementation s'applique, même si le réseau est réservé aux visiteurs. La fonction ne réduit pas le périmètre de conformité, c'est l'accessibilité qui le détermine.
| Règle ou norme | S'applique lorsque | Exigence relative au réseau invité | Preuves à conserver |
|---|---|---|---|
| GDPR (UE et UK GDPR) | Le portail collecte des données personnelles auprès des visiteurs | Base légale, minimisation des données, limite de conservation et registre du consentement | Cartographie des données et calendrier de conservation |
| CCPA et CPRA (Californie) | Données personnelles collectées auprès de visiteurs californiens | Avis lors de la collecte et droits de refus (opt-out) concernant la vente ou le partage | Avis de confidentialité et registres des flux de données |
| PCI-DSS v4.0.1 | Le réseau invité peut accéder aux systèmes de données des titulaires de cartes | La segmentation isole le trafic invité de l'environnement des titulaires de cartes ; les clés sans fil changent lorsque le personnel autorisé quitte l'entreprise | Résultats des tests de segmentation et journal des modifications de clés |
| HIPAA (secteur de la santé aux États-Unis) | Le réseau invité partage un chemin d'accès avec des systèmes contenant des ePHI | Contrôles d'accès et d'audit sur chaque système accessible par les invités | Analyse des risques et journaux d'accès |
| CIPA (écoles américaines bénéficiant du programme E-rate) | Les élèves utilisent le réseau | Politique de sécurité Internet et filtrage des contenus nocifs | Configuration du filtre et politique écrite |
| ISO 27001 | Les clients ou la direction demandent une certification | Procédures documentées de contrôle d'accès, de journalisation et de révision | Déclaration d'applicabilité et registres de révision des journaux |
Traitez les obligations dans l'ordre
- Cartographiez ce à quoi la zone invitée peut accéder. Partez de la carte des VLAN et du test d'accessibilité, pas de simples suppositions.
- Déterminez les règles applicables par type de site. Un hôtel, une école et une clinique ont des obligations différentes sur un même modèle.
- Documentez l'architecture et conservez les résultats des tests. Les auditeurs exigent des preuves de l'efficacité de la segmentation. C'est pourquoi vos preuves de conformité PCI-DSS pour le WiFi doivent inclure des résultats d'accessibilité datés et non de simples schémas.
- Définissez une procédure de révocation pour les départs. La clé ou le certificat d'un employé partant doit être supprimé dans un délai défini. Une clé partagée rend cela irréalisable, car la modifier impose de réémettre l'accès pour tous ceux qui en ont encore besoin.
- Planifiez de nouveaux tests après chaque modification. Les modifications apportées aux pare-feux et aux points d'accès sont les principales causes de dérive des architectures conformes.
Purple Access regroupe les réseaux WiFi en trois SSIDs, Open pour les invités et le BYOD, Secure pour le personnel et les utilisateurs de confiance, et xPSK pour les objets, les locataires et les communautés. Les invités qui reviennent utilisent un profil Passpoint ou OpenRoaming sur le réseau Secure, sans portail lors de leur retour, et le profil fonctionne sur chaque propriété qui l'exécute. Les serrures connectées, les thermostats et les détecteurs de fuites reçoivent des clés xPSK individuelles liées aux adresses MAC sur un VLAN d'équipement par classe, inaccessibles pour les invités, et la clé dure plus longtemps que chaque visiteur jusqu'au remplacement de l'équipement.
Quel que soit le modèle déployé, exigez les trois mêmes preuves avant le lancement : une cartographie VLAN, un journal de test d'accessibilité et un registre de test de révocation. Si un fournisseur ne peut pas fournir ces trois éléments, il n'a pas prouvé que son architecture invités fonctionne. Il a seulement prouvé qu'elle se connecte.
Si vous êtes prêt à remplacer les mots de passe partagés et l'accès invité plat par des réseaux séparés et pilotés par l'identité que vous pouvez tester, Purple Access vous offre des réseaux ouverts, sécurisés et xPSK sur les points d'accès que vous possédez déjà, avec révocation par appareil et attribution de VLAN intégrées. Rendez-nous visite pour planifier votre architecture à trois réseaux et découvrir comment les accès invités, le personnel et les équipements peuvent fonctionner proprement côte à côte.
