Saltar al contenido principal

Las ventajas de seguridad de RADIUS as a Service para plantillas híbridas

Esta guía técnica de referencia explica cómo RADIUS as a Service protege el acceso a la red para plantillas híbridas en centros distribuidos. Abarca la arquitectura, las ventajas de seguridad y los pasos de implementación para sustituir la infraestructura RADIUS local por un servicio de autenticación gestionado en la nube. Diseñada para responsables de TI y arquitectos de redes de hoteles, cadenas de tiendas, estadios y organismos del sector público, esta guía aporta los argumentos necesarios para evaluar y ejecutar la migración a un RADIUS en la nube este trimestre.

📖 9 min de lectura📝 2,077 palabras🔧 2 ejemplos prácticos3 preguntas de práctica📚 9 definiciones clave

Escuchar esta guía

Ver transcripción del podcast
Le damos la bienvenida a esta sesión técnica de Purple. Soy su anfitrión y hoy analizaremos un cambio crítico en la arquitectura de redes empresariales: la migración de servidores RADIUS locales a RADIUS as a Service. Si gestiona el departamento de TI de un grupo hotelero, una cadena minorista, un estadio o cualquier gran recinto público, sabrá que proteger el acceso a la red para una plantilla híbrida ya no es una preocupación secundaria. Es un aspecto central para su seguridad operativa, su cumplimiento normativo y, sinceramente, para su tranquilidad. Hoy abordaremos cinco áreas. Primero, el contexto: por qué la infraestructura RADIUS local tradicional tiene dificultades para seguir el ritmo del trabajo híbrido. Segundo, la arquitectura técnica de RADIUS as a Service y cómo funciona realmente. Tercero, los beneficios específicos de seguridad que obtendrá. Cuarto, una guía práctica de implementación y los errores que debe evitar. Y quinto, una sección rápida de preguntas y respuestas que cubre las dudas que escuchamos con más frecuencia de los responsables de TI y arquitectos de red. Comencemos con el contexto. Durante dos décadas, la autenticación 802.1X ha dependido de servidores físicos que ejecutaban FreeRADIUS en Linux, Microsoft Network Policy Server en Windows o Cisco Identity Services Engine en hardware dedicado. Estos sistemas funcionaban. Siguen funcionando. Pero requieren una atención constante. Había que parchear sistemas operativos, gestionar cadenas de certificados, configurar la alta disponibilidad manualmente y crear redundancia en múltiples servidores. En un mundo donde los trabajadores se mueven constantemente entre la oficina, ubicaciones remotas, habitaciones de hotel y las sedes de los clientes, esa infraestructura estática y local se convierte en un verdadero inconveniente. El problema se ve agravado por la migración a los proveedores de identidad en la nube. Microsoft NPS, por ejemplo, está estrechamente vinculado a Active Directory. No tiene soporte nativo para Microsoft Entra ID, Google Workspace o Okta. Si su organización ha migrado a cualquiera de estos directorios en la nube, se enfrenta a una difícil elección: mantener un Active Directory paralelo solo para dar soporte a su servidor RADIUS o invertir un esfuerzo de ingeniería considerable en integraciones personalizadas. Ninguna de las dos opciones es atractiva. RADIUS as a Service cambia la ecuación por completo. Traslada el motor de autenticación a la nube. Usted ya no gestiona la infraestructura, sino las políticas. El proveedor se encarga de los servidores, los parches, la alta disponibilidad y las integraciones. Usted define quién tiene acceso a qué y el servicio lo aplica. Pasemos ahora a la arquitectura técnica. RADIUS, que significa Remote Authentication Dial-In User Service (Servicio de autenticación de usuarios de acceso telefónico de forma remota), es el protocolo definido en RFC 2865. Proporciona servicios centralizados de autenticación, autorización y contabilidad (lo que llamamos AAA) para el acceso a la red. Cuando un dispositivo se conecta a su red WiFi, el punto de acceso actúa como un cliente RADIUS. Reenvía la solicitud de autenticación al servidor RADIUS. El servidor valida las credenciales con su almacén de identidades y devuelve un Access-Accept o un Access-Reject. En un despliegue de RADIUS en la nube, el proveedor aloja el servidor en varios centros de datos distribuidos geográficamente. Sus puntos de acceso, ya sean Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist o Ubiquiti UniFi, apuntan a los endpoints de RADIUS en la nube a través de túneles seguros y cifrados. El flujo de autenticación es idéntico al de un RADIUS local desde la perspectiva del punto de acceso. La diferencia es que el propio servidor es gestionado, parcheado y escalado por el proveedor. La mejora de seguridad más importante en los despliegues modernos de RADIUS en la nube es la transición a EAP-TLS, que significa Protocolo de Autenticación Extensible con Seguridad en la Capa de Transporte. EAP-TLS está definido en RFC 5216 y proporciona autenticación mutua mediante certificados digitales. Tanto el dispositivo cliente como el servidor RADIUS se presentan certificados mutuamente. Esto elimina por completo las contraseñas del proceso de autenticación. Un certificado está vinculado criptográficamente al dispositivo y no se puede pescar (phishing), adivinar ni robar de la forma en que se puede hacer con una contraseña. La segunda capacidad de seguridad principal es la asignación dinámica de VLAN. Cuando el servidor RADIUS autentica a un usuario, no se limita a conceder o denegar el acceso. También le indica al punto de acceso en qué LAN virtual debe colocar el dispositivo, en función de la identidad y el rol del usuario. Un recepcionista de hotel se autentica y se le coloca en la VLAN de recepción con acceso al sistema de gestión hotelera. Un miembro del personal de limpieza se coloca en una VLAN restringida con acceso exclusivo a internet. Un dispositivo de invitado se coloca en la VLAN de invitados, completamente aislado de todos los recursos corporativos. Un dispositivo IoT, como una cámara de seguridad, se coloca en una VLAN de IoT dedicada. Esta segmentación de red basada en la identidad es fundamental para un modelo de seguridad Zero Trust. Ya no se confía en un dispositivo por el hecho de haberse conectado a un SSID concreto. Se concede el acceso en función de una identidad verificada y se limita ese acceso únicamente a lo que esa identidad requiere. Este es el principio de mínimo privilegio aplicado al acceso a la red. Abordemos también el aspecto del cumplimiento normativo. PCI DSS versión 4.0 exige controles de acceso estrictos para cualquier red que esté en contacto con datos de titulares de tarjetas. El Requisito 8 exige una autenticación única para todos los usuarios. El Requisito 1 exige la segmentación de la red. RADIUS en la nube, con EAP-TLS y asignación dinámica de VLAN, cumple directamente con ambos requisitos. Para el GDPR, el registro de auditoría centralizado que proporciona RADIUS en la nube le ofrece un historial completo de quién accedió a la red, cuándo y desde qué dispositivo. Esa pista de auditoría es esencial para demostrar el cumplimiento normativo y para investigar cualquier posible brecha de datos. Ahora permítame guiarle a través de dos escenarios de implementación concretos que ilustran cómo funciona esto en la práctica. El primer escenario es un grupo hotelero. Imagine un hotel de doscientas habitaciones. Actualmente utilizan una clave compartida común para el WiFi de su personal. Todos los miembros del equipo, desde el director general hasta el personal de limpieza de temporada, utilizan la misma contraseña. Cuando un empleado de temporada se marcha al final del verano, la contraseña rara vez se cambia porque hacerlo implica actualizar todos los dispositivos del establecimiento. Esta es una vulnerabilidad de seguridad de manual. La solución es implementar RADIUS como servicio integrado con Microsoft Entra ID. El hotel configura sus puntos de acceso Cisco Meraki para utilizar WPA3-Enterprise con 802.1X. Cada miembro del personal se autentica utilizando sus credenciales de Entra ID. El servidor RADIUS lee su rol desde el directorio y los asigna a la VLAN correspondiente de forma dinámica. El personal de limpieza se asigna a la VLAN 10, con acceso exclusivo al sistema de gestión de tareas de limpieza. El personal de recepción se asigna a la VLAN 20, con acceso al sistema de gestión del establecimiento. La dirección se asigna a la VLAN 30, con un acceso más amplio. Cuando finaliza el contrato de un empleado de temporada, su cuenta de Entra ID se deshabilita y su acceso WiFi se revoca al instante en todos los puntos de acceso del establecimiento, sin necesidad de cambiar contraseñas. El segundo escenario es una cadena minorista nacional. Imagine una cadena con cuatrocientas tiendas que actualmente gestiona cuatrocientas instancias independientes de FreeRADIUS en servidores locales de cada tienda. Cada servidor requiere parches, supervisión y mantenimiento individuales. Cuando se detecta una vulnerabilidad crítica, el equipo de seguridad debe parchear cuatrocientos servidores, lo que a menudo lleva semanas y deja los establecimientos expuestos durante ese periodo. La solución es migrar a una única instancia de RADIUS como servicio. Las cuatrocientas tiendas dirigen sus puntos de acceso HPE Aruba a los mismos endpoints de RADIUS en la nube. Los terminales de punto de venta se autentican mediante EAP-TLS con certificados de máquina distribuidos a través de la plataforma MDM. El servidor RADIUS los asigna a una VLAN compatible con PCI, aislada de todo el demás tráfico de red. El personal de la tienda utiliza un SSID independiente autenticado a través de Okta, que los ubica en una VLAN para el personal general. Ahora, el equipo de seguridad gestiona un único conjunto de políticas desde un único panel de control. Cuando se detecta una vulnerabilidad, el proveedor parchea la infraestructura. El equipo de seguridad de la cadena minorista se centra en la política, no en la infraestructura física. Veamos ahora las recomendaciones de implementación y los errores que se deben evitar. El primer paso consiste en conectar el servicio RADIUS en la nube a su proveedor de identidad. En el caso de Microsoft Entra ID o Google Workspace, esto suele implicar la autorización de una aplicación empresarial. Asocie sus grupos de directorio a políticas de red específicas. Defina detenidamente su taxonomía de roles antes de empezar; hacerlo bien desde el principio le evitará tener que repetir gran parte del trabajo más adelante. El segundo paso es configurar el despliegue de certificados para dispositivos corporativos. Configure su plataforma MDM para enviar certificados de cliente a los dispositivos gestionados. Esto permite la autenticación EAP-TLS y elimina por completo las contraseñas de la ecuación. Para los dispositivos que no gestione, puede utilizar PEAP con una credencial de usuario como alternativa, pero EAP-TLS debería ser el objetivo para todos los dispositivos propiedad de la empresa. El tercer paso es configurar el hardware de red. Añada las direcciones IP de RADIUS en la nube y los secretos compartidos a sus controladores inalámbricos o puntos de acceso. Configure siempre tanto el extremo principal como el secundario para aprovechar la redundancia integrada del proveedor. El cuarto paso es definir sus políticas de VLAN. Cuando el servidor RADIUS autentica a un usuario, devuelve el ID de VLAN correcto al punto de acceso. Planifique esto antes de realizar el despliegue. Sepa en qué VLAN debe acabar cada rol de usuario y pruébelo a fondo antes de lanzarlo a producción. Ahora, los errores comunes. El fallo más habitual es un cortafuegos mal configurado que bloquea los puertos UDP 1812 y 1813, que son los puertos de autenticación y contabilidad de RADIUS. Verifique siempre la conectividad entre sus puntos de acceso y los extremos de RADIUS en la nube antes de la puesta en marcha. El segundo error es una cadena de confianza de certificados rota. Si sus dispositivos cliente no confían en la Entidad de Certificación Raíz que emitió el certificado del servidor RADIUS, rechazarán silenciosamente la conexión. Esto puede parecer una caída de la red cuando en realidad es un problema de configuración de la PKI. Pasemos a las preguntas rápidas. Pregunta uno: ¿Qué ocurre si se cae nuestra conexión a internet? Si la sede se queda sin internet, no podrá comunicarse con el RADIUS en la nube. No obstante, si la sede no tiene internet, los usuarios tampoco podrán acceder a las aplicaciones en la nube de todos modos. Para los recursos locales de misión crítica, algunos puntos de acceso ofrecen modos de supervivencia local. Pero la dependencia principal es su enlace WAN, lo cual se aplica a casi cualquier servicio SaaS que utilice su organización. Pregunta dos: ¿Cumple el RADIUS en la nube con el GDPR y PCI DSS? Sí. La autenticación centralizada con transporte cifrado favorece un sólido cumplimiento normativo. Los registros de auditoría satisfacen los requisitos de PCI DSS, y los estrictos controles de acceso respaldan los principios de minimización de datos y limitación de acceso del GDPR. Pregunta tres: ¿Funciona esto con nuestro hardware actual? Sí. RADIUS es un protocolo estándar definido en RFC 2865. Si su hardware es compatible con 802.1X, y todos los equipos empresariales de Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet lo son, funcionará con cualquier RADIUS as a Service que cumpla con los estándares. Para resumir los puntos clave. En primer lugar, RADIUS as a Service sustituye los servidores locales por una plataforma en la nube gestionada, lo que reduce el gasto de capital y los costes de mantenimiento. En segundo lugar, cloud RADIUS se integra de forma nativa con Microsoft Entra ID, Okta y Google Workspace, eliminando la necesidad de un middleware complejo. En tercer lugar, permite la asignación dinámica de VLAN, garantizando que los usuarios y dispositivos accedan al segmento de red correcto en función de su identidad verificada. En cuarto lugar, la transición a EAP-TLS elimina el riesgo de robo de contraseñas y ataques de phishing en su red. En quinto lugar, la gestión centralizada en la nube garantiza políticas de seguridad coherentes en cientos de ubicaciones físicas distribuidas. En sexto lugar, los proveedores se encargan de los parches de seguridad y de la alta disponibilidad. Y en séptimo lugar, cloud RADIUS facilita el cumplimiento de PCI DSS y GDPR al imponer controles de acceso estrictos basados en la identidad con un registro de auditoría completo. Su siguiente paso es evaluar su infraestructura RADIUS actual. Calcule el coste real de propiedad, incluyendo las licencias, los ciclos de renovación de hardware y el tiempo de ingeniería dedicado al mantenimiento. A continuación, realice una prueba de concepto con un proveedor de cloud RADIUS. Es muy probable que compruebe que el despliegue requiere horas, no semanas. Gracias por su atención. Proteja sus redes, segmente su tráfico y deje de gestionar servidores que no necesita tener en propiedad.

