Les avantages de sécurité de RADIUS as a Service pour les effectifs hybrides

Ce guide de référence technique explique comment RADIUS as a Service sécurise l'accès au réseau pour les effectifs hybrides au sein des sites distribués. Il présente l'architecture, les avantages de sécurité et les étapes de déploiement pour remplacer une infrastructure RADIUS sur site par un service d'authentification géré dans le cloud. Destiné aux responsables informatiques et aux architectes réseau des hôtels, chaînes de magasins, stades et organisations du secteur public, ce guide fournit les éléments requis pour évaluer et mettre en œuvre une migration vers le RADIUS cloud dès ce trimestre.

📖 9 min de lecture📝 2,171 mots🔧 2 exemples concrets❓ 3 questions d'entraînement📚 9 définitions clés

Écouter ce guide

Voir la transcription du podcast

Bienvenue dans ce point technique de Purple. Je suis votre hôte et nous examinons aujourd'hui un changement critique dans l'architecture réseau des entreprises : le passage de serveurs RADIUS sur site à RADIUS en tant que Service. Si vous gérez l'IT d'un groupe hôtelier, d'une chaîne de magasins, d'un stade ou de tout autre grand lieu public, vous savez que la sécurisation de l'accès réseau pour une main-d'œuvre hybride n'est plus une préoccupation secondaire. Elle est au cœur de votre sécurité opérationnelle, de votre conformité et, pour tout dire, de votre tranquillité d'esprit.

Aujourd'hui, nous aborderons cinq thèmes. Tout d'abord, le contexte : pourquoi l'infrastructure RADIUS traditionnelle sur site peine à suivre le rythme du travail hybride. Deuxièmement, l'architecture technique de RADIUS en tant que Service et son fonctionnement réel. Troisièmement, les avantages spécifiques en matière de sécurité que vous en retirez. Quatrièmement, des conseils pratiques de mise en œuvre et les pièges à éviter. Et cinquièmement, une session rapide de questions-réponses couvrant les questions que nous entendons le plus souvent de la part des directeurs informatiques et des architectes réseau.

Commençons par le contexte. Pendant deux décennies, l'authentification 802.1X reposait sur des serveurs physiques exécutant FreeRADIUS sur Linux, Microsoft Network Policy Server sur Windows ou Cisco Identity Services Engine sur du matériel dédié. Ces systèmes fonctionnaient. Ils fonctionnent toujours. Mais ils nécessitent une attention constante. Vous deviez corriger les systèmes d'exploitation, gérer les chaînes de certificats, configurer manuellement la haute disponibilité et créer de la redondance sur plusieurs serveurs. Dans un monde où les collaborateurs se déplacent constamment entre le bureau, les sites distants, les chambres d'hôtel et les sites clients, cette infrastructure statique sur site devient un véritable handicap.

Le problème est aggravé par la transition vers les fournisseurs d'identité cloud. Microsoft NPS, par exemple, est étroitement lié à Active Directory. Il ne prend pas en charge de manière native Microsoft Entra ID, Google Workspace ou Okta. Si votre organisation a migré vers l'un de ces annuaires cloud, vous êtes confronté à un choix difficile : maintenir un Active Directory parallèle uniquement pour prendre en charge votre serveur RADIUS, ou investir un effort d'ingénierie important dans des intégrations personnalisées. Aucune de ces options n'est séduisante.

RADIUS en tant que Service change complètement la donne. Il déplace le moteur d'authentification vers le cloud. Vous ne gérez plus l'infrastructure ; vous gérez les politiques. Le fournisseur s'occupe des serveurs, des correctifs, de la haute disponibilité et des intégrations. Vous définissez qui a accès à quoi, et le service l'applique.

Entrons maintenant dans l'architecture technique. RADIUS (Remote Authentication Dial-In User Service) est le protocole défini dans la RFC 2865. Il fournit une centralisation de l'Authentification, de l'Autorisation et de la Comptabilisation (ce que nous appelons AAA) pour l'accès réseau. Lorsqu'un appareil se connecte à votre réseau WiFi, le point d'accès agit comme un client RADIUS. Il transmet la demande d'authentification au serveur RADIUS. Le serveur valide les identifiants par rapport à votre base d'identités et renvoie un Access-Accept ou un Access-Reject.

Dans un déploiement cloud RADIUS, le serveur est hébergé par le fournisseur au sein de plusieurs centres de données géographiquement distribués. Vos points d'accès, qu'il s'agisse de Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist ou Ubiquiti UniFi, pointent vers les endpoints cloud RADIUS via des tunnels sécurisés et chiffrés. Le flux d'authentification est identique à celui d'un RADIUS sur site du point de vue du point d'accès. La différence réside dans le fait que le serveur lui-même est géré, corrigé et mis à l'échelle par le fournisseur.

L'amélioration de sécurité la plus importante dans les déploiements modernes de cloud RADIUS est le passage à l'EAP-TLS, qui signifie Extensible Authentication Protocol avec Transport Layer Security. L'EAP-TLS est défini dans la norme RFC 5216 et fournit une authentification mutuelle à l'aide de certificats numériques. L'appareil client et le serveur RADIUS se présentent mutuellement des certificats. Cela élimine totalement les mots de passe du processus d'authentification. Un certificat est lié de manière cryptographique à l'appareil et ne peut pas être hameçonné, deviné ou volé comme le serait un mot de passe.

La seconde fonctionnalité de sécurité majeure est l'attribution dynamique de VLAN. Lorsque le serveur RADIUS authentifie un utilisateur, il ne se contente pas d'autoriser ou de refuser l'accès. Il indique également au point d'accès dans quel LAN virtuel placer l'appareil, en fonction de l'identité et du rôle de l'utilisateur. Un réceptionniste d'hôtel s'authentifie et est placé dans le VLAN de la réception avec un accès au système de gestion de l'établissement. Un membre du personnel d'entretien est placé dans un VLAN restreint avec un accès Internet uniquement. Un appareil invité est placé dans le VLAN invité, complètement isolé de toutes les ressources de l'entreprise. Un appareil IoT, comme une caméra de sécurité, est placé dans un VLAN IoT dédié.

