Captive Portal vs Splash Page

PORTAIL CAPTIF VS SPLASH PAGE - UN BRIEFING TECHNIQUE PURPLE Script de Podcast - Environ 10 Minutes Voix en anglais du Royaume-Uni --- SÉQUENCE 1 : INTRODUCTION ET CONTEXTE (environ 1 minute) Bienvenue dans la série de briefings techniques Purple. Je suis votre hôte, et aujourd'hui, nous allons lever le voile sur l'une des sources de confusion les plus persistantes dans l'acquisition et le déploiement de WiFi pour invités : la différence entre un portail captif et une splash page. Si vous avez déjà assisté à une réunion avec un fournisseur et entendu ces deux termes utilisés de manière interchangeable, vous n'êtes pas seul. Cela se produit constamment - dans les documents d'appel d'offres, dans les présentations de stratégie informatique, et même dans les conversations entre ingénieurs réseau qui devraient pourtant faire la différence. Et cette confusion a son importance, car lorsque vous confondez les deux, vous risquez soit de sur-spécifier le mauvais composant, soit de sous-investir dans le bon, ou pire - de déployer une solution WiFi pour invités qui a fière allure mais qui ne dispose d'aucun contrôle réseau adéquat sous le capot, ou encore une solution techniquement solide qui fait fuir les invités à cause d'un écran de connexion lourd et sans image de marque. Corrigeons donc cela aujourd'hui. À la fin de ce briefing, vous disposerez d'un modèle mental clair de ce que fait chaque composant, de la façon dont ils interagissent et de ce qu'il faut rechercher lorsque vous évaluez des solutions pour votre site - qu'il s'agisse d'un hôtel, d'un parc de points de vente, d'un stade ou d'un bâtiment du secteur public. --- SÉQUENCE 2 : ANALYSE TECHNIQUE APPROFONDIE (environ 5 minutes) Commençons par le portail captif, car c'est la fondation sur laquelle repose tout le reste. Un portail captif est un mécanisme de couche réseau. Son rôle est d'intercepter tout le trafic sortant d'un appareil nouvellement connecté et de le maintenir dans une sorte de salle d'attente numérique jusqu'à ce que cet appareil ait été authentifié. Lorsqu'un invité se connecte à votre SSID WiFi, son appareil obtient une adresse IP via DHCP - cette partie fonctionne normalement. Mais avant que le moindre trafic Internet réel ne soit autorisé à passer, le portail captif l'intercepte. Voici la séquence technique. L'appareil de l'invité envoie une requête HTTP ou HTTPS - il peut essayer de charger un site web, ou il peut s'agir du test de connectivité propre au système d'exploitation, que les appareils modernes comme les iPhones et les téléphones Android exécutent automatiquement. Le contrôleur du portail captif - qui se trouve soit sur votre contrôleur sans fil, votre routeur, soit sur une plateforme basée sur le cloud - intercepte cette requête DNS ou cette requête HTTP et la redirige. Au lieu d'atteindre Internet, l'appareil reçoit une réponse de redirection pointant vers une URL spécifique. C'est sur cette URL que réside la splash page. Désormais, le mécanisme de redirection lui-même utilise l'une des deux techniques principales. La première est le détournement de DNS - le Captive Portal intercepte les requêtes DNS et renvoie l'adresse IP du serveur du portail au lieu de la destination réelle. La seconde est la redirection HTTP - le portail intercepte la requête HTTP au niveau de la passerelle et émet une réponse de redirection 302. Pour le trafic HTTPS, cela est plus complexe, car vous ne pouvez pas intercepter une session chiffrée sans déclencher un avertissement de certificat. C'est pourquoi la plupart des implémentations de Captive Portal s'appuient sur l'assistant de réseau captif intégré au système d'exploitation - la fenêtre contextuelle qui s'affiche sur votre téléphone lorsque vous vous connectez à un nouveau réseau - qui utilise un point de terminaison HTTP connu pour détecter les portails captifs avant de tenter des connexions HTTPS. Au niveau de la couche réseau, le Captive Portal applique le contrôle d'accès à l'aide de règles de pare-feu. Les appareils non authentifiés sont placés dans un VLAN ou un sous-réseau restreint où tout le trafic, à l'exception du DNS et du HTTP vers le serveur du portail, est bloqué. Une fois l'authentification confirmée - qu'il s'agisse d'un simple clic, d'un login social, d'une saisie d'e-mail ou d'un échange complet d'identifiants 802.1X - le contrôleur de portail met à jour les règles de pare-feu pour l'adresse MAC de cet appareil, le déplaçant de la zone restreinte vers la zone autorisée avec un accès complet à Internet. Ceci est important : le Captive Portal est invisible pour l'invité. Ils ne le voient jamais directement. Ce qu'ils voient, c'est la page d'accueil. La page d'accueil correspond à la couche applicative - c'est l'HTML, le CSS et le JavaScript qui s'affichent dans le navigateur de l'invité ou dans la fenêtre contextuelle de l'assistant de réseau captif. C'est l'interface visuelle : votre marque, votre logo, votre message d'accueil, vos conditions générales, vos boutons de connexion sociale, vos cases à cocher d'inscription marketing. C'est ce qui transforme un simple événement d'authentification réseau en une expérience invité personnalisée aux couleurs de votre marque. Voyez les choses ainsi. Le Captive Portal est le videur à l'entrée - il décide qui entre et applique les règles. La page d'accueil est le bureau de réception - c'est le visage de votre établissement, elle recueille les informations et permet à l'invité de se sentir le bienvenu. Vous avez besoin des deux, et ils doivent fonctionner ensemble de manière transparente. Pourquoi cette distinction est-elle importante sur le plan commercial ? Parce que lorsque vous évaluez une solution de WiFi invité, vous devez poser des questions différentes pour chaque composant. Pour le Captive Portal, vous vous demandez : Quels modes d'authentification prend-il en charge ? Peut-il gérer le 802.1X pour les appareils d'entreprise parallèlement à la connexion sociale pour les invités ? Prend-il en charge le contournement d'adresse MAC pour les appareils qui ne peuvent pas afficher un navigateur ? Comment gère-t-il les expirations de session et la ré-authentification ? Est-il conforme à vos obligations de protection des données en vertu du GDPR ? S'intègre-t-il à votre infrastructure RADIUS ? Peut-il segmenter le trafic par type d'utilisateur - en séparant le trafic invité du trafic du personnel au niveau de la couche réseau ? Pour la page d'accueil, vous vous demandez : À quel point est-elle personnalisable ? Votre équipe marketing peut-elle la modifier sans toucher à la configuration réseau ? Prend-elle en charge l'A/B testing ? Peut-elle proposer des contenus différents selon les segments d'utilisateurs - les membres du programme de fidélité par rapport aux nouveaux visiteurs, par exemple ? Gère-t-elle les arrière-plans vidéo, les bannières promotionnelles ou les pages de redirection après connexion ? Quel est son comportement sur mobile ? Est-elle accessible ? Ce sont des critères d'achat fondamentalement différents, et les confondre conduit à de mauvaises décisions. Nous avons vu des entreprises investir massivement dans un superbe design de page d'accueil pour découvrir ensuite que le Captive Portal sous-jacent ne prenait pas en charge les méthodes d'authentification requises par leur politique de sécurité informatique. Nous avons également vu l'inverse - des déploiements de Captive Portal techniquement robustes mais avec des pages d'accueil si mal conçues que les taux d'adoption par les visiteurs plafonnaient à 30 %. Parlons des normes qui sous-tendent tout cela. Le mécanisme de Captive Portal ne dispose pas d'une norme de gouvernance unique, mais il fonctionne dans le cadre de plusieurs standards majeurs. La norme 802.1X est le standard de contrôle d'accès réseau basé sur les ports qui régit la manière dont les appareils s'authentifient auprès d'un réseau à l'aide d'identifiants, de certificats ou de jetons. C'est le fondement de la sécurité WiFi d'entreprise, et elle est de plus en plus pertinente, même pour le WiFi visiteur, lorsque vous souhaitez offrir un accès transparent et basé sur des identifiants aux visiteurs réguliers. Le WPA3, dernier protocole de sécurité WiFi, introduit l'Opportunistic Wireless Encryption, qui chiffre le trafic même sur les réseaux ouverts - un élément important pour les déploiements de Captive Portal car il modifie le fonctionnement de la liaison de connexion initiale. Du point de vue de la conformité, le GDPR a des implications majeures sur la conception de la page d'accueil. Si votre page d'accueil collecte des données personnelles - une adresse e-mail, un nom, un identifiant de réseau social - vous devez obtenir un consentement explicite et éclairé, afficher une politique de confidentialité claire et disposer d'une base légale pour le traitement. C'est sur la page d'accueil que ce consentement est recueilli, mais c'est le Captive Portal qui applique la liaison entre le consentement et l'accès. Si un visiteur refuse de s'abonner à vos communications marketing, le Captive Portal doit tout de même lui accorder l'accès à Internet - le consentement au marketing ne peut pas être une condition d'accès au réseau en vertu du GDPR. La norme PCI-DSS est pertinente si votre réseau WiFi visiteur se situe dans le périmètre des environnements de données de cartes de paiement - généralement dans le commerce de détail ou l'hôtellerie. La segmentation réseau appliquée par le Captive Portal est un contrôle clé ici, garantissant que le trafic des visiteurs est isolé des systèmes de paiement. - SEGMENT 3 : RECOMMANDATIONS DE MISE EN ŒUVRE ET PIÈGES À ÉVITER (environ 2 minutes) Laissez-moi vous présenter deux scénarios réels qui illustrent comment tout cela se traduit en pratique. Tout d'abord, un groupe hôtelier de 200 chambres. Ils ont déployé une solution de WiFi pour les clients où la splash page était magnifiquement personnalisée à leur marque - leur logo, un message de bienvenue, une offre promotionnelle pour le spa. Mais le Captive Portal sous-jacent était une implémentation open-source basique qui utilisait le détournement de DNS sans aucune gestion de session. Résultat : les clients qui revenaient à l'hôtel étaient invités à se reconnecter à chaque visite, même au cours du même séjour. La splash page était superbe, mais le Captive Portal n'avait pas de persistance d'adresse MAC, pas de configuration de délai d'expiration de session, et aucune intégration avec le système de gestion de l'établissement. La correction a nécessité le remplacement complet du contrôleur de Captive Portal - la splash page était correcte. Ensuite, une chaîne nationale de vente au détail. Ils ont déployé un Captive Portal de classe entreprise avec un support complet 802.1X, une intégration RADIUS et une segmentation sophistiquée du trafic. Mais leur splash page était un modèle par défaut - blanc uni, sans branding, avec un message générique "Se connecter au WiFi". Le taux d'adoption par les clients était de 34 %. Après avoir investi dans une splash page de marque correctement conçue, avec une option de connexion sociale en un clic, l'adoption est passée à 71 % en trois mois. Le Captive Portal n'avait pas changé d'un iota. La leçon de ces deux scénarios : ces composants distincts nécessitent un investissement et une expertise distincts. Ne laissez pas votre équipe réseau s'occuper de la conception de la splash page, et ne laissez pas votre équipe marketing prendre des décisions concernant l'architecture du Captive Portal. Les pièges courants à éviter : premièrement, supposer qu'une splash page est un Captive Portal. Ce n'est pas le cas. Une splash page sans Captive Portal n'est qu'une page web que personne n'est obligé de visiter. Deuxièmement, déployer un Captive Portal sans support HTTPS pour la splash page. Toutes les données collectées sur une splash page non chiffrée - adresses e-mail, identifiants de connexion - sont transmises en texte clair. C'est un risque pour la sécurité et vis-à-vis du GDPR. Troisièmement, ignorer l'expérience mobile. Plus de 80 % des connexions WiFi des clients proviennent d'appareils mobiles. Si votre splash page n'est pas optimisée pour le mobile, vous créez des frictions au moment précis où vous devriez créer une impression de marque positive. - SEGMENT 4 : QUESTIONS-RÉPONSES RAPIDES (environ 1 minute) Passons en revue quelques questions que nous entendons régulièrement. Puis-je avoir une splash page sans Captive Portal ? Techniquement oui - vous pouvez héberger une page web et y diriger les gens - mais sans le Captive Portal pour imposer la redirection, les clients n'ont aucune raison de s'y rendre. Vous n'auriez aucune capture de données, aucune gestion du consentement et aucun contrôle d'accès au réseau. Puis-je avoir un Captive Portal sans splash page ? Oui, et c'est courant dans les environnements d'entreprise où le 802.1X gère l'authentification de manière transparente. Mais pour les déploiements destinés aux clients, vous souhaitez presque toujours une splash page pour gérer l'expérience utilisateur et la capture de données. Le WPA3 bloque-t-il les portails captifs ? Pas s'il est implémenté correctement. Le WPA3 avec l'Opportunistic Wireless Encryption est compatible avec les déploiements de portails captifs, mais il nécessite que le portail utilise HTTPS et que le réseau diffuse correctement l'URL du portail. Certains appareils clients plus anciens rencontrent des problèmes de compatibilité, c'est pourquoi de nombreux établissements configurent un double SSID. La connexion via les réseaux sociaux sur la splash page est-elle sécurisée ? Cela dépend de l'implémentation. La connexion sociale basée sur OAuth 2.0 - via Google, Facebook ou Apple - est sécurisée lorsqu'elle est correctement mise en œuvre. La splash page gère le flux OAuth, et le portail captif reçoit un jeton confirmant l'authentification. Le risque principal réside dans la manière dont ce jeton est validé et dont la session est gérée. - SEGMENT 5 : RÉSUMÉ ET PROCHAINES ÉTAPES (environ 1 minute) Terminons par les points clés à retenir. Premièrement : un portail captif et une splash page ne sont pas la même chose. Le portail captif est le mécanisme de contrôle du réseau - il intercepte le trafic et applique les règles d'accès. La splash page est l'interface visuelle - c'est ce que l'invité voit et avec quoi il interagit. Deuxièmement : ils fonctionnent ensemble. Le portail captif redirige l'invité vers la splash page. La splash page recueille l'authentification ou le consentement. Le portail captif accorde ensuite l'accès en fonction de ce résultat. Troisièmement : évaluez-les séparément. Posez des questions différentes, appliquez des expertises différentes et budgétisez les deux de manière indépendante. Quatrièmement : la conformité se situe à leur intersection. Le consentement GDPR est recueilli sur la splash page mais appliqué par le portail captif. Assurez-vous de bien configurer les deux. Cinquièmement : Purple fournit les deux. Si vous recherchez une plateforme qui gère un contrôle de portail captif de classe entreprise ainsi qu'une conception de splash page riche et personnalisable - avec des analyses complètes, des outils de conformité GDPR et des intégrations avec votre infrastructure existante - c'est exactement pour cela que Purple a été conçu. Pour vos prochaines étapes, je vous recommande de consulter les guides d'implémentation de Purple sur l'authentification 802.1X et l'analyse du WiFi invité. Les liens se trouvent dans les notes de l'émission. Et si vous êtes en plein processus d'achat, contactez l'équipe de Purple pour une évaluation technique - cela vaut la peine de concevoir la bonne architecture avant de vous lancer dans un déploiement. Merci pour votre écoute. À la prochaine. - FIN DU SCRIPT