Migración multisitio de RADIUS: secuenciación de sitios, puntos de acceso y directivas

Puede migrar una infraestructura multisede a cloud RADIUS en cuatro fases sin necesidad de un cambio radical repentino cuando los servidores antiguos y nuevos se ejecutan en paralelo. Cada SSID enumera ambos y cada dispositivo confía en el certificado del nuevo servidor. Cada sede realiza la transición bajo IEEE 802.1X con una prueba de salida por escrito. En Purple, la transición en sí suele ser un trabajo de fin de semana.

¿Qué cambia en una migración RADIUS multisede y qué se mantiene?

El estado final es una política cloud RADIUS que da servicio a cada sede, con la identidad definiendo la VLAN. RADIUS, definido en RFC 2865, es el protocolo que utilizan sus puntos de acceso para preguntar a un servidor si un dispositivo puede unirse. El servidor acepta o rechaza el dispositivo. También puede devolver atributos como la VLAN, el segmento de red en el que aterriza el dispositivo.

En una red segura, ese intercambio se ejecuta dentro de IEEE 802.1X, el estándar para el control de acceso a la red basado en puertos. 802.1X transporta EAP (Extensible Authentication Protocol) entre el dispositivo, el punto de acceso y el servidor. EAP-TLS, definido en RFC 5216, autentica a ambas partes con certificados. PEAP envuelve un intercambio de contraseñas dentro de un túnel TLS.

Cambian cuatro cosas:

• Cada punto de acceso o controlador apunta a una nueva dirección de servidor y secreto compartido. RADIUS llama a ese dispositivo el NAS (network access server).
• Los dispositivos ven un nuevo certificado de servidor durante el protocolo de enlace EAP.
• La política lee grupos de Microsoft Entra ID, Okta o Google Workspace en lugar de un directorio local.
• Los registros se trasladan a una nueva consola.

Lo que se mantiene igual importa aún más. Conserva sus puntos de acceso, nombres de SSID, IDs de VLAN, trunks de switches y zonas de firewall. Nadie cambia una contraseña ni se une a una red nueva.

El mismo enfoque se aplica a las tres redes en Purple Access. En redes abiertas, muchos Captive Portals autorizan dispositivos a través de RADIUS. Las redes seguras utilizan EAP-TLS o PEAP. En redes xPSK, RADIUS da a cada dispositivo o residente su propia clave precompartida. Esta guía sigue la red segura, porque es la que conlleva más riesgo.

{"tone":"warning","title":"El riesgo real: la confianza en el certificado del servidor","text":"Los dispositivos en EAP-TLS o PEAP comprueban el certificado del servidor RADIUS y muchos confían únicamente en la autoridad de certificación del servidor antiguo. Despliegue la nueva CA en cada perfil de dispositivo antes de trasladar la primera sede, o esos dispositivos no podrán unirse y seguirán reintentándolo."}

Una vez resuelta la confianza en los certificados, el resto de la migración es trabajo de configuración y periodos de espera.

¿Qué debe ser cierto antes de la fase 1?

Deben cumplirse cinco condiciones antes de crear cualquier política. Si falta una, causará problemas en una fase posterior.

Un inventario de NAS completo

Enumere todos los dispositivos que envían solicitudes al servidor antiguo. Esto incluye puntos de acceso, controladores inalámbricos, conmutadores que realizan 802.1X por cable y pasarelas VPN. Elabore la lista a partir de la lista de clientes RADIUS del servidor antiguo, no del diagrama de red. Si falta un NAS en el inventario, no podrá apagar el servidor antiguo en la fase 4.

Un mapa de políticas, fila por fila

