Cloud RADIUS vs On-Premise RADIUS: Guía de decisión para equipos de TI

Esta guía proporciona a directores de TI, arquitectos de red y equipos de operaciones de recintos un marco definitivo para elegir entre servicios RADIUS alojados en la nube y servidores RADIUS tradicionales on-premise. Cubre la arquitectura técnica, las compensaciones de latencia y fiabilidad, el coste total de propiedad y las consideraciones de cumplimiento para despliegues multisitio en hostelería, comercio minorista y sector público. Al finalizar, los lectores dispondrán de un modelo de decisión claro y alineado con las limitaciones específicas de su infraestructura y el nivel de riesgo aceptable de su organización.

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

Escuchar esta guía

Ver transcripción del podcast

PARTE 1 — INTRODUCCIÓN Y CONTEXTO

Bienvenido a la sesión informativa técnica de Purple. Soy su anfitrión y hoy abordaremos una decisión de infraestructura crítica para centros multi-sitio: Cloud RADIUS frente a RADIUS On-Premise. Si es un director de TI o un arquitecto de redes que gestiona la autenticación para un grupo hotelero, una cadena de tiendas o un gran espacio público, esta sesión le proporcionará el marco de trabajo práctico que necesita para tomar la decisión correcta.

Pongámonos en contexto. RADIUS (Remote Authentication Dial-In User Service) es el guardián de su red. Cada vez que un invitado inicia sesión en su WiFi o un empleado se conecta al SSID corporativo a través de 802.1X, RADIUS es el motor que comprueba sus credenciales en su directorio y autoriza el acceso. Tradicionalmente, esto significaba acumular servidores físicos en su centro de datos, instalar FreeRADIUS o un Network Policy Server propietario y gestionar toda la pila usted mismo. Hoy en día, los servicios Cloud RADIUS ofrecen una alternativa gestionada y distribuida globalmente. Pero, ¿cuál es el adecuado para su despliegue específico? Analicemos las ventajas y desventajas técnicas.

PARTE 2 — ANÁLISIS TÉCNICO DETALLADO

En primer lugar, hablemos de arquitectura y latencia. En un despliegue on-premise, sus puntos de acceso se comunican directamente con un servidor RADIUS local. Para un único gran estadio o un hospital independiente, esto ofrece una latencia increíblemente baja. Las solicitudes de autenticación viajan a través de la LAN local; estamos hablando de viajes de ida y vuelta de menos de un milisegundo. Sin embargo, si se trata de una cadena de tiendas multi-sitio, enrutar todo el tráfico de autenticación de vuelta a un centro de datos central introduce latencia WAN y un único punto de fallo. Si ese enlace WAN se cae, sus sitios remotos no podrán autenticar a los usuarios en absoluto.

Cloud RADIUS cambia este modelo por completo. La infraestructura RADIUS se aloja de forma global en múltiples zonas de disponibilidad. Cuando un usuario se conecta en una sucursal, la solicitud se enruta al nodo perimetral de la nube más cercano. Esto reduce significativamente la latencia para despliegues distribuidos en comparación con el retorno a un servidor on-premise central. Además, los proveedores de la nube incorporan alta disponibilidad por defecto. Si un nodo falla, el tráfico se transfiere automáticamente al siguiente nodo más cercano. Para lograr ese nivel de redundancia on-premise, tendría que desplegar clústeres activo-activo en múltiples centros de datos dispersos geográficamente, lo que requiere un esfuerzo de ingeniería y un gasto de capital significativos.
Ahora, analicemos los costes de mantenimiento y la escalabilidad. Un RADIUS local requiere que su equipo gestione el sistema operativo, aplique parches de seguridad, gestione los certificados SSL y supervise el estado del servidor las 24 horas del día. Cuando necesita escalar para un gran evento (por ejemplo, un estadio que alberga un concierto para 70.000 personas), debe aprovisionar nuevo hardware o máquinas virtuales con antelación. No existe el escalado elástico. Cloud RADIUS se ofrece como un servicio SaaS. El proveedor se encarga de la infraestructura subyacente, los parches y el escalado de forma automática. Usted simplemente gestiona las políticas y las integraciones a través de un panel web o una API. Esto libera a sus ingenieros sénior del mantenimiento rutinario, lo que les permite centrarse en iniciativas estratégicas en lugar de limitarse a mantener los sistemas operativos.

Hablemos de la integración con los proveedores de identidad. Si su directorio de usuarios ya está en la nube (utilizando Azure Active Directory, Google Workspace u Okta), una solución Cloud RADIUS es la opción natural. Se integra a la perfección a través de APIs o conectores seguros. Por el contrario, si dispone de un Active Directory local heredado que no se puede exponer a Internet por motivos de seguridad o conformidad, un servidor RADIUS local podría ser su única opción viable. Puede consultar el AD local directamente sin atravesar el cortafuegos, lo que resulta especialmente relevante en entornos sanitarios o instalaciones gubernamentales donde la soberanía de los datos es un requisito estricto.

Ahora hablemos de la conformidad normativa. La norma PCI DSS exige que los entornos de datos de titulares de tarjetas utilicen una autenticación sólida. El GDPR exige que los datos personales, incluidos los registros de autenticación, se traten de forma adecuada. Los proveedores de Cloud RADIUS suelen ofrecer certificaciones SOC 2 Tipo II, acuerdos de procesamiento de datos conformes al GDPR y opciones de residencia de datos regionales. El modelo local le ofrece un control total sobre dónde residen sus datos, lo que puede resultar ventajoso en sectores altamente regulados. Sin embargo, también significa que la carga de la conformidad recae por completo en su equipo.

Permítame analizar más a fondo la arquitectura técnica de cada enfoque, ya que comprender el funcionamiento interno le ayudará a tomar una decisión más informada.

En un despliegue de RADIUS local tradicional, normalmente se dispone de uno o más servidores que ejecutan el Network Policy Server de Microsoft (comúnmente conocido como NPS) o la plataforma de código abierto FreeRADIUS. Estos servidores se ubican dentro del perímetro de su red y se comunican con sus puntos de acceso a través de UDP, normalmente en el puerto 1812 para la autenticación y en el puerto 1813 para la contabilidad. El secreto compartido entre el punto de acceso y el servidor RADIUS es un elemento de seguridad crítico: debe ser largo, aleatorio y renovarse periódicamente.

FreeRADIUS es el servidor RADIUS más implementado del mundo, y gestiona la autenticación de cientos de millones de usuarios a nivel global. Es altamente configurable, admite una amplia gama de métodos EAP y puede integrarse con prácticamente cualquier directorio backend. Sin embargo, esa flexibilidad tiene un coste: requiere una administración especializada. La configuración incorrecta es una fuente común de fallos de autenticación, y depurar los registros de FreeRADIUS requiere experiencia.

Las plataformas Cloud RADIUS abstraen toda esta complejidad. Internamente, ejecutan una infraestructura RADIUS distribuida en múltiples regiones de la nube, pero usted interactúa con ellas a través de una interfaz web limpia o una API. Usted define sus políticas de autenticación (qué SSIDs se asignan a qué grupos de usuarios, qué métodos EAP están permitidos, cómo gestionar dispositivos desconocidos) y la plataforma se encarga del resto.

Un área donde el RADIUS local sigue teniendo una clara ventaja es en entornos con requisitos de rendimiento de autenticación muy elevados combinados con presupuestos de latencia estrictos. Piense en un gran centro de transporte (un aeropuerto o una estación de tren) donde miles de dispositivos intentan autenticarse simultáneamente a medida que llegan los pasajeros. En este escenario, un clúster RADIUS local puede procesar las solicitudes de autenticación en menos de un milisegundo, mientras que una solicitud de Cloud RADIUS debe viajar por internet de ida y vuelta, lo que añade entre 5 y 50 milisegundos según el nodo perimetral más cercano del proveedor.

