Migración de Cisco ISE a RADIUS en la nube: un plan de transición por fases

Puede migrar de Cisco ISE a RADIUS en la nube en cinco fases sin necesidad de fijar un día crítico en el que cada dispositivo deba confiar en el nuevo certificado de servidor. Ejecute Purple junto con ISE sede por sede. Mantenga IEEE 802.1X y EAP-TLS sin cambios en el cliente. Realice la transición por oleadas, utilizando ISE como vía de retorno hasta que se haya migrado la última sede.

¿Qué cambia al abandonar Cisco ISE y qué permanece igual?

El estado final es sencillo de describir. Sus puntos de acceso envían solicitudes de autenticación a RADIUS en la nube de Purple en lugar de a los nodos de ISE de su centro de datos. Purple verifica la identidad con Microsoft Entra ID, Okta o Google Workspace. A continuación, devuelve la VLAN a la que pertenece dicha identidad. ISE se apaga, sus licencias caducan y nadie vuelve a aplicarle parches.

En primer lugar, veamos algunos términos. RADIUS (RFC 2865) es el protocolo de autenticación con el que ya se comunican sus controladores. IEEE 802.1X es el estándar de control de acceso basado en puertos que traslada el inicio de sesión sobre WiFi. EAP-TLS (RFC 5216) autentica cada dispositivo mediante un certificado. PEAP envuelve un intercambio de contraseñas dentro de un túnel TLS cifrado. Una VLAN, o LAN virtual, es el segmento de red en el que se ubica un dispositivo tras autenticarse.

Hay cuatro aspectos que cambian:

• Las direcciones del servidor RADIUS y los secretos compartidos en cada dispositivo de acceso a la red (NAD), es decir, el controlador, el punto de acceso o el panel en la nube que envía las solicitudes.
• El certificado de servidor que los dispositivos ven durante la autenticación 802.1X.
• Dónde reside la directiva. Los conjuntos de directivas y los perfiles de autorización de ISE se convierten en grupos de identidad asignados a VLAN.
• De dónde procede la identidad. Un directorio en la nube sustituye a ISE unido a un Active Directory local.

Sus SSID, puntos de acceso, VLAN, conmutación y cualquier certificado de cliente de su propia autoridad de certificación (CA) se mantienen tal cual. Esto es lo que permite llevar a cabo una migración en fases. Las propias funciones de ISE necesitan un destino, y no todas se transfieren a la red segura.

Lo que hace ISE actualmente	Adónde se traslada	Red de Purple
802.1X para empleados y dispositivos corporativos	RADIUS en la nube de Purple con EAP-TLS y su proveedor de identidad	Segura
MAB (MAC Authentication Bypass) para escáneres, impresoras y sensores	Una clave por dispositivo o grupo de dispositivos (iPSK o PPSK, conjuntamente xPSK)	xPSK
Portales de invitados y patrocinados	Un portal cautivo, la página de inicio de sesión previa al acceso	Abierta
Incorporación de BYOD con la CA interna de ISE	Certificados de su MDM o de su propia CA	Segura
TACACS+, 802.1X por cable, postura, TrustSec	Fuera del alcance de este plan; asigne un responsable a cada uno	Ninguna
Este plan cubre la autenticación WiFi en sus puntos de acceso. Si ISE también gestiona la administración de dispositivos, puertos cableados o postura, liste cada uno antes de la fase 1 y asígnele un responsable independiente. Si ISE aloja un portal de invitados utilizado para marketing, este se traslada a la red abierta y a Purple Engage. La guía de red segura sobre certificados, identidad y Passpoint cubre el diseño de destino en profundidad.

¿Qué debe cumplirse antes de la fase 1?

Seis condiciones, cada una con un sí o un no. No empiece la configuración hasta que las seis sean afirmativas.