📚 Parte de nuestra serie principal: Enterprise WiFi Security Guide

header_image.png

कार्यकारी सारांश

हायब्रिड वर्कफोर्सकडे झालेल्या बदलावामुळे पारंपारिक नेटवर्क सुरक्षेमधील एक मूलभूत कमकुवतपणा समोर आला आहे: ऑन-प्रिमाइसेस RADIUS सर्व्हर्स अशा जगासाठी डिझाइन केले गेले होते जेथे कर्मचारी एकाच इमारतीमध्ये बसून एकाच नेटवर्कशी कनेक्ट होत असत. ते जग आता राहिलेले नाही. आज, तुमचे कर्मचारी हॉटेलच्या खोल्या, रिटेल फ्लोर्स, रिमोट ऑफिस आणि इव्हेंटच्या ठिकाणांवरून ऑथेंटिकेट करतात. तुमचे आयडेंटिटी प्रोव्हाइडर्स क्लाउडमध्ये आहेत. तुमचे ऍक्सेस पॉइंट्स शेकडो ठिकाणी पसरलेले आहेत. तरीही अनेक संस्था अजूनही फिजिकल RADIUS सर्व्हर्सवर अवलंबून आहेत ज्यांना मॅन्युअल पॅचिंगची आवश्यकता असते, जे Microsoft Entra ID किंवा Google Workspace सह नेटिव्हली इंटिग्रेट होऊ शकत नाहीत आणि हार्डवेअर खराब झाल्यावर कोणतीही पूर्वकल्पना न देता बंद पडतात.

