Los beneficios de seguridad de RADIUS as a Service para fuerzas de trabajo híbridas

Esta guía de referencia técnica explica cómo RADIUS as a Service protege el acceso a la red para fuerzas de trabajo híbridas en instalaciones distribuidas. Cubre la arquitectura, los beneficios de seguridad y los pasos de implementación para reemplazar la infraestructura RADIUS local por un servicio de autenticación gestionado en la nube. Para gerentes de TI y arquitectos de red en hoteles, cadenas de retail, estadios y organizaciones del sector público, esta guía proporciona la evidencia necesaria para evaluar y actuar en una migración a RADIUS en la nube este trimestre.

📖 9 min de lectura📝 2,171 palabras🔧 2 ejemplos resueltos❓ 3 preguntas de práctica📚 9 definiciones clave

Escucha esta guía

Ver transcripción del podcast

Le damos la bienvenida a este informe técnico de Purple. Soy su anfitrión y hoy analizaremos un cambio fundamental en la arquitectura de redes empresariales: la transición de los servidores RADIUS locales a RADIUS as a Service. Si administra la TI de un grupo hotelero, una cadena minorista, un estadio o cualquier gran recinto público, sabe que proteger el acceso a la red para una fuerza laboral híbrida ya no es una preocupación secundaria. Es fundamental para su seguridad operativa, su postura de cumplimiento y, francamente, su tranquilidad para poder dormir por las noches.

Hoy abordaremos cinco áreas. Primero, el contexto: por qué la infraestructura tradicional de RADIUS local tiene dificultades para mantener el ritmo del trabajo híbrido. Segundo, la arquitectura técnica de RADIUS as a Service y cómo funciona realmente. Tercero, los beneficios de seguridad específicos que obtiene. Cuarto, orientación práctica para la implementación y los errores que se deben evitar. Y quinto, una sección de preguntas y respuestas rápidas sobre los temas que escuchamos con más frecuencia de los administradores de TI y arquitectos de redes.

Comencemos con el contexto. Durante dos décadas, la autenticación 802.1X dependió 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 atención constante. Había que aplicar parches a los sistemas operativos, administrar cadenas de certificados, configurar la alta disponibilidad de forma manual y desarrollar redundancia en múltiples servidores. En un mundo donde los trabajadores se trasladan constantemente entre la oficina, ubicaciones remotas, habitaciones de hotel y sitios de clientes, esa infraestructura local estática se convierte en un riesgo real.

El problema se complica con la transició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 u Okta. Si su organización se ha migrado a cualquiera de estos directorios en la nube, se enfrenta a una decisión difícil: mantener un Active Directory paralelo solo para dar soporte a su servidor RADIUS o invertir un esfuerzo de ingeniería significativo en integraciones personalizadas. Ninguna de las opciones es atractiva.

RADIUS as a Service cambia la ecuación por completo. Traslada el motor de autenticación a la nube. Ya no administra la infraestructura; administra 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.

Ahora entremos en la arquitectura técnica. RADIUS, que significa Remote Authentication Dial-In User Service, es el protocolo definido en el RFC 2865. Proporciona autenticación, autorización y contabilidad centralizadas, 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. Este reenvía la solicitud de autenticación al servidor RADIUS. El servidor valida las credenciales frente a 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 múltiples 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 a RADIUS local desde la perspectiva del punto de acceso. La diferencia es que el propio servidor es administrado, actualizado 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 el 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 puede ser objeto de phishing, adivinado o robado como 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 solo otorga o deniega el acceso. También le indica al punto de acceso en qué LAN virtual debe colocar el dispositivo, según la identidad y el rol del usuario. Un recepcionista de hotel se autentica y se le asigna a la VLAN de recepción con acceso al sistema de gestión de la propiedad. Un miembro del personal de limpieza se coloca en una VLAN restringida solo con acceso 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 simplemente porque se conectó a un SSID en particular. Se otorga acceso con base en una identidad verificada y se limita ese acceso únicamente a lo que esa identidad requiere. Este es el principio de privilegio mínimo 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 maneje 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. Ese registro de auditoría es esencial para demostrar el cumplimiento y para investigar cualquier posible vulneración de datos.

Now let me walk you through two concrete implementation scenarios that illustrate how this works in practice.