1. El inventario está completo. Cada SSID, cada NAD con su secreto compartido, cada conjunto de directivas y perfil de autorización, y cada grupo de puntos de extremo que dependa de MAB.
2. Dispone de una línea base de ISE. Registre las autenticaciones por hora y la tasa de éxito por SSID y por sitio durante al menos dos semanas. Los informes y registros en directo de ISE le proporcionan estos datos. Sin una línea base, no podrá determinar si una oleada ha sido exitosa.
3. El plan de certificados está redactado. Anote qué CA emitió los certificados de cliente y qué certificado presenta ISE para EAP. Compruebe si algún dispositivo conserva certificados de la CA interna de ISE.
4. Los grupos de identidad existen en su directorio. Cada regla de autorización de ISE necesita un grupo coincidente en Microsoft Entra ID, Okta o Google Workspace, y cada grupo necesita una VLAN.
5. Los sitios pueden acceder a la nube. Los firewalls de cada sitio permiten el tráfico RADIUS desde el controlador o los AP hacia los servidores RADIUS de Purple.
6. ISE mantiene el soporte. Mantenga ISE con licencia, parches y propietario asignado hasta que finalice la fase 5. Es su plan de recuperación.

Una decisión de diseño también corresponde a esta etapa. PEAP-MSCHAPv2 comprueba un hash de contraseña que los directorios en la nube como Microsoft Entra ID no exponen a los servidores RADIUS. Si ISE valida PEAP contra un Active Directory local, migre primero esos dispositivos a EAP-TLS, mientras ISE aún los autentica. Cambie un solo elemento por oleada: primero el método EAP y luego el servidor RADIUS.

{"tone":"warning","title":"El riesgo más frecuente: la confianza en el certificado del servidor","text":"Cada dispositivo comprueba el certificado del servidor RADIUS durante el proceso 802.1X. Los perfiles que solo confían en el certificado EAP de ISE o en su CA rechazarán a Purple hasta que su MDM aplique la nueva confianza, por lo que debe desplegarla en la fase 2, no la noche del cambio definitivo."}

¿Cuáles son las fases de una migración de ISE, en orden?

Cinco fases, cada una con un responsable y una prueba de salida. Las duraciones a continuación se adaptan a un entorno de 40 sitios; ajústelas a su caso. El cambio definitivo en un sitio determinado suele ser un trabajo de fin de semana. Las semanas previas son las que garantizan su éxito.

{"kind":"timeline","direction":"lr","caption":"Cinco fases para una instalación de 40 sedes que migra de Cisco ISE a Purple cloud RADIUS. ISE se mantiene activo hasta la salida de la fase 5.","alt":"Línea de tiempo de cinco fases de migración, desde el descubrimiento en las semanas 1 a 2 hasta el desmantelamiento de ISE a partir de la semana 10.","nodes":[{"id":"p1","label":"Fase 1: descubrimiento y diseño","sub":"Inventario de NAD, conjuntos de políticas, certificados y dispositivos MAB","tone":"neutral","when":"Semanas 1-2"},{"id":"p2","label":"Fase 2: construcción en paralelo","sub":"Cloud RADIUS, grupos de IdP, reglas de VLAN, confianza de certificados","tone":"brand","when":"Semana 3"},{"id":"p3","label":"Fase 3: piloto en una sede","sub":"Cada clase de dispositivo se autentica en la VLAN correcta","tone":"brand","when":"Semanas 4-5"},{"id":"p4","label":"Fase 4: transición por olas","sub":"Ventanas de cambio en fin de semana, ISE se mantiene para reversión","tone":"brand","when":"Semanas 6-9"},{"id":"p5","label":"Fase 5: desmantelar ISE","sub":"Cero autenticaciones en ISE, nodos apagados","tone":"success","when":"Semana 10+"}],"edges":[{"from":"p1","to":"p2"},{"from":"p2","to":"p3"},{"from":"p3","to":"p4"},{"from":"p4","to":"p5"}]}

{"caption":"Plan de fases de ISE a cloud RADIUS","asOf":"2026-06-10","columns":[{"key":"phase","label":"Fase"},{"key":"scope","label":"Alcance"},{"key":"owner","label":"Responsable"},{"key":"exit","label":"Prueba de salida"}],"rows":[["1. Descubrimiento y diseño","Cada SSID, NAD, conjunto de políticas, perfil de autorización, certificado y dispositivo MAB","Arquitecto de red","Mapeo firmado de cada regla de ISE a un grupo de identidad y VLAN"],["2. Construcción en paralelo","Cloud RADIUS, conexión IdP, reglas de VLAN, claves xPSK, confianza en certificados de servidor","Líder de identidad y acceso","Los dispositivos de prueba se autentican en Purple desde un SSID de laboratorio"],["3. Piloto en una sede","Una sede representativa, cada clase de dispositivo","Director de TI con el responsable de la sede","Cinco días laborables al nivel o por encima de la referencia de ISE, VLAN correcta para cada clase"],["4. Transición por olas","Sedes en grupos, una ventana de cambio para cada uno","Operaciones de red","Cada ola mantiene el nivel de referencia durante 48 horas sin reversión"],["5. Desmantelar ISE","Nodos ISE, entradas NAD, licencias, CA interna","Director de TI","Cero autenticaciones en ISE durante el periodo configurado, evidencias archivadas"]],"footnote":"Las duraciones y los umbrales son valores predeterminados de planificación para una instalación de 40 sedes. Establezca los suyos a partir del nivel de referencia de ISE que capture antes de la fase 1.","download":{"filename":"ise-to-cloud-radius-phase-plan.csv"}}