RADIUS as a Service या इन्फ्रास्ट्रक्चरची जागा क्लाउड-नेटिव्ह ऑथेंटिकेशन इंजिनने घेते. तुम्ही तुमचे ऍक्सेस पॉइंट्स क्लाउड एंडपॉइंट्सकडे निर्देशित करता. प्रोव्हाइडर सर्व्हर्स, पॅचिंग आणि हाय अवेलेबिलिटी व्यवस्थापित करतो. तुम्ही पॉलिसी व्यवस्थापित करता. हॉस्पिटॅलिटी ग्रुप्स, रिटेल चेन्स आणि सार्वजनिक ठिकाणांमधील IT टीम्ससाठी, हा बदल हार्डवेअर ओव्हरहेड काढून टाकतो, आयडेंटिटी-आधारित नेटवर्क सेगमेंटेशन लागू करतो आणि PCI DSS आणि GDPR साठी आवश्यक असणारा ऑडिट ट्रेल प्रदान करतो.


तांत्रिक सखोल विश्लेषण

ऑन-प्रिमाइसेस RADIUS का संघर्ष करत आहे

RFC 2865 मध्ये परिभाषित केलेले RADIUS, नेटवर्क ऍक्सेससाठी केंद्रीकृत ऑथेंटिकेशन, ऑथरायझेशन आणि अकाउंटिंग (AAA) प्रदान करते. WPA2-Enterprise किंवा WPA3-Enterprise WiFi चालवणारी प्रत्येक संस्था यावर अवलंबून असते. हा प्रोटोकॉल स्वतःच मजबूत आहे. समस्या त्याच्याभोवती विकसित झालेल्या इन्फ्रास्ट्रक्चर मॉडेलमध्ये आहे.

लिनक्सवरील FreeRADIUS उपयोजित करणे, सुरक्षित करणे आणि राखणे यासाठी मोठ्या कौशल्याची आवश्यकता असते. Microsoft Network Policy Server (NPS) हे Active Directory शी घट्ट जोडलेले आहे आणि त्यात Microsoft Entra ID, Okta, किंवा Google Workspace साठी कोणतेही नेटिव्ह सपोर्ट नाही. Cisco Identity Services Engine (ISE) एंटरप्राइझ-दर्जाची पॉलिसी वैशिष्ट्ये प्रदान करते परंतु यासाठी समर्पित हार्डवेअर, गुंतागुंतीचे लायसन्सिंग आणि ते ऑपरेट करण्यासाठी तज्ञ टीमची आवश्यकता असते. या तिन्हींसाठी तुम्हाला मॅन्युअली हाय अवेलेबिलिटी तयार करावी आणि राखली पाहिजे, सामान्यतः डेटाबेस रेप्लिकेशनसह दोन सर्व्हर्स आणि त्यांच्या समोर लोड बॅलन्सर चालवून.

स्थिर Active Directory असलेल्या सिंगल-साइट संस्थेसाठी, हे मॉडेल व्यवस्थापित करण्यायोग्य आहे. ५० प्रॉपर्टीज असलेल्या हॉटेल ग्रुपसाठी, ४०० स्टोअर्स असलेल्या रिटेल चेनसाठी किंवा विखुरलेला कॅम्पस असलेल्या युनिव्हर्सिटीसाठी, हे अशक्य बनते. तुम्ही एकतर RADIUS सर्व्हर्स केंद्रीकृत करता आणि रिमोट साईट्सवरून ऑथेंटिकेशन लेटन्सी स्वीकारता, किंवा तुम्ही प्रत्येक ठिकाणी सर्व्हर्स तैनात करता आणि त्यांचे वैयक्तिकरित्या व्यवस्थापन करता. दोन्हीपैकी कोणताही पर्याय स्केल होत नाही.

RADIUS as a Service ची आर्किटेक्चर

RADIUS as a Service हे RADIUS प्रोटोकॉलसाठी क्लाउड-आधारित डिलिव्हरी मॉडेल आहे. RFC 2865 आणि त्याच्या विस्तारांचे पालन करून प्रोटोकॉल स्वतः अपरिवर्तित राहतो. काय बदलते ते म्हणजे इन्फ्रास्ट्रक्चर कोण राखते. जेव्हा एखादे डिव्हाइस तुमच्या WiFi नेटवर्कशी कनेक्ट होते, तेव्हा ॲक्सेस पॉइंट (RADIUS क्लायंट) ऑथेंटिकेशन विनंती एका सुरक्षित, एन्क्रिप्टेड टनेलद्वारे क्लाउड RADIUS एंडपॉइंट्सकडे फॉरवर्ड करतो. क्लाउड सेवा तुमच्या आयडेंटिटी प्रोव्हाइडरद्वारे क्रेडेंशियल्सची पडताळणी करते आणि डायनॅमिक VLAN असाइनमेंट्स सारख्या पॉलिसी ॲट्रिब्युट्ससह Access-Accept किंवा Access-Reject मेसेज पाठवते. ॲक्सेस पॉइंटच्या दृष्टीकोनातून, ऑथेंटिकेशन फ्लो हा ऑन-प्रिमाइसेस RADIUS सारखाच असतो.

architecture_overview.png

क्लाउड प्रोव्हाइडर भौगोलिकदृष्ट्या वेगवेगळ्या ठिकाणी असलेल्या मल्टिपल डेटा सेंटर्समध्ये RADIUS सर्व्हर्स ऑपरेट करतो. फेलओव्हर स्वयंचलित असतो. जर एक एंडपॉइंट अनुपलब्ध झाला, तर ट्रॅफिक तुमच्या टीमच्या कोणत्याही हस्तक्षेपाशिवाय पुढच्या सक्रीय एंडपॉइंटकडे रूट केले जाते. मल्टिपल रीजन्समध्ये ऑफिसेस असलेल्या संस्थांसाठी, ऑथेंटिकेशन सर्वात जवळच्या क्लाउड एंडपॉइंटवर होते, ज्यामुळे भौगोलिक स्थान कोणतेही असले तरी लॅटन्सी कमी राहते.

