Cómo implementar SCEP para el registro automatizado de certificados WiFi
Esta guía explica cómo implementar SCEP (Simple Certificate Enrollment Protocol) para el registro automatizado de certificados WiFi en entornos empresariales. Cubre el diseño arquitectónico completo, desde el diseño de PKI y la integración con MDM hasta la secuencia de despliegue obligatoria de tres pasos, y muestra a los responsables de TI y arquitectos de red cómo eliminar las credenciales compartidas, automatizar la gestión del ciclo de vida de los certificados y cumplir con los requisitos de PCI DSS y GDPR a escala.
Escuchar esta guía
Ver transcripción del podcast
Resumen ejecutivo
Para los operadores de recintos que ofrecen Guest WiFi en hoteles, tiendas, estadios y centros de conferencias, depender de claves precompartidas o portales cautivos básicos para el acceso a la red del personal es un riesgo de seguridad. La arquitectura de red moderna exige una autenticación 802.1X mediante EAP-TLS (Extensible Authentication Protocol - Transport Layer Security), lo que garantiza que cada dispositivo se verifique criptográficamente antes de acceder a la red. El desafío es la distribución: ¿cómo desplegar certificados de cliente únicos en miles de dispositivos Windows, iOS y Android sin saturar al servicio de soporte técnico?
La respuesta es SCEP (Simple Certificate Enrollment Protocol). Formalizado por el IETF como RFC 8894 en 2020, SCEP automatiza el registro de certificados en flotas de dispositivos gestionados. Cuando se integra con una plataforma MDM como Microsoft Intune o Jamf, SCEP ofrece un aprovisionamiento de certificados sin intervención: los dispositivos solicitan, reciben y renuevan sus propios certificados sin ninguna intervención de TI. La clave privada se genera localmente en el dispositivo y nunca se transmite a través de la red, lo que supone una ventaja de seguridad fundamental frente a la entrega basada en PKCS.
Esta guía detalla todo el flujo de trabajo de implementación de SCEP: la arquitectura de PKI, la configuración de la pasarela NDES, la secuencia obligatoria de despliegue de MDM en tres pasos y los controles operativos (en particular, la verificación de CRL y la asignación de grupos) que determinan si un despliegue tiene éxito o se estanca. Dos escenarios del mundo real ilustran este enfoque en entornos de hostelería y comercio minorista. Purple opera en más de 80.000 recintos activos y cuenta con 350 millones de usuarios únicos; los patrones descritos aquí reflejan lo que funciona a esa escala.
Análisis técnico detallado
Qué hace realmente SCEP
SCEP se sitúa entre su plataforma MDM y su autoridad de certificación (CA). Proporciona un mecanismo estandarizado basado en HTTP para que los dispositivos soliciten, reciban y renueven certificados X.509 sin necesidad de una credencial unida al dominio o de la intervención manual de un administrador. El protocolo se desarrolló originalmente a principios de la década de 2000 y obtuvo una adopción generalizada en entornos MDM empresariales antes de que el IETF lo publicara formalmente como RFC 8894.
El flujo de registro de seis pasos funciona de la siguiente manera. En primer lugar, el dispositivo gestionado se conecta a la URL de la pasarela SCEP preconfigurada en su perfil de MDM. En segundo lugar, el dispositivo genera un par de claves privada/pública localmente y crea una solicitud de firma de certificado (CSR). En tercer lugar, la pasarela SCEP valida la autorización del dispositivo mediante una contraseña de desafío o un OTP integrado en la política de MDM. En cuarto lugar, la pasarela reenvía la CSR validada a la CA. En quinto lugar, la CA firma el certificado y lo devuelve a la pasarela. En sexto lugar, la pasarela entrega el certificado firmado al dispositivo. Las renovaciones futuras siguen la misma ruta automatizada: el dispositivo se vuelve a registrar antes de la expiración sin ninguna acción por parte del usuario o del administrador.
SCEP frente a PKCS: la decisión clave
Microsoft Intune y la mayoría de las plataformas MDM admiten dos mecanismos de entrega de certificados: SCEP y PKCS. La distinción es arquitectónica, no estética.
Con SCEP, la clave privada se genera en el dispositivo y permanece allí. La CA nunca la ve. El TPM del dispositivo (en Windows) o el Secure Enclave (en iOS/macOS) protegen la clave a nivel de hardware. Con PKCS, la CA genera el par de claves de forma centralizada y lo transmite al dispositivo a través de la red. La CA conserva una copia, lo que permite el depósito de claves, algo útil para el cifrado de correo electrónico S/MIME pero que introduce un riesgo innecesario para la autenticación de red.
Para la autenticación WiFi 802.1X, utilice SCEP. La clave privada nunca sale del dispositivo. Esa es la regla.
| Criterio | SCEP | PKCS |
|---|---|---|
| Clave privada generada en | Dispositivo | CA (centralizado) |
| Clave privada transmitida por la red | Nunca | Sí |
| Compatible con TPM / Secure Enclave | Sí | No |
| Recomendado para autenticación WiFi | Sí | No |
| Recomendado para cifrado de correo (S/MIME) | No | Sí |
| Depósito de claves posible | No | Sí |
802.1X y EAP-TLS: el marco de autenticación
IEEE 802.1X es el estándar de control de acceso a la red basado en puertos que sustenta la seguridad WiFi empresarial. Define tres roles: el suplicante (el dispositivo cliente), el autenticador (el punto de acceso: Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme o Fortinet) y el servidor de autenticación (un servidor RADIUS como Microsoft NPS, FreeRADIUS o Cisco ISE).
EAP-TLS es el método EAP más seguro para 802.1X. Ambas partes presentan certificados: el servidor RADIUS presenta su certificado al cliente, y el cliente presenta su certificado provisto por SCEP al servidor RADIUS. Ninguna de las partes puede suplantar a la otra sin un certificado válido y no revocado de la jerarquía de CA de confianza. Este modelo de autenticación mutua elimina el robo de credenciales, los ataques de gemelo malvado (Evil Twin) y los riesgos de puntos de acceso no autorizados en una sola decisión arquitectónica.
EAP-TLS cumple con el requisito 8.6 de PCI DSS 4.0 para la autenticación multifactor en la capa de red. Es obligatorio para despliegues de WPA3 Enterprise de 192 bits (Suite B). Para cualquier red inalámbrica dentro del alcance del procesamiento de datos de titulares de tarjetas: minoristas punto de venta, recepción de hotel, venta de entradas en estadios: EAP-TLS es la opción correcta.
Para analizar en profundidad la arquitectura de secure WiFi y cómo la autenticación basada en certificados se integra en un marco de seguridad más amplio, consulte nuestra guía esencial.
Guía de implementación
La secuencia de despliegue no es negociable. Intune y Jamf resuelven las dependencias de los perfiles en orden: el perfil de WiFi depende del perfil SCEP, que a su vez depende del perfil de raíz de confianza (Trusted Root). Si los despliega fuera de orden, el perfil de WiFi no se aplicará.
Paso 1: Diseñe su PKI
Antes de tocar una consola MDM, diseñe su jerarquía de certificados. Una PKI de dos niveles es el estándar: una CA raíz fuera de línea (offline) y una CA emisora en línea (online). La clave privada de la CA raíz es el ancla de confianza maestra para toda su infraestructura de certificados; manténgala aislada de la red (air-gapped). La CA emisora gestiona la emisión diaria de certificados y publica la lista de revocación de certificados (CRL) y el respondedor OCSP.
Para la mayoría de los despliegues en recintos empresariales, Microsoft Active Directory Certificate Services (AD CS) ejecutado en Windows Server proporciona la CA emisora. Los servicios de PKI alojados en la nube de proveedores como SCEPman o SecureW2 eliminan por completo el requisito de infraestructura local y vale la pena evaluarlos para despliegues en entornos distribuidos en grupos hoteleros, cadenas de tiendas o administraciones públicas con múltiples sedes.
Paso 2: Despliegue el servidor NDES (o la pasarela SCEP en la nube)
NDES (Network Device Enrollment Service) es el rol de Microsoft Windows Server que actúa como pasarela SCEP entre su MDM y su CA. Requisitos clave de configuración:
- Publique la URL de NDES externamente a través de Azure AD Application Proxy (o un proxy inverso equivalente). Esto permite que los dispositivos remotos se registren antes de llegar a las instalaciones, sin necesidad de abrir puertos de entrada en el cortafuegos.
- La cuenta de servicio de NDES requiere permisos de lectura y registro (Read and Enroll) en la plantilla de certificado de la CA.
- Configure la plantilla de certificado con el uso de clave (Key Usage) establecido en Firma digital (Digital Signature) y Cifrado de clave (Key Encipherment), y el uso de clave extendido (Extended Key Usage) establecido en Autenticación de cliente (Client Authentication) (OID: 1.3.6.1.5.5.7.3.2).
- Establezca un periodo de validez de certificado adecuado. Un año es lo habitual para certificados de cliente; dos años es aceptable para certificados de dispositivo en flotas estables.
Si prefiere evitar la infraestructura NDES local, las pasarelas SCEP en la nube se integran directamente con Intune y su CA a través de una API, eliminando por completo la dependencia de IIS.
Paso 3: Despliegue el perfil de certificado raíz de confianza (Trusted Root)
En su plataforma MDM, cree un perfil de certificado de confianza (Trusted Certificate) y cargue su certificado de CA raíz (y cualquier certificado de CA intermedia) como archivos .cer. Despliegue este perfil en sus grupos de dispositivos de destino antes de cualquier otro perfil de certificado o de WiFi. Sin este paso, los dispositivos no podrán validar el certificado del servidor RADIUS durante el saludo (handshake) EAP-TLS, ni podrán confiar en la CA emisora al solicitar su propio certificado SCEP.
Regla de oro: Diríjase siempre al mismo grupo de Azure AD (ya sea de usuarios o de dispositivos) en los tres perfiles relacionados. Una discrepancia aquí es la causa más común de fallos en el despliegue de perfiles de WiFi.
Paso 4: Configure el perfil de certificado SCEP
Cree un perfil de configuración de certificado SCEP en su MDM:
- Formato del nombre del sujeto (Subject name format): Para la autenticación basada en el usuario, utilice
CN={{UserPrincipalName}}. Para la autenticación de dispositivos (recomendada para dispositivos compartidos e IoT), utiliceCN={{AAD_Device_ID}}. - Uso de clave (Key usage): Firma digital (Digital Signature), Cifrado de clave (Key Encipherment).
- Uso de clave extendido (Extended key usage): Autenticación de cliente (Client Authentication) (OID: 1.3.6.1.5.5.7.3.2).
- URL del servidor SCEP: La URL de NDES publicada externamente.
- Certificado raíz: Enlace al perfil de raíz de confianza (Trusted Root) del Paso 3.
- Periodo de validez del certificado: Debe coincidir con la plantilla configurada en la CA.
Paso 5: Despliegue el perfil de WiFi 802.1X
Cree un perfil de configuración de WiFi:
- SSID: Introduzca el nombre de la red exactamente como lo transmiten sus puntos de acceso.
- Tipo de seguridad: WPA2-Enterprise o WPA3-Enterprise.
- Tipo de EAP: EAP-TLS.
- Certificado de autenticación de cliente: Seleccione el perfil de certificado SCEP del Paso 4.
- Validación del servidor: Especifique el certificado de raíz de confianza (Trusted Root) del Paso 3 e introduzca el nombre esperado del servidor RADIUS. Esto evita que los dispositivos se conecten a puntos de acceso no autorizados que presenten certificados fraudulentos.
Buenas prácticas
Aplique una comprobación estricta de CRL en su servidor RADIUS
La revocación de certificados es el control operativo que cierra la brecha entre la desactivación de una cuenta y el bloqueo del acceso a la red. Cuando un dispositivo se pierde, se roba o un empleado se marcha, desactive la cuenta de AD y revoque el certificado en la CA. Su servidor RADIUS debe estar configurado para comprobar la CRL en cada intento de autenticación. Si la CRL no está disponible (porque el punto de distribución de CRL o CDP no es accesible), la mayoría de los servidores RADIUS fallan por defecto en modo abierto (fail open), lo que supone un riesgo de seguridad. Asegúrese de que sus CDP tengan una alta disponibilidad y de que su servidor RADIUS esté configurado para fallar en modo cerrado (fail closed) si no se puede obtener la CRL.
Para la revocación en tiempo real, configure OCSP (Online Certificate Status Protocol) además de la CRL. OCSP proporciona respuestas de estado por certificado sin necesidad de que el servidor RADIUS descargue y analice toda la CRL.
Utilice certificados de dispositivo para dispositivos compartidos e IoT
Para dispositivos compartidos (tabletas del servicio de limpieza de hoteles, terminales de punto de venta minoristas, lectores de control de acceso a estadios), utilice certificados de dispositivo en lugar de certificados de usuario. Los certificados de dispositivo están vinculados a la identidad de la máquina, no a una cuenta de usuario. Esto significa que el dispositivo se autentica independientemente del usuario que haya iniciado sesión, y la revocación está vinculada al registro del dispositivo en lugar de a la salida de un empleado.
Para despliegues en el sector minorista , los certificados de dispositivo en el hardware de punto de venta también cumplen con el requisito de PCI DSS para la identidad del dispositivo a nivel de red, sin introducir la complejidad de las credenciales de usuario en el punto de venta.
Automatice la renovación de certificados
SCEP admite la renovación automática: el MDM indica al dispositivo que vuelva a registrarse antes de que el certificado caduque. Configure su perfil SCEP para activar la renovación al 20 % del periodo de validez restante del certificado. Para un certificado de un año, la renovación comienza aproximadamente 73 días antes de la expiración. Este margen de tiempo ofrece suficiente margen para resolver cualquier fallo de renovación antes de que el certificado caduque y los dispositivos pierdan el acceso a la red.
Los certificados caducados que causan fallos de autenticación masivos son el incidente operativo más común en los despliegues de 802.1X. La renovación automatizada a través de SCEP elimina este riesgo por completo.
Segmentar redes por atributo de certificado
Los servidores RADIUS pueden leer los atributos de los certificados (Subject, SAN u OID personalizados) y utilizarlos para asignar dispositivos a VLAN de forma dinámica. Una tableta del servicio de limpieza con un certificado emitido a partir de la plantilla HousekeepingDevices se asigna a la VLAN de limpieza. Un terminal de punto de venta (POS) con un certificado de la plantilla RetailPOS se asigna a la VLAN dentro del alcance de PCI. Se trata de una segmentación de red aplicada criptográficamente, mucho más fiable que los enfoques basados en SSID o en direcciones MAC.
Para los operadores de hostelería que ofrecen WiFi para invitados junto con WiFi para el personal en la misma infraestructura física, la asignación de VLAN mediante atributos de certificado garantiza que los invitados y el personal estén siempre en segmentos de red separados, independientemente del SSID al que se conecte un dispositivo.
Resolución de problemas y mitigación de riesgos
El perfil de WiFi muestra 'Error' o 'No aplicable' en Intune
Causa raíz: Discrepancia en la asignación de grupos. El perfil SCEP está asignado a un grupo diferente al del perfil de WiFi. Intune no puede resolver la dependencia del certificado.
Solución: Audite los tres perfiles (Raíz de confianza, SCEP, WiFi). Asegúrese de que todos estén asignados exactamente al mismo grupo de Azure AD. Si va a realizar el despliegue para Usuarios, los tres perfiles deben dirigirse a un grupo de Usuarios. Si lo hace para Dispositivos, los tres deben dirigirse a un grupo de Dispositivos.
NDES devuelve errores HTTP 403
Causa raíz: La cuenta de servicio de Intune Certificate Connector carece de permisos de lectura o inscripción (Read o Enroll) en la plantilla de certificado de la CA, o el filtrado de URL del cortafuegos está bloqueando las cadenas de consulta SCEP.
Solución: Verifique que la cuenta del conector tenga permisos de lectura e inscripción (Read y Enroll) en la plantilla dentro de la consola de la CA. Revise los registros del cortafuegos en busca de solicitudes bloqueadas que contengan ?operation=GetCACaps o ?operation=PKIOperation. Estas cadenas de consulta deben pasar sin modificaciones.
Los dispositivos no renuevan los certificados antes de su vencimiento
Causa raíz: El margen de renovación de SCEP es demasiado corto o el servidor NDES no está accesible en el momento de la renovación.
Solución: Establezca el umbral de renovación en el 20 % de la validez del certificado. Asegúrese de que la URL de NDES se publique a través de un proxy inverso de alta disponibilidad. Supervise los registros de IIS de NDES para detectar fallos en las solicitudes de renovación y genere alertas de forma proactiva.
RADIUS rechaza certificados válidos
Causa raíz: El almacén de CA de confianza del servidor RADIUS no incluye el certificado de la CA emisora, o la CRL está desactualizada.
Solución: Importe la cadena de CA completa (CA raíz + CA emisora) en el almacén de confianza del servidor RADIUS. Verifique que la CRL se esté recuperando correctamente y que la URL de CDP sea accesible desde el servidor RADIUS. Compruebe la marca de tiempo de la próxima actualización de la CRL; si ya ha pasado, la CA debe publicar una nueva CRL.
Para conocer consideraciones más amplias sobre el rendimiento de la red junto con la seguridad, consulte nuestra guía de gestión de ancho de banda .
ROI e impacto empresarial
El caso de negocio para el registro de certificados basado en SCEP es sencillo. El acceso WiFi basado en contraseñas genera un volumen predecible de incidencias de soporte técnico: caducidad de contraseñas, bloqueos de cuentas, personal que comparte credenciales con invitados y dificultades de incorporación para los nuevos empleados. La autenticación basada en certificados es invisible para el usuario final. Los dispositivos se conectan automáticamente. No hay contraseñas que caduquen, se compartan o se olviden.
Las organizaciones que migran de un acceso WiFi basado en contraseñas a EAP-TLS con SCEP suelen registrar una reducción del 70-80 % en las incidencias de soporte técnico relacionadas con el WiFi (datos internos de Purple, 2024, basados en despliegues en sectores de hostelería y comercio minorista). El ahorro en soporte técnico por sí solo suele justificar el coste de implementación durante el primer año.
El impacto en el cumplimiento normativo es igualmente tangible. EAP-TLS cumple con el requisito 8.6 de PCI DSS 4.0 para la autenticación multifactor en la capa de red. Para entornos de sanidad , se alinea con los requisitos de salvaguarda técnica de HIPAA para el acceso a redes inalámbricas. Para las organizaciones del sector público, respalda los requisitos de certificación NCSC Cyber Essentials Plus para el control de acceso a la red.
Para los operadores de transporte (concesiones ferroviarias, operadores aeroportuarios, redes de autobuses), la autenticación basada en certificados en los dispositivos del personal garantiza que las redes operativas que transmiten datos críticos para la seguridad estén aisladas del WiFi para pasajeros y protegidas contra ataques basados en credenciales.
La plataforma WiFi Analytics de Purple se integra con redes protegidas por 802.1X para ofrecer información de datos de origen (first-party data) sin comprometer la seguridad de la infraestructura subyacente. Los 29 000 millones de puntos de datos recopilados en la red de Purple demuestran que la seguridad y la analítica son objetivos complementarios, no contrapuestos.
Para la gestión de comentarios y experiencias junto con el despliegue de su red segura, consulte nuestro manual de recopilación de comentarios en establecimientos .
Definiciones clave
SCEP (Simple Certificate Enrollment Protocol)
Un protocolo estandarizado por el IETF (RFC 8894) que automatiza el registro de certificados X.509 para dispositivos gestionados. El dispositivo genera su propia clave privada localmente y envía únicamente una solicitud de firma de certificado (CSR) a la CA a través de una pasarela. La clave privada nunca sale del dispositivo.
Los equipos de TI se encuentran con SCEP al configurar plataformas MDM (Intune, Jamf) para desplegar certificados de autenticación WiFi a escala. Es el mecanismo recomendado para despliegues de 802.1X EAP-TLS porque la clave privada está protegida por hardware en el dispositivo final.
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
El método de autenticación 802.1X más seguro. Tanto el dispositivo cliente como el servidor RADIUS presentan certificados X.509. Ninguna de las partes puede autenticarse sin un certificado válido y no revocado de la jerarquía de CA de confianza.
EAP-TLS es el protocolo de autenticación de destino que habilita el despliegue de certificados SCEP. Cumple con el requisito 8.6 de PCI DSS 4.0 y es obligatorio para despliegues de WPA3 Enterprise de 192 bits (Suite B).
PKCS (Public Key Cryptography Standards)
Un mecanismo de entrega de certificados en el que la CA genera de forma centralizada el par de claves pública y privada y las transmite al dispositivo final. La CA conserva una copia de la clave privada, lo que permite el depósito de claves.
Los equipos de TI eligen entre SCEP y PKCS al configurar perfiles de certificado en Intune. PKCS es adecuado para el cifrado de correo electrónico S/MIME donde se requiere el depósito de claves. No se recomienda para la autenticación WiFi porque la clave privada se transmite a través de la red.
NDES (Network Device Enrollment Service)
Un rol de Microsoft Windows Server que actúa como pasarela SCEP entre una plataforma MDM y una autoridad de certificación (CA). Valida las solicitudes de registro de dispositivos y reenvía las CSR a la CA.
NDES es un componente de infraestructura obligatorio para despliegues locales de SCEP con Microsoft Intune. Debe publicarse externamente a través de un proxy de aplicaciones para permitir el registro de dispositivos remotos. Las pasarelas SCEP en la nube son una alternativa que elimina la dependencia de NDES local.
CRL (Certificate Revocation List)
Una lista publicada por la CA que contiene los números de serie de los certificados que han sido revocados antes de su fecha de caducidad. Los servidores RADIUS verifican la CRL para garantizar que los dispositivos con certificados revocados no puedan autenticarse.
La verificación de CRL es el control operativo que aplica la revocación de certificados. Los equipos de TI deben configurar su servidor RADIUS para verificar la CRL en cada intento de autenticación y garantizar que el punto de distribución de CRL (CDP) sea de alta disponibilidad.
802.1X
Un estándar IEEE para el control de acceso a la red basado en puertos. Define el marco de autenticación de tres partes (suplicante, autenticador, servidor de autenticación) utilizado en redes cableadas y WiFi empresariales.
802.1X es el marco dentro del cual operan EAP-TLS y SCEP. Los equipos de TI se lo encuentran al configurar SSIDs WPA2-Enterprise o WPA3-Enterprise y al establecer políticas de servidor RADIUS.
RADIUS (Remote Authentication Dial-In User Service)
Un protocolo de red que proporciona autenticación, autorización y contabilidad (AAA) centralizadas para el acceso a la red. En despliegues de 802.1X, el servidor RADIUS valida los certificados de cliente y aplica las políticas de asignación de VLAN.
El servidor RADIUS es el punto de decisión de autenticación en cada despliegue de 802.1X. Las implementaciones comunes incluyen Microsoft NPS, FreeRADIUS y Cisco ISE. Debe configurarse con la cadena de CA de confianza y una verificación estricta de CRL u OCSP.
CSR (Certificate Signing Request)
Un bloque de texto codificado generado por un dispositivo que contiene la clave pública y la información de identidad del dispositivo. El dispositivo envía la CSR a la CA (a través de la pasarela SCEP) para solicitar un certificado firmado. La clave privada correspondiente se genera y se conserva en el dispositivo.
La CSR es el elemento central en el flujo de registro de SCEP. Los equipos de TI configuran el formato de la CSR (nombre del sujeto, uso de clave, EKU) en el perfil de certificado SCEP dentro de su plataforma MDM.
PKI (Public Key Infrastructure)
La combinación de hardware, software, políticas y procedimientos necesarios para crear, gestionar, distribuir y revocar certificados digitales. Una PKI empresarial estándar consta de una CA raíz fuera de línea (offline) y una CA emisora en línea (online).
La PKI es el requisito previo para cualquier despliegue de EAP-TLS. Los equipos de TI deben diseñar y desplegar una jerarquía de CA de dos niveles antes de configurar SCEP. Los servicios de PKI alojados en la nube reducen la carga de infraestructura para despliegues en entornos distribuidos.
VLAN (Virtual Local Area Network)
Un segmento de red lógico que aísla el tráfico en la Capa 2. En despliegues de 802.1X, los servidores RADIUS asignan dispositivos a las VLAN de forma dinámica en función de los atributos del certificado, la identidad del usuario o la política.
La asignación de VLAN a través de RADIUS es el mecanismo que aplica la segmentación de red en el WiFi empresarial. Los equipos de TI lo utilizan para separar los dispositivos TPV en VLAN dentro del alcance de PCI, los dispositivos de invitados en VLAN solo de internet y los dispositivos del personal en VLAN corporativas, todo desde una única infraestructura física.
Ejemplos prácticos
Un hotel Premier Inn de 200 habitaciones necesita desplegar un WiFi seguro para 150 dispositivos iOS del personal de limpieza. Actualmente, el personal comparte una contraseña WPA2-Personal con los huéspedes, lo que genera un riesgo operativo y de cumplimiento. El director de TI necesita eliminar la contraseña compartida sin interrumpir las operaciones diarias.
El director de TI implementa un despliegue de SCEP gestionado por Jamf en tres fases. Primera fase: el certificado de la CA raíz se distribuye a los 150 dispositivos iOS a través de un perfil de certificado de confianza de Jamf, dirigido al grupo inteligente 'Housekeeping Devices'. Segunda fase: se despliega un perfil de certificado SCEP que dirige los dispositivos a un servidor NDES publicado mediante Azure AD App Proxy. El nombre del sujeto utiliza CN={{SERIALNUMBER}} para vincular el certificado al hardware del dispositivo. Tercera fase: se distribuye un perfil de WiFi WPA2-Enterprise, especificando EAP-TLS y vinculándolo al certificado SCEP. Los dispositivos se autentican de forma silenciosa. Se retira el SSID con contraseña compartida. El servidor RADIUS se configura con una verificación estricta de CRL y asignación de VLAN: los dispositivos de limpieza se asignan a la VLAN 20 (operaciones) y los dispositivos de invitados a la VLAN 10 (solo internet).
Una cadena de tiendas con 500 ubicaciones necesita proteger el WiFi corporativo para tabletas TPV con Windows que ejecutan software de procesamiento de pagos. El cumplimiento de PCI DSS 4.0 requiere autenticación multifactor en la capa de red. La configuración actual de WPA2-Personal no supera la evaluación del requisito 8.6 de PCI DSS.
El arquitecto de red despliega EAP-TLS a través de Microsoft Intune y SCEP en las 500 ubicaciones. El despliegue utiliza certificados de dispositivo con CN={{AAD_Device_ID}} como nombre del sujeto, vinculando cada certificado al registro del dispositivo en Intune. La secuencia de tres perfiles (raíz de confianza, SCEP, WiFi) se despliega en el grupo de Azure AD 'POS Devices', el mismo grupo para los tres perfiles. El servidor RADIUS asigna los dispositivos TPV a una VLAN dedicada dentro del alcance de PCI (VLAN 100) según la plantilla de emisión del certificado. La CRL se publica en un endpoint de alta disponibilidad alojado en CDN con una ventana de validez de cuatro horas. Se habilita OCSP para la verificación de revocación en tiempo real. El QSA valida el despliegue frente al requisito 8.6 de PCI DSS 4.0.
Preguntas de práctica
Q1. Ha desplegado perfiles de certificado de raíz de confianza y SCEP en el grupo de usuarios 'All Staff' en Intune. A continuación, despliega el perfil de WiFi en el grupo de dispositivos 'Corporate Devices'. Los dispositivos reciben los certificados, pero el perfil de WiFi muestra 'Error' en la consola de Intune. ¿Cuál es la causa más probable y cómo lo soluciona?
Sugerencia: Considere cómo resuelve Intune las dependencias entre perfiles y qué sucede cuando los perfiles se dirigen a diferentes tipos de grupos.
Ver respuesta modelo
La causa principal es una discrepancia en la asignación de grupos. El perfil de WiFi depende del perfil SCEP, que a su vez depende del perfil de raíz de confianza. Intune no puede resolver estas dependencias cuando los perfiles se dirigen a diferentes tipos de grupos (usuarios frente a dispositivos). Solución: vuelva a desplegar los tres perfiles en el mismo grupo. Si el perfil de WiFi se dirige a 'Corporate Devices' (un grupo de dispositivos), los perfiles SCEP y de raíz de confianza también deben dirigirse a 'Corporate Devices'. Alternativamente, mueva los tres a un grupo de usuarios si se requiere autenticación basada en el usuario.
Q2. Se denuncia el robo del iPad de un miembro del personal de limpieza de un hotel. Desactiva inmediatamente la cuenta de Active Directory de dicho empleado. A la mañana siguiente, el iPad robado sigue conectándose a la red WPA2-Enterprise del hotel. ¿Por qué ocurre esto y qué dos acciones debe realizar para evitarlo?
Sugerencia: Pense en lo que realmente valida el servidor RADIUS durante la autenticación EAP-TLS y qué controles rigen la validez del certificado.
Ver respuesta modelo
Desactivar la cuenta de AD no revoca el certificado de cliente almacenado en el iPad. El servidor RADIUS valida el certificado, no el estado de la cuenta de AD, durante la autenticación EAP-TLS. Las dos acciones requeridas son: (1) revocar el certificado del dispositivo en la CA (esto añade el número de serie del certificado a la CRL); (2) asegurarse de que el servidor RADIUS esté configurado con una verificación estricta de CRL para que obtenga la CRL actualizada y rechace el certificado revocado en el siguiente intento de autenticación. Para una revocación más rápida, configure OCSP en el servidor RADIUS para realizar comprobaciones del estado del certificado en tiempo real.
Q3. Una cadena de tiendas está desplegando WiFi 802.1X en 500 ubicaciones de TPV. El arquitecto de seguridad propone utilizar la entrega de certificados PKCS en lugar de SCEP para evitar el despliegue de un servidor NDES. El QSA que revisa la evaluación de PCI DSS 4.0 plantea una objeción. ¿Cuál es la objeción y cuál es la recomendación correcta?
Sugerencia: Considere lo que dice PCI DSS sobre el manejo de claves privadas y lo que hace PKCS con la clave privada durante la entrega.
Ver respuesta modelo
La preocupación del QSA es que PKCS transmite la clave privada a través de la red desde la CA al dispositivo. El requisito 3.5 de PCI DSS 4.0 exige que las claves privadas utilizadas para la autenticación estén protegidas contra la divulgación. Transmitir la clave privada a través de la red, incluso cifrada, introduce un riesgo que SCEP elimina por completo. La recomendación correcta es utilizar SCEP, donde la clave privada se genera en el dispositivo TPV y nunca sale de él. Para evitar la infraestructura NDES local, el arquitecto debería evaluar un servicio de pasarela SCEP en la nube que se integre directamente con Intune y la CA a través de una API.
Q4. Está diseñando una red WiFi para un gran centro de conferencias que alberga más de 50 eventos al año. Los dispositivos del personal deben estar en una red 802.1X segura. Quiere asegurarse de que si el dispositivo de un contratista se ve comprometido, pueda aislarse de la red en un plazo de 15 minutos. ¿Qué mecanismo de revocación de certificados configura y por qué?
Sugerencia: Compare CRL y OCSP en términos de latencia de revocación y qué determina la rapidez con la que un servidor RADIUS actúa ante una revocación.
Ver respuesta modelo
Configure OCSP (Online Certificate Status Protocol) en el servidor RADIUS. La revocación basada en CRL tiene una latencia determinada por el período de validez de la CRL (normalmente de una a 24 horas), lo que significa que un certificado revocado aún podría autenticarse hasta que el servidor RADIUS obtenga la siguiente CRL. OCSP proporciona respuestas de estado por certificado en tiempo real: cuando se revoca un certificado en la CA, el respondedor OCSP devuelve inmediatamente un estado de 'revocado' en la siguiente consulta. Con OCSP configurado en el servidor RADIUS, el certificado revocado de un contratista se bloquea en el siguiente intento de autenticación, normalmente en cuestión de segundos. Asegúrese de que el respondedor OCSP sea de alta disponibilidad: si no está accesible y el servidor RADIUS está configurado para denegar el acceso en caso de fallo (fail closed), todas las autenticaciones fallarán.
Continúe leyendo esta serie
Cómo configurar un Captive Portal en Starlink: guía para establecimientos remotos y marítimos
Esta guía detalla cómo omitir el hardware nativo de Starlink e integrar un Captive Portal gestionado en la nube utilizando equipos de enrutamiento empresariales. Aprenderá a superar la limitación de CGNAT, aplicar la segmentación de VLAN, gestionar las limitaciones de ancho de banda satelital y garantizar el cumplimiento normativo.
Hotel Guest WiFi Management: Integrating PMS, Portals, and Brand Standards
Esta guía técnica detalla cómo diseñar redes WiFi hoteleras de nivel empresarial, centrándose en la segmentación de VLAN, la integración de PMS para la gestión automatizada de sesiones y la optimización del Captive Portal para la captura de datos de conformidad con el GDPR.
Cómo optimizar los captive portals para una máxima seguridad de red y conversión de usuarios
Esta guía proporciona un esquema técnico completo para optimizar los captive portals en entornos empresariales, abarcando la arquitectura de segmentación de red, la selección del método de autenticación, el diseño de consentimiento conforme a la GDPR y la optimización de la conversión. Está dirigida a responsables de TI, arquitectos de red y CTO de hoteles, cadenas de tiendas, estadios y organizaciones del sector público que necesitan equilibrar la seguridad de la red con la captura de datos de primera mano. Purple opera la infraestructura de captive portals en más de 80.000 establecimientos con 440 millones de inicios de sesión en 2024, y los marcos de trabajo aquí presentados reflejan esa experiencia operativa.