El primer escenario es un grupo hotelero. Considere un hotel de doscientas habitaciones. Actualmente utilizan una clave precompartida compartida para el WiFi de su personal. Cada miembro del personal, desde el gerente general hasta el equipo de limpieza de temporada, utiliza la misma contraseña. Cuando un empleado de temporada se va al final del verano, la contraseña rara vez se cambia porque cambiarla implica actualizar cada dispositivo de la propiedad. Esta es una vulnerabilidad de seguridad clásica.

La solución es implementar RADIUS as a Service integrado con Microsoft Entra ID. El hotel configura sus puntos de acceso Cisco Meraki para usar 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 de la propiedad. La gerencia se asigna a la VLAN 30 con un acceso más amplio. Cuando termina el contrato de un empleado de temporada, su cuenta de Entra ID se deshabilita y su acceso a WiFi se revoca instantáneamente en cada punto de acceso de la propiedad. No se requieren cambios de contraseña.

El segundo escenario es una cadena minorista nacional. Considere una cadena con cuatrocientas tiendas. Actualmente gestionan cuatrocientas instancias independientes de FreeRADIUS en servidores locales de las tiendas. Cada servidor requiere parches, monitoreo y mantenimiento individuales. Cuando se revela una vulnerabilidad crítica, el equipo de seguridad debe aplicar parches en cuatrocientos servidores, a menudo durante un período de semanas, dejando la infraestructura expuesta durante ese lapso.

La solución es migrar a una sola instancia de RADIUS as a Service. Las cuatrocientas tiendas apuntan sus puntos de acceso HPE Aruba a los mismos endpoints de RADIUS en la nube. Las terminales de punto de venta se autentican mediante EAP-TLS con certificados de dispositivo distribuidos a través de la plataforma MDM. El servidor RADIUS los coloca en una VLAN que cumple 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, lo que los coloca en una VLAN general para el personal. El equipo de seguridad ahora gestiona un único conjunto de políticas desde un solo panel de control. Cuando se revela una vulnerabilidad, el proveedor aplica los parches a la infraestructura. El equipo de seguridad de la cadena minorista se enfoca en las políticas, no en la infraestructura de soporte.

Ahora cubramos las recomendaciones de implementación y los errores comunes que se deben evitar.

El paso uno es conectar el servicio RADIUS en la nube con su proveedor de identidad. Para Microsoft Entra ID o Google Workspace, esto normalmente implica autorizar una aplicación empresarial. Asocie sus grupos de directorio con políticas de red específicas. Piense detenidamente en su taxonomía de roles antes de comenzar. Hacer esto bien desde el principio evita tener que repetir una gran cantidad de trabajo más adelante.

El segundo paso consiste en configurar el despliegue de certificados para los dispositivos corporativos. Configure su plataforma MDM para enviar los certificados de cliente a los dispositivos gestionados. Esto habilita 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 de respaldo, pero EAP-TLS debe ser el objetivo para todos los dispositivos propiedad de la empresa.

El tercer paso es configurar el hardware de su 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. Identifique en qué VLAN debe ubicarse cada rol de usuario y pruébelo a fondo antes de lanzarlo a producción.

Ahora, hablemos de los errores comunes. El fallo más habitual es un firewall 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 común 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 la conexión de forma silenciosa. Esto puede parecer una caída de la red cuando en realidad es un problema de configuración de la PKI.

Pasemos a la ronda de preguntas rápidas.

Pregunta uno: ¿Qué ocurre si se cae nuestra conexión a internet? Si el sitio se queda sin internet, no podrá comunicarse con el RADIUS en la nube. No obstante, si el sitio no tiene internet, de todos modos los usuarios no podrán acceder a las aplicaciones en la nube. Para recursos locales de misión crítica, algunos puntos de acceso ofrecen modos de supervivencia local. Sin embargo, la dependencia principal es su enlace WAN, lo cual ocurre con 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 respalda un sólido nivel de cumplimiento. Los registros de auditoría cumplen con 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 servicio RADIUS as a Service que cumpla con los estándares.
Para resumir los puntos clave. Primero, RADIUS como Servicio reemplaza los servidores locales con una plataforma en la nube administrada, lo que reduce los gastos de capital y los costos de mantenimiento. Segundo, cloud RADIUS se integra de forma nativa con Microsoft Entra ID, Okta y Google Workspace, eliminando la necesidad de middleware complejo. Tercero, permite la asignación dinámica de VLAN, asegurando que los usuarios y dispositivos se ubiquen en el segmento de red correcto según su identidad verificada. Cuarto, la transición a EAP-TLS elimina el riesgo de robo de contraseñas y ataques de phishing en su red. Quinto, la gestión centralizada en la nube garantiza políticas de seguridad consistentes en cientos de ubicaciones distribuidas. Sexto, los proveedores se encargan de los parches de seguridad y la alta disponibilidad. Y séptimo, cloud RADIUS apoya el cumplimiento de PCI DSS y GDPR al aplicar 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 costo real de propiedad, incluyendo licencias, ciclos de actualización de hardware y el tiempo de ingeniería dedicado al mantenimiento. Luego, realice una prueba de concepto con un proveedor de cloud RADIUS. Es muy probable que descubra que la implementación toma horas, no semanas. Gracias por su atención. Asegure sus redes, segmente su tráfico y deje de administrar servidores que no necesita tener.