PARTE 3 — RECOMENDACIONES DE IMPLEMENTACIÓN Y ERRORES COMUNES

Permítame guiarle a través de dos escenarios del mundo real para concretar esto.

Escenario uno: Un grupo hotelero europeo con 45 propiedades en seis países. El equipo de TI está centralizado, con solo tres ingenieros de redes gestionando todo el patrimonio. Ejecutaban FreeRADIUS en máquinas virtuales en cada propiedad: 45 instancias independientes que parchear, monitorizar y mantener. Cuando caducó un certificado en una propiedad, provocó una interrupción total del WiFi para huéspedes durante una conferencia importante. Migraron a un servicio Cloud RADIUS, centralizando la gestión de políticas y eliminando el mantenimiento por sitio. El equipo de tres ingenieros recuperó aproximadamente el 40 por ciento de su tiempo, que antes dedicaban al mantenimiento de RADIUS.

Escenario dos: Un estadio deportivo nacional con 68.000 asientos. El equipo de TI tiene requisitos estrictos en torno a la soberanía de los datos: todos los registros de autenticación deben permanecer en suelo del Reino Unido. Desplegaron un clúster RADIUS local dual en configuración activo-activo, con un clúster secundario en una instalación de coubicación a 20 millas de distancia. Esto les proporcionó control local, autenticación de menos de un milisegundo y la capacidad de gestionar picos de tráfico sin depender de la conectividad a internet.

Al implementar Cloud RADIUS, el error más común es ignorar la conexión a internet local en el establecimiento. Cloud RADIUS depende por completo del enlace WAN. Para mitigar esto, implemente una estrategia de supervivencia local: almacene en caché las credenciales en el controlador de red local para el personal crítico, o utilice SD-WAN para garantizar la alta disponibilidad del enlace de internet.

Para implementaciones locales (on-premise), el mayor riesgo operativo es la gestión de certificados. Si el certificado de su servidor RADIUS local expira, todos y cada uno de los dispositivos cliente rechazarán la conexión, lo que provocará una interrupción total de la autenticación. Los proveedores de Cloud RADIUS automatizan la rotación de certificados, eliminando este riesgo por completo.

PARTE 4 — PREGUNTAS Y RESPUESTAS RÁPIDAS

Pregunta uno: ¿Admite Cloud RADIUS el bypass de autenticación MAC (MAB) para dispositivos sin interfaz de usuario como impresoras y sensores IoT? Respuesta: Sí. La mayoría de las plataformas Cloud RADIUS empresariales admiten MAB. Puede gestionar las listas de direcciones MAC permitidas a través de su panel de control o API, lo que facilita enormemente la gestión de dispositivos IoT en cientos de ubicaciones.

Pregunta dos: ¿Cómo se compara el coste total de propiedad a lo largo de cinco años? Respuesta: El modelo local requiere un gran gasto de capital (CapEx): hardware, licencias, energía, refrigeración y tiempo de ingeniería. Cloud RADIUS es un gasto operativo (OpEx), que suele facturarse anualmente por usuario o por dispositivo. Para implementaciones multi-sitio en rápido crecimiento, el OpEx predecible de la nube suele ser más rentable. Las organizaciones con más de 10 sitios y menos de 5 ingenieros de red casi siempre obtienen un ROI positivo de la nube en un plazo de 18 meses.

Pregunta tres: ¿Se puede ejecutar un modelo híbrido? Respuesta: Absolutamente. Cloud RADIUS para los SSID de invitados e IoT, y local para el SSID corporativo que se autentica contra el Active Directory interno. Purple WiFi admite este modelo híbrido de forma nativa.

Pregunta cuatro: ¿Qué ocurre durante una interrupción del proveedor de la nube? Respuesta: Los proveedores de Cloud RADIUS de confianza publican acuerdos de nivel de servicio (SLA) con un tiempo de actividad del 99,99 por ciento, respaldados por redundancia multirregión. Configure siempre sus puntos de acceso con una política de respaldo (ya sea acceso abierto a una VLAN restringida o credenciales almacenadas en caché localmente) para gestionar este escenario de forma fluida.

PARTE 5 — RESUMEN Y PRÓXIMOS PASOS

Para resumir el marco de decisión clave: Elija RADIUS local cuando tenga una única ubicación de gran tamaño con requisitos estrictos de soberanía de datos, un entorno de seguridad aislado (air-gapped) o directorios locales heredados que no puedan conectarse a la nube. Elija Cloud RADIUS cuando tenga una presencia distribuida en varios sitios, proveedores de identidad nativos de la nube como Okta o Azure AD, un equipo de TI central pequeño o cuando necesite un despliegue rápido en nuevos sitios sin los plazos de entrega que requiere la adquisición de hardware.

En conclusión: para la mayoría de los operadores de recintos multi-sitio actuales, Cloud RADIUS es la opción operativamente superior. El argumento de la latencia a favor de las soluciones locales ha quedado prácticamente neutralizado por la infraestructura en la nube distribuida globalmente. Antes de tomar una decisión, audite tres aspectos: su proveedor de identidad actual y si es nativo de la nube, la resiliencia de su WAN en cada sitio y la capacidad de su equipo para gestionar el mantenimiento continuo. Esos tres factores le indicarán qué camino es el adecuado para su organización.

Gracias por asistir a esta sesión técnica de Purple. Para profundizar más en la arquitectura de WiFi empresarial, visite nuestra biblioteca de guías en Purple.ai.

Conclusiones clave

✓Cloud RADIUS ofrece alta disponibilidad integrada, rotación automática de certificados y escalabilidad elástica, lo que lo hace operativamente superior para despliegues multisitio con presencia distribuida y equipos de TI centrales reducidos.
✓El RADIUS local sigue siendo la opción correcta para entornos aislados (air-gapped), despliegues con requisitos estrictos de soberanía de datos que ningún proveedor de nube puede satisfacer y recintos de un solo sitio muy grandes donde la autenticación en LAN local de menos de un milisegundo es críticamente operativa.
✓La regla de los 10 sitios: las organizaciones con más de 10 sitios y menos de 5 ingenieros de red casi siempre logran un ROI positivo de Cloud RADIUS en un plazo de 18 meses, impulsado principalmente por la eliminación de los costes indirectos de mantenimiento por sitio.
✓La resiliencia de la WAN es el requisito previo no negociable para el despliegue de Cloud RADIUS. Implemente conectividad ISP dual o conmutación por error de SD-WAN, y configure el almacenamiento en caché de credenciales en los controladores inalámbricos antes de migrar cualquier tráfico de autenticación de producción a la nube.
✓La expiración de los certificados es la causa principal de las interrupciones de RADIUS local y es completamente evitable, ya sea a través de Cloud RADIUS (rotación automatizada) o mediante un proceso de gestión del ciclo de vida de los certificados correctamente implementado con monitorización proactiva a intervalos de 90, 60 y 30 días.
✓El modelo híbrido (Cloud RADIUS para redes de invitados e IoT, y RADIUS local para redes corporativas de empleados) es una arquitectura común y pragmática que aplica la herramienta adecuada a cada caso de uso sin forzar una elección binaria.
✓La plataforma de Purple se integra con backends de RADIUS tanto en la nube como locales, y los datos de eventos de autenticación presentados a través de la capa de analítica de Purple transforman los registros de contabilidad de RADIUS en inteligencia de afluencia accionable para los operadores de recintos.

