Vous faites face à un serveur Network Policy Server que personne ne souhaite mettre à jour, un contrôleur sans fil pointant vers un unique boîtier RADIUS dans une salle serveur, et une file d'attente au support remplie de réinitialisations de mots de passe. L'identité a migré vers Microsoft Entra ID ou Okta, mais l'authentification WiFi dépend toujours d'une infrastructure locale conçue pour Active Directory sur site. C'est en constatant ce décalage que les organisations commencent à envisager un serveur cloud radius, non pas parce que déplacer un serveur est passionnant, mais parce que l'ancien modèle ne correspond plus au fonctionnement des utilisateurs, des appareils et des sites.
Qu'est-ce qu'un serveur Cloud RADIUS
Considérez RADIUS comme un agent de sécurité à l'entrée d'un bâtiment. Une personne arrive, présente un badge, et l'agent vérifie ce badge par rapport à une liste d'autorisations avant d'ouvrir la porte. Si le badge est valide, l'agent détermine également les étages auxquels cette personne peut accéder. S'il ne l'est pas, la porte reste fermée.
Un serveur RADIUS cloud déplace ce contrôle d'une guérite locale vers un service géré de manière centralisée. La vérification s'effectue toujours à l'entrée, ce qui, en termes de WiFi, correspond à votre point d'accès ou à votre commutateur. La décision provient toutefois d'un service hébergé que vous configurez via des politiques, plutôt que de serveurs que vous devez mettre à jour, sauvegarder et regrouper vous-même.
Fonctionnement du flux d'authentification
Un ordinateur portable ou un téléphone se connecte à un SSID WPA2 ou WPA3 Enterprise protégé par le protocole 802.1X. Le point d'accès ne prend pas la décision seul. Il transmet la demande d'authentification au serveur RADIUS cloud, qui valide l'identifiant, le certificat ou l'identité de l'équipement auprès de votre annuaire ou de votre autorité de certification.
Le serveur renvoie une réponse d'acceptation ou de rejet, souvent assortie d'attributs tels qu'un VLAN, un rôle ou une limite de session. Le point d'accès applique cette décision localement. Cette séparation est essentielle, car le serveur RADIUS constitue le point de décision, et non l'intégralité du réseau ni votre fournisseur d'identités lui-même.
- Demandeur (Supplicant) : L'ordinateur portable, le téléphone ou l'appareil qui demande l'accès et présente un identifiant ou un certificat.
- Authentificateur : Le point d'accès, le contrôleur ou le commutateur qui transmet la demande et applique le résultat.
- Source d'identité : Entra ID, Okta, Google Workspace, Active Directory ou une autorité de certification qui détient l'enregistrement faisant foi.
Pourquoi l'approche hybride est le point de départ habituel
Les organisations du Royaume-Uni n'ont pas tout migré vers le cloud en une seule étape. Le Cloud Industry Forum a rapporté que 84 % des organisations britanniques avaient formellement adopté au moins un service cloud dans son étude de 2016, contre 48 % en 2010, ce qui explique pourquoi le RADIUS cloud est généralement déployé dans le cadre d'une architecture hybride plutôt qu'en remplacement immédiat de chaque composant local, comme indiqué dans l'étude du Cloud Industry Forum sur les tendances d'adoption du cloud au Royaume-Uni pour 2016.
En pratique, vos commutateurs, points d'accès, imprimantes et systèmes hérités restent sur site. Ce qui change, c'est l'endroit où la décision d'authentification est prise et la cohérence avec laquelle vous pouvez l'appliquer sur l'ensemble de vos sites. C'est une définition plus précise et plus utile que de parler d'un simple remplacement de serveur hébergé.
Cloud RADIUS vs RADIUS sur site
La véritable comparaison n'est pas entre le cloud qui serait idéal et le site physique qui serait obsolète. Il s'agit de savoir qui porte la charge opérationnelle, de quel niveau de contrôle vous avez besoin, et de ce qui se passe en cas de défaillance. Une paire de serveurs sur site bien gérée peut fonctionner pendant des années. Une infrastructure négligée devient un point unique de défaillance auquel plus personne n'ose toucher.
Les parcs informatiques au Royaume-Uni restent également mixtes. Une étude du gouvernement britannique de 2025 a révélé qu'environ 55 % des organisations du gouvernement central ont déclaré avoir plus de 60 % de leur parc technologique dans le cloud, tandis qu'environ 28 % des parcs technologiques du gouvernement central demeuraient hérités, selon la State of Digital Government Review. C'est précisément la raison pour laquelle cette combinaison exige toujours de connecter l'identité cloud aux bâtiments et aux réseaux sans fil qui restent sur site.
Comparatif des coûts et de la maintenance
| Critères | RADIUS Cloud | RADIUS Sur site |
|---|---|---|
| Coût d'investissement | Faible, basé sur un abonnement | Matériel et licences initiales plus élevés |
| Maintenance | Le fournisseur applique les correctifs et gère le service | Votre équipe applique les correctifs à l'OS, au RADIUS et aux certificats |
| Scalabilité | Ajout de sites par simple configuration | Ajout de serveurs, de clustering et de répartition de charge |
| Contrôle | Contrôle des politiques, contrôle réduit des infrastructures | Contrôle total, responsabilité totale |
| Résilience | Points d'accès redondants fournis par le prestataire | Vous concevez et testez vous-même le basculement |
FreeRADIUS semble gratuit jusqu'à ce que vous comptabilisiez le temps des ingénieurs, les renouvellements de certificats, la surveillance et le dépannage en dehors des heures d'ouverture. Microsoft NPS semble inclus jusqu'à ce que vous ayez besoin d'une intégration native avec un annuaire cloud pour lequel il n'a pas été conçu. Cisco ISE offre des fonctionnalités de politique avancées, mais exige des licences et des compétences spécialisées que de nombreuses équipes ne peuvent pas justifier pour le seul WiFi.
L'idée reçue concernant la sécurité
L'emplacement du serveur ne garantit pas la sécurité de l'authentification. Ce sont la configuration, l'intégration de l'identité, le transport chiffré et la surveillance qui la garantissent.
Le cloud déplace les risques plutôt qu'il ne les supprime. Vous gagnez en cohérence dans les correctifs et les politiques multi-sites, mais vous dépendez de la connectivité internet, du plan de contrôle du fournisseur et du fournisseur d'identités. Une solution sur site conserve le trafic en local, mais un serveur unique non mis à jour utilisant des secrets partagés partout n'est pas plus sûr simplement parce qu'il se trouve dans votre bâtiment.
Choisissez le cloud si vous manquez de personnel pour gérer correctement une paire à haute disponibilité, si vous gérez de nombreux sites ou si vous avez déjà migré l'identité vers le cloud. Restez sur site lorsque la réglementation, la latence ou un site déconnecté nécessitent véritablement des décisions locales. De nombreuses migrations RH et IT suivent la même logique hybride, c'est pourquoi ce guide pour les équipes RH Microsoft 365 constitue une lecture parallèle utile sur la migration des systèmes centraux sans prétendre que l'existant disparaît du jour au lendemain.
Intégration avec Microsoft Entra ID, Okta et les certificats
Un serveur RADIUS cloud prouve toute sa valeur au niveau des interconnexions. S'il ne peut pas communiquer de façon fluide avec votre annuaire, votre autorité de certification et vos flux invités, vous avez acheté un goulot d'étranglement hébergé. Mettez en place les bons schémas d'intégration pour que l'accès réseau suive la même logique d'arrivée, de changement de poste et de départ d'employé que le reste de votre SI.
RADIUS lui-même ne prend pas en charge la fédération Web moderne. Si votre équipe cherche à comprendre où se termine l'authentification réseau et où commence le SSO des applications, cette présentation de l'authentification SAML et OIDC aide à séparer ces couches. RADIUS gère l'admission sur le réseau, tandis que SAML et OIDC gèrent généralement la connexion aux applications une fois que l'utilisateur est déjà connecté.
Authentification adossée à l'annuaire pour le personnel
Avec Microsoft Entra ID ou Okta, le service RADIUS vérifie l'utilisateur ou l'appareil par rapport aux groupes et attributs de l'annuaire. Un utilisateur de la finance peut se voir attribuer un rôle différent de celui d'un prestataire des services généraux, même sur le même SSID. Lorsque les RH désactivent un compte, ce changement doit se répercuter sur l'accès au réseau sans nécessiter de ticket séparé auprès de l'équipe réseau.
Pour Microsoft Entra ID en particulier, validez la façon dont les groupes, les objets d'appareil et les signaux conditionnels s'associent aux stratégies RADIUS avant de déployer à grande échelle, comme expliqué dans ce guide d'intégration RADIUS-as-a-Service pour Microsoft Entra ID. Testez le départ d'un employé, un changement de rôle et un appareil désactivé pendant la phase pilote. Ces trois cas d'usage sont plus révélateurs que cent connexions réussies.
Certificats pour les appareils que vous gérez
EAP-TLS utilise des certificats des deux côtés, il n'y a donc aucun mot de passe à hameçonner, partager ou forcer par attaque par force brute. C'est le modèle le plus solide pour les ordinateurs portables gérés, à condition de pouvoir émettre, renouveler et révoquer les certificats via un MDM ou SCEP sans intervention manuelle. Si le provisionnement des certificats est instable, les utilisateurs vous pousseront à revenir aux mots de passe, et ils obtiendront gain de cause.
- Émettre l'identité : Déployez un certificat d'utilisateur ou d'appareil via Intune, Jamf ou votre MDM avec un propriétaire clair et une date d'expiration.
- Valider la confiance : Configurez le service RADIUS pour faire confiance à votre AC émettrice et vérifier le statut de révocation.
- Lier à la politique : Associez les champs de certificat et les groupes d'annuaire aux VLAN ou aux rôles au niveau du point d'accès.
- Révoker rapidement : Supprimez simultanément le certificat et l'accès à l'annuaire lorsqu'un appareil est perdu ou qu'un collaborateur quitte l'entreprise.
Invités et appareils ne prenant pas en charge 802.1X
Les visiteurs ne devraient pas avoir besoin d'un compte d'entreprise pour obtenir un accès sécurisé. Passpoint et OpenRoaming permettent à un appareil de s'authentifier une fois et de se reconnecter avec un accès chiffré lors des visites ultérieures, ce qui convient parfaitement aux hôtels, hubs de transport et sites multiples. Pour les imprimantes, les terminaux de paiement et les anciens équipements IoT qui ne peuvent pas présenter de certificats, utilisez le bypass d'authentification MAC ou des clés individuelles prépartagées avec une segmentation stricte, et considérez ces appareils comme non fiables par défaut.
Considérations de sécurité et Zero-Trust
Considérez un serveur RADIUS cloud comme une frontière de confiance, et non comme un simple outil pratique. Il décide qui accède à votre réseau, communique avec votre annuaire, et sa console d'administration peut modifier les politiques de tous les sites simultanément. Cette concentration de pouvoir est utile, et c'est précisément pour cela que les contrôles qui l'entourent exigent un examen rigoureux.
Le NCSC recommande que les interfaces de services Cloud n'exposent l'accès qu'à des identités authentifiées et autorisées, avec une authentification contextuelle utilisant des assertions cryptographiques ou un échange de clés sécurisé, comme décrit dans le Principe 10 du NCSC sur l'identité et l'authentification. Pour le RADIUS Cloud, cela implique de traiter le service et ses interfaces d'administration comme des périmètres de confiance distincts, avec des identités de service uniques, des autorisations strictement limitées et des événements d'authentification auditables au lieu d'identifiants d'administration partagés.
Ne vous fiez plus à l'emplacement réseau
Le Zero Trust transforme la question : il ne s'agit plus de savoir si cet équipement est sur notre VLAN, mais qui est cet utilisateur, quel est cet équipement et qu'il doit pouvoir atteindre à cet instant précis. La présence sur un VLAN d'entreprise ou invité n'est pas une preuve d'autorisation. L'accès doit rester conditionné par l'identité authentifiée et la politique appliquée à cette session, ce tenant et ce site.
Ce principe a des conséquences pratiques sur la conception du WiFi. Le portable d'un prestataire et celui du service financier peuvent partager un SSID mais ne doivent pas partager la même accessibilité réseau. Votre ensemble global de contrôles doit s'aligner sur un guide de sécurité WiFi d'entreprise pour un accès réseau zero trust afin que les décisions d'authentification soient liées à la segmentation, à la surveillance et au moindre privilège, et pas seulement à l'établissement de la connexion.
Contrôles à exiger d'un fournisseur
- Transport chiffré : RadSec ou une protection équivalente pour le trafic RADIUS, ainsi qu'un TLS moderne pour les API et l'accès d'administration.
- Rotation et révocation : Rotation documentée des certificats et des secrets, et révocation rapide lorsque les comptes ou appareils sont désactivés.
- Administration basée sur les rôles : Rôles de lecteur, d'opérateur et d'administrateur distincts, sans identifiants partagés pour les modifications de politique.
- Journalisation exploitable : Événements d'authentification, modifications de politique et actions d'administration exportés vers votre SIEM avec une rétention claire.
Règle pratique : Si la compromission d'un site ou d'un compte d'intégration donne à un attaquant l'accès d'administration sur d'autres clients ou sur le plan de contrôle, l'architecture a échoué.
Posez rapidement les questions complexes. Qui peut consulter les journaux d'authentification, où sont-ils stockés, et comment l'accès de gestion du fournisseur est-il isolé de votre plan de données. Si un fournisseur ne peut pas répondre clairement, c'est une indication en soi.
Modèles de déploiement pour le WiFi d'entreprise et multi-locataires
Un hôtel au moment de l'enregistrement, un service hospitalier avec des dispositifs médicaux et un centre commercial un samedi ne partagent pas le même profil de risque. Ils peuvent partager un serveur RADIUS cloud, à condition que chaque population dispose de sa propre politique et que le réseau applique la séparation après l'authentification. L'erreur consiste à supposer qu'une connexion réussie équivaut à un réseau segmenté.
Les données de l'enquête gouvernementale indiquent que 85 % des grandes entreprises britanniques maintenaient des réseaux WiFi séparés pour le personnel et les visiteurs, contre 93 % auparavant, dans le chapitre sur les contrôles de sécurité réseau du Cyber Security Breaches Survey 2025. La séparation n'est pas un problème résolu, même pour les grandes organisations. Le RADIUS cloud doit donc être combiné avec des VLAN dynamiques ou l'application de politiques afin d'offrir une véritable segmentation, et pas seulement une meilleure authentification.
Ce dont les différents sites ont réellement besoin
Dans l'hôtellerie, les clients s'authentifient à leur arrivée, les appareils du personnel sont vérifiés par rapport à l'annuaire, et les terminaux de paiement se trouvent dans un segment restreint qui ne peut voir ni l'un ni l'autre. Dans le secteur de la santé, le personnel clinique, les brancardiers, les patients et les équipements médicaux coexistent, et certains de ces équipements ne prendront jamais en charge les certificats. La politique doit refléter cette réalité au lieu d'imposer un modèle unique à chaque appareil.
Les chaînes de magasins de détail sont confrontées à un problème d'échelle plutôt qu'à un problème de complexité dans chaque point de vente. Le siège souhaite un accès du personnel et une séparation des invités constants dans chaque filiale sans expédier de serveurs sur chaque site. Les hubs de transport ajoutent la gestion de l'itinérance, où un usager s'attend à ce que la connexion enregistrée dans une gare fonctionne dans la suivante. Un service centralisé répond à ces deux besoins car la stratégie réseau suit l'identité.
Les bâtiments multi-occupants nécessitent un isolement dès la conception
Les résidents d'immeubles en location gérée ou de logements étudiants s'attendent à un WiFi comme à la maison, mais les appareils de chaque foyer doivent rester invisibles pour les voisins. Cela nécessite des politiques par locataire, des clés individuelles pour les appareils anciens et un accès pour le personnel qui n'empiète pas sur les réseaux des résidents. Un guide du WiFi multi-locataires pour réseaux résidents isolés mérite d'être consulté en parallèle de votre architecture RADIUS, car l'authentification n'est utile que si la séparation sous-jacente des locataires est solide.
Avant le déploiement, cartographiez chaque classe d'équipement présente, et pas seulement la liste idéale du registre des actifs. Le personnel, les invités, les prestataires, l'IoT, les caisses, les scanners et la vieille imprimante de la comptabilité doivent tous suivre un parcours défini. Les équipements non anticipés deviennent l'exception qui fragilise la politique globale.
Meilleures pratiques pour la mise en œuvre et l'exploitation
La plupart des problèmes de RADIUS cloud ne sont pas des problèmes de protocole. Ce sont des surprises opérationnelles que personne n'a testées, comme un compte révoqué qui continue de fonctionner, un site qui perd son accès Internet ou une connexion d'urgence qui ne laisse aucune trace d'audit. Planifiez ces cas de figure avant la mise en service du premier site, pas pendant la première panne.
L'enquête 2025 du gouvernement britannique sur les violations de la cybersécurité a révélé que 43 % des entreprises ont signalé une violation ou une attaque au cours des 12 derniers mois, mais seules 31 % ont réalisé des évaluations formelles des risques cyber, comme l'indiquent les résultats de l'enquête 2025 à 2026 sur les violations de la cybersécurité. Cet écart explique pourquoi vous avez besoin de réponses explicites concernant les pannes de fournisseur, l'indisponibilité du fournisseur d'identité et la perte de connectivité, ainsi qu'un accès d'urgence audité.
Définir le comportement en cas de défaillance par SSID
Déterminez par écrit où l'authentification échoue en mode fermé (fail closed) et où un basculement restreint est acceptable. Les SSID du personnel privilégié et les segments sensibles doivent échouer en mode fermé, car un accès ouvert lors d'une panne va à l'encontre du principe même du 802.1X. Les services essentiels au fonctionnement peuvent justifier un basculement strictement encadré et limité dans le temps, mais celui-ci doit déclencher une alerte, être journalisé et révisé.
- Pilotez un site et un SSID : Validez l'authentification, l'attribution de VLAN et la journalisation avec des appareils réels, y compris votre matériel pris en charge le plus ancien.
- Provoquez des pannes volontaires : Désactivez un compte de test, révoquez un certificat et simulez la perte du point d'accès principal, puis mesurez l'impact sur l'expérience utilisateur.
- Mesurez la vitesse de révocation : Chronométrez le temps pendant lequel un compte Microsoft Entra ID ou Okta désactivé conserve son accès au réseau, puis enregistrez le résultat dans la documentation opérationnelle.
- Testez la stratégie de sortie : Confirmez que vous pouvez exporter la configuration et les journaux, puis rediriger les points d'accès vers un autre service sans avoir à reconfigurer les politiques de mémoire.
Gérez-le comme une infrastructure critique
Surveillez les taux de réussite et d'échec d'authentification, l'état des points de terminaison et les pics inhabituels par site. Examinez les journaux à la recherche d'échecs répétés provenant d'un seul appareil, car il s'agit souvent d'une mauvaise configuration, d'un certificat expiré ou d'une tentative de sondage de votre réseau. Négociez la rétention des journaux, les exigences de résidence des données au Royaume-Uni et les délais de réponse du support dans le contrat, et non lors d'un simple appel commercial.
Ne mesurez pas le succès au simple fait que le protocole 802.1X soit activé. Mesurez si l'isolation fonctionne, si la révocation est rapide et si un site continue de fonctionner de manière dégradée mais prévisible en cas de perte de connectivité.
Évaluez chaque année le risque lié aux fournisseurs, y compris les sous-traitants ultérieurs et l'origine des accès de support. Conservez une procédure d'exploitation courte qu'un ingénieur d'astreinte peut appliquer la nuit sans l'équipe projet. Si cette procédure n'existe pas, vous ne disposez pas encore d'un modèle opérationnel.
Points clés et prochaines étapes
Un serveur RADIUS cloud prend tout son sens lorsque l'identité réside déjà dans le cloud, que vous gérez plusieurs sites ou que votre équipe ne peut pas exploiter une paire sur site résiliente selon des normes élevées. Il élimine la maintenance du serveur et centralise les politiques. Il ne vous décharge pas de votre responsabilité en matière de segmentation, de révocation, de journalisation ou de planification des pannes.
Elle ne constitue pas non plus une segmentation à elle seule. L'authentification détermine l'identité revendiquée par un équipement. Les VLAN dynamiques, les politiques basées sur les rôles et les règles de moindre privilège définissent ce à quoi cet équipement peut accéder - et vous avez besoin que ces deux aspects fonctionnent de concert.
Une courte liste de contrôle d'évaluation
- Adéquation de l'identité : Intégration native avec votre annuaire, et comportement éprouvé lors des arrivées, changements de poste et départs d'employés.
- Gestion des certificats : Délivrance, renouvellement et révocation gérés que votre parc d'équipements peut prendre en charge.
- Comportement en cas de défaillance : Blocage des accès par défaut pour les SSID sensibles, avec un mode secours restreint, journalisé et limité dans le temps.
- Preuves d'audit : Journaux exportables, résidence des données claire, administration basée sur les rôles et séparation stricte entre les clients.
- Sortie du service : Exportation des configurations et des journaux, afin que le changement de prestataire reste un projet gérable et non une reconstruction complète.
Commencez par un pilote sur un site ou un SSID, mesurez le taux de réussite des authentifications ainsi que la latence de révocation, et simulez des pannes d'intégration avant que les utilisateurs ne dépendent du service. Ne passez à l'échelle que lorsque ces résultats sont prévisibles. La prévisibilité est la marque d'une authentification réussie en production.
Purple fournit RADIUS-as-a-Service pour le WiFi invités, personnel et multi-locataires, s'intégrant avec Entra ID, Google Workspace et Okta afin que vous puissiez retirer vos serveurs RADIUS sur site et appliquer un accès uniforme basé sur l'identité sur l'ensemble de vos sites. Si vous planifiez un pilote ou remplacez une configuration NPS ou FreeRADIUS fragile, visitez Purple pour découvrir comment le RADIUS cloud géré, Passpoint et l'isolation par locataire fonctionnent avec votre parc Meraki, Aruba, Ruckus, Mist ou UniFi existant.
