Saltar al contenido principal

El papel de SCEP y NAC en la infraestructura moderna de MDM

Esta guía ofrece un desglose técnico detallado de cómo SCEP y NAC se integran con las plataformas MDM para ofrecer un acceso a la red seguro y sin intervención (zero-touch) a escala empresarial. Abarca toda la arquitectura, desde la emisión de certificados hasta la aplicación de 802.1X, con escenarios de implementación reales del sector de la hostelería y el comercio minorista. Diseñado para responsables de TI en grandes recintos que necesitan eliminar las vulnerabilidades de las contraseñas, automatizar el aprovisionamiento de dispositivos y cumplir con los requisitos de conformidad en este trimestre.

📖 7 min de lectura📝 1,710 palabras🔧 2 ejemplos prácticos3 preguntas de práctica📚 9 definiciones clave

Escuchar esta guía

Ver transcripción del podcast
Bienvenido al boletín técnico de Purple. Soy su anfitrión y hoy profundizaremos en un tema de arquitectura crítico para las redes empresariales: el papel de SCEP y NAC en la infraestructura MDM moderna. Si es director de TI, arquitecto de redes o gestiona operaciones en un gran recinto (ya sea un estadio, un hospital o una cadena de tiendas), conoce de primera mano el dolor de cabeza que supone incorporar dispositivos de forma segura. Los días de las claves precompartidas han terminado. Hoy hablaremos de la autenticación basada en certificados. Exploraremos cómo el Protocolo de Inscripción de Certificados Simple, o SCEP, se asocia con el Control de Acceso a la Red, o NAC, para automatizar el aprovisionamiento de dispositivos y aplicar el acceso zero-trust. Entremos de lleno en materia. Analicemos la arquitectura. En el núcleo, tenemos tres capas: la capa de dispositivo, el motor de políticas y la capa de acceso a la red. Cuando un nuevo dispositivo corporativo o un endpoint BYOD necesita acceso, primero se registra en su plataforma de Mobile Device Management. Pero el MDM por sí solo no otorga acceso a la red. Ahí es donde entra SCEP. SCEP actúa como el mensajero automatizado entre su MDM y su Autoridad de Certificación. En lugar de que un administrador de TI genere e instale manualmente un certificado X.509 en cada dispositivo, el MDM envía un payload al dispositivo. El dispositivo genera una Solicitud de Firma de Certificado, o CSR, y la envía al servidor SCEP. La CA emite el certificado y el dispositivo cuenta ahora con una identidad criptográficamente segura. Sin contraseñas que puedan ser objeto de phishing ni claves compartidas que puedan filtrarse. Pero un certificado es solo una tarjeta de identificación. Sigue necesitando un portero en la puerta. Ese es su NAC. Cuando el dispositivo intenta conectarse a la WiFi (normalmente mediante 802.1X EAP-TLS), el punto de acceso inalámbrico pasa la solicitud al servidor RADIUS, que está gobernado por el motor de políticas del NAC. El NAC comprueba el certificado: ¿es válido?, ¿ha sido revocado? Pero el NAC moderno va más allá. Comprueba el estado en el MDM: ¿está actualizado el sistema operativo?, ¿está activado el cortafuegos? En caso afirmativo, el NAC indica al conmutador o punto de acceso que coloque el dispositivo en la VLAN correcta. En caso negativo, los desvía a una red de remediación. Esta integración es fundamental para entornos como grandes cadenas de tiendas o centros sanitarios donde coexiste una mezcla de portátiles corporativos, dispositivos IoT y redes de invitados. Hablando de redes de invitados, aquí es donde las plataformas como Guest WiFi y WiFi Analytics de Purple se integran a la perfección junto a sus SSID corporativos seguros, garantizando que el acceso público esté aislado de su infraestructura segura respaldada por certificados. Entonces, ¿cómo desplegar esto sin alterar su red? Primera recomendación: utilice siempre EAP-TLS. Requiere certificados tanto en el servidor como en el cliente, lo que proporciona una autenticación mutua. En segundo lugar, preste atención a sus Listas de Revocación de Certificados, o CRL, y a OCSP. Si un dispositivo se ve comprometido o un empleado se marcha, revocar el certificado en la CA no sirve de nada si el NAC no está comprobando el estado de revocación en tiempo real. Un error común que vemos en el sector de la hostelería y en grandes recintos es no tener en cuenta los dispositivos IoT. No todos los sensores IoT o smart TVs son compatibles con 802.1X o SCEP. Para estos, necesitará una estrategia de contingencia como MAC Authentication Bypass, o MAB, estrechamente controlada por su NAC para puertos de conmutador específicos o VLANs aisladas. Otro error tiene que ver con los periodos de validez de los certificados. No los configure para 10 años, pero tampoco para 30 días, a menos que su renovación automatizada a través de SCEP sea infalible. Una validez de un año con autorenovación a los 30 días es un estándar sólido en la industria. Respondamos rápidamente a un par de preguntas que solemos recibir de los CTO. Pregunta uno: ¿Podemos usar nuestro Active Directory Certificate Services existente para SCEP? Sí, Microsoft AD CS incluye un rol de Network Device Enrollment Service, o NDES, que actúa como servidor SCEP. Solo asegúrese de que esté debidamente protegido y expuesto a su MDM. Pregunta dos: ¿Esto reemplaza a nuestro firewall? En absoluto. SCEP y el NAC gestionan la autenticación y el control de acceso en el extremo - Capa 2. Su firewall gestiona la inspección del tráfico y la prevención de amenazas en las Capas 3 a 7. Trabajan juntos. Para resumir, combinar SCEP, NAC y MDM le proporciona un extremo de red altamente seguro y sin intervención (zero-touch). Elimina las incidencias de soporte técnico relacionadas con las contraseñas y garantiza que solo los dispositivos conformes accedan a su infraestructura crítica. Para los operadores de recintos, esto significa que sus operaciones internas funcionan de forma segura, lo que le permite centrarse en la experiencia de cara al público, la cual puede potenciar con las herramientas de análisis y engagement de Purple. Comience por auditar sus capacidades de MDM actuales y asegurarse de que su infraestructura RADIUS sea compatible con EAP-TLS. Planifique sus tipos de dispositivos y realice primero un piloto con los dispositivos del equipo de TI. Gracias por sintonizar este informe técnico. Manténgase seguro y nos vemos en el próximo.