IEEE 802.1X आणि EAP पद्धती

IEEE 802.1X हा पोर्ट-बेस्ड नेटवर्क ॲक्सेस कंट्रोल (NAC) चा स्टँडर्ड आहे. हे डिव्हाइसला IP ॲड्रेस मिळण्यापूर्वी आणि ट्रॅफिक पास करण्याची परवानगी मिळण्यापूर्वी ऑथेंटिकेट करण्यास भाग पाडते. 802.1X डिप्लॉयमेंटमध्ये RADIUS हा ऑथेंटिकेशन सर्व्हर असतो.

Extensible Authentication Protocol (EAP) क्रेडेंशियल्सची देवाणघेवाण कशी होते हे परिभाषित करते. क्लाउड RADIUS सर्व EAP पद्धतींना सपोर्ट करतो:

EAP पद्धत ऑथेंटिकेशन प्रकार सुरक्षा पातळी शिफारस केलेला वापर
EAP-TLS म्युच्युअल सर्टिफिकेट-बेस्ड सर्वोच्च MDM-व्यवस्थापित सर्टिफिकेट्स असलेली कॉर्पोरेट डिव्हाइसेस
PEAP-MSCHAPv2 युझरनेम आणि पासवर्ड मध्यम जुनी डिव्हाइसेस किंवा MDM शिवाय BYOD
EAP-TTLS टनेल्ड क्रेडेंशियल्स मध्यम मिश्रित एन्व्हायरमेंट्स
MAC Authentication Bypass डिव्हाइस MAC ॲड्रेस कमी IoT डिव्हाइसेस जे 802.1X ला सपोर्ट करू शकत नाहीत

RFC 5216 मध्ये परिभाषित केलेले EAP-TLS हे सर्वोत्तम मानले जाते. क्लायंट डिव्हाइस आणि RADIUS सर्व्हर दोन्ही एकमेकांना डिजिटल सर्टिफिकेट्स सादर करतात. हे म्युच्युअल ऑथेंटिकेशन नेटवर्क ॲक्सेस प्रक्रियेतून पासवर्डची गरज पूर्णपणे काढून टाकते. सर्टिफिकेट हे क्रिप्टोग्राफिक पद्धतीने डिव्हाइसशी जोडलेले असते आणि पासवर्डप्रमाणे ते फिशिंगद्वारे मिळवता येत नाही, त्याचा अंदाज लावता येत नाही किंवा ते चोरले जाऊ शकत नाही. क्रेडेंशियल-बेस्ड डेटा ब्रीचचा सामना केलेल्या संस्थांसाठी, ही सर्वात थेट तांत्रिक उपाययोजना आहे.

डायनॅमिक VLAN असाइनमेंट

ऑथेंटिकेशन व्यतिरिक्त, RADIUS सर्व्हर ऑथरायझेशन लागू करतो. जेव्हा ते कनेक्शन स्वीकारते, तेव्हा ते ॲक्सेस पॉइंटला पॉलिसी ॲट्रिब्युट्स परत पाठवते, ज्यामध्ये डिव्हाइसला असाइन करण्यासाठी VLAN ID समाविष्ट असतो. हे डायनॅमिक VLAN असाइनमेंट हे आयडेंटिटी-बेस्ड नेटवर्क्स सक्षम करणारे मुख्य मेकॅनिझम आहे.

हॉटेलमधील रिसेप्शनिस्ट प्रमाणीकरण करतो आणि मालमत्ता व्यवस्थापन प्रणालीच्या प्रवेशासह त्यांना फ्रंट-ऑफ-हाउस VLAN मध्ये ठेवले जाते. हाऊसकीपिंग कर्मचाऱ्याला केवळ इंटरनेटचा प्रवेश असलेल्या मर्यादित VLAN मध्ये ठेवले जाते. अतिथीच्या डिव्हाइसला कॉर्पोरेट संसाधनांपासून पूर्णपणे वेगळे असलेल्या Guest WiFi VLAN मध्ये ठेवले जाते. सुरक्षा कॅमेऱ्यासारखे एखादे IoT डिव्हाइस समर्पित IoT VLAN मध्ये ठेवले जाते. हे सर्व RADIUS सर्व्हरद्वारे सत्यापित केलेल्या ओळखीच्या आधारे स्वयंचलितपणे घडते, प्रत्येक डिव्हाइससाठी कोणत्याही मॅन्युअल VLAN कॉन्फिगरेशनशिवाय.

हे नेटवर्क प्रवेशासाठी लागू केलेले सर्वात कमी विशेषाधिकाराचे (least privilege) तत्त्व आहे. एखादे डिव्हाइस विशिष्ट SSID ला कनेक्ट झाले आहे म्हणून तुम्ही त्यावर विश्वास ठेवत नाही आहात. तुम्ही सत्यापित ओळखीच्या आधारे प्रवेश मंजूर करत आहात आणि तो प्रवेश केवळ त्या ओळखीसाठी आवश्यक असलेल्या गोष्टींपुरता मर्यादित करत आहात. हे अधिक व्यापक नेटवर्क प्रवेश नियंत्रण धोरणामध्ये कसे बसते याच्या सखोल माहितीसाठी, आमचे network access control systems वरील मार्गदर्शक पहा.

नेटिव्ह क्लाउड ओळख एकत्रीकरण (identity integration)

क्लाउड RADIUS चा सर्वात महत्त्वाचा ऑपरेशनल फायदा म्हणजे त्याचे आधुनिक ओळख प्रदात्यांसह (identity providers) असलेले नेटिव्ह एकत्रीकरण. क्लाउड RADIUS थेट Microsoft Entra ID, Okta आणि Google Workspace ला OIDC, SAML आणि LDAP यांसारख्या मानक प्रोटोकॉलद्वारे जोडतो. जेव्हा तुम्ही तुमच्या ओळख प्रदात्यामध्ये नवीन कर्मचारी समाविष्ट करता, तेव्हा ते त्वरित WiFi नेटवर्कवर प्रमाणीकृत होऊ शकतात. जेव्हा तुम्ही एखाद्या कर्मचाऱ्याला कामावरून कमी करता, तेव्हा तुम्ही डिरेक्टरीमध्ये त्यांचे खाते निष्क्रिय करता आणि त्यांचा WiFi प्रवेश प्रत्येक ठिकाणच्या प्रत्येक ॲक्सेस पॉइंटवर त्वरित रद्द केला जातो.

हे रिअल-टाइम सिंक्रोनाइझेशन एंटरप्राइझ WiFi मधील सर्वात कठीण सुरक्षा त्रुटींपैकी एक दूर करते: माजी कर्मचारी ज्यांच्याकडे अजूनही सामायिक केलेला PSK आहे किंवा ते निघून गेल्यावर त्यांचे RADIUS खाते मॅन्युअली हटवले गेले नव्हते. क्लाउड RADIUS आणि क्लाउड ओळख प्रदात्यासह, कर्मचाऱ्याला कमी करणे ही तात्काळ नेटवर्क-व्यापी प्रभावासह एकच क्रिया बनते.


