Saltar al contenido principal

Asegurar el trabajo híbrido: Combinar NAC con ZTNA para un acceso sin fricciones

Esta guía técnica autorizada cubre la convergencia arquitectónica de Network Access Control (NAC) y Zero Trust Network Access (ZTNA) para asegurar entornos de trabajo híbridos en espacios corporativos, comerciales, de hostelería y del sector público. Proporciona un plan de despliegue por fases, casos de estudio reales y directrices de cumplimiento para arquitectos de TI y CTOs que necesiten eliminar las brechas de seguridad creadas por dominios de acceso locales y en la nube aislados.

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

Escuchar esta guía

Ver transcripción del podcast
Bienvenido al Purple Enterprise Architecture Briefing. Soy su anfitrión y hoy vamos a analizar a fondo un desafío fundamental para los líderes de TI: proteger a la fuerza laboral híbrida. En concreto, analizaremos la convergencia arquitectónica del control de acceso a la red (NAC) y el acceso a la red Zero Trust (ZTNA). Si gestiona redes complejas en sedes corporativas, espacios comerciales o entornos del sector público, esto es para usted. Pongámonos en contexto. El perímetro tradicional ha muerto. Todos lo sabemos. Proteger una sede corporativa con un NAC robusto mientras se depende de VPN heredadas para el acceso remoto ya no es suficiente. Genera fricciones para el usuario y puntos ciegos para el departamento de TI. Las empresas modernas necesitan una postura de seguridad unificada que conecte sin problemas la infraestructura local con las aplicaciones nativas de la nube. Ahí es donde entra en juego la combinación de NAC y ZTNA. Históricamente, estos eran dominios aislados. El NAC, que utiliza estándares como 802.1X, era ideal para controlar el acceso físico e inalámbrico dentro del edificio. Comprobaba el estado del dispositivo y asignaba VLAN. El ZTNA, por otro lado, se diseñó para la era de la nube: protegía el acceso remoto en función de la identidad y el contexto, no de la ubicación de la red. El problema surge cuando un trabajador híbrido se desplaza entre estos dominios. Se autentica sin problemas en casa a través de ZTNA, pero se topa con un muro de políticas inconexas cuando entra en la oficina. Es frustrante, ineficiente y, francamente, crea brechas de seguridad que los atacantes pueden aprovechar. Hablemos de la arquitectura técnica. La solución es una capa unificada de intermediación de identidad y contexto. Necesitamos sincronizar la telemetría entre los motores de políticas de NAC y ZTNA. Piense en ello como una evaluación continua del estado que sigue al usuario, esté donde esté. Así es como funciona en la práctica. Cuando un dispositivo se conecta a la red corporativa, el NAC realiza una comprobación exhaustiva del estado: versión del sistema operativo, estado del antivirus, validación de certificados. Comparte este contexto inmediatamente con el intermediario de ZTNA mediante la integración de la API. Si el estado del dispositivo empeora (por ejemplo, si se detecta malware), el NAC lo pone en cuarentena en la red local y, al mismo tiempo, ordena al intermediario de ZTNA que revoque el acceso a las aplicaciones en la nube críticas. A medida que el usuario se traslada de la oficina a una ubicación remota, el cliente de ZTNA mantiene ese contexto de confianza establecido. No es necesario volver a autenticarse. La experiencia es fluida, pero la seguridad es continua. Ahora, analicemos los estándares que sustentan esto. IEEE 802.1X es el estándar de oro para la autenticación local. Proporciona una validación criptográfica de la identidad del dispositivo a nivel de puerto. RADIUS actúa como el protocolo backend, comunicando la solución NAC y su proveedor de identidad. En el lado de ZTNA, nos encontramos con proveedores de identidad como Azure Active Directory u Okta, con intermediarios de ZTNA de los principales proveedores. La clave es garantizar que estos sistemas puedan comunicarse de forma bidireccional. Para los operadores de espacios (hoteles, centros de conferencias, estadios) existe un nivel adicional de complejidad. Se gestiona al personal corporativo, contratistas, invitados y una flota creciente de dispositivos IoT, todo en la misma infraestructura física. NAC se encarga de la segmentación. El personal corporativo obtiene autenticación 802.1X y acceso a los recursos internos. Los invitados se aíslan en una red dedicada, idealmente gestionada a través de una plataforma como el Guest WiFi de Purple, que proporciona un aislamiento sólido a la vez que captura valiosos análisis. Los dispositivos IoT que no pueden admitir 802.1X (como cartelería digital, sensores ambientales o terminales de punto de venta) se gestionan mediante MAC Authentication Bypass, o MAB, con una segmentación estricta de VLAN para contener cualquier posible brecha de seguridad. Permítame guiarle a través de un escenario de despliegue en el mundo real. Pensemos en una cadena de distribución global con quinientos establecimientos. Los directores regionales viajan constantemente entre las tiendas, la sede central y sus hogares. Sufren desconexiones de la VPN y un acceso inconsistente a las aplicaciones de gestión de inventario. La solución es una arquitectura convergente de NAC y ZTNA. Cuando un director está en la tienda, NAC autentica el dispositivo mediante 802.1X y comparte el contexto interno de confianza con el agente de ZTNA. A continuación, el agente concede acceso directo y optimizado a la aplicación de inventario alojada en la nube, sin necesidad de un túnel VPN. Cuando el director trabaja desde casa, el cliente de ZTNA establece un microtúnel seguro con la aplicación, manteniendo las mismas políticas de acceso. ¿El resultado? Un acceso consistente, menos llamadas al servicio de asistencia y una postura de seguridad notablemente mejorada. Pasemos ahora a la implementación. Recomiendo un enfoque de tres fases. La fase uno es la visibilidad. Despliegue primero NAC en modo de monitorización. Descubra y analice el perfil de todo lo que hay en su red: portátiles, dispositivos BYOD, IoT y dispositivos de invitados. No aplique ninguna restricción todavía. Simultáneamente, integre sus proveedores de identidad tanto con NAC como con ZTNA para consolidar las identidades de los usuarios. Utilice su solución ZTNA para mapear los patrones de acceso a las aplicaciones. Esto le proporcionará los datos necesarios para redactar políticas sensatas. La fase dos es la definición de políticas. Defina los requisitos de postura básicos para los dispositivos corporativos. Implemente la microsegmentación de ZTNA en función de los roles de los usuarios y la sensibilidad de las aplicaciones. Y lo que es fundamental, establezca la integración de API entre sus plataformas NAC y ZTNA para compartir el contexto de forma bidireccional. Pruebe a fondo esta integración antes de pasar a la fase de aplicación. La fase tres es la aplicación. Active gradualmente la aplicación de NAC, empezando por un grupo piloto. Monitorice los fallos de autenticación y ajuste las políticas. Despliegue los clientes de ZTNA en todos los endpoints corporativos. Y amplíe los principios de zero-trust a sus redes de invitados utilizando una plataforma gestionada. Permítame ofrecerle una orientación rápida sobre los errores más comunes. En primer lugar, los retrasos en la sincronización de contextos. Si la integración de la API entre el NAC y el ZTNA experimenta latencia, un dispositivo comprometido podría conservar el acceso a las aplicaciones en la nube más tiempo de lo aceptable. La solución es utilizar notificaciones push basadas en webhooks en lugar de depender de mecanismos de sondeo. Esto garantiza actualizaciones de políticas casi en tiempo real. En segundo lugar, las políticas excesivamente restrictivas que provocan picos en el servicio de soporte. Implementar comprobaciones estrictas del estado de los dispositivos sin una comunicación adecuada con el usuario es una fórmula para el caos. Utilice un Captive Portal para informar a los usuarios sobre el incumplimiento y proporcionar soluciones de autoservicio antes de bloquear el acceso por completo. En tercer lugar, los fallos de autenticación de los dispositivos IoT. Los dispositivos IoT sin interfaz gráfica simplemente no pueden admitir clientes 802.1X o ZTNA. La respuesta es el bypass de autenticación MAC (MAB) combinado con un perfilado riguroso de los dispositivos y una segmentación estricta de las VLAN. En cuarto lugar, y esto es muy importante, no supervisar la salud de la propia integración de la API. Si la sincronización entre el NAC y el ZTNA falla, se genera una brecha de seguridad. Implemente la supervisión y las alertas sobre el estado de la integración, y defina políticas de seguridad ante fallos que se activen si la sincronización se pierde durante más tiempo del umbral definido. ¿Cuál es entonces el retorno de la inversión? El caso de negocio para esta arquitectura es convincente. La consolidación de la gestión de políticas reduce la carga administrativa de los equipos de TI. La eliminación de las VPN heredadas mejora significativamente la experiencia de trabajo híbrido, reduciendo el tiempo de inactividad y la frustración. Además, la capacidad de demostrar una evaluación continua del estado de los dispositivos y un control de acceso basado en la identidad simplifica los informes de cumplimiento para marcos normativos como PCI-DSS y GDPR - de especial relevancia en entornos minoristas y sanitarios. Para resumir las conclusiones clave de la sesión de hoy: la identidad es el nuevo perímetro y el contexto es la clave. Utilice el NAC para el cable y el ZTNA para la aplicación. Nunca confíe, verifique siempre, y hágalo de forma continua. Impleméntelo por fases: primero la visibilidad, luego la política y, por último, la aplicación de medidas. Y no se olvide de la red de invitados y del parque de IoT: deben formar parte de su arquitectura de seguridad, no ser una idea de última hora. Si desea profundizar en el futuro de la seguridad de red impulsado por la IA, consulte la guía de Purple sobre NAC impulsado por IA y detección de amenazas. Y para quienes gestionen sedes distribuidas, nuestra guía de SD-WAN frente a MPLS bien merece su tiempo. Esto es todo por hoy. Gracias por escucharnos y nos vemos en la próxima ocasión.