header_image.png

Resumen Ejecutivo

Para los recintos empresariales - desde estadios con capacidad para 80 000 personas hasta cadenas de tiendas con múltiples ubicaciones -, la seguridad en el extremo de la red ha superado definitivamente el uso de claves precompartidas y la gestión manual de credenciales. La proliferación de terminales corporativos, dispositivos BYOD e infraestructura IoT exige una arquitectura zero-trust que sea escalable sin sobrecargar al equipo de soporte de TI.

Esta guía detalla la arquitectura técnica para integrar el Simple Certificate Enrolment Protocol (SCEP) y el control de acceso a la red (NAC) con la infraestructura de gestión de dispositivos móviles (MDM). Al aprovechar SCEP para automatizar la distribución de certificados X.509 y NAC para aplicar la autenticación EAP-TLS de IEEE 802.1X, las organizaciones pueden lograr un aprovisionamiento sin intervención, eliminar las vías de robo de credenciales y aplicar un acceso a la red dinámico y basado en el estado del dispositivo. Mientras que el acceso de cara al público se gestiona a través de una solución de WiFi para invitados dedicada, esta arquitectura protege las operaciones críticas internas que mantienen el recinto en funcionamiento. El resultado es una reducción drástica de los costes indirectos de TI, un mayor cumplimiento de PCI-DSS y GDPR, y la aplicación proactiva de principios zero-trust en el extremo de la red.


Análisis Técnico Detallado

La Arquitectura de Tres Capas

La seguridad de red moderna se basa en la identidad criptográfica en lugar del conocimiento del usuario. El stack SCEP-NAC-MDM opera en tres capas principales:

Capa Componentes Función
Gestión de dispositivos MDM / UEM Autoridad central para la configuración, el cumplimiento y el ciclo de vida de los dispositivos
Identidad y emisión PKI / SCEP / CA Genera, emite y gestiona certificados digitales
Aplicación del acceso NAC / RADIUS Evalúa los certificados y el estado del dispositivo antes de conceder el acceso a la red

