Mover su servidor RADIUS a la nube no es, por sí solo, una estrategia de seguridad WiFi. El consejo habitual de reemplazar FreeRADIUS o Windows NPS por un extremo alojado pasa por alto las preguntas más difíciles: qué identidad controla el acceso, cómo lo pierde un empleado que deja la empresa y qué ocurre cuando la ubicación no puede conectarse al servicio.
RADIUS as a Service es muy útil como control de gobernanza de identidades, no solo como un mero reemplazo de servidor. Para empresas y ubicaciones del Reino Unido, el diseño adecuado suele combinar la autenticación del personal vinculada al directorio con claves únicas para los dispositivos que no pueden utilizar una autenticación empresarial moderna. Una transición basada únicamente en certificados no es automáticamente la opción más sólida.
Qué cambia RADIUS as a Service para el WiFi
RADIUS as a Service es un plano de control alojado para autenticación, autorización y contabilidad (AAA). Su punto de acceso o controlador WLAN sigue siendo el punto de aplicación. El servicio alojado decide si admite a un usuario o dispositivo y devuelve la directiva de red que se debe aplicar.
Comparativa entre RADIUS local, en la nube y federado
| Modelo | Quién opera AAA | Fuente de identidad | Conmutación por error y crecimiento | Caso de uso ideal |
|---|---|---|---|---|
| FreeRADIUS o Windows NPS local | Su equipo aplica parches y supervisa el servicio | Directorio local o un proveedor de identidades accesible a través de su servidor | Aplica parches, crea clústeres y supervisa cada instancia, y luego configura sitios adicionales | Una única ubicación con competencias internas en RADIUS |
| Cloud RADIUS as a Service | El proveedor aplica parches y supervisa el servicio alojado | Entra ID, Okta, Google Workspace u otro proveedor de identidades compatible | Extremos y SLA del proveedor, añadiendo nuevos sitios sin necesidad de nuevos servidores de autenticación | Ubicaciones multisitio sin un equipo dedicado a RADIUS |
| Proxy RADIUS federado | Operadores de proxy compartidos más el proveedor de identidades de origen | Credenciales de la organización de origen | La infraestructura de proxy nacional o compartida conecta los sitios participantes | Usuarios en itinerancia entre sitios gestionados de forma independiente |
Mover el servidor no crea un modelo de confianza cero (zero trust). La seguridad sigue basándose en identidades únicas, una revocación inmediata y una regla por escrito que determine si el acceso falla abierto o cerrado cuando la autenticación no está disponible.
Una contraseña compartida de WiFi no puede identificar de forma fiable a una persona. Tampoco se puede revocar el acceso a un empleado que deja la empresa sin cambiar esa contraseña para todos los demás. Además, mantener a los invitados alejados de los sistemas de los empleados requiere una directiva de red, no solo una contraseña diferente.
Separe el modelo operativo de la directiva de acceso
El alojamiento en la nube cambia quién mantiene la infraestructura de autenticación. En Purple, operamos el RADIUS en la nube que reemplaza a FreeRADIUS o Windows NPS, de modo que su equipo no tiene que aplicar parches ni gestionar la conmutación por error de servidores de autenticación locales. Su equipo sigue siendo el propietario de las reglas de acceso, los grupos de directorio y el diseño de la red local.
La federación resuelve un problema distinto: permitir que las personas se autentiquen en ubicaciones gestionadas de forma independiente. Según el informe de gestión de eduroam de Jisc, el servicio del Reino Unido se lanzó el 2 de mayo de 2006, redirigiendo la autenticación de los visitantes a su institución de origen en lugar de requerir que las ubicaciones visitadas administren cuentas locales de invitados. Eso es gestión delegada de identidades, no un mero alojamiento remoto de servidores.
Regla práctica: Marque el modelo que coincida con el propietario actual de la identidad y, a continuación, decida si esa titularidad debe cambiar.
La autenticación tampoco es una solución para una mala cobertura de radio, la congestión o una conexión a Internet débil. La guía de Madeira Remote para mejorar el WiFi para realizar videollamadas más fluidas ofrece un contexto útil para separar el trabajo de calidad de conexión del trabajo de control de acceso. Solucionar la admisión a la red no reparará un canal inalámbrico sobrecargado.
Por lo tanto, la decisión es tanto operativa como técnica. Puede externalizar el mantenimiento del servidor al tiempo que conserva la responsabilidad exacta sobre quién accede a qué red.
Cómo decide el acceso Cloud RADIUS
Un portátil gestionado se conecta a un SSID configurado para WPA2-Enterprise o WPA3-Enterprise. En lugar de demostrar que conoce una contraseña común a todo el edificio, inicia un intercambio con el Protocolo de Autenticación Extensible (EAP) a través del punto de acceso.
El punto de acceso o el controlador empaqueta ese intercambio en un paquete RADIUS Access-Request y lo envía al servicio alojado. EAP puede requerir varios intercambios antes de que el servicio disponga de información suficiente para tomar una decisión.
Pruebe las funciones AAA por separado
La documentación sobre la arquitectura FreeRADIUS del Gobierno del Reino Unido describe el servicio a través de la autenticación, autorización y contabilidad. Trate estas funciones como pruebas de aceptación independientes y no como nombres intercambiables para un inicio de sesión correcto.
- La autenticación establece la identidad. El servicio evalúa la credencial o el certificado mediante el método configurado. Un Access-Challenge continúa el intercambio, un Access-Reject deniega la admisión y un Access-Accept la permite.
- La autorización asigna permisos. La respuesta puede incluir una VLAN, un rol, una lista de control de acceso (ACL) o un límite de sesión. El controlador debe entender y aplicar dichos atributos.
- La contabilidad registra la sesión. Recopile el inicio, las actualizaciones intermedias y el final de la sesión con identificadores estables de identidad y dispositivo, marcas de tiempo e identificadores de sesión.
Un Access-Accept no demuestra que la segmentación haya funcionado. Supongamos que un contratista se autentica correctamente pero termina en la VLAN de empleados porque el controlador ignora un atributo de rol. La autenticación tuvo éxito, pero el diseño de acceso falló.
Del mismo modo, el resultado de una autenticación en el panel de control de un proveedor no sustituye la contabilidad de la sesión. Los investigadores necesitan vincular una identidad a un dispositivo, una ubicación y una sesión, incluyendo el momento exacto en que comenzó y finalizó el acceso.
Diseñe pensando en extremos inalcanzables
Configure extremos de servicio redundantes, supervisión del estado y temporizadores de reintento delimitados. Los reintentos infinitos pueden dejar a los clientes colgados y dificultar el diagnóstico. Nuestro RADIUS en la nube opera con conmutación por error multirregional respaldado por un SLA de disponibilidad del 99,9 %, pero la conectividad de la ubicación y el comportamiento del controlador siguen necesitando sus propias pruebas.
Defina la regla para interrupciones antes del paso a producción. El comportamiento fallo abierto (fail-open) puede admitir dispositivos sin las comprobaciones previstas, lo que podría crear un acceso sin restricciones. El comportamiento fallo cerrado (fail-closed) deniega las nuevas admisiones, lo que protege el perímetro pero puede interrumpir los terminales de pago u otros equipos operativos.
No asuma que las sesiones existentes y las nuevas conexiones se comportan de forma idéntica durante una interrupción. Pruebe la autenticación inicial, la reautenticación y la recuperación del extremo por separado, y obtenga por escrito el compromiso de disponibilidad y el diseño de la conmutación por error.
Finalice la prueba piloto con pruebas observables:
- Sesión aceptada: El cliente accede a la VLAN prevista y únicamente a los servicios permitidos.
- Identidad deshabilitada: Un nuevo intento de autenticación recibe un rechazo (reject).
- Contabilidad con capacidad de búsqueda: Un administrador puede buscar posteriormente el registro de sesión resultante.
Controles de seguridad que debe demostrar un servicio alojado
En 2024, el 50 % de las empresas del Reino Unido sufrió una brecha de seguridad o un ciberataque en los 12 meses anteriores, con una tasa que superó el 70 % entre las medianas y grandes empresas, según el análisis sobre confianza cero de Consultancy.uk. Un servicio de inicio de sesión alojado no resuelve por sí solo dicha exposición.
El modelo de confianza cero implica autenticar y autorizar el acceso en lugar de confiar en un dispositivo solo por haberse conectado al SSID corporativo. Un servicio en la nube aún puede aplicar directivas débiles mediante credenciales compartidas, falta de comprobación de dispositivos o permisos demasiado amplios.
Exija pruebas en cada perímetro
Comience con la credencial y, a continuación, examine el transporte, la administración y la aplicación de políticas. Cada uno tiene un modo de fallo diferente.
- Identidades nominativas: Utilice cuentas individuales o identidades de dispositivo, con la eliminación gestionada desde el directorio en lugar de mantener manualmente una lista de acceso.
- Autenticación sólida del cliente: Opte por la autenticación de dispositivos basada en certificados para los extremos gestionados. Utilice métodos resistentes al phishing cuando sea posible y exija autenticación de múltiples factores (MFA) para la administración y los flujos de trabajo de incorporación adecuados.
- Transporte protegido: Proteja la ruta del controlador al servicio con un transporte cifrado adecuado, como RadSec o un túnel seguro. El secreto compartido de RADIUS por sí solo no cifra todo el intercambio.
- Administración separada: Mantenga las identidades de administrador con privilegios separadas de las cuentas cotidianas y conserve un registro de auditoría de los cambios en las directivas.
- Roles de mínimo privilegio: Conceda al personal, contratistas, equipos clínicos y sistemas de gestión de edificios únicamente el acceso que necesiten.
No asuma que la solicitud de MFA basada en navegador de un directorio en la nube pueda aparecer dentro de cada intercambio EAP. El método EAP elegido, el software cliente y la integración de identidades deben ser compatibles con el flujo de autenticación previsto.
Compruebe también los controles inalámbricos y operativos
Configure la seguridad inalámbrica empresarial con validación de certificados de servidor, autenticación mutua y tramas de datos cifradas. Exija Tramas de Gestión Protegidas (PMF) donde sean compatibles y adecuadas para el modo WPA elegido, en lugar de considerar la etiqueta empresarial como prueba de que todas las protecciones están activadas.
Para el diseño general de las directivas, nuestra guía de seguridad WiFi para empresas resulta un complemento muy útil. Nuestro WiFi para empleados ofrece seguridad de nivel empresarial sin la complejidad de un NAC, pero los administradores deben seguir definiendo los límites de acceso y supervisar su funcionamiento.
La infraestructura física sigue siendo relevante incluso cuando la autenticación está alojada en la nube. La guía de ABCO Security Services Australia sobre el refuerzo de la seguridad en centros de datos ofrece un contexto complementario para proteger las instalaciones que respaldan los servicios de red.
Una credencial válida no debería conceder a un dispositivo permiso para acceder a absolutamente todo en el edificio.
Asigne un responsable a las alertas de rechazos repetidos, los cambios inesperados de privilegios y las actividades administrativas sospechosas. Los registros solo son de utilidad cuando alguien puede interpretarlos y actuar en consecuencia.
Conexión de directorios sin un segundo almacén de usuarios
El directorio principal debe seguir siendo el lugar donde se gestionen el estado laboral y la pertenencia a grupos. Ya se trate de Entra ID, Okta o Google Workspace, la integración alojada de RADIUS debe traducir la identidad en permisos de red, en lugar de crear una base de datos de contraseñas desconectada.
El método de integración es importante. Un conector puede sincronizar grupos, validar credenciales a través de un mecanismo compatible o asociar certificados con identidades de directorio. No asuma que todos los directorios en la nube ofrecen la misma interfaz de validación de contraseñas.
Siga el flujo de altas, cambios de puesto y bajas
Considere el caso de un nuevo empleado que se incorpora al equipo de instalaciones. Una vez que su pertenencia al directorio es correcta y su dispositivo está registrado, el servicio debe asignarle el rol de red de instalaciones sin que un administrador tenga que crear una cuenta de WiFi independiente.
Cuando ese empleado pasa al departamento de finanzas, el cambio en el directorio debe traducirse en la VLAN o ACL correspondiente en la siguiente evaluación de directivas. Un diseño acertado elimina la necesidad de editar los controladores individualmente, pero debe especificar cuándo se actualizan las pertenencias almacenadas en caché y las sesiones existentes.
En el caso de una baja, deshabilitar la cuenta del directorio debería impedir autenticaciones posteriores dentro de un plazo acordado. El cambio de autorización (Change of Authorisation o CoA) puede desconectar o modificar una sesión activa cuando el controlador lo admite y la integración lo activa. Los despliegues basados en certificados también necesitan un proceso explícito de revocación de certificados o de comprobación del estado de la identidad.
Condición de aceptación: Acuerde la rapidez con la que un cambio en el directorio se refleja en las nuevas autenticaciones y en las sesiones activas. Pruebe ambas situaciones en lugar de aceptar «automático» como compromiso de tiempo.
El principio de identidad y control de acceso del NCSC respalda la verificación y autorización de usuarios, dispositivos y sistemas antes de concederles acceso. Aplicado al WiFi, esto convierte la gestión del ciclo de vida en un requisito de seguridad y no en una mera comodidad de incorporación.
Confirme los límites de la integración
CoA, los roles dinámicos y el comportamiento de jardín vallado (walled garden) dependen del controlador de la ubicación. En entornos con Meraki, Aruba, Ruckus, Mist y UniFi, confirme el modelo exacto, el firmware y la compatibilidad de funciones en lugar de confiar solo en la marca del fabricante.
Los portátiles gestionados pueden utilizar EAP-TLS u otro método empresarial sin contraseña compatible. Los invitados no deberían tener que realizar el mismo proceso de certificado para dispositivos gestionados. El SSO corresponde a la consola de administración y a los flujos de incorporación del personal adecuados, pero no reemplaza al 802.1X en el enlace inalámbrico.
Para un despliegue basado en Entra, utilice nuestra visión general sobre la integración con Entra ID para estructurar los requisitos de identidad. A continuación, realice una pequeña prueba del ciclo de vida:
- Alta: Un nuevo empleado aprovisionado correctamente debe poder conectarse.
- Cambio de puesto: Un cambio de grupo debe generar el rol de red previsto.
- Baja: Una cuenta deshabilitada en un momento de prueba registrado debe fallar dentro de la ventana de revocación acordada.
Patrones de acceso para invitados, personal y entornos multiinquilino
Un edificio alberga diferentes tipos de usuarios con distintos límites de confianza. El huésped de un hotel, el portátil de un empleado y el televisor de un inquilino no deberían heredar la misma directiva de acceso solo por utilizar los mismos puntos de acceso.
Elija la fila correspondiente al tipo de usuario antes de seleccionar su pantalla de incorporación. El método debe funcionar en el dispositivo, mientras que la red debe impedir el acceso a usuarios y sistemas ajenos.
Patrones de acceso por tipo de usuario
| Tipo de usuario | Método de autenticación | Aislamiento | Cómo finaliza el acceso |
|---|---|---|---|
| Visitante invitado | Correo electrónico o identidad de un solo uso, con cifrado cuando se utilice enterprise o Passpoint | Rol o VLAN para invitados sin ruta hacia el personal | Caducidad de la sesión o directiva del portal |
| Personal y dispositivos gestionados | Identidad de directorio mediante EAP, a menudo certificados o autenticación empresarial sin contraseña | Rol, VLAN o ACL a partir del grupo de directorio | Deshabilitación en el directorio, más CoA si el controlador lo admite |
| Contratista | Grupo de directorio limitado en el tiempo | Rol restringido, no la VLAN completa del personal | Caducidad del grupo o fin de la solicitud/ticket |
| Dispositivos heredados e IoT | PSK única u otra credencial de alcance muy limitado | Segmento propio sin ruta lateral más allá de los servicios expresamente permitidos | Rotación de claves o desvinculación del propietario |
| Residente multiinquilino | PSK única por persona o vivienda | Red privada aislada de otros inquilinos | Revocación de clave al mudarse/dejar la vivienda |
Separe la incorporación sencilla del acceso amplio
Los invitados necesitan una incorporación con pocas complicaciones, a menudo mediante la verificación del correo electrónico. Sin embargo, una página de bienvenida (splash page) no cifra por sí sola la conexión inalámbrica. Seleccione un método de acceso cifrado siempre que sea posible y no utilice la finalización con éxito del portal como permiso para acceder a los sistemas internos.
El personal necesita una autenticación empresarial vinculada al directorio. Los contratistas necesitan una fecha de caducidad y un rol más restringido, incluso cuando trabajan junto a los empleados. Asigne a los responsables operativos la función de prorrogar el acceso de los contratistas en lugar de dejar las cuentas activas indefinidamente.
Los residentes e inquilinos comerciales tienen otro requisito: sus propios dispositivos deben funcionar juntos sin quedar expuestos a sus vecinos. Nuestra guía de WiFi multiinquilino analiza ese modelo de red privada.
Utilice claves únicas para dispositivos con limitaciones
Es posible que las impresoras, los televisores, las consolas y los escáneres no admitan el método EAP requerido. Una clave precompartida única, a menudo denominada iPSK o xPSK, le permite asociar su acceso a una persona, vivienda o dispositivo sin restablecer una contraseña común para todo el edificio.
La clave por sí sola no crea el aislamiento. El controlador y la red deben asignarla al segmento privado previsto y hacer cumplir las rutas permitidas. Trate la credencial como transferible, registre a su propietario y revóquela cuando finalice dicha titularidad.
Ofrecemos WiFi para invitados, seguridad 802.1X para personal y redes de área privada xPSK en una única plataforma en la nube. Nuestro xPSK y WiFi multiinquilino ofrece a cada residente, inquilino o dispositivo una clave única con aislamiento entre inquilinos, incluida conectividad privada para consolas y televisores sin navegador.
En el caso de los operadores residenciales, coordine la salida digital con la retirada del acceso físico. El control de acceso a cancelas para comunidades multifamiliares de Nimbio es un paralelismo útil para reflexionar sobre la propiedad de las credenciales de los residentes. Ni el acceso a la puerta ni la clave de red de un antiguo residente deben permanecer activos tras su marcha.
Cómo realizar la migración sin recurrir a una contraseña compartida de respaldo
Una migración debe demostrar que cada tipo de dispositivo puede conectarse de forma segura antes de desmantelar la configuración anterior. El error operativo consiste en tratar cada excepción como un motivo para conservar una contraseña de emergencia para todo el edificio.
La necesidad de una planificación deliberada va más allá del WiFi: el informe de Cyber Magazine sobre un estudio de Hiscox señala que dos tercios de las empresas encuestadas tienen previsto implementar una arquitectura de confianza cero antes de 2030. Se trata de una intención de futuro declarada, no de una prueba de que sus redes actuales cumplan con dicho modelo.
Ejecute la transición de forma secuencial y controlada
- Clasifique los clientes. Separe los extremos del personal compatibles con 802.1X, los equipos heredados o sin navegador, y los invitados. Registre la propiedad del dispositivo y su criticidad operativa.
- Valide las funciones del controlador. Confirme la autenticación empresarial, las VLAN o roles dinámicos, CoA y cualquier jardín vallado (walled garden) necesario. Compruebe el firmware instalado, no solo la familia de productos.
- Realice una prueba piloto con un SSID limitado en un sitio seleccionado. Conéctelo al directorio y documente el comportamiento de fallo cerrado (fail-closed). Incluya un dispositivo operativo representativo, no solo un portátil de TI.
- Aprovisione los dispositivos gestionados del personal. Utilice certificados o un método empresarial sin contraseña compatible. Nuestro WiFi para empleados funciona en los puntos de acceso existentes sin necesidad de crear una PKI propia.
- Asigne credenciales de alcance limitado a los dispositivos con restricciones. Emita claves PSK únicas para impresoras, equipos médicos e IoT según corresponda. Permita únicamente sus destinos requeridos.
- Mantenga a los invitados en una directiva independiente. Pruebe que los dispositivos de invitados no puedan acceder a los recursos del personal, incluso si la incorporación y la autenticación comparten plataforma de gestión.
- Ponga a prueba el escenario de interrupción. Interrumpa el acceso al proveedor de identidades y la conectividad a Internet de la ubicación por separado. Demuestre la recuperación sin necesidad de distribuir una contraseña común.
- Realice la transición de forma progresiva. Revise la contabilidad, la segmentación y el comportamiento de los clientes en cada ubicación. Elimine la clave de acceso antigua una vez superadas las comprobaciones de aceptación acordadas.
Sepa cuándo no debe realizar la migración
Las ubicaciones aisladas (air-gapped) no pueden depender de un plano de control en la nube. Los controladores incapaces de procesar los atributos RADIUS requeridos también pueden bloquear el diseño previsto, incluso si la autenticación básica funciona.
Cualquier requisito interno para mantener los metadatos de autenticación en el Reino Unido debe resolverse mediante ubicaciones de procesamiento documentadas y acuerdos con subcontratistas. El hecho de que un proveedor tenga oficina en el Reino Unido no basta para cumplirlo. La conservación de registros, el acceso administrativo y los planes de recuperación también deben incluirse en la aprobación de adquisiciones.
Nuestro servicio funciona como una superposición en la nube sobre los puntos de acceso existentes, por lo que no requiere sustituir toda la infraestructura. Nuestro xPSK y WiFi multiinquilino es compatible con hardware de Meraki, Aruba, Ruckus y UniFi, sujeto a las capacidades del controlador requeridas por el diseño.
Un modelo híbrido entre autenticación empresarial y claves únicas resuelve la compatibilidad con los clientes, pero no necesariamente la dependencia de caídas en la nube. En los casos en que la autonomía local sea fundamental, mantenga un diseño de autenticación local adecuado o permanezca en una infraestructura local. No disfrace un requisito de resiliencia no resuelto bajo una contraseña de excepción.
Decida si Cloud RADIUS se adapta a su infraestructura
Elija Cloud RADIUS cuando varios centros necesiten un acceso coherente basado en la identidad y su equipo no quiera mantener servidores de autenticación. el argumento más sólido es operativo: los cambios en el directorio deben regir el acceso a la red sin generar otra carga de trabajo de administración de cuentas.
Permanezca en una solución local cuando su equipo ya opere correctamente un RADIUS resiliente, un servicio alojado entre en conflicto con sus requisitos de procesamiento de datos o el controlador no pueda aplicar la directiva propuesta. Una migración que elimina un servidor pero debilita la disponibilidad local no supone un avance.
Tome la decisión basándose en el inventario de sus instalaciones
Elija un modelo de acceso híbrido cuando los extremos gestionados del personal admitan 802.1X, pero el edificio contenga también televisores, impresoras, escáneres o equipos clínicos que requieran claves delimitadas. El objetivo es ofrecer un nivel de garantía adecuado para cada grupo de usuarios, no credenciales idénticas para todos los dispositivos.
Elabore un inventario con:
- Infraestructura inalámbrica: SSID, fabricante del controlador, modelo y firmware.
- Titularidad de la identidad: Directorio principal, propietarios de grupos y proceso de bajas.
- Capacidad de los clientes: Qué dispositivos pueden utilizar certificados y cuáles no.
- Dependencias operativas: Sistemas que deben permanecer disponibles en caso de pérdida de conectividad.
Compare compromisos por escrito, no demostraciones
Formule las mismas preguntas a todos los servicios seleccionados: qué cubre el compromiso de disponibilidad durante fallos multisitio, cuánto tiempo se conservan los registros, dónde se procesan los metadatos de autenticación, qué subcontratistas pueden acceder a ellos y cómo evita el plan de recuperación el recurso a una contraseña compartida?
Incluya a Purple en su lista de candidatos junto con otros proveedores cuando su infraestructura coincida con el patrón de invitados, personal y entorno multiinquilino. Hemos prestado soporte a estos entornos desde 2012 en comercios minoristas, organizaciones sanitarias, estadios, centros de transporte y centros urbanos. Las tarifas de nuestro WiFi para empleados no son públicas, por lo que le invitamos a contactar con nosotros para solicitar un presupuesto adaptado a las instalaciones que va a migrar.
Su siguiente paso es elaborar un plan de aceptación respaldado por el inventario. Una demostración impecable nunca debe sustituir la superación de las pruebas por parte de su controlador, su directorio y sus dispositivos más complejos.
Purple ofrece RADIUS alojado para la autenticación del personal, junto con WiFi para invitados y un acceso aislado multiinquilino. Visite Purple con el inventario de sus controladores, sus requisitos de proveedor de identidades y la lista de sus dispositivos heredados para consultar un despliegue y un presupuesto basados en su infraestructura actual.
