WiFi Certificate Authentication: How Digital Certificates Secure Wireless Networks

Autenticación 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 abordar uno de los temas más importantes (y que con más frecuencia se malinterpreta) en el ámbito de la seguridad de las redes empresariales: la autenticación WiFi mediante certificados. Si gestiona un grupo hotelero, una cadena de tiendas, un centro de conferencias o cualquier organización en la que tanto el personal como los clientes se conectan a su infraestructura inalámbrica, este informe es de directa relevancia para su estrategia de seguridad actual. Permítame situarle en el escenario. El enfoque tradicional para proteger la red WiFi corporativa ha sido una clave precompartida (WPA-PSK): una contraseña que todo el mundo conoce, que se escribe en pizarras, se comparte en canales de Slack y que, sinceramente, nunca se cambia porque hacerlo implicaría actualizar cada dispositivo de la empresa. Ese modelo está obsoleto. Siempre lo ha estado. 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 aportará la claridad necesaria para tomar esa decisión. Por lo tanto, ¿qué es exactamente la autenticación WiFi mediante certificados, por qué es importante y cómo se implementa realmente? Vamos a profundizar en ello. 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 de conexión 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 mismo instante en que se pierde un dispositivo o un empleado se marcha de la empresa. La infraestructura 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 (Root CA), el anclaje de confianza definitivo. Por debajo de ella, normalmente se tienen una o más 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 Root CA puede mantenerse completamente fuera de línea y aislada de la red, reduciendo drásticamente la superficie de ataque. Si una CA intermedia se ve comprometida en algún momento, se revoca sin necesidad de alterar la Root CA. 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 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 el estándar 802.1X denomina el 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 firmas, 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 con éxito, 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 de invitados restringido o un grupo de políticas específico basado en los atributos del certificado. Hablemos del ciclo de vida de los certificados, ya que 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 pueden revocarse 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 con los números de serie de los certificados revocados; y OCSP, el Protocolo de Estado de Certificados en Línea, que permite comprobar la revocación en tiempo real. Para implementaciones en grandes empresas, se prefiere encarecidamente OCSP porque los archivos CRL pueden llegar a ser muy grandes e introducir latencia. El registro de certificados —es decir, la instalación inicial de los certificados en los dispositivos— 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, lo habitual sería utilizar los Servicios de Certificados de Active Directory 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 de invitados? Esta es una distinción importante. La autenticación mediante 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 en 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 fluido entre ubicaciones. La plataforma de Purple se sitúa de lleno en ese espacio de WiFi de invitados, proporcionando la capa de captura de identidad, analítica e interacción sobre una infraestructura inalámbrica segura. El principio arquitectónico clave es la segmentación de red: su SSID corporativo autenticado mediante certificados y su SSID de WiFi de invitados están lógicamente separados, con las políticas de firewall adecuadas entre ellos. Esto no es negociable 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 dados los datos que maneja en ambas redes. Recomendaciones de implementación y errores comunes. Permítame ofrecerle una guía práctica de despliegue, así como 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 desplegar la autenticación mediante 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 (Root CA) fuera de línea. La sobrecarga operativa es mínima; el beneficio de seguridad es sustancial. En segundo lugar, asegure 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 conmutación por error. He visto a organizaciones desplegar 802.1X correctamente y luego descubrir durante una interrupción que su conmutación por error de RADIUS no estaba configurada en los puntos de acceso. Tercero, los periodos de validez de los certificados deben alinearse con los ciclos de actualización de su MDM. Si su MDM fuerza las renovaciones 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 de la expiración. Cuarto —y esto suele pillar a la gente desprevenida—, 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 clase 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 previo a la autenticación, o configure su servidor RADIUS para almacenar en caché las respuestas OCSP de manera adecuada. Preguntas y respuestas rápidas. Permítame repasar las preguntas que me hacen con más frecuencia. Pregunta: ¿Podemos utilizar la autenticación por certificado junto con nuestro portal de WiFi para invitados actual? Absolutamente. Son SSID 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; su infraestructura RADIUS gestiona la parte corporativa. Pregunta: ¿Qué ocurre si se pierde o roban un dispositivo? Se revoca el certificado 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 de su intervalo de publicación de CRL, que suele ser de horas. Por este motivo, se prefiere OCSP para entornos de alta seguridad. Pregunta: ¿Es compatible EAP-TLS 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 para WiFi empresarial en la actualidad. Pregunta: ¿Cómo afecta esto a nuestro cumplimiento de PCI DSS? Positivamente. Tanto el Requisito 1 como el Requisito 8 de PCI DSS se benefician de la autenticación basada en certificados. Eliminar las claves precompartidas compartidas elimina 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 por certificado WiFi a través de 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 limpiamente 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 conforme a la normativa, con las capacidades de análisis e interacción que convierten su infraestructura de WiFi en un activo empresarial en lugar de un simple servicio básico. Si está evaluando su enfoque de autenticación actual, el punto de partida adecuado es una auditoría de su configuración de SSID existente y una revisión de la preparación de su infraestructura de certificados. A partir de ahí, un despliegue gradual, empezando por un grupo piloto de dispositivos gestionados, es el camino de menor riesgo hacia el despliegue completo. Gracias por escuchar este Informe Técnico de Purple. Para seguir leyendo, consulte nuestras guías sobre seguridad WiFi empresarial y los métodos de autenticación WiFi más seguros en el sitio web de Purple en purple.ai.