Puntos clave

✓RADIUS como servicio reemplaza los servidores locales con una plataforma en la nube administrada, eliminando los CapEx de hardware y los costos indirectos de mantenimiento.
✓Cloud RADIUS se integra de forma nativa con Microsoft Entra ID, Okta y Google Workspace, eliminando la necesidad de middleware complejo o implementaciones paralelas de Active Directory.
✓La asignación dinámica de VLAN garantiza que los usuarios y dispositivos se ubiquen automáticamente en el segmento de red correcto según su identidad verificada, no según el SSID al que se conectaron.
✓La transición a EAP-TLS (autenticación basada en certificados) elimina el riesgo de robo de contraseñas y ataques de phishing en su red.
✓La gestión centralizada en la nube aplica políticas de seguridad consistentes en cientos de ubicaciones distribuidas desde un solo panel de control.
✓Los proveedores se encargan de los parches de seguridad y de la alta disponibilidad en múltiples regiones, garantizando que los servicios de autenticación sigan disponibles incluso durante las actualizaciones de infraestructura.
✓Cloud RADIUS es compatible con el cumplimiento de PCI DSS v4.0 y GDPR al aplicar controles de acceso estrictos basados en la identidad con un registro de auditoría centralizado completo.

Resumen ejecutivo

El cambio hacia fuerzas de trabajo híbridas ha expuesto una debilidad fundamental en la seguridad de red tradicional: los servidores RADIUS locales fueron diseñados para un mundo donde el personal trabajaba en un solo edificio y se conectaba a una sola red. Ese mundo ya no existe. Hoy en día, su personal se autentica desde habitaciones de hotel, pisos de venta minorista, oficinas remotas y recintos de eventos. Sus proveedores de identidad residen en la nube. Sus puntos de acceso se extienden por cientos de ubicaciones. Sin embargo, muchas organizaciones aún dependen de servidores RADIUS físicos que requieren parches manuales, no se pueden integrar de forma nativa con Microsoft Entra ID o Google Workspace y fallan silenciosamente cuando el hardware tiene problemas.

RADIUS as a Service reemplaza esa infraestructura con un motor de autenticación nativo de la nube. Usted apunta sus puntos de acceso a endpoints en la nube. El proveedor administra los servidores, el parchado y la alta disponibilidad. Usted administra las políticas. Para los equipos de TI en grupos de Hospitalidad , cadenas de Retail y recintos públicos, este cambio elimina los costos indirectos de hardware, impone la segmentación de red basada en la identidad y ofrece el registro de auditoría que requieren PCI DSS y GDPR.

Análisis técnico profundo

Por qué el RADIUS local está teniendo dificultades

RADIUS, definido en RFC 2865, proporciona Autenticación, Autorización y Contabilidad (AAA) centralizadas para el acceso a la red. Cada empresa que ejecuta WiFi WPA2-Enterprise o WPA3-Enterprise depende de él. El protocolo en sí es sólido. El problema es el modelo de infraestructura que creció a su alrededor.

FreeRADIUS en Linux requiere una experiencia significativa para implementarse, protegerse y mantenerse. Microsoft Network Policy Server (NPS) está estrechamente acoplado a Active Directory y no tiene soporte nativo para Microsoft Entra ID, Okta o Google Workspace. Cisco Identity Services Engine (ISE) ofrece funciones de políticas de nivel empresarial, pero exige hardware dedicado, licencias complejas y un equipo de especialistas para operarlo. Los tres requieren que construya y mantenga la alta disponibilidad de forma manual, normalmente ejecutando dos servidores con replicación de bases de datos y un equilibrador de carga frente a ellos.