अंमलबजावणी मार्गदर्शिका

पायरी १: तुमचे ओळख प्रदाता कनेक्ट करा

क्लाउड RADIUS सेवेला तुमच्या ओळख प्रदात्याशी कनेक्ट करा. Microsoft Entra ID किंवा Google Workspace साठी, यामध्ये सहसा OAuth द्वारे एंटरप्राइझ ॲप्लिकेशनला अधिकृत करणे किंवा LDAP कनेक्टर कॉन्फिगर करणे समाविष्ट असते. तुमच्या डिरेक्टरी गटांना विशिष्ट नेटवर्क धोरणांवर मॅप करा. तुम्ही सुरू करण्यापूर्वी तुमची भूमिका वर्गीकरण (role taxonomy) परिभाषित करा: कोणते गट कोणत्या VLAN वर मॅप होतात आणि प्रत्येक VLAN कडे कोणते प्रवेश अधिकार आहेत. सुरुवातीलाच हे योग्यरित्या केल्याने नंतरचे महत्त्वपूर्ण काम वाचते.

पायरी २: कॉर्पोरेट डिव्हाइसेससाठी प्रमाणपत्रे तैनात करा

कॉर्पोरेट-मालकीच्या डिव्हाइसेससाठी, डिव्हाइसेसवर क्लायंट प्रमाणपत्रे पाठवण्यासाठी तुमचे मोबाइल डिव्हाइस व्यवस्थापन (MDM) प्लॅटफॉर्म, जसे की Microsoft Intune किंवा Jamf कॉन्फिगर करा. हे EAP-TLS प्रमाणीकरण सक्षम करते. RADIUS सर्व्हरचे प्रमाणपत्र जारी करणाऱ्या रूट सर्टिफिकेट ऑथॉरिटी (CA) वर सर्व क्लायंट डिव्हाइसेसद्वारे विश्वास ठेवला गेला असल्याची खात्री करा. विश्वास नसलेली साखळी हे सुप्त प्रमाणीकरण अयशस्वी होण्याचे सर्वात सामान्य कारण आहे.

पायरी ३: तुमचे नेटवर्क हार्डवेअर कॉन्फिगर करा

तुमच्या वायरलेस कंट्रोलर किंवा ॲक्सेस पॉइंट्समध्ये क्लाउड RADIUS IP पत्ते आणि शेअर केलेले सिक्रेट्स जोडा. प्रदाताच्या अंगभूत रिडंडन्सीचा वापर करण्यासाठी नेहमी प्रायमरी आणि सेकंडरी दोन्ही एंडपॉइंट्स कॉन्फिगर करा. तुमच्या ॲक्सेस पॉइंट्सवरून क्लाउड RADIUS एंडपॉइंट्सकडे जाणाऱ्या UDP पोर्ट्स 1812 (ऑथेंटिकेशन) आणि 1813 (अकाउंटिंग) आउटबाउंड उघडे असल्याची खात्री करा. गो-लाइव्ह जाण्यापूर्वी याची पडताळणी करा. चुकीच्या पद्धतीने कॉन्फिगर केलेले फायरवॉल नियम हे डिप्लॉयमेंट अपयशाचे दुसरे सर्वात सामान्य कारण आहे.

क्लाउड RADIUS हे Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme आणि Fortinet सोबत काम करते. कॉन्फिगरेशनच्या पायऱ्या वेंडरनुसार बदलू शकतात, परंतु RADIUS प्रोटोकॉल प्रमाणित आहे, त्यामुळे मुख्य पॅरामीटर्स (सर्व्हर IP, शेअर केलेले सिक्रेट, ऑथेंटिकेशन पोर्ट) सुसंगत असतात.

पायरी 4: VLAN पॉलिसी परिभाषित करा

तुमच्या RADIUS पॉलिसी इंजिनमध्ये डायनॅमिक VLAN असाइनमेंट कॉन्फिगर करा. प्रत्येक वापरकर्ता भूमिका किंवा डिव्हाइस प्रकार एका विशिष्ट VLAN ID शी मॅप करा. प्रोडक्शनमध्ये रोल आउट करण्यापूर्वी प्रत्येक पॉलिसीची चाचणी घ्या. एक साधी चाचणी मॅट्रिक्स - प्रति भूमिका एक डिव्हाइस, प्रति भूमिका एक VLAN, प्लेसमेंटची पडताळणी करणे - बहुतांश कॉन्फिगरेशन त्रुटी वापरकर्त्यांवर परिणाम करण्यापूर्वीच पकडते.


सर्वोत्तम पद्धती

सर्व कॉर्पोरेट डिव्हाइसेससाठी EAP-TLS लागू करा. तुमच्या MDM रोलआउटला परवानगी मिळताच लवकरात लवकर PEAP-MSCHAPv2 वापरणे बंद करा. PEAP हा पासवर्डवर अवलंबून असतो, जे तडजोड केले जाऊ शकतात. EAP-TLS हा प्रमाणपत्रांवर अवलंबून असतो, ज्यांच्याशी तडजोड केली जाऊ शकत नाही.

प्रत्येक गोष्टीचे वर्गीकरण (segment) करा. कर्मचारी, पाहुणे आणि IoT डिव्हाइसेस कधीही एकाच सबनेटवर ठेवू नका. कठोर VLAN सीमा लागू करण्यासाठी RADIUS चा वापर करा. PCI DSS अंतर्गत पेमेंट कार्ड डेटा हाताळणाऱ्या किरकोळ विक्री (Retail) वातावरणासाठी आणि रुग्णांच्या डेटाचे रक्षण करणाऱ्या आरोग्य सेवा (Healthcare) वातावरणासाठी हे अत्यंत आवश्यक आहे.

WPA3-Enterprise शी संरेखित व्हा. WPA3-Enterprise, सध्याचा WiFi सुरक्षा मानक, यासाठी 802.1X ऑथेंटिकेशन आवश्यक आहे. तुमचे ॲक्सेस पॉइंट्स WPA3-Enterprise ला सपोर्ट करत असल्याची खात्री करा आणि कर्मचाऱ्यांच्या नेटवर्कसाठी ते किमान सुरक्षा मानक म्हणून कॉन्फिगर करा.

तुमच्या RADIUS लॉगचे नियमितपणे ऑडिट करा. क्लाउड RADIUS केंद्रीकृत ऑडिट लॉग प्रदान करते. ऑथेंटिकेशन अपयशांचे दर आठवड्याला पुनरावलोकन करा. एखाद्या विशिष्ट डिव्हाइस किंवा स्थानावरील अपयशांमध्ये अचानक झालेली वाढ ही चुकीच्या कॉन्फिगरेशनची किंवा संभाव्य हल्ल्याचे प्रारंभिक संकेत असते.

फेलओव्हर चाचणी घ्या. दर तिमाहीत किमान एकदा, प्रायमरी RADIUS एंडपॉइंट अपयशाचे सिम्युलेशन करा आणि सेकंडरी एंडपॉइंटद्वारे ऑथेंटिकेशन सुरू राहते याची पडताळणी करा. निकालाची नोंद करा. ही एक सोपी चाचणी आहे जी बहुतेक टीम्स गरजेची वेळ येईपर्यंत कधीही चालवत नाहीत.

