Conformité IWF pour les réseaux WiFi publics au Royaume-Uni

Animateur : Bonjour et bienvenue dans ce Briefing IT de Purple pour les entreprises. Je suis votre hôte, et aujourd'hui nous abordons un sujet que chaque directeur informatique, CTO et architecte réseau au Royaume-Uni doit impérativement maîtriser : la conformité IWF pour les réseaux WiFi publics. Si vous gérez l'infrastructure de chaînes de magasins, d'établissements hôteliers, de stades ou de bâtiments du secteur public, proposer un WiFi invité ne se résume plus à une simple question de bande passante et de couverture. C'est une question de limitation des risques. Fournir un accès direct à Internet sans un filtrage robuste et certifié expose votre organisation à de graves préjudices juridiques et de réputation. Aujourd'hui, nous allons droit au but. Pas de théorie académique — uniquement des conseils concrets et neutres vis-à-vis des fournisseurs pour concevoir un réseau conforme et performant. Entrons directement dans le vif du sujet. L'Internet Watch Foundation, ou IWF, tient à jour la liste définitive du Royaume-Uni des URL contenant du matériel d'abus sexuel sur mineur, ou CSAM. Pour tout établissement proposant un WiFi public, l'intégration de cette liste de blocage est la base absolue d'une exploitation responsable. Mais voici le point critique : vous ne pouvez pas vous contenter de télécharger une liste statique une fois par mois et de l'importer dans votre pare-feu. La liste de l'IWF est extrêmement dynamique. Des URL sont ajoutées et supprimées en permanence. Votre moteur de filtrage web doit consommer ce flux en temps réel ou quasi-réel. Si vous utilisez un fournisseur qui n'est pas un membre officiel de l'IWF consommant activement leur flux dynamique, vous n'êtes pas conforme. Point final. Alors, comment concevoir concrètement cette architecture à la périphérie du réseau ? Plongeons dans les détails techniques. La mise en œuvre de la conformité IWF nécessite une approche multicouche. Vous ne pouvez pas vous reposer sur un seul point de passage unique. La première couche est le filtrage DNS. C'est votre première ligne de défense. Lorsqu'un appareil invité demande un domaine CSAM connu, votre DNS sécurisé l'intercepte et le redirige vers une page de blocage. C'est extrêmement efficace et cela n'introduit pratiquement aucune latence. Cependant, le filtrage DNS seul présente des lacunes fondamentales pour la conformité moderne. Pourquoi ? Parce que le DNS fonctionne au niveau du domaine. La liste de l'IWF spécifie souvent des URL exactes — des pages spécifiques situées en profondeur dans un site. Si vous utilisez uniquement le DNS, vous êtes confronté à deux problèmes majeurs. Soit vous sous-bloquez, en autorisant l'accès via une IP directe, soit vous sur-bloquez, en bloquant complètement un domaine légitime entier à cause d'une seule URL problématique. Le sur-blocage entraîne la frustration des utilisateurs et une augmentation des tickets de support. Cela nous amène à la couche deux : l'inspection approfondie des paquets (DPI) HTTP et HTTPS, et plus particulièrement l'inspection SNI. Comme la grande majorité du trafic web est chiffrée via HTTPS, vous ne pouvez pas facilement voir le chemin d'accès complet de l'URL sans déchiffrer le trafic. Certains ingénieurs réseau pourraient suggérer un déchiffrement SSL complet — l'inspection SSL. Laissez-moi être clair : ne faites pas cela sur un réseau invité public. Cela nécessite l'installation de certificats racines personnalisés sur les appareils des invités, ce qui est impossible à imposer, rompt la confiance du navigateur et constitue une violation majeure de la vie privée. La norme de l'industrie est l'inspection SNI (Server Name Indication). L'inspection SNI permet à votre pare-feu d'analyser la poignée de main TLS initiale et d'identifier le nom d'hôte demandé par le client avant l'établissement du tunnel chiffré. En combinant un filtrage DNS robuste avec une inspection SNI avancée et une catégorisation IP dynamique, vous pouvez appliquer la liste de l'IWF avec précision sans rompre le chiffrement de bout en bout. Abordons maintenant les recommandations de mise en œuvre et les pièges à éviter. Premièrement, le problème du contournement. Votre filtrage est inutile si les utilisateurs peuvent simplement modifier leurs paramètres DNS pour utiliser le 8.8.8.8 et contourner vos contrôles. Vous devez configurer vos routeurs de périphérie ou vos pare-feux pour bloquer le trafic sortant sur les ports UDP et TCP 53, ainsi que sur le port 853 pour le DNS sur TLS. Forcez toutes les requêtes DNS à passer par votre infrastructure conforme. De plus, gardez un œil sur le DNS sur HTTPS, ou DoH. Les navigateurs modernes utilisent de plus en plus le DoH, qui encapsule les requêtes DNS dans le trafic HTTPS standard. Vous devez vous assurer que votre pare-feu est configuré pour bloquer les points de terminaison des résolveurs DoH connus afin de forcer le navigateur à se rabattre sur votre DNS local sécurisé. Deuxièmement, le Captive Portal. Le captive portal n'est pas seulement un espace pour afficher votre logo ; c'est une barrière de contrôle juridique. Votre politique d'utilisation acceptable (AUP) doit stipuler explicitement que le filtrage de contenu est actif et que l'accès aux contenus illégaux est surveillé et bloqué. Les utilisateurs doivent accepter activement cette AUP avant d'obtenir l'accès. Cela constitue votre couverture juridique. Troisièmement, la journalisation. Vous devez configurer vos systèmes pour conserver les journaux des tentatives d'accès bloquées, associés à l'adresse MAC de l'appareil et aux données de session, pendant une durée minimale de 12 mois. Cela est conforme au GDPR et facilite les enquêtes des forces de l'ordre en cas d'incident. Et enfin, la segmentation du réseau. Ne mélangez jamais le trafic des invités avec le trafic opérationnel. Votre VLAN invité doit être strictement isolé de vos systèmes de point de vente ou de votre infrastructure d'entreprise. Appliquez le filtrage web strict au réseau invité, mais utilisez des listes d'autorisation strictes pour votre réseau de point de vente afin de garantir une latence nulle pour les transactions. Passons maintenant à une séance de questions-réponses rapide basée sur les scénarios courants que nous rencontrons sur le terrain. Question 1 : « Pouvons-nous utiliser les URL réelles de l'IWF pour tester la configuration de notre nouveau pare-feu ? » Réponse : Absolument pas. L'accès à ces URL est illégal. L'IWF fournit des URL de test spécifiques et sécurisées, conçues uniquement pour valider le bon fonctionnement de votre moteur de filtrage. Utilisez celles-ci. Question 2 : « Notre équipe marketing souhaite un réseau WiFi ouvert "sans friction" et sans captive portal. Est-ce conforme ? » Réponse : Non. Sans captive portal, vous ne pouvez pas imposer la politique d'utilisation acceptable, ce qui signifie que vous n'avez aucun accord juridique avec l'utilisateur. Cela expose l'établissement à une responsabilité juridique importante. Question 3 : « Que faisons-nous pour les invités qui utilisent des VPN ? » Réponse : Dans des environnements tels que les hôtels, les voyageurs d'affaires ont besoin de VPN. Vous ne pouvez pas tous les bloquer. Cependant, vous devez surveiller les tunnels chiffrés excessifs et continus qui contournent les ports standard, ce qui pourrait indiquer un abus plutôt qu'un accès d'entreprise légitime. Résumons les prochaines étapes. La conformité n'est pas un centre de coûts ; c'est la protection de votre marque. Le préjudice réputationnel lié à l'association de votre établissement à des contenus illégaux l'emporte largement sur les coûts de déploiement. Pour réussir cette mise en œuvre : 1. Vérifiez que votre fournisseur de filtrage web est un membre actif de l'IWF. 2. Implémentez un filtrage double couche en utilisant à la fois un DNS sécurisé et l'inspection SNI. 3. Verrouillez les ports DNS sortants pour empêcher les contournements. 4. Imposez une charte d'utilisation informatique (AUP) via un Captive Portal. 5. Conservez vos journaux de connexion pendant 12 mois. En suivant ces étapes, vous construirez un réseau non seulement performant, mais fondamentalement sécurisé et conforme. Merci d'avoir participé à ce briefing informatique Purple Enterprise. Pour obtenir des schémas d'architecture plus détaillés et des listes de contrôle de mise en œuvre, reportez-vous au guide technique complet. Restez en sécurité, et à la prochaine fois.