header_image.png

Resumen Ejecutivo

Para los arquitectos de redes empresariales y los CTO que gestionan entornos distribuidos, el perímetro de red ya no existe. El modelo tradicional de proteger la sede corporativa con un robusto Network Access Control (NAC) mientras se depende de VPN heredadas para el acceso remoto ya no es viable. Las empresas modernas necesitan una postura de seguridad unificada que conecte de forma fluida la infraestructura local con las aplicaciones nativas de la nube. Esta guía detalla la convergencia arquitectónica de NAC y Zero Trust Network Access (ZTNA), proporcionando un plan para proteger los entornos de trabajo híbridos sin comprometer la experiencia del usuario ni el rendimiento de la red.

Al combinar la aplicación de políticas de estado de los dispositivos a nivel de NAC con la microsegmentación centrada en la identidad de ZTNA, las empresas pueden lograr una verificación de confianza continua independientemente de dónde se encuentren los usuarios. Esta convergencia es especialmente crítica en sectores con una gran afluencia de público y requisitos de cumplimiento complejos, como el comercio minorista , la sanidad y la hostelería . Además, el aprovechamiento de plataformas como la infraestructura de Guest WiFi de Purple permite extender estos principios de confianza cero a las redes de invitados, garantizando un aislamiento robusto y la protección de datos en consonancia con las obligaciones de GDPR y PCI-DSS.

