Guía de RADIUS-as-a-Service para redes multisitio
Published
La red de invitados del hotel funciona, pero el SSID del personal tiene una contraseña compartida diferente en cada establecimiento, una caja registradora se ha ubicado en la VLAN incorrecta y nadie puede confirmar si el dispositivo de un antiguo contratista aún tiene acceso. El equipo de red puede solucionar cada problema a nivel local, pero el mismo trabajo vuelve a repetirse en diferentes ubicaciones, plantas y plataformas de puntos de acceso.
RADIUS-as-a-Service traslada las decisiones de autenticación a una plataforma alojada mientras deja que los puntos de acceso, switches y controladores las apliquen. Esto puede simplificar las políticas en un entorno distribuido, pero no hace que la red sea independiente de la WAN, del proveedor de identidades o de la infraestructura de certificados. Una evaluación sólida comienza con una pregunta más contundente que si el servicio tiene un SLA: ¿qué le ocurre a cada clase de usuario y dispositivo cuando falla una dependencia?
Índice de contenidos
- Por qué centralizar las decisiones de red lo cambia todo
- Los orígenes y los estándares detrás del RADIUS alojado moderno
- Cómo funciona realmente una arquitectura RADIUS-as-a-Service
- Comparación entre RADIUS alojado y despliegues locales
- SLA, conmutación por error multirregión y qué es lo que realmente falla
- Seguridad, cumplimiento y migración desde un RADIUS heredado
- Elección y despliegue de un servicio RADIUS alojado
Por qué centralizar las decisiones de red lo cambia todo
Un patrón habitual en una cadena hotelera es un SSID para invitados que se ha multiplicado con el tiempo, credenciales de personal compartidas entre equipos y puertos de switch configurados según el criterio de quien haya trabajado por última vez en esa planta. El problema no es solo la dispersión de la configuración. Es que los dispositivos locales guardan fragmentos de la directiva de acceso, por lo que un cambio en un establecimiento puede no coincidir con el de otro.
RADIUS ofrece una forma de centralizar las decisiones. Un punto de acceso o servidor de acceso a la red envía una solicitud de autenticación a un servicio compartido, el cual comprueba la identidad y devuelve una decisión de acceso. El dispositivo de red sigue aplicando esa decisión, pero el operador puede gestionar la identidad y la directiva de forma centralizada en lugar de duplicar reglas en cada controlador o switch.
Esa división es la idea central tras RADIUS alojado. Un servicio centralizado puede devolver atributos que asignan a un empleado, invitado, contratista o dispositivo a una red o VLAN adecuada. Cuando alguien se marcha, la identidad gestionada centralmente se puede revocar en lugar de depender de que cada centro actualice los ajustes locales. Los registros de contabilidad (accounting) también ayudan a los operadores a investigar qué identidad utilizó una red y cuándo.
Las alertas de guardia siguen siendo importantes
La centralización reduce ciertos tipos de trabajo operativo, pero no exime de la responsabilidad del diseño de la red. El servicio alojado no puede corregir un registro de identidad impreciso, una VLAN asignada de forma incorrecta o un punto de acceso que no puede comunicarse con su extremo configurado. Tampoco decide automáticamente qué dispositivos deben mantener el acceso cuando una sucursal pierde la conectividad.
Para el responsable de guardia, el cambio pasa de mantener servidores y directivas de autenticación locales a gestionar las dependencias y el comportamiento ante fallos de un servicio compartido. Esto incluye probar la accesibilidad, validar los atributos devueltos, supervisar la contabilidad y acordar qué debe suceder durante una interrupción del servicio.
Regla operativa: Centralice la directiva rutinaria, pero haga que la directiva de fallos sea explícita para cada grupo de usuarios y dispositivos.
La sesión de un invitado, el portátil de un empleado, una caja registradora, una cámara y un sensor de un edificio no necesitan necesariamente la misma alternativa en caso de fallo. Tratarlos como una única población genérica de "WiFi" puede convertir una interrupción de la autenticación en una interrupción del negocio o en una excepción de seguridad evitable.
Los orígenes y estándares detrás del RADIUS alojado moderno
RADIUS comenzó en 1991 después de que Merit Network solicitara un sistema de autenticación centralizado para el acceso telefónico a NSFNET. Livingston Enterprises construyó la primera implementación para sus servidores de acceso a la red PortMaster. La decisión de diseño que aún da forma a los despliegues fue combinar autenticación, autorización y contabilidad en un solo modelo cliente-servidor en lugar de sistemas propietarios independientes para cada función. Historia y antecedentes del protocolo RADIUS
Esa división importa por algo más que por la compatibilidad. Dado que la división NAS/autenticador está fijada en el protocolo, una interrupción de la WAN o del proveedor de identidad cambia quién puede llegar al servidor compartido, no los roles en sí, razón por la cual el diseño de reserva, y no la elección del protocolo, decide lo que sucede en la sede.
El registro de estándares muestra cómo el modelo se volvió interoperable. El IETF documentó RADIUS en enero de 1997 como RFC 2058 para la autenticación y RFC 2059 para la contabilidad (accounting). RFC 2138 y RFC 2139 los sustituyeron más tarde ese mismo año, seguidos por RFC 2865 y RFC 2866 en 2000. El RFC 2865 perfeccionó el protocolo después de que los primeros despliegues sacaran a la luz problemas a mayor escala, un recordatorio útil de que esta especificación se consolidó mediante fallos operativos en lugar de haberse diseñado perfectamente desde cero. Documentos del grupo de trabajo IETF RADIUS
Por qué los estándares antiguos siguen siendo importantes
Para un grupo hotelero o un operador de recintos, la separación entre el dispositivo de acceso y el servidor de autenticación sigue siendo muy útil. Un controlador inalámbrico de un fabricante y los conmutadores de otro pueden enviar solicitudes a un servicio de directivas común, siempre que implementen un comportamiento RADIUS compatible. La toma de decisiones centralizada sobre identidad y acceso pasa a ser posible sin necesidad de adquirir la solución completa de control de acceso de un solo proveedor.
Las asignaciones de puertos muestran el trabajo de estándares que afecta a las operaciones diarias. Las primeras implementaciones utilizaban comúnmente el puerto UDP 1645, mientras que el puerto UDP 1812 se convirtió en la asignación formal para la autenticación bajo la norma RFC 2865. Los equipos que aún utilicen el puerto 1645 de forma predeterminada fallarán al conectarse a un punto de enlace alojado que busque el puerto 1812, por lo que debe comprobar lo que admite cada dispositivo antes de configurar firewalls, puntos de enlace regionales y planes de migración.
La seguridad del transporte es una preocupación actual. La norma RFC 6614 define RADIUS sobre TLS, o RadSec, con el puerto TCP 2083 como destino predeterminado y requisitos de protección de la integridad. También advierte que el estado y el procesamiento de la conexión TLS pueden generar una carga mayor que el UDP tradicional, por lo que un diseño seguro requiere reutilización de conexiones, reintentos delimitados y planificación de capacidad, no simplemente un puerto nuevo. Considere esa advertencia de carga como una cuestión de modo de fallo: un punto de extremo que colapsa cuando cientos de puntos de acceso se reconectan a la vez tras un microcorte de WAN es peor que uno que se degrada gradualmente. RFC 6614 sobre RADIUS sobre TLS
El RFC 9813 de 2025 del IETF documenta las consideraciones operativas para claves precompartidas TLS y la migración de RADIUS/UDP a RADIUS/TLS. Este trabajo resulta relevante al evaluar cómo gestiona un proveedor los certificados o las claves, los límites del proxy y la migración gradual. Estándares RADIUS del IETF y documentación relacionada
Cómo funciona realmente una arquitectura de RADIUS-as-a-Service
Un diseño RADIUS alojado es más fácil de evaluar cuando se separan sus tres funciones de sus tres planos. Las funciones son autenticación, autorización y contabilidad (accounting). Los planos son identidad, transporte e informes. La propuesta de un proveedor puede empaquetarlos juntos, pero los operadores siguen necesitando saber qué componente valida la identidad, cuál transporta la solicitud y dónde terminan los registros de la sesión.
Desde la solicitud de conexión hasta la directiva de red
Cuando un usuario o dispositivo intenta conectarse, un punto de acceso o controlador actúa como Network Access Server. Envía la solicitud a RADIUS. El servicio comprueba la identidad o las credenciales del dispositivo presentadas, a menudo mediante un proveedor de identidades conectado o un acuerdo de confianza de certificados, y luego devuelve una decisión de aceptación o rechazo.
Una solicitud aceptada puede incluir atributos de autorización, como la asignación de VLAN u otros parámetros de red. El punto de acceso o controlador aplica dichas instrucciones. Siguiendo la analogía de un hotel, el punto de acceso es el recepcionista, el servicio RADIUS alojado es el directorio de identidades y los atributos devueltos son la pulsera que determina a qué áreas puede acceder la persona.
El servicio alojado conecta el plano de identidad con sistemas como Microsoft Entra ID, Okta, Google Workspace, una plataforma de gestión de dispositivos móviles o un sistema de gestión de propiedades. La integración exacta depende del servicio y del método de acceso. No asuma que la presencia de un conector significa que cada directiva se pueda evaluar de la forma en que requiere su centro. Pruebe los casos de identidad y dispositivos, incluyendo las bajas de empleados, los dispositivos compartidos y los arrendatarios de terceros.
La contabilidad (Accounting) no es un complemento opcional
El registro de contabilidad (accounting) guarda los eventos de sesión y la información de uso de forma independiente a la decisión de autenticación inicial. Estos registros permiten realizar auditorías, planificación de capacidad, imputación de costes e investigaciones, incluso cuando otro sistema realiza parte de la verificación de identidad. Para operaciones multisede, determine cómo gestionar las actualizaciones retrasadas, las retransmisiones, la ausencia de registros de parada (stop) y la conmutación por error en puntos de acceso regionales.
El plano de transporte lleva las solicitudes entre el dispositivo de red y RADIUS. El RADIUS tradicional suele utilizar UDP; RadSec utiliza TCP y TLS. El plano de informes recopila pruebas de autenticación y contabilidad para que los operadores puedan revisar las decisiones en lugar de inferir el acceso solo a partir de los registros de asociación inalámbrica.
Al comparar servicios, mapee cada componente y flujo de datos antes de firmar. Un recurso útil es esta guía sobre soluciones de control de acceso a la red, especialmente si RADIUS forma parte de un diseño de directivas y aplicación más amplio.
Comparativa entre RADIUS alojado y despliegues localmente alojados
El protocolo RADIUS alojado y el local utilizan el mismo protocolo. Los dispositivos de acceso siguen siendo servidores de acceso a la red (Network Access Servers) en ambos casos; lo que cambia es quién ejecuta el servidor de autenticación compartido y qué hay entre este y sus instalaciones. Si lo opera usted mismo, la disponibilidad es un problema de ingeniería en su sala de servidores. Si lo adquiere alojado (SaaS), el mismo problema se traslada a sus rutas WAN, cadena de identidad y confianza de certificados, nada de lo cual gestiona el proveedor en su nombre.
| Criterio | RADIUS alojado | RADIUS local |
|---|---|---|
| Trabajo de infraestructura | El proveedor opera la plataforma alojada; su equipo se encarga de la configuración de clientes, las políticas y la integración. | Su equipo opera el servidor, el software, el sistema operativo, la supervisión y los planes de recuperación. |
| Política multisitio | La política centralizada puede dar servicio a equipos en distintas ubicaciones, según la conectividad y las implementaciones compatibles. | Un servidor central o un despliegue sitio por sitio pueden funcionar, pero usted es responsable del modelo de replicación y coherencia. |
| Compatibilidad con dispositivos de red | Depende de los atributos RADIUS admitidos, las opciones de transporte y los dispositivos de acceso que despliegue. | Usted controla la configuración del servidor, pero sigue necesitando validar el comportamiento en switches, controladores y puntos de acceso. |
| Seguridad de transporte | El soporte de RadSec puede proteger el transporte, con gestión de certificados y capacidad TLS por diseñar. | RadSec también se puede desplegar localmente, pero su equipo gestiona los certificados, las conexiones y el escalado. |
| Responsabilidad de fallos | El proveedor gestiona las operaciones de la plataforma; su equipo debe probar el comportamiento de la WAN, la identidad, los puntos finales y la alternativa local. | Su equipo controla la disponibilidad local, pero debe diseñar y mantener la redundancia y la recuperación. |
| Estructura de costes | A menudo se ofrece como suscripción al servicio; evalúe el contrato y el alcance operativo incluido. | Puede utilizar la infraestructura existente, pero el tiempo del personal, el mantenimiento y la sustitución siguen siendo su responsabilidad. |
Decida según los modos de fallo, no por eslóganes
El RFC 2865 codifica la separación entre el dispositivo de acceso y el servidor de autenticación compartido (RFC 2865); la prestación en la nube modifica dónde se ejecuta dicho servidor, no la función que desempeñan sus switches, controladores y puntos de acceso. Por tanto, la pregunta relevante es idéntica para ambos modelos: cuando la autenticación no está disponible, ¿qué sigue funcionando en las instalaciones?
Utilice la opción alojada cuando pueda aceptar que un fallo en la ruta WAN de un hotel o estadio es un problema que debe resolver localmente, a través de SSID supervivientes, políticas en caché o de respaldo y un comportamiento de los AP que haya probado previamente. Utilice la opción en las instalaciones (on-premises) cuando pueda contar con personal para operaciones de servidores las 24 horas del día y sea responsable de la rotación de certificados, los parches y la redundancia. Un servidor gestionado localmente no es más resiliente por defecto. He auditado bastantes equipos únicos en las instalaciones que ejecutaban certificados caducados y sin conmutación por error, manteniendo una red unida más por costumbre que por diseño.
El modelo de despliegue determina menos que el diseño ante fallos que lo rodea.
La postura de seguridad depende de la implementación y no de la ubicación. Pregunte dónde se almacenan los secretos compartidos y los certificados, quién puede leer los datos de contabilidad, cómo se protegen las solicitudes en tránsito y cómo realiza el servicio el proxy de las solicitudes que no puede responder por sí mismo. Las cajas registradoras, el WiFi para invitados, las cámaras y los dispositivos IoT suelen compartir la misma ruta de autenticación, por lo que un punto débil en cualquiera de los modelos tiende a aflorar en todas partes al mismo tiempo. Si está sopesando una plataforma alojada frente a una infraestructura gestionada por el cliente, una comparación de RADIUS alojado localmente le ayudará a estructurar qué responsabilidades operativas conservaría.
SLA, conmutación por error multirregión y qué es lo que realmente falla
El tiempo de actividad de la plataforma de un proveedor, su compromiso de servicio RADIUS y la disponibilidad de la autenticación en un establecimiento específico están relacionados, pero no son intercambiables. Una plataforma alojada puede funcionar correctamente mientras un hotel no puede acceder a ella debido a un fallo de DNS o de la red WAN. Del mismo modo, un establecimiento puede comunicarse con RADIUS mientras su proveedor de identidad o su cadena de certificados impiden una autenticación con éxito.
Evalúe la respuesta ante fallos por usuario y dispositivo
- Interrupción de la WAN: Las nuevas autenticaciones en la nube pueden fallar. Las sesiones existentes pueden continuar, según el comportamiento de la red local y la política de sesión. Pregunte si se ha probado la supervivencia local en sus puntos de acceso.
- Fallo del DNS: Es posible que los dispositivos no resuelvan los puntos finales del servicio si su configuración depende del DNS. Confirme cómo se aprovisionan los puntos finales y qué hace el equipo de acceso cuando falla la resolución.
- Interrupción del proveedor de identidades: Es posible que se pueda acceder al servicio RADIUS pero que no se pueda validar una nueva identidad. Las credenciales en caché pueden ayudar, pero también podrían mantener el acceso después de que cambie el estado de un usuario.
- Caducidad del certificado o interrupción de la CA: La autenticación basada en certificados puede fallar cuando un certificado requerido es no válido, ha caducado o no es de confianza. La supervisión del ciclo de vida de los certificados debe incluir los dispositivos y la cadena de confianza implicados, no solo el servidor RADIUS.
- Interrupción del plano de gestión: Es posible que los operadores pierdan la capacidad de cambiar las políticas o revocar el acceso aunque la autenticación continúe. Establezca cómo se realizan y registran los cambios de emergencia.
Un SSID de emergencia con contraseña compartida, el acceso basado en MAC y las credenciales en caché no son formas equivalentes de resiliencia. Cada una compensa la disponibilidad inmediata a costa de la seguridad: las claves compartidas son difíciles de revocar de forma específica, los identificadores MAC se pueden suplantar y las decisiones en caché pueden durar más que el estado de identidad que debían reflejar.
Solicite una directiva de fallos usuario por usuario: ¿Deben los empleados, invitados, cajas registradoras, cámaras, residentes y dispositivos IoT bloquearse en caso de fallo, utilizar una alternativa local limitada o continuar en una sesión autorizada previamente?
El soporte multirregión es un requisito de diseño, no una prueba
Los puntos de enlace RADIUS multirregión pueden reducir la dependencia de una sola región de servicio, pero los dispositivos de acceso necesitan una vía viable para alcanzarlos y conmutar por error entre ellos. Verifique si los puntos de acceso y controladores desplegados reintentan la conexión automáticamente, cómo eligen un punto de enlace alternativo y si la pérdida de una región requiere intervención manual. Compruebe también cómo se comportan los registros de contabilidad (accounting) durante la retransmisión y la recuperación.
Antes de la adquisición, pregunte cuánto tiempo se mantiene válida la autenticación almacenada en caché, quién puede revocar el acceso de emergencia, con qué frecuencia se ejercita la conmutación por error y qué pruebas puede mostrar el proveedor a partir de los ensayos. Para hoteles y grandes recintos, realice la prueba con dispositivos y servicios representativos, no solo con el portátil del personal. Un resultado útil es una matriz de fallos por escrito que identifique la población afectada, el comportamiento esperado, el responsable y la acción de recuperación.
Seguridad, cumplimiento normativo y migración desde un RADIUS heredado
Trate la migración como un proyecto de seguridad, no como un simple cambio de dirección de servidor. La afirmación de un "RADIUS seguro" puede referirse a varios aspectos diferentes: proteger el transporte, autenticar dispositivos de red, validar la identidad del usuario o dispositivo, o devolver la autorización correcta. Estos controles resuelven problemas distintos.
RadSec utiliza TLS para proteger el transporte de RADIUS, y la autenticación mutua mediante certificados puede ayudar a garantizar que tanto el servidor como el dispositivo cliente sean de confianza. Pero el cifrado por sí solo no garantiza que el usuario correcto reciba la VLAN correcta, o que el acceso de un empleado que abandona la empresa se revoque de inmediato. Los operadores también deben confirmar cómo maneja el servicio Message-Authenticator, las protecciones contra suplantación de identidad y ataques de réplica, la inspección de proxy y la integridad de la contabilidad cuando se reintentan paquetes o cambian los puntos de acceso.
Solicite pruebas, no solo garantías
Al evaluar a un proveedor, haga preguntas directas:
- Gestión de certificados: ¿Se gestionan los certificados por cliente, inquilino, sitio o dispositivo de red? ¿Cómo se supervisan el vencimiento y la rotación?
- Límites de transporte: ¿Dónde finaliza TLS? ¿Pueden los proxies intermedios inspeccionar o reenviar solicitudes, y qué protección se mantiene de extremo a extremo?
- Pruebas de auditoría: ¿Puede revisar las decisiones de autenticación, los cambios de directivas, el acceso administrativo y los registros de contabilidad?
- Postura de seguridad: ¿Qué certificaciones posee el proveedor y qué alcance cubren? Si requiere ISO 27001 o Cyber Essentials, verifique la evidencia actual y su aplicabilidad en lugar de confiar únicamente en un logotipo.
- Migración y reversión: ¿Puede el proveedor admitir una transición escalonada de UDP a TLS y cuál es la ruta de reversión probada si un modelo de dispositivo de acceso se comporta de manera diferente?
Una secuencia de migración debe comenzar con un inventario de clientes RADIUS, fuentes de identidad, métodos de autenticación, reglas de VLAN, secretos compartidos, certificados y consumidores de contabilidad. A continuación, documente la directiva de destino y pruébela con identidades y dispositivos representativos. Realice una prueba piloto en una ubicación, compare las decisiones devueltas con los resultados previstos y, a continuación, realice la transición servicio por servicio. Mantenga una ruta de reversión hasta que se comprenda el comportamiento del acceso y la contabilidad en producción.
El cumplimiento normativo debe seguir al tráfico y los registros que gestiona su entorno. Para una perspectiva práctica del control de red, consulte esta guía sobre PCI-DSS cumplimiento y WiFi. La pregunta útil no es si un producto afirma cumplir la norma, sino si su despliegue genera pruebas para los controles que su organización debe demostrar.
Existe un riesgo adicional entre la especificación del protocolo y la red instalada. Las guías de seguridad pueden requerir comprobaciones que algunos dispositivos de acceso o proxies no implementan de manera consistente. Pregunte a los proveedores qué controles aplican, cuáles dependen del firmware del cliente y cómo validan el comportamiento en sus equipos.
Elección e implantación de un servicio RADIUS alojado
Elija un proveedor por el comportamiento ante fallos y las pruebas operativas que pueda verificar, no solo por la etiqueta de la nube. Confirme la cobertura regional, el soporte de proveedores de identidad, la gestión de claves por cliente donde sea necesario, el acceso a auditorías, los procesos de certificados y RadSec, y qué sucede cuando finaliza el contrato.
Despliegue en un orden controlado: inventaríe las dependencias actuales de AAA y de los dispositivos; defina la directiva de identidad a red; realice pruebas piloto en ubicaciones y tipos de dispositivos representativos; realice la transición por fases; y, a continuación, valide las decisiones de acceso y la contabilidad con los registros de identidad o de gestión de la propiedad. Supervise las autenticaciones fallidas, la gestión de revocaciones, la conciliación contable y el rendimiento de la red de invitados como señales operativas, no como prueba de resiliencia por sí solas.
Purple Access ofrece Cloud RADIUS alojado junto con opciones de red abiertas, seguras y xPSK, con acceso basado en la identidad a través de los puntos de acceso existentes. Evalúelo con las mismas pruebas de fallos, requisitos de directivas y pruebas que solicitaría a cualquier proveedor.
Si está planificando el despliegue de RADIUS en múltiples instalaciones, mapee sus dependencias de WAN, identidad, certificados y redundancia local antes de cambiar la ruta de autenticación. Visite Purple Access para revisar sus opciones de Cloud RADIUS y acceso a la red para redes de invitados, personal y dispositivos.
