Accès invité sécurisé : Implémenter le NAC pour les terminaux non gérés

Accès invité sécurisé : Implémenter le NAC pour les appareils non gérés. Un briefing d'information Purple WiFi. Introduction et contexte. Bienvenue. Si vous êtes responsable de la sécurité réseau d'un hôtel, d'une chaîne de magasins, d'un stade ou d'un site du secteur public, vous êtes confronté à un problème de plus en plus complexe : comment offrir aux invités, visiteurs et prestataires un accès WiFi rapide et pratique - sans ouvrir une brèche dans votre infrastructure d'entreprise ? C'est exactement ce que nous allons aborder aujourd'hui. Il ne s'agit pas d'un aperçu théorique. Nous allons couvrir l'architecture, les décisions de déploiement, les exigences de conformité et les scénarios réels où tout se passe bien - et ceux où cela tourne mal. Le défi majeur est le suivant : les appareils non gérés. Vos invités se connectent avec leurs smartphones personnels, ordinateurs portables, tablettes et, de plus en plus, avec des appareils IoT - dont aucun n'est sous votre contrôle, aucun ne dispose de votre agent MDM et tous représentent un risque potentiel pour la sécurité s'ils ne sont pas correctement segmentés et authentifiés. Le Network Access Control, ou NAC, est le cadre qui résout ce problème. Entrons dans le vif du sujet. Analyse technique approfondie. Tout d'abord, définissons précisément ce qu'est réellement le NAC. Le Network Access Control est un cadre de sécurité qui applique un accès basé sur des politiques aux ressources du réseau. Il évalue qui se connecte, quel appareil est utilisé et si cet appareil répond à vos exigences de sécurité - avant d'accorder l'accès. Pour les appareils invités non gérés, la vérification de la sécurité est nécessairement légère, mais les composants d'identité et de segmentation sont essentiels. L'architecture se divise en trois couches fonctionnelles. La première est la couche d'authentification. Pour les appareils d'entreprise gérés, vous utiliseriez généralement la norme 802.1X avec EAP-TLS, où les certificats sont déployés via SCEP par le biais de votre MDM. Mais pour les appareils invités non gérés, le 802.1X n'est pas pratique - les invités n'ont pas de certificats et vous ne pouvez pas leur en imposer. La couche d'authentification pour les invités repose donc sur un Captive Portal : une page d'authentification web qui intercepte la requête HTTP ou HTTPS initiale et redirige l'utilisateur vers un flux de connexion ou d'inscription. C'est là que fonctionnent les plateformes comme la solution Guest WiFi de Purple - en capturant l'identité via une connexion par réseau social, un e-mail, une vérification par SMS ou un formulaire d'inscription, et en transmettant cette identité au moteur de politique NAC. La deuxième couche est le moteur de politique. C'est là que sont prises les décisions d'accès. Le système NAC évalue l'identité authentifiée par rapport à vos politiques d'accès et attribue l'appareil au segment de réseau approprié. Pour un invité, cela signifie généralement un VLAN invité dédié avec un accès Internet uniquement et sans routage vers vos sous-réseaux d'entreprise. Pour un prestataire avec un appareil connu, vous pouvez lui attribuer un VLAN restreint avec accès à des ressources internes spécifiques. Le moteur de politique peut également appliquer un accès basé sur le temps - un participant à une conférence obtient un accès pour la durée de l'événement, un client d'hôtel obtient un accès pour la durée de son séjour. La troisième couche est la mise en application. Celle-ci est gérée à la périphérie du réseau - vos points d'accès sans fil, vos commutateurs et votre pare-feu. Le système NAC communique avec ces appareils via RADIUS, le protocole Remote Authentication Dial-In User Service. Lorsqu'un invité s'authentifie, le serveur RADIUS renvoie un message Access-Accept avec des attributs d'attribution de VLAN, et le point d'accès place l'appareil sur le bon VLAN. Si l'authentification échoue, le serveur RADIUS renvoie un message Access-Reject, et l'appareil reste dans un VLAN de quarantaine de pré-authentification avec un accès uniquement au Captive Portal. Parlons maintenant de WPA3. Si vous déployez ou modernisez votre infrastructure sans fil, WPA3 devrait figurer sur votre feuille de route. WPA3-SAE, qui signifie Simultaneous Authentication of Equals, remplace WPA2-PSK et élimine la vulnérabilité aux attaques par dictionnaire hors ligne. Pour les réseaux d'invités en particulier, WPA3-OWE - Opportunistic Wireless Encryption - est particulièrement pertinent. L'OWE fournit un chiffrement sans nécessiter de mot de passe, ce qui signifie que les invités bénéficient d'une connexion chiffrée sans friction supplémentaire. Il s'agit d'une amélioration significative par rapport à l'SSID d'invité ouvert traditionnel, qui transmet les données en texte clair. La conformité n'est pas négociable dans la plupart des secteurs d'activité dont nous parlons. Si vous gérez un hôtel avec un système de point de vente, PCI-DSS exige une segmentation stricte du réseau entre les environnements de données des titulaires de cartes et les réseaux d'invités. L'exigence est explicite : le WiFi invité doit se trouver sur un segment de réseau distinct sans routage vers le périmètre PCI. Le NAC applique cette règle au niveau de la couche réseau, et votre politique de pare-feu l'applique au périmètre. Le GDPR ajoute une autre dimension - si vous collectez des données d'identité d'invités via votre Captive Portal, vous devez obtenir un consentement explicite, disposer d'une base légale pour le traitement et d'une politique de conservation des données. La plateforme de Purple gère nativement la capture de consentement conforme au GDPR, avec des périodes de conservation configurables et des pistes d'audit. Abordons également la randomisation des adresses MAC, car c'est un véritable casse-tête opérationnel. Depuis iOS 14, Android 10 et Windows 10, les appareils randomisent leur adresse MAC par SSID par défaut. Cela brise toute politique NAC qui repose sur l'adresse MAC comme identifiant persistant. La bonne réponse consiste à déplacer votre modèle d'identité vers l'utilisateur authentifié, et non vers l'adresse MAC de l'appareil. Lorsqu'un invité s'authentifie via votre Captive Portal, vous liez sa session à son identité authentifiée - e-mail, numéro de téléphone ou profil social - plutôt qu'à son adresse MAC. La plateforme d'analyse de Purple gère cela correctement, en maintenant l'identité au niveau de l'utilisateur d'une session à l'autre, même lorsque l'adresse MAC change. Pour les organisations qui ont besoin d'une évaluation plus approfondie de l'état de sécurité des terminaux non gérés, il existe des approches avec et sans agent. L'évaluation de l'état de sécurité sans agent utilise des techniques telles que l'empreinte de l'OS, le balayage des ports ouverts et l'analyse de l'user-agent HTTP pour classifier les terminaux et évaluer la conformité de base. Cela est approprié pour les réseaux invités où vous souhaitez identifier le type de terminal à des fins d'analyse ou appliquer des politiques différenciées - par exemple, bloquer l'accès de certains objets connectés à des services spécifiques. L'évaluation de l'état de sécurité avec agent exige que l'utilisateur installe un agent temporaire, ce qui convient aux scénarios d'accès des sous-traitants ou des partenaires, mais crée des frictions pour les invités ponctuels. Recommandations de déploiement et pièges à éviter. Laissez-moi vous guider à travers la séquence de déploiement la plus efficace en pratique. Commencez par la segmentation du réseau avant de toucher à la configuration du NAC. Définissez vos VLANs : un VLAN de pré-authentification avec accès uniquement au Captive Portal et aux DNS, un VLAN invité avec accès internet et sans routes internes, et éventuellement un VLAN sous-traitant avec un accès interne restreint. Mettez en place les ACL de votre pare-feu. C'est la fondation - tout le reste repose dessus. Deuxièmement, déployez votre infrastructure RADIUS. Pour la plupart des déploiements sur le marché intermédiaire, un service RADIUS hébergé dans le cloud et intégré à votre plateforme de Captive Portal est la solution idéale. Cela élimine la charge opérationnelle liée à la gestion de serveurs RADIUS sur site et fournit la redondance nécessaire pour un réseau invité en production. Assurez-vous que vos secrets partagés RADIUS sont forts et renouvelés régulièrement. Troisièmement, configurez votre Captive Portal. Le portail doit être accessible depuis le VLAN de pré-authentification - ce qui signifie que la résolution DNS pour le domaine du portail doit fonctionner avant l'authentification. Configurez votre plage DHCP sur le VLAN de pré-authentification pour pointer vers un serveur DNS qui résout le domaine du portail. Testez cela attentivement - une mauvaise configuration DNS est la cause la plus fréquente d'échec du Captive Portal. Quatrièmement, testez votre attribution de VLAN de bout en bout. Connectez un terminal de test, effectuez le parcours d'authentification et vérifiez que le terminal arrive sur le bon VLAN avec la bonne politique d'accès. Utilisez une capture de paquets pour confirmer que les attributs RADIUS sont transmis correctement. Vérifiez que le VLAN invité n'a pas de route vers vos sous-réseaux d'entreprise - lancez un traceroute depuis le VLAN invité vers une IP d'entreprise et confirmez qu'il échoue. Maintenant, les pièges à éviter. Le cas de défaillance le plus courant est la mauvaise configuration du split-tunneling - où le VLAN invité dispose d'une route involontaire vers les ressources internes en raison d'une règle de pare-feu mal configurée ou d'une ACL manquante. Auditez vos règles de pare-feu avant la mise en service. La deuxième défaillance courante concerne la gestion des délais d'attente RADIUS - si votre serveur RADIUS est injoignable, que se passe-t-il ? Assurez-vous que vos points d'accès sont configurés pour basculer en mode fermé (fail-closed) et non en mode ouvert (fail-open). Le mode fail-open signifie que les invités accèdent au réseau même si le serveur RADIUS est hors service, ce qui constitue un risque de sécurité. Le mode fail-closed signifie qu'aucun accès n'est autorisé si le serveur RADIUS est injoignable, ce qui est la posture correcte pour un déploiement sécurisé. Le troisième piège est l'expiration du certificat sur votre Captive Portal. Si le certificat TLS de votre portail expire, les invités verront un avertissement de sécurité du navigateur et votre taux d'authentification chutera à presque zéro. Automatisez le renouvellement des certificats avec Let's Encrypt ou votre plateforme de gestion des certificats. Questions et Réponses Rapides. Ai-je besoin de la norme 802.1X pour les réseaux invités ? Non. La norme 802.1X est adaptée aux appareils d'entreprise gérés. Pour les invités non gérés, un Captive Portal avec attribution de VLAN basée sur RADIUS est l'architecture correcte. Puis-je utiliser un seul SSID pour les invités et les appareils d'entreprise ? Techniquement oui, en utilisant l'attribution dynamique de VLAN basée sur le résultat de l'authentification. Mais sur le plan opérationnel, des SSID distincts sont plus simples à gérer et plus faciles à auditer. Gardez-les séparés. Comment gérer les appareils IoT qui ne peuvent pas effectuer un parcours de Captive Portal ? Utilisez le contournement d'authentification basé sur l'adresse MAC (MAB) pour les appareils IoT connus avec des adresses MAC pré-enregistrées. Pour les appareils IoT inconnus, placez-les dans un VLAN de quarantaine et examinez-les manuellement. Quel est le bon délai d'expiration de session pour l'accès invité ? Pour le secteur de l'hôtellerie, alignez-le sur la durée du séjour de l'invité. Pour le commerce de détail, deux à quatre heures sont courantes. Pour les événements, alignez-le sur le programme de l'événement. Configurez toujours un délai d'inactivité - 30 minutes d'inactivité constituent une valeur par défaut raisonnable. Dois-je enregistrer le trafic des invités ? Oui, à des fins juridiques et de conformité. Conservez les journaux de connexion - IP source, horodatage, identité authentifiée - pendant un minimum de 90 jours, ou plus si votre juridiction l'exige. La plateforme de Purple fournit cette piste d'audit de manière native. Résumé et Prochaines Étapes. Pour résumer : l'accès invité sécurisé pour les appareils non gérés est un problème résolu, mais il nécessite une architecture délibérée. Les trois piliers sont l'identité - qui se connecte ; la segmentation - où ils peuvent aller ; et l'application - comment vous vous assurez que la politique est respectée. Le NAC relie ces éléments, avec RADIUS comme protocole de communication entre votre plateforme d'authentification et votre infrastructure réseau. Pour vos prochaines étapes : si ce n'est pas déjà fait, auditez la segmentation actuelle de votre réseau invité. Confirmez qu'il n'existe aucune route entre votre VLAN invité et vos sous-réseaux d'entreprise. Passez en revue le parcours de consentement GDPR de votre Captive Portal et la configuration de la rétention des données. Et si vous êtes sur du WPA2 avec un SSID invité ouvert, inscrivez le WPA3-OWE sur la feuille de route de renouvellement de votre infrastructure. La plateforme de Purple s'intègre directement à cette architecture - fournissant le Captive Portal, la capture d'identité, la couche de conformité GDPR et les analyses qui s'ajoutent à votre infrastructure NAC. Si vous souhaitez voir comment cela s'applique à l'environnement spécifique de votre établissement, l'équipe de Purple peut vous présenter une architecture de référence adaptée à votre cas d'usage. Merci pour votre écoute. C'était un briefing de Purple sur le WiFi intelligent concernant l'accès invité sécurisé : implémentation du NAC pour les terminaux non gérés.