Resumen Ejecutivo

La autenticación RADIUS es el núcleo de cualquier despliegue de WiFi empresarial. Tanto si está protegiendo el acceso de los empleados a través de IEEE 802.1X como si gestiona el registro de invitados en un patrimonio de recintos multisitio, la decisión de dónde alojar su infraestructura RADIUS tiene consecuencias directas en el tiempo de actividad, los costes operativos y el coste total de propiedad.

Los servicios Cloud RADIUS ofrecen una infraestructura de autenticación gestionada y distribuida globalmente con alta disponibilidad integrada, rotación automática de certificados y escalabilidad elástica, lo que elimina la carga de mantenimiento por sitio que afecta a los despliegues locales distribuidos. RADIUS on-premise, ya sea ejecutando FreeRADIUS o Microsoft NPS, ofrece autenticación local de submilisegundos, soberanía total de los datos e independencia de la conectividad WAN, ventajas que siguen siendo decisivas en entornos específicos regulados o de alta densidad.

Para la mayoría de los operadores multisitio (grupos hoteleros, cadenas de retail, centros de conferencias), Cloud RADIUS ofrece un resultado operativo superior con un coste total de propiedad a cinco años más bajo. Las excepciones están bien definidas: entornos aislados (air-gapped), mandatos estrictos de residencia de datos y despliegues de un solo sitio muy grandes donde el rendimiento de la LAN local es primordial. Esta guía le proporciona el marco para determinar en qué categoría se encuadra su despliegue y cómo actuar en consecuencia.

Análisis Técnico Detallado

El Protocolo RADIUS y su Papel en la Infraestructura 802.1X

RADIUS (Remote Authentication Dial-In User Service, RFC 2865) funciona como el intermediario de autenticación entre su capa de acceso a la red y su directorio de identidad. En un despliegue 802.1X , el punto de acceso o switch actúa como el Servidor de Acceso a la Red (NAS), reenviando las tramas de autenticación EAP al servidor RADIUS a través de UDP (puerto 1812 para autenticación, puerto 1813 para contabilidad). El servidor RADIUS valida las credenciales del suplicante contra un directorio backend (Active Directory, LDAP o un proveedor de identidad en la nube) y devuelve una respuesta Access-Accept o Access-Reject, incluyendo opcionalmente atributos de asignación de VLAN.

Esta arquitectura es fundamentalmente la misma tanto si su servidor RADIUS es un dispositivo montado en rack en su sala de servidores como si es un servicio en la nube distribuido globalmente. La diferencia radica en dónde reside ese servidor, quién lo mantiene y cómo escala.

RADIUS On-Premise: Arquitectura y Compensaciones

Las dos plataformas RADIUS on-premise dominantes son FreeRADIUS y Microsoft Network Policy Server (NPS). FreeRADIUS es el servidor RADIUS más implementado del mundo, compatible con una amplia gama de métodos EAP, incluidos EAP-TLS, PEAP-MSCHAPv2, EAP-TTLS y EAP-PWD. Se integra con prácticamente cualquier directorio backend a través de LDAP, SQL o API, y está disponible sin coste de licencia. Sin embargo, exige una administración especializada: la configuración se basa en archivos, la depuración requiere experiencia en análisis de registros y el escalado en docenas de sitios exige una planificación cuidadosa de la replicación y la tolerancia a fallos.

Microsoft NPS se integra de forma nativa con Active Directory y es la opción predeterminada para entornos centrados en Windows. Admite PEAP-MSCHAPv2 y EAP-TLS de forma nativa y se gestiona a través de la interfaz familiar de Windows Server. La desventaja es el fuerte acoplamiento a las licencias de Windows Server y un conjunto de métodos EAP más limitado en comparación con FreeRADIUS.

Para implementaciones on-premise de alta disponibilidad, las organizaciones suelen desplegar clústeres RADIUS activos-activos o activos-pasivos. Los puntos de acceso se configuran con una dirección de servidor RADIUS principal y otra secundaria; si el principal no responde dentro del tiempo de espera configurado (normalmente de 3 a 5 segundos), el NAS pasa al secundario. Esta arquitectura requiere servidores dispersos geográficamente —lo que introduce su propia complejidad— o un par de servidores en la misma instalación, lo que no protege contra una interrupción a nivel de sitio.

Perfil de latencia: El RADIUS on-premise ofrece tiempos de ida y vuelta de autenticación de menos de 1 milisegundo a través de una LAN local. Para entornos de alta densidad que procesan miles de autenticaciones simultáneas —un estadio de 68.000 asientos durante un evento con entradas agotadas, por ejemplo— esta capacidad de procesamiento local es una ventaja operativa real.

Cloud RADIUS: Arquitectura y Compensaciones

Las plataformas Cloud RADIUS alojan la infraestructura RADIUS en múltiples zonas de disponibilidad distribuidas geográficamente. Cuando un punto de acceso envía una solicitud de autenticación, esta se enruta al nodo perimetral de la nube más cercano, lo que suele añadir entre 5 y 50 milisegundos de latencia de ida y vuelta, dependiendo de la proximidad del punto de presencia del proveedor al sitio. Para la gran mayoría de los casos de uso de autenticación, esta latencia es imperceptible para los usuarios finales.

El modelo de alta disponibilidad es fundamentalmente diferente al local (on-premise). En lugar de configurar un par primario/secundario, el equilibrador de carga de la plataforma en la nube redirige automáticamente las solicitudes fuera de los nodos con fallos. Los proveedores de Cloud RADIUS empresariales suelen publicar SLA de 99,99% de tiempo de actividad, respaldados por redundancia multirregión. Lograr una redundancia equivalente de forma local requiere desplegar clústeres activo-activo en múltiples centros de datos dispersos geográficamente, lo que supone una inversión de capital y de ingeniería significativa.

Las plataformas Cloud RADIUS se integran de forma nativa con los proveedores de identidad en la nube. Si su organización utiliza Okta, Azure Active Directory o Google Workspace, un servicio Cloud RADIUS se conecta a través de SAML, LDAP-over-TLS o conectores API propios. Para obtener un tutorial detallado sobre la integración específica con Okta, consulte nuestra guía: Okta and RADIUS: Extending Your Identity Provider to WiFi Authentication .

La gestión de certificados es uno de los argumentos operativos más convincentes a favor de Cloud RADIUS. Tanto EAP-TLS como PEAP dependen de certificados digitales en el lado del servidor. En entornos locales, la expiración de los certificados es una de las principales causas de interrupciones en la autenticación: la expiración de un certificado en un servidor FreeRADIUS hace que todos los clientes conectados rechacen la identidad del servidor, lo que provoca una caída total de la red WiFi hasta que el certificado se renueva y se despliega. Los proveedores de Cloud RADIUS automatizan por completo la rotación de certificados, eliminando este tipo de fallos.

Consideraciones sobre WPA3-Enterprise y protocolos

La especificación WPA3-Enterprise de la WiFi Alliance introduce un modo de seguridad de 192 bits que exige EAP-TLS con criptografía Suite B (ECDHE, ECDSA, AES-256-GCM). Esto es cada vez más relevante para despliegues en los sectores sanitario, financiero y gubernamental. La mayoría de las plataformas Cloud RADIUS modernas son compatibles con WPA3-Enterprise de forma nativa. Los despliegues locales que ejecutan versiones de FreeRADIUS más antiguas (anteriores a la 3.0.x) o configuraciones NPS heredadas pueden requerir actualizaciones antes de poder desplegar WPA3-Enterprise. Si WPA3-Enterprise está en su hoja de ruta, valide la compatibilidad de su plataforma RADIUS antes de comprometerse con una infraestructura específica.

