Conceptos fundamentales de PKI para administradores de WiFi: certificados, CA y cadenas de confianza
Esta guía de referencia técnica explica los conceptos fundamentales de la Infraestructura de Clave Pública (PKI) para administradores de WiFi empresarial, cubriendo autoridades de certificación, cadenas de confianza y certificados X.509. Detalla cómo PKI sustenta la autenticación mutua EAP-TLS y proporciona orientación de implementación práctica para equipos de TI en entornos de hostelería, retail y sector público. Comprender PKI es un requisito previo obligatorio para implementar la autenticación WiFi de empleados basada en certificados con Purple.
Escuchar esta guía
Ver transcripción del podcast
Parte de nuestra serie principal: Guía de seguridad WiFi empresarial →
Resumen Ejecutivo
Para los directores de TI, arquitectos de red y directores de operaciones de instalaciones, garantizar la seguridad de las redes WiFi corporativas y de personal es un requisito operativo y de cumplimiento fundamental. Los métodos de autenticación heredados, como las claves previamente compartidas (PSK) o el filtrado de direcciones MAC, son insuficientes para los entornos empresariales modernos, lo que deja a las redes expuestas al robo de credenciales y a la suplantación de identidad de dispositivos. Para lograr una seguridad sólida y auditable, las organizaciones deben realizar la transición a la autenticación basada en certificados, concretamente EAP-TLS (Extensible Authentication Protocol-Transport Layer Security).
La implementación de EAP-TLS requiere una comprensión sólida de la infraestructura de clave pública (PKI). Esta guía desmitifica la PKI para los administradores de WiFi, explicando las funciones de las autoridades de certificación (CA), la mecánica de la cadena de confianza y las diferencias prácticas entre los certificados de servidor y de cliente. Al dominar estos conceptos fundamentales, los equipos de TI pueden diseñar e implementar con confianza soluciones de acceso a la red seguras y escalables en sectores como la hostelería, el comercio minorista y los espacios del sector público, garantizando el cumplimiento de normativas como PCI-DSS y GDPR, a la vez que ofrecen una conectividad fluida y sin contraseñas para los dispositivos gestionados. Comprender la PKI es también el requisito previo fundamental para implementar la autenticación de WiFi para personal basada en certificados con Purple.
Análisis Técnico Detallado
La Arquitectura de la Confianza: ¿Qué es la Infraestructura de Clave Pública?
La infraestructura de clave pública (PKI) es un marco criptográfico que permite una comunicación segura y una autenticación mutua a través de una red no confiable. En el contexto de la red WiFi empresarial, la PKI actúa como un sistema de pasaporte digital, verificando la identidad tanto del dispositivo cliente (el suplicante) como del servidor de autenticación de red (el servidor RADIUS) antes de que se intercambie cualquier dato.
Este sistema se basa en certificados X.509, que vinculan una clave pública a una identidad verificada (como el nombre de host de un servidor o la dirección de correo electrónico de un usuario) y están firmados digitalmente por un tercero de confianza conocido como Autoridad de Certificación (CA). La firma de la CA es la garantía criptográfica de que la declaración de identidad es legítima.
La Jerarquía de Certificados y la Cadena de Confianza
La solidez de la PKI reside en su estructura jerárquica, conocida como la cadena de confianza. Esta jerarquía garantiza que cualquier certificado presentado por un dispositivo o servidor pueda rastrearse criptográficamente hasta una fuente de confianza universal. Los tres niveles son los siguientes.
Autoridad de Certificación Raíz (Root CA): La Root CA es el ancla criptográfica de todo el ecosistema PKI. Emite un certificado autofirmado y es inherentemente de confianza para los dispositivos cliente y servidores. En una implementación empresarial segura, la Root CA se mantiene fuera de línea y aislada físicamente para proteger su clave privada de cualquier compromiso basado en la red. Su único propósito operativo es firmar los certificados de las Intermediate CAs.
Autoridad de Certificación Intermedia (Intermediate CA): La Intermediate CA actúa como un amortiguador entre la Root CA, altamente segura, y el entorno operativo. Está en línea y se encarga de la emisión y revocación diaria de los certificados hoja. Esta separación es una estrategia crítica de mitigación de riesgos: si una Intermediate CA se ve comprometida, puede ser revocada por la Root CA sin invalidar toda la infraestructura PKI o requerir que se vuelvan a configurar todos los dispositivos cliente.
Certificados Hoja (Certificados de Entidad Final): Estos son los certificados instalados en servidores individuales y dispositivos cliente. Se encuentran en la parte inferior de la cadena de confianza y no pueden firmar otros certificados. Existen dos tipos principales relevantes para la implementación de WiFi. El Certificado de Servidor se instala en el servidor RADIUS, lo que permite a los dispositivos cliente verificar que se están conectando a la red corporativa legítima. El Certificado de Cliente se instala en los portátiles del personal, dispositivos móviles o terminales de punto de venta, lo que permite al servidor RADIUS verificar la identidad de cada dispositivo o usuario específico.
Cómo sustenta la PKI la autenticación EAP-TLS
EAP-TLS es el estándar de oro para la autenticación WiFi segura porque exige una autenticación mutua basada en certificados. Esto significa que tanto el dispositivo cliente como el servidor RADIUS deben demostrar su identidad mutuamente mediante certificados validados contra la cadena de confianza de la PKI, eliminando los riesgos inherentes a los enfoques basados en contraseñas.
Durante el protocolo de enlace EAP-TLS, que opera dentro del marco IEEE 802.1X, el servidor RADIUS presenta primero su Certificado de Servidor al dispositivo cliente. El dispositivo valida la firma del certificado contra su almacén de Root CA de confianza. Si es válido, el dispositivo tiene una prueba criptográfica de que se está conectando a la red corporativa legítima, no a un punto de acceso no autorizado o un punto de acceso gemelo malicioso. A continuación, el dispositivo cliente presenta su propio Certificado de Cliente al servidor RADIUS, que lo valida contra la CA. Una vez que ambas partes se han autenticado, se establece un túnel TLS seguro y se concede el acceso a la red. No se transmiten contraseñas y no existen secretos compartidos que puedan ser robados.
Esta arquitectura es también la base de WPA3-Enterprise, que exige un modo de seguridad de 192 bits y se apoya en los mismos fundamentos de PKI y 802.1X. Para las organizaciones que despliegan Wireless Access Points en entornos de alta seguridad, WPA3-Enterprise con EAP-TLS representa la mejor práctica actual.
CA pública frente a CA privada: la decisión de despliegue
Una de las decisiones de diseño de arquitectura más trascendentales en un despliegue de PKI es la elección entre una CA pública y una CA privada. La siguiente tabla resume las diferencias.
| Criterio | CA pública | CA privada |
|---|---|---|
| Coste | Tarifa por certificado (viable para un número reducido de servidores) | Coste de infraestructura, pero sin tarifas por certificado a gran escala |
| Confianza del dispositivo | Confiable por defecto en la mayoría de los sistemas operativos y dispositivos | Requiere que la Root CA se distribuya a todos los dispositivos mediante MDM |
| Control | Limitado; la CA controla las políticas de emisión | Control total sobre la emisión, revocación y ciclo de vida |
| Mejor caso de uso | Certificado de servidor RADIUS | Certificados de cliente para dispositivos corporativos gestionados |
| Cumplimiento normativo | Auditable mediante registros públicos de CT | Requiere procesos de auditoría interna |
El enfoque recomendado para la mayoría de los despliegues de WiFi empresariales es un modelo híbrido: utilizar una CA pública para el certificado del servidor RADIUS para garantizar una amplia compatibilidad, y desplegar una CA privada (como Microsoft Active Directory Certificate Services o un proveedor de PKI basado en la nube) para emitir certificados de cliente a dispositivos gestionados a gran escala.
¿Tiene preguntas sobre su configuración específica?
Nuestro equipo trabaja con operadores de recintos, responsables de TI e ingenieros de redes en 80 000 espacios. Reserve una llamada de 20 minutos y le mostraremos cómo lo han solucionado otros profesionales como usted.
Guía de implementación
Paso 1: Diseñar la arquitectura de la CA
Comience por definir sus requisitos de certificados. Identifique el número de dispositivos gestionados, los sistemas operativos en uso y la plataforma MDM disponible. Determine si una jerarquía de dos niveles (Root CA + Intermediate CA) o de tres niveles es la adecuada para la escala y el perfil de riesgo de su organización.
Paso 2: Desplegar y proteger las CA raíz e intermedias
Establezca la Root CA sin conexión en una máquina dedicada y aislada de la red. Utilice la Root CA para firmar el certificado de la Intermediate CA. Asegúrese de que la Intermediate CA se despliegue de forma segura en su centro de datos o entorno en la nube y se integre con su proveedor de identidad (IdP) o solución MDM. Almacene la clave privada de la Root CA en un módulo de seguridad de hardware (HSM) siempre que el presupuesto lo permita.
Paso 3: Configurar el servidor RADIUS
Instale el certificado de servidor en su servidor RADIUS. Configure el servidor para que requiera EAP-TLS para el SSID corporativo seguro. Asegúrese de que el servidor RADIUS confíe en la Intermediate CA que emitió los certificados de cliente y configúrelo para realizar la verificación de revocación a través de OCSP.
Paso 4: Distribuir certificados a través de MDM
Nunca intente la instalación manual de certificados a gran escala. Utilice una plataforma MDM como Microsoft Intune o Jamf para distribuir el certificado de la Root CA, el certificado de la Intermediate CA y los certificados de cliente únicos a todos los dispositivos gestionados mediante políticas automatizadas. Esto garantiza un despliegue constante y permite la renovación automatizada.
Paso 5: Implementar y probar los mecanismos de revocación
Configure listas de revocación de certificados (CRL) o el protocolo de estado de certificados en línea (OCSP). Pruebe el flujo de trabajo de revocación de extremo a extremo revocando un certificado de prueba y confirmando que el servidor RADIUS deniega el acceso dentro del plazo previsto. Para entornos que requieren una revocación casi instantánea - como las redes de punto de venta en el sector de Retail - el uso de OCSP es obligatorio.
Paso 6: Supervisar y automatizar la gestión del ciclo de vida
Implemente la supervisión automatizada de la caducidad de los certificados en todos los niveles de la jerarquía. Configure alertas a los 90, 60 y 30 días antes de la caducidad. Automatice la renovación a los 60 días. Este es el paso operativo más eficaz para evitar interrupciones en la red.
Buenas prácticas
Imponer la autenticación mutua sin excepción: Asegúrese de que los dispositivos cliente estén configurados para validar estrictamente el certificado del servidor RADIUS. Desactivar la validación del certificado del servidor - un atajo común durante el despliegue inicial - deja a los dispositivos vulnerables a ataques de intermediario (man-in-the-middle) y a la recopilación de credenciales, además de violar los requisitos de PCI-DSS.
Segregar las redes por método de autenticación: Utilice EAP-TLS para los dispositivos corporativos y del personal en un SSID dedicado. Para el acceso de visitantes públicos, despliegue una solución sólida de Captive Portal como Guest WiFi en una red totalmente segregada. No intente desplegar PKI en dispositivos de invitados no gestionados.
Auditar la infraestructura de PKI con regularidad: Realice auditorías trimestrales de los controles de acceso a la CA, las listas de revocación y los registros de emisión de certificados. En entornos de Healthcare y Retail, este es un requisito de cumplimiento regulado por HIPAA y PCI-DSS respectivamente.
Integrar con análisis de red: Una vez establecida la autenticación segura, incorpore WiFi Analytics para obtener visibilidad sobre el comportamiento de los dispositivos, los patrones de conexión y las posibles anomalías. Una red segura es la base para obtener datos de confianza.
Considerar la integración con SD-WAN: Para despliegues multisitio en cadenas de hoteles o establecimientos de retail, la PKI se integra de forma natural con las arquitecturas SD-WAN. Para comprender cómo se complementan estas tecnologías, consulte The Core SD-WAN Benefits for Modern Businesses.
Resolución de problemas y mitigación de riesgos
La siguiente tabla asocia los fallos más comunes con sus causas de origen y las mitigaciones recomendadas.
| Síntoma | Causa de origen | Mitigación |
|---|---|---|
| Los dispositivos no pueden conectarse; los registros de RADIUS muestran "CA desconocida" | El dispositivo cliente no confía en la CA que emitió el certificado del servidor RADIUS | Distribuya la CA raíz en todos los dispositivos mediante MDM |
| Interrupción repentina en toda la red para todos los dispositivos corporativos | El certificado del servidor RADIUS o el certificado de la CA intermedia ha caducado | Implemente la supervisión y renovación automatizadas; configure alertas a los 90, 60 y 30 días |
| Un portátil robado aún puede acceder a la red | La CRL no está actualizada o no se ha configurado OCSP | Cambie a OCSP para la verificación de revocación en tiempo real |
| Fallos de autenticación intermitentes | Desviación horaria entre el cliente y el servidor RADIUS | Asegúrese de que todos los dispositivos utilicen la sincronización de hora por NTP |
Para comprender mejor la configuración y resolución de problemas de 802.1X, la guía Autenticación 802.1X: Asegurando el acceso a la red en dispositivos modernos proporciona instrucciones detalladas de configuración independientes del fabricante.
ROI e impacto empresarial
La transición a una arquitectura EAP-TLS respaldada por PKI ofrece un valor empresarial medible para los operadores de recintos en múltiples dimensiones.
Mitigación de riesgos y cumplimiento: Eliminar la autenticación basada en contraseñas suprime el vector de ataque más común para la vulneración de redes. Esto reduce directamente la probabilidad de costosas brechas de datos y simplifica el cumplimiento de PCI-DSS (necesario para el procesamiento de pagos), GDPR (para la protección de datos) y las normativas específicas del sector. Para los recintos que despliegan Sensors de IoT o sistemas de localización Wayfinding, una red protegida criptográficamente es un requisito previo para garantizar la integridad de los datos de confianza.
Eficiencia operativa: Automatizar el despliegue de certificados a través de un MDM elimina la sobrecarga operativa de la gestión de contraseñas, reduciendo los tickets de soporte técnico de TI relacionados con la conectividad WiFi. En entornos con alta rotación de personal, como hoteles y comercios minoristas, donde las altas y bajas de empleados son frecuentes, la emisión y revocación automatizada de certificados proporciona un ahorro de tiempo significativo en comparación con la gestión de credenciales compartidas.
Base para servicios avanzados: Una red corporativa segura y autenticada es la base de confianza sobre la cual se construyen los servicios operativos avanzados. Ya sea implementando WiFi Analytics para inteligencia de afluencia, Sensors para datos de ocupación en tiempo real o Wayfinding para grandes recintos, cada una de estas capacidades se beneficia de las garantías de integridad que proporciona una PKI.
Específicamente para los operadores de Hospitality, la combinación de una red de personal segura y un portal de invitados bien diseñado - como se analiza en Soluciones modernas de WiFi para hostelería que sus huéspedes se merecen - representa la arquitectura WiFi empresarial completa. Para los centros de Transport y los grandes recintos públicos, se aplican los mismos principios a gran escala.
Definiciones clave
Infraestructura de Clave Pública (PKI)
Un marco de funciones, políticas, hardware, software y procedimientos necesarios para crear, gestionar, distribuir, utilizar, almacenar y revocar certificados digitales y gestionar el cifrado de clave pública.
La arquitectura fundamental que debe estar implementada antes de que un equipo de TI pueda implementar una autenticación WiFi segura basada en certificados mediante EAP-TLS.
Autoridad de Certificación (CA)
Una entidad de confianza que emite certificados digitales, verificando la identidad del sujeto del certificado y vinculando esa identidad a una clave pública con una firma criptográfica.
La autoridad central en su red que actúa como la fuente de confianza para todas las identidades de dispositivos y servidores. Sin una CA de confianza, no es posible realizar ninguna autenticación basada en certificados.
Certificado X.509
El formato estándar para certificados de clave pública, definido en RFC 5280. Contiene la identidad del sujeto, la clave pública, la identidad del emisor, el período de validez y la firma digital de la CA.
El pasaporte digital real instalado en un ordenador portátil o servidor que demuestra su identidad durante el protocolo de enlace EAP-TLS.
EAP-TLS (Protocolo de Autenticación Extensible-Seguridad de la Capa de Transporte)
Un método de autenticación 802.1X que requiere autenticación mutua basada en certificados entre el dispositivo cliente (suplicante) y el servidor de autenticación (RADIUS). Definido en RFC 5216.
El método más seguro para autenticar dispositivos corporativos en una red WiFi. Elimina la necesidad de contraseñas y proporciona una prueba criptográfica de identidad para ambas partes.
Cadena de Confianza
Una secuencia jerárquica de certificados utilizada para autenticar una entidad, comenzando desde el certificado final y subiendo a través de la CA intermedia hasta la CA raíz.
El mecanismo mediante el cual un ordenador portátil verifica que el certificado de un servidor RADIUS es legítimo. Cada enlace de la cadena se valida hasta que se alcanza una CA raíz de confianza.
Lista de Revocación de Certificados (CRL)
Una lista publicada periódicamente de certificados digitales que han sido revocados por la CA emisora antes de su fecha de caducidad programada y en los que ya no se debe confiar.
Un mecanismo para bloquear el acceso desde dispositivos perdidos o robados. Las CRL se almacenan en caché y se actualizan de forma programada, lo que significa que la revocación puede no ser inmediata, una limitación que aborda OCSP.
Protocolo de Estado de Certificados en Línea (OCSP)
Un protocolo de internet (RFC 6960) utilizado para obtener el estado de revocación en tiempo real de un certificado digital X.509 mediante la consulta al respondedor OCSP de la CA.
El mecanismo de revocación preferido para entornos de alta seguridad. Permite al servidor RADIUS comprobar la validez del certificado en tiempo real durante cada intento de autenticación, lo que proporciona una aplicación de la revocación casi instantánea.
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) para usuarios y dispositivos que se conectan a una red.
El servidor central en un despliegue de WiFi corporativo que valida certificados y toma la decisión final de control de acceso. El servidor RADIUS es el núcleo operativo de un despliegue EAP-TLS.
IEEE 802.1X
Un estándar de IEEE para el Control de Acceso a Red Basado en Puertos (PNAC) que proporciona un mecanismo de autenticación para los dispositivos que desean conectarse a una LAN o WLAN.
El marco general dentro del cual opera EAP-TLS. Comprender 802.1X es esencial para configurar puntos de acceso y switches con el fin de aplicar la autenticación basada en certificados.
Mobile Device Management (MDM)
Una plataforma de software utilizada por los administradores de TI para gestionar, configurar y proteger de forma remota dispositivos móviles y portátiles en toda una organización.
La herramienta operativa esencial para desplegar certificados a escala. Las plataformas MDM como Microsoft Intune y Jamf automatizan la distribución de certificados de CA raíz, certificados de CA intermedia y certificados de cliente a todos los dispositivos gestionados.
Ejemplos prácticos
Un hotel de lujo de 500 habitaciones en Londres necesita proteger su red WiFi de personal para las tablets de limpieza y las terminales de punto de venta (POS). Actualmente, utilizan una única Clave Precompartida (PSK) que no se ha rotado en tres años y que es conocida por todo el personal fijo y de agencia. El director de TI tiene la tarea de realizar la transición a una arquitectura basada en certificados antes de la próxima auditoría de PCI-DSS. ¿Cómo se debería abordar esto?
Fase 1 - Diseño de la arquitectura: implementar una PKI privada basada en la nube (por ejemplo, Microsoft NDES a través de Intune, o un proveedor de PKI en la nube dedicado) integrada con la plataforma MDM del hotel. Obtener un certificado de servidor RADIUS de una CA pública como DigiCert.
Fase 2 - Implementación de la infraestructura: configurar el servidor RADIUS con el nuevo certificado de servidor y habilitar EAP-TLS en un nuevo SSID oculto designado para los dispositivos del personal. Configurar OCSP para la verificación de revocación en tiempo real.
Fase 3 - Registro de dispositivos: utilizar la plataforma MDM para distribuir la CA raíz privada, la CA intermedia y los certificados de cliente únicos a todas las tablets de limpieza y terminales POS. Verificar la instalación correcta del certificado en un grupo piloto de 20 dispositivos antes del despliegue completo.
Fase 4 - Migración y desmantelamiento: migrar todos los dispositivos al nuevo SSID EAP-TLS a través de la política de MDM. Confirmar la conectividad en todos los tipos de dispositivos. Tras un periodo de funcionamiento en paralelo de dos semanas, desmantelar la red PSK heredada.
Fase 5 - Entrega operativa: documentar el ciclo de vida de los certificados, los procedimientos de revocación y las políticas de MDM. Configurar alertas de vencimiento automatizadas y programar auditorías de PKI trimestrales.
Una cadena de tiendas nacional está implementando EAP-TLS en 200 tiendas. Durante las pruebas piloto en cinco tiendas, el equipo de TI descubre que cuando se denuncia el robo de la tablet de un gerente de tienda y se revoca el certificado en el sistema PKI, el dispositivo aún puede autenticarse con éxito en la red WiFi corporativa hasta 18 horas después de la revocación. El equipo de seguridad considera que este es un riesgo inaceptable, dado que el dispositivo puede tener acceso a los sistemas de gestión de inventario. ¿Cómo debería resolverse esto?
El retraso de 18 horas se debe a que el servidor RADIUS depende de una Lista de Revocación de Certificados (CRL) almacenada en caché y descargada con poca frecuencia. Las CRL se suelen publicar de forma programada (por ejemplo, cada 24 horas) y el servidor RADIUS las almacena en caché, lo que significa que la revocación no se refleja en tiempo real.
La resolución consiste en reconfigurar el servidor RADIUS para que utilice el Protocolo de Estado de Certificados en Línea (OCSP) como mecanismo principal de comprobación de revocación. El OCSP permite al servidor RADIUS realizar consultas al respondedor OCSP de la CA en tiempo real durante cada protocolo de enlace EAP-TLS, recibiendo una respuesta inmediata de "válido", "revocado" o "desconocido" para el certificado específico que se presenta.
Pasos de configuración: (1) Asegurarse de que la CA privada esté configurada con un endpoint de respondedor OCSP. (2) Actualizar la configuración del servidor RADIUS para consultar el endpoint OCSP en cada intento de autenticación. (3) Configurar el grapado OCSP (OCSP stapling) donde sea compatible para reducir la latencia. (4) Realizar una prueba revocando un certificado y confirmando que el servidor RADIUS deniega el acceso en menos de 60 segundos.
Preguntas de práctica
Q1. Su organización está migrando de PEAP-MSCHAPv2 (usuario y contraseña) a EAP-TLS para la red WiFi corporativa. El equipo de redes propone utilizar la infraestructura existente de Active Directory Certificate Services (AD CS) para emitir certificados tanto a los servidores RADIUS como a todos los portátiles corporativos. Un miembro del equipo señala que la organización también cuenta con 50 portátiles de contratistas que no están unidos al dominio. ¿Cuál es el principal riesgo de compatibilidad y cómo debería abordarse?
Sugerencia: Considere cómo validarán los dispositivos que no están unidos al dominio la identidad del servidor RADIUS cuando este presente un certificado firmado por su AD CS Root CA privada.
Ver respuesta modelo
El riesgo principal es que los 50 portátiles de contratistas que no están unidos al dominio no tendrán la AD CS Root CA privada en su almacén de certificados de confianza. Cuando el servidor RADIUS presente su certificado de servidor durante el saludo EAP-TLS, estos dispositivos recibirán un error de "Certificado no confiable" y la conexión fallará. La solución recomendada consiste en obtener el certificado de servidor RADIUS de una CA pública (como DigiCert o Sectigo) en lugar de la AD CS privada. Las raíces de las CA públicas están preinstaladas en los almacenes de confianza de todos los sistemas operativos principales, lo que garantiza la compatibilidad tanto con dispositivos unidos al dominio como con aquellos que no lo están. La AD CS privada debe reservarse únicamente para la emisión de certificados de cliente para dispositivos gestionados y unidos al dominio.
Q2. Durante una auditoría de cumplimiento para un gran consorcio de hospitales del NHS, el auditor señala que la Root CA se está ejecutando como una máquina virtual en el centro de datos principal y está conectada de forma permanente a la red interna del hospital. El auditor califica esto como un hallazgo crítico. ¿Qué cambio de arquitectura debe implementarse y por qué la configuración actual representa un riesgo significativo?
Sugerencia: Considere qué sucedería con cada uno de los certificados de la organización si la clave privada de la Root CA se viera comprometida por un ataque de ransomware o por una amenaza interna.
Ver respuesta modelo
La CA raíz debe desconectarse de inmediato y mantenerse aislada físicamente (air-gapped). La configuración actual representa un riesgo crítico porque la clave privada de la CA raíz está expuesta a ataques basados en la red, incluidos el ransomware, el movimiento lateral desde una cuenta de dominio comprometida o las amenazas internas. Si la clave privada de la CA raíz es robada o utilizada para firmar certificados maliciosos, toda la infraestructura de PKI - y por lo tanto, cada sistema autenticado por certificado en la cadena de confianza - se ve comprometida. La recuperación requeriría revocar la CA raíz y volver a emitir cada certificado en la organización, un evento operativo catastrófico. La arquitectura correcta requiere que la CA raíz se encienda únicamente al firmar o revocar un certificado de CA intermedia, dejando toda la emisión diaria en manos de una CA intermedia en línea. La clave privada de la CA raíz debe almacenarse en un Módulo de Seguridad de Hardware (HSM).
Q3. El operador de un gran centro de conferencias desea implementar la autenticación basada en certificados tanto para su personal de TI permanente como para los miles de expositores y visitantes que asisten a los eventos. Le piden que diseñe una única infraestructura PKI para dar servicio a ambos grupos. ¿Cuál es su recomendación y por qué?
Sugerencia: Considere la viabilidad operativa de distribuir certificados a miles de visitantes temporales no gestionados que pueden asistir a un evento por un solo día.
Ver respuesta modelo
Debería desaconsejar encarecidamente el uso de PKI y EAP-TLS para visitantes públicos y expositores. La autenticación basada en certificados requiere la instalación de un certificado de cliente y, a menudo, de un perfil de CA raíz en el dispositivo del usuario final, lo cual es operacionalmente imposible para dispositivos temporales no gestionados y genera una experiencia de usuario extremadamente deficiente. EAP-TLS debe reservarse estrictamente para el personal de TI permanente que utiliza dispositivos corporativos gestionados e inscritos en la plataforma MDM de la organización. Para expositores y visitantes, se debe implementar una solución de Captive Portal en un SSID completamente separado y segregado. Esta arquitectura de dos redes - EAP-TLS seguro para el personal, Captive Portal para los invitados - es el estándar de la industria para los operadores de recintos y es el modelo que admite la plataforma de Purple.
Q4. Un responsable de TI de una cadena minorista ha implementado con éxito EAP-TLS en las 150 tiendas. Seis meses después, el servidor RADIUS de 12 tiendas deja de aceptar conexiones de clientes de forma simultánea. La investigación revela que no se ha producido ninguna revocación de certificados. ¿Cuál es la causa más probable y qué fallo en el proceso permitió que esto sucediera?
Sugerencia: Considere qué podrían tener en común las 12 tiendas afectadas desde la perspectiva de los certificados, y qué evento podría causar fallos simultáneos.
Ver respuesta modelo
La causa más probable es que el certificado de la CA intermedia - o el certificado del servidor RADIUS - haya caducado. Si las 12 tiendas se configuraron utilizando la misma CA intermedia o el mismo lote de certificados de servidor RADIUS emitidos al mismo tiempo, todos caducarían simultáneamente. Se trata de un fallo en la gestión del ciclo de vida: la organización no implementó una supervisión y alerta automatizadas de la caducidad de los certificados. La resolución requiere renovar los certificados caducados e implementar de inmediato una supervisión automatizada con alertas a los 90, 60 y 30 días antes de la caducidad para todos los certificados de la jerarquía, incluidos la CA intermedia, el certificado del servidor RADIUS y la CA raíz.
Continúe leyendo esta serie
Cumplimiento con CIPA: lista de verificación para operadores de establecimientos
Podrá decidir si CIPA vincula su WiFi, segmentar redes, enrutar DNS a través de Purple Shield y cerrar rutas de derivación. También sabrá qué pruebas conservar para la certificación del Formulario 486 o del Formulario 479. La lista de verificación asigna un responsable a cada requisito, para que no falte nada en la certificación de su próximo año de financiación.
Fallos de conexión en modo de transición WPA3: lista de comprobación de implementación para Cisco Meraki, HPE Aruba y Ruckus
Utilice esta lista de comprobación para diagnosticar por qué los dispositivos fallan en un SSID con modo de transición WPA3 SAE y soluciónelo en Cisco Meraki, HPE Aruba o Ruckus. Relacionará los códigos de estado 802.11 con sus causas, aislará problemas de PMF, 802.11r y 6GHz, y decidirá cuándo pasar a un SSID exclusivo de WPA3.
El mejor filtrado de DNS: una guía completa para empresas
Esta guía de referencia técnica explica cómo el filtrado de DNS empresarial protege las redes públicas al bloquear dominios maliciosos en la capa de resolución, antes de que se establezca una conexión. Proporciona a los directores de TI, arquitectos de redes y equipos de operaciones de las instalaciones la arquitectura de despliegue, la configuración del firewall y el contexto de cumplimiento que necesitan para proteger el WiFi de invitados en entornos de hostelería, comercio minorista y sector público. Purple Shield bloquea el malware, las redes de bots y el contenido inapropiado a nivel de DNS en más de 80.000 establecimientos activos.
¿Tiene preguntas sobre su configuración específica?
Nuestro equipo trabaja con operadores de recintos, responsables de TI e ingenieros de redes en 80 000 espacios. Reserve una llamada de 20 minutos y le mostraremos cómo lo han solucionado otros profesionales como usted.