सागरी किंवा दुर्गम ठिकाणांसह गुंतागुंतीच्या वातावरणात WiFi तैनात करणाऱ्या ठिकाणांसाठी, WAN अवलंबित्वाबद्दलच्या बाबींसाठी आमचे Starlink वर Captive Portal सेट करणे यावरील मार्गदर्शक पहा.


त्रुटी निवारण आणि जोखीम कमी करणे

ऑथेंटिकेशन टाइमआउट्स

डिव्हाइस प्रमाणित करण्यात अयशस्वी झाल्यास, प्रथम तुमचे ऍक्सेस पॉइंट्स आणि क्लाउड RADIUS एंडपॉइंट्स मधील कनेक्टिव्हिटी तपासा. UDP पोर्ट्स १८१२ आणि १८१३ आउटबाउंडसाठी उघडे आहेत याची पडताळणी करा. आधुनिक फायरवॉलवरील डीप पॅकेट इन्स्पेक्शन RADIUS पॅकेट्सना विलंब करू शकतात किंवा ड्रॉप करू शकतात. तुम्हाला टाईमआउट्स दिसल्यास, RADIUS एंडपॉइंट्सवरील UDP ट्रॅफिकचे इन्स्पेक्शन किंवा रेट-लिमिटिंग करू शकणाऱ्या नियमांसाठी तुमचे फायरवॉल धोरण तपासा.

सर्टिफिकेट ट्रस्ट चेन अयशस्वी होणे

जर तुम्ही EAP-TLS वापरत असाल, तर क्लायंट डिव्हाइसेस RADIUS सर्व्हर प्रमाणपत्र जारी करणाऱ्या रूट CA वर विश्वास ठेवतात याची खात्री करा. ट्रस्ट चेन तुटलेली असल्यास, मॅन-इन-द-मिडल हल्ला रोखण्यासाठी डिव्हाइस कनेक्शन सायलेंटली नाकारेल. हे कोणत्याही स्पष्ट त्रुटी संदेशाशिवाय कनेक्शन बिघाड म्हणून दर्शविते. EAP-TLS हँडशेक अयशस्वी झाल्याबद्दल RADIUS सर्व्हर लॉग तपासा. MDM द्वारे सर्व व्यवस्थापित डिव्हाइसेसवर रूट CA प्रमाणपत्र उपयोजित (Deploy) करा.

WAN अवलंबित्व

क्लाउड RADIUS ला सक्रिय इंटरनेट कनेक्शन आवश्यक आहे. WAN लिंक अयशस्वी झाल्यास, प्रमाणीकरण विनंत्या सर्व्हरपर्यंत पोहोचू शकत नाहीत. मिशन-क्रिटिकल स्थानिक संसाधनांसाठी, स्थानिक सर्व्हायव्हेबिलिटी किंवा ऑथेंटिकेशन कॅशिंगला सपोर्ट करणाऱ्या ऍक्सेस पॉइंट्सचे मूल्यांकन करा. बर्‍याच उपयोजनांसाठी (Deployments), WAN अवलंबित्व स्वीकार्य आहे कारण इंटरनेट नसलेली साइट कशाही प्रकारे क्लाउड ऍप्लिकेशन्समध्ये प्रवेश करू शकत नाही.

सामायिक सिक्रेट्स विसंगती (Shared secret mismatches)

प्रत्येक ऍक्सेस पॉइंट किंवा वायरलेस कंट्रोलर योग्य सामायिक सिक्रेटसह RADIUS क्लायंट म्हणून कॉन्फिगर केलेला असणे आवश्यक आहे. विसंगतीमुळे त्या डिव्हाइसवरील सर्व प्रमाणीकरण विनंत्या सायलेंटली फेटाळल्या जातात. इतर यशस्वी होत असताना एखादा विशिष्ट ऍक्सेस पॉइंट अयशस्वी होत असल्यास, त्या डिव्हाइसवरील सामायिक सिक्रेट कॉन्फिगरेशन सत्यापित करा.


ROI आणि व्यावसायिक प्रभाव

comparison_chart.png

RADIUS as a Service चे व्यावसायिक फायदे तीन स्तंभांवर आधारलेले आहेत: भांडवली खर्च कमी करणे, कमी ऑपरेशनल ओव्हरहेड आणि सुधारित सुरक्षा व्यवस्था.

भांडवली खर्चाच्या बाबतीत, तुम्ही भौतिक सर्व्हर खरेदी, परवाना देणे आणि नवीन करणे यासाठीचा खर्च पूर्णपणे वाचवता. किमान व्यावहारिक ऑन-प्रिमाइसेस RADIUS उपयोजनासाठी उच्च उपलब्धतेसाठी दोन सर्व्हर, ऑपरेटिंग सिस्टम परवाने आणि दर तीन ते पाच वर्षांनी हार्डवेअर नूतनीकरण आवश्यक आहे. ५०-मालमत्ता असलेल्या हॉटेल समूहासाठी, संपूर्ण मालमत्तेवर ही एक लक्षणीय हार्डवेअर गुंतवणूक ठरेल.

ऑपरेशनल ओव्हरहेडच्या बाबतीत, तुमच्या इंजिनिअरिंग टीमला आता विंडोज सर्व्हर पॅच करण्यासाठी, FreeRADIUS कॉन्फिगरेशनमधील त्रुटी निवारण करण्यासाठी किंवा भौतिक पायाभूत सुविधांवरील प्रमाणपत्र नूतनीकरण व्यवस्थापित करण्यासाठी वेळ घालवावा लागणार नाही. तो वेळ सुरक्षा धोरणाच्या कामाकडे वळवला जाऊ शकतो ज्यामुळे तुमची सुरक्षा थेट सुधारते.

सुरक्षा व्यवस्थेचा विचार केल्यास, EAP-TLS आणि डायनॅमिक VLAN असाइनमेंटकडे जाण्यामुळे नेटवर्कवरील हल्ल्याची शक्यता लक्षणीयरीत्या कमी होते. क्रेडेंशियल चोरी हे नेटवर्क उल्लंघनाचे प्रमुख कारण आहे. नेटवर्क प्रमाणीकरण प्रक्रियेतून पासवर्ड काढून टाकल्याने या धोक्याचे थेट निराकरण होते. केंद्रीकृत ऑडिट लॉगिंग PCI DSS v4.0 आणि GDPR चे पालन करण्यास मदत करते, ज्यामुळे अनुपालन ऑडिटचा खर्च आणि गुंतागुंत कमी होते. वाहतूक हब किंवा जास्त गर्दी असलेल्या ठिकाणांचे व्यवस्थापन करणाऱ्या संस्थांसाठी, एकाच डॅशबोर्डवरून सर्व ठिकाणांवर सुसंगत सुरक्षा धोरणे लागू करण्याची क्षमता ही मोजता येण्याजोगी ऑपरेशनल सुधारणा आहे. Purple ८०,०००+ हून अधिक लाइव्ह ठिकाणी कार्यरत आहे आणि २०२४ मध्ये ४४० दशलक्ष लॉगइन प्रक्रियेत आणले आहेत (Purple अंतर्गत डेटा, २०२४). या प्रमाणाला सपोर्ट करणारी पायाभूत सुविधा डिझाइननुसार क्लाउड-नेटिव्ह आहे.