Para las organizaciones que estén considerando la capa SD-WAN que sustenta los despliegues de Cloud RADIUS multisitio, nuestra guía sobre The Core SD-WAN Benefits for Modern Businesses proporciona un contexto complementario sobre la arquitectura de resiliencia WAN.

Guía de implementación

Paso 1: Audite sus dependencias de autenticación actuales

Antes de seleccionar un modelo de despliegue, documente cada SSID, VLAN, método EAP y directorio backend con el que interactúa su infraestructura de autenticación actual. Incluya las políticas de derivación de autenticación MAC (MAB) para dispositivos sin interfaz de usuario (impresoras, sensores IoT, terminales de punto de venta), ya que con frecuencia se pasan por alto durante las migraciones y pueden causar incidentes significativos tras la transición.### Paso 2: Evaluar la preparación del proveedor de identidad

Si su directorio de usuarios es un Active Directory local y no se puede sincronizar con un IdP en la nube, sus opciones de Cloud RADIUS se limitan a plataformas que admitan proxy LDAP para directorios locales. Si puede implementar Azure AD Connect o una herramienta de sincronización similar, tendrá a su disposición toda la gama de plataformas Cloud RADIUS. Esta única decisión (IdP en la nube frente a directorio local) suele ser el factor determinante en la elección de un RADIUS en la nube o local.

Paso 3: Evaluar la resiliencia de la WAN en cada ubicación

Cloud RADIUS es tan fiable como la conexión a Internet de cada ubicación. Antes de realizar la migración, audite la conectividad WAN en cada centro. Las ubicaciones con una única conexión de ISP y sin conmutación por error representan un riesgo significativo. Implemente una conectividad de doble ISP o una conmutación por error de SD-WAN antes de desplegar Cloud RADIUS como su infraestructura de autenticación principal. Para entornos de retail donde los sistemas de punto de venta dependen de la autenticación de red, la resiliencia de la WAN es innegociable.

Paso 4: Planificar la migración de certificados (despliegues locales)

Si va a implementar o mantener un RADIUS local con EAP-TLS, establezca un proceso de gestión del ciclo de vida de los certificados. Implemente alertas de monitorización a los 90, 60 y 30 días antes de la expiración del certificado. Considere la posibilidad de implementar una PKI interna (como Microsoft ADCS o HashiCorp Vault) para automatizar la emisión y renovación de certificados. Nunca confíe únicamente en los recordatorios del calendario para la gestión de certificados en entornos de producción.

Paso 5: Configurar políticas de supervivencia

Para despliegues de Cloud RADIUS, configure una política de supervivencia local en sus controladores inalámbricos o puntos de acceso. Las opciones incluyen: almacenar en caché el último estado de autenticación conocido durante un periodo configurable, recurrir a MAC Authentication Bypass para listas de dispositivos preaprobados o enrutar los SSID del personal crítico a través de una ruta de autenticación secundaria. Para los operadores de hospitality , asegúrese de que el registro de invitados a la WiFi a través de plataformas como el Guest WiFi de Purple tenga un comportamiento de contingencia definido durante la indisponibilidad de RADIUS.

Paso 6: Ejecutar un despliegue en paralelo

Despliegue la nueva plataforma RADIUS en paralelo con la infraestructura existente. Cree un SSID de prueba dedicado asignado al nuevo servidor RADIUS y valide todos los métodos EAP, asignaciones de VLAN y aplicación de políticas antes de migrar los SSID de producción. Este periodo de ejecución en paralelo debe ser de un mínimo de dos semanas para un despliegue en una sola ubicación y de cuatro a seis semanas para una migración multi-sitio.

Paso 7: Ejecutar una migración gradual por ubicaciones

Para despliegues multi-sitio, migre las ubicaciones de forma secuencial en lugar de simultánea. Comience con los centros de menor riesgo (ubicaciones más pequeñas con menos tráfico y usuarios más tolerantes) antes de migrar las ubicaciones de alta prioridad, como tiendas insignia o establecimientos hoteleros con gran volumen de conferencias. Documente el procedimiento de reversión para cada ubicación antes de comenzar la transición.

Buenas prácticas

Higiene de secretos compartidos: Los secretos compartidos de RADIUS entre los puntos de acceso y el servidor RADIUS deben tener un mínimo de 32 caracteres, ser generados aleatoriamente y ser únicos por dispositivo NAS. Reutilizar secretos compartidos en todos los puntos de acceso significa que comprometer un solo dispositivo expone toda la infraestructura de autenticación. Rote los secretos compartidos anualmente o tras cualquier sospecha de compromiso.

Segmentación de VLAN: Utilice VLAN asignadas por RADIUS (a través de los atributos Tunnel-Type, Tunnel-Medium-Type y Tunnel-Private-Group-ID) para segmentar dinámicamente el tráfico según el rol del usuario. Los dispositivos de invitados deben ubicarse en una VLAN aislada con acceso exclusivo a internet; los dispositivos corporativos, en la VLAN de producción; los dispositivos IoT, en una VLAN restringida dedicada. Esta segmentación es un requisito de PCI DSS para cualquier red que gestione datos de titulares de tarjetas.

Contabilidad y registro de auditoría: Habilite la contabilidad de RADIUS (puerto 1813) y conserve los registros de contabilidad durante un mínimo de 12 meses. Estos registros guardan las horas de inicio y finalización de las sesiones, los volúmenes de datos y las direcciones IP asignadas, lo cual es esencial para la investigación de incidentes de seguridad y el cumplimiento de GDPR. Las plataformas Cloud RADIUS suelen exportar los datos de contabilidad a sistemas SIEM a través de syslog o API; las implementaciones locales deben dirigir los datos de contabilidad a una plataforma de gestión de registros centralizada.

Selección del método EAP: Para las redes de empleados corporativos, EAP-TLS (basado en certificados) proporciona el nivel de seguridad más sólido y se recomienda para entornos de PCI DSS y del sector sanitario. PEAP-MSCHAPv2 es aceptable para entornos de menor riesgo, pero es vulnerable a ataques de recolección de credenciales si el certificado del servidor no es validado correctamente por los suplicantes. Evite por completo EAP-MD5: está obsoleto y no proporciona autenticación mutua.

RadSec (RADIUS sobre TLS): El protocolo RADIUS tradicional transmite datos sobre UDP con solo el atributo User-Password cifrado. RadSec (RFC 6614) envuelve RADIUS en TLS, proporcionando un cifrado de transporte completo y autenticación mutua entre el NAS y el servidor RADIUS. La mayoría de las plataformas Cloud RADIUS modernas son compatibles con RadSec. Para nuevas implementaciones, RadSec debería ser la opción de transporte predeterminada.

Para implementaciones en los sectores de sanidad y transporte , donde las obligaciones de gestión de datos bajo GDPR y las normativas específicas del sector son especialmente estrictas, asegúrese de que su plataforma RADIUS proporcione un Acuerdo de Procesamiento de Datos y admita la residencia de datos regional.

Resolución de problemas y mitigación de riesgos

Modo de fallo común 1: Caducidad del certificado (local)

Síntoma: Todos los clientes fallan repentinamente al autenticarse; los registros de RADIUS muestran fallos en el saludo TLS.

Causa raíz: El certificado del lado del servidor en el servidor RADIUS ha caducado. Los suplicantes del cliente rechazan la identidad del servidor.