Análisis Técnico Detallado: La Arquitectura Convergente

Las Limitaciones de los Dominios de Seguridad Aislados

Históricamente, NAC y ZTNA han funcionado como dominios de seguridad aislados. NAC, aprovechando el estándar 802.1X de la IEEE y RADIUS, destaca en el control del acceso físico y inalámbrico dentro del perímetro corporativo. Proporciona perfiles de dispositivos robustos, evaluación del estado de seguridad y asignación de VLAN. ZTNA, por el contrario, surgió para asegurar el acceso remoto a aplicaciones locales y en la nube, operando bajo el principio de "nunca confiar, siempre verificar" basado en la identidad y el contexto del usuario en lugar de la ubicación de la red.

La fricción surge cuando los trabajadores híbridos se mueven entre estos dominios. Un usuario se autentica sin problemas en casa a través de ZTNA a diario, pero al entrar en la oficina corporativa a menudo se enfrenta a una experiencia inconexa, ya que las políticas de NAC locales pueden no alinearse con su contexto de ZTNA. Esta fragmentación introduce puntos ciegos de seguridad y costes operativos, lo que afecta directamente a la eficiencia de TI y a la productividad del usuario final.

El Agente Unificado de Identidad y Contexto

La solución arquitectónica consiste en establecer una capa de intermediación unificada de identidad y contexto que sincronice la telemetría entre los motores de políticas de NAC y ZTNA. Esta integración permite una evaluación continua del estado de seguridad que persiste a través de los límites de la red.

