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 propiedad, una caja registradora ha terminado en la VLAN incorrecta y nadie puede confirmar si el dispositivo de un antiguo contratista todavía tiene acceso. El equipo de red puede solucionar cada problema localmente, pero el mismo trabajo sigue reapareciendo en todas las sedes, pisos 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. Eso puede simplificar la política en una propiedad distribuida, pero no hace que la red sea independiente de la WAN, del proveedor de identidad o de la infraestructura de certificados. Una evaluación sólida comienza con una pregunta más difícil que si el servicio tiene un SLA: ¿qué le sucede a cada clase de usuario y dispositivo cuando falla una dependencia?
Tabla de contenido
- Por qué centralizar las decisiones de red lo cambia todo
- Los orígenes y estándares detrás del RADIUS alojado moderno
- Cómo funciona realmente una arquitectura de RADIUS-as-a-Service
- Comparación entre RADIUS alojado y implementaciones locales
- SLA, conmutación por error multirregional y lo que realmente se rompe
- Seguridad, cumplimiento y migración desde RADIUS heredado
- Elección e implementación de un servicio RADIUS alojado
Por qué centralizar las decisiones de red lo cambia todo
Un patrón común en una cadena hotelera es un SSID de invitados que se ha multiplicado con el tiempo, credenciales de personal compartidas entre equipos y puertos de switch configurados según la última persona que trabajó en ese piso. El problema no es solo la dispersión de la configuración. Se trata de que los dispositivos locales conservan fragmentos de la política de acceso, por lo que un cambio en una propiedad podría no coincidir con el cambio en otra.
RADIUS proporciona una forma de centralizar la decisión. Un punto de acceso o servidor de acceso a la red envía una solicitud de autenticación a un servicio compartido, el cual verifica 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 política de forma centralizada en lugar de duplicar reglas en cada controlador o switch.
Esa división es la idea central detrás de RADIUS alojado. Un servicio central puede devolver atributos que mapean a un miembro del personal, invitado, contratista o dispositivo a una red o VLAN adecuada. Cuando alguien se va, se puede revocar una identidad gestionada centralmente en lugar de depender de que cada recinto actualice sus configuraciones locales. Los registros de contabilidad (accounting) también pueden ayudar a los operadores a investigar qué identidad usó una red y cuándo.
El localizador sigue importando
La centralización reduce algunos tipos de trabajo operativo, pero no elimina 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 alcanzar su punto de enlace configurado. Tampoco decide automáticamente qué dispositivos deben conservar el acceso cuando una sucursal pierde la conectividad.
Para la persona a cargo del soporte, el cambio consiste en pasar de mantener servidores y políticas de autenticación locales a gestionar las dependencias y el comportamiento ante fallos de un servicio compartido. Eso incluye probar la alcanzabilidad, validar los atributos devueltos, monitorear la contabilidad y acordar qué debería suceder durante una interrupción del servicio.
Regla operativa: Centralice las directivas de rutina, pero haga explícita la directiva de falla para cada grupo de usuarios y dispositivos.
La sesión de un invitado, la laptop de un empleado, una caja registradora, una cámara y un sensor de edificio no necesitan necesariamente la misma contingencia. Tratarlos como una población genérica de "WiFi" puede convertir una interrupción de 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 acceso por marcación telefónica 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 las implementaciones fue combinar la autenticación, autorización y contabilidad en un modelo cliente-servidor en lugar de sistemas propietarios independientes para cada función. Historia de RADIUS y antecedentes del protocolo
Esa división importa por algo más que la compatibilidad. Como la división NAS/autenticador es fija 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 contingencia, y no la elección del protocolo, decide lo que sucede en las instalaciones.
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 autenticación y RFC 2059 para contabilidad. RFC 2138 y RFC 2139 los reemplazaron 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 las primeras implementaciones expusieran problemas a mayor escala, un recordatorio útil de que esta especificación se fortaleció mediante fallas operativas en lugar de redactarse desde cero. Documentos del grupo de trabajo RADIUS del IETF
Por qué los antiguos estándares aún importan
Para un grupo hotelero u 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 switches de otro pueden enviar solicitudes a un servicio de políticas común, siempre que implementen un comportamiento RADIUS compatible. Las decisiones centralizadas de identidad y acceso se vuelven posibles sin tener que comprar el stack completo de control de acceso de un solo proveedor.
Las asignaciones de puertos muestran cómo el trabajo de estándares afecta 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 el RFC 2865. El equipo que aún utiliza 1645 por defecto fallará frente a un punto final alojado que espera el 1812, así que verifique lo que admite cada dispositivo antes de configurar firewalls, puntos finales regionales y planes de migración.
La seguridad del transporte es una preocupación actual. RFC 6614 define RADIUS sobre TLS, o RadSec, con el puerto TCP 2083 como el destino predeterminado y requisitos de protección de integridad. También advierte que el estado de la conexión TLS y el procesamiento 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 solo un puerto nuevo. Considere esa advertencia de carga como una pregunta de modo de falla: un punto de extremo que colapsa cuando cientos de puntos de acceso se reconectan al mismo tiempo tras una falla en la WAN es peor que uno que se degrada gradualmente. RFC 6614 sobre RADIUS sobre TLS
El RFC 9813 de 2025 del IETF documenta consideraciones operativas para claves precompartidas de TLS y la migración de RADIUS/UDP a RADIUS/TLS. Ese trabajo es relevante al evaluar cómo un proveedor maneja la gestión de certificados o claves, los límites de proxy y la migración gradual. Estándares RADIUS del IETF y trabajo relacionado
Cómo funciona realmente una arquitectura RADIUS-as-a-Service
Un diseño de 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 y reportes. La propuesta de un proveedor puede empaquetarlos juntos, pero los operadores aún necesitan saber qué componente valida la identidad, cuál lleva la solicitud y dónde terminan las evidencias de la sesión.
De la solicitud de conexión a la política de red
Cuando un usuario o dispositivo intenta conectarse, un punto de acceso o controlador actúa como el Network Access Server. Envía la solicitud a RADIUS. El servicio verifica la identidad presentada o las credenciales del dispositivo, a menudo utilizando un proveedor de identidad conectado o un acuerdo de confianza de certificados, y luego devuelve una decisión de aceptación o rechazo.
Una solicitud aceptada puede contener atributos de autorización, como la asignación de VLAN u otros parámetros de red. El punto de acceso o el controlador aplican esas instrucciones. En una analogía con un hotel, el punto de acceso es el recepcionista, el servicio RADIUS alojado es el directorio de identidades y los atributos devueltos son el brazalete que determina a qué áreas puede ingresar 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 (PMS). La integración exacta depende del servicio y del método de acceso. No asuma que un conector significa que cada política se puede evaluar de la manera que su sitio requiere. Pruebe los casos de identidad y dispositivos, incluidos los empleados salientes, dispositivos compartidos e inquilinos de terceros.
La contabilidad no es un extra opcional
La contabilidad (accounting) registra los eventos de sesión y la información de uso independientemente de la decisión de autenticación inicial. Esos registros pueden respaldar auditorías, planificación de capacidad, cobranzas e investigaciones, incluso cuando otro sistema realiza parte de la verificación de identidad. Para operaciones multisitio, se debe acordar cómo manejar las actualizaciones retrasadas, las retransmisiones, la falta de registros de detención y la conmutación por error (failover) de los puntos de enlace 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 únicamente a partir de los registros de asociación inalámbrica.
Al comparar servicios, mapee cada componente y flujo de datos antes de firmar. Un complemento útil es esta guía sobre soluciones de control de acceso a la red, particularmente si RADIUS forma parte de un diseño más amplio de políticas y aplicación.
Comparación de RADIUS alojado con implementaciones locales
El RADIUS alojado y el local (on-premises) utilizan el mismo protocolo. Los dispositivos de acceso siguen siendo Servidores de Acceso a la Red de cualquier manera; lo que cambia es quién ejecuta el servidor de autenticación compartido y qué hay entre él 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 como SaaS, el mismo problema se traslada a sus rutas WAN, cadena de identidad y confianza de certificados, nada de lo cual el proveedor administra en su nombre.
| Criterio | RADIUS alojado | RADIUS en las instalaciones |
|---|---|---|
| Trabajo de infraestructura | El proveedor opera la plataforma alojada; su equipo sigue gestionando la configuración del cliente, las directivas y la integración. | Su equipo opera el servidor, el software, el sistema operativo, el monitoreo y los acuerdos de recuperación. |
| Directiva multisitio | La directiva centralizada puede dar servicio a equipos en varias ubicaciones, sujeto a la conectividad y a implementaciones compatibles. | Un servidor central o una implementación sitio por sitio pueden funcionar, pero usted es responsable del modelo de replicación y consistencia. |
| Compatibilidad con dispositivos de red | Depende de los atributos RADIUS compatibles, las opciones de transporte y los dispositivos de acceso que implemente. | Usted controla la configuración del servidor, pero aún necesita 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 implementar localmente, pero su equipo gestiona los certificados, las conexiones y el escalado. |
| Responsabilidad ante fallos | El proveedor gestiona las operaciones de la plataforma; su equipo debe probar el comportamiento de la WAN, la identidad, el punto final y el respaldo local. | Su equipo controla la disponibilidad local, pero debe diseñar y mantener la redundancia y la recuperación. |
| Estructura de costos | A menudo se ofrece como una 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 el reemplazo siguen siendo su responsabilidad. |
Decida por el modo de falla, no por el eslogan
El RFC 2865 codifica la separación entre el dispositivo de acceso y el servidor de autenticación compartido (RFC 2865); la entrega alojada cambia la ubicación donde se ejecuta ese servidor, no el rol que desempeñan sus switches, controladores y puntos de acceso. Por lo tanto, la pregunta útil es idéntica para ambos modelos: cuando la autenticación no se encuentra disponible, ¿qué sigue funcionando en el establecimiento?
Utilice la opción alojada cuando pueda aceptar que la falla de una ruta WAN en un hotel o arena es su problema a resolver localmente, a través de SSID supervivientes, políticas almacenadas en caché o de respaldo, y un comportamiento de los AP que haya probado. Utilice la opción en las instalaciones cuando pueda contar con personal para operaciones de servidor las 24 horas del día y sea responsable de la rotación de certificados, parches y redundancia. Un servidor administrado localmente no es más resiliente de forma predeterminada. He auditado muchos equipos únicos en las instalaciones que ejecutan certificados vencidos sin conmutación por error, manteniendo una red unida por hábito y no por diseño.
El modelo de implementación determina menos que el diseño de respuesta ante fallas 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 el servicio realiza 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 una sola ruta de autenticación, por lo que un punto débil en cualquiera de los dos modelos tiende a aflorar en todas partes a la vez. Si está evaluando una plataforma alojada en comparación con una infraestructura operada por el cliente, una comparación de RADIUS autoalojado ayuda a estructurar qué responsabilidades operativas conservaría usted.
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 autenticación en un establecimiento particular están relacionados, pero no son intercambiables. Una plataforma alojada puede estar funcionando correctamente mientras que un hotel no puede comunicarse con ella debido a una falla de WAN o DNS. Un establecimiento también puede comunicarse con RADIUS mientras su proveedor de identidades o cadena de certificados impide una autenticación exitosa.
Califique la respuesta ante fallas por usuario y dispositivo
- Interrupción de la WAN: Las nuevas autenticaciones en la nube pueden fallar. Las sesiones existentes pueden continuar, dependiendo del comportamiento de la red local y la directiva de sesión. Pregunte si se han probado las capacidades de supervivencia local en su infraestructura de puntos de acceso.
- Fallo de DNS: Es posible que los dispositivos no resuelvan los puntos finales del servicio si su configuración depende de 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 identidad: El servicio RADIUS puede estar accesible pero ser incapaz de validar una nueva identidad. Las credenciales almacenadas en caché pueden ayudar, pero también podrían mantener el acceso después de que cambie el estado de un usuario.
- Vencimiento de certificado o interrupción de CA: La autenticación basada en certificados puede fallar cuando un certificado requerido es no válido, venció o no es de confianza. El monitoreo del ciclo de vida del certificado debe incluir los dispositivos y la cadena de confianza involucrados, no solo el servidor RADIUS.
- Interrupción del plano de gestión: Los operadores pueden perder la capacidad de cambiar directivas o revocar accesos, incluso si la autenticación continúa. 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 frente a la seguridad: las claves compartidas son difíciles de enfocar para su revocación, 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 falla usuario por usuario: ¿Deben los empleados, invitados, cajas registradoras, cámaras, residentes y dispositivos IoT bloquearse en caso de falla, usar una contingencia local limitada o continuar en una sesión previamente autorizada?
La multirregión es una entrada 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 forma viable de alcanzarlos y realizar la conmutación por error entre ellos. Verifique si los puntos de acceso y controladores implementados reintentan automáticamente, cómo eligen un punto de enlace alternativo y si la pérdida de una región requiere intervención manual. También pruebe cómo se ven los registros de contabilidad (accounting) durante la retransmisión y la recuperación.
Antes de la adquisición, pregunte cuánto tiempo sigue siendo válida la autenticación en caché, quién puede revocar el acceso de emergencia, con qué frecuencia se ejercita la conmutación por error (failover) y qué evidencia puede mostrar el proveedor a partir de las pruebas. Para hoteles y grandes recintos, ejecute la prueba con dispositivos y servicios representativos, no solo con la laptop del personal. Un resultado útil es una matriz de fallas por escrito que nombre a la población afectada, el comportamiento esperado, el responsable y la acción de recuperación.
Seguridad, cumplimiento y migración desde un RADIUS heredado
Trate la migración como un proyecto de seguridad, no como un cambio en la dirección del servidor. Una afirmación de "RADIUS seguro" puede referirse a varias cosas diferentes: proteger el transporte, autenticar dispositivos de red, validar la identidad del usuario o dispositivo, o devolver la autorización correcta. Esos controles resuelven problemas diferentes.
RadSec utiliza TLS para proteger el transporte de RADIUS, y la autenticación mutua de certificados puede ayudar a garantizar que el servidor y 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 causa baja se revoque de inmediato. Los operadores también deben confirmar cómo maneja el servicio el Message-Authenticator, las protecciones contra suplantación de identidad (spoofing) y ataques de repetición (replay), la inspección de proxy y la integridad de la contabilidad cuando los paquetes se reintentan o los puntos de acceso cambian.
Solicite evidencia, no solo garantías
Al evaluar a un proveedor, haga preguntas directas:
- Gestión de certificados: ¿Los certificados se gestionan por cliente, inquilino, sitio o dispositivo de red? ¿Cómo se monitorean 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?
- Evidencia de auditoría: ¿Puede revisar las decisiones de autenticación, los cambios de política, el acceso administrativo y los registros de contabilidad de red?
- Postura de seguridad: ¿Qué certificaciones posee el proveedor y qué alcance cubren? Si requiere ISO 27001 o Cyber Essentials Plus, verifique la evidencia actual y la aplicabilidad en lugar de confiar 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 política de destino y pruébela con identidades y dispositivos representativos. Realice una prueba piloto en un sitio, compare las decisiones devueltas con los resultados previstos y luego realice la transición servicio por servicio. Mantenga una ruta de reversión hasta que el comportamiento de acceso y contabilidad se comprendan completamente en producción.
El cumplimiento normativo debe seguir al tráfico y a los registros que maneja su entorno. Para una perspectiva práctica del control de red, consulte esta guía sobre cumplimiento PCI y WiFi. La pregunta útil no es si un producto afirma cumplir, sino si su implementación produce evidencias para los controles que su organización debe demostrar.
Un riesgo adicional se encuentra entre la especificación del protocolo y la red instalada. Las guías de seguridad pueden requerir verificaciones que algunos dispositivos de acceso o proxies no implementan de manera uniforme. Pregunte a los proveedores qué controles aplican, cuáles dependen del firmware del cliente y cómo validan el comportamiento en todo su equipamiento.
Elección e implementación de un servicio RADIUS alojado
Elija un proveedor por el comportamiento ante fallas y las pruebas operativas que pueda verificar, no solo por la etiqueta de la nube. Confirme la cobertura regional, el soporte del proveedor 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.
Realice la implementación en un orden controlado: inventaríe las dependencias actuales de AAA y de dispositivos; defina la política de red e identidad; realice pruebas piloto en sitios y tipos de dispositivos representativos; realice la transición por etapas; y luego valide las decisiones de acceso y la contabilidad frente a los registros de identidad o de gestión de la propiedad. Siga las autenticaciones fallidas, el manejo 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 impulsado por la identidad a través de los puntos de acceso existentes. Evalúelo con las mismas pruebas de falla, requisitos de directivas y evidencia que solicitaría a cualquier proveedor.
Si está planeando un despliegue de RADIUS en múltiples sitios, mapee sus dependencias de WAN, identidad, certificados y contingencia 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.