Mitigación: Implemente una supervisión automatizada de certificados con alertas a los 90, 60 y 30 días. Utilice una CA interna con renovación automatizada. Cloud RADIUS elimina por completo este modo de fallo mediante la rotación automatizada de certificados.

Modo de fallo común 2: Interrupción de la WAN que bloquea Cloud RADIUS

Síntoma: La autenticación falla en un sitio específico; otros sitios no se ven afectados. La red local está operativa.

Causa raíz: La conexión a Internet del sitio ha fallado, lo que impide que los puntos de acceso se comuniquen con el servicio Cloud RADIUS.

Mitigación: Implemente conectividad de doble ISP o SD-WAN con conmutación por error automática. Configure políticas de supervivencia en los puntos de acceso para almacenar en caché las credenciales o recurrir a MAB para dispositivos críticos.

Modo de fallo común 3: Discrepancia en el secreto compartido (Shared Secret)

Síntoma: Las solicitudes de autenticación se descartan silenciosamente; los registros de RADIUS muestran errores de "autenticador no válido" o "autenticador de mensajes".

Causa raíz: El secreto compartido configurado en el punto de acceso no coincide con el secreto configurado en el servidor RADIUS.

Mitigación: Utilice un sistema de gestión de secretos centralizado (HashiCorp Vault, AWS Secrets Manager) para garantizar la coherencia. Valide los secretos compartidos después de cualquier cambio de configuración en el NAS o en el servidor RADIUS.

Modo de fallo común 4: Error de configuración del suplicante

Síntoma: Dispositivos individuales no logran autenticarse mientras que otros en el mismo SSID lo hacen correctamente.

Causa raíz: El suplicante 802.1X en el dispositivo que falla no está configurado para confiar en el certificado del servidor RADIUS, o está configurado para un método EAP incompatible.

Mitigación: Implemente la configuración del suplicante a través de MDM o directivas de grupo para garantizar la coherencia. Para entornos BYOD, proporcione una guía de incorporación clara. La plataforma WiFi Analytics de Purple puede ayudar a identificar patrones de fallos de autenticación en todo su parque de dispositivos.

Modo de fallo común 5: Tiempo de espera de RADIUS agotado bajo carga

Síntoma: Retrasos o fallos de autenticación durante periodos de máxima actividad (inicio de eventos, cambios de turno).

Causa raíz: El servidor RADIUS está saturado por solicitudes de autenticación simultáneas; se supera el tiempo de espera del NAS antes de recibir una respuesta.

Mitigación: Local (on-premise): aumente la capacidad del servidor RADIUS antes de eventos de máxima actividad conocidos; implemente la limitación de la tasa de conexión en los puntos de acceso. Cloud RADIUS: verifique que su nivel de suscripción admita su rendimiento máximo de autenticación; la mayoría de las plataformas en la nube empresariales se escalan automáticamente.

ROI e impacto empresarial

Coste total de propiedad: Comparativa a cinco años

El siguiente análisis se basa en una cadena minorista representativa de 20 sitios con aproximadamente 50 puntos de acceso por sitio y 200 dispositivos autenticados simultáneamente por sitio en horas punta.

Componente de coste	RADIUS local (20 sitios)	Cloud RADIUS (20 sitios)
Hardware (servidores, pares HA)	80.000 €–120.000 €	0 €
Licencias de SO y software	10.000 €–30.000 €	0 €
Suscripción anual	0 €	18.000 €–40.000 €/año
Energía y refrigeración (5 años)	15.000 €–25.000 €	0 €
Tiempo de ingeniería (5 años)	60.000 €–100.000 €	10.000 €–20.000 €
Total a 5 años	165.000 €–275.000 €	100.000 €–220.000 €
El diferencial de tiempo de ingeniería es el factor más significativo. El RADIUS on-premise en 20 ubicaciones requiere parches continuos, gestión de certificados, monitorización y respuesta a incidentes. Cloud RADIUS reduce esto a la gestión de políticas y al mantenimiento de la integración, una fracción del esfuerzo.

Medición del éxito

Los indicadores clave de rendimiento para su despliegue de RADIUS deben incluir: tasa de éxito de autenticación (objetivo: >99,5 % para entornos de producción), latencia media de autenticación (objetivo: <100 ms para la nube, <5 ms para LAN on-premise), tiempo medio de recuperación ante caídas de autenticación (objetivo: <15 minutos) e incidentes por expiración de certificados (objetivo: cero, alcanzable con una automatización adecuada).

Para los operadores de hostelería que utilizan la plataforma Guest WiFi de Purple, la fiabilidad de la infraestructura de autenticación afecta directamente a las puntuaciones de satisfacción de los huéspedes. Un retraso de autenticación de 2 segundos durante los períodos de máxima afluencia en el registro de entrada es medible en los comentarios de los huéspedes. Cloud RADIUS con políticas de supervivencia correctamente configuradas supera sistemáticamente a los despliegues on-premise ad-hoc en esta métrica.

Las organizaciones que han migrado de despliegues distribuidos de FreeRADIUS on-premise a Cloud RADIUS informan sistemáticamente de una reducción del 30-50 % en los incidentes de TI relacionados con la autenticación y de una reducción significativa en las horas de ingeniería asignadas al mantenimiento de RADIUS, horas que se reasignan a proyectos estratégicos de mejora de la red. La plataforma de Purple, que se integra con ambos modelos de despliegue, proporciona los datos de WiFi Analytics y Sensors para cuantificar estas mejoras con respecto a las métricas de referencia registradas antes de la migración.

Para los operadores de recintos que consideran el contexto más amplio de la modernización de la red, las capacidades de Wayfinding de Purple y la integración de los datos de autenticación con las analíticas de afluencia representan la siguiente capa de valor que permite una infraestructura RADIUS bien estructurada. Los eventos de autenticación son, en su esencia, datos de presencia y, cuando se muestran a través de la capa de analítica de Purple, se convierten en una herramienta potente para comprender el comportamiento de los visitantes, el tiempo de permanencia y las tasas de visitas recurrentes en todo su patrimonio.

Definiciones clave

RADIUS (Remote Authentication Dial-In User Service)

Un protocolo de red (RFC 2865) que proporciona autenticación, autorización y contabilidad (AAA) centralizadas para los usuarios que se conectan a una red. RADIUS funciona sobre UDP y actúa como intermediario entre los equipos de acceso a la red (puntos de acceso, switches) y el directorio de identidades (Active Directory, LDAP, IdP en la nube).

Los equipos de TI se encuentran con RADIUS siempre que despliegan la autenticación 802.1X para redes WiFi o cableadas. Es el protocolo fundamental para el control de acceso a redes empresariales y es necesario para los despliegues de WPA2-Enterprise y WPA3-Enterprise.

802.1X

Un estándar IEEE para el control de acceso a la red basado en puertos que define el marco para la autenticación basada en EAP. En el contexto de una red WiFi, 802.1X requiere tres componentes: el suplicante (dispositivo cliente), el autenticador (punto de acceso) y el servidor de autenticación (RADIUS). El punto de acceso bloquea todo el tráfico del cliente hasta que RADIUS devuelve un Access-Accept.

802.1X es el mecanismo de autenticación para redes WPA2-Enterprise y WPA3-Enterprise. Los equipos de TI lo utilizan para garantizar que solo los dispositivos y usuarios autorizados puedan conectarse a la WiFi corporativa, con asignación dinámica de VLAN basada en la identidad del usuario.

EAP (Extensible Authentication Protocol)

Un marco de autenticación flexible utilizado dentro de 802.1X que admite múltiples métodos de autenticación. Los métodos EAP comunes incluyen EAP-TLS (basado en certificados, la seguridad más sólida), PEAP-MSCHAPv2 (basado en contraseña con validación de certificado de servidor) y EAP-TTLS (autenticación de contraseña tunelizada).