¿Qué ocurre en cada fase de la migración de ISE?

Fase 1: descubrimiento y diseño

Exporte lo que ISE conoce antes de cambiar nada. Enumere cada conjunto de políticas, sus condiciones y el perfil de autorización que devuelve. La mayoría de las instalaciones descubren que años de reglas se reducen a un puñado de resultados reales: VLAN de personal, VLAN de contratistas, VLAN de IoT, denegar.

Escriba cada resultado como un grupo de identidad y una VLAN. La asignación de VLAN a través de RADIUS utiliza los atributos de túnel descritos en RFC 3580. Algunos controladores también leen atributos específicos del proveedor (VSA), como el atributo de rol que utilizan los controladores de HPE Aruba. Tome nota de los que espera su hardware.

A continuación, busque los dispositivos que no puedan realizar 802.1X. La lista de puntos de conexión de ISE muestra qué direcciones MAC se autentican mediante MAB. Cada una necesita una clave xPSK y una VLAN antes de que su sitio se traslade.

Fase 2: cree Purple en paralelo

Conecte Purple a su proveedor de identidades y cree las reglas de grupo a VLAN de la fase 1. Cargue la CA que emitió sus certificados de cliente para que EAP-TLS los valide. Emita claves xPSK para los grupos de dispositivos sin interfaz de usuario (headless).

Envíe la confianza del certificado de servidor de Purple a cada dispositivo gestionado a través de su MDM. Esta es la tarea que más tiempo requiere en la fase de creación, así que comience el primer día. Configure un SSID de laboratorio apuntando a Purple y autentique un dispositivo de cada clase.

Fase 3: realice una prueba piloto en un sitio representativo

Elija un sitio que tenga todas las clases de dispositivos que posea: Windows, macOS, iOS, Android, escáneres y cualquier elemento inusual. Evite su sitio principal y el más sencillo. Realice la migración con los mismos pasos que utilizará en las oleadas.

Manténgalo durante cinco días laborables. Compare la tasa de éxito de Purple con la referencia de ISE para ese sitio. Compruebe que cada clase de dispositivo llegue a la VLAN correcta. Solucione aquí cualquier fallo, no durante una oleada.

Fase 4: realice la migración por oleadas

Agrupe los sitios restantes en oleadas que un solo equipo pueda mantener en una única ventana de cambio. Ejecute la comprobación de aprobación o rechazo antes de cada oleada. Siga los mismos pasos en cada sitio.

{"title":"Migrar una sede de ISE a Purple cloud RADIUS","steps":[{"title":"Registrar la línea base","body":"Anote las autenticaciones por hora de ISE de la sede y la tasa de éxito por SSID en el registro de migración.","check":"Las cifras de la línea base quedan registradas antes de abrir la ventana."},{"title":"Apuntar el SSID seguro a Purple","body":"Sustituya los servidores RADIUS de ISE por los servidores de Purple y el secreto compartido. Mantenga anotadas las entradas de ISE para la reversión.","check":"El panel de control muestra a Purple como el servidor RADIUS para este SSID.","variants":[{"label":"Cisco Meraki","body":"En Meraki Dashboard, edite la configuración del control de acceso del SSID y actualice la lista de servidores RADIUS."},{"label":"HPE Aruba","body":"En Aruba Central o en el controlador, actualice el grupo de servidores utilizado por el perfil 802.1X de la WLAN."},{"label":"Ruckus","body":"En RUCKUS One o SmartZone, actualice el servidor AAA asignado a la WLAN."},{"label":"Juniper Mist","body":"En el panel de control de Mist, edite la configuración de seguridad empresarial de la WLAN y actualice los servidores RADIUS."},{"label":"Ubiquiti UniFi","body":"En UniFi Network, actualice el perfil RADIUS utilizado por el SSID empresarial."}]},{"title":"Reconectar dispositivos de prueba","body":"Vuelva a conectar un dispositivo de cada clase en la sede, incluidos los dispositivos headless en xPSK.","check":"Cada dispositivo de prueba se ubica en su VLAN prevista."},{"title":"Supervisar la primera hora","body":"Consulte los registros de autenticación de Purple y agrupe los fallos por motivo.","check":"La tasa de éxito es igual o superior a la línea base de la sede."},{"title":"Mantener o revertir","body":"Si la tasa se mantiene por debajo de la línea base al final de la ventana acordada, restaure los servidores ISE en el SSID.","check":"La decisión y el motivo quedan registrados en el historial de migración."},{"title":"Cerrar la sede","body":"Marque la sede como migrada transcurridas 48 horas. Mantenga su entrada de NAD en ISE hasta la fase 5 para que la reversión siga funcionando.","check":"ISE no muestra nuevas autenticaciones desde esta sede."}]}

