Cloud RADIUS vs RADIUS sur site : guide de décision pour les équipes informatiques

PARTIE 1 - INTRODUCTION ET CONTEXTE Bienvenue dans ce briefing technique Purple. Je suis votre hôte, et nous abordons aujourd'hui une décision d'infrastructure essentielle pour les sites multi-établissements : le Cloud RADIUS face au RADIUS On-Premises. Si vous êtes directeur informatique ou architecte réseau et que vous gérez l'authentification pour un groupe hôtelier, une chaîne de magasins ou un grand site accueillant du public, ce briefing vous fournira le cadre d'action dont vous avez besoin pour prendre la bonne décision. Posons le contexte. Le protocole RADIUS - Remote Authentication Dial-In User Service - est le gardien de votre réseau. Chaque fois qu'un utilisateur invité se connecte à votre WiFi, ou qu'un employé se connecte au SSID de l'entreprise via le protocole 802.1X, RADIUS est le moteur qui vérifie ses identifiants par rapport à votre annuaire et autorise l'accès. Traditionnellement, cela impliquait d'empiler des serveurs physiques dans votre centre de données, d'installer FreeRADIUS ou un Network Policy Server propriétaire, et de gérer l'intégralité de la pile vous-même. Aujourd'hui, les services Cloud RADIUS offrent une alternative managée et distribuée à l'échelle mondiale. Mais quelle est la solution la plus adaptée à votre déploiement spécifique ? Examinons de plus près les compromis techniques. PARTIE 2 - ANALYSE TECHNIQUE APPROFONDIE Parlons tout d'abord d'architecture et de latence. Dans un déploiement on-premises, vos points d'accès communiquent directement avec un serveur RADIUS local. Pour un seul grand stade ou un hôpital indépendant, cela offre une latence extrêmement faible. Les demandes d'authentification transitent par le réseau LAN local - nous parlons ici d'allers-retours de l'ordre de la milliseconde. En revanche, si vous êtes une chaîne de magasins multi-sites, acheminer tout le trafic d'authentification vers un serveur on-premises centralisé introduit de la latence sur le réseau WAN et crée un point de défaillance unique. Si cette liaison WAN est coupée, vos sites distants ne peuvent plus du tout authentifier les utilisateurs. Le Cloud RADIUS inverse totalement ce modèle. L'infrastructure RADIUS est hébergée mondialement sur plusieurs zones de disponibilité. Lorsqu'un utilisateur se connecte sur un site distant, la demande est acheminée vers le nœud périphérique cloud le plus proche. Cela réduit considérablement la latence pour les déploiements distribués par rapport à un retour vers un serveur on-premises central. De plus, les fournisseurs de cloud intègrent la haute disponibilité par défaut. Si un nœud tombe en panne, le trafic bascule automatiquement vers le nœud le plus proche. Pour atteindre ce niveau de redondance en on-premises, vous devriez déployer des clusters actifs-actifs sur plusieurs centres de données géographiquement dispersés, ce qui exige des efforts d'ingénierie et des dépenses d'investissement considérables. Examinons maintenant les frais de maintenance et l'évolutivité. Un RADIUS sur site exige que votre équipe gère le système d'exploitation, applique les correctifs de sécurité, gère les certificats SSL et surveille l'état du serveur 24 heures sur 24. Lorsque vous devez monter en charge pour un événement majeur - par exemple, un stade accueillant un concert de 70 000 personnes - vous devez provisionner du matériel ou des machines virtuelles supplémentaires à l'avance. Il n'y a pas d'évolutivité élastique. Le Cloud RADIUS est fourni sous forme de service (SaaS). Le fournisseur gère automatiquement l'infrastructure sous-jacente, les correctifs et la mise à l'échelle. Vous gérez simplement les politiques et les intégrations via un tableau de bord web ou une API. Cela libère vos ingénieurs seniors de la maintenance de routine, leur permettant de se concentrer sur des initiatives stratégiques plutôt que de simplement maintenir les systèmes opérationnels. Parlons de l'intégration avec les fournisseurs d'identité. Si votre annuaire d'utilisateurs est déjà dans le cloud - en utilisant Microsoft Entra ID, Google Workspace ou Okta - une solution Cloud RADIUS est le choix naturel. Elle s'intègre de manière transparente via des API ou des connecteurs sécurisés. À l'inverse, si vous disposez d'un Active Directory sur site hérité qui ne peut pas être exposé à Internet pour des raisons de sécurité ou de conformité, un serveur RADIUS sur site peut être votre seule option viable. Il peut interroger directement l'AD local sans traverser le pare-feu, ce qui est particulièrement pertinent dans les environnements de santé ou les installations gouvernementales où la souveraineté des données est une exigence absolue. Abordons maintenant la question de la conformité. La norme PCI-DSS exige que les environnements contenant des données de titulaires de cartes utilisent une authentification forte. Le GDPR exige que les données personnelles - y compris les journaux d'authentification - soient traitées de manière appropriée. Les fournisseurs de Cloud RADIUS proposent généralement des certifications SOC 2 Type II, des accords de traitement des données conformes au GDPR et des options de résidence des données régionales. Le déploiement sur site vous donne un contrôle total sur l'emplacement de vos données, ce qui peut être avantageux dans les secteurs hautement réglementés. Cependant, cela signifie également que la charge de la conformité repose entièrement sur votre équipe. Examinons de plus près l'architecture technique de chaque approche, car la compréhension des mécanismes vous aidera à prendre une décision plus éclairée. Dans un déploiement RADIUS traditionnel sur site, vous disposez généralement d'un ou plusieurs serveurs exécutant soit le Network Policy Server de Microsoft - communément appelé NPS - soit la plateforme open source FreeRADIUS. Ces serveurs se trouvent à l'intérieur du périmètre de votre réseau et communiquent avec vos points d'accès via UDP, généralement sur le port 1812 pour l'authentification et le port 1813 pour la comptabilisation. Le secret partagé entre le point d'accès et le serveur RADIUS est un élément de sécurité essentiel - il doit être long, aléatoire et renouvelé périodiquement. FreeRADIUS est le serveur RADIUS le plus déployé au monde, gérant l'authentification de centaines de millions d'utilisateurs à l'échelle mondiale. Il est hautement configurable, prend en charge une vaste gamme de méthodes EAP et peut s'intégrer à pratiquement n'importe quel annuaire back-end. Cependant, cette flexibilité a un coût : elle nécessite une administration qualifiée. Une mauvaise configuration est une source courante d'échecs d'authentification, et le débogage des journaux de FreeRADIUS requiert de l'expérience. Les plateformes de RADIUS-as-a-Service dans le cloud masquent toute cette complexité. Sous le capot, elles exécutent une infrastructure RADIUS distribuée sur plusieurs régions cloud, mais vous interagissez avec elles via une interface web claire ou une API. Vous définissez vos politiques d'authentification - quels SSID correspondent à quels groupes d'utilisateurs, quelles méthodes EAP sont autorisées, comment gérer les appareils inconnus - et la plateforme s'occupe du reste. Un domaine dans lequel le RADIUS sur site conserve un net avantage est celui des environnements ayant des exigences de débit d'authentification très élevées combinées à des budgets de latence stricts. Prenons l'exemple d'un grand hub de transport - un aéroport ou une gare ferroviaire - où des milliers d'appareils tentent de s'authentifier simultanément à l'arrivée des passagers. Dans ce scénario, un cluster RADIUS local peut traiter les demandes d'authentification en moins d'une milliseconde, tandis qu'une demande vers un RADIUS cloud doit traverser internet pour l'aller et le retour, ce qui ajoute entre 5 et 50 millisecondes selon le nœud périphérique le plus proche du fournisseur. PARTIE 3 - RECOMMANDATIONS DE MISE EN ŒUVRE ET PIÈGES À ÉVITER Laissez-moi vous présenter deux scénarios réels pour rendre cela concret. Premier scénario : Un groupe hôtelier européen comptant 45 établissements répartis dans six pays. L'équipe informatique est centralisée, avec seulement trois ingénieurs réseau pour gérer l'ensemble du parc. Ils exécutaient FreeRADIUS sur des machines virtuelles dans chaque établissement - soit 45 instances distinctes à corriger, surveiller et maintenir. Lorsqu'un certificat a expiré dans un établissement, cela a provoqué une panne complète du WiFi invité lors d'une conférence majeure. Ils ont migré vers un service de RADIUS cloud, centralisant la gestion des politiques et éliminant la maintenance par site. L'équipe de trois ingénieurs a récupéré environ 40 pour cent du temps qu'elle consacrait auparavant à la maintenance de RADIUS. Deuxième scénario : Un stade national de sport de 68 000 places. L'équipe informatique a des exigences strictes en matière de souveraineté des données - tous les journaux d'authentification doivent rester sur le sol britannique. Ils ont déployé un double cluster RADIUS sur site en configuration actif-actif, avec un cluster secondaire dans un centre de colocalisation situé à 30 kilomètres. Cela leur a permis d'obtenir un contrôle local, une authentification de l'ordre de la milliseconde et la capacité de gérer les pics de trafic sans dépendre de la connectivité internet. Lors du déploiement d'un RADIUS cloud, le piège le plus courant consiste à ignorer la connexion internet locale du site. Le RADIUS cloud dépend entièrement de la liaison WAN. Pour atténuer ce risque, mettez en œuvre une stratégie de résilience locale - en mettant en cache les identifiants sur le contrôleur réseau local pour le personnel critique, ou en utilisant le SD-WAN pour garantir une haute disponibilité de la liaison internet. Pour les déploiements sur site, le plus grand risque opérationnel est la gestion des certificats. Si le certificat de votre serveur RADIUS sur site expire, chaque appareil client rejettera la connexion, ce qui entraînera une panne complète de l'authentification. Les fournisseurs de Cloud RADIUS automatisent la rotation des certificats, éliminant ainsi totalement ce risque. PARTIE 4 - QUESTIONS-RÉPONSES RAPIDES Question un : Le Cloud RADIUS prend-il en charge le MAC Authentication Bypass pour les appareils sans écran comme les imprimantes et les capteurs IoT ? Réponse : Oui. La plupart des plateformes Cloud RADIUS d'entreprise prennent en charge le MAB. Vous pouvez gérer les listes d'autorisation d'adresses MAC via leur tableau de bord ou leur API, ce qui facilite grandement la gestion des appareils IoT sur des centaines de sites. Question deux : Comment se compare le coût total de possession sur cinq ans ? Réponse : Les solutions sur site sont lourdes en CapEx - matériel, licences, alimentation, refroidissement et temps d'ingénierie. Le Cloud RADIUS relève de l'OpEx - généralement facturé par utilisateur ou par appareil sur une base annuelle. Pour les déploiements multi-sites en croissance rapide, l'OpEx prévisible du cloud est généralement plus rentable. Les organisations comptant plus de 10 sites et moins de 5 ingénieurs réseau constatent presque toujours un ROI positif du cloud en moins de 18 mois. Question trois : Peut-on utiliser un modèle hybride ? Réponse : Absolument. Le Cloud RADIUS pour les SSID invités et IoT, et le sur-site pour le SSID d'entreprise s'authentifiant auprès de l'Active Directory interne. Purple WiFi prend en charge ce modèle hybride de manière native. Question quatre : Que se passe-t-il en cas de panne du fournisseur cloud ? Réponse : Les fournisseurs de Cloud RADIUS réputés publient des SLA de 99,99 % de temps de disponibilité, soutenus par une redondance multi-région. Configurez toujours vos points d'accès avec une politique de secours - soit un accès ouvert à un VLAN restreint, soit des identifiants mis en cache localement - pour gérer ce scénario de manière fluide. PARTIE 5 - RÉSUMÉ ET PROCHAINES ÉTAPES Pour résumer le cadre décisionnel clé. Choisissez le RADIUS sur site lorsque vous disposez d'un seul site de grande taille avec des exigences strictes en matière de souveraineté des données, d'un environnement de sécurité isolé physiquement, ou d'annuaires locaux existants qui ne peuvent pas être connectés au cloud. Choisissez le Cloud RADIUS lorsque vous disposez d'une empreinte multi-sites distribuée, de fournisseurs d'identité cloud-native tels que Okta ou Azure AD, d'une petite équipe informatique centrale, ou lorsque vous avez besoin d'un déploiement rapide sur de nouveaux sites sans les délais d'approvisionnement du matériel. En fin de compte : pour la plupart des opérateurs de sites multi-sites aujourd'hui, le Cloud RADIUS est le choix opérationnel supérieur. L'argument de la latence pour le sur-site a été largement neutralisé par l'infrastructure cloud mondialement distribuée. Avant de prendre votre décision, auditez trois éléments : votre fournisseur d'identité actuel et sa nature cloud-native, la résilience de votre réseau WAN sur chaque site, et la capacité de votre équipe à gérer la maintenance continue. Ces trois facteurs vous indiqueront quelle voie est la bonne pour votre organisation. Merci d'avoir participé à ce briefing technique Purple. Pour plus d'analyses approfondies sur l'architecture WiFi d'entreprise, visitez notre bibliothèque de guides sur Purple.ai.