nac_ztna_architecture_overview.png

Esta integración funciona a través de tres mecanismos clave. Primero, evaluación continua de la postura: cuando un dispositivo se conecta a la red corporativa, la solución NAC realiza una comprobación exhaustiva de la postura que cubre la versión del sistema operativo, el estado del antivirus y la validación del certificado. Este contexto se comparte inmediatamente con el agente de ZTNA mediante la integración de la API. Segundo, aplicación dinámica de políticas: si la postura de seguridad de un dispositivo se degrada (por ejemplo, si se detecta malware), el sistema NAC pone en cuarentena el dispositivo en la red local mientras indica simultáneamente al agente de ZTNA que revoque el acceso a las aplicaciones en la nube críticas. Tercero, transición fluida: a medida que el usuario se desplaza de la oficina a una ubicación remota, el cliente de ZTNA mantiene el contexto de confianza establecido, eliminando la necesidad de volver a autenticarse y garantizando un acceso ininterrumpido a los recursos autorizados.

Para profundizar en las tecnologías inalámbricas subyacentes que respaldan estas implementaciones, consulte nuestra guía: Frecuencias WiFi: La guía de 2026 de bandas WiFi .

hybrid_work_security_comparison.png

Guía de implementación: Despliegue por fases

El despliegue de una arquitectura convergente NAC/ZTNA requiere un enfoque por fases para minimizar las interrupciones y garantizar una aplicación sólida de las políticas.

Fase 1: Descubrimiento de identidad y activos

Antes de implementar las políticas de aplicación, debe lograr una visibilidad completa de su entorno de red. Despliegue su solución NAC en modo de solo monitorización: configúrela para descubrir y perfilar todos los dispositivos conectados, incluidos portátiles corporativos, BYOD, IoT y dispositivos de invitados, sin bloquear el acceso. Consolide la identidad del usuario integrando las soluciones NAC y ZTNA con un proveedor de identidad central como Azure AD u Okta. Esto garantiza políticas de autenticación coherentes en ambos dominios. Paralelamente, utilice su solución ZTNA para supervisar los patrones de acceso a las aplicaciones, identificando qué usuarios necesitan acceso a aplicaciones específicas y sentando las bases de sus políticas de microsegmentación.

Fase 2: Definición de políticas y microsegmentación

Pase de la visibilidad al control definiendo políticas de acceso granulares basadas en el principio de mínimo privilegio. Establezca requisitos de seguridad básicos para los dispositivos corporativos, incluidas las versiones mínimas del sistema operativo y el requisito de un agente EDR activo, y configure la solución NAC para aplicarlos al acceso local. Defina políticas ZTNA que restrinjan el acceso a las aplicaciones en función del rol del usuario y el contexto del dispositivo, garantizando la alineación con los requisitos de postura definidos en la solución NAC. De manera crucial, configure la integración de la API entre las plataformas NAC y ZTNA para permitir el intercambio bidireccional de contextos, garantizando que los cambios en la postura de los dispositivos detectados por NAC activen inmediatamente actualizaciones de políticas en el agente ZTNA en tiempo real.

Fase 3: Ejecución y Optimización

Habilite gradualmente el modo de ejecución, supervisando las anomalías y ajustando las políticas según sea necesario. Realice la transición de la solución NAC del modo de supervisión al modo de ejecución, comenzando con un grupo de usuarios o ubicación piloto, y supervise los fallos de autenticación. Implemente el cliente ZTNA en todos los endpoints corporativos, garantizando un acceso fluido tanto a las aplicaciones en la nube como a las locales. Amplíe las políticas sólidas de acceso de invitados utilizando plataformas como el Guest WiFi de Purple, garantizando que el tráfico de invitados esté estrictamente aislado de los recursos corporativos. Aproveche WiFi Analytics para supervisar los patrones de uso y detectar posibles anomalías en todo el entorno de invitados.

Buenas Prácticas para Entornos Empresariales