Cette segmentation réseau basée sur l'identité est fondamentale pour un modèle de sécurité Zero Trust. Vous ne faites plus confiance à un appareil simplement parce qu'il s'est connecté à un SSID particulier. Vous accordez l'accès sur la base d'une identité vérifiée, et vous limitez cet accès à ce que cette identité requiert uniquement. C'est le principe du moindre privilège appliqué à l'accès réseau.

Abordons également l'aspect conformité. La norme PCI DSS version 4.0 exige des contrôles d'accès stricts pour tout réseau en contact avec des données de titulaires de cartes. L'exigence 8 impose une authentification unique pour tous les utilisateurs. L'exigence 1 exige une segmentation du réseau. Le cloud RADIUS, avec l'EAP-TLS et l'attribution dynamique de VLAN, répond directement à ces deux exigences. Pour le GDPR, la journalisation d'audit centralisée fournie par le cloud RADIUS vous donne un historique complet de qui a accédé au réseau, quand, et depuis quel appareil. Cette piste d'audit est essentielle pour démontrer la conformité et pour enquêter sur toute violation potentielle de données.

Laissez-moi maintenant vous présenter deux scénarios concrets de mise en œuvre qui illustrent comment cela fonctionne en pratique.

Le premier scénario concerne un groupe hôtelier. Prenons l'exemple d'un hôtel de deux cents chambres. Il utilise actuellement une clé pré-partagée unique pour le WiFi de son personnel. Chaque membre de l'équipe, du directeur général au personnel de ménage saisonnier, utilise le même mot de passe. Lorsqu'un employé saisonnier part à la fin de l'été, le mot de passe est rarement modifié, car le changer implique de mettre à jour chaque appareil de l'établissement. Il s'agit d'une vulnérabilité de sécurité classique.

La solution consiste à déployer RADIUS as a Service intégré à Microsoft Entra ID. L'hôtel configure ses points d'accès Cisco Meraki pour utiliser le protocole WPA3-Enterprise avec 802.1X. Chaque membre du personnel s'authentifie à l'aide de ses identifiants Entra ID. Le serveur RADIUS lit son rôle dans l'annuaire et l'affecte de manière dynamique au VLAN approprié. Le personnel de ménage est placé dans le VLAN 10 avec un accès unique au système de gestion des tâches de nettoyage. Le personnel de réception est placé dans le VLAN 20 avec accès au système de gestion de l'établissement. La direction est placée dans le VLAN 30 avec un accès plus large. Lorsque le contrat d'un employé saisonnier prend fin, son compte Entra ID est désactivé et son accès WiFi est révoqué instantanément sur tous les points d'accès de l'établissement. Aucun changement de mot de passe n'est requis.

Le second scénario est celui d'une chaîne de magasins nationale. Prenons l'exemple d'une chaîne de quatre cents magasins. Ils gèrent actuellement quatre cents instances FreeRADIUS distinctes sur des serveurs locaux en magasin. Chaque serveur nécessite des correctifs, une surveillance et une maintenance individuels. Lorsqu'une vulnérabilité critique est découverte, l'équipe de sécurité doit corriger quatre cents serveurs, souvent sur plusieurs semaines, laissant le parc informatique exposé pendant cette période.

La solution consiste à migrer vers une instance unique de RADIUS as a Service. Les quatre cents magasins dirigent leurs points d'accès HPE Aruba vers les mêmes points de terminaison RADIUS dans le cloud. Les terminaux de point de vente sont authentifiés à l'aide d'EAP-TLS avec des certificats machines déployés via la plateforme MDM. Le serveur RADIUS les place dans un VLAN conforme aux normes PCI, isolé de tout autre trafic réseau. Le personnel du magasin utilise un SSID distinct authentifié via Okta, ce qui le place dans un VLAN dédié au personnel général. L'équipe de sécurité gère désormais un seul ensemble de politiques à partir d'un tableau de bord unique. Lorsqu'une vulnérabilité est découverte, le fournisseur applique les correctifs sur l'infrastructure. L'équipe de sécurité de la chaîne de magasins se concentre sur les politiques, et non sur la maintenance technique.

Abordons maintenant les recommandations de mise en œuvre et les pièges à éviter.

La première étape consiste à connecter le service cloud RADIUS à votre fournisseur d'identité. Pour Microsoft Entra ID ou Google Workspace, cela implique généralement d'autoriser une application d'entreprise. Associez vos groupes d'annuaire à des politiques réseau spécifiques. Réfléchissez attentivement à la taxonomie de vos rôles avant de commencer. Faire les bons choix dès le départ évite de devoir retravailler l'ensemble de la structure par la suite.

La deuxième étape consiste à configurer le déploiement des certificats pour les appareils de l'entreprise. Configurez votre plateforme MDM pour pousser les certificats clients vers les appareils gérés. Cela permet l'authentification EAP-TLS et élimine totalement les mots de passe. Pour les appareils que vous ne gérez pas, vous pouvez utiliser PEAP avec un identifiant utilisateur en guise de secours, mais l'EAP-TLS doit être l'objectif pour tous les appareils appartenant à l'entreprise.

La troisième étape consiste à configurer votre matériel réseau. Ajoutez les adresses IP RADIUS cloud et les secrets partagés à vos contrôleurs sans fil ou points d'accès. Configurez toujours les terminaux primaires et secondaires pour utiliser la redondance intégrée du fournisseur.

La quatrième étape consiste à définir vos politiques de VLAN. Lorsque le serveur RADIUS authentifie un utilisateur, il renvoie l'ID de VLAN correct au point d'accès. Cartographiez cela avant le déploiement. Sachez dans quel VLAN chaque rôle d'utilisateur doit atterrir et testez-le rigoureusement avant de le déployer en production.