Estas capas no son secuenciales: operan en un bucle de retroalimentación continuo. El MDM informa al NAC sobre el estado de cumplimiento en tiempo real, mientras que el NAC puede activar flujos de trabajo de corrección en el MDM cuando un dispositivo no supera una comprobación de estado.

architecture_overview.png

Cómo SCEP Automatiza la PKI a Escala

El despliegue manual de certificados es operativamente imposible a gran escala. Un parque de 500 dispositivos requeriría que un administrador de TI generara, firmara e instalara un certificado X.509 individual en cada dispositivo, un proceso que lleva varios minutos por dispositivo e introduce un riesgo significativo de error humano. SCEP elimina esto por completo.

Cuando un dispositivo se registra en el MDM, este envía un perfil de configuración que contiene una carga útil de SCEP. La carga útil indica al dispositivo que genere un par de claves localmente (lo cual es crucial, ya que la clave privada nunca sale del dispositivo) y que envíe una Solicitud de Firma de Certificado (CSR) al servidor SCEP. El servidor SCEP (normalmente el Servicio de Registro de Dispositivos de Red (NDES) de Microsoft o un equivalente basado en la nube) valida la solicitud con el MDM para confirmar que el dispositivo está autorizado. A continuación, reenvía la CSR a la Entidad de Certificación (CA), que emite el certificado X.509 firmado. El certificado se devuelve al dispositivo y se instala en su enclave seguro o en el almacén de claves del sistema.

Todo el proceso se realiza de forma silenciosa, de forma inalámbrica y sin interacción del usuario. Para un despliegue de 1.000 dispositivos, todo el conjunto de certificados se puede aprovisionar a las pocas horas de completarse el registro en el MDM.

NAC y 802.1X EAP-TLS: la capa de aplicación

Una vez que un dispositivo dispone de un certificado válido, intenta conectarse al SSID corporativo o al puerto cableado mediante IEEE 802.1X. El punto de acceso o switch actúa como autenticador, reenviando la solicitud a un servidor RADIUS regido por el motor de políticas de NAC. El método EAP más seguro es EAP-TLS, que requiere autenticación mutua: tanto el cliente como el servidor RADIUS deben presentar certificados válidos, lo que evita ataques de intermediario a través de puntos de acceso fraudulentos. El NAC realiza varias comprobaciones críticas en secuencia:

  1. Validación criptográfica: ¿Es el certificado matemáticamente válido y está firmado por una CA raíz de confianza?
  2. Comprobación de revocación: ¿Figura el certificado en una Lista de Revocación de Certificados (CRL) o está marcado mediante el Protocolo de Estado de Certificados en Línea (OCSP)?
  3. Evaluación de la postura: Consultando al MDM a través de una API, el NAC pregunta: ¿Cumple el dispositivo con las normativas? ¿Tiene el sistema operativo el nivel de parches necesario? ¿Está activado el cifrado de disco?

Si se superan todas las comprobaciones, el NAC envía un mensaje RADIUS Access-Accept, que normalmente contiene atributos específicos del proveedor (VSA) que asignan dinámicamente el dispositivo a una VLAN específica o aplican listas de control de acceso (ACL). Los dispositivos que no cumplen con los requisitos se colocan en una VLAN de remediación con permisos limitados, que normalmente solo bastan para activar los flujos de trabajo de remediación gestionados por el MDM.

scep_nac_workflow.png

Segregación de la red de invitados

En cualquier entorno de espacio físico, la infraestructura corporativa debe estar estrictamente segregada de las redes orientadas al público. La plataforma de Guest WiFi opera completamente en SSIDs y VLANs independientes, sin ruta de enrutamiento hacia los recursos corporativos. La arquitectura SCEP-NAC gobierna el nivel corporativo; el nivel de invitados se controla mediante la autenticación de Captive Portal y los flujos de trabajo de captura de datos. Para los espacios que despliegan WiFi Analytics , esta segregación es un requisito previo: los datos de analítica fluyen a través de la red de invitados, mientras que los datos operativos fluyen a través de la red corporativa autenticada por certificado. Para obtener más información sobre la arquitectura de RF subyacente que soporta ambas redes, consulte Wi-Fi Frequencies: A 2026 Guide to Wi-Fi Frequencies .