Para una organización de un solo sitio con un Active Directory estable, este modelo es manejable. Para un grupo hotelero con 50 propiedades, una cadena de retail con 400 tiendas o una universidad con un campus distribuido, se vuelve inviable. O bien centraliza los servidores RADIUS y acepta la latencia de autenticación de los sitios remotos, o bien implementa servidores en cada ubicación y los administra individualmente. Ninguna de las dos opciones es escalable.

La arquitectura de RADIUS as a Service

RADIUS as a Service es un modelo de entrega basado en la nube para el protocolo RADIUS. El protocolo en sí permanece sin cambios, siguiendo RFC 2865 y sus extensiones. Lo que cambia es quién mantiene la infraestructura. Cuando un dispositivo se conecta a su red WiFi, el punto de acceso (el cliente RADIUS) reenvía la solicitud de autenticación a los endpoints de RADIUS en la nube a través de un túnel seguro y cifrado. El servicio en la nube valida las credenciales con su proveedor de identidad y devuelve un mensaje de Access-Accept o Access-Reject, junto con atributos de política como asignaciones dinámicas de VLAN. Desde la perspectiva del punto de acceso, el flujo de autenticación es idéntico al de un RADIUS local.

El proveedor en la nube opera los servidores RADIUS en múltiples centros de datos distribuidos geográficamente. El failover es automático. Si un endpoint deja de estar disponible, el tráfico se enruta al siguiente que esté activo sin ninguna intervención de su equipo. Para las organizaciones con ubicaciones en múltiples regiones, la autenticación se realiza en el endpoint en la nube más cercano, lo que mantiene una baja latencia independientemente de la geografía.

Métodos IEEE 802.1X y EAP

IEEE 802.1X es el estándar para el Control de Acceso a la Red (NAC) basado en puertos. Obliga a un dispositivo a autenticarse antes de que se le asigne una dirección IP y se le permita transmitir tráfico. RADIUS es el servidor de autenticación en una implementación de 802.1X.

El Protocolo de Autenticación Extensible (EAP) define cómo se intercambian las credenciales. Cloud RADIUS es compatible con toda la gama de métodos EAP:

Método EAP	Tipo de autenticación	Nivel de seguridad	Uso recomendado
EAP-TLS	Basado en certificado mutuo	El más alto	Dispositivos corporativos con certificados gestionados por MDM
PEAP-MSCHAPv2	Usuario y contraseña	Moderado	Dispositivos heredados o BYOD sin MDM
EAP-TTLS	Credenciales en túnel	Moderado	Entornos mixtos
MAC Authentication Bypass	Dirección MAC del dispositivo	Bajo	Dispositivos IoT que no admiten 802.1X

EAP-TLS, definido en RFC 5216, es el estándar de oro. Tanto el dispositivo cliente como el servidor RADIUS se presentan certificados digitales mutuamente. Esta autenticación mutua elimina por completo las contraseñas del proceso de acceso a la red. Un certificado está vinculado criptográficamente al dispositivo y no puede ser objeto de phishing, adivinación o robo de la forma en que lo puede ser una contraseña. Para las organizaciones que han sufrido brechas de seguridad basadas en credenciales, esta es la mitigación técnica más directa disponible.

Asignación dinámica de VLAN

Más allá de la autenticación, el servidor RADIUS aplica la autorización. Cuando acepta una conexión, devuelve atributos de política al punto de acceso, incluido el ID de VLAN que se asignará al dispositivo. Esta asignación dinámica de VLAN es el mecanismo que hace posibles las Redes Basadas en la Identidad.

La recepcionista de un hotel se autentica y es asignada a la VLAN de recepción con acceso al sistema de gestión de la propiedad. Un miembro del personal de limpieza es asignado a una VLAN restringida con acceso exclusivo a internet. El dispositivo de un huésped se asigna a la VLAN de Guest WiFi, completamente aislado de todos los recursos corporativos. Un dispositivo IoT, como una cámara de seguridad, se asigna a una VLAN de IoT dedicada. Todo esto sucede de forma automática, según la identidad verificada por el servidor RADIUS, sin necesidad de configurar manualmente la VLAN por dispositivo.

Este es el principio de mínimo privilegio aplicado al acceso a la red. No se confía en un dispositivo solo porque se conectó a un SSID en particular. Se otorga acceso según la identidad verificada y se limita ese acceso únicamente a lo que esa identidad requiere. Para analizar más a fondo cómo encaja esto en una estrategia más amplia de control de acceso a la red, consulte nuestra guía sobre sistemas de control de acceso a la red .