WiFi ॲनालिटिक्स आणि नेटवर्क इंटेलिजन्स व्यावसायिक परिणामांशी कसे जोडले जातात याच्या विस्तृत दृश्यासाठी, आमचे WiFi Analytics platform पहा.


संदर्भ

[1] IEEE Standard for Local and metropolitan area networks - Port-Based Network Access Control. IEEE Std 802.1X-2020. [2] IETF. Remote Authentication Dial In User Service (RADIUS). RFC 2865. 1997. [3] IETF. The EAP-TLS Authentication Protocol. RFC 5216. 2008. [4] IronWiFi. Benefits of a Cloud RADIUS Server: Why Enterprises Are Moving Authentication Online. फेब्रुवारी २०२६. [5] SecureW2. Cloud vs. On-Site RADIUS: Which is Better? मे २०२६. [6] Portnox. RADIUS as a Service. २०२६. [7] PCI Security Standards Council. PCI DSS v4.0. मार्च २०२२. [8] Purple. अंतर्गत प्लॅटफॉर्म डेटा: ४४० दशलक्ष लॉगइन, ८०,०००+ ठिकाणे. २०२४.

Definiciones clave

RADIUS

Remote Authentication Dial-In User Service. Un protocolo de red definido en RFC 2865 que proporciona una gestión centralizada de autenticación, autorización y contabilidad (AAA) para los usuarios que se conectan a un servicio de red.

Los equipos de TI utilizan RADIUS como el motor de decisión central para verificar si un dispositivo o usuario tiene permitido el acceso a la red WiFi corporativa. Se sitúa entre el punto de acceso y el proveedor de identidad.

802.1X

Un estándar de la IEEE para el control de acceso a la red basado en puertos. Proporciona un mecanismo de autenticación para los dispositivos que desean conectarse a una LAN o WLAN, obligándolos a autenticarse antes de recibir una dirección IP.

Este es el estándar en el que se basa la seguridad WiFi de nivel empresarial. Sin 802.1X, cualquier dispositivo que se conecte al SSID obtiene acceso a la red. Con 802.1X, cada dispositivo debe demostrar su identidad primero.

EAP-TLS

Extensible Authentication Protocol - Transport Layer Security. Un método de autenticación definido en RFC 5216 que requiere tanto al dispositivo cliente como al servidor RADIUS presentar certificados digitales, proporcionando una autenticación mutua sin contraseñas.

Considerado el estándar de oro para la seguridad WiFi empresarial. Los certificados se despliegan en los dispositivos corporativos a través de MDM. EAP-TLS elimina el riesgo de robo de contraseñas y ataques de phishing en la red.

PEAP

Protected Extensible Authentication Protocol. Un método EAP que encapsula un intercambio de nombre de usuario y contraseña dentro de una sesión TLS. Es menos seguro que EAP-TLS porque depende de contraseñas.

PEAP-MSCHAPv2 está ampliamente desplegado en entornos heredados. Los equipos de TI deben planificar una migración a EAP-TLS para los dispositivos corporativos, utilizando PEAP solo como alternativa para dispositivos no gestionados o BYOD.

Asignación dinámica de VLAN

Un proceso en el que el servidor RADIUS indica al punto de acceso en qué red de área local virtual (VLAN) debe ubicar un dispositivo, basándose en la identidad y el rol verificados del usuario, en lugar del SSID al que se conectó.

Esencial para la segmentación de red en entornos con múltiples roles. Un único SSID de "Personal" puede separar de forma segura el tráfico de limpieza, recepción y dirección en diferentes VLAN con diferentes derechos de acceso.

AAA

Autenticación, Autorización y Contabilidad (Accounting). Las tres funciones que realiza un servidor RADIUS: verificar la identidad (autenticación), determinar qué acceso está permitido (autorización) y registrar los datos de la sesión para fines de auditoría (contabilidad).

Los equipos de TI y los auditores utilizan AAA como un marco de referencia para evaluar el control de acceso a la red. Cloud RADIUS ofrece estas tres funciones desde un servicio gestionado.

WPA3-Enterprise

El estándar de seguridad WiFi actual para redes empresariales, que requiere autenticación 802.1X a través de un servidor RADIUS. Ofrece una mayor robustez criptográfica en comparación con WPA2-Enterprise, incluyendo un modo de seguridad de 192 bits para entornos de alta seguridad.

Los administradores de TI deben configurar WPA3-Enterprise como el estándar de seguridad mínimo para las redes del personal. Las redes de invitados pueden utilizar WPA2 o autenticación abierta con un Captive Portal.

Control de Acceso a la Red (NAC)

Un enfoque de seguridad que aplica políticas en los dispositivos que intentan acceder a los recursos de la red, combinando la evaluación de la seguridad del endpoint, la autenticación de la identidad y la aplicación de políticas de red.

RADIUS es un componente fundamental de NAC. Cloud RADIUS extiende NAC a entornos distribuidos y multisitio sin necesidad de infraestructura local en cada ubicación.

Captive portal

Una página web con la que el usuario de una red de acceso público debe interactuar antes de que se le conceda acceso a Internet. Se utiliza habitualmente en redes WiFi para invitados con el fin de recopilar el consentimiento o mostrar las condiciones de uso.

Los portales cautivos gestionan el acceso de invitados no autenticados, mientras que 802.1X gestiona el acceso del personal autenticado. Ambos mecanismos funcionan en SSIDs y VLANs independientes.

Ejemplos prácticos

Un hotel de 200 habitaciones necesita proteger la red de su personal (limpieza, recepción y dirección), manteniendo la red Guest WiFi totalmente independiente. Actualmente utilizan una clave PSK compartida para la red del personal, que no se ha cambiado en dos años.

Implementar RADIUS as a Service integrado con Microsoft Entra ID. Configurar los puntos de acceso Cisco Meraki para utilizar WPA3-Enterprise con 802.1X. El personal de limpieza se autentica con sus credenciales de Entra ID; el servidor RADIUS lee su grupo de directorio y los asigna dinámicamente a la VLAN 10 (con acceso exclusivo al sistema de tareas de limpieza). El personal de recepción se asigna a la VLAN 20 (acceso al sistema de gestión hotelera). La dirección se asigna a la VLAN 30 (acceso más amplio). La red Guest WiFi permanece en un SSID independiente con un Captive Portal, aislada en la VLAN 40. Cuando un empleado de temporada se marcha, se desactiva su cuenta de Entra ID, lo que revoca al instante su acceso a la WiFi en todos los puntos de acceso del establecimiento.

Comentario del examinador: Este enfoque elimina la vulnerabilidad de la clave PSK compartida y el riesgo de que los antiguos empleados sigan teniendo acceso. La asignación dinámica de VLAN garantiza que un dispositivo de limpieza en peligro no pueda acceder al sistema de gestión hotelera. Al utilizar un RADIUS en la nube, se elimina la necesidad de disponer de un servidor físico en el limitado cuarto de TI del hotel. La integración con Entra ID permite que la baja de un empleado sea una única acción con efecto inmediato en toda la red.