Guía de implementación

El despliegue de esta arquitectura requiere una secuenciación cuidadosa para evitar bloquear a los usuarios legítimos durante la transición.

Paso 1: Preparación de PKI y SCEP

Establezca una PKI interna sólida o aproveche un servicio de PKI gestionada en la nube (mPKI). Despliegue y fortalezca el servidor SCEP; si utiliza Microsoft NDES, asegúrese de que se ejecute en un servidor dedicado en lugar de estar coubicado con la CA. Configure el servidor SCEP para utilizar contraseñas de desafío dinámicas generadas por dispositivo por el MDM, en lugar de un secreto compartido estático. Esto evita solicitudes de certificados no autorizadas si se descubre la URL de SCEP.

Paso 2: Configuración del MDM

Cree la carga útil de SCEP en su plataforma de MDM. Defina los campos de nombre alternativo del sujeto (SAN) con cuidado; el SAN debe contener identificadores únicos (como el número de serie del dispositivo o el UPN del usuario) que el NAC utilizará para las decisiones de políticas. Envíe el perfil a un grupo piloto de dispositivos del equipo de TI en primer lugar y valide todo el flujo de inscripción antes de realizar un despliegue más amplio.

Paso 3: Configuración de NAC y RADIUS

Configure su NAC para confiar en la CA raíz que emitió los certificados de cliente. Instale un certificado de servidor en el servidor RADIUS para la autenticación mutua EAP-TLS. Defina políticas de acceso basadas en los atributos del certificado y el estado de cumplimiento del MDM. Implemente reglas de asignación dinámica de VLAN: dispositivos corporativos conformes a la VLAN corporativa, dispositivos no conformes a la VLAN de remediación y dispositivos IoT a una VLAN dedicada con acceso restringido a internet.

Paso 4: Integración de la infraestructura de red

Configure los switches y los puntos de acceso inalámbrico para 802.1X. Para escenarios con hardware de punto de venta heredado en entornos de retail , o controladores de habitaciones inteligentes en espacios de hospitality , implemente la derivación de autenticación MAC (MAB) como alternativa para los dispositivos que no pueden participar en EAP-TLS. Restrinja MAB a puertos de switch específicos y asegúrese de que la base de datos de direcciones MAC esté estrictamente controlada. Para entornos de healthcare y transport , configure reglas de evaluación de postura para cumplir con los requisitos de cumplimiento específicos del sector.

Paso 5: Despliegue paralelo y transición

Nunca realice el cambio de forma inmediata. Difunda el nuevo SSID 802.1X en paralelo con la red existente. Distribuya el nuevo perfil de WiFi a través del MDM. Supervise la adopción y resuelva los fallos de inscripción. Una vez que más del 95 % de los dispositivos se autentiquen correctamente en el nuevo SSID, desmantele la red heredada.


Buenas prácticas

Exija EAP-TLS. Nunca acepte EAP-PEAP o EAP-TTLS como método de autenticación principal para dispositivos corporativos. Estos métodos dependen de credenciales de usuario/contraseña dentro de un túnel TLS y siguen siendo vulnerables a la recopilación de credenciales. EAP-TLS elimina por completo esa superficie de ataque.

Implemente la revocación en tiempo real. Las descargas programadas de CRL crean ventanas de exposición. Configure el NAC para realizar comprobaciones OCSP en tiempo real. Cuando se informe de la pérdida o el robo de un dispositivo, revoque el certificado en la CA y el dispositivo perderá el acceso a la red en su próximo intento de autenticación - o de forma inmediata, si se implementa el cambio de autorización (CoA).

Establezca periodos de validez de certificados razonables. El estándar del sector es un periodo de validez de un año, con una renovación automática SCEP activada 30 días antes del vencimiento. Una validez más larga aumenta la ventana de exposición si un certificado se ve comprometido; una validez más corta incrementa el riesgo de que los fallos de renovación causen interrupciones del servicio.