Passons maintenant aux pièges à éviter. L'erreur la plus courante est un pare-feu mal configuré qui bloque les ports UDP 1812 et 1813, qui sont les ports d'authentification et de comptabilité RADIUS. Vérifiez toujours la connectivité entre vos points d'accès et les terminaux RADIUS cloud avant la mise en service. Le deuxième piège est une chaîne de confiance de certificats rompue. Si vos appareils clients ne font pas confiance à l'Autorité de Certification Racine qui a émis le certificat du serveur RADIUS, ils rejetteront silencieusement la connexion. Cela peut ressembler à une panne de réseau alors qu'il s'agit en réalité d'un problème de configuration PKI.

Passons aux questions rapides.

Question un : Que se passe-t-il si notre connexion internet est coupée ? Si le site perd sa connexion internet, il ne peut pas joindre le RADIUS cloud. Cependant, si le site n'a pas internet, les utilisateurs ne peuvent de toute façon pas accéder aux applications SaaS. Pour les ressources locales critiques, certains points d'accès proposent des modes de survie locale. Mais la dépendance principale reste votre liaison WAN, et cela est vrai pour presque tous les services SaaS que votre organisation utilise.

Question deux : Le RADIUS cloud est-il conforme aux normes GDPR et PCI DSS ? Oui. L'authentification centralisée avec transport chiffré favorise une posture de conformité solide. Les journaux d'audit répondent aux exigences PCI DSS, et les contrôles d'accès stricts soutiennent les principes de minimisation des données et de limitation d'accès de la GDPR.

Question trois : Cela fonctionne-t-il avec notre matériel existant ? Oui. RADIUS est un protocole standard défini dans la RFC 2865. Si votre matériel prend en charge le 802.1X, ce qui est le cas de tous les équipements d'entreprise de Juniper Mist, Ubiquiti UniFi, Cambium, Extreme et Fortinet, il fonctionnera avec n'importe quel RADIUS as a Service conforme aux normes.

Pour résumer les points clés. Premièrement, RADIUS en tant que Service remplace les serveurs sur site par une plateforme cloud gérée, réduisant ainsi les dépenses d'investissement et les frais de maintenance. Deuxièmement, le RADIUS cloud s'intègre nativement avec Microsoft Entra ID, Okta et Google Workspace, éliminant ainsi le besoin de middleware complexe. Troisièmement, il permet l'attribution dynamique de VLAN, garantissant que les utilisateurs et les appareils soient orientés vers le bon segment de réseau en fonction de leur identité vérifiée. Quatrièmement, la transition vers EAP-TLS élimine le risque de vol de mots de passe et d'attaques par phishing sur votre réseau. Cinquièmement, la gestion centralisée dans le cloud garantit des politiques de sécurité cohérentes sur des centaines de sites distribués. Sixièmement, les fournisseurs gèrent les correctifs de sécurité et la haute disponibilité. Et septièmement, le RADIUS cloud soutient la conformité avec PCI DSS et le GDPR en appliquant des contrôles d'accès stricts basés sur l'identité, avec une journalisation complète des audits.

Votre prochaine étape consiste à évaluer votre infrastructure RADIUS actuelle. Calculez le coût réel de possession, y compris les licences, les cycles de renouvellement du matériel et le temps d'ingénierie consacré à la maintenance. Ensuite, lancez une preuve de concept avec un fournisseur de RADIUS cloud. Vous constaterez probablement que le déploiement prend quelques heures, et non des semaines. Merci pour votre écoute. Sécurisez vos réseaux, segmentez votre trafic et arrêtez de gérer des serveurs que vous n'avez pas besoin de posséder.

Points clés à retenir

✓RADIUS as a Service remplace les serveurs sur site par une plateforme cloud gérée, éliminant ainsi les dépenses d'investissement (CapEx) matérielles et les coûts de maintenance.
✓Cloud RADIUS s'intègre nativement avec Microsoft Entra ID, Okta et Google Workspace, éliminant ainsi le besoin de middleware complexes ou de déploiements Active Directory parallèles.
✓L'attribution dynamique de VLAN garantit que les utilisateurs et les appareils sont automatiquement placés dans le bon segment de réseau en fonction de leur identité vérifiée, et non du SSID auquel ils se sont connectés.
✓La transition vers EAP-TLS (authentification basée sur des certificats) élimine le risque de vol de mots de passe et d'attaques par phishing sur votre réseau.
✓La gestion centralisée dans le cloud applique des politiques de sécurité cohérentes sur des centaines de sites distribués à partir d'un tableau de bord unique.
✓Les fournisseurs gèrent les correctifs de sécurité et la haute disponibilité multi-régions, garantissant que les services d'authentification restent disponibles même pendant les mises à jour de l'infrastructure.
✓Cloud RADIUS prend en charge la conformité avec PCI DSS v4.0 et le GDPR en imposant des contrôles d'accès stricts basés sur l'identité, avec un journal d'audit centralisé complet.

Résumé exécutif

La transition vers des effectifs hybrides a révélé une faiblesse fondamentale dans la sécurité réseau traditionnelle : les serveurs RADIUS sur site ont été conçus pour un monde où le personnel travaillait dans un seul bâtiment et se connectait à un seul réseau. Ce monde n'existe plus. Aujourd'hui, vos collaborateurs s'authentifient depuis des chambres d'hôtel, des surfaces de vente, des bureaux à distance et des lieux d'événements. Vos fournisseurs d'identité résident dans le cloud. Vos points d'accès s'étendent sur des centaines de sites. Pourtant, de nombreuses organisations s'appuient encore sur des serveurs RADIUS physiques qui nécessitent des correctifs manuels, ne peuvent pas s'intégrer nativement à Microsoft Entra ID ou Google Workspace, et tombent en panne de manière invisible en cas de défaillance matérielle.

Le RADIUS as a Service remplace cette infrastructure par un moteur d'authentification cloud-native. Vous pointez vos points d'accès vers des terminaux cloud. Le fournisseur gère les serveurs, les correctifs et la haute disponibilité. Vous gérez les politiques. Pour les équipes informatiques des groupes de l' Hôtellerie , des chaînes de Détail et des espaces publics, cette transition élimine les coûts matériels, impose une segmentation réseau basée sur l'identité et fournit la piste d'audit exigée par la norme PCI DSS et le GDPR.