Priorice la experiencia del usuario a lo largo de la implementación. La seguridad no debe impedir la productividad, y la transición entre el acceso local y el remoto debe ser transparente para los usuarios, aprovechando el inicio de sesión único y los mecanismos de autenticación continua. Para el acceso local, exija la autenticación 802.1X para todos los dispositivos corporativos, ya que proporciona una sólida verificación criptográfica de la identidad del dispositivo a nivel de puerto.

Integre capacidades de detección de amenazas impulsadas por IA en sus soluciones NAC y ZTNA para identificar comportamientos anómalos y poner en cuarentena automáticamente los dispositivos comprometidos. Para obtener una perspectiva de futuro sobre esta capacidad, consulte The Future of Wi-Fi Security: AI-Driven NAC and Threat Detection y su versión en español El Futuro de la Seguridad Wi-Fi: NAC Impulsado por IA y Detección de Amenazas . Para las empresas distribuidas, la integración de ZTNA con SD-WAN puede optimizar el enrutamiento de aplicaciones y mejorar el rendimiento en varias ubicaciones - consulte nuestra comparación en SD WAN vs MPLS: The 2026 Enterprise Network Guide .

Resolución de Problemas y Mitigación de Riesgos

La latencia de sincronización de contexto representa el modo de fallo más crítico. Si la integración de la API entre NAC y ZTNA experimenta retrasos, un dispositivo comprometido puede mantener el acceso a las aplicaciones en la nube durante más tiempo de lo aceptable. La mitigación consiste en implementar notificaciones push basadas en webhooks en lugar de depender únicamente de mecanismos de sondeo, lo que garantiza actualizaciones de políticas casi en tiempo real.

Las políticas excesivamente restrictivas pueden provocar un fuerte aumento en el volumen de tickets de soporte técnico cuando se implementan controles de postura estrictos sin una comunicación adecuada con el usuario. Utilice un Captive Portal para notificar a los usuarios el incumplimiento y proporcionar instrucciones de reparación de autoservicio antes de bloquear completamente el acceso.

Los fallos de autenticación de dispositivos IoT son inevitables en entornos de recintos. Los dispositivos IoT sin interfaz de usuario no pueden admitir clientes 802.1X o ZTNA. La solución es adoptar la evasión de autenticación MAC (MAB) combinada con un perfilado estricto de dispositivos y una segmentación de VLAN rigurosa para aislar el tráfico de IoT de los recursos corporativos.

La supervisión del estado de la integración de la API se pasa por alto con frecuencia. Si la sincronización entre NAC y ZTNA se rompe, existe una brecha de seguridad que ninguno de los dos sistemas puede resolver de forma independiente. Implemente una supervisión y alertas dedicadas para el estado de la integración, y defina políticas de seguridad a prueba de fallos que activen restricciones de acceso automáticas si se pierde la sincronización más allá de un umbral definido.

ROI e impacto empresarial

La convergencia de NAC y ZTNA ofrece un valor empresarial medible que va más allá de la mitigación de riesgos. La gestión de políticas unificada reduce la carga administrativa de los equipos de TI, lo que les permite centrarse en iniciativas estratégicas en lugar de gestionar silos de seguridad fragmentados. La eliminación de las VPN heredadas mejora significativamente la experiencia de trabajo híbrido, reduciendo el tiempo de inactividad y la frustración, al tiempo que mejora el rendimiento de las aplicaciones para los usuarios remotos.

La capacidad de demostrar una evaluación continua de la postura y un control de acceso basado en la identidad simplifica la generación de informes de cumplimiento para marcos como PCI-DSS y GDPR, lo cual es especialmente importante en entornos de Transporte y comercio minorista, donde las obligaciones de protección de datos personales y de titulares de tarjetas son estrictas. Las organizaciones que han implementado una arquitectura convergente informan de forma constante de una reducción del tiempo medio de contención (MTTC) de los incidentes de seguridad, ya que la aplicación de políticas bidireccionales permite la cuarentena automática sin intervención manual.

Definiciones clave

Control de Acceso a la Red (NAC)

Una solución de seguridad que aplica políticas a los dispositivos que intentan acceder a una infraestructura de red, utilizando normalmente IEEE 802.1X para la autenticación y la evaluación de postura con el fin de determinar la asignación de VLAN y los derechos de acceso.