Segregue de forma estricta el IoT. Los dispositivos IoT nunca deben compartir una VLAN con los endpoints corporativos. Utilice el NAC para aplicar ACL estrictas en la VLAN de IoT, permitiendo únicamente los protocolos y destinos específicos que requiere cada clase de dispositivo. Para las instalaciones que implementan servicios de localización, consulte Sistemas de posicionamiento WiFi en interiores: cómo funcionan y cómo desplegarlos para saber cómo se integra la infraestructura de posicionamiento con la arquitectura de red más amplia.

Alinee con WPA3. Siempre que el hardware lo admita, configure los SSID corporativos para utilizar WPA3-Enterprise, que exige marcos de gestión protegidos (PMF) y proporciona una protección criptográfica más sólida que WPA2. Para obtener más información sobre cómo encaja esto en el panorama de la conectividad empresarial global, consulte SD-WAN frente a MPLS: guía de redes corporativas para 2026 .


Resolución de problemas y mitigación de riesgos

Modo de fallo Causa raíz Mitigación
Los dispositivos fallan en EAP-TLS tras la renovación del certificado La renovación SCEP falla de forma silenciosa Supervise los registros del servidor SCEP; configure alertas para envíos de CSR fallidos
La validación del certificado falla debido a un desajuste del reloj Configuración incorrecta de NTP Imponga la sincronización NTP en todos los endpoints e infraestructura
Los dispositivos IoT no pueden autenticarse No disponen de suplicante 802.1X Implemente MAB con controles estrictos de direcciones MAC y una VLAN aislada
Bloqueo masivo de dispositivos tras la migración de la CA El NAC no confía en la CA raíz heredada Planifique las migraciones de CA por etapas; añada la nueva CA raíz al almacén de confianza del NAC antes de revocar la antigua
Los dispositivos revocados conservan el acceso a la red Revocación solo por CRL con intervalos de descarga largos Implemente OCSP y CoA para una revocación en tiempo real

Para dispositivos IoT específicos basados en BLE, la arquitectura de autenticación difiere de la de los terminales conectados a WiFi. Consulta BLE Low Energy explicado para empresas para conocer las consideraciones de seguridad específicas que se aplican a la infraestructura de Bluetooth Low Energy.


ROI e impacto empresarial

El caso de negocio para la integración de SCEP-NAC-MDM es sencillo cuando se compara con el coste de las alternativas.

Métrica Antes de la implementación Después de la implementación
Tickets de soporte de TI (acceso a la red) Alto - restablecimiento de contraseñas, rotación de claves Casi cero - ciclo de vida de certificados automatizado
Tiempo medio para revocar un dispositivo comprometido Horas (proceso manual) Segundos (OCSP + CoA)
Cumplimiento del control de acceso PCI DSS Manual, requiere auditorías constantes Automatizado, aplicado de forma continua
Tiempo de incorporación de BYOD 15 - 30 minutos por dispositivo Menos de 5 minutos sin intervención de TI

Para un parque de 500 dispositivos, eliminar la gestión manual de certificados y los tickets de soporte relacionados con contraseñas suele reducir los costes indirectos de soporte de TI de red entre un 25% y un 35%. El valor de la mitigación de riesgos - evitar una única brecha basada en credenciales - supera sistemáticamente el coste total de la implementación. Para las organizaciones sanitarias y del sector público sujetas al GDPR, la capacidad de demostrar un control de acceso automatizado y auditable es un activo de cumplimiento normativo significativo.

Definiciones clave

SCEP (Protocolo de Registro de Certificados Simple)

Un protocolo que automatiza la emisión y revocación de certificados digitales en los dispositivos sin intervención del usuario, actuando como la capa de comunicación entre la plataforma MDM y la Entidad de Certificación.

Utilizado por las plataformas MDM para desplegar sin problemas certificados X.509 a miles de terminales a escala. Los equipos de TI se encuentran con SCEP al configurar perfiles MDM para la autenticación WiFi 802.1X.

NAC (Control de Acceso a la Red)

Una solución de seguridad que aplica políticas a los dispositivos que intentan acceder a la infraestructura de red, evaluando las credenciales de autenticación, la validez de los certificados y el estado de conformidad del dispositivo antes de conceder el acceso.

Actúa como el guardián en el extremo de la red. Los equipos de TI configuran las políticas NAC para definir qué dispositivos acceden a qué VLANs en función de los atributos de sus certificados y de su estado de conformidad con el MDM.