Integración nativa de identidad en la nube

La ventaja más significativa a nivel operativo de un sistema RADIUS en la nube es su integración nativa con los proveedores de identidad modernos. El servicio de RADIUS en la nube se conecta directamente a Microsoft Entra ID, Okta y Google Workspace mediante protocolos estándar que incluyen OIDC, SAML y LDAP. Al dar de alta a un nuevo empleado en su proveedor de identidad, este puede autenticarse en la red WiFi de inmediato. Al dar de baja a un empleado, usted deshabilita su cuenta en el directorio y su acceso a la red WiFi se revoca al instante, en cada punto de acceso de todas las ubicaciones.

Esta sincronización en tiempo real elimina una de las brechas de seguridad más persistentes en la red WiFi empresarial: el ex-empleado que aún tiene la PSK compartida, o cuya cuenta de RADIUS no se eliminó manualmente al momento de su salida. Con un sistema RADIUS en la nube y un proveedor de identidad en la nube, la baja de personal es una sola acción con un efecto inmediato en toda la red.

Guía de implementación

Paso 1: Conecte su proveedor de identidad

Conecte el servicio de RADIUS en la nube a su proveedor de identidad. En el caso de Microsoft Entra ID o Google Workspace, esto suele requerir la autorización de una aplicación empresarial mediante OAuth o la configuración de un conector LDAP. Vincule sus grupos de directorio a políticas de red específicas. Defina su taxonomía de roles antes de comenzar: qué grupos se asocian a qué VLANs y qué derechos de acceso tiene cada VLAN. Hacer esto bien desde el principio evita tener que repetir el trabajo más adelante.

Paso 2: Implemente certificados para dispositivos corporativos

Para los dispositivos propiedad de la empresa, configure su plataforma de gestión de dispositivos móviles (MDM), como Microsoft Intune o Jamf, para enviar certificados de cliente a los dispositivos. Esto habilita la autenticación EAP-TLS. Asegúrese de que la Autoridad de Certificación (CA) raíz que emitió el certificado del servidor RADIUS sea de confianza para todos los dispositivos cliente. Una cadena de confianza rota es la causa más común de fallas silenciosas de autenticación.

Paso 3: Configure el hardware de su red

Agregue las direcciones IP de RADIUS en la nube y los secretos compartidos a sus controladores inalámbricos o puntos de acceso. Configure siempre los endpoints primarios y secundarios para utilizar la redundancia integrada del proveedor. Asegúrese de que los puertos UDP 1812 (autenticación) y 1813 (contabilidad) estén abiertos de salida desde sus puntos de acceso hacia los endpoints de RADIUS en la nube. Verifique esto antes del lanzamiento. Las reglas de firewall mal configuradas son la segunda causa más común de fallas en la implementación.

Cloud RADIUS funciona con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. Los pasos de configuración varían según el proveedor, pero el protocolo RADIUS está estandarizado, por lo que los parámetros principales (IP del servidor, secreto compartido, puerto de autenticación) son consistentes.

Paso 4: Definir políticas de VLAN

Configure la asignación dinámica de VLAN en su motor de políticas RADIUS. Asocie cada rol de usuario o tipo de dispositivo a un ID de VLAN específico. Pruebe cada política antes de implementarla en producción. Una matriz de prueba simple (un dispositivo por rol, una VLAN por rol, verificar la asignación) detecta la mayoría de los errores de configuración antes de que afecten a los usuarios.

Buenas prácticas

Exija EAP-TLS para todos los dispositivos corporativos. Migre fuera de PEAP-MSCHAPv2 tan rápido como lo permita su implementación de MDM. PEAP depende de contraseñas, que pueden verse comprometidas. EAP-TLS se basa en certificados, que no.

Segmente todo. Nunca coloque al personal, a los invitados y a los dispositivos IoT en la misma subred. Utilice RADIUS para aplicar límites estrictos de VLAN. Esto es fundamental para entornos de Retail que manejan datos de tarjetas de pago bajo PCI DSS, y para entornos de Salud que protegen datos de pacientes.

Alinéese con WPA3-Enterprise. WPA3-Enterprise, el estándar de seguridad WiFi actual, requiere autenticación 802.1X. Asegúrese de que sus puntos de acceso sean compatibles con WPA3-Enterprise y configúrelo como el estándar de seguridad mínimo para las redes del personal.

