WiFi invité ISO 27001 : un guide de conformité

ISO 27001 Guest WiFi: A Compliance Primer Purple Technical Briefing Podcast — Episode Script Approximate runtime: 10 minutes | Voice: UK English, senior consultant tone --- SEGMENT 1: INTRODUCTION AND CONTEXT (approx. 1 minute) Bienvenue au briefing technique de Purple. Je suis votre hôte pour l'épisode d'aujourd'hui, et nous plongeons dans un sujet qui se situe à l'intersection des opérations réseau et de la gouvernance de la sécurité de l'information : le WiFi invité et la conformité ISO 27001. Si vous êtes un responsable informatique, un architecte réseau ou un auditeur principal ISO 27001 dans un groupe hôtelier, une chaîne de magasins, un stade ou une organisation du secteur public, cet épisode est conçu pour vous. Nous n'allons pas reprendre l'ISO 27001 depuis le début — vous connaissez la norme. Ce que nous allons faire, c'est vous donner une cartographie précise et pratique de la manière dont votre déploiement de WiFi invité s'intègre dans votre système de gestion de la sécurité de l'information, quels contrôles s'appliquent, ce que votre évaluation des risques doit documenter et, surtout, quelles preuves vous devez produire lorsque l'auditeur se présentera. Le WiFi invité est l'un de ces domaines que les organisations sous-estiment systématiquement du point de vue de la conformité. On a l'impression qu'il s'agit d'un service de base — brancher quelques points d'accès, donner un mot de passe, et c'est tout. Mais du point de vue du SMSI, il s'agit d'un actif informationnel actif qui touche à la limite de votre réseau, à vos relations avec les fournisseurs, à vos obligations en matière de protection des données et à votre exposition juridique. Analysons cela en détail. --- SEGMENT 2: TECHNICAL DEEP-DIVE (approx. 5 minutes) Commençons par la cartographie des contrôles. La norme ISO 27001:2022 a restructuré ses contrôles de l'Annexe A, et plusieurs d'entre eux s'appliquent directement au WiFi invité. Le groupe le plus critique se trouve dans la section des contrôles technologiques — à savoir la clause 8 de l'Annexe A. Le Contrôle A.8.22 — Ségrégation des réseaux — est votre exigence fondamentale. Ce contrôle exige que les groupes de services d'information, d'utilisateurs et de systèmes soient séparés sur les réseaux. Pour le WiFi invité, cela se traduit directement par une isolation VLAN. Votre réseau invité doit être séparé logiquement et, le cas échéant, physiquement de votre réseau d'entreprise, de votre environnement de traitement des paiements et de tout segment d'IoT ou de technologie opérationnelle. Si un auditeur constate que le trafic invité peut atteindre des partages de fichiers internes ou des interfaces de gestion, il s'agit d'une non-conformité claire par rapport au contrôle A.8.22. Le Contrôle A.8.20 — Sécurité des réseaux — exige que les réseaux soient gérés et contrôlés pour protéger les informations dans les systèmes et les applications. Pour le WiFi invité, cela signifie des règles de pare-feu documentées, des listes de contrôle d'accès et une politique de sécurité réseau qui traite explicitement du segment invité. Vous devez être en mesure de montrer à l'auditeur un schéma réseau actuel avec le VLAN invité clairement identifié, ainsi que l'ensemble de règles de pare-feu qui régit ce que ce segment peut et ne peut pas atteindre. Le Contrôle A.8.21 — Sécurité des services réseau — traite des fournisseurs tiers de services réseau. La plupart des organisations qui exploitent un WiFi invité utilisent un fournisseur de services gérés, une plateforme de Captive Portal basée sur le cloud ou une solution fournie par un FAI. Chacune de ces relations est une relation fournisseur qui doit être gouvernée. Vous avez besoin d'accords de niveau de service qui incluent des exigences de sécurité, et vous devez prouver l'existence d'évaluations périodiques des fournisseurs. C'est là que les attestations SOC 2 Type II des fournisseurs deviennent véritablement utiles — nous y reviendrons. Le Contrôle A.8.15 — Journalisation — exige que des journaux d'événements soient produits, stockés, protégés et analysés. Pour le WiFi invité, cela signifie enregistrer les événements de connexion, les tentatives d'authentification et les données de session. Il existe ici une tension avec le GDPR et les principes de minimisation des données, en particulier au Royaume-Uni et dans l'UE. Vous devez enregistrer suffisamment de données pour satisfaire à vos obligations de surveillance de la sécurité, mais pas au point de conserver des données personnelles au-delà de ce qui est nécessaire. Votre politique de journalisation doit explicitement traiter du périmètre du WiFi invité, définir les périodes de conservation et documenter la base juridique de toutes les données personnelles capturées. Le Contrôle A.8.23 — Filtrage web — exige que l'accès aux sites web externes soit géré pour protéger les systèmes contre les infections par des logiciels malveillants et pour empêcher l'accès à des ressources web non autorisées. Pour le WiFi invité, cela signifie généralement le déploiement d'un filtrage basé sur le DNS ou d'un proxy web cloud qui bloque les domaines malveillants connus, les infrastructures de commande et de contrôle et, selon votre secteur, les catégories de contenus inappropriés. Un exploitant d'hôtel s'adressant à un public familial a des obligations de filtrage différentes de celles d'un centre de conférences accueillant des délégués d'entreprises, mais tous deux ont besoin d'une politique documentée et de preuves que le filtrage est actif et révisé. Pour ce qui est des contrôles organisationnels — clause 5 de l'Annexe A — deux contrôles sont particulièrement pertinents. Le Contrôle A.5.14 — Transfert d'informations — régit les règles, procédures et contrôles pour le transfert d'informations. Si des invités utilisent votre réseau pour transférer des fichiers, accéder à des services cloud ou mener des affaires, vous devez disposer d'une politique d'utilisation acceptable qui leur est présentée lors de l'authentification — généralement via le Captive Portal — et acceptée avant que l'accès ne soit accordé. Cet événement d'acceptation doit être enregistré comme preuve. Le Contrôle A.5.31 — Exigences légales, réglementaires, statutaires et contractuelles — exige que vous identifiiez et documentiez toutes les obligations légales et réglementaires pertinentes. Pour le WiFi invité, cela inclut le GDPR ou le UK GDPR si vous capturez des données personnelles lors de l'authentification, l'Investigatory Powers Act si vous êtes au Royaume-Uni et que vous pouvez être tenu de conserver des données de communication, et des réglementations sectorielles telles que PCI DSS si votre réseau invité entre dans le périmètre des données de titulaires de cartes. Parlons maintenant de l'évaluation des risques. La norme ISO 27001 est une norme basée sur le risque, ce qui signifie que vous ne pouvez pas simplement mettre en œuvre des contrôles et considérer que c'est réglé. Vous devez documenter une évaluation formelle des risques pour l'actif WiFi invité. Cette évaluation doit identifier les menaces — accès non autorisé aux systèmes internes, propagation de logiciels malveillants à partir des appareils des invités, interception de données sur le support sans fil, déni de service et atteinte à la réputation en cas d'utilisation abusive de votre réseau. Pour chaque menace, vous évaluez la probabilité et l'impact, déterminez votre traitement du risque — qu'il s'agisse d'atténuer, d'accepter, de transférer ou d'éviter — et documentez le risque résiduel. La déclaration d'applicabilité doit faire référence à l'évaluation des risques du WiFi invité comme justification de l'inclusion ou de l'exclusion de contrôles spécifiques de l'Annexe A. Abordons le WPA3 et les normes d'authentification. Les générations de matériel WiFi IEEE 802.11ax et 802.11be prennent en charge le WPA3, qui fournit l'authentification simultanée d'égaux — SAE — remplaçant l'ancienne poignée de main par clé pré-partagée. Pour un réseau invité où vous utilisez un mot de passe partagé, le WPA3-Personal avec SAE offre une confidentialité persistante, ce qui signifie que même si le mot de passe est compromis, le trafic des sessions historiques ne peut pas être déchiffré. Pour les déploiements d'entreprise où vous souhaitez une authentification par utilisateur, le WPA3-Enterprise avec IEEE 802.1X et EAP-TLS fournit une authentification basée sur des certificats qui s'associe directement aux contrôles de gestion des identités ISO 27001. Le choix entre ces deux modèles dépend de votre population d'utilisateurs et de votre tolérance à la complexité opérationnelle. Parlons des attestations SOC 2 des fournisseurs. Si vous utilisez une plateforme de WiFi invité gérée dans le cloud — et c'est le cas de la plupart des organisations — le rapport SOC 2 Type II de ce fournisseur est un élément essentiel de vos preuves d'assurance fournisseur. Un rapport SOC 2 Type II couvre les critères de services de confiance : sécurité, disponibilité, intégrité du traitement, confidentialité et protection de la vie privée, sur une période d'audit généralement de six à douze mois. Lorsque vous constituez votre dossier d'assurance fournisseur ISO 27001, le rapport SOC 2 Type II du fournisseur, combiné à un questionnaire de sécurité fournisseur complété et à un accord de traitement des données, vous fournit un ensemble de preuves solides pour le contrôle A.8.21. Purple, par exemple, présente un alignement SOC 2 qui soutient directement cette exigence du SMSI en aval — ce qui signifie que vous pouvez faire référence à leur attestation dans vos propres preuves d'audit plutôt que de mener une évaluation de sécurité complète et sur mesure de la plateforme. --- SEGMENT 3: IMPLEMENTATION RECOMMENDATIONS AND PITFALLS (approx. 2 minutes) Laissez-moi vous présenter les quatre décisions de mise en œuvre que la plupart des organisations gèrent mal. Premièrement : la dérive du périmètre dans l'évaluation des risques. Les organisations définissent le périmètre du WiFi invité soit de manière trop étroite — en le considérant hors périmètre car il est réservé aux visiteurs — soit de manière trop large, en tentant d'appliquer tous les contrôles possibles sans tenir compte de leur pertinence. La bonne approche consiste à le définir comme un actif informationnel inclus dans le périmètre du SMSI, à mener une évaluation des risques proportionnée et à documenter la logique de sélection de vos contrôles dans la déclaration d'applicabilité. Deuxièmement : une ségrégation réseau inadéquate. J'ai vu des VLAN invités techniquement distincts mais partageant une zone de pare-feu avec des systèmes internes, ou des cas où l'interface de gestion du contrôleur sans fil était accessible depuis le segment invité. La ségrégation doit être vérifiée par un test d'intrusion ou au minimum par un examen des accès réseau, et cette vérification doit être documentée comme preuve d'audit. Troisièmement : ignorer le Captive Portal en tant que mécanisme de contrôle d'accès. Le Captive Portal n'est pas seulement un exercice d'image de marque. C'est le point de passage où vous présentez votre politique d'utilisation acceptable, obtenez le consentement pour le traitement des données et créez le journal d'authentification qui sert de preuve pour plusieurs contrôles ISO 27001. Si votre Captive Portal n'enregistre pas les événements d'acceptation avec des horodatages et des identifiants de session, vous avez une lacune qu'un auditeur finira par trouver. Quatrièmement : traiter l'assurance des fournisseurs comme un exercice ponctuel. Les rapports SOC 2 expirent. Les contrats des FAI changent. Les conditions de service des plateformes cloud sont mises à jour. Votre programme d'assurance des fournisseurs doit inclure un examen annuel des attestations de sécurité des fournisseurs, et cet examen doit être documenté. Configurez un rappel dans votre calendrier pour la fin de la période de validité du rapport SOC 2 de chaque fournisseur et demandez le rapport mis à jour de manière proactive. Sur la question des délais d'expiration des sessions : la norme ISO 27001 ne prescrit pas de valeurs de délai spécifiques, mais votre évaluation des risques doit documenter la logique de la valeur que vous choisissez. Un délai d'expiration de session de huit heures est courant dans l'hôtellerie, mais un centre de conférences accueillant un événement d'une journée peut définir un délai plus court pour s'assurer que les identifiants ne sont pas partagés entre les participants. Le principe clé est que la politique d'expiration est documentée, justifiée par le risque et mise en œuvre de manière cohérente. La plateforme de Purple, par exemple, vous permet de configurer et d'appliquer des politiques d'expiration de session de manière centralisée, l'état de la configuration étant exportable comme preuve d'audit. --- SEGMENT 4: RAPID-FIRE Q&A (approx. 1 minute) Passons en revue les questions que je reçois le plus fréquemment de la part des responsables informatiques qui se préparent à la certification ISO 27001. Le WiFi invité doit-il obligatoirement figurer dans le périmètre de notre SMSI ? S'il traite, stocke ou transmet des informations qui entrent dans le périmètre de votre SMSI, oui. Si les invités s'authentifient en utilisant des données personnelles, ou si le réseau se connecte à des systèmes qui sont dans le périmètre, il doit être inclus. Pouvons-nous exclure le WiFi invité de la déclaration d'applicabilité ? Vous pouvez exclure des contrôles, mais vous devez en documenter la justification. Exclure le contrôle A.8.22 Ségrégation des réseaux pour un déploiement de WiFi invité nécessiterait un argument très convaincant que l'auditeur a peu de chances d'accepter. Quel est le dossier de preuves minimal viable pour un audit de WiFi invité ? Un schéma réseau montrant la ségrégation VLAN, l'ensemble de règles du pare-feu, la configuration du Captive Portal avec le texte de la politique d'utilisation acceptable, un échantillon de journal d'authentification, l'entrée correspondante dans l'évaluation des risques et le rapport SOC 2 du fournisseur ou un document d'assurance équivalent. Comment le GDPR interagit-il avec l'ISO 27001 pour le WiFi invité ? Le GDPR est une exigence légale qui alimente le contrôle A.5.31. Votre avis de confidentialité, l'accord de traitement des données avec le fournisseur de votre plateforme WiFi et votre politique de conservation des données sont tous des éléments de preuve ISO 27001 ainsi que des artefacts de conformité GDPR. Ils ont une double fonction. --- SEGMENT 5: SUMMARY AND NEXT STEPS (approx. 1 minute) Pour résumer : le WiFi invité n'est pas une préoccupation secondaire pour votre SMSI — c'est une frontière de réseau active avec une réelle exposition aux risques et un ensemble clair de contrôles ISO 27001:2022 applicables. Les contrôles les plus importants sont le A.8.22 pour la ségrégation réseau, le A.8.20 pour la gestion de la sécurité réseau, le A.8.21 pour l'assurance des fournisseurs, le A.8.15 pour la journalisation, le A.8.23 pour le filtrage web, le A.5.14 pour l'utilisation acceptable et le A.5.31 pour la conformité légale. Vos prochaines étapes immédiates : premièrement, confirmez que le WiFi invité est explicitement inclus dans la déclaration de périmètre de votre SMSI. Deuxièmement, ajoutez une entrée WiFi invité à votre registre des risques avec les menaces, la probabilité, l'impact et les décisions de traitement documentés. Troisièmement, constituez votre dossier de preuves — schéma réseau, règles de pare-feu, configuration du Captive Portal, politique de journalisation et rapport SOC 2 du fournisseur. Quatrièmement, planifiez un examen annuel de l'assurance fournisseur pour votre fournisseur de plateforme WiFi. Si vous déployez ou mettez à niveau votre infrastructure de WiFi invité, la plateforme de Purple est conçue en tenant compte de ces exigences de conformité — alignée sur SOC 2, avec une gestion centralisée des politiques et des preuves de configuration exportables qui alimentent directement votre documentation SMSI. Merci d'avoir suivi ce briefing technique de Purple. Pour consulter le guide écrit complet, les schémas d'architecture et les exemples pratiques, visitez le centre de ressources de Purple. À la prochaine.