Analyse technique approfondie

Pourquoi le RADIUS sur site est en difficulté

Le protocole RADIUS, défini dans la norme RFC 2865, fournit une centralisation de l'Authentification, de l'Autorisation et de la Comptabilisation (AAA) pour l'accès au réseau. Chaque entreprise utilisant le WiFi WPA2-Enterprise ou WPA3-Enterprise en dépend. Le protocole en lui-même est robuste. Le problème réside dans le modèle d'infrastructure qui s'est développé autour.

FreeRADIUS sur Linux nécessite une expertise significative pour être déployé, sécurisé et maintenu. Microsoft Network Policy Server (NPS) est étroitement lié à Active Directory et ne dispose d'aucun support natif pour Microsoft Entra ID, Okta ou Google Workspace. Cisco Identity Services Engine (ISE) offre des fonctionnalités de politique de classe entreprise mais exige du matériel dédié, des licences complexes et une équipe de spécialistes pour l'exploiter. Tous trois vous obligent à concevoir et à maintenir manuellement la haute disponibilité, généralement en exécutant deux serveurs avec réplication de base de données et un répartiteur de charge en amont.

Pour une organisation sur un site unique dotée d'un Active Directory stable, ce modèle est gérable. Pour un groupe hôtelier de 50 propriétés, une chaîne de vente au détail de 400 magasins ou une université disposant d'un campus distribué, cela devient irréalisable. Soit vous centralisez les serveurs RADIUS et acceptez la latence d'authentification des sites distants, soit vous déployez des serveurs sur chaque site et les gérez individuellement. Aucune de ces options n'est évolutive.

L'architecture du RADIUS as a Service

Le RADIUS as a Service est un modèle de diffusion basé sur le cloud pour le protocole RADIUS. Le protocole lui-même reste inchangé, conformément à la norme RFC 2865 et à ses extensions. Ce qui change, c'est l'entité qui maintient l'infrastructure.Lorsqu'un appareil se connecte à votre réseau WiFi, le point d'accès (le client RADIUS) transmet la demande d'authentification aux terminaux RADIUS cloud via un tunnel sécurisé et chiffré. Le service cloud valide les identifiants auprès de votre fournisseur d'identité et renvoie un message Access-Accept ou Access-Reject, ainsi que des attributs de politique tels que les attributions de VLAN dynamiques. Du point de vue du point d'accès, le flux d'authentification est identique à celui d'un RADIUS sur site.

Le fournisseur cloud gère les serveurs RADIUS sur plusieurs centres de données répartis géographiquement. Le basculement est automatique. Si un terminal devient indisponible, le trafic est acheminé vers le suivant en bonne santé sans aucune intervention de votre équipe. Pour les organisations implantées dans plusieurs régions, l'authentification s'effectue au terminal cloud le plus proche, ce qui permet de maintenir une faible latence quelle que soit la zone géographique.

Méthodes IEEE 802.1X et EAP

La norme IEEE 802.1X est le standard pour le contrôle d'accès réseau basé sur les ports (NAC). Elle oblige un appareil à s'authentifier avant de recevoir une adresse IP et d'être autorisé à faire transiter du trafic. RADIUS est le serveur d'authentification dans un déploiement 802.1X.

Le protocole EAP (Extensible Authentication Protocol) définit la manière dont les identifiants sont échangés. Cloud RADIUS prend en charge l'ensemble des méthodes EAP :

Méthode EAP	Type d'authentification	Niveau de sécurité	Utilisation recommandée
EAP-TLS	Basé sur des certificats mutuels	Le plus élevé	Appareils d'entreprise avec certificats gérés par MDM
PEAP-MSCHAPv2	Nom d'utilisateur et mot de passe	Modéré	Appareils existants ou BYOD sans MDM
EAP-TTLS	Identifiants tunnelisés	Modéré	Environnements mixtes
MAC Authentication Bypass	Adresse MAC de l'appareil	Faible	Appareils IoT ne pouvant pas prendre en charge le 802.1X

L'EAP-TLS, défini dans la norme RFC 5216, est la référence absolue. L'appareil client et le serveur RADIUS se présentent mutuellement des certificats numériques. Cette authentification mutuelle élimine totalement les mots de passe du processus d'accès au réseau. Un certificat est lié cryptographiquement à l'appareil et ne peut pas être hameçonné, deviné ou volé comme l'est un mot de passe. Pour les organisations qui ont subi des violations basées sur des identifiants, il s'agit de la mesure d'atténuation technique la plus directe.

Attribution dynamique de VLAN

Au-delà de l'authentification, le serveur RADIUS applique l'autorisation. Lorsqu'il accepte une connexion, il renvoie des attributs de politique au point d'accès, y compris l'ID de VLAN à attribuer à l'appareil. Cette attribution dynamique de VLAN est le mécanisme qui permet de créer des réseaux basés sur l'identité.Un réceptionniste d'hôtel s'authentifie et est placé dans le VLAN de la réception avec un accès au système de gestion de l'établissement. Un membre du personnel d'entretien est placé dans un VLAN restreint avec un accès Internet uniquement. Un appareil invité est placé dans le VLAN Guest WiFi, complètement isolé de toutes les ressources de l'entreprise. Un appareil IoT, tel qu'une caméra de sécurité, est placé dans un VLAN IoT dédié. Tout cela se produit automatiquement, sur la base de l'identité vérifiée par le serveur RADIUS, sans aucune configuration manuelle du VLAN par appareil.

C'est le principe du moindre privilège appliqué à l'accès au réseau. Vous ne faites pas confiance à un appareil simplement parce qu'il s'est connecté à un SSID particulier. Vous accordez l'accès sur la base d'une identité vérifiée et vous limitez cet accès à ce dont cette identité a strictement besoin. Pour en savoir plus sur la façon dont cela s'intègre dans une stratégie globale de contrôle d'accès au réseau, consultez notre guide sur les systèmes de contrôle d'accès au réseau .

Intégration native de l'identité cloud