MDM (Gestión de Dispositivos Móviles)

Software utilizado por los departamentos de TI para supervisar, gestionar y proteger los terminales de los empleados en múltiples sistemas operativos, sirviendo como la fuente de información central para la identidad y la conformidad de los dispositivos.

El iniciador del proceso de registro SCEP y la fuente de datos de estado consultados por el NAC. Sin la integración con MDM, el NAC no puede realizar un control de acceso basado en el estado del dispositivo.

IEEE 802.1X

Un estándar IEEE para el control de acceso a la red basado en puertos que proporciona un mecanismo de autenticación a los dispositivos que desean conectarse a una LAN o WLAN, requiriendo una autenticación correcta antes de abrir el puerto.

El protocolo subyacente que obliga a los dispositivos a autenticarse antes de que el conmutador o punto de acceso permita el paso de cualquier tráfico. Se configura tanto en la infraestructura de red como en el suplicante 802.1X del dispositivo.

EAP-TLS (Protocolo de Autenticación Extensible - Seguridad de la Capa de Transporte)

El estándar EAP más seguro, que requiere autenticación mutua donde tanto el dispositivo cliente como el servidor RADIUS deben presentar certificados digitales válidos, eliminando los ataques a las credenciales basados en contraseñas.

El estándar de oro para la seguridad inalámbrica empresarial. Los arquitectos de TI deben exigir EAP-TLS sobre PEAP o TTLS siempre que exista una infraestructura de certificados de dispositivo.

CSR (Solicitud de Firma de Certificado)

Un bloque de texto codificado generado por un dispositivo que contiene su clave pública y los datos de su identidad, que se envía a la Entidad de Certificación para solicitar un certificado X.509 firmado.

Generada automáticamente por el dispositivo durante el proceso de registro SCEP. La clave privada correspondiente a la CSR nunca sale del dispositivo, lo que garantiza que el certificado no se pueda duplicar.

MAB (Bypass de Autenticación MAC)

Un método de autenticación alternativo en el que la red utiliza la dirección MAC de hardware del dispositivo como su credencial, utilizado para dispositivos que carecen de la capacidad de suplicante 802.1X.

Utilizado para dispositivos IoT heredados, como impresoras, sensores y controladores de salas inteligentes que no pueden participar en EAP-TLS. Siempre debería dar lugar a la asignación a una VLAN muy restringida.

OCSP (Protocolo de Estado de Certificados en Línea)

Un protocolo de internet utilizado para obtener el estado de revocación de un certificado digital X.509 en tiempo real, proporcionando una alternativa a la descarga y análisis de las Listas de Revocación de Certificados.

Crítico para los sistemas NAC que necesitan bloquear inmediatamente el acceso a la red cuando un dispositivo está comprometido o se denuncia su robo. OCSP proporciona el estado en tiempo real; las descargas de CRL crean una ventana de revocación de tiempo.

CoA (Cambio de Autorización)

Una extensión de RADIUS (RFC 5176) que permite al NAC modificar o terminar dinámicamente una sesión de red activa sin esperar a que expire la sesión o a que el dispositivo se vuelva a autenticar.

Se utiliza para desconectar inmediatamente un dispositivo cuando se revoca su certificado o cambia su estado de conformidad con el MDM. Es esencial para la aplicación de zero-trust en tiempo real.

Ejemplos prácticos

Un complejo hotelero de lujo de 500 habitaciones necesita proteger su red de operaciones internas. El personal utiliza tabletas compartidas para la gestión del servicio de limpieza y la dirección utiliza portátiles corporativos. La red WPA2-PSK actual ha sufrido varias filtraciones de la clave previamente compartida, lo que ha provocado dos incidentes de seguridad en el último año. ¿Cómo debe el equipo de TI realizar la transición a la autenticación basada en certificados sin interrumpir las operaciones?

