Implementación de SCEP para WiFi 802.1X y BYOD seguro en educación superior

Bienvenido al boletín técnico de Purple. Soy su anfitrión, y hoy analizaremos en profundidad un tema que surge constantemente en los departamentos de TI de la educación superior: cómo implementar SCEP - es decir, el protocolo de inscripción de certificados simple - para ofrecer WiFi 802.1X y BYOD seguro en el campus. Si actualmente gestiona la red de una universidad o un centro de estudios superiores, probablemente se enfrente a una tensión familiar. Por un lado, tiene a estudiantes, profesores y personal que traen cientos o miles de dispositivos personales. Por el otro, tiene una postura de seguridad que debe cumplir con los requisitos institucionales, normativos y, cada vez más, de los ciberseguros. El WiFi basado en contraseñas y los portales cautivos abiertos ya no son suficientes. Así que hablemos de lo que sí funciona. En primer lugar, analicemos el escenario. El estándar 802.1X es la norma de la IEEE para el control de acceso a redes basado en puertos. Existe desde 2001, pero hoy es más relevante que nunca. La idea principal es que, antes de que cualquier dispositivo acceda a su red, debe demostrar quién es - no solo presentar una contraseña que cualquiera podría compartir, sino presentar una credencial verificable. En un contexto cableado, esa comprobación de credenciales se realiza en el puerto del switch. En WiFi, ocurre en el punto de acceso, bajo la mediación de un servidor RADIUS. Ahora bien, la propia credencial puede adoptar varias formas. Puede utilizar un nombre de usuario y contraseña mediante PEAP - es decir, el protocolo de autenticación extensible protegido. O puede utilizar un certificado digital mediante EAP-TLS - protocolo de autenticación extensible con seguridad de la capa de transporte. EAP-TLS es el estándar de oro. Es mutuo - la red se autentica ante el dispositivo y el dispositivo se autentica ante la red. Esa autenticación mutua es lo que bloquea los puntos de acceso fraudulentos. El portátil de un estudiante simplemente no se conectará a una red suplantada que no tenga el certificado correcto. ¿Dónde entra en juego SCEP? SCEP - Simple Certificate Enrolment Protocol - es el mecanismo mediante el cual los dispositivos solicitan y reciben esos certificados digitales de forma automática. Sin SCEP, tendría que generar y distribuir manualmente los certificados a cada dispositivo. En una universidad con diez mil estudiantes y tres mil empleados, esa operación no es viable. SCEP automatiza todo el proceso. Así es como funciona el flujo. Un dispositivo se conecta a una red de aprovisionamiento - a veces llamada SSID de incorporación. Se pone en contacto con su servidor SCEP, que normalmente está integrado con su entidad de certificación - su CA. El dispositivo envía una solicitud de firma de certificado. El servidor SCEP valida la solicitud, a menudo comprobando las credenciales del usuario con su directorio - Microsoft Entra ID o Google Workspace. Una vez validada, la CA emite un certificado firmado y el dispositivo lo instala. A partir de ese momento, el dispositivo utiliza ese certificado para autenticarse automáticamente en su SSID protegido por 802.1X. Sin portales, sin solicitudes de contraseña y sin incidencias para el equipo de TI.Hablemos de la arquitectura con un poco más de detalle. En un despliegue típico de educación superior, tendrá que pensar en tres segmentos de red. Primero, su red de incorporación: aquí es donde aterrizan los dispositivos no registrados. Tiene acceso a internet pero está aislada de sus recursos internos. Segundo, su SSID protegido por 802.1X: aquí es donde se conectan los dispositivos registrados, con acceso total a los recursos adecuados para su rol. Tercero, su infraestructura de gestión: su servidor RADIUS, su CA, su servidor SCEP y su integración de directorio. El servidor RADIUS es el agente de tráfico. Cuando un dispositivo intenta conectarse a su SSID 802.1X, el punto de acceso envía una solicitud de autenticación a RADIUS. RADIUS valida el certificado frente a la lista de revocación de certificados de la CA, comprueba el estado del usuario en su directorio y concede o deniega el acceso. También puede asignar el dispositivo a una VLAN según el rol: los estudiantes van a un segmento, el profesorado a otro y el personal administrativo a un tercero. Eso es Identity-Based Networking en la práctica. Ahora, una de las preguntas más comunes que recibo es: ¿con qué hardware funciona esto? La buena noticia es que 802.1X es un estándar, por lo que funciona con cualquier punto de acceso que admita WPA2 o WPA3 Enterprise. En la práctica, querrá verificar la implementación de su proveedor específico. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi: todos ellos admiten el estándar. Los pasos de configuración varían según el proveedor, pero el protocolo subyacente es el mismo. Permítame guiarle a través de cómo es una implementación real. Utilizaré un ejemplo compuesto basado en una universidad mediana del Reino Unido: unos quince mil estudiantes, tres campus y una mezcla de infraestructura Aruba y Meraki. El proyecto comenzó con una auditoría de red. La configuración existente era una mezcla de SSIDs abiertos y un Captive Portal para el acceso de los estudiantes. El equipo de TI estaba desbordado de solicitudes de restablecimiento de contraseñas: unas cuarenta a la semana. La aleatorización de direcciones MAC en iOS y Android había roto por completo sus análisis, por lo que no disponían de datos fiables sobre los patrones de uso de la red. La primera fase fue el despliegue de la infraestructura de PKI. Establecieron una CA de dos niveles: una CA raíz fuera de línea y una CA emisora en línea. El servidor SCEP se integró con la CA emisora y se conectó a Microsoft Entra ID para la validación de la identidad. La duración del certificado se fijó en un año, con una renovación automática activada a los treinta días. La segunda fase consistió en configurar el SSID 802.1X. Crearon un SSID dedicado con WPA3-Enterprise, lo apuntaron a sus servidores RADIUS y configuraron reglas de asignación de VLAN. Los estudiantes obtuvieron una VLAN, el personal otra y los dispositivos de IoT una tercera. La tercera fase fue la experiencia de incorporación. Utilizaron una solución de control de acceso a la red para redirigir los dispositivos no registrados a un portal de autoservicio. Los estudiantes se autenticaban con sus credenciales universitarias, el flujo SCEP se ejecutaba en segundo plano y se instalaba el certificado. En iOS, esto requería un perfil de configuración. En Android, el proceso era ligeramente diferente pero igualmente automatizado. ¿El resultado? Los tickets de restablecimiento de contraseña disminuyeron en más de un noventa por ciento en el primer mes. La visibilidad de la red mejoró drásticamente porque las identidades basadas en certificados no rotan como lo hacen las direcciones MAC. Y el equipo de seguridad por fin tuvo un registro de auditoría fiable para cada dispositivo de la red. Ahora hablemos de dónde encaja Purple en este escenario. El producto SecurePass de Purple está diseñado exactamente sobre esta arquitectura. SecurePass emite perfiles de WiFi firmados digitalmente utilizando WPA2 y WPA3-Enterprise con autenticación mutua 802.1X. El proceso de registro tarda menos de treinta segundos. Una vez que un dispositivo tiene un perfil, se conecta automáticamente - sin portales, sin contraseñas, sin fricciones. Lo que hace que SecurePass sea especialmente relevante para la educación superior es la combinación de seguridad y analítica. Debido a que la credencial de autenticación es un certificado estable en lugar de una dirección MAC rotativa, se obtienen datos precisos de visitas recurrentes, tiempos de permanencia y frecuencia de visitas. Esos datos se envían directamente a la plataforma de analítica de Purple, lo que le ofrece una visibilidad real de cómo se utiliza la red de su campus. SecurePass también se integra con Microsoft Entra ID y Google Workspace para despliegues de personal. Esto significa que cuando un miembro del personal deja la universidad, su acceso se revoca automáticamente. Sin procesos manuales, sin cuentas olvidadas, sin brechas de seguridad. Es el flujo de trabajo de altas, cambios y bajas automatizado de extremo a extremo. Para la infraestructura RADIUS, Purple opera servidores RADIUS en la nube - principales y secundarios - de modo que usted no tiene que gestionar esa infraestructura por sí mismo. La lista de hardware compatible incluye Cisco Meraki, Cisco Catalyst, HPE Aruba, Ubiquiti UniFi, Ruckus, Juniper Mist y Fortinet, entre otros. Todos los detalles están en las preguntas frecuentes de SecurePass en el sitio de soporte de Purple. Permítame indicarle los errores de implementación que debe evitar. Estos son los aspectos que suelen pillar desprevenidos a los equipos en los despliegues reales. Primero: la revocación de certificados. Necesita una CRL - Lista de Revocación de Certificados - o un respondedor OCSP que funcione. Si su servidor RADIUS no puede comprobar el estado de revocación, o bien bloquea todas las conexiones o bien las acepta todas. Ninguna de las dos opciones es aceptable. Pruebe su infraestructura de revocación antes de la puesta en marcha. Segundo: la compatibilidad de los dispositivos. La mayoría de los dispositivos modernos iOS, Android, macOS y Windows admiten EAP-TLS de forma nativa. Pero los dispositivos más antiguos, los terminales IoT y algunos sistemas heredados no lo hacen. Necesita un plan para esos dispositivos, ya sea un SSID independiente con una autenticación diferente o un proceso de excepción gestionado. Tercero: vida útil y renovación de los certificados. Si los certificados caducan y el proceso de renovación falla, los usuarios pierden el acceso. Establezca un margen de renovación generoso - treinta días antes de la expiración es un mínimo razonable. Supervise la expiración de los certificados de forma centralizada y envíe alertas antes de que se convierta en un problema. Cuarto: la experiencia de incorporación. El flujo técnico puede ser perfecto, pero si los estudiantes encuentran confuso el proceso de registro, no lo completarán. Invierta en una señalización clara, un portal de autoservicio sencillo y una guía de ayuda breve. El registro en treinta segundos que promete SecurePass es alcanzable, pero solo si la experiencia de usuario es la adecuada. Quinto: resiliencia del servidor RADIUS. Su infraestructura 802.1X es ahora un elemento crítico para el acceso a la red. Si su servidor RADIUS se cae, nadie se conecta. Necesita servidores RADIUS primarios y secundarios, idealmente en diferentes zonas de disponibilidad, con conmutación por error automática. Pasemos ahora a nuestra sesión rápida de preguntas y respuestas. Estas son las preguntas que recibo con más frecuencia. ¿Puede SCEP funcionar con una CA basada en la nube? Sí. NDES de Microsoft - Network Device Enrolment Service - y varios proveedores de CA en la nube de terceros son compatibles con SCEP sobre HTTPS. No necesita infraestructura local. ¿Funciona 802.1X con Passpoint y OpenRoaming? Sí. Passpoint - también conocido como Hotspot 2.0 - utiliza 802.1X como su capa de autenticación. OpenRoaming amplía eso a una federación global de redes de confianza. Un estudiante registrado a través de SecurePass se conectará automáticamente en cualquiera de los más de ochenta mil puntos de acceso de OpenRoaming en todo el mundo. Eso incluye aeropuertos, hoteles y centros de transporte - todo sin necesidad de realizar ninguna acción adicional. ¿Qué pasa con el acceso de invitados? 802.1X y SCEP son para dispositivos gestionados e identidades conocidas. Para los invitados reales, se sigue necesitando un mecanismo de acceso de invitados independiente. Ambos sistemas funcionan en paralelo; no entran en conflicto. ¿Es obligatorio WPA3-Enterprise? No, WPA2-Enterprise con 802.1X todavía se implementa ampliamente y es perfectamente seguro para la mayoría de los casos de uso. WPA3-Enterprise añade un cifrado más sólido. Si su hardware lo admite, actívelo. Si no, WPA2-Enterprise es una base sólida. Para terminar, estas son las cinco ideas clave que me gustaría que se llevara de esta sesión. Uno: 802.1X con autenticación basada en certificados es la arquitectura de seguridad adecuada para BYOD en la educación superior. Las contraseñas y los portales no son adecuados para el entorno de amenazas en el que opera hoy en día. Dos: SCEP es lo que hace que la autenticación basada en certificados sea escalable. Sin un registro automatizado, no se pueden implementar certificados a la escala que requiere una universidad. Tres: la autenticación mutua es la propiedad de seguridad clave. Protege a sus estudiantes de los puntos de acceso no autorizados tanto como protege a su red de los dispositivos no autorizados. Cuatro: la integración de directorios - con Microsoft Entra ID o Google Workspace - es lo que automatiza el flujo de trabajo de altas, cambios y bajas de usuarios. No implemente 802.1X sin ella. Cinco: la experiencia de incorporación determina la adopción. La tecnología puede ser perfecta, pero si el proceso de registro es engorroso, pasará más tiempo resolviendo solicitudes de asistencia que el que conseguirá ahorrar. Si desea profundizar más, el sitio de asistencia de Purple cuenta con documentación detallada sobre SecurePass que cubre la configuración de RADIUS, la compatibilidad de hardware y el flujo de registro. Encontrará los enlaces en las notas del programa. Gracias por escucharnos. Nos vemos en el próximo informe.