La elección del método EAP afecta directamente al nivel de seguridad y a la complejidad del despliegue. EAP-TLS requiere certificados de cliente en cada dispositivo, lo que hace que su despliegue sea más complejo pero significativamente más resistente a los ataques de robo de credenciales. Los equipos de TI de sectores regulados (sanidad, finanzas) deberían optar por defecto por EAP-TLS.

FreeRADIUS

El servidor RADIUS de código abierto más implantado del mundo, que gestiona la autenticación de cientos de millones de usuarios a nivel global. FreeRADIUS admite una amplia gama de métodos EAP e integraciones de backend, está disponible sin coste de licencia y se ejecuta en Linux. Requiere una administración cualificada y una configuración basada en archivos.

FreeRADIUS es la opción predeterminada para despliegues de RADIUS locales en entornos que no son de Microsoft. Los equipos de TI que evalúen la decisión entre la nube y el entorno local deben valorar si disponen de la experiencia interna necesaria para operar FreeRADIUS de forma eficaz, ya que una configuración incorrecta es una de las principales causas de incidentes de autenticación.

NPS (Network Policy Server)

El servidor RADIUS integrado de Microsoft, incluido con Windows Server. NPS se integra de forma nativa con Active Directory y admite PEAP-MSCHAPv2 y EAP-TLS. Se gestiona a través de la interfaz gráfica de Windows Server y es la opción RADIUS predeterminada para entornos centrados en Microsoft.

Los equipos de TI que gestionan infraestructuras de Windows Server suelen desplegar NPS como su servidor RADIUS local. NPS está estrechamente vinculado a las licencias de Windows Server y a Active Directory, lo que simplifica el despliegue en entornos Microsoft pero limita la flexibilidad en entornos heterogéneos o nativos de la nube.

MAC Authentication Bypass (MAB)

Un método de autenticación que utiliza la dirección MAC de un dispositivo como credencial, lo que permite que los dispositivos sin interfaz de usuario (impresoras, sensores IoT, terminales de punto de venta) que no pueden ejecutar un suplicante 802.1X se autentiquen en la red. La dirección MAC se comprueba con una lista de permitidos en el servidor RADIUS.

MAB es esencial para cualquier red con dispositivos IoT o equipos heredados. Los equipos de TI deben mantener inventarios precisos de direcciones MAC e implementar procesos para añadir nuevos dispositivos. Las plataformas Cloud RADIUS suelen ofrecer un panel de control centralizado para la gestión de listas MAB en todos los centros, lo que resulta significativamente más eficiente que la gestión de archivos de configuración por centro en FreeRADIUS.

RadSec (RADIUS over TLS)

Una extensión del protocolo RADIUS (RFC 6614) que transporta paquetes RADIUS sobre TLS en lugar de UDP. RadSec proporciona cifrado de transporte completo y autenticación mutua entre el NAS y el servidor RADIUS, resolviendo varias vulnerabilidades de seguridad bien documentadas en el protocolo tradicional RADIUS basado en UDP.

El RADIUS tradicional cifra únicamente el atributo User-Password; todos los demás atributos, incluidos los nombres de usuario y los datos de la sesión, se transmiten en texto plano. RadSec es el mecanismo de transporte moderno y seguro para RADIUS y es compatible con la mayoría de las plataformas Cloud RADIUS empresariales y proveedores de puntos de acceso modernos. Los equipos de TI que desplieguen una nueva infraestructura RADIUS deberían evaluar RadSec como transporte por defecto.

VLAN Assignment (RADIUS-assigned VLAN)

Una capacidad de RADIUS que asigna dinámicamente un dispositivo de conexión a una VLAN específica en función del resultado de la autenticación. El servidor RADIUS devuelve los atributos Tunnel-Type (13=VLAN), Tunnel-Medium-Type (6=802) y Tunnel-Private-Group-ID (VLAN ID) en la respuesta Access-Accept, y el punto de acceso coloca el dispositivo en la VLAN especificada.

La asignación dinámica de VLAN es el mecanismo mediante el cual los equipos de TI implementan la segmentación de red basada en la identidad del usuario. Un único SSID puede dar servicio a múltiples tipos de usuarios (invitados, empleados, contratistas, dispositivos IoT), y cada tipo se coloca automáticamente en la VLAN adecuada en función del resultado de su autenticación RADIUS. Este es un requisito de PCI DSS para las redes que gestionan datos de titulares de tarjetas.

High Availability (HA) RADIUS

Una arquitectura de despliegue de RADIUS que garantiza que los servicios de autenticación sigan estando disponibles a pesar de los fallos individuales de los servidores. Los patrones comunes de HA incluyen la agrupación activo-activo (ambos servidores gestionan el tráfico simultáneamente, con equilibrio de carga), la conmutación por error activo-pasivo (el servidor secundario toma el control cuando falla el primario) y la redundancia distribuida geográficamente (servidores en ubicaciones físicas independientes).

La alta disponibilidad (HA) es una consideración de diseño crítica para cualquier despliegue de RADIUS en producción. Los equipos de TI deben definir su Objetivo de Tiempo de Recuperación (RTO) —con qué rapidez debe restablecerse la autenticación tras un fallo— y diseñar su arquitectura de HA en consecuencia. Los proveedores de Cloud RADIUS ofrecen HA como un servicio integrado; la HA local requiere un diseño arquitectónico explícito y un mantenimiento continuo.

Ejemplos prácticos

Un grupo hotelero europeo opera 45 propiedades en seis países. Cada propiedad tiene entre 150 y 400 habitaciones para huéspedes, además de instalaciones para conferencias. El equipo de TI central está formado por tres ingenieros de redes. Actualmente ejecutan FreeRADIUS en máquinas virtuales en cada propiedad (45 instancias independientes). La expiración de un certificado en una propiedad provocó una caída total del WiFi de invitados durante una conferencia importante. El CTO quiere eliminar este tipo de incidentes y reducir los costes de mantenimiento. ¿Cuál es la arquitectura recomendada?

Arquitectura recomendada: Cloud RADIUS con integración de Purple Guest WiFi

Seleccione un proveedor de Cloud RADIUS con residencia de datos europea (para cumplir con las obligaciones del GDPR) e integración nativa con su IdP existente. Si el grupo hotelero utiliza Azure AD para la identidad del personal, seleccione una plataforma compatible con el conector LDAP de Azure AD.
Migre primero los SSID de WiFi de invitados. La autenticación de invitados es el objetivo de migración con mayor volumen y menor riesgo. Configure el Captive Portal de Purple para gestionar el registro de invitados (captura de datos, consentimiento, página de bienvenida personalizada) y transferir las sesiones autenticadas al backend de Cloud RADIUS. Esto elimina de inmediato el mantenimiento de FreeRADIUS por propiedad para la red de invitados.
Migre los SSID del personal propiedad por propiedad, comenzando por las propiedades más pequeñas. Para cada propiedad, ejecute un despliegue en paralelo de dos semanas con un SSID de prueba antes de transferir el tráfico de producción.
Configure la supervivencia de la WAN en cada propiedad. Implemente conectividad SD-WAN o doble ISP. Configure el controlador inalámbrico para almacenar localmente en caché las credenciales del personal hasta un máximo de 8 horas, garantizando que el personal operativo del hotel pueda autenticarse incluso durante breves interrupciones de internet.
Desmantele las VM de FreeRADIUS en cada propiedad tras la migración. Conserve las instantáneas de las VM durante 30 días como red de seguridad para una posible reversión.
Centralice la gestión de políticas a través del panel de control de Cloud RADIUS. Defina las políticas de asignación de VLAN una sola vez y aplíquelas en las 45 propiedades, una tarea que antes requería editar los archivos de configuración de cada propiedad.