Fase 1 - Preparación (semanas 1 y 2): implementar una solución NAC/RADIUS basada en la nube e integrarla con el MDM existente. Configurar un perfil SCEP en el MDM para enviar certificados basados en el dispositivo a todas las tabletas y portátiles. Utilizar certificados basados en el dispositivo (vinculados al número de serie del dispositivo) en lugar de certificados basados en el usuario, de modo que las tabletas compartidas se autentiquen automáticamente independientemente de qué miembro del personal las esté utilizando. Fase 2 - Implementación paralela (semanas 3 y 4): emitir un nuevo SSID oculto configurado para 802.1X EAP-TLS. Enviar el nuevo perfil de WiFi a través de MDM a todos los dispositivos registrados. Supervisar el panel de control del NAC para comprobar que las autenticaciones se realizan correctamente. Fase 3 - Transición (semana 5): una vez que más del 95 % de los dispositivos estén conectados al nuevo SSID, retirar la red WPA2-PSK heredada. Revocar la PSK antigua de toda la documentación y de los puntos de acceso.

Comentario del examinador: El enfoque de certificados basados en el dispositivo es la opción correcta para entornos de dispositivos compartidos. Los certificados basados en el usuario requerirían que cada miembro del personal tuviera su propio certificado, lo que generaría unos costes de gestión que anularían las ventajas de la automatización. La estrategia de implementación paralela es fundamental: realizar la transición de inmediato bloquearía cualquier dispositivo en el que fallara el registro SCEP, lo que provocaría interrupciones operativas. El SSID oculto para la nueva red evita que los huéspedes intenten conectarse a la red corporativa durante el periodo de transición.

Una cadena nacional de tiendas minoristas va a implantar 3000 nuevos terminales de punto de venta en 150 tiendas. El equipo de seguridad exige una segmentación estricta de la red PCI-DSS y un acceso de confianza cero (zero-trust). El plazo de implantación es de 8 semanas. ¿Cómo facilitan esto SCEP y NAC a gran escala sin necesidad de personal de TI en cada tienda?

Antes de la implantación: el proveedor de los puntos de venta registra previamente los 3000 dispositivos en el MDM del minorista mediante el programa de registro zero-touch del proveedor. El MDM se configura con un perfil SCEP que se activará automáticamente al iniciarse por primera vez. Implantación: cuando se enciende un terminal de punto de venta en la tienda, se conecta a un SSID de incorporación temporal (solo internet, sin acceso corporativo). Se envía el perfil MDM, se activa la carga útil de SCEP y el dispositivo solicita y recibe su certificado X.509 de la entidad emisora de certificados. A continuación, el MDM envía el perfil de WiFi corporativo. Acceso a la red: cuando el punto de venta se conecta al puerto del switch de la tienda, el switch inicia 802.1X. El NAC valida el certificado, consulta al MDM para confirmar que el punto de venta cumple con las normativas (cifrado activado, agente MDM activo, sin detección de jailbreak) y asigna dinámicamente el puerto del switch a la VLAN de PCI-DSS. El punto de venta ya está operativo. No se ha requerido personal de TI en la tienda.

Comentario del examinador: Este escenario demuestra el poder de combinar el registro MDM sin intervención con la automatización SCEP. El SSID de incorporación temporal es un elemento de diseño crítico: proporciona acceso a internet para el proceso de registro en el MDM sin exponer la red corporativa. La asignación dinámica de VLAN garantiza que incluso si un dispositivo malicioso obtuviera de alguna manera una dirección MAC válida, seguiría fallando la comprobación del certificado EAP-TLS y se le denegaría el acceso a la VLAN de PCI. Esta arquitectura cumple simultáneamente con el Requisito 1 de PCI-DSS (segmentación de red) y el Requisito 8 (identificación única de dispositivos).

Preguntas de práctica

Q1. Su organización está migrando de WPA2-Enterprise utilizando PEAP-MSCHAPv2 a EAP-TLS. Durante la prueba piloto, los portátiles Windows y los iPhones se conectan correctamente, pero 200 escáneres de códigos de barras de almacén no logran autenticarse. Los escáneres son compatibles con 802.1X pero no pueden procesar el payload de SCEP del MDM; ejecutan un sistema operativo propietario integrado sin compatibilidad con agentes MDM. ¿Cuál es la solución de arquitectura más segura que mantiene la segmentación de la red sin necesidad de sustituir los escáneres?

Sugerencia: Considere mecanismos alternativos de entrega de certificados que no requieran un agente MDM y qué controles de segmentación de red deberían aplicarse a los dispositivos que no pueden participar en una evaluación completa del estado de seguridad (posture).