Anote cada regla que aplica el servidor antiguo, con su condición, su resultado y los atributos que devuelve. Las filas típicas se ven así: grupo de personal a VLAN de personal, contratistas a una VLAN restringida, portátiles corporativos por certificado a la VLAN corporativa. Tome nota de qué atributos llevan la VLAN. El RFC 3580 (https://www.rfc-editor.org/rfc/rfc3580) define el conjunto estándar: Tunnel-Type, Tunnel-Medium-Type y Tunnel-Private-Group-ID. Algunas instalaciones utilizan atributos específicos de cada proveedor en su lugar, y debe replicarlos de forma exacta.

Un plan de certificados

Decida qué autoridad de certificación (CA) emite el certificado del nuevo servidor. En los dispositivos gestionados, distribuya esa CA a través de Microsoft Intune, Jamf o su plataforma de gestión de dispositivos móviles (MDM) antes de realizar cualquier traslado de ubicación. Para EAP-TLS, el nuevo servidor también debe confiar en la CA que emitió los certificados de sus dispositivos.

Una fuente de identidad que el nuevo servidor pueda leer

Conecte su proveedor de identidad y confirme que todos los grupos del mapa de políticas existen allí. Si un grupo existe únicamente en el servidor antiguo, vuelva a crearlo primero en el proveedor de identidad.

Accesibilidad, responsables y ventanas de cambio

Cada ubicación necesita una ruta de red hacia el servidor en la nube, utilizando las direcciones y los puertos indicados en la documentación de incorporación de Purple. Asigne un responsable para cada ubicación y acuerde las ventanas de cambio con los directores de cada centro. Deje definido el detonante de la reversión (rollback) antes de realizar cualquier movimiento.

{"title":"Lista de comprobación para la migración de RADIUS multisitio","groups":[{"heading":"Antes de la fase 1","items":[{"text":"Exporte la lista de clientes RADIUS del servidor antiguo y concíliela con el inventario de NAS","why":"Un NAS olvidado bloquea el desmantelamiento"},{"text":"Mapee cada regla de directiva: condición, resultado y atributos devueltos"},{"text":"Confirme que cada grupo de directivas existe en Microsoft Entra ID, Okta o Google Workspace"},{"text":"Despliegue la CA del nuevo servidor en los dispositivos gestionados mediante su MDM"},{"text":"Abra las rutas indicadas en la documentación de integración de Purple en cada sede"},{"text":"Asigne un responsable y una ventana de cambio por sede, y acuerde el activador de reversión por escrito"}]},{"heading":"Fase 1: creación","items":[{"text":"Congele los cambios de directivas en el servidor antiguo"},{"text":"Vuelva a crear cada fila de directiva en el nuevo servidor"},{"text":"Pruebe una identidad por fila en ambos servidores y compruebe que las respuestas coinciden"}]},{"heading":"Fases 2 y 3: piloto y oleadas","items":[{"text":"Registre una tasa de rechazo de referencia por sede antes de la transición"},{"text":"Añada el nuevo servidor junto al antiguo en cada SSID"},{"text":"Confirme que todas las clases de dispositivos se autentican en el nuevo servidor"},{"text":"Mantenga cada oleada durante un ciclo comercial completo antes de pasar a la siguiente"}]},{"heading":"Fase 4: desmantelamiento","items":[{"text":"Elimine el servidor antiguo de cada SSID y NAS"},{"text":"Confirme que no hay peticiones en el servidor antiguo durante el periodo de inactividad acordado"},{"text":"Exporte y conserve los registros del servidor antiguo según su directiva de retención"},{"text":"Retire los secretos compartidos utilizados con el servidor antiguo"},{"text":"Actualice el manual de procedimientos y archive el registro de la prueba de salida de cada sede"}]}],"download":{"filename":"radius-migration-checklist.csv"}}

¿Cuáles son las 4 fases, en orden?

El plan consta de cuatro fases. Cada una de ellas finaliza con una prueba de salida que se puede aprobar o suspender. Nada pasa a la siguiente fase hasta que se aprueba la prueba, evitando así una transición drástica sin retorno.

{"kind":"timeline","direction":"lr","caption":"Instalación ilustrativa de 40 sedes: cuatro fases, cada una finalizada con una prueba de salida","alt":"Cronograma que muestra la preparación, seguida de la fase 1 de construcción, fase 2 de piloto, fase 3 por oleadas y fase 4 de desmantelamiento en unas 12 semanas.","nodes":[{"id":"p0","label":"Antes de la fase 1","sub":"Inventario, mapa de directivas, despliegue de CA, fuente de identidad","tone":"neutral","when":"Semanas 1-2"},{"id":"p1","label":"Fase 1: construcción y réplica","sub":"Directiva reconstruida en cloud RADIUS, las respuestas de laboratorio coinciden","tone":"brand","when":"Semana 3"},{"id":"p2","label":"Fase 2: sede piloto","sub":"Una sede, el servidor antiguo se mantiene como secundario","tone":"brand","when":"Semanas 4-5"},{"id":"p3","label":"Fase 3: oleadas","sub":"Cinco, luego 10 y después las 24 sedes restantes","tone":"brand","when":"Semanas 6-10"},{"id":"p4","label":"Fase 4: desmantelamiento","sub":"Cero solicitudes en el servidor antiguo, luego apagar","tone":"success","when":"Semanas 11-12"}],"edges":[{"from":"p0","to":"p1","label":"prerrequisitos cumplidos"},{"from":"p1","to":"p2","label":"las respuestas de laboratorio coinciden"},{"from":"p2","to":"p3","label":"prueba de salida del piloto"},{"from":"p3","to":"p4","label":"todas las sedes migradas"}]}

{"caption":"Plan de fases para una migración de RADIUS en múltiples sedes","asOf":"2026-06-10","columns":[{"key":"phase","label":"Fase"},{"key":"scope","label":"Alcance"},{"key":"owner","label":"Propietario"},{"key":"exit","label":"Prueba de salida"}],"rows":[["Antes de la fase 1","Inventario NAS, mapa de directivas, despliegue de CA, fuente de identidad, rutas de sedes","Responsable de TI con el responsable de identidad y acceso","Cada NAS enumerado, cada grupo de directivas en el proveedor de identidades, nueva CA en dispositivos gestionados"],["Fase 1: construcción","Directiva reconstruida en cloud RADIUS, sin tráfico en directo","Responsable de identidad y acceso","Una identidad de prueba por fila obtiene la misma respuesta y VLAN del antiguo y del nuevo"],["Fase 2: piloto","Una sede representativa, servidor nuevo como primario y antiguo como secundario","Arquitecto de red","Un ciclo de negocio sin rechazos no explicados y todas las clases de dispositivos vistas en el nuevo servidor"],["Fase 3: oleadas","Sedes restantes en oleadas crecientes, agrupadas por plantilla de consola","Arquitecto de red con los propietarios de las sedes","Cada oleada supera la prueba de salida del piloto antes de iniciar la siguiente"],["Fase 4: desmantelamiento","Servidor antiguo eliminado de cada SSID y NAS","Responsable de TI","Cero solicitudes en el servidor antiguo durante el periodo de inactividad, registros conservados, secretos retirados"]],"footnote":"Los propietarios son roles, no personas concretas. Establezca el periodo de inactividad en al menos un ciclo de reautenticación más una semana laborable.","download":{"filename":"radius-migration-phase-plan.csv"}}

¿Qué ocurre dentro de cada fase?

Fase 1: construir y replicar la directiva

Reconstruya el mapa de directivas en el nuevo servidor antes de que le llegue ninguna solicitud en directo. Conecte el proveedor de identidades y vuelva a crear cada fila con su condición, resultado y atributos devueltos. Mantenga los ID de VLAN idénticos para que la configuración del switch y del firewall no cambie nunca.

Pruebe cada fila desde un laboratorio. Utilice eapol_test, una herramienta del proyecto wpa_supplicant. Envía un intercambio EAP real a un servidor RADIUS y muestra la respuesta. Ejecute una identidad por fila contra ambos servidores y compare las respuestas. La prueba finaliza con éxito si hay coincidencia en cada fila, con el mismo resultado de aceptación o rechazo y la misma VLAN.

Fase 2: prueba piloto en una ubicación

Elija una ubicación que sea representativa de todo el entorno, no la más sencilla. Debe incluir todas las clases de dispositivos con las que opere, incluidas las más complejas. Piense en escáneres portátiles, terminales de pago por WiFi y portátiles más antiguos. También necesitará a alguien en el lugar que pueda probar un dispositivo cuando se le solicite.

Añada el nuevo servidor junto al antiguo, pruébelo y, a continuación, configure el nuevo servidor como primario. Manténgalo durante un ciclo comercial completo. En el caso de un hotel, esto equivale a una semana de turnos rotativos. En una oficina, supone una semana de inicios de sesión de lunes por la mañana. La prueba piloto se da por superada cuando se cumplen dos condiciones. Primero, que todas las clases de dispositivos se hayan autenticado en el nuevo servidor. Segundo, que la tasa de rechazo no sea peor que su línea base.

Fase 3: migración del entorno por oleadas

Haga que cada oleada sea mayor que la anterior a medida que se completen con éxito. En un entorno de 40 ubicaciones, se podría migrar primero la ubicación piloto, luego cinco, después 10 y finalmente las 24 restantes. Agrupe cada oleada por plantilla de consola o grupo, de modo que un solo cambio se aplique a todas las ubicaciones incluidas. Las plantillas de configuración de Meraki, las plantillas WLAN de Juniper Mist y los grupos de HPE Aruba Central se adaptan perfectamente a este enfoque.

Realice la transición mientras el personal de la ubicación esté presente, no a las 3:00 am. Un cambio que nadie prueba hasta la mañana siguiente es un cambio que no se ha probado. Evite acumular otros cambios de red dentro de la misma ventana de mantenimiento.

Fase 4: desmantelamiento del servidor antiguo

Elimine el servidor antiguo de cada SSID y de cada NAS del inventario y, a continuación, supervise sus registros. Las solicitudes deben reducirse a cero. Cualquier petición que siga llegando procederá de un NAS que haya omitido. Mantenga este periodo de inactividad durante al menos un ciclo de reautenticación completo más una semana laboral. Después, exporte los registros según su directiva de retención, apague el servidor y retire sus secretos compartidos.

Caso práctico: un grupo de 40 hoteles con Cisco Meraki

Tomemos como ejemplo un grupo de 40 hoteles que opera la WiFi del personal sobre Cisco Meraki. Utiliza PEAP contra un servidor RADIUS local situado en la sede central. Cada solicitud atraviesa la red WAN hacia un único edificio, por lo que una caída en la sede central deja sin WiFi al personal de todos los hoteles.

El grupo distribuye la nueva CA a través de su MDM durante la primera semana. Reconstruye cinco filas de directiva en cloud RADIUS conectándolo con Microsoft Entra ID y, a continuación, realiza una prueba piloto en un hotel urbano de 120 habitaciones. A continuación se suceden oleadas de cinco, 10 y 24 hoteles, gestionada cada una mediante una plantilla de configuración de Meraki. Un hotel debe revertir los cambios durante una tarde porque una tablet del personal de limpieza solo confía en la CA antigua. Vuelve a migrarse una semana después.

El resultado:

• Los 40 hoteles se migran en seis ventanas de cambio.
• Una ubicación revierte los cambios en una sola ocasión.
• La sede central deja de estar en la ruta de autenticación.

¿Cómo funcionan en paralelo el servidor RADIUS antiguo y el nuevo?

La ejecución en paralelo depende de cómo fallen los puntos de acceso en la conmutación por error. Un NAS envía cada solicitud al primer servidor de su lista. Solo intentará conectarse con el siguiente servidor cuando el primero no responda dentro del tiempo de espera (timeout).

Un Access-Reject se considera una respuesta, no un fallo, por lo que el NAS no reintentará la solicitud en otro lugar. Esto tiene dos consecuencias:

• Ambos servidores deben dar la misma respuesta. Si difieren, la experiencia del dispositivo dependerá del servidor que haya respondido en ese momento.
• La ejecución en paralelo es una red de seguridad, no una prueba. Pruebe la política en la fase 1 y en el piloto. No la pruebe esperando a ver qué hace la conmutación por error.

Compruebe los tiempos de espera antes de trasladar la primera ubicación. Un servidor en la nube está más distante que un servidor situado en su sala de comunicaciones. Compare los ajustes de reintento y tiempo de espera del NAS de cada ubicación con su tiempo de ida y vuelta (RTT). Si los ajustes son demasiado estrictos, las solicitudes se desviarán al servidor antiguo sin un motivo real, lo que ocultará los problemas. Traslade la contabilidad RADIUS al nuevo servidor en el mismo momento que la autenticación, para que los registros de sesión permanezcan en un solo lugar.

La transición en cada ubicación consiste simplemente en cambiar el orden de los dos servidores. Estos pasos se aplican a todas las ubicaciones, con las diferencias de cada proveedor indicadas dentro del paso 2.

{"title":"Cambiar una ubicación sin un día de interrupción total","steps":[{"title":"Confirmar que la ubicación está lista","body":"Compruebe la ubicación con la lista de verificación de migración: NAS en la lista, nueva CA en dispositivos gestionados, ruta a Purple abierta, responsable en la ubicación.","check":"Se han cumplido todos los requisitos previos para la ubicación."},{"title":"Añadir el nuevo servidor junto al antiguo","body":"Añada el RADIUS en la nube de Purple a la lista de servidores RADIUS del SSID, utilizando el secreto compartido que Purple emite para la ubicación. Deje el servidor antiguo en primer lugar por ahora.","check":"La consola muestra ambos servidores junto al SSID.","variants":[{"label":"Meraki","body":"En el Meraki Dashboard, añada el servidor en la configuración de control de acceso del SSID, preferiblemente en la plantilla de configuración."},{"label":"Aruba","body":"En HPE Aruba Central, añada el servidor al grupo de servidores de autenticación que utiliza la WLAN."},{"label":"Ruckus","body":"Añada el servidor al perfil del servidor AAA que utiliza la WLAN, como servidor secundario."},{"label":"Mist","body":"En el portal de Juniper Mist, añada el servidor a los servidores de autenticación RADIUS de la WLAN, preferiblemente en la plantilla de la WLAN."},{"label":"UniFi","body":"En la aplicación UniFi Network, añada el servidor al perfil RADIUS asignado a la red WiFi."}]},{"title":"Probar antes de intercambiar","body":"Desde un host de prueba registrado como cliente RADIUS, envíe una identidad por fila de directiva al nuevo servidor.","code":{"lang":"bash","text":"eapol_test -c eap-tls.conf -a <purple-radius-address> -p 1812 -s <shared-secret>"},"check":"Cada identidad recibe Access-Accept o Access-Reject según lo indicado en el mapa de directivas, con la VLAN esperada."},{"title":"Invertir el orden","body":"Establezca el nuevo servidor como primario y mantenga el antiguo como secundario. Este es el punto de cambio.","check":"Los registros del nuevo servidor muestran solicitudes de cada punto de acceso en la ubicación."},{"title":"Mantener durante un ciclo comercial","body":"Compare la tasa de rechazo con su línea base y confirme que cada clase de dispositivo se ha autenticado.","check":"Sin rechazos no explicados, y la ubicación supera su prueba de salida."}]}

¿Cómo se revierte una ubicación o una fase?

Revertir es el proceso de cambio a la inversa: vuelve a colocar el servidor antiguo en primer lugar. En cada consola mencionada anteriormente, esto supone un solo cambio de configuración. Solo funciona si el servidor antiguo sigue en funcionamiento, sin cambios y con sus secretos compartidos intactos. Por eso, la retirada del servicio se realiza al final. También es la razón por la que se congela la directiva en el servidor antiguo al inicio de la fase 1.

Acuerde los desencadenantes antes de empezar. Los desencadenantes habituales son:

• Una clase de dispositivo que no puede unirse y no tiene solución en el mismo día.
• Asignaciones de VLAN que difieren del mapa de directivas.
• Una tasa de rechazo superior a la línea base que no pueda explicar dentro de la ventana de cambio.

{"title":"Avanzar, pausar o revertir una oleada","start":"q1","nodes":[{"id":"q1","question":"¿Falla algún tipo de dispositivo en el nuevo servidor que funcionaba en el antiguo?","help":"Compare los rechazos por tipo de dispositivo con la línea base registrada antes del cambio.","options":[{"label":"Sí","to":"q2"},{"label":"No","to":"q3"}]},{"id":"q2","question":"¿El fallo se limita a una clase de dispositivo con una solución conocida?","help":"La falta de una CA en un perfil es una solución conocida. Los rechazos en varias clases no lo son.","options":[{"label":"Sí","to":"o2"},{"label":"No","to":"o3"}]},{"id":"q3","question":"¿Cada identidad de prueba acaba en la VLAN prevista en todos los sitios de la oleada?","options":[{"label":"Sí","to":"q4"},{"label":"No","to":"o3"}]},{"id":"q4","question":"¿Ha completado la oleada un ciclo comercial completo sin rechazos no explicados?","options":[{"label":"Sí","to":"o1"},{"label":"No","to":"o2"}]},{"id":"o1","outcome":"Avanzar: iniciar la siguiente oleada","detail":"Registre el resultado de la prueba de salida por sitio y programe la siguiente oleada.","link":"[One policy across every location](guide:cloud-radius-multi-site)"},{"id":"o2","outcome":"Pausar: corregir y volver a probar","detail":"Coloque el servidor antiguo en primer lugar solo en el SSID afectado, corrija el perfil o regla y repita la prueba de salida."},{"id":"o3","outcome":"Revertir la oleada","detail":"Coloque el servidor antiguo en primer lugar en todos los SSID de la oleada, capture los registros de ambos servidores y determine la causa antes de reintentar.","link":"[When RADIUS is unreachable](guide:radius-server-down-wifi)"}]}

Tras cualquier reversión, exporte los registros de ambos servidores para el periodo con errores. Identifique la causa y corríjala en la nueva directiva. A continuación, vuelva a ejecutar la prueba de laboratorio de la fase 1 para la fila afectada antes de desplazar de nuevo el sitio.

¿Cómo saber si la migración ha finalizado?

La migración finaliza cuando las evidencias lo confirman, no al desplazar el último sitio. Cinco pruebas permiten cerrarla:

1. El servidor antiguo ha registrado cero solicitudes durante el periodo de inactividad acordado.
2. Todos los NAS del inventario aparecen en los registros del nuevo servidor.
3. Un dispositivo real ha probado cada fila de directiva y ha accedido a la VLAN prevista.
4. La tasa de rechazo se sitúa en la línea base registrada antes de la fase 2 o por debajo de ella.
5. El servidor antiguo está apagado, sus registros se conservan, sus credenciales secretas se han retirado y el libro de procedimientos está actualizado.

Guarde un registro de una página para cada sitio con la fecha, el resultado de la prueba de salida y cualquier reversión realizada. Junto con los nuevos registros de autenticación, esos registros constituyen la evidencia para los controles de acceso de ISO 27001 y los controles de registro de PCI-DSS. También sirven como evidencia de control de cambios para el próximo ciclo de auditoría.

Modos de fallo habituales en el entorno real

Dispositivos que solo confían en el certificado antiguo

Este es el fallo más común. Los dispositivos PEAP no gestionados pueden solicitar el nuevo certificado o rechazarlo por completo. Algunos perfiles gestionados fijan tanto el nombre del servidor como la CA. Compruebe ambos elementos antes del piloto.

Un NAS que nadie incluyó en la lista

Los controladores consolidados en el olvido, los switches 802.1X cableados y las pasarelas VPN mantienen ocupado al servidor antiguo mucho después de que la red WiFi se haya migrado. El período de inactividad de la fase 4 es la forma de detectarlos.

Directivas que residían en el servidor antiguo

Los grupos locales, las listas MAC codificadas de forma rígida y las reglas según la hora del día suelen existir solo en el servidor antiguo. Si no están en el mapa de directivas, desaparecerán en el momento de la transición.

Desajustes en secretos compartidos y atributos

Un secreto mal escrito falla en silencio en algunas consolas. Una VLAN devuelta por nombre en lugar de por ID puede arrastrar dispositivos a la VLAN predeterminada. Ambos problemas deberían aparecer durante las pruebas de la fase 1 y deben comprobarse de nuevo en la fase piloto.

Tiempos de espera ajustados para un servidor local

Los tiempos de espera muy estrictos en un NAS provocan una conmutación por error falsa al servidor antiguo. Todo parece funcionar hasta que el servidor antiguo se retira.

Caso práctico: un minorista de 120 tiendas con dos consolas

Tomemos como ejemplo un minorista de 120 tiendas con establecimientos más antiguos en HPE Aruba y otros más recientes en Juniper Mist. Los dispositivos portátiles y portátiles de las tiendas utilizan EAP-TLS contra un par de servidores RADIUS locales. La prueba piloto y las oleadas transcurren sin problemas, agrupadas por grupo de Aruba Central y plantilla WLAN de Mist.

En la fase 4, los servidores antiguos siguen registrando solicitudes de tres direcciones después de haber migrado cada SSID. Dos son controladores del centro de distribución fuera del parque de tiendas. La tercera es una pasarela VPN para los portátiles de la sede central. El equipo añade las tres al inventario, las traslada en una ventana adicional y reinicia el período de inactividad. El desmantelamiento finaliza dos semanas más tarde, sin ninguna interrupción en ninguna tienda.

Dónde encaja Purple

Purple Access gestiona redes abiertas, seguras y xPSK en una sola plataforma, utilizando los puntos de acceso que ya posee. La red segura impulsa esta migración. Proporciona RADIUS en la nube, EAP-TLS e identidad desde Microsoft Entra ID, Okta o Google Workspace. También admite Passpoint, también llamado Hotspot 2.0, que permite que los dispositivos se unan a una red segura de forma automática mediante una credencial. Purple no depende del hardware, por lo que una única directiva presta servicio a sitios en estas plataformas:

• Cisco Meraki
• HPE Aruba
• Ruckus
• Juniper Mist
• Ubiquiti UniFi
• Cambium
• Extreme
• Fortinet

Esto significa que un parque mixto se puede migrar con un solo plan.

Purple opera la mayor infraestructura RADIUS en la nube del mundo. Incluye un SLA de tiempo de actividad RADIUS del 99,9 %, en una plataforma que funciona con un tiempo de actividad del 99,999 %. Dado que la parte de Purple se configura antes de que comience la fase 2, la transición de cada sitio suele ser un ejercicio de fin de semana. Las fases existen para gestionar el riesgo en su parque informático, no en nuestra plataforma.

{"items":[{"value":"80,000+","label":"ubicaciones activas","note":"Datos propios de Purple"},{"value":"90","label":"países"},{"value":"99.9%","label":"SLA de tiempo de actividad de RADIUS","note":"En una plataforma con un 99.999% de tiempo de actividad"}]}

{"tone":"proof","title":"WiFi para empleados a escala de sucursales","text":"JPMorgan gestiona la red WiFi para empleados con Purple en 5000 sucursales."}

Consulte cloud RADIUS en Purple Access para obtener los detalles del producto y la guía de seguridad para empresas de WiFi para conocer el conjunto de controles más amplio. El marketing para invitados se encuentra en Engage y el filtrado de DNS en Shield. Ninguno de los dos cambia durante una migración de RADIUS.

Preguntas frecuentes

¿Cuánto tiempo lleva una migración de RADIUS multisede?

Planifique varias semanas para todo el parque y un fin de semana por sede. En Purple, la transición de cada sede suele ser un trabajo de fin de semana. La totalidad del parque lleva más tiempo porque cada ola se mantiene durante un ciclo comercial antes de comenzar la siguiente. Un parque ilustrativo de 40 sedes tarda unas 12 semanas desde el inventario hasta la retirada del servicio. La mayor parte de ese tiempo se dedica a la preparación y a los periodos de mantenimiento, no al trabajo de cambio.

¿Necesito nuevos puntos de acceso para migrar a cloud RADIUS?

No. Cloud RADIUS cambia el servidor al que consultan sus puntos de acceso, no los puntos de acceso en sí. Purple funciona con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. Solo tiene que añadir el nuevo servidor a la lista de servidores de RADIUS de cada SSID en la consola que ya utiliza. Sus SSID, ID de VLAN y la configuración de los switches se mantienen tal cual.

¿Cómo debo modelar el coste de cloud RADIUS en múltiples sedes?

Modélelo basándose en dos cifras: sedes e identidades. Cuente cada sede que se autentique y cada identidad que se conecte, incluidos los dispositivos en EAP-TLS. Luego, compare eso con el coste total del servidor antiguo: hardware, licencias, parches, alta disponibilidad y la ruta WAN a la oficina central. Nuestra guía para modelar el coste por sede de cloud RADIUS explica detalladamente el cálculo.

¿Puedo mantener el servidor de RADIUS antiguo como alternativa de respaldo tras la migración?

Manténgalo durante la ejecución en paralelo y, a continuación, apáguelo. Mientras figure como secundario, cubrirá los Tiempos de espera agotados en las sedes que aún estén en las olas de migración. Después de la fase 4, un servidor que contenga una copia congelada de la directiva antigua se convierte en un riesgo, ya que cualquier respuesta que dé utilizará reglas obsoletas. A partir de ese momento, la resiliencia proviene del SLA de tiempo de actividad del 99,9 % de RADIUS y de un plan de recuperación ante interrupciones.

¿Tendrá el personal que volver a inscribir sus dispositivos?

No si el certificado del nuevo servidor es de confianza antes de la transición. Distribuya la nueva CA a los dispositivos gestionados a través de su MDM durante la fase de creación. Los dispositivos EAP-TLS conservan sus certificados de cliente existentes, siempre que el nuevo servidor confíe en la CA que los emitió. Los dispositivos PEAP no gestionados son la excepción, ya que algunos solicitan confirmación una vez para aceptar el nuevo certificado. Envíe a ese personal un aviso breve antes de que su sede migre.

¿Afecta la migración a nuestras evidencias de ISO 27001 o PCI DSS?

Esto cambia el origen de sus evidencias, por lo que debe planificarlo desde el principio. Los registros de autenticación, las definiciones de directivas y los registros de cambios se trasladan a la nueva plataforma. Conserve los registros del servidor antiguo según su directiva de retención y archive el registro de la prueba de salida de cada sede. Purple cuenta con la certificación ISO 27001, lo que proporciona evidencias a sus auditores respecto a la plataforma. Sus propios controles seguirán necesitando sus propias evidencias.

¿En qué se diferencia esto para un MSP que gestiona varios entornos?

Las fases son las mismas. Lo que cambia es el aislamiento entre entornos. Un MSP ejecuta las mismas cuatro fases para cada entorno, pero cada uno requiere su propia directiva, origen de identidad y registros dentro de una plataforma compartida. Las oleadas suelen seguir los límites de los contratos en lugar de las plantillas de la consola. Nuestra guía sobre RADIUS multinquilino para MSP explica cómo mantener cada entorno separado durante y después del traslado.