Crítico para asegurar entornos locales, garantizando que solo los dispositivos autorizados y que cumplan las normativas puedan conectarse a los switches corporativos y puntos de acceso inalámbricos. Los equipos de TI se encuentran con esto al gestionar redes de oficinas físicas y de recintos.

Acceso a la Red de Confianza Cero (ZTNA)

Una solución de seguridad de TI que proporciona acceso remoto seguro a aplicaciones y servicios basándose en políticas de control de acceso definidas, operando bajo el principio de mínimo privilegio y verificación continua de la identidad en lugar de la ubicación de la red.

Reemplaza las VPN heredadas proporcionando microsegmentación basada en la identidad, otorgando acceso solo a aplicaciones específicas en lugar de a toda la red. Relevante al proteger a los trabajadores remotos y el acceso a aplicaciones en la nube.

Microsegmentación

La práctica de dividir una red en segmentos aislados para reducir la superficie de ataque y evitar el movimiento lateral por parte de actores de amenazas, aplicada a nivel de aplicación o carga de trabajo en lugar del perímetro de la red.

ZTNA aplica este concepto a nivel de aplicación, garantizando que un endpoint comprometido no pueda pivotar para acceder a recursos no autorizados. Los equipos de TI se encuentran con esto al diseñar arquitecturas de confianza cero.

Evaluación de Postura

El proceso de evaluar el estado de seguridad de un dispositivo -incluyendo la versión del sistema operativo, el antivirus activo, los certificados instalados y el nivel de parches- antes de conceder acceso a la red o a las aplicaciones.

Una función principal de NAC, que garantiza que los dispositivos vulnerables o comprometidos sean puestos en cuarentena o corregidos antes de que puedan interactuar con la red corporativa. Relevante durante la incorporación de dispositivos y la supervisión continua.

IEEE 802.1X

Un estándar IEEE para el control de acceso a redes basado en puertos, que proporciona un mecanismo de autenticación a los dispositivos que desean conectarse a una LAN o WLAN, utilizando EAP (Protocolo de Autenticación Extensible) sobre el medio de red.

El estándar de oro para la autenticación de redes empresariales, que proporciona una sólida validación criptográfica de la identidad del dispositivo. Los equipos de TI se encuentran con esto al configurar switches, controladores inalámbricos y servidores RADIUS.

RADIUS (Servicio de Usuario de Acceso Telefónico de Autenticación Remota)

Un protocolo de red que proporciona una gestión centralizada de Autenticación, Autorización y Contabilidad (AAA) para los usuarios que se conectan y utilizan un servicio de red, actuando como capa de comunicación entre NAC y los proveedores de identidad.

El protocolo de backend utilizado por las soluciones NAC para comunicarse con los proveedores de identidad y aplicar las políticas de acceso. Relevante al integrar NAC con Active Directory o IdPs en la nube.

Bypass de Autenticación MAC (MAB)

Un método de autenticación alternativo utilizado por las soluciones NAC para los dispositivos que no admiten 802.1X, que se basa en la dirección MAC del dispositivo como identificador para asignar políticas de acceso a la red.

Necesario para dar cabida a dispositivos sin interfaz de usuario -impresoras, sensores IoT, señalización digital- en entornos empresariales. Menos seguro que 802.1X y requiere una estricta segmentación de VLAN para mitigar los riesgos de suplantación de identidad MAC.

Proveedor de Identidad (IdP)

Una entidad del sistema que crea, mantiene y gestiona la información de identidad de los principales, al tiempo que proporciona servicios de autenticación a las aplicaciones que confían en ella dentro de una federación o red distribuida.

La fuente central de verdad para las identidades de los usuarios, que se integra tanto con NAC como con ZTNA para garantizar políticas de autenticación coherentes. Los equipos de TI se encuentran con esto al configurar el inicio de sesión único (SSO) y MFA en los sistemas de la empresa.

VLAN (Virtual Local Area Network)

Una subdivisión lógica de una red física que agrupa dispositivos en dominios de difusión aislados, lo que permite la segmentación del tráfico sin necesidad de una infraestructura física independiente.

El mecanismo principal para aislar diferentes clases de dispositivos (corporativos, invitados, IoT) dentro de una red física compartida. Es fundamental para cumplir con los requisitos de la normativa PCI-DSS relativos al aislamiento del entorno de datos de los titulares de tarjetas.