L'avantage opérationnel le plus significatif du RADIUS cloud est son intégration native avec les fournisseurs d'identité modernes. Le RADIUS cloud se connecte directement à Microsoft Entra ID, Okta et Google Workspace via des protocoles standard, notamment OIDC, SAML et LDAP. Lorsque vous configurez un nouvel employé dans votre fournisseur d'identité, il peut s'authentifier immédiatement sur le réseau WiFi. Lorsque vous désactivez un employé, vous désactivez son compte dans l'annuaire et son accès WiFi est instantanément révoqué, sur chaque point d'accès de chaque site.

Cette synchronisation en temps réel élimine l'une des failles de sécurité les plus persistantes du WiFi d'entreprise : l'ancien employé qui possède toujours la clé PSK partagée, ou dont le compte RADIUS n'a pas été supprimé manuellement lors de son départ. Avec le RADIUS cloud et un fournisseur d'identité cloud, la désactivation est une action unique à effet immédiat sur l'ensemble du réseau.

Guide d'implémentation

Étape 1 : Connectez votre fournisseur d'identité

Connectez le service RADIUS cloud à votre fournisseur d'identité. Pour Microsoft Entra ID ou Google Workspace, cela implique généralement d'autoriser une application d'entreprise via OAuth ou de configurer un connecteur LDAP. Associez vos groupes d'annuaire à des politiques réseau spécifiques. Définissez votre taxonomie de rôles avant de commencer : quels groupes correspondent à quels VLANs, et quels droits d'accès chaque VLAN comporte. Faire cela correctement dès le départ évite d'importants ajustements par la suite.

Étape 2 : Déployez des certificats pour les appareils de l'entreprise

Pour les appareils appartenant à l'entreprise, configurez votre plateforme de gestion des appareils mobiles (MDM), telle que Microsoft Intune ou Jamf, pour déployer des certificats clients sur les appareils. Cela permet l'authentification EAP-TLS. Assurez-vous que l'autorité de certification (CA) racine qui a émis le certificat du serveur RADIUS est approuvée par tous les appareils clients. Une chaîne de confiance rompue est la cause la plus fréquente d'échecs d'authentification silencieux.

Étape 3 : Configurez votre matériel réseau

Ajoutez les adresses IP RADIUS cloud et les secrets partagés à vos contrôleurs sans fil ou points d'accès. Configurez toujours les points de terminaison principal et secondaire pour utiliser la redondance intégrée du fournisseur. Assurez-vous que les ports UDP 1812 (authentification) et 1813 (comptabilité) sont ouverts en sortie depuis vos points d'accès vers les points de terminaison RADIUS cloud. Vérifiez ce point avant la mise en service. Les règles de pare-feu mal configurées sont la deuxième cause la plus fréquente d'échec de déploiement.

