Gestión de certificados digitales para la autenticación WiFi EAP-TLS

Hable en inglés británico con un tono seguro, autoritario y conversacional, como un consultor sénior informando a un cliente. Ritmo pausado, dicción clara, cálido pero directo. Pausas naturales ocasionales para dar énfasis: Bienvenido a la serie de informes técnicos de Purple. Hoy hablaremos sobre la gestión de certificados EAP-TLS, específicamente, cómo ejecutar un programa de autenticación WiFi basado en certificados a escala sin que se convierta en una carga operativa a tiempo completo. [medium pause] Si es responsable de la red WiFi corporativa o del personal en múltiples ubicaciones, ya sea un grupo hotelero, un patrimonio comercial, un campus universitario o un patrimonio del sector público, este informe es para usted. Vamos a cubrir todo el ciclo de vida de los certificados: desde la configuración de su jerarquía de CA, pasando por el despliegue automatizado a través de SCEP y MDM, hasta la renovación y la revocación. Y hablaremos de dónde suelen salir mal las cosas, porque a veces salen mal, y de cómo evitar las trampas más comunes. [medium pause] Comencemos con los fundamentos. EAP-TLS, que es el Protocolo de Autenticación Extensible con Seguridad de la Capa de Transporte, es el estándar de oro para la autenticación WiFi 802.1X. A diferencia de PEAP, que depende de un nombre de usuario y contraseña, EAP-TLS utiliza autenticación mutua basada en certificados. El dispositivo demuestra su identidad con un certificado de cliente. El servidor RADIUS demuestra su identidad con un certificado de servidor. Ambas partes verifican a la otra. No hay contraseña que pescar con phishing. No hay credenciales que robar. Es por eso que PCI-DSS 4.0 y la guía de confianza cero del NCSC apuntan hacia la autenticación basada en certificados para las redes del personal. [medium pause] Ahora, la arquitectura. Necesita tres cosas para que EAP-TLS funcione. En primer lugar, una infraestructura de clave pública: su jerarquía de CA. En segundo lugar, un mecanismo para llevar los certificados a los dispositivos: es decir, SCEP o su plataforma MDM. En tercer lugar, un servidor RADIUS que confíe en su CA y pueda validar los certificados de cliente en tiempo real. [medium pause] La jerarquía de CA es donde la mayoría de las organizaciones se meten en problemas desde el principio. El patrón correcto es un modelo de tres niveles. Tiene una CA raíz en la parte superior; esta debe estar sin conexión, aislada y solo ponerse en línea para firmar el certificado de su CA intermedia. La CA intermedia, a veces llamada CA emisora, es la que realmente firma los certificados del día a día. Está en línea, pero su clave privada está bien protegida. Por debajo de eso, se emiten dos tipos de certificados: certificados de servidor para su infraestructura RADIUS y certificados de cliente para sus dispositivos y usuarios. [medium pause] ¿Por qué es importante esto? Porque si su CA raíz se ve comprometida, tendrá que reconstruir toda su PKI desde cero y volver a registrar cada dispositivo. Mantenerla fuera de línea elimina ese riesgo. La CA intermedia se puede reemplazar sin tocar la raíz. Ese es el argumento de resiliencia operativa para el modelo de tres niveles. [medium pause] Hablemos sobre los periodos de validez de los certificados. Se ha producido un cambio muy significativo en el sector. Apple, Google y Mozilla han pasado a exigir duraciones máximas de certificados más cortas. Para los certificados de servidor TLS, el máximo actual es de 398 días. Para los certificados de cliente en redes WiFi corporativas, dispone de más flexibilidad (lo habitual es de uno a dos años), pero la tendencia es hacia duraciones más cortas y renovación automatizada en lugar de certificados de larga duración gestionados manualmente. El motivo es sencillo: una duración menor limita el tiempo de exposición si un certificado se ve comprometido. [medium pause] Esto nos lleva a la automatización. La gestión manual de certificados no es escalable. Si tiene 500 dispositivos, casi puede gestionar las renovaciones a mano. Si tiene 5000 dispositivos distribuidos en 50 centros, es imposible. Necesita SCEP (Simple Certificate Enrolment Protocol) o su sucesor moderno, EST. SCEP se integra directamente con plataformas MDM como Microsoft Intune, Jamf Pro y VMware Workspace ONE. El MDM envía un perfil de configuración SCEP al dispositivo. El dispositivo genera un par de claves, envía una solicitud de firma de certificado a su servidor SCEP y recibe de vuelta un certificado firmado, todo ello sin ninguna interacción del usuario. [medium pause] Para los dispositivos Windows en un entorno de Active Directory, existe una alternativa: la autoinscripción basada en Directivas de grupo a través de Active Directory Certificate Services. El dispositivo se autentica en el dominio, la CA emite un certificado de forma automática y este se renueva antes de que expire sin necesidad de intervención manual. Este es el camino más directo para entornos con una gran presencia de Windows. [medium pause] Ahora, hablemos de la revocación. Este es el elemento en el que las organizaciones suelen invertir menos recursos, y es el que más importa cuando algo sale mal. Si un dispositivo se pierde o es robado, o si un empleado se marcha, es necesario revocar su certificado de inmediato. Existen dos mecanismos: CRL (Certificate Revocation Lists) y OCSP (Online Certificate Status Protocol). [medium pause] CRL es el mecanismo más antiguo. Su CA publica una lista de números de serie de certificados revocados en una URL conocida. El servidor RADIUS descarga esta lista periódicamente y la contrasta. El problema de la CRL es la latencia: si su CRL tiene un periodo de validez de 24 horas, un certificado revocado todavía se puede autenticar hasta 24 horas después de su revocación. [medium pause] OCSP es la alternativa en tiempo real. El servidor RADIUS envía una consulta al respondedor OCSP para cada intento de autenticación y obtiene una respuesta en directo sobre si el estado es correcto o está revocado. El inconveniente es que su respondedor OCSP se convierte en una dependencia crítica: si no está disponible, debe decidir si permite el acceso de forma predeterminada o si lo deniega. Para entornos de alta seguridad, denegar el acceso es la respuesta correcta. Para entornos operativos donde prima la disponibilidad, puede configurar un breve periodo de gracia de OCSP. [medium pause] Permítame presentarle dos escenarios concretos para ilustrar esto de forma práctica. [medium pause] Primero: un grupo hotelero de 150 propiedades. Utilizaban PEAP con una contraseña compartida para el WiFi del personal. La rotación de contraseñas era trimestral, lo que significaba un intervalo de dos semanas cada trimestre en el que el personal se quedaba sin acceso o utilizaba la contraseña antigua. Pasaron a EAP-TLS utilizando Microsoft Intune para el despliegue de certificados. Los perfiles SCEP se enviaron a todos los dispositivos Windows e iOS. Se utilizó Active Directory Certificate Services como CA. El resultado: cero eventos de rotación de contraseñas, renovación de certificados gestionada automáticamente 30 días antes de la expiración y, cuando un miembro del personal se marchaba, su certificado se revocaba en el MDM a los pocos minutos de desactivar su cuenta en Microsoft Entra ID. El equipo de TI calculó que ahorraron aproximadamente 40 horas por trimestre en restablecimientos de contraseñas y tickets de soporte técnico. [medium pause] Segundo: una cadena de tiendas multisede con 3.000 dispositivos de personal repartidos en 200 tiendas. El reto en este caso era la diversidad de dispositivos: una mezcla de portátiles Windows, terminales de mano Android y dispositivos iOS. Utilizaron Jamf Pro para los dispositivos Apple y Microsoft Intune para Windows y Android, ambos apuntando al mismo servidor SCEP respaldado por una CA intermedia de Microsoft ADCS. La infraestructura de WiFi era Cisco Meraki, con autenticación RADIUS gestionada por un servicio RADIUS alojado en la nube e integrado con Purple. La decisión clave de diseño fue emitir certificados con una validez de 12 meses y configurar la renovación automática a los 60 días antes de la expiración. Esto proporcionó un margen de renovación cómodo sin generar costes operativos adicionales. [medium pause] Ahora, los errores comunes. Hay cuatro que veo de forma constante. [medium pause] Primero: no probar la revocación. Las organizaciones configuran su PKI, despliegan los certificados y nunca llegan a probar si la revocación funciona de extremo a extremo. Pruébelo. Revoque un certificado de prueba, confirme que el servidor RADIUS detecta la revocación dentro del plazo previsto y confirme que se deniega el acceso al dispositivo. [medium pause] Segundo: acantilados de expiración. Si emite todos sus certificados al mismo tiempo con el mismo periodo de validez, todos expirarán a la vez. Escale la emisión o, como mínimo, escalone los activadores de renovación. Una tasa de fallo de renovación del 10 % en 5.000 dispositivos de forma simultánea representa una incidencia grave. [medium pause] Tercero: no distribuir el certificado de la CA raíz a todos los dispositivos antes de desplegar EAP-TLS. Si el dispositivo no confía en su CA raíz, rechazará el certificado del servidor RADIUS y la autenticación fallará. Esto parece obvio, pero pilla desprevenidas a las organizaciones cuando tienen dispositivos BYOD o portátiles de contratistas que no están registrados en el MDM. [medium pause] Cuarto: disponibilidad del respondedor OCSP. Si su respondedor OCSP se cae y su servidor RADIUS está configurado para denegar el acceso en caso de errores de OCSP, toda su red WiFi dejará de funcionar. Introduzca redundancia en su infraestructura OCSP o configure un breve periodo de gracia con la monitorización adecuada. [medium pause] Muy bien, preguntas rápidas. [medium pause] ¿Puedo utilizar una CA pública para los certificados de cliente EAP-TLS? Técnicamente sí, pero en la práctica no. Las CA públicas no emitirán certificados de cliente para dispositivos arbitrarios. Necesita su propia CA para los certificados de cliente. Para el certificado del servidor RADIUS, una CA pública es adecuada y simplifica la distribución de la confianza. [medium pause] ¿Qué ocurre con el BYOD? El BYOD es el caso más difícil. No se pueden insertar certificados en dispositivos no gestionados a través de MDM. Las opciones incluyen un portal de control de acceso a la red que emita certificados de corta duración tras la autenticación del usuario, o simplemente mantener el BYOD en un SSID independiente con un método de autenticación diferente. [medium pause] ¿Cómo interactúa esto con WPA3? WPA3-Enterprise exige el modo de seguridad de 192 bits para entornos sensibles, lo que requiere conjuntos de cifrado específicos. EAP-TLS es totalmente compatible con WPA3-Enterprise y es, de hecho, el método de autenticación recomendado. [medium pause] En resumen: la gestión de certificados EAP-TLS no es sencilla, pero es manejable si se acierta con la arquitectura desde el principio. Jerarquía de CA de tres niveles. Registro automatizado mediante SCEP o MDM. Ciclos de vida de certificados cortos con renovación automatizada. Revocación en tiempo real a través de OCSP. Pruébelo todo, especialmente la revocación. E integre el ciclo de vida de sus certificados con su proveedor de identidad - Microsoft Entra ID, Okta o Google Workspace - para que la revocación de certificados se active automáticamente cuando se desactive una cuenta. [medium pause] Si utiliza servidores RADIUS vinculados a Purple, los puntos de integración son la URL de su servidor SCEP, el certificado de su servidor RADIUS y su punto de conexión CRL u OCSP. La arquitectura agnóstica de hardware de Purple significa que esto funciona en Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist y el resto de la lista de hardware habitual; no está limitado a las herramientas de PKI de un único proveedor. [medium pause] Siguientes pasos: realice una auditoría de su inventario actual de certificados. Si no sabe cuántos certificados tiene, cuándo caducan y quién los emitió, eso es lo primero que debe solucionar. A partir de ahí, el camino hacia la automatización completa está bien definido. Gracias por su atención.