Audite sus registros de RADIUS con regularidad. Cloud RADIUS proporciona registros de auditoría centralizados. Revise las fallas de autenticación semanalmente. Un aumento repentino en las fallas de un dispositivo o ubicación específicos es un indicador temprano de una mala configuración o de un ataque potencial.

Pruebe la conmutación por error. Al menos una vez al trimestre, simule una falla en el endpoint de RADIUS primario y verifique que la autenticación continúe a través del endpoint secundario. Documente el resultado. Esta es una prueba sencilla que la mayoría de los equipos nunca ejecutan hasta que la necesitan.

Para los establecimientos que implementan WiFi en entornos complejos, incluidos lugares marítimos o remotos, consulte nuestra guía sobre cómo configurar un Captive Portal en Starlink para conocer las consideraciones sobre la dependencia de WAN.

Resolución de problemas y mitigación de riesgos

Tiempos de espera de autenticación

Si los dispositivos no logran autenticarse, primero verifique la conectividad entre sus puntos de acceso y los endpoints de RADIUS en la nube. Verifique que los puertos UDP 1812 y 1813 estén abiertos para tráfico saliente. La inspección profunda de paquetes en los firewalls modernos puede retrasar o descartar los paquetes de RADIUS. Si observa tiempos de espera agotados, revise las reglas de su política de firewall que podrían estar inspeccionando o limitando el ancho de banda del tráfico UDP hacia los endpoints de RADIUS.

Fallas en la cadena de confianza de certificados

Si utiliza EAP-TLS, asegúrese de que los dispositivos cliente confíen en la CA raíz que emitió el certificado del servidor RADIUS. Si la cadena de confianza se rompe, el dispositivo rechazará silenciosamente la conexión para evitar un ataque de intermediario (man-in-the-middle). Esto se presenta como una falla de conexión sin un mensaje de error obvio. Revise los registros del servidor RADIUS para identificar fallas en el saludo (handshake) de EAP-TLS. Distribuya el certificado de la CA raíz en todos los dispositivos administrados a través de un MDM.

Dependencia de la red WAN

RADIUS en la nube requiere una conexión activa a internet. Si el enlace WAN falla, las solicitudes de autenticación no podrán llegar al servidor. Para recursos locales de misión crítica, evalúe puntos de acceso que admitan la supervivencia local o el almacenamiento en caché de autenticación. Para la mayoría de las implementaciones, la dependencia de la WAN es aceptable porque un sitio sin internet no puede acceder a las aplicaciones en la nube de todos modos.

Discrepancias en el secreto compartido (shared secret)

Cada punto de acceso o controlador inalámbrico debe configurarse como un cliente RADIUS con el secreto compartido correcto. Una discrepancia provoca que todas las solicitudes de autenticación de ese dispositivo se descarten silenciosamente. Si un punto de acceso específico está fallando mientras que otros funcionan correctamente, verifique la configuración del secreto compartido en ese dispositivo.

ROI e impacto empresarial

El caso de negocio para RADIUS como servicio se basa en tres pilares: reducción de gastos de capital (CapEx), menores costos operativos (OpEx) y una mejor postura de seguridad.

En cuanto a los gastos de capital, se elimina el costo de adquisición, licenciamiento y renovación de servidores físicos. Una implementación mínima viable de RADIUS en sitio requiere dos servidores para alta disponibilidad, licencias de sistema operativo y renovación de hardware cada tres a cinco años. Para un grupo hotelero de 50 propiedades, esto representa una inversión significativa de hardware en todo su patrimonio.

En cuanto a los costos operativos, su equipo de ingeniería ya no dedicará tiempo a aplicar parches en Windows Server, solucionar problemas de configuración de FreeRADIUS o gestionar la renovación de certificados en la infraestructura física. Ese tiempo se redirige a tareas de políticas de seguridad que mejoran directamente su postura.

En cuanto a la postura de seguridad, la transición a EAP-TLS y la asignación dinámica de VLAN reduce considerablemente la superficie de ataque. El robo de credenciales es la principal causa de brechas de red. Eliminar las contraseñas del proceso de autenticación de red aborda directamente ese riesgo. El registro de auditoría centralizado facilita el cumplimiento de PCI DSS v4.0 y GDPR, reduciendo el costo y la complejidad de las auditorías de cumplimiento.Para las organizaciones que gestionan centros de Transporte o puntos de gran afluencia de personas, la capacidad de aplicar políticas de seguridad consistentes en todas las ubicaciones desde un único panel es una mejora operativa medible. Purple opera en más de 80,000 puntos activos y ha procesado 440 millones de inicios de sesión en 2024 (datos internos de Purple, 2024). La infraestructura que soporta esa escala es nativa de la nube por diseño.