Fase 5: desmantelar ISE

Inicie la fase 5 únicamente cuando ISE no haya registrado ninguna autenticación WiFi durante un periodo establecido por usted, como 30 días. Exporte los informes de autenticación de ISE exigidos por su directiva de retención para auditorías. Elimine las entradas de NAD y, a continuación, apague los nodos. Deje que las licencias expiren en el momento de la renovación en lugar de cancelarlas antes de tiempo.

Retire la CA interna de ISE al final. Cualquier certificado emitido por ella dejará de encadenarse a una CA activa una vez que ISE haya desaparecido.

¿Cómo se ejecutan ISE y Purple en paralelo durante la migración?

Existen dos patrones y se comportan de manera distinta.

SSID paralelo. Transmita un segundo SSID seguro autenticado por Purple junto con el SSID de ISE. Su MDM traslada grupos de dispositivos al nuevo perfil de SSID por lotes. Ambas redes se ejecutan a la vez, por lo que se trata de una ejecución en paralelo real. El coste es el tiempo de aire ocupado por un SSID adicional durante el tiempo que dure la migración.

Mismo SSID, servidor cambiado. Mantenga un solo SSID y cambie su servidor RADIUS durante la ventana de cambio. Esto es más limpio para el espectro radioeléctrico, pero se trata de un conmutado directo, no de una transición progresiva.

El punto que la mayoría de los equipos pasa por alto: la conmutación por error de RADIUS en la mayoría de los controladores se activa cuando el servidor primario deja de responder, no cuando rechaza un dispositivo. Si coloca Purple en primer lugar e ISE en segundo, un rechazo de Purple no conmuta a ISE. No confíe en el orden de los servidores como red de seguridad. Confíe en la prueba piloto.

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

Un grupo hotelero ejecuta WiFi para empleados en 40 hoteles con Cisco Meraki. Dos nodos de ISE en un centro de datos autentican al personal con PEAP frente al Active Directory local. El grupo desea retirar el centro de datos.

El equipo dividió la migración en dos partes. En primer lugar, distribuyó los certificados EAP-TLS y la confianza en el servidor de Purple a través de su MDM mientras ISE seguía autenticándolo todo. ISE validó los nuevos certificados, por lo que nada cambió para el personal. En segundo lugar, realizó una prueba piloto en un hotel de tamaño mediano y luego migró el resto en cuatro oleadas de fin de semana de nueve o diez hoteles.

El resultado cuantificable fue la propia prueba de salida. El recuento de autenticaciones del SSID del personal en ISE llegó a cero tras la última oleada. Ninguna oleada requirió reversión. Los nodos de ISE se apagaron a finales del mes siguiente.

¿Cómo se revierte una oleada que falla?

La reversión es el paso inverso al paso dos: restaurar los servidores ISE y el secreto compartido en los SSID afectados. Dado que ISE permanece activo y sus entradas NAD siguen en su sitio, el centro vuelve a su estado anterior en la siguiente reconexión. Acuerde con antelación quién toma la decisión y cuánto tiempo se espera antes de tomarla.