Ejemplos prácticos

Una cadena de tiendas global con 500 ubicaciones necesita asegurar el acceso de los directores regionales que viajan con frecuencia entre las tiendas, la sede corporativa y las oficinas domésticas remotas. Actualmente experimentan desconexiones frecuentes de la VPN y un acceso inconsistente a las aplicaciones de gestión de inventario alojadas en la nube.

Implementar una arquitectura convergente NAC/ZTNA en todas las ubicaciones. Desplegar 802.1X a través de NAC para un acceso seguro y sin fricciones cuando los directores se encuentren físicamente en la tienda o en la sede, autenticándose contra un servidor RADIUS centralizado integrado con Azure AD. Desplegar un cliente ZTNA en todos los portátiles corporativos. Integrar los motores de políticas NAC y ZTNA a través de API, configurando notificaciones de webhook para actualizaciones inmediatas de estado de seguridad. Cuando un director se conecta a la red de la tienda, el NAC autentica el dispositivo y comparte el contexto de "interno de confianza" con el broker ZTNA. A continuación, el broker ZTNA concede un acceso directo y optimizado a la aplicación de inventario alojada en la nube sin requerir un túnel VPN, lo que reduce la latencia y elimina los problemas de desconexión. Cuando el director trabaja desde casa, el cliente ZTNA establece un microtúnel seguro hacia la aplicación, manteniendo las mismas políticas de acceso sin depender del perímetro de la red corporativa. Los dispositivos de invitados e IoT en la tienda se aíslan en VLANs independientes gestionadas a través de la plataforma de Guest WiFi de Purple.

Comentario del examinador: Este enfoque resuelve los problemas de experiencia de usuario asociados con las VPN heredadas al proporcionar un acceso fluido y consciente del contexto, independientemente de la ubicación. La integración de la API garantiza que el estado de seguridad se evalúe continuamente, mitigando el riesgo de que un dispositivo comprometido acceda a aplicaciones críticas. La decisión arquitectónica clave es el enrutamiento "local edge" (borde local): cuando se está en la red corporativa, el tráfico ZTNA debe enrutarse a un broker local en lugar de realizar un bucle de retorno a través de un broker en la nube, lo que anularía los beneficios de latencia.

Un gran centro de conferencias necesita proporcionar WiFi seguro para el personal corporativo, al tiempo que aísla miles de conexiones diarias de invitados y dispositivos IoT de proveedores externos, incluidos cartelería digital, balizas BLE y sensores ambientales.

Desplegar una solución NAC robusta configurada con una segmentación estricta de VLAN en tres niveles distintos. Nivel uno: los dispositivos del personal corporativo se autentican mediante 802.1X y se asignan a una VLAN interna segura con acceso total a los sistemas de gestión interna. Nivel dos: implementar la plataforma Guest WiFi de Purple para gestionar el acceso público, capturando análisis valiosos y garantizando al mismo tiempo un aislamiento completo de la red corporativa a través de una VLAN dedicada para invitados con acceso exclusivo a internet. Nivel tres: para los dispositivos IoT de proveedores, utilizar MAC Authentication Bypass (MAB) combinado con un perfilado profundo de dispositivos (analizando huellas DHCP, agentes de usuario HTTP y patrones de tráfico) para identificar con precisión los tipos de dispositivos y asignarlos a VLANs restringidas con acceso exclusivo a internet. Integrar ZTNA para que el personal corporativo acceda a las aplicaciones de gestión interna de forma segura desde cualquier ubicación dentro del recinto o de forma remota. Para la infraestructura de balizas BLE, consulte la guía sobre BLE Low Energy Explained for Enterprise para consideraciones de integración.

Comentario del examinador: Este escenario destaca la necesidad de gestionar diversos tipos de dispositivos dentro de un único entorno físico. El modelo de segmentación de tres niveles es el enfoque correcto; intentar gestionar todos los tipos de dispositivos dentro de un único marco de políticas conduce invariablemente a políticas excesivamente permisivas o restrictivas. El uso de la plataforma Purple para WiFi de invitados (Guest WiFi) para el nivel de invitados es especialmente relevante aquí, ya que proporciona tanto el aislamiento necesario para la seguridad como la capacidad analítica requerida para las operaciones del espacio.

Preguntas de práctica