Ver respuesta modelo

Dado que los escáneres admiten 802.1X pero no el registro SCEP o MDM, el enfoque más seguro es aprovisionar manualmente los certificados de dispositivo utilizando una plantilla de certificado dedicada con un perfil de uso de clave restringido. Los certificados se instalan una vez durante una ventana de mantenimiento. El NAC está configurado para aceptar estos certificados pero asignar los escáneres a una VLAN de operaciones de almacén dedicada con ACL estrictas - no a la VLAN corporativa completa - porque la evaluación del estado de seguridad no es posible. Alternativamente, si el aprovisionamiento manual de certificados no es escalable operativamente, configure MAB como alternativa específicamente para las OUI MAC del hardware del escáner, asignándolas el NAC a la misma VLAN restringida. Documente esto como una excepción conocida en su registro de riesgos y planifique la sustitución de los escáneres en el próximo ciclo de renovación de hardware.

Q2. Un administrador de seguridad de red observa que cuando un empleado denuncia el robo de un portátil, el MDM envía un comando de borrado remoto, pero el dispositivo permanece conectado a la WiFi corporativa durante un máximo de 12 horas (el tiempo de espera de sesión RADIUS actual). Durante esta ventana, el dispositivo podría utilizarse para exfiltrar datos. ¿Cómo debería modificarse la arquitectura para terminar el acceso a la red inmediatamente después de que se denuncie el robo de un dispositivo?

Sugerencia: El NAC debe estar informado del cambio de estado al instante en lugar de esperar al siguiente ciclo de autenticación. Considere tanto el mecanismo de terminación de sesión como el mecanismo de prevención de reautenticación.

Ver respuesta modelo

Implemente dos controles complementarios. En primer lugar, configure el MDM para que envíe un webhook al NAC inmediatamente después de marcar un dispositivo como perdido o robado. A continuación, el NAC envía un mensaje Disconnect-Request de Change of Authorization (CoA) de RADIUS al punto de acceso específico o al puerto del switch, finalizando la sesión activa de inmediato. En segundo lugar, revoque el certificado del dispositivo en la CA y asegúrese de que el NAC está configurado para la comprobación OCSP en tiempo real en lugar de la revocación basada en CRL. Esto significa que incluso si el dispositivo vuelve a conectarse antes de que se procese el CoA, la autenticación EAP-TLS fallará en la comprobación OCSP. Ambos controles juntos reducen la ventana de exposición de 12 horas a menos de 60 segundos.

Q3. Durante una auditoría de seguridad de la red de un gran centro de conferencias, se descubre que el servidor SCEP está expuesto a internet pública utilizando una contraseña de desafío estática para permitir el registro remoto de dispositivos. El auditor señala esto como una vulnerabilidad crítica. ¿Cómo debería rediseñarse el proceso de registro SCEP para mantener la capacidad de registro remoto eliminando al mismo tiempo el riesgo de la contraseña estática?

Sugerencia: El servidor SCEP necesita una forma de verificar que el dispositivo que solicita un certificado está realmente autorizado por el MDM, sin depender de un secreto compartido que podría extraerse de un dispositivo o interceptarse.

Ver respuesta modelo

Sustituya la contraseña de desafío estática por contraseñas de desafío de un solo uso dinámicas y por dispositivo generadas por el MDM. El flujo de trabajo pasa a ser: (1) El MDM genera una contraseña de desafío única y con límite de tiempo para cada dispositivo durante el registro. (2) El MDM incluye este desafío en la carga útil SCEP enviada al dispositivo. (3) El dispositivo incluye el desafío en su CSR. (4) El servidor SCEP valida el desafío con el MDM a través de una API antes de reenviar el CSR a la CA. (5) El desafío se invalida inmediatamente después de su uso. Esto garantiza que solo los dispositivos gestionados por el MDM puedan obtener correctamente un certificado y que, incluso si se descubre la URL de SCEP, un atacante no pueda generar certificados válidos sin un desafío de un solo uso válido. Además, restrinja el servidor SCEP a HTTPS únicamente e implemente listas de IP permitidas para las IP de salida del MDM siempre que sea posible.