Autenticación de certificados WiFi: cómo protegen los certificados digitales las redes inalámbricas

Autenticación de WiFi mediante certificados: cómo los certificados digitales protegen las redes inalámbricas. Un informe técnico de Purple. Introducción y contexto. Le damos la bienvenida a la serie de informes técnicos de Purple. Soy su anfitrión, y hoy vamos a profundizar en uno de los temas más importantes - y que con más frecuencia se malinterpreta - de la seguridad de redes empresariales: la autenticación de WiFi mediante certificados. Si gestiona un grupo hotelero, una cadena de tiendas de retail, un centro de conferencias o cualquier organización donde tanto el personal como los invitados se conectan a su infraestructura inalámbrica, este informe es directamente relevante para su estado de seguridad actual. Permítame contextualizar la situación. El enfoque tradicional para proteger el WiFi corporativo ha sido una clave precompartida común: una contraseña que todo el mundo conoce, que se escribe en pizarras, se comparte en canales de Slack y, francamente, nunca se cambia porque cambiarla implicaría actualizar cada dispositivo de las instalaciones. Ese modelo está obsoleto. Siempre lo estuvo. La autenticación basada en certificados es la forma en que las redes empresariales serias llevan haciendo esto durante más de una década, y si aún no ha realizado la transición, este informe le dará la claridad necesaria para tomar esa decisión. Así pues, ¿qué es exactamente la autenticación de WiFi mediante certificados, por qué es importante y cómo se despliega realmente? Vamos a analizarlo. Análisis técnico detallado. Comencemos con los aspectos fundamentales. Un certificado digital, en el contexto de la autenticación WiFi, es una credencial digital X.509, esencialmente un documento firmado criptográficamente que demuestra la identidad de un dispositivo o de un usuario. Piense en él como un pasaporte para el punto final de su red. A diferencia de una contraseña, que es un secreto compartido que puede ser robado, adivinado o filtrado, un certificado está vinculado matemáticamente a una clave privada específica que nunca sale del dispositivo. No se puede hacer phishing a un certificado. No se puede descifrar por fuerza bruta. Y lo que es fundamental, se puede revocar en el momento en que se pierde un dispositivo o un empleado se marcha. La estructura subyacente que hace que esto funcione se denomina PKI - Infraestructura de Clave Pública. La PKI es una jerarquía de confianza. En la cúspide se encuentra una Autoridad de Certificación Raíz, el punto de anclaje de confianza definitivo. Por debajo de ella, normalmente se tienen una o varias Autoridades de Certificación Intermedias, que son las que realmente emiten los certificados de entidad final a los dispositivos y usuarios. Esta jerarquía es importante porque significa que su CA Raíz puede mantenerse completamente desconectada y aislada de la red, reduciendo drásticamente su superficie de ataque. Si una CA Intermedia se ve comprometida, se revoca sin necesidad de alterar la Raíz. Ahora bien, ¿cómo funciona esto realmente en una red WiFi? La pila de protocolos es IEEE 802.1X - el estándar de control de acceso a redes basado en puertos - combinado con EAP-TLS, que significa Protocolo de Autenticación Extensible con Seguridad en la Capa de Transporte. Este es el estándar de oro para la seguridad de WiFi empresarial. Este es el flujo de autenticación. Cuando un dispositivo cliente intenta conectarse a su SSID corporativo, el punto de acceso - que actúa como lo que 802.1X denomina Autenticador - no concede acceso a la red de inmediato. En su lugar, actúa como intermediario en una conversación EAP entre el cliente y su servidor RADIUS, que es el Servidor de Autenticación en la terminología de 802.1X. El cliente presenta su certificado. El servidor RADIUS valida dicho certificado frente a su PKI - comprobando la cadena de firma, el periodo de validez y el estado de revocación. Simultáneamente - y esta es la parte que hace que EAP-TLS sea genuinamente superior a la mayoría de los demás métodos EAP - el cliente también valida el certificado del servidor. Esta autenticación mutua evita los ataques de puntos de acceso no autorizados, en los que un atacante configura una red WiFi falsa para recopilar credenciales. Con EAP-TLS, ambas partes demuestran su identidad antes de que se transmita un solo byte de datos. Una vez que la autenticación mutua se realiza correctamente, el servidor RADIUS envía un mensaje Access-Accept al punto de acceso, y el cliente se ubica en el segmento de red adecuado - ya sea la VLAN corporativa, un segmento restringido para invitados o un grupo de políticas específico basado en los atributos del certificado. Hablemos del ciclo de vida de los certificados, porque aquí es donde muchas implementaciones se topan con fricciones operativas. Los certificados se emiten, tienen un periodo de validez - normalmente de uno a tres años para los certificados de dispositivo - y deben renovarse antes de que caduquen. También se pueden revocar antes de su vencimiento si un dispositivo es robado o se retira del servicio. La revocación se gestiona a través de dos mecanismos: CRL, o Listas de Revocación de Certificados, que son listas publicadas periódicamente de números de serie de certificados revocados; y OCSP, el Protocolo de Estado de Certificados en Línea, que permite la comprobación de revocaciones en tiempo real. Para implementaciones de grandes empresas, se prefiere encarecidamente OCSP porque los archivos CRL pueden llegar a ser muy grandes e introducir latencia. El registro de certificados - la obtención de certificados en los dispositivos en primer lugar - se gestiona a través de protocolos como SCEP, el Protocolo Simple de Registro de Certificados, o EST, Registro sobre Transporte Seguro, que es el sustituto más moderno. En un entorno de Microsoft, normalmente utilizaría Active Directory Certificate Services con directivas de grupo para registrar automáticamente los certificados en los equipos unidos al dominio. Para escenarios de gestión de dispositivos móviles, su plataforma MDM - ya sea Intune, Jamf u otra solución - se encarga de la distribución de certificados como parte del perfil de configuración del dispositivo. Ahora bien, ¿dónde se cruza esto con el WiFi para invitados? Esta es una distinción importante. La autenticación por certificados es principalmente un control de red corporativa. Sus invitados no van a tener certificados emitidos por la PKI de su empresa. Para el acceso de invitados, se opera con un modelo de autenticación diferente: normalmente un Captive Portal con inicio de sesión social, registro por correo electrónico o, cada vez más, Passpoint y OpenRoaming, que utilizan certificados a nivel de infraestructura para permitir un roaming seguro y sin interrupciones entre ubicaciones. La plataforma de Purple se sitúa de lleno en ese espacio de WiFi para invitados, proporcionando la capa de captura de identidad, análisis y fidelización sobre una infraestructura inalámbrica segura. El principio arquitectónico clave es la segmentación de red: el SSID corporativo autenticado por certificado y el SSID de WiFi para invitados están lógicamente separados, con políticas de firewall adecuadas entre ellos. Esto es innegociable para el cumplimiento de PCI-DSS si procesa pagos con tarjeta en cualquier lugar cercano a su infraestructura inalámbrica, y se recomienda encarecidamente para el cumplimiento de GDPR debido a los datos que gestiona en ambas redes. Recomendaciones de implementación y errores comunes. Permítame ofrecerle una guía práctica de despliegue y señalar los errores en los que veo caer a las organizaciones una y otra vez. En primer lugar, planifique su PKI antes de tocar un solo punto de acceso. El error más común es implementar la autenticación por certificados con una estructura de CA plana de un solo nivel. Implemente siempre al menos una jerarquía de dos niveles con una CA raíz fuera de línea. La sobrecarga operativa es mínima; el beneficio de seguridad es sustancial. En segundo lugar, consolide su infraestructura RADIUS. Un único servidor RADIUS es un punto único de fallo. Despliegue como mínimo dos servidores RADIUS en una configuración activo-pasivo o activo-activo, y pruebe su tolerancia a fallos. He visto a organizaciones implementar 802.1X correctamente para luego descubrir durante una caída de servicio que la tolerancia a fallos de RADIUS no estaba configurada en los puntos de acceso. En tercer lugar, los periodos de validez de los certificados deben alinearse con los ciclos de renovación de su MDM. Si su MDM fuerza la renovación de certificados en un ciclo de 90 días pero sus certificados tienen una validez de 12 meses, tendrá un desfase. Automatice la renovación y configure alertas a los 60 días antes del vencimiento. En cuarto lugar (y esto suele pillar desprevenida a la gente), iOS y Android gestionan la confianza de los certificados de forma diferente. iOS requiere que el usuario confíe explícitamente en el certificado de la CA raíz en la primera conexión, a menos que se envíe a través de MDM. El comportamiento de Android varía según la versión y el fabricante. Pruebe la experiencia del cliente en cada tipo de dispositivo antes del lanzamiento. El quinto error común es la disponibilidad de OCSP. Si su respondedor OCSP es interno y un cliente no puede acceder a él durante la autenticación (quizás porque se está conectando por primera vez y aún no tiene acceso a la red), la autenticación puede fallar o recurrir a la CRL. Diseñe su infraestructura OCSP para que sea accesible desde el estado de preautenticación, o configure su servidor RADIUS para almacenar en caché las respuestas OCSP de forma adecuada. Preguntas y respuestas rápidas. Permítame repasar las preguntas que me hacen con más frecuencia. Pregunta: ¿Podemos usar la autenticación por certificado junto con nuestro portal de WiFi para invitados existente? Absolutamente. Son SSIDs independientes con mecanismos de autenticación distintos. Sus usuarios corporativos se autentican a través de EAP-TLS; sus invitados pasan por el flujo del Captive Portal. Purple gestiona la parte de invitados y su infraestructura RADIUS gestiona la parte corporativa. Pregunta: ¿Qué ocurre si un dispositivo se pierde o es robado? El certificado se revoca inmediatamente a través de su consola de gestión de CA. La próxima vez que ese dispositivo intente conectarse, el servidor RADIUS comprobará el estado de revocación y rechazará la conexión. Con OCSP, esto puede ser casi en tiempo real. Con CRL, depende del intervalo de publicación de su CRL - normalmente horas. Por eso se prefiere OCSP para entornos de alta seguridad. Pregunta: ¿Es EAP-TLS compatible con WPA3? Sí. WPA3-Enterprise exige el uso del modo de seguridad de 192 bits para los despliegues más sensibles, y EAP-TLS es totalmente compatible. De hecho, WPA3-Enterprise con EAP-TLS es la configuración de mayor seguridad disponible actualmente para WiFi empresarial. Pregunta: ¿Cómo afecta esto a nuestro estado de cumplimiento de PCI-DSS? De forma positiva. Los requisitos 1 y 8 de PCI-DSS se benefician de la autenticación basada en certificados. Eliminar las claves compartidas evita un hallazgo de auditoría significativo, y la identidad por dispositivo significa que dispone de un registro de auditoría claro de qué dispositivo accedió a qué segmento de red y cuándo. Resumen y próximos pasos. En resumen: la autenticación de WiFi por certificado mediante 802.1X y EAP-TLS es el enfoque correcto para cualquier organización que se tome en serio la seguridad de su red. Elimina los secretos compartidos, proporciona autenticación mutua, permite un control de acceso granular y se integra perfectamente con su infraestructura de identidad existente. La ruta de despliegue es bien conocida: diseñe su jerarquía de PKI, despliegue una infraestructura RADIUS redundante, intégrela con su MDM para la distribución de certificados, configure sus puntos de acceso para 802.1X y realice pruebas exhaustivas en todo su parque de dispositivos. Para su red de invitados, esa es una conversación aparte - y es ahí donde las plataformas como Purple aportan un valor real, ofreciéndole una incorporación de invitados segura y compatible con las capacidades de análisis y fidelización que convierten su infraestructura de WiFi en un activo comercial en lugar de un simple servicio básico. Si está evaluando su estado de autenticación actual, el punto de partida adecuado es una auditoría de la configuración de su SSID existente y una revisión de la preparación de su infraestructura de certificados. A partir de ahí, un despliegue por fases - empezando con un grupo piloto de dispositivos gestionados - es la vía de menor riesgo hacia un despliegue completo. Gracias por escuchar esta sesión informativa técnica de Purple. Para obtener más información, consulte nuestras guías sobre seguridad de WiFi empresarial y los métodos de autenticación de WiFi más seguros en el sitio web de Purple en purple.ai.