Captive Portal vs Splash Page

PORTAL CAPTIF VS SPLASH PAGE - UN BRIEFING TECHNIQUE PURPLE Script de Podcast - Environ 10 Minutes Voix Anglaise UK --- SEGMENT 1 : INTRODUCTION ET CONTEXTE (environ 1 minute) Bienvenue dans la série des briefings techniques Purple. Je suis votre hôte, et aujourd'hui, nous allons clarifier l'une des sources de confusion les plus persistantes dans l'acquisition et le déploiement de solutions WiFi invités : la différence entre un captive portal et une splash page. Si vous avez déjà assisté à une réunion de fournisseurs et entendu ces deux termes utilisés de manière interchangeable, vous n'êtes pas seul. Cela arrive constamment - dans les documents d'appels 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 des conséquences, car en confondant les deux, vous risquez soit de surévaluer le mauvais composant, soit de sous-investir dans le bon, ou pire - de déployer une solution WiFi invités esthétique mais dépourvue de contrôle réseau adéquat, ou encore une solution techniquement solide mais qui fait fuir les invités avec un écran de connexion lourd et sans image de marque. Nous allons donc clarifier cela aujourd'hui. À la fin de ce briefing, vous disposerez d'un modèle mental clair du rôle de chaque composant, de leur interaction et des éléments à évaluer lors du choix de solutions pour votre établissement - qu'il s'agisse d'un hôtel, d'un point de vente, d'un stade ou d'un bâtiment du secteur public. --- SEGMENT 2 : ANALYSE TECHNIQUE APPROFONDIE (environ 5 minutes) Commençons par le captive portal, car c'est la fondation sur laquelle repose tout le reste. Un captive portal 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 retenir dans une sorte de salle d'attente numérique jusqu'à ce que cet appareil soit authentifié. Lorsqu'un invité se connecte au SSID de votre WiFi, son appareil obtient une adresse IP via DHCP - cette partie fonctionne normalement. Mais avant que le trafic internet réel ne soit autorisé à passer, le captive portal l'intercepte. Voici la séquence technique. L'appareil de l'invité envoie une requête HTTP ou HTTPS - il peut s'agir d'une tentative de chargement de site web ou 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 captive portal - situé sur votre contrôleur sans fil, votre routeur ou une plateforme cloud - intercepte cette requête DNS ou HTTP et la redirige. Au lieu d'accéder à internet, l'appareil reçoit une réponse de redirection pointant vers une URL spécifique. Cette URL correspond à l'endroit où se trouve 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 DNS - le Captive Portal intercepte les requêtes DNS et renvoie l'adresse IP du serveur de portail à la place 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 une alerte de certificat. C'est pourquoi la plupart des implémentations de Captive Portal s'appuient sur l'assistant 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 est bloqué, à l'exception du DNS et du HTTP vers le serveur de portail. Une fois l'authentification confirmée - qu'il s'agisse d'un simple clic, d'un login social, d'une capture d'e-mail ou d'un échange complet de 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é. Il ne le voit jamais directement. Ce qu'il voit, 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 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 à la porte - 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. Maintenant, pourquoi cette distinction est-elle importante sur le plan commercial ? Parce que lorsque vous évaluez une solution 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 de l'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 de 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 splash page, vous vous demandez : à quel point est-elle personnalisable ? Votre équipe marketing peut-elle la modifier sans toucher à la configuration du 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 ? Prend-elle en charge les arrière-plans vidéo, les bannières promotionnelles ou les pages de redirection après connexion ? Comment se comporte-t-elle 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 magnifique design de splash page 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 avec des splash pages 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 n'a pas de norme de gouvernance unique, mais il fonctionne dans le cadre de plusieurs normes importantes. La norme 802.1X est la norme de contrôle d'accès réseau basée sur les ports qui régit la manière dont les appareils s'authentifient sur 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 dans le cadre du WiFi invité, lorsque vous souhaitez offrir un accès transparent, basé sur des identifiants, aux visiteurs de retour. Le WPA3, le dernier protocole de sécurité WiFi, introduit le chiffrement sans fil opportuniste (OWE), qui chiffre le trafic même sur les réseaux ouverts - ce qui est pertinent pour les déploiements de Captive Portal car cela modifie le fonctionnement de la liaison de connexion initiale. Du point de vue de la conformité, le GDPR a des implications importantes sur la conception des splash pages. Si votre splash page collecte des données personnelles - une adresse e-mail, un nom, une connexion sociale - vous devez obtenir un consentement explicite et éclairé, fournir une notice de confidentialité claire et disposer d'une base légale pour le traitement. La splash page est l'endroit où ce consentement est capturé, mais le Captive Portal est ce qui applique le lien 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 un 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 invité entre dans le champ d'application des environnements de données de cartes de paiement - généralement dans le commerce de détail ou l'hôtellerie. La segmentation du 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 cela se passe en pratique. D'abord, un groupe hôtelier de 200 chambres. Ils ont déployé une solution de WiFi invité où la page de splash était magnifiquement personnalisée à leur image : 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 DNS sans aucune gestion de session. Résultat : les clients qui revenaient à l'hôtel devaient s'identifier à nouveau lors de chaque visite, même au cours du même séjour. La page de splash était superbe, mais le captive portal n'avait pas de persistance d'adresse MAC, pas de configuration 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 du captive portal - la page de splash, elle, fonctionnait très bien. Ensuite, une chaîne nationale de vente au détail. Ils ont déployé un captive portal de qualité entreprise avec un support complet du 802.1X, une intégration RADIUS, et une segmentation sophistiquée du trafic. Mais leur page de splash était un modèle par défaut : fond blanc uni, aucun branding, un message générique "Se connecter au WiFi". Le taux d'adoption par les invités était de 34 %. Après avoir investi dans une page de splash de conception professionnelle, à l'image de la marque et 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é du tout. La leçon de ces deux scénarios : ces composants distincts nécessitent des investissements et une expertise différents. Ne laissez pas votre équipe réseau s'occuper de la conception de la page de splash, 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 page de splash est un captive portal. Ce n'est pas le cas. Une page de splash sans captive portal est juste une page web que personne n'est obligé de visiter. Deuxièmement, déployer un captive portal sans support HTTPS pour la page de splash. Toutes les données collectées sur une page de splash non chiffrée - adresses e-mail, identifiants de connexion - sont transmises en texte clair. C'est un risque pour la sécurité et la conformité GDPR. Troisièmement, ignorer l'expérience mobile. Plus de 80 % des connexions WiFi des invités proviennent d'appareils mobiles. Si votre page de splash n'est pas optimisée pour le mobile, vous créez des frictions au moment précis où vous devriez faire 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 page de splash sans captive portal ? Techniquement oui - vous pouvez héberger une page web et y diriger les utilisateurs - mais sans le captive portal pour imposer la redirection, les invités n'ont aucune raison de s'y rendre. Vous n'auriez pas de capture de données, pas de gestion du consentement, et pas de contrôle d'accès réseau. Puis-je avoir un captive portal sans page de splash ? 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 invités, vous souhaitez presque toujours une page de splash pour gérer l'expérience utilisateur et la capture de données. Est-ce que le WPA3 perturbe les portails captifs ? Pas s'il est implémenté correctement. Le WPA3 avec 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 présentent des problèmes de compatibilité, c'est pourquoi de nombreux sites 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 via 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 principal risque réside dans la validation de ce jeton et dans la gestion de la session. --- 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 à l'intersection des deux. Le consentement GDPR est capturé 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 tout en offrant un design 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 ce pour quoi 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