¿Qué es PKI? Cómo la infraestructura de clave pública impulsa la seguridad WiFi
Esta guía de referencia técnica autorizada explica la infraestructura de clave pública (PKI) y su papel fundamental en la protección de redes WiFi empresariales en entornos de hostelería, retail y sector público. Diseñada para directores de TI, arquitectos de redes y CTO, ofrece orientación práctica sobre la autenticación basada en certificados, la implementación de IEEE 802.1X con EAP-TLS y cómo la plataforma de Purple aprovecha estos estándares para una conectividad escalable y conforme a las normativas. Los lectores obtendrán una hoja de ruta de implementación concreta, casos de estudio reales y una comprensión clara de cómo la PKI elimina las vulnerabilidades del WiFi con secreto compartido.
Escuchar esta guía
Ver transcripción del podcast
Resumen Ejecutivo
Para los líderes de TI empresariales que gestionan despliegues a gran escala en entornos de hostelería, retail o espacios públicos, proteger el acceso inalámbrico es un requisito fundamental, no una actualización opcional. Las claves precompartidas (PSK) tradicionales son inadecuadas para los entornos corporativos: no ofrecen responsabilidad individual, no se pueden auditar y generan una carga operativa significativa cuando se rotan. La Infraestructura de Clave Pública (PKI) proporciona la base criptográfica necesaria para una seguridad de red sólida y escalable. Esta guía detalla qué es la PKI, cómo impulsa la seguridad WiFi empresarial mediante la autenticación basada en certificados y los pasos concretos necesarios para desplegar IEEE 802.1X con EAP-TLS. Al realizar la transición a una arquitectura respaldada por PKI, las organizaciones pueden eliminar el robo de credenciales, automatizar la incorporación de dispositivos y garantizar un acceso fluido y seguro tanto para los dispositivos corporativos como para los invitados, al tiempo que cumplen con los requisitos de PCI DSS, GDPR y ISO 27001.
Análisis Técnico Detallado: Comprensión de PKI en WiFi Empresarial
La Infraestructura de Clave Pública (PKI) es el marco de hardware, software, políticas y procedimientos necesarios para crear, gestionar, distribuir, utilizar, almacenar y revocar certificados digitales, así como para gestionar el cifrado de clave pública. En el contexto del WiFi empresarial, la PKI es el motor que impulsa la verificación de identidad y el cifrado, sustituyendo la contraseña compartida, intrínsecamente insegura, por una identidad criptográfica única para cada dispositivo o usuario.
Los Componentes Clave de la PKI
En su esencia, la PKI se basa en la criptografía asimétrica, donde se utilizan dos claves relacionadas matemáticamente: una clave pública (compartida abiertamente) y una clave privada (mantenida en secreto). Los datos cifrados con la clave pública solo pueden descifrarse con la clave privada correspondiente, y viceversa. Los componentes principales de un despliegue de PKI son los siguientes.
| Componente | Función | Contexto de WiFi Empresarial |
|---|---|---|
| Autoridad de Certificación (CA) | Emite y firma certificados digitales | La raíz de confianza para su red; todos los dispositivos deben confiar en la CA |
| Certificado Digital (X.509) | Vincula una clave pública a una identidad | Instalado en cada dispositivo corporativo; se presenta durante la autenticación 802.1X |
| Servidor RADIUS | Valida certificados y concede acceso a la red | El motor de decisión que acepta o rechaza las solicitudes de conexión |
| Autoridad de Registro (RA) | Verifica la identidad antes de la emisión del certificado | A menudo gestionado por MDM/UEM en despliegues automatizados |
| CRL / OCSP | Comprueba si un certificado ha sido revocado | Crítico para bloquear dispositivos comprometidos o robados en tiempo real |
Cómo Impulsa la PKI a 802.1X y EAP-TLS
La seguridad WiFi empresarial se basa en el estándar IEEE 802.1X para el control de acceso a la red basado en puertos. Cuando se combina con el Protocolo de Autenticación Extensible (EAP), específicamente EAP-TLS (Transport Layer Security), la PKI ofrece el nivel más alto de seguridad inalámbrica: la autenticación mutua.
En un despliegue EAP-TLS, el dispositivo cliente presenta su certificado digital a la red para demostrar su identidad, y el servidor RADIUS presenta su certificado al cliente, demostrando que la red es legítima y no un punto de acceso malicioso "evil twin". Esta confianza mutua se establece porque ambas partes confían en la CA Raíz que emitió los certificados. Una vez autenticada, la sesión se cifra utilizando la suite de cifrado TLS negociada, lo que evita la interceptación de datos y los ataques de intermediario (man-in-the-middle).
El flujo EAP-TLS opera a través de cuatro entidades lógicas: el Dispositivo Cliente (suplicante), el Punto de Acceso (autenticador), el Servidor RADIUS (servidor de autenticación) y la Autoridad de Certificación. El punto de acceso actúa como un relé transparente: no toma la decisión de autenticación por sí mismo. Esa decisión recae por completo en el servidor RADIUS, que valida la cadena de certificados hasta la CA Raíz de confianza.
Guía de Implementación: Despliegue de WiFi Basado en Certificados
La transición a una arquitectura WiFi respaldada por PKI requiere una planificación cuidadosa a lo largo de cuatro fases.
Fase 1: Arquitectura y Selección de la CA
Decida si va a crear una PKI interna (por ejemplo, Microsoft Active Directory Certificate Services) o a utilizar un proveedor de PKI gestionado en la nube. Para despliegues modernos a escala, la PKI en la nube reduce significativamente la carga administrativa y proporciona alta disponibilidad integrada. Asegúrese de que la CA elegida se integre perfectamente con su solución de gestión de dispositivos móviles (MDM) o de gestión unificada de endpoints (UEM). Para entornos que utilizan Guest WiFi , asegúrese de que la infraestructura RADIUS esté diseñada para gestionar tanto el tráfico corporativo 802.1X como la autenticación del Captive Portal de invitados en SSID independientes.
Fase 2: Configuración del Servidor RADIUS
Despliegue un servidor RADIUS robusto; las opciones incluyen FreeRADIUS, Cisco ISE, Aruba ClearPass o un RADIUS-as-a-Service nativo de la nube. Configure el servidor RADIUS con su propio certificado de servidor emitido por su CA. Esto es crítico: sin un certificado de servidor válido, el cliente no puede realizar la autenticación mutua y será vulnerable a ataques de tipo "evil twin". Para despliegues en grandes recintos, considere configuraciones de proxy RADIUS para admitir el roaming entre sitios. Los recintos que desplieguen plataformas de WiFi Analytics deben asegurarse de que los datos de contabilidad de RADIUS se alimenten en el flujo de analítica para una atribución precisa de las sesiones.
Fase 3: Aprovisionamiento Automatizado de Certificados
La instalación manual de certificados no es escalable y es propensa a errores. Aproveche los protocherramientas como SCEP (Simple Certificate Enrollment Protocol) o EST (Enrollment over Secure Transport) a través de su MDM para enviar certificados de forma silenciosa a los dispositivos corporativos. Para escenarios BYOD, implemente un portal de incorporación que proporcione de forma segura un certificado al dispositivo del usuario tras la verificación de identidad inicial. Para dispositivos IoT sin interfaz de usuario (como equipos médicos, terminales de punto de venta o señalización digital), los certificados deben aprovisionarse durante la fase de preparación del dispositivo antes de su despliegue.
Fase 4: Aplicación de políticas de red
Configure sus controladores inalámbricos y puntos de acceso para aplicar 802.1X en el SSID corporativo. Asocie los atributos del certificado (como el Subject Alternative Name o el campo OU) a VLAN específicas o políticas de firewall utilizando atributos RADIUS, garantizando el acceso a la red con el menor privilegio posible. Para establecimientos que utilicen hardware de proveedores específicos, consulte las guías del fabricante, como Su guía para un punto de acceso inalámbrico Ruckus , para conocer los pasos de configuración específicos de la plataforma.
Buenas prácticas para la PKI empresarial
Proteja la CA raíz. Si utiliza una PKI interna, la CA raíz debe mantenerse fuera de línea y protegida físicamente. Solo las CA intermedias deben estar en línea y emitir certificados activamente. Una CA raíz comprometida invalida toda su PKI.
Implemente una comprobación de revocación sólida. Asegúrese de que sus servidores RADIUS comprueben activamente las CRL o utilicen OCSP para verificar el estado del certificado en cada intento de autenticación. El certificado de un dispositivo comprometido debe revocarse inmediatamente para bloquear el acceso. Configurar RADIUS para almacenar en caché las respuestas CRL durante demasiado tiempo crea una ventana de exposición.
Automatice las renovaciones antes del vencimiento. Los certificados caducan. Implemente procesos de renovación automatizados que se activen al 60-70 % del periodo de validez del certificado para evitar interrupciones de red causadas por certificados caducados. El vencimiento de los certificados es una de las causas más comunes de interrupciones imprevistas de WiFi en entornos empresariales.
Adopte OpenRoaming para espacios públicos. Para establecimientos de Hostelería , Retail , Transporte y Sanidad , participar en OpenRoaming ofrece una conectividad de invitados segura y fluida a escala. Purple actúa como un proveedor de identidad gratuito para OpenRoaming bajo la licencia Connect, lo que permite a los usuarios con perfiles existentes conectarse de forma segura sin necesidad de un Captive Portal o contraseña, respaldado por el mismo modelo de confianza PKI descrito en esta guía.
Resolución de problemas y mitigación de riesgos
Incluso con una planificación cuidadosa, los despliegues de PKI se enfrentan a modos de fallo predecibles. La siguiente tabla resume los problemas más comunes y sus soluciones.
| Modo de fallo | Síntoma | Causa raíz | Resolución |
|---|---|---|---|
| Fallo de sincronización horaria | Errores de validación de certificados en todos los dispositivos | Configuración incorrecta de NTP en el cliente o RADIUS | Aplicar la política NTP a través del MDM y la infraestructura de red |
| Fallo en la cadena de confianza | Tipos de dispositivos específicos (por ejemplo, Android) no pueden conectarse | La CA raíz no está en el almacén de raíces de confianza del dispositivo | Enviar la CA raíz a través del perfil MDM |
| CRL inaccesible | Fallos de autenticación intermitentes | El firewall bloquea los endpoints CRL/OCSP | Abrir reglas de firewall para los puntos de distribución de la CA |
| Vencimiento del certificado | Desconexión masiva repentina | Automatización de la renovación no configurada | Implementar la renovación activada por MDM al 60 % de validez |
| Discrepancia de cert. RADIUS | Todos los clientes fallan en la autenticación mutua | El certificado del servidor RADIUS ha caducado o es de una CA incorrecta | Renovar el certificado del servidor RADIUS y volver a desplegar |
Para entornos sanitarios específicamente, donde el tiempo de inactividad de la red tiene implicaciones directas en la seguridad del paciente, consulte WiFi en hospitales: guía para redes clínicas seguras para obtener recomendaciones de resiliencia de nivel clínico.
ROI e impacto empresarial
La implementación de PKI para la seguridad WiFi aporta un valor empresarial medible en tres dimensiones.
Reducción de riesgos y cumplimiento normativo. La eliminación de las contraseñas compartidas suprime el vector más común para el movimiento lateral en la red. La autenticación basada en certificados responde directamente a los requisitos de PCI DSS (requisito 8.6), GDPR (medidas técnicas del artículo 32) e ISO 27001 (anexo A.9). La capacidad de revocar instantáneamente un certificado cuando un empleado se marcha o se roba un dispositivo proporciona un control auditable y demostrable que los entornos de clave compartida simplemente no pueden igualar.
Eficiencia operativa. El aprovisionamiento automatizado de certificados a través de MDM reduce significativamente los tickets de soporte de TI relacionados con problemas de conectividad WiFi (restablecimiento de contraseñas, rotación de claves y retrasos en la incorporación). En entornos de retail con una alta rotación de personal, esto se traduce directamente en una reducción de los costes de soporte de TI y en tiempos de despliegue de dispositivos más rápidos.
Experiencia de usuario e invitados mejorada. La autenticación basada en certificados es invisible para el usuario final. Los empleados corporativos se conectan de forma automática y segura sin necesidad de realizar pasos manuales. Para los invitados, plataformas como la solución de WiFi para invitados de Purple gestionan la separación entre el acceso corporativo administrado y la incorporación de invitados, garantizando que cada público reciba la experiencia de autenticación adecuada sin comprometer la seguridad en ninguna de las redes.
Definiciones clave
Infraestructura de clave pública (PKI)
El marco integral de funciones, políticas, hardware y software utilizado para gestionar certificados digitales y el cifrado de clave pública. Establece las relaciones de confianza que permiten a los dispositivos y servidores verificar sus identidades criptográficamente.
La arquitectura fundamental necesaria para alejarse de las contraseñas compartidas y avanzar hacia la seguridad de red basada en la identidad. Cada implementación de WiFi empresarial que utiliza 802.1X depende de una PKI.
Autoridad de certificación (CA)
Una entidad de confianza que emite, firma y gestiona certificados digitales. Actúa como la raíz de confianza en una PKI: cualquier certificado firmado por la CA es de confianza para todas las partes que confían en la CA.
El pilar central de la seguridad de su red. Si la CA se ve comprometida, todos los certificados que ha emitido están potencialmente comprometidos. Proteger la CA raíz es el control de seguridad más importante en una implementación de PKI.
X.509
El estándar ITU-T que define el formato de los certificados de clave pública. Los certificados X.509 contienen campos que incluyen el Sujeto, el Emisor, la Clave Pública, el Periodo de Validez y la Firma Digital de la CA.
Al configurar las políticas del servidor RADIUS, los equipos de TI asignan campos X.509 específicos, como el Subject Alternative Name (SAN) o la Unidad Organizativa (OU), a asignaciones de VLAN y políticas de acceso.
IEEE 802.1X
El estándar IEEE para el Control de Acceso a Red basado en puertos (PNAC). Proporciona un mecanismo de autenticación que bloquea todo el tráfico de red en el punto de acceso hasta que un servidor de autenticación haya verificado la identidad del dispositivo que se conecta.
El protocolo que aplica la autenticación basada en certificados en el punto de acceso inalámbrico. Sin 802.1X, un dispositivo puede conectarse al SSID sin demostrar su identidad.
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
Un método EAP que utiliza certificados de cliente y servidor para establecer una sesión TLS cifrada y mutuamente autenticada. Es el método EAP más seguro disponible para WiFi empresarial.
El estándar de oro para la autenticación WiFi corporativa. A diferencia de PEAP o EAP-TTLS, que utilizan contraseñas dentro de un túnel TLS, EAP-TLS elimina las contraseñas por completo, reemplazándolas por certificados criptográficos.
RADIUS (Remote Authentication Dial-In User Service)
Un protocolo de red que proporciona una gestión centralizada de autenticación, autorización y contabilidad (AAA). En las implementaciones 802.1X, el servidor RADIUS recibe el certificado del cliente desde el punto de acceso, lo valida contra la CA y devuelve una decisión de acceso.
El motor de decisiones de la pila de autenticación WiFi empresarial. RADIUS también gestiona la asignación dinámica de VLAN, lo que permite la segmentación de la red en función de la identidad del dispositivo o el rol del usuario.
Lista de revocación de certificados (CRL)
Una lista publicada periódicamente de certificados que han sido revocados por la CA emisora antes de su fecha de caducidad programada. Los servidores RADIUS comprueban la CRL para asegurarse de que no están concediendo acceso a dispositivos comprometidos o retirados del servicio.
Fundamental para mantener la seguridad cuando los dispositivos se pierden, se roban o se retiran del servicio. La comprobación de CRL debe configurarse en el servidor RADIUS; no se realiza de forma automática.
Autenticación mutua
Un proceso de seguridad en el que ambas partes de un enlace de comunicación se autentican mutuamente de forma simultánea. En EAP-TLS, el cliente se autentica ante la red y la red se autentica ante el cliente.
Evita los ataques de 'Evil Twin' en los que un hacker configura un punto de acceso falso con el mismo SSID que la red corporativa para interceptar credenciales. Sin autenticación mutua, el cliente no tiene forma de verificar que se está conectando a la red legítima.
SCEP (Simple Certificate Enrollment Protocol)
Un protocolo que permite la distribución automatizada y escalable de certificados digitales a los dispositivos a través de un MDM o un sistema de gestión de dispositivos de red.
El mecanismo que hace que las implementaciones de PKI empresariales sean operativamente viables a escala. Sin SCEP o un protocolo de inscripción automatizado similar, el aprovisionamiento de certificados a miles de dispositivos requeriría una intervención manual.
Ejemplos prácticos
Una gran cadena de retail con 500 tiendas necesita proteger su WiFi corporativo para las tabletas de punto de venta (POS) de los empleados y los escáneres de inventario. Actualmente utilizan una única clave WPA2-PSK en todas las tiendas, que se comparte con frecuencia con personas ajenas a la empresa y no se puede auditar. ¿Cómo deberían rediseñar su arquitectura de autenticación?
La cadena de retail debe migrar a WPA3-Enterprise utilizando 802.1X y EAP-TLS. Paso 1: Seleccionar un proveedor de PKI gestionado en la nube e integrarlo con la solución MDM existente que gestiona las tabletas POS y los escáneres. Paso 2: Configurar SCEP para enviar automáticamente certificados digitales únicos y vinculados al dispositivo a cada equipo corporativo a través del MDM. Paso 3: Implementar un servicio Cloud RADIUS y configurarlo para validar los certificados contra la PKI, con la comprobación OCSP habilitada. Paso 4: Reconfigurar los controladores inalámbricos en cada tienda para aplicar la autenticación 802.1X en el SSID corporativo. Paso 5: Retirar la red PSK. Paso 6: Configurar la asignación de VLAN a través de atributos RADIUS para segmentar los dispositivos POS de los dispositivos del personal general a nivel de red.
Una importante red de hospitales está implementando nuevas bombas de infusión médica inalámbricas en tres centros. Estos dispositivos carecen de una interfaz de usuario para introducir credenciales o aceptar solicitudes de Captive Portal. ¿Cómo se pueden conectar de forma segura a la red WiFi clínica sin crear una vulnerabilidad de clave compartida?
Implementar una arquitectura basada en PKI específicamente para dispositivos médicos IoT sin interfaz de usuario (headless). Paso 1: Generar certificados X.509 específicos para cada bomba de infusión, utilizando el número de serie del dispositivo como Subject Common Name. Paso 2: Instalar los certificados en las bombas durante la fase de preparación y aprovisionamiento, antes de su despliegue clínico. Paso 3: Configurar el SSID de la WiFi clínica para 802.1X EAP-TLS. Paso 4: Configurar el servidor RADIUS para asignar el Subject CN del certificado del dispositivo a una VLAN específica dedicada a dispositivos médicos. Paso 5: Implementar la comprobación CRL para permitir la revocación instantánea si un dispositivo se retira del servicio o se retira del mercado.
Preguntas de práctica
Q1. Su organización está migrando de PEAP (usuario/contraseña) a EAP-TLS (certificados) para el SSID corporativo. Durante las pruebas, los portátiles Windows se conectan correctamente, pero los dispositivos Android fallan sistemáticamente. Los registros de RADIUS muestran que los dispositivos Android rechazan el certificado del servidor durante el protocolo de enlace TLS. ¿Cuál es la causa más probable y cómo se resuelve?
Sugerencia: Considere el concepto de autenticación mutua y la cadena de confianza. ¿Qué necesita el dispositivo Android para confiar en el certificado del servidor RADIUS?
Ver respuesta modelo
Los dispositivos Android no tienen instalado el certificado de la CA raíz en su almacén de raíces de confianza. Los portátiles Windows reciben la CA raíz a través de la Directiva de grupo de forma automática, pero los dispositivos Android requieren que la CA raíz se envíe a través de un perfil de MDM. Sin la CA raíz en el almacén de confianza, el dispositivo Android no puede verificar la cadena de certificados del servidor RADIUS, lo que hace que rechace el certificado del servidor y aborte el protocolo de enlace TLS. Solución: crear un perfil de configuración de MDM que instale el certificado de la CA raíz en el almacén de raíces de confianza en todos los dispositivos Android gestionados y, a continuación, volver a realizar la prueba.
Q2. El portátil corporativo de un empleado despedido recientemente sigue conectándose correctamente a la red WiFi de la empresa dos días después de que se deshabilitara su cuenta de Active Directory. La red utiliza EAP-TLS. ¿Por qué ocurre esto y qué se debe hacer para evitarlo?
Sugerencia: Deshabilitar una cuenta de Active Directory no invalida automáticamente un certificado criptográfico. Considere qué está validando realmente el servidor RADIUS.
Ver respuesta modelo
El servidor RADIUS está validando el certificado, no el estado de la cuenta de Active Directory. Dado que el certificado sigue siendo matemáticamente válido y no ha sido revocado, el servidor RADIUS concede el acceso. Para resolverlo de inmediato, se debe revocar en la Autoridad de certificación el certificado específico emitido para ese portátil. Para evitar esto de forma sistemática, integre el proceso de baja de RR. HH. con el MDM y la PKI: cuando se despide a un empleado, el MDM debe revocar automáticamente el certificado del dispositivo y anular su inscripción. Además, asegúrese de que el servidor RADIUS esté configurado para comprobar OCSP o la CRL en cada intento de autenticación, y no solo periódicamente, para que la revocación surta efecto de inmediato.
Q3. Está diseñando la arquitectura de red para un gran estadio que desea ofrecer WiFi seguro y sin interrupciones a 60 000 asistentes sin necesidad de que cada persona pase por un Captive Portal. El recinto también desea dar soporte a los expositores corporativos que necesitan acceso seguro mediante 802.1X para sus equipos POS. ¿Cómo influye la PKI en ambos requisitos?
Sugerencia: Tenga en cuenta que existen dos públicos distintos con diferentes necesidades de autenticación. OpenRoaming aborda uno; un SSID corporativo dedicado con 802.1X aborda el otro.
Ver respuesta modelo
Se requieren dos SSID independientes. Para los 60 000 asistentes, implemente OpenRoaming. La red del estadio debe estar configurada para confiar en las CA raíz de OpenRoaming. Cuando el dispositivo de un visitante, aprovisionado por un proveedor de identidad como Purple o un operador móvil, se conecta, presenta un certificado. El servidor RADIUS lo valida contra la cadena de confianza de OpenRoaming y concede un acceso seguro y cifrado sin necesidad de un Captive Portal. Para los expositores corporativos con equipos POS, implemente un SSID 802.1X independiente utilizando EAP-TLS. A los expositores se les emiten certificados de dispositivo temporales durante su proceso de acreditación, que se revocan automáticamente después del evento. Los atributos RADIUS asignan los dispositivos POS a una VLAN dedicada, cumpliendo con los requisitos de segmentación de red de PCI DSS.
Continúe leyendo esta serie
PSK por dispositivo según el fabricante: comparación de iPSK, DPSK, MPSK y PPSK (y compatibilidad con WPA3)
Una comparación exhaustiva de las implementaciones de PSK por dispositivo en Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Extreme, Fortinet y Ubiquiti UniFi. Descubra cómo afecta WPA3-SAE a las estrategias de claves por dispositivo y cuándo implementar modos de transición en lugar de migrar a 802.1X.
Comparativa de métodos de autenticación de Captive Portal
Esta guía de referencia técnica autorizada evalúa las ventajas y desventajas arquitectónicas, operativas y de cumplimiento de cinco métodos principales de autenticación de Captive Portal. Proporciona a los arquitectos de red, directores de TI y directores de marketing los datos cuantitativos y los marcos de decisión necesarios para equilibrar la fricción en el registro de invitados con los requisitos de recopilación de datos en los recintos empresariales.
¿Qué es la autenticación por dirección MAC? Cuándo usarla y cuándo evitarla
Esta guía de referencia técnica autorizada aborda la autenticación por dirección MAC en entornos WiFi empresariales: cómo funciona la autenticación MAC basada en RADIUS en la Capa 2, sus vulnerabilidades de seguridad inherentes (incluido el spoofing de MAC y el impacto de la aleatorización de MAC a nivel de sistema operativo) y los contextos operativos precisos donde sigue siendo una herramienta válida para gestionar dispositivos IoT y headless. Proporciona orientación de despliegue práctica para responsables de TI y arquitectos de red en sectores como hostelería, retail, sanidad y espacios públicos, con ejemplos prácticos reales, marcos de decisión y contexto de integración para la plataforma de analítica y WiFi de invitados de Purple.