Para una visión más amplia de cómo la analítica de WiFi y la inteligencia de red se conectan con los resultados de negocio, consulte nuestra plataforma de WiFi Analytics .

Referencias

[1] Estándar IEEE para redes de área local y metropolitana - Control de acceso a la red basado en puertos. IEEE Std 802.1X-2020. [2] IETF. Servicio de usuario de acceso telefónico de autenticación remota (RADIUS). RFC 2865. 1997. [3] IETF. El protocolo de autenticación EAP-TLS. RFC 5216. 2008. [4] IronWiFi. Beneficios de un servidor RADIUS en la nube: por qué las empresas están trasladando la autenticación en línea. Febrero de 2026. [5] SecureW2. RADIUS en la nube frente a local: ¿cuál es mejor? Mayo de 2026. [6] Portnox. RADIUS como servicio. 2026. [7] Consejo de Normas de Seguridad de la PCI. PCI DSS v4.0. Marzo de 2022. [8] Purple. Datos internos de la plataforma: 440 millones de inicios de sesión, más de 80,000 puntos. 2024.

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 ubica entre el punto de acceso y el proveedor de identidad.

802.1X

Un estándar de 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 que sustenta la seguridad WiFi empresarial. Sin 802.1X, cualquier dispositivo que se conecte al SSID obtiene acceso a la red. Con 802.1X, cada dispositivo debe demostrar primero su identidad.

EAP-TLS

Extensible Authentication Protocol - Transport Layer Security. Un método de autenticación definido en RFC 5216 que requiere que tanto el dispositivo cliente como el servidor RADIUS presenten certificados digitales, proporcionando 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 un 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 se despliega ampliamente en entornos heredados. Los equipos de TI deben planificar una migración a EAP-TLS para los dispositivos corporativos, utilizando PEAP únicamente como respaldo 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é LAN virtual debe colocar 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 solo SSID para "Personal" puede separar de forma segura el tráfico de limpieza, recepción y administración en diferentes VLAN con distintos derechos de acceso.

AAA

Autenticación, Autorización y Contabilidad. 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 auditores utilizan AAA como un marco de referencia para evaluar el control de acceso a la red. Cloud RADIUS ofrece las 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 resistencia criptográfica mejorada en comparación con WPA2-Enterprise, incluyendo el modo de seguridad de 192 bits para entornos de alta seguridad.

Los administradores de TI deben configurar WPA3-Enterprise como el estándar mínimo de seguridad 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 a los dispositivos que intentan acceder a los recursos de la red, combinando la evaluación de seguridad del endpoint, la autenticación de 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 de múltiples sitios sin necesidad de infraestructura local en cada ubicación.

Captive Portal

Una página web con la que un usuario de una red de acceso público debe interactuar antes de que se le conceda acceso a Internet. Se utiliza típicamente en redes WiFi de invitados para recopilar el consentimiento o mostrar los términos de uso.

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

Ejemplos resueltos

Un hotel de 200 habitaciones necesita proteger la red de su personal de limpieza, recepción y administración, manteniendo el WiFi para huéspedes completamente separado. Actualmente utilizan una PSK compartida para la red del personal, la cual 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 usar 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 les asigna dinámicamente la VLAN 10 (con acceso exclusivo al sistema de tareas de limpieza). El personal de recepción es asignado a la VLAN 20 (con acceso al sistema de gestión de la propiedad). La administración es asignada a la VLAN 30 (con un acceso más amplio). El WiFi para huéspedes permanece en un SSID separado con un Captive Portal, aislado en la VLAN 40. Cuando un miembro del personal de temporada se va, su cuenta de Entra ID se deshabilita, revocando instantáneamente el acceso a WiFi en todos los puntos de acceso de la propiedad.

Comentario del examinador: Este enfoque elimina la vulnerabilidad de la PSK compartida y el riesgo de que ex-empleados conserven el acceso. La asignación dinámica de VLAN garantiza que un dispositivo de limpieza comprometido no pueda llegar al sistema de gestión de la propiedad. El uso de RADIUS en la nube elimina la necesidad de un servidor físico en el limitado cuarto de TI del hotel. La integración con Entra ID permite que la baja del personal sea una sola acción con efecto inmediato en toda la red.