{"title":"Avanzar, no avanzar o revertir para una oleada de migración","start":"q1","nodes":[{"id":"q1","question":"¿Mantuvo el piloto o la oleada anterior la línea base de tasa de éxito de ISE?","help":"Compare la tasa de éxito de Purple por SSID con la línea base de ISE para los mismos centros.","options":[{"label":"Sí","to":"q2"},{"label":"No","to":"o3"}]},{"id":"q2","question":"¿Confía cada dispositivo de esta oleada en el certificado de servidor de Purple?","help":"Compruebe el estado de despliegue del MDM para cada grupo de dispositivos en estos centros.","options":[{"label":"Sí","to":"q3"},{"label":"No","to":"o2"}]},{"id":"q3","question":"¿Pueden todos los centros de la oleada alcanzar los servidores RADIUS de Purple?","help":"Realice pruebas a través del firewall de cada centro antes de que se abra la ventana.","options":[{"label":"Sí","to":"q4"},{"label":"No","to":"o2"}]},{"id":"q4","question":"¿Sigue ISE activo, con un responsable de reversión designado de guardia?","options":[{"label":"Sí","to":"o1"},{"label":"No","to":"o2"}]},{"id":"o1","outcome":"Avanzar","detail":"Abra la ventana de cambio y siga los pasos de migración del centro."},{"id":"o2","outcome":"No avanzar: corregir y reprogramar","detail":"Solucione el problema y vuelva a ejecutar esta comprobación antes de la siguiente ventana."},{"id":"o3","outcome":"Revertir y diagnosticar","detail":"Restaure ISE en los SSID afectados, identifique la regla o clase de dispositivo que falla y corríjala primero en el centro piloto.","link":"[Comparar alternativas a ISE](guide:cisco-ise-alternatives)"}]}

Escenario práctico: una cadena minorista de 300 tiendas con HPE Aruba

Un minorista opera 300 tiendas sobre HPE Aruba. ISE autentica los portátiles del personal con EAP-TLS y los escáneres de inventario portátiles con MAB. La tienda piloto superó la prueba, por lo que el equipo avanzó con la primera ola de 30 tiendas.

Los escáneres fallaron en cuatro tiendas de la segunda ola. Esas tiendas tenían un modelo de escáner más nuevo cuyas direcciones MAC nunca habían llegado al inventario de la fase 1. El responsable del plan de reversión restauró el grupo de servidores ISE en las WLAN afectadas dentro de la ventana de cambio, y el escaneo se reanudó.

El equipo extrajo las direcciones del nuevo modelo de la lista de endpoints de ISE y le asignó claves xPSK. Probó un escáner en la tienda piloto y luego volvió a ejecutar la ola. Las 300 tiendas completaron la migración a Purple. Se retiraron todas las reglas MAB y los terminales de pago ahora están en su propia VLAN. Esa segmentación se convirtió en prueba para el alcance de cumplimiento PCI-DSS del minorista.

¿Cómo demostrar que la migración desde ISE ha finalizado?

"Finalizado" es un conjunto de hechos, no una sensación. Ha terminado cuando todo lo siguiente es cierto:

• ISE ha registrado cero autenticaciones WiFi durante el periodo establecido.
• La tasa de éxito de Purple en cada ubicación se encuentra en el nivel de referencia de ISE o por encima de este.
• Cada grupo de identidad llega a su VLAN prevista, comprobado con un dispositivo de prueba por clase.
• Ningún dispositivo mantiene un certificado que se encadene a la CA interna de ISE.
• Los informes de ISE para su periodo de retención se han exportado y almacenado.
• Los nodos de ISE están apagados y la renovación se ha cancelado.

Mantenga un único registro para todo el programa. La lista de verificación a continuación es ese registro.