Q1. ¿Su organización está implementando ZTNA para sustituir una VPN heredada. Sin embargo, los usuarios que regresan a la oficina corporativa experimentan latencia al acceder a las aplicaciones alojadas localmente en el centro de datos local, ya que el tráfico de ZTNA se está enrutando a través de un intermediario alojado en la nube. ¿Cuál es la solución arquitectónica recomendada?

Sugerencia: Piense en cómo el cliente ZTNA determina la ruta óptima hacia la aplicación en función del contexto de red física del usuario.

Ver respuesta modelo

Implementar un intermediario ZTNA local o en las instalaciones (On-Premises) dentro del centro de datos corporativo. Configure el cliente ZTNA para que detecte cuándo se autentica el dispositivo en la red corporativa interna a través de NAC y enrute el tráfico directamente a la aplicación local a través del intermediario interno, en lugar de realizar un bucle de retorno (hair-pinning) a través del intermediario alojado en la nube. Esto reduce la latencia de las aplicaciones locales al tiempo que mantiene los mismos controles de acceso basados en la identidad. El intercambio de contexto de NAC a través de la API debe indicar al intermediario ZTNA que el dispositivo se encuentra en una red interna de confianza, lo que permite tomar la decisión de enrutamiento local.

Q2. El equipo de TI de un hospital necesita proteger cientos de dispositivos médicos conectados (bombas de infusión, monitores de pacientes, equipos de imagenología) que no pueden ejecutar suplicantes 802.1X ni clientes ZTNA. ¿Cómo se deben proteger estos dispositivos dentro de una arquitectura convergente de NAC/ZTNA?

Sugerencia: Considere los métodos de autenticación de respaldo y el principio de aislamiento a nivel de red para los dispositivos que no pueden participar en los controles basados en la identidad.

Ver respuesta modelo

Utilizar la omisión de autenticación MAC (MAB) en la solución NAC, combinada con un perfilado profundo de dispositivos mediante huellas de DHCP, agentes de usuario HTTP y análisis de comportamiento del tráfico para identificar y clasificar con precisión cada tipo de dispositivo médico. Una vez identificados, el NAC asigna dinámicamente estos dispositivos a VLAN altamente restringidas y aisladas que solo permiten la comunicación con servidores y sistemas médicos específicos y obligatorios, bloqueando todo el resto del tráfico por defecto. ZTNA no es aplicable a estos dispositivos; la seguridad depende por completo de una segmentación de red estricta y de la supervisión continua del tráfico para detectar comportamientos anómalos. Asegúrese de que las VLAN de los dispositivos médicos estén completamente aisladas del entorno de datos de los titulares de tarjetas para mantener la conformidad con PCI-DSS.

Q3. Durante un despliegue en producción, la integración de la API entre sus soluciones NAC y ZTNA falla de forma silenciosa sin que se activen alertas. Posteriormente, el portátil de un usuario en la red corporativa se infecta con malware. Describa el resultado de seguridad esperado e identifique el fallo de arquitectura que lo permitió.

Sugerencia: Analice el impacto de la pérdida de sincronización de contexto en cada motor de políticas de forma independiente y considere qué supervisión debería haberse implementado.

Ver respuesta modelo

La solución NAC detectará la postura degradada a través de la integración con EDR y aislará el dispositivo en la red local, evitando el movimiento lateral dentro del entorno corporativo. Sin embargo, dado que la integración de la API ha fallado de forma silenciosa, el agente ZTNA no ha recibido el contexto de postura actualizado. Si el usuario intenta acceder a una aplicación en la nube, el cliente ZTNA aún podría establecer una conexión si el token de autenticación de identidad inicial sigue siendo válido y no ha caducado. La brecha arquitectónica es doble: primero, la ausencia de monitorización del estado de la propia integración de la API; segundo, la falta de una política de seguridad contra fallos que active restricciones de acceso automáticas si la sincronización del contexto se pierde más allá de un umbral definido. La solución es implementar una monitorización dedicada con alertas sobre el estado de la integración, configurar el agente ZTNA para que requiera una revalidación periódica de la postura (no solo la autenticación inicial) y definir una política de denegación por defecto que se active si el flujo de contexto del NAC no está disponible durante más de un intervalo especificado.