Implementación de SCEP para la autenticación segura de BYOD y WiFi en educación superior

Bienvenido al Informe Técnico de Purple. Soy su anfitrión, y hoy vamos a tratar un tema que surge constantemente en el departamento 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, este informe le interesa directamente. Y si ya está planeando la transición a la autenticación basada en certificados, le proporcionaremos la arquitectura, los errores comunes y la secuencia de implementación para lograrlo. Empecemos con el problema. Las universidades son, por diseño, entornos abiertos. Los estudiantes llegan en septiembre con dos, tres o a veces hasta cinco dispositivos personales. Esperan conectarse de inmediato, de forma segura y sin llamar al servicio de asistencia. La realidad para la mayoría de las instituciones es una cola de soporte que alcanza los dos mil tickets en las primeras cuarenta y ocho horas del inicio del trimestre. Eso no es un problema de personal. Es un problema de arquitectura. La causa principal es casi siempre la misma: la autenticación WiFi basada en contraseñas. Cuando ejecuta WPA2-Enterprise con PEAP y MSCHAPv2, está pidiendo a los estudiantes que configuren manualmente los ajustes de 802.1X en cada dispositivo. Una configuración incorrecta y quedan expuestos 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 la WiFi simultáneamente. Eso es un desastre predecible y evitable. 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. SCEP fue formalizado por el IETF en el RFC 8894 en 2020, aunque se utiliza 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 pasarela SCEP y una contraseña de desafío compartida. El dispositivo genera una Solicitud de Firma de Certificado (CSR), la envía a la pasarela SCEP, que valida la contraseña de desafío y reenvía la solicitud a su Entidad Certificadora (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 por el aire. Esa parte de la autenticación mutua es fundamental. Con PEAP, un estudiante que se conecte a un punto de acceso no autorizado que emita su SSID entregará gustosamente sus credenciales. Con EAP-TLS, el dispositivo comprueba el certificado del servidor RADIUS antes de proceder. Si no coincide con la CA de confianza, la conexión falla de forma silenciosa. Acaba de eliminar por completo la categoría de ataques de gemelo malvado (evil twin). Ahora hablemos de arquitectura. Un despliegue de SCEP en producción para una universidad tiene 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 Entidad de Certificación: ya sea Microsoft Active Directory Certificate Services local o una PKI en la nube. Cuarto, su pasarela SCEP: el punto de conexión HTTP que recibe las solicitudes de certificados. Quinto, su servidor RADIUS para la 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 certificado raíz se distribuye a cada dispositivo a través del MDM, estableciendo la confianza. A continuación, 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 con respecto a la raíz de confianza. El acceso se concede o se deniega en función de la validez del certificado, no de una contraseña. Permítame guiarle a través de la secuencia de implementación. Este es el orden que funciona. Paso uno: limpie 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: despliegue su Entidad de Certificación. Si utiliza Microsoft ADCS, configure una jerarquía de dos niveles: una CA raíz sin conexión y una CA emisora en línea. La CA raíz debe quedar aislada de la red tras la configuración inicial. Paso tres: configure su pasarela SCEP. Este es el punto de conexión HTTP al que el MDM dirigirá 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. 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 dinámicamente 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. Despliéguelos en ese orden exacto. Cada uno depende de que el anterior ya esté implementado. 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 de RADIUS en al menos cinco segundos para dar margen a la latencia de validación de certificados durante los picos de incorporación. Ahora, los errores comunes. He visto cómo estos problemas descarrilan implementaciones una y otra vez. El primero es desplegar 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 tiene ningún certificado con el que autenticarse. La conexión falla y el usuario llama al servicio de soporte.El segundo error común es olvidarse de los dispositivos BYOD. Intune y Jamf gestionan la flota propiedad de la institución. Pero los dispositivos personales de los estudiantes no están registrados 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 de Captive Portal, de modo que los estudiantes completan el registro en menos de dos minutos sin intervención de TI. El tercer error común son los fallos de tiempo de espera (timeout) de RADIUS durante los picos de incorporación. Realice pruebas de carga en su infraestructura 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 marcha, o se pierde o roban un dispositivo, debe revocar el certificado de inmediato. Asegúrese de que su CA publique una lista de revocación de certificados (CRL) y de que su servidor RADIUS la compruebe en cada autenticación. A continuación, presentamos una sección rápida de preguntas y respuestas sobre las dudas más frecuentes. ¿Puede funcionar SCEP sin un MDM? Técnicamente sí, pero en la práctica no. Sin un MDM para enviar la carga de pago de SCEP y el perfil de WiFi, volverá a la configuración manual de los dispositivos. ¿Cuál debería ser la validez de los certificados? Para los dispositivos de los estudiantes, lo habitual es de uno a dos años. Lo suficientemente largo como para superar el curso académico sin problemas de renovación, y lo suficientemente corto como para limitar la exposición si un certificado se ve comprometido. ¿Qué ocurre con los dispositivos IoT que no admiten 802.1X? Utilice MAC Authentication Bypass con un portal de registro de dispositivos de autoservicio. Los estudiantes registran la dirección MAC de su videoconsola o Smart TV, y su sistema NAC la ubica en la VLAN correcta. ¿Funciona esto 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 de todo el mundo. Para terminar, estas son las tres decisiones que definen una implementación exitosa de SCEP. Primero: elija la arquitectura de su CA antes que nada. ADCS de manera local (on-premises) le ofrece un control total. Cloud PKI le aporta simplicidad operativa. Una elección incorrecta aquí le costará meses de trabajo de rediseño. 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 trimestre. Tercero: pruebe la capacidad de su servidor RADIUS bajo carga antes de septiembre. Una interrupción de RADIUS el primer día del trimestre es algo totalmente evitable. La plataforma de Purple es compatible con estos tres aspectos: integración de PKI en la nube (cloud overlay), incorporación de BYOD de autoservicio a través de nuestro Captive Portal e infraestructura RADIUS probada en ochenta mil ubicaciones reales con un noventa y nueve coma nueve veintinueve por ciento de tiempo de actividad. Gracias por participar en el Purple Technical Briefing. Para obtener más información, visite purple.ai.