{"title":"Registro de migración de ISE a RADIUS en la nube","groups":[{"heading":"Antes de la fase 1","items":[{"text":"Cada SSID, NAD y secreto compartido listado"},{"text":"Cada conjunto de políticas asignado a un grupo de identidad y VLAN"},{"text":"Dos semanas de referencia de ISE capturadas por ubicación y SSID","why":"Sin esto, ninguna ola puede aprobarse o rechazarse"},{"text":"Dispositivos PEAP identificados y plan EAP-TLS acordado"},{"text":"Dispositivos MAB listados desde la lista de endpoints de ISE"},{"text":"El alcance cableado, TACACS+ y de postura tiene asignados responsables independientes"}]},{"heading":"Construcción y piloto","items":[{"text":"Proveedor de identidad conectado y grupos asignados a VLANs"},{"text":"CA de certificado de cliente en la que se confía para EAP-TLS"},{"text":"Confianza en el certificado de servidor de Purple enviada a través de MDM","why":"El riesgo que afecta en la noche de la transición"},{"text":"Claves xPSK emitidas para grupos de dispositivos sin interfaz"},{"text":"Los firewalls de la ubicación permiten el tráfico RADIUS hacia Purple"},{"text":"La ubicación piloto mantuvo la referencia durante cinco días laborables"}]},{"heading":"Olas","items":[{"text":"Verificación de paso o no paso registrada para cada ola"},{"text":"Responsable de reversión designado para cada ventana de cambio"},{"text":"Cada ola mantuvo la referencia durante 48 horas"}]},{"heading":"Finalizado","items":[{"text":"Cero autenticaciones WiFi en ISE durante el periodo acordado"},{"text":"Ningún certificado se encadena a la CA interna de ISE"},{"text":"Informes de ISE exportados para la retención de auditoría"},{"text":"Entradas NAD eliminadas y nodos ISE apagados"},{"text":"Renovación de licencia de ISE cancelada"}]}],"download":{"filename":"ise-migration-log.csv"}}

¿Qué modos de fallo aparecen en el terreno?

La mayoría de las fases con errores se deben a una lista reducida de causas.

• Certificado de servidor no confiable. Los dispositivos muestran avisos o rechazan la conexión de forma silenciosa. Soluciónelo en la fase 2 a través de su MDM, nunca pidiendo al personal que acepte un aviso.
• Cambiar dos cosas a la vez. Pasar de PEAP a EAP-TLS en la misma ventana que el cambio de servidor oculta qué cambio ha provocado el fallo.
• Dispositivos sin interfaz gráfica olvidados. Escáneres, impresoras y sensores en MAB fallan primero, como descubrió el minorista. Reconstruya la lista de MAB desde ISE justo antes de cada fase.
• Discrepancias en el secreto compartido. Un secreto mal escrito en un solo controlador rechaza una sede completa. Copie los secretos desde una única fuente, nunca a mano.
• Salida de firewall. Las sedes con salida local o reglas de firewall antiguas bloquean el tráfico RADIUS hacia la nube. Pruebe cada sede antes de su ventana.
• Diferencias de atributos de VLAN. Los perfiles de autorización de ISE pueden devolver un nombre de VLAN, un ID de VLAN o un rol específico del fabricante. Coincida lo que espera cada controlador en la sede piloto.
• Consumidores secundarios silenciosos. Si un firewall obtenía identidades de ISE a través de pxGrid, esa fuente se detiene durante la transición. Si depende de la Change of Authorisation (RFC 5176) para finalizar sesiones, pruébela durante el piloto.
• Confiar en la conmutación por error. Incluir ISE como servidor secundario no detecta los rechazos. Solo lo hace una reversión probada.

Dónde encaja Purple

Purple Access ejecuta tres redes en los puntos de acceso que ya posee: abierta, segura y xPSK. Una migración de ISE se asienta en la red segura. Purple cloud RADIUS se autentica con EAP-TLS frente a Microsoft Entra ID, Okta o Google Workspace. Passpoint, el estándar Hotspot 2.0 para conexiones automáticas y cifradas, extiende la misma identidad en todas las sedes. La identidad establece la VLAN en cada red.

Purple es independiente del hardware. Funciona con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet, sin necesidad de hardware nuevo. Purple opera el RADIUS en la nube más grande del mundo. Ofrece un SLA de tiempo de actividad de RADIUS del 99,9 % en una plataforma que funciona con un tiempo de actividad del 99,999 %.

{"items":[{"value":"99.9%","label":"SLA de tiempo de actividad de RADIUS","note":"SLA contractual de Purple"},{"value":"99.999%","label":"tiempo de actividad de la plataforma","note":"Datos propios de Purple"},{"value":"80,000+","label":"recintos activos","note":"Datos propios de Purple"},{"value":"90","label":"países","note":"Datos propios de Purple"}]}

{"tone":"proof","title":"WiFi para empleados a escala de sucursal","text":"JPMorgan ejecuta WiFi para empleados en Purple en más de 5000 sucursales."}

Purple cuenta con las certificaciones ISO 27001, Cyber Essentials y B Corp, y opera bajo GDPR y CCPA. Estas certificaciones acortan la evaluación de proveedores que realizará su equipo de seguridad. Para obtener una visión de seguridad más amplia, lea la guía de seguridad WiFi para empresas. Si todavía está eligiendo un destino, consulte las alternativas a Cisco ISE para la autenticación WiFi.