Resultados esperados: Eliminación de los incidentes por expiración de certificados (rotación automatizada), reducción del tiempo de ingeniería relacionado con RADIUS en aproximadamente un 40% y mejora de la latencia de autenticación en las propiedades de los países donde el proveedor de la nube dispone de nodos perimetrales locales.

Comentario del examinador: Este escenario es el caso de uso canónico para la migración a Cloud RADIUS. Los factores clave de decisión son la presencia distribuida en múltiples ubicaciones (45 propiedades), el pequeño equipo central de TI (3 ingenieros) y el problema específico de los fallos en la gestión de certificados. El enfoque de migración por fases (primero los SSID de invitados y luego los del personal) es la mejor práctica porque limita el radio de impacto durante la transición. El requisito de supervivencia de la WAN es crítico para el sector hotelero: un hotel que no pueda autenticar al personal en la VLAN del sistema de gestión de la propiedad durante una caída de internet se enfrenta a graves consecuencias operativas. Se consideró la alternativa de mantener FreeRADIUS de forma local, pero se rechazó porque perpetúa la carga de mantenimiento y no resuelve la causa raíz de la gestión de certificados.

Un estadio deportivo nacional con 68.000 asientos alberga 30 eventos importantes al año. El pico de usuarios simultáneos de WiFi supera los 25.000 durante los partidos con entradas agotadas. El estadio dispone de una conexión dedicada a internet de 10 Gbps, pero el equipo de seguridad de TI tiene un requisito estricto: todos los registros de autenticación deben permanecer en suelo británico y no deben atravesar la red pública de internet. El estadio también opera una red de puntos de venta que cumple con la normativa PCI DSS para las concesiones. ¿Qué arquitectura RADIUS es la adecuada?

Arquitectura recomendada: RADIUS local con clúster Activo-Activo y recuperación ante desastres en Co-Location

Despliegue un clúster RADIUS activo-activo principal dentro de la sala de datos local del estadio. Utilice dos servidores físicos que ejecuten FreeRADIUS en configuración activo-activo, con equilibrio de carga a través de la lista de servidores RADIUS del controlador inalámbrico. Cada servidor debe ser capaz de gestionar toda la carga de autenticación de forma independiente (dimensionado para más de 3.000 autenticaciones por minuto en el momento de máxima afluencia al evento).
Despliegue un clúster secundario en una instalación de co-location en el Reino Unido a menos de 30 millas del estadio, conectado a través de un enlace WAN privado dedicado (no por internet público). Esto proporciona recuperación ante desastres a nivel de sitio sin infringir el requisito de soberanía de datos.
Segmente el entorno PCI DSS con una política RADIUS dedicada para el SSID de los puntos de venta. Asigne los dispositivos de punto de venta a una VLAN dedicada mediante atributos RADIUS. Asegúrese de que los registros de contabilidad de RADIUS para la autenticación de los puntos de venta se conserven durante un mínimo de 12 meses, almacenados localmente de conformidad con el requisito 10 de PCI DSS.
Implemente EAP-TLS para toda la autenticación del personal y de los dispositivos de punto de venta. Despliegue una Autoridad de Certificación interna (Microsoft ADCS o equivalente) para emitir y gestionar los certificados de cliente. Configure la renovación automatizada de certificados con alertas anticipadas de 90 días.
Despliegue RadSec (RADIUS sobre TLS) entre los puntos de acceso y el clúster RADIUS local para cifrar el tráfico de autenticación en la red interna, algo especialmente importante dado el entorno público de alta densidad.
Preaprovisione la capacidad antes de los eventos importantes. Colabore con el equipo de operaciones de eventos del estadio para recibir las cifras de asistencia confirmadas con 72 horas de antelación y valide la capacidad del servidor RADIUS frente a las tasas de pico de autenticación previstas.

Resultados esperados: Latencia de autenticación inferior al milisegundo durante el pico de entrada al evento, cumplimiento total de la soberanía de datos, registro de autenticación conforme a PCI DSS y una disponibilidad superior al 99,99% a través de la arquitectura de clúster activo-activo.

Comentario del examinador: Este escenario representa el argumento más sólido que queda para optar por un RADIUS local. La combinación de los requisitos de soberanía de datos, el cumplimiento de PCI DSS, la carga máxima extrema y una conexión dedicada a internet de gran ancho de banda hace que la opción local sea la correcta. El sitio de recuperación ante desastres en co-location es esencial: un despliegue local en un único sitio sin redundancia externa no cumpliría con los estándares de disponibilidad empresarial. La clave es que el requisito de soberanía de datos del estadio es una restricción estricta que descarta a la mayoría de los proveedores de Cloud RADIUS (que enrutan el tráfico a través de una infraestructura global). La recomendación de EAP-TLS sobre PEAP se debe al entorno PCI DSS: la autenticación basada en certificados ofrece un nivel de seguridad más sólido para los entornos de datos de titulares de tarjetas.

Preguntas de práctica

Q1. Una cadena nacional de farmacias opera 320 tiendas en todo el Reino Unido. Cada tienda tiene una única conexión a internet de un ISP principal sin failover. La cadena utiliza Microsoft 365 y Azure Active Directory para la identidad de todo el personal. El equipo de TI, compuesto por 8 ingenieros, gestiona actualmente instancias de FreeRADIUS en una máquina virtual en cada tienda. El CISO ha señalado que el 23% de las tiendas tienen certificados RADIUS que caducarán en un plazo de 90 días. El CTO quiere resolver esto y reducir los costes de mantenimiento continuo. ¿Qué arquitectura RADIUS recomienda y cuál es el cambio de infraestructura más crítico que se requiere antes de la migración?

Sugerencia: Considere detenidamente el requisito de resiliencia de la WAN: ¿qué ocurre con las operaciones en las tiendas si la conexión a internet falla después de implementar Cloud RADIUS?

Ver respuesta modelo

Arquitectura recomendada: Cloud RADIUS integrado con Azure Active Directory, reemplazando las 320 instancias de FreeRADIUS. La integración con Azure AD es sencilla dada la implementación existente de Microsoft 365, y Cloud RADIUS elimina la crisis de gestión de certificados de inmediato mediante la rotación automatizada.

Cambio crítico de infraestructura antes de la migración: Resiliencia de la WAN. Actualmente, cada tienda tiene una única conexión ISP sin failover. Cloud RADIUS depende por completo de la conectividad a internet. Antes de migrar cualquier tienda, implemente SD-WAN con failover de doble ISP o, como mínimo, configure el controlador inalámbrico para almacenar en caché las credenciales del personal localmente durante 8-12 horas. Sin esto, una tienda que pierda la conectividad a internet no podrá autenticar al personal en la red corporativa, lo que podría bloquear el acceso a los sistemas de punto de venta, la gestión de inventario y otras operaciones que dependen de la red.

Secuencia de migración: (1) Implementar SD-WAN o almacenamiento en caché de credenciales en las 320 tiendas. (2) Migrar primero el 23% de las tiendas con caducidad inminente de certificados; esto aborda el riesgo inmediato. (3) Migrar las tiendas restantes en lotes de 20-30 por semana. (4) Desmantelar las VM de FreeRADIUS después de la migración. Resultado esperado: cero incidentes de caducidad de certificados, reducción del 60-70% en el tiempo de ingeniería relacionado con RADIUS y gestión centralizada de políticas en las 320 tiendas.