Le RADIUS cloud fonctionne avec Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme et Fortinet. Les étapes de configuration varient selon le constructeur, mais le protocole RADIUS est standardisé, de sorte que les paramètres de base (IP du serveur, secret partagé, port d'authentification) restent les mêmes.

Étape 4 : Définir les politiques de VLAN

Configurez l'attribution dynamique de VLAN dans votre moteur de politique RADIUS. Associez chaque rôle d'utilisateur ou type d'appareil à un identifiant VLAN spécifique. Testez chaque politique avant le déploiement en production. Une matrice de test simple - un appareil par rôle, un VLAN par rôle, vérification de l'attribution - permet de détecter la plupart des erreurs de configuration avant qu'elles n'affectent les utilisateurs.

Bonnes pratiques

Imposez l'EAP-TLS pour tous les appareils d'entreprise. Abandonnez PEAP-MSCHAPv2 aussi rapidement que votre déploiement MDM le permet. PEAP repose sur des mots de passe, qui peuvent être compromis. EAP-TLS repose sur des certificats, ce qui n'est pas le cas.

Segmentez tout. Ne placez jamais le personnel, les invités et les appareils IoT sur le même sous-réseau. Utilisez RADIUS pour imposer des limites strictes de VLAN. C'est un élément essentiel pour les environnements du Commerce de détail qui gèrent des données de cartes de paiement sous la norme PCI DSS, et pour les environnements de Santé protégeant les données des patients.

Alignez-vous sur le WPA3-Enterprise. Le WPA3-Enterprise, la norme de sécurité WiFi actuelle, requiert une authentification 802.1X. Assurez-vous que vos points d'accès prennent en charge le WPA3-Enterprise et configurez-le comme norme de sécurité minimale pour les réseaux du personnel.

Auditez régulièrement vos journaux RADIUS. Le RADIUS cloud fournit des journaux d'audit centralisés. Examinez les échecs d'authentification chaque semaine. Une augmentation soudaine des échecs depuis un appareil ou un emplacement spécifique est un indicateur précoce d'une mauvaise configuration ou d'une attaque potentielle.

Testez le basculement. Au moins une fois par trimestre, simulez une panne du point de terminaison RADIUS principal et vérifiez que l'authentification se poursuit via le point de terminaison secondaire. Documentez le résultat. C'est un test simple que la plupart des équipes n'exécutent jamais avant d'en avoir réellement besoin.

Pour les sites déployant du WiFi dans des environnements complexes, y compris des zones maritimes ou éloignées, consultez notre guide sur la configuration d'un Captive Portal sur Starlink pour connaître les aspects liés à la dépendance WAN.

Dépannage et atténuation des risques

Expirations de délai d'authentification

Si les appareils ne parviennent pas à s'authentifier, vérifiez d'abord la connectivité entre vos points d'accès et les terminaux cloud RADIUS. Vérifiez que les ports UDP 1812 et 1813 sont ouverts en sortie. L'inspection approfondie des paquets (DPI) sur les pare-feu modernes peut retarder ou abandonner les paquets RADIUS. Si vous constatez des expirations de délai (timeouts), vérifiez vos règles de pare-feu pour identifier celles qui pourraient inspecter ou limiter le débit du trafic UDP vers les terminaux RADIUS.

Échecs de la chaîne de confiance des certificats

Si vous utilisez EAP-TLS, assurez-vous que les appareils clients font confiance à l'autorité de certification racine (Root CA) qui a émis le certificat du serveur RADIUS. Si la chaîne de confiance est rompue, l'appareil rejettera silencieusement la connexion pour empêcher une attaque de l'homme du milieu (man-in-the-middle). Cela se traduit par un échec de connexion sans message d'erreur explicite. Vérifiez les journaux du serveur RADIUS pour détecter les échecs de handshake EAP-TLS. Déployez le certificat Root CA sur tous les appareils gérés via un MDM.

Dépendance au réseau WAN

Le cloud RADIUS nécessite une connexion internet active. Si la liaison WAN échoue, les demandes d'authentification ne peuvent pas atteindre le serveur. Pour les ressources locales stratégiques, évaluez les points d'accès qui prennent en charge la survie locale ou la mise en cache de l'authentification. Pour la plupart des déploiements, la dépendance au WAN est acceptable car un site sans internet ne peut de toute façon pas accéder aux applications SaaS.

Incohérences de secret partagé

Chaque point d'accès ou contrôleur sans fil doit être configuré comme un client RADIUS avec le secret partagé correct. Une incohérence entraîne le rejet silencieux de toutes les demandes d'authentification provenant de cet appareil. Si un point d'accès spécifique échoue alors que d'autres réussissent, vérifiez la configuration du secret partagé sur cet appareil.

ROI et impact commercial

L'argument commercial en faveur de RADIUS as a Service repose sur trois piliers : la réduction des dépenses d'investissement, la baisse des coûts opérationnels et l'amélioration de la posture de sécurité.

Concernant les dépenses d'investissement, vous éliminez les coûts d'achat, de licence et de renouvellement des serveurs physiques. Un déploiement RADIUS sur site minimal viable nécessite deux serveurs pour la haute disponibilité, des licences de système d'exploitation et un renouvellement du matériel tous les trois à cinq ans. Pour un groupe hôtelier de 50 établissements, cela représente un investissement matériel conséquent sur l'ensemble du parc.

Concernant les coûts opérationnels, votre équipe d'ingénierie ne passe plus de temps à corriger Windows Server, à dépanner les configurations FreeRADIUS ou à gérer les renouvellements de certificats sur l'infrastructure physique. Ce temps est réorienté vers l'élaboration de politiques de sécurité qui améliorent directement votre posture.

Concernant la posture de sécurité, le passage à EAP-TLS et à l'attribution dynamique de VLAN réduit considérablement la surface d'attaque. Le vol d'identifiants est la principale cause de failles de réseau. L'élimination des mots de passe du processus d'authentification réseau répond directement à ce risque. La centralisation des journaux d'audit facilite la conformité avec PCI DSS v4.0 et le GDPR, réduisant ainsi le coût et la complexité des audits de conformité. Pour les organisations qui gèrent des hubs de Transport ou des sites à forte fréquentation, la capacité d'appliquer des politiques de sécurité cohérentes sur l'ensemble des sites depuis un tableau de bord unique constitue une amélioration opérationnelle mesurable. Purple est déployé sur plus de 80 000 sites actifs et a traité 440 millions de connexions en 2024 (données internes Purple, 2024). L'infrastructure qui soutient cette envergure est nativement conçue pour le cloud.

Pour une vision plus large de la manière dont les analyses WiFi et l'intelligence réseau sont liées aux résultats commerciaux, consultez notre plateforme d'analyse WiFi .

Références

[1] Norme IEEE pour les réseaux locaux et métropolitains - Contrôle d'accès au réseau basé sur les ports. IEEE Std 802.1X-2020. [2] IETF. Remote Authentication Dial In User Service (RADIUS). RFC 2865. 1997. [3] IETF. Protocole d'authentification EAP-TLS. RFC 5216. 2008. [4] IronWiFi. Avantages d'un serveur Cloud RADIUS : pourquoi les entreprises migrent l'authentification en ligne. Février 2026. [5] SecureW2. Cloud vs. RADIUS sur site : quel est le meilleur choix ? Mai 2026. [6] Portnox. RADIUS as a Service. 2026. [7] Conseil des normes de sécurité PCI. PCI DSS v4.0. Mars 2022. [8] Purple. Données de plateforme internes : 440 millions de connexions, plus de 80 000 sites. 2024.

Définitions clés

RADIUS

Remote Authentication Dial-In User Service. Un protocole réseau défini dans la norme RFC 2865 qui fournit une gestion centralisée de l'authentification, de l'autorisation et de la comptabilisation (AAA) pour les utilisateurs se connectant à un service réseau.

Les équipes informatiques utilisent RADIUS comme moteur de décision central pour vérifier si un appareil ou un utilisateur est autorisé à accéder au réseau WiFi de l'entreprise. Il se positionne entre le point d'accès et le fournisseur d'identité.

802.1X

Une norme IEEE pour le contrôle d'accès réseau basé sur les ports. Elle fournit un mécanisme d'authentification aux appareils souhaitant se connecter à un réseau LAN ou WLAN, les obligeant à s'authentifier avant de recevoir une adresse IP.

Il s'agit de la norme qui sous-tend la sécurité du WiFi d'entreprise. Sans 802.1X, tout appareil qui se connecte au SSID obtient un accès au réseau. Avec 802.1X, chaque appareil doit d'abord prouver son identité.

EAP-TLS

Extensible Authentication Protocol - Transport Layer Security. Une méthode d'authentification définie dans la norme RFC 5216 qui exige que l'appareil client et le serveur RADIUS présentent tous deux des certificats numériques, offrant ainsi une authentification mutuelle sans mot de passe.

Considéré comme la référence absolue en matière de sécurité WiFi d'entreprise. Les certificats sont déployés sur les appareils de l'entreprise via MDM. EAP-TLS élimine le risque de vol de mot de passe et d'attaques de phishing sur le réseau.

PEAP

Protected Extensible Authentication Protocol. Une méthode EAP qui encapsule un échange de nom d'utilisateur et de mot de passe à l'intérieur d'une session TLS. Moins sécurisée que EAP-TLS car elle repose sur des mots de passe.

PEAP-MSCHAPv2 est largement déployé dans les environnements existants. Les équipes informatiques doivent planifier une migration vers EAP-TLS pour les appareils de l'entreprise, en utilisant PEAP uniquement comme solution de secours pour les appareils non gérés ou BYOD.

Dynamic VLAN assignment

Un processus par lequel le serveur RADIUS indique au point d'accès dans quel VLAN virtuel placer un appareil, en fonction de l'identité et du rôle vérifiés de l'utilisateur, plutôt que du SSID auquel il s'est connecté.

Essentiel pour la segmentation du réseau dans les environnements multi-rôles. Un seul SSID « Personnel » peut séparer en toute sécurité le trafic du personnel d'entretien, de la réception et de la direction dans différents VLAN avec des droits d'accès distincts.

AAA

Authentification, Autorisation et Comptabilisation (Authentication, Authorisation, and Accounting). Les trois fonctions exécutées par un serveur RADIUS : vérifier l'identité (authentification), déterminer quel accès est autorisé (autorisation) et enregistrer les données de session à des fins d'audit (comptabilisation).

Les équipes informatiques et les auditeurs utilisent AAA comme cadre pour évaluer le contrôle d'accès au réseau. Cloud RADIUS assure ces trois fonctions à partir d'un service géré.

WPA3-Enterprise

La norme de sécurité WiFi actuelle pour les réseaux d'entreprise, nécessitant une authentification 802.1X via un serveur RADIUS. Elle offre une résistance cryptographique améliorée par rapport à WPA2-Enterprise, incluant un mode de sécurité 192 bits pour les environnements hautement sécurisés.

Les responsables informatiques doivent configurer WPA3-Enterprise comme norme de sécurité minimale pour les réseaux du personnel. Les réseaux invités peuvent utiliser WPA2 ou une authentification ouverte avec un Captive Portal.

Network Access Control (NAC)

Une approche de sécurité qui applique des politiques aux appareils cherchant à accéder aux ressources du réseau, combinant l'évaluation de la sécurité des terminaux, l'authentification de l'identité et l'application des règles réseau.

RADIUS est un composant fondamental du NAC. Cloud RADIUS étend le NAC aux environnements distribués et multisites sans nécessiter d'infrastructure sur site à chaque emplacement.

Captive Portal

Une page web avec laquelle l'utilisateur d'un réseau d'accès public doit interagir avant de se voir accorder l'accès à Internet. Généralement utilisé pour le WiFi invité afin de recueillir le consentement ou d'afficher les conditions d'utilisation.

Les portails captifs gèrent l'accès des invités non authentifiés, tandis que le 802.1X gère l'accès du personnel authentifié. Les deux mécanismes fonctionnent sur des SSIDs et des VLANs distincts.

Exemples concrets

Un hôtel de 200 chambres doit sécuriser son réseau destiné au personnel (ménage, réception et direction), tout en séparant totalement le Wi-Fi invités. Il utilise actuellement une clé PSK partagée pour le réseau du personnel, qui n'a pas été modifiée depuis deux ans.

Déployer RADIUS as a Service intégré à Microsoft Entra ID. Configurer les points d'accès Cisco Meraki pour utiliser le WPA3-Enterprise avec 802.1X. Le personnel de ménage s'authentifie à l'aide de ses identifiants Entra ID ; le serveur RADIUS lit leur groupe d'annuaire et leur attribue dynamiquement le VLAN 10 (accès uniquement au système de tâches ménagères). Le personnel de réception est affecté au VLAN 20 (accès au système de gestion de l'établissement). La direction est affectée au VLAN 30 (accès plus large). Le Wi-Fi invités reste sur un SSID distinct avec un Captive Portal, isolé sur le VLAN 40. Lorsqu'un employé saisonnier quitte l'entreprise, son compte Entra ID est désactivé, révoquant instantanément son accès Wi-Fi sur l'ensemble des points d'accès de l'établissement.

Commentaire de l'examinateur : Cette approche élimine la vulnérabilité liée à la clé PSK partagée et le risque que d'anciens employés conservent leur accès. L'attribution dynamique de VLAN garantit qu'un appareil compromis du service ménage ne puisse pas accéder au système de gestion de l'établissement. L'utilisation du RADIUS cloud supprime le besoin d'un serveur physique dans le local informatique restreint de l'hôtel. L'intégration avec Entra ID permet un départ d'employé en une seule action, avec un effet immédiat sur l'ensemble du réseau.

Une chaîne nationale de vente au détail comptant 400 magasins doit garantir la conformité PCI DSS pour ses terminaux de point de vente (POS). Elle gère actuellement 400 instances FreeRADIUS distinctes sur des serveurs locaux en magasin, chacune nécessitant des correctifs individuels.

Migrer vers une instance unique de RADIUS as a Service. Configurer les points d'accès HPE Aruba des 400 magasins pour authentifier les terminaux POS à l'aide d'EAP-TLS avec des certificats machines déployés via Microsoft Intune. Le serveur RADIUS cloud authentifie les certificats et place les terminaux POS dans un VLAN conforme à la norme PCI (VLAN 30), isolé de tout autre trafic réseau. Le personnel du magasin utilise un SSID distinct authentifié via Okta, qui le place dans un VLAN dédié au personnel général (VLAN 20). Les clients sur le réseau invités sont isolés sur le VLAN 40. L'équipe de sécurité gère l'ensemble des politiques depuis un tableau de bord unique.

Commentaire de l'examinateur : La centralisation de l'infrastructure RADIUS élimine la charge de maintenance liée à l'application de correctifs sur 400 serveurs locaux. L'utilisation d'EAP-TLS pour les terminaux POS supprime totalement les mots de passe, empêchant ainsi le vol d'identifiants. Cette architecture répond aux exigences de la norme PCI DSS v4.0 (Exigence 8 : authentification unique et Exigence 1 : segmentation du réseau). En cas de vulnérabilité signalée, c'est le fournisseur qui applique le correctif sur l'infrastructure cloud, évitant ainsi à l'équipe de sécurité de la chaîne de magasins de devoir corriger 400 serveurs sur plusieurs semaines.

Questions d'entraînement

Q1. Le campus de votre université utilise actuellement Microsoft NPS sur Windows Server pour authentifier les étudiants via PEAP-MSCHAPv2. L'établissement migre vers Google Workspace et souhaite déclasser tous les serveurs sur site d'ici 12 mois. Quel est le changement d'architecture le plus sécurisé et le plus efficace sur le plan opérationnel pour l'infrastructure d'authentification WiFi ?

Conseil : Microsoft NPS ne prend pas en charge nativement Google Workspace. Réfléchissez à ce qui remplace à la fois le serveur et la méthode d'authentification.

Voir la réponse type

Migrer vers RADIUS as a Service avec une intégration native à Google Workspace. Le service cloud RADIUS se connecte directement à Google Workspace via LDAP ou OIDC, éliminant ainsi le besoin d'Active Directory ou de NPS. Simultanément, faites passer les appareils gérés des étudiants et du personnel de PEAP-MSCHAPv2 à EAP-TLS en déployant des certificats clients via la plateforme MDM de l'établissement. Cela supprime les mots de passe du processus d'authentification et garantit que seuls les appareils gérés et approuvés peuvent accéder aux réseaux du personnel et des étudiants. La migration peut être progressive : déployez le service cloud RADIUS aux côtés de NPS, migrez un SSID à la fois, puis déclassez NPS une fois que tous les appareils utilisent le nouveau service.

Q2. Un stade d'une capacité de 80 000 places nécessite un WiFi sécurisé pour le personnel de l'entreprise, les terminaux de billetterie, les membres de la presse écrite et les prestataires présents les jours d'événement. Comment configurer le réseau à l'aide de cloud RADIUS pour appliquer l'accès approprié à chaque groupe ?

Conseil : Réfléchissez à la manière dont RADIUS gère l'autorisation, et pas seulement l'authentification. Chaque groupe a besoin de droits d'accès différents.

Voir la réponse type

Déployez un seul SSID 802.1X pour tous les groupes authentifiés. Configurez le service cloud RADIUS pour utiliser l'attribution dynamique de VLAN en fonction du rôle de l'utilisateur dans le fournisseur d'identité. Le personnel de l'entreprise est affecté au VLAN 10 avec accès aux systèmes internes. Les terminaux de billetterie, authentifiés via des certificats de machine (EAP-TLS), sont placés dans un VLAN 20 restreint avec un accès uniquement à la plateforme de billetterie. Les membres de la presse écrite sont affectés au VLAN 30 avec un accès internet haut débit mais aucun accès aux systèmes internes. Les prestataires présents les jours d'événement sont affectés au VLAN 40 avec un accès internet limité uniquement. Un SSID ouvert distinct avec un Captive Portal gère l'accès invité des supporters et des spectateurs sur le VLAN 50, isolé de tout autre trafic.

Q3. Lors d'un audit de sécurité, il est découvert que le serveur FreeRADIUS de votre entreprise n'a pas reçu de correctif de sécurité depuis huit mois. L'équipe a hésité à appliquer les correctifs car la dernière mise à jour a provoqué une interruption de l'authentification de deux heures. Comment la migration vers RADIUS as a Service résout-elle à la fois le risque de sécurité et le risque opérationnel ?

Conseil : Prenez en compte le partage des responsabilités dans un modèle de service géré et la manière dont les fournisseurs gèrent les correctifs sans interruption de service.

Voir la réponse type

RADIUS as a Service transfère la responsabilité de l'application des correctifs du système d'exploitation et de la gestion des vulnérabilités au fournisseur. Le fournisseur exploite des clusters hautement disponibles et multirégionaux, ce qui lui permet d'appliquer des correctifs aux points de terminaison individuels et de déployer les mises à jour de manière progressive sans provoquer d'interruption de l'authentification. Votre équipe n'a plus besoin de planifier des fenêtres de maintenance ni d'accepter le risque d'une panne provoquée par un correctif. Le risque de sécurité est éliminé car le fournisseur applique les correctifs à l'infrastructure dès que les vulnérabilités sont révélées, souvent avant que la CVE ne soit largement diffusée. Le risque opérationnel est éliminé car le SLA du fournisseur garantit la disponibilité, quelle que soit l'activité d'application des correctifs. Le rôle de votre équipe passe de la maintenance de l'infrastructure à la gestion des politiques.

Continuer la lecture de cette série

Intégration de RADIUS as a Service avec les annuaires cloud (Azure AD & Google Workspace)

Ce guide de référence technique détaille comment intégrer RADIUS as a Service avec les annuaires cloud - Microsoft Entra ID et Google Workspace - pour l'authentification WiFi d'entreprise. Il couvre la transition architecturale du NPS sur site vers un RADIUS cloud-native, le déploiement de l'authentification EAP-TLS basée sur des certificats, ainsi que les meilleures pratiques opérationnelles pour sécuriser l'accès sans fil dans les secteurs de l'hôtellerie, du commerce de détail et du secteur public. Pour les responsables informatiques et les architectes réseau déjà investis dans l'identité cloud, ce guide comble le fossé entre la gestion des annuaires et la sécurité du réseau physique.

Comment implémenter l'authentification 802.1X avec Cloud RADIUS

Ce guide de référence technique fournit un cadre complet pour implémenter l'authentification 802.1X avec Cloud RADIUS sur l'ensemble des parcs d'entreprises distribués. Il détaille l'architecture, la sélection de la méthode EAP, le séquençage du déploiement et les stratégies de réduction des risques nécessaires pour sécuriser l'accès au réseau tout en éliminant les coûts opérationnels de l'infrastructure sur site.

Qu'est-ce que Cloud RADIUS ? Le guide complet du RADIUS as a Service

Ce guide complet explore Cloud RADIUS (RADIUS as a Service), en détaillant son architecture, ses méthodes EAP et ses stratégies de déploiement. Il fournit aux responsables informatiques des conseils pratiques pour migrer de serveurs sur site vers un modèle d'authentification cloud évolutif, sécurisé et conforme.