Preguntas frecuentes

¿Cuánto tiempo lleva migrar de Cisco ISE a RADIUS en la nube?

La transición en sí suele ser un trabajo de fin de semana; la preparación lleva más tiempo. Para una red de 40 sedes, planifique dos semanas de evaluación, una semana de compilación, un piloto de dos semanas y varias fases durante los fines de semana. Los certificados son la variable principal. Si los dispositivos ya usan EAP-TLS con certificados de su propia CA, el plan se acorta. Si interviene PEAP con Active Directory, añada una fase para trasladar primero esos dispositivos a EAP-TLS.

¿Necesito nuevos puntos de acceso para migrar desde Cisco ISE?

No. RADIUS en la nube funciona con los puntos de acceso y controladores que ya utiliza: Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. El cambio es una modificación de configuración en cada SSID: nuevas direcciones de servidor RADIUS, un nuevo secreto compartido y, donde sea necesario, nuevos atributos VLAN. Su conmutación, VLAN y SSID se mantienen exactamente como están.

¿Podemos conservar los certificados de cliente que ya hemos emitido?

Sí, siempre que los haya emitido su propia CA o MDM. RADIUS en la nube valida los certificados EAP-TLS con la CA emisora, por lo que siguen funcionando una vez que se confía en esa CA. Los certificados de la CA interna de ISE son la excepción. Están vinculados a un sistema que se va a retirar, por lo que deberá volver a emitirlos desde su MDM o CA antes de que comience la fase 5.

¿Qué ocurre con los dispositivos que utilizan MAC Authentication Bypass en ISE?

Se trasladan a la red xPSK. MAB confía en una dirección MAC, que es fácil de suplantar. Una clave por dispositivo o grupo de dispositivos proporciona a los escáneres, impresoras y sensores su propia credencial y los ubica en su propia VLAN. Identifíquelos en la fase 1 mediante la lista de puntos de conexión de ISE. Emita claves en la fase 2 y, a continuación, pruebe un modelo de cada uno en la sede piloto.

¿Afecta a nuestras pruebas de PCI DSS o ISO 27001 el hecho de dejar de utilizar ISE?

Cambia el origen de las pruebas, no su disponibilidad. Exporte los informes de autenticación de ISE correspondientes a su período de retención antes del desmantelamiento. A partir de la transición, los registros de autenticación de Purple y las asignaciones de VLAN aportan pruebas de la segmentación de red y el control de acceso. La propia certificación ISO 27001 y Cyber Essentials de Purple también respalda la evaluación de proveedores que sus auditores esperarán consultar.

¿Cómo se compara el precio de RADIUS en la nube con el de Cisco ISE?

Compare el coste total en lugar de las líneas de licencias. El coste de ISE incluye las licencias, los nodos o máquinas virtuales en los que se ejecuta, los contratos de soporte y el tiempo que los ingenieros dedican a aplicar parches y actualizar. RADIUS en la nube es una suscripción sin servidores que deba administrar. Purple le ofrecerá un presupuesto adaptado a su infraestructura, por lo que conviene tener a mano el número de sedes, SSID y dispositivos. La guía de alternativas a ISE detalla qué otros aspectos comparar.

¿Deberíamos migrar 802.1X por cable al mismo tiempo que WiFi?

No. Traslade primero la red WiFi de WiFi y trate la red cableada de 802.1X como un proyecto independiente con su propia prueba piloto. Los puertos cableados suelen albergar dispositivos MAB, teléfonos de escritorio y reglas de postura que necesitan su propio inventario. Cambiar ambos en una sola ventana duplica la cantidad de elementos que pueden fallar a la vez. También dificulta la decisión de revertir los cambios bajo presión.

¿Es diferente la migración desde Aruba ClearPass?

Las cinco fases son las mismas; lo que difiere es la exportación. ClearPass almacena las políticas como servicios, políticas de aplicación y perfiles, en lugar de conjuntos de políticas de ISE. Asignar estos elementos a grupos de identidad y VLAN es la tarea principal de la fase 1. El riesgo de confianza de certificados y el comportamiento de conmutación por error se aplican exactamente de la misma manera. La guía de migración de ClearPass detalla la exportación de forma exhaustiva.