Implementación de SCEP para BYOD Seguro en Educación Superior y Autenticación de WiFi

Le damos la bienvenida a la sesión técnica de Purple. Soy su anfitrión y hoy abordaremos un tema que surge constantemente en el área de TI de la educación superior: la implementación de SCEP para la autenticación segura de BYOD y WiFi. Si ha estado ejecutando PEAP-MSCHAPv2 en la red de su campus, esta sesión es directamente relevante para usted. Y si ya está planeando una transición a la autenticación basada en certificados, le proporcionaremos la arquitectura, los errores comunes y la secuencia de implementación para lograrlo. Comencemos con el problema. Las universidades son, por diseño, entornos abiertos. Los estudiantes llegan en septiembre con dos, tres o a veces cinco dispositivos personales. Esperan conectarse de inmediato, de forma segura y sin llamar a la mesa de ayuda. La realidad para la mayoría de las instituciones es una fila en la mesa de ayuda que alcanza los dos mil tickets dentro de las cuarenta y ocho horas posteriores al inicio del periodo escolar. Eso no es un problema de personal. Es un problema de arquitectura. La causa principal casi siempre es la misma: la autenticación WiFi basada en contraseñas. Cuando ejecuta WPA2-Enterprise con PEAP y MSCHAPv2, les pide a los estudiantes que configuren manualmente los ajustes de 802.1X en cada dispositivo. Un solo ajuste incorrecto y quedan vulnerables a un ataque de intermediario (man-in-the-middle). Peor aún, cuando la universidad obliga a restablecer las contraseñas cada noventa días, todos los dispositivos del campus pierden el acceso a WiFi de forma simultánea. Ese es un desastre predecible y prevenible. La respuesta es la autenticación basada en certificados mediante EAP-TLS, y el mecanismo que la hace escalable es SCEP: el Protocolo de Inscripción de Certificados Simple (Simple Certificate Enrollment Protocol). SCEP fue formalizado por el IETF en el RFC 8894 en 2020, aunque se ha utilizado desde principios de la década de 2000. Automatiza el proceso de solicitud e instalación de certificados digitales X.509 en los dispositivos, sin requerir ninguna intervención manual de TI por dispositivo. Así es como funciona a grandes rasgos. Su plataforma MDM, ya sea Microsoft Intune o Jamf, envía un payload SCEP a cada dispositivo registrado. Ese payload contiene dos cosas: la URL de la puerta de enlace SCEP y una contraseña de desafío compartida. El dispositivo genera una Solicitud de Firma de Certificado (CSR) y la envía a la puerta de enlace SCEP, la cual valida la contraseña de desafío y reenvía la solicitud a su Autoridad de Certificación (CA). La CA firma el certificado y lo devuelve al dispositivo. A partir de ese momento, el dispositivo se autentica en su red WiFi mediante EAP-TLS: el certificado demuestra la identidad del dispositivo ante el servidor RADIUS, y el certificado del servidor RADIUS demuestra la identidad de la red ante el dispositivo. Autenticación mutua. Sin intercambio de contraseñas de forma inalámbrica. Esa pieza de autenticación mutua es fundamental. Con PEAP, un estudiante que se conecte a un punto de acceso no autorizado que transmita su SSID entregará con gusto sus credenciales. Con EAP-TLS, el dispositivo verifica el certificado del servidor RADIUS antes de proceder. Si no coincide con la CA de confianza, la conexión falla de manera silenciosa. De este modo, acaba de eliminar por completo la categoría de ataques de gemelo malvado (evil twin). Ahora hablemos de arquitectura. Una implementación de SCEP en producción para una universidad consta de seis componentes principales. Primero, su proveedor de identidad: Microsoft Entra ID, Okta o Google Workspace. Segundo, su plataforma MDM: Intune para Windows y Android, Jamf para macOS e iOS. Tercero, su Autoridad de Certificación: ya sea Microsoft Active Directory Certificate Services de forma local (on-premises) o una PKI en la nube. Cuarto, su puerta de enlace SCEP: el punto de conexión (endpoint) HTTP que recibe las solicitudes de certificados. Quinto, su servidor RADIUS para autenticación. Sexto, su capa de acceso: puntos de acceso Cisco Meraki, HPE Aruba, Ruckus o Juniper Mist configurados para 802.1X. La cadena de confianza funciona de la siguiente manera. La CA emite un certificado raíz. Ese raíz se distribuye a cada dispositivo a través del MDM, lo que establece la confianza. Luego, la CA emite certificados de cliente a los dispositivos a través de SCEP. Cuando un dispositivo se conecta, presenta su certificado de cliente al servidor RADIUS, y el servidor RADIUS presenta su certificado de servidor al dispositivo. Ambas partes realizan la verificación contra la raíz de confianza. El acceso se concede o deniega según la validez del certificado, no por una contraseña. Permítame guiarlo a través de la secuencia de implementación. Este es el orden que funciona. Paso uno: depure su almacén de identidades. Asegúrese de que su Active Directory o Entra ID tenga grupos bien definidos para estudiantes, personal y huéspedes. Las políticas de certificados y las asignaciones de VLAN estarán vinculadas a estos grupos. Paso dos: implemente su Autoridad de Certificación. Si utiliza Microsoft ADCS, establezca una jerarquía de dos niveles: una CA raíz sin conexión (offline) y una CA emisora en línea (online). La CA raíz debe quedar aislada de la red (air-gapped) después de la configuración inicial. Paso tres: configure su puerta de enlace SCEP. Este es el punto de conexión HTTP al que su MDM apuntará los dispositivos. Asegúrese de que sea accesible desde el segmento de red donde los dispositivos realizan el registro inicial, que suele ser su SSID de incorporación (onboarding). Paso cuatro: configure su servidor RADIUS. Importe el certificado de la CA emisora como una CA de confianza. Configure EAP-TLS como su método de autenticación. Configure los atributos de retorno de VLAN para que RADIUS pueda asignar de forma dinámica a los estudiantes al segmento de red correcto. Paso cinco: configure sus perfiles de MDM. En Intune, cree primero un perfil de Certificado de Confianza, luego un perfil de Certificado SCEP y, después, un perfil de WiFi que haga referencia al certificado SCEP. Impleméntelos en ese orden exacto. Cada uno depende de que el anterior ya esté configurado. Paso seis: configure sus puntos de acceso. En Cisco Meraki, HPE Aruba, Ruckus o Juniper Mist, configure su SSID seguro para WPA2-Enterprise o WPA3-Enterprise. Establezca el tiempo de espera (timeout) de RADIUS en al menos cinco segundos para admitir la latencia de validación de certificados durante las horas pico de incorporación. Ahora, los errores comunes. He visto cómo estos descarrilan las implementaciones una y otra vez. El primero es implementar los perfiles de MDM en el orden incorrecto. Si el perfil de WiFi llega al dispositivo antes que el perfil de certificado SCEP, el dispositivo no tendrá ningún certificado con el cual autenticarse. La conexión falla y el usuario llama a la mesa de ayuda. El segundo error común es olvidar los dispositivos BYOD. Intune y Jamf administran la flota de propiedad de la institución. Pero los dispositivos personales de los estudiantes no están inscritos en su MDM. Para ellos, necesita un portal de incorporación de autoservicio. El estudiante se autentica mediante Single Sign-On utilizando sus credenciales universitarias, y el portal utiliza SCEP para aprovisionar el certificado. La plataforma de Purple integra este flujo de incorporación directamente en la experiencia del Captive Portal, de modo que los estudiantes completan la inscripción en menos de dos minutos sin ninguna intervención de TI. El tercer error común son las fallas por tiempo de espera (timeout) de RADIUS durante el pico de incorporación. Realice pruebas de carga en su infraestructura de RADIUS antes de septiembre, no durante este mes. Implemente el equilibrio de carga en al menos dos nodos RADIUS. El cuarto error común es la revocación de certificados. Cuando un estudiante se va, o un dispositivo se pierde o se lo roban, es necesario revocar el certificado de inmediato. Asegúrese de que su CA publique una Lista de Revocación de Certificados, y de que su servidor RADIUS la verifique en cada autenticación. Ahora pasemos a una sesión rápida de preguntas y respuestas sobre las dudas más frecuentes. ¿Puede SCEP funcionar sin un MDM? Técnicamente sí, pero en la práctica no. Sin un MDM para enviar el payload de SCEP y el perfil de WiFi, volverá a la configuración manual de los dispositivos. ¿Cuál debería ser la validez de un certificado? Para los dispositivos de los estudiantes, lo habitual es de uno a dos años. Lo suficientemente largo para cubrir el año académico sin complicaciones de renovación, y lo suficientemente corto para limitar la exposición si un certificado se ve comprometido. ¿Qué pasa con los dispositivos IoT que no admiten 802.1X? Utilice el bypass de autenticación MAC (MAC Authentication Bypass) con un portal de registro de dispositivos de autoservicio. Los estudiantes registran la dirección MAC de su consola de videojuegos o smart TV, y su sistema NAC la ubica en la VLAN correcta. ¿Esto funciona con eduroam? Sí. EAP-TLS es totalmente compatible con la federación eduroam. Los certificados emitidos por la CA de su campus pueden autenticar a los estudiantes en eduroam en cualquier institución participante a nivel mundial. Para cerrar, aquí están las tres decisiones que definen un despliegue exitoso de SCEP. Primero: elija su arquitectura de CA antes que cualquier otra cosa. ADCS on-premises le ofrece un control total. Cloud PKI le brinda simplicidad operativa. Una elección incorrecta aquí le costará meses de retrabajo. Segundo: automatice la incorporación de BYOD desde el primer día. No asuma que los estudiantes configurarán sus dispositivos personales de forma manual. No lo harán. Diseñe el portal de autoservicio antes de que comience el ciclo escolar. Tercero: pruebe la capacidad de su RADIUS bajo carga antes de septiembre. Una caída de RADIUS en el primer día del ciclo escolar es algo completamente evitable. La plataforma de Purple admite estas tres opciones: integración de PKI superpuesta en la nube, incorporación de BYOD de autoservicio a través de nuestro Captive Portal e infraestructura RADIUS probada en ochenta mil establecimientos activos con un noventa y nueve punto nueve veintinueve por ciento de tiempo de actividad. Gracias por acompañarnos en el Purple Technical Briefing. Para obtener más orientación, visite purple.ai.