Una cadena de retail nacional con 400 tiendas necesita garantizar el cumplimiento de PCI DSS para sus terminales de punto de venta. Actualmente gestionan 400 instancias independientes de FreeRADIUS en servidores locales de las tiendas, y cada una requiere parches individuales.

Migrar a una sola instancia de RADIUS as a Service. Configurar los puntos de acceso HPE Aruba en las 400 tiendas para autenticar los dispositivos POS usando EAP-TLS con certificados de máquina distribuidos a través de Microsoft Intune. El servidor RADIUS en la nube autentica los certificados y coloca los dispositivos POS en una VLAN que cumple con PCI (VLAN 30), 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, lo que los coloca en una VLAN de personal general (VLAN 20). Los clientes en la red de invitados están aislados en la VLAN 40. El equipo de seguridad gestiona todas las políticas desde un único panel.

Comentario del examinador: Centralizar la infraestructura RADIUS elimina la carga de mantenimiento que implica aplicar parches a 400 servidores locales. El uso de EAP-TLS para dispositivos POS elimina por completo las contraseñas, evitando 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 en la nube en lugar de que el equipo de seguridad de la cadena de retail tenga que aplicar parches en 400 servidores durante 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 se está migrando a Google Workspace y desea desmantelar 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 de 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 de 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 administrados 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 administrados y de confianza puedan acceder a las redes del personal y los estudiantes. La migración se puede realizar por fases: implementar RADIUS en la nube junto con NPS, migrar un SSID a la vez y luego desmantelar NPS una vez que todos los dispositivos estén utilizando el nuevo servicio.

Q2. Un estadio con capacidad para 80,000 personas requiere WiFi seguro para el personal corporativo, las terminales de venta de boletos, los miembros de la prensa y los contratistas del día del 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 RADIUS maneja 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 según el rol del usuario en el proveedor de identidad. El personal corporativo se asigna a la VLAN 10 con acceso a los sistemas internos. Las terminales de venta de boletos, autenticadas mediante certificados de máquina (EAP-TLS), se colocan en una VLAN 20 restringida con acceso únicamente a la plataforma de boletaje. Los miembros de la prensa se asignan a la VLAN 30 con acceso a internet de alto ancho de banda pero sin acceso a los sistemas internos. Los contratistas del día del evento se asignan a la VLAN 40 con acceso limitado a internet únicamente. Un SSID abierto independiente con un Captive Portal maneja el acceso de invitados de 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 aplicar parches porque la última actualización causó 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 administrado y cómo los proveedores manejan los parches sin tiempo de inactividad.

Ver respuesta modelo

RADIUS como Servicio transfiere la responsabilidad del parche de seguridad del sistema operativo y la gestión de vulnerabilidades al proveedor. El proveedor opera clústeres multirregión de alta disponibilidad, lo que les permite aplicar parches a endpoints individuales y realizar actualizaciones de manera progresiva sin causar tiempo de inactividad de 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 aplica parches a la infraestructura a medida que se revelan las vulnerabilidades, a menudo antes de que la CVE se publique ampliamente. El riesgo operativo se elimina porque el SLA del proveedor garantiza el tiempo de actividad independientemente de la actividad de parchado. El rol de tu equipo cambia de mantenimiento de infraestructura a gestión de políticas.

Continúe leyendo esta serie

Integrating RADIUS as a Service with Cloud Directories (Azure AD & Google Workspace)

This technical reference guide details how to integrate RADIUS as a Service with cloud directories - Microsoft Entra ID and Google Workspace - for enterprise WiFi authentication. It covers the architectural shift from on-premise NPS to cloud-native RADIUS, the deployment of certificate-based EAP-TLS authentication, and the operational best practices for securing wireless access across hospitality, retail, and public-sector environments. For IT managers and network architects already invested in cloud identity, this guide bridges the gap between directory management and physical network security.

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, eliminando al mismo tiempo la carga operativa de la infraestructura local.

¿Qué es Cloud RADIUS? Una guía completa de RADIUS como servicio

Esta guía completa explora Cloud RADIUS (RADIUS como servicio), detallando su arquitectura, métodos 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 basado en la nube que es escalable, seguro y cumple con las normativas.