Una cadena nacional de tiendas de retail con 400 establecimientos necesita garantizar el cumplimiento de la normativa PCI DSS para sus terminales de punto de venta (TPV). Actualmente gestionan 400 instancias independientes de FreeRADIUS en servidores locales de cada tienda, y cada una de ellas requiere parches individuales.

Migrar a una única instancia de RADIUS as a Service. Configurar los puntos de acceso HPE Aruba en las 400 tiendas para autenticar los dispositivos TPV mediante EAP-TLS con certificados de máquina distribuidos a través de Microsoft Intune. El servidor RADIUS en la nube autentica los certificados y sitúa los dispositivos TPV en una VLAN que cumple con la normativa PCI (VLAN 30), aislada del resto del tráfico de red. El personal de la tienda utiliza un SSID independiente autenticado a través de Okta, que lo sitúa en una VLAN de personal general (VLAN 20). Los clientes de la red de invitados están aislados en la VLAN 40. El equipo de seguridad gestiona todas las políticas desde un único panel de control.

Comentario del examinador: La centralización de la infraestructura RADIUS elimina la carga de mantenimiento que supone parchear 400 servidores locales. El uso de EAP-TLS para los dispositivos TPV elimina por completo las contraseñas, lo que evita el robo de credenciales. Esta arquitectura cumple con el Requisito 8 (autenticación única) y el Requisito 1 (segmentación de red) de PCI DSS v4.0. Cuando se detecta una vulnerabilidad, el proveedor aplica el parche en la infraestructura de la nube, en lugar de que el equipo de seguridad de la cadena de tiendas tenga que parchear 400 servidores a lo largo de varias semanas.

Preguntas de práctica

Q1. ¿El campus de tu universidad utiliza actualmente Microsoft NPS en Windows Server para autenticar a los estudiantes a través de PEAP-MSCHAPv2. La institución está migrando a Google Workspace y desea retirar todos los servidores locales en un plazo de 12 meses. ¿Cuál es el cambio arquitectónico más seguro y operativamente eficiente para la infraestructura de autenticación WiFi?

Sugerencia: Microsoft NPS no es compatible de forma nativa con Google Workspace. Considera qué reemplaza tanto al servidor como al método de autenticación.

Ver respuesta modelo

Migrar a RADIUS como servicio con integración nativa con Google Workspace. El servicio RADIUS en la nube se conecta directamente a Google Workspace a través de LDAP u OIDC, eliminando la necesidad de Active Directory o NPS. Simultáneamente, realizar la transición de los dispositivos gestionados de estudiantes y personal de PEAP-MSCHAPv2 a EAP-TLS mediante la implementación de certificados de cliente a través de la plataforma MDM de la institución. Esto elimina las contraseñas del proceso de autenticación y garantiza que solo los dispositivos gestionados y de confianza puedan acceder a las redes de personal y estudiantes. La migración se puede realizar por fases: implementar RADIUS en la nube junto con NPS, migrar un SSID a la vez y, a continuación, retirar NPS una vez que todos los dispositivos utilicen el nuevo servicio.

Q2. Un estadio con capacidad para 80.000 personas requiere WiFi seguro para el personal corporativo, las terminales de venta de entradas, los miembros de la prensa y los contratistas los días de evento. ¿Cómo se debe configurar la red utilizando RADIUS en la nube para aplicar el acceso adecuado a cada grupo?

Sugerencia: Considera cómo gestiona RADIUS la autorización, no solo la autenticación. Cada grupo necesita diferentes derechos de acceso.

Ver respuesta modelo

Implementar un único SSID 802.1X para todos los grupos autenticados. Configurar el servicio RADIUS en la nube para utilizar la asignación dinámica de VLAN basada en el rol del usuario en el proveedor de identidad. Al personal corporativo se le asigna la VLAN 10 con acceso a los sistemas internos. Las terminales de venta de entradas, autenticadas mediante certificados de máquina (EAP-TLS), se ubican en una VLAN 20 restringida con acceso exclusivo a la plataforma de venta de entradas. A los miembros de la prensa se les asigna la VLAN 30 con acceso a internet de banda ancha pero sin acceso a los sistemas internos. A los contratistas de los días de evento se les asigna la VLAN 40 con acceso exclusivo a internet de forma limitada. Un SSID abierto independiente con un Captive Portal gestiona el acceso de los aficionados y asistentes en la VLAN 50, aislado de todo el demás tráfico.

Q3. Durante una auditoría de seguridad, se descubre que el servidor FreeRADIUS de tu organización no ha recibido un parche de seguridad en ocho meses. El equipo se ha mostrado reacio a parchearlo porque la última actualización provocó una interrupción de la autenticación de dos horas. ¿Cómo resuelve la migración a RADIUS como servicio tanto el riesgo de seguridad como el riesgo operativo?

Sugerencia: Considera la división de responsabilidades en un modelo de servicio gestionado y cómo gestionan los proveedores las actualizaciones sin tiempo de inactividad.

Ver respuesta modelo

RADIUS como servicio transfiere la responsabilidad del parcheado del sistema operativo y la gestión de vulnerabilidades al proveedor. El proveedor opera clústeres multirregión de alta disponibilidad, lo que le permite parchear endpoints individuales y aplicar actualizaciones de forma progresiva sin causar interrupciones en la autenticación. Tu equipo ya no necesita programar ventanas de mantenimiento ni aceptar el riesgo de una interrupción provocada por un parche. El riesgo de seguridad se elimina porque el proveedor parchea la infraestructura a medida que se revelan las vulnerabilidades, a menudo antes de que la CVE se haga pública de forma generalizada. El riesgo operativo se elimina porque el SLA del proveedor garantiza el tiempo de actividad independientemente de la actividad de parcheado. El rol de tu equipo pasa del mantenimiento de la infraestructura a la gestión de políticas.

Continúe leyendo esta serie

Integración de RADIUS as a Service con directorios en la nube (Azure AD y Google Workspace)

Esta guía de referencia técnica detalla cómo integrar RADIUS as a Service con directorios en la nube (Microsoft Entra ID y Google Workspace) para la autenticación WiFi empresarial. Cubre la transición arquitectónica de NPS local a RADIUS nativo de la nube, el despliegue de la autenticación EAP-TLS basada en certificados y las mejores prácticas operativas para proteger el acceso inalámbrico en entornos de hostelería, comercio minorista y sector público. Para los responsables de TI y arquitectos de redes que ya han invertido en identidad en la nube, esta guía cierra la brecha entre la gestión de directorios y la seguridad de la red física.

Leer la guía →

Cómo implementar la autenticación 802.1X con Cloud RADIUS

Esta guía de referencia técnica proporciona un marco integral para implementar la autenticación 802.1X con Cloud RADIUS en entornos empresariales distribuidos. Detalla la arquitectura, la selección del método EAP, la secuencia de implementación y las estrategias de mitigación de riesgos necesarias para proteger el acceso a la red y, al mismo tiempo, eliminar los costes operativos de la infraestructura local.

Leer la guía →

¿Qué es Cloud RADIUS? Una guía completa sobre RADIUS-as-a-Service

Esta guía completa analiza Cloud RADIUS (RADIUS-as-a-Service), detallando su arquitectura, métodos de EAP y estrategias de implementación. Proporciona a los líderes de TI información práctica sobre la migración de servidores locales a un modelo de autenticación en la nube escalable, seguro y compatible.

Leer la guía →