Q2. Un operador de centros de conferencias gestiona un único recinto emblemático con capacidad para 5.000 delegados. El recinto alberga 200 eventos al año, que van desde pequeñas reuniones de juntas directivas hasta grandes conferencias internacionales. El pico de usuarios concurrentes de WiFi alcanza los 4.500 durante los eventos principales. El recinto dispone de una conexión a internet dedicada de 1 Gbps con un SLA del 99,9%. El equipo de TI está formado por dos ingenieros de redes. No existen requisitos específicos de soberanía de datos. El servidor FreeRADIUS on-premise actual se acerca al final de su vida útil. ¿Deberían sustituirlo por una nueva implementación on-premise o migrar a Cloud RADIUS?

Sugerencia: Considere tanto el perfil de carga máxima como el tamaño del equipo. ¿Son 4.500 usuarios concurrentes en un solo sitio un argumento sólido para una solución on-premise, o el tamaño del equipo y los costes de gestión inclinan la balanza?

Ver respuesta modelo

Arquitectura recomendada: Cloud RADIUS. A pesar del perfil de sitio único y alta densidad, la combinación de un equipo de TI pequeño (2 ingenieros), la ausencia de requisitos de soberanía de datos y una conexión a internet dedicada y fiable hace que Cloud RADIUS sea la opción más sólida.

Justificación: La carga máxima de 4.500 usuarios concurrentes está muy dentro de la capacidad de procesamiento de las plataformas Cloud RADIUS empresariales, diseñadas para volúmenes mucho mayores. La latencia adicional de 5 a 20 ms del enrutamiento en la nube es imperceptible en un entorno de conferencias. La conexión a internet dedicada de 1 Gbps con un SLA del 99,9% proporciona suficiente fiabilidad WAN para la dependencia de Cloud RADIUS.

El factor decisivo es el tamaño del equipo. Que dos ingenieros gestionen la sustitución de un FreeRADIUS on-premise (incluyendo la adquisición de hardware, el endurecimiento del sistema operativo, la gestión de certificados, la configuración de EAP y el mantenimiento continuo) representa una carga de trabajo constante y significativa para un equipo pequeño. Cloud RADIUS reduce esto a la gestión de políticas, liberando a ambos ingenieros para las necesidades más amplias de la infraestructura de red del recinto.

Nota de implementación: Configure el almacenamiento en caché de credenciales en el controlador inalámbrico para el SSID del personal de operaciones del recinto, proporcionando redundancia durante cualquier interrupción breve de internet. Asegúrese de que el proveedor de Cloud RADIUS tenga un nodo perimetral en el Reino Unido o Europa para minimizar la latencia de autenticación en el escenario de eventos de alta densidad.

Q3. Un consorcio regional del NHS gestiona 12 centros hospitalarios en un condado. Los requisitos de autenticación incluyen: (1) acceso del personal a la red clínica mediante 802.1X con EAP-TLS, (2) WiFi para invitados/pacientes mediante Captive Portal, y (3) autenticación de dispositivos médicos mediante MAC Authentication Bypass. El equipo de gobernanza de la información del consorcio ha establecido que todos los datos relacionados con los pacientes, incluidos los registros de autenticación, deben permanecer dentro de centros de datos aprobados por el NHS en Inglaterra. El consorcio utiliza Active Directory on-premise sin planes actuales de migración a Azure AD. ¿Qué arquitectura recomienda?

Sugerencia: Este escenario presenta múltiples restricciones estrictas. Identifique cada una de ellas y determine si eliminan Cloud RADIUS por completo o solo parcialmente.

Ver respuesta modelo

Arquitectura recomendada: Híbrida: RADIUS on-premise para el personal clínico y la autenticación de dispositivos médicos; Cloud RADIUS (compatible con el NHS) u on-premise para el WiFi de invitados/pacientes.

Análisis de restricciones:

Soberanía de datos (centros de datos en Inglaterra aprobados por el NHS): Esto elimina a la mayoría de los proveedores comerciales de Cloud RADIUS, a menos que ofrezcan residencia de datos compatible con el NHS. Algunos proveedores ofrecen implementaciones específicas para el NHS; estas deben ser evaluadas. Si no existe una opción de nube compatible, se requiere una solución on-premise para toda la autenticación.
Active Directory on-premise sin sincronización en la nube: Esta es una restricción estricta para la integración con Cloud RADIUS. Sin Azure AD Connect o equivalente, Cloud RADIUS no puede consultar el directorio de personal del consorcio. Se requiere RADIUS on-premise para la autenticación del personal.
EAP-TLS para el personal clínico: Compatible tanto con FreeRADIUS on-premise como con NPS. Requiere una PKI interna (se recomienda Microsoft ADCS para un entorno integrado con AD).

Implementación recomendada: Implemente RADIUS on-premise (NPS o FreeRADIUS) en cada uno de los 12 centros hospitalarios en pares activo-pasivo, integrados con el Active Directory on-premise del consorcio. Utilice VLAN asignadas por RADIUS para segmentar el tráfico clínico, administrativo y de dispositivos médicos. Para el WiFi de invitados/pacientes, implemente el Captive Portal de Purple para la captura de datos y la gestión del consentimiento de conformidad con el GDPR; esto no requiere RADIUS para la autenticación de invitados y evita por completo la restricción de soberanía de datos para la red de invitados. Las políticas MAB de los dispositivos médicos se gestionan en el servidor RADIUS on-premise con listas de direcciones MAC mantenidas de forma centralizada mediante una herramienta de gestión de configuración.

Riesgo clave a mitigar: Gestión de certificados para EAP-TLS en 12 centros. Implemente Microsoft ADCS con inscripción automática de certificados a través de directivas de grupo (Group Policy) para garantizar que todos los dispositivos clínicos reciban y renueven los certificados automáticamente.

Continúe leyendo esta serie

PSK por dispositivo según el fabricante: comparación de iPSK, DPSK, MPSK y PPSK (y compatibilidad con WPA3)

Una comparación exhaustiva de las implementaciones de PSK por dispositivo en Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Extreme, Fortinet y Ubiquiti UniFi. Descubra cómo afecta WPA3-SAE a las estrategias de claves por dispositivo y cuándo implementar modos de transición en lugar de migrar a 802.1X.

Comparativa de métodos de autenticación de Captive Portal

Esta guía de referencia técnica autorizada evalúa las ventajas y desventajas arquitectónicas, operativas y de cumplimiento de cinco métodos principales de autenticación de Captive Portal. Proporciona a los arquitectos de red, directores de TI y directores de marketing los datos cuantitativos y los marcos de decisión necesarios para equilibrar la fricción en el registro de invitados con los requisitos de recopilación de datos en los recintos empresariales.

¿Qué es la autenticación por dirección MAC? Cuándo usarla y cuándo evitarla

Esta guía de referencia técnica autorizada aborda la autenticación por dirección MAC en entornos WiFi empresariales: cómo funciona la autenticación MAC basada en RADIUS en la Capa 2, sus vulnerabilidades de seguridad inherentes (incluido el spoofing de MAC y el impacto de la aleatorización de MAC a nivel de sistema operativo) y los contextos operativos precisos donde sigue siendo una herramienta válida para gestionar dispositivos IoT y headless. Proporciona orientación de despliegue práctica para responsables de TI y arquitectos de red en sectores como hostelería, retail, sanidad y espacios públicos, con ejemplos prácticos reales, marcos de decisión y contexto de integración para la plataforma de analítica y WiFi de invitados de Purple.