Del VPN a Zero Trust: guía práctica para empresas del Cono Sur

Por qué el VPN tradicional ya no alcanza

El VPN de acceso remoto fue diseñado para un mundo que ya no existe: aplicaciones dentro del datacenter propio y empleados que se conectaban de vez en cuando. Hoy la mayoría de las empresas medianas del Cono Sur trabaja en modo híbrido, usa varias aplicaciones SaaS y tiene parte de su infraestructura en la nube pública.

En ese escenario, el VPN resuelve el problema equivocado. Conecta a una persona a la red, cuando lo que necesita es acceder a una aplicación. Esa diferencia, que parece técnica, es la que define cuánto daño puede hacer una credencial robada.

Esta guía explica qué riesgos concretos tiene el modelo VPN, qué significa Zero Trust según los marcos de referencia reconocidos (y no según el folleto de un fabricante), y cómo planificar una migración por etapas sin cortar la operación.

Los riesgos concretos del VPN

El VPN hoy es uno de los puntos de entrada preferidos de los atacantes. Según el Verizon DBIR 2025, los VPN y dispositivos de borde pasaron del 3% al 22% de las brechas por explotación de vulnerabilidades en un año, y solo el 54% de esas fallas se terminó de remediar, con una mediana de 32 días (SecurityWeek).

El problema tiene tres capas:

Superficie expuesta. El concentrador VPN escucha en internet las 24 horas. Cualquier vulnerabilidad nueva en ese equipo es una puerta abierta hasta que se aplica el parche. Un ejemplo: en abril de 2025, la Shadowserver Foundation detectó más de 5.000 equipos Ivanti Connect Secure expuestos a la CVE-2025-22457, ya explotada por un grupo vinculado a China e incorporada al catálogo KEV de CISA (Cybersecurity Dive).
Acceso demasiado amplio. Una vez autenticado, el usuario (o quien le robó la credencial) suele quedar dentro de un segmento de red completo. Desde ahí puede escanear, descubrir servidores y moverse lateralmente.
Confianza implícita. El VPN valida quién entra al principio de la sesión, pero en general no vuelve a evaluar el estado del dispositivo ni el contexto mientras la conexión sigue abierta.

Ninguno de estos puntos se resuelve con un VPN "más nuevo". Son consecuencia del modelo: conectar personas a redes.

Qué es Zero Trust de verdad

Zero Trust no es un producto: es un modelo de arquitectura que deja de proteger segmentos de red y pasa a proteger cada recurso por separado. La definición de referencia es la de NIST SP 800-207 (agosto de 2020).

Según NIST, la idea central es que no se otorga confianza implícita a un usuario o dispositivo por estar dentro de la red de la empresa ni por ser un equipo corporativo. La autenticación y la autorización, tanto de la persona como del dispositivo, se resuelven antes de abrir cada sesión hacia un recurso.

En la práctica, eso se traduce en cuatro reglas:

Cada acceso se decide por separado, para una aplicación concreta y no para "la red".
La decisión usa contexto: identidad, grupo, estado del dispositivo, ubicación y riesgo de la sesión.
Mínimo privilegio: cada usuario ve solo las aplicaciones que necesita para su trabajo.
Todo queda registrado para auditar y detectar comportamiento anómalo.

Para medir el avance, el Modelo de Madurez Zero Trust v2.0 de CISA (abril de 2023) organiza el trabajo en cinco pilares: identidad, dispositivos, redes, aplicaciones y cargas de trabajo, y datos. Cada pilar tiene cuatro etapas (tradicional, inicial, avanzada y óptima) y tres capacidades transversales: visibilidad y analítica, automatización y orquestación, y gobierno.

El modelo de CISA es útil porque baja a tierra algo que el marketing suele inflar. Ninguna empresa "compra Zero Trust": avanza de etapa en etapa, pilar por pilar.

Arquitectura de referencia

La diferencia clave está en qué alcanza el usuario después de autenticarse: con VPN, la red entera; con ZTNA, solo la aplicación que la política le permite.

VPN vs. ZTNA: qué alcanza el usuario en cada modelo

Una arquitectura ZTNA típica tiene cinco piezas:

Proveedor de identidad (IdP) con MFA: define quién es el usuario y a qué grupos pertenece.
Agente o navegador en el dispositivo: informa la postura del equipo (sistema actualizado, cifrado, EDR activo).
Broker de acceso, normalmente un servicio en la nube: recibe cada pedido, consulta identidad y postura, y aplica la política de esa aplicación.
Conector dentro del datacenter o la nube privada: abre una conexión saliente hacia el broker, así que no hace falta exponer puertos a internet.
Registro centralizado de cada acceso, idealmente integrado con un SIEM.

Con esta arquitectura, las aplicaciones internas dejan de ser visibles desde internet. Para un atacante externo no hay concentrador que escanear.

Plan de migración en fases

La migración se hace por etapas, con el VPN y el acceso Zero Trust (ZTNA) conviviendo hasta que el último grupo de usuarios está migrado. Cortar el VPN de un día para el otro es la forma más rápida de generar rechazo interno y volver atrás.

Relevamiento. Inventariar quién usa el VPN, desde qué dispositivos y para llegar a qué aplicaciones. En la mayoría de las empresas medianas aparecen menos aplicaciones críticas de las que se esperaba, y algunos accesos que nadie recuerda haber habilitado.
Identidad primero. Consolidar un proveedor de identidad único (Microsoft Entra ID, Google Workspace, Okta u otro) con MFA obligatorio para todos. Sin identidad confiable no hay política Zero Trust posible.
Piloto con aplicaciones web. Publicar dos o tres aplicaciones web internas a través del ZTNA para un grupo chico de usuarios, por ejemplo el equipo de IT y un área de negocio. Medir experiencia de uso e incidencias.
Postura del dispositivo. Sumar controles sobre el equipo: sistema operativo actualizado, disco cifrado, antivirus o EDR activo. Definir qué se hace con equipos personales (BYOD): acceso solo por navegador aislado, o ningún acceso.
Aplicaciones no web. Migrar los accesos más difíciles: escritorio remoto, SSH, bases de datos y aplicaciones cliente-servidor. Aquí suele hacer falta un conector o agente dentro del datacenter.
Terceros. Pasar proveedores y contratistas al modelo nuevo. Suele ser donde más rápido se ve el beneficio, porque hoy muchos tienen cuentas VPN con acceso amplio y sin vencimiento.
Apagado del VPN. Cuando el registro muestra que nadie lo usa durante un período acordado, se da de baja el concentrador y se cierra el puerto expuesto a internet.

Errores comunes y cómo evitarlos

La mayoría de los proyectos que fracasan no fallan por la tecnología, sino por decisiones de diseño tomadas al principio.

Replicar el VPN con otra marca. Si la política nueva da acceso a toda una subred, el resultado es un VPN con otro nombre. La regla es una política por aplicación.
Empezar sin MFA sólido. Zero Trust descansa en la identidad. Con contraseñas sin segundo factor, o con MFA por SMS, el punto débil solo se mueve de lugar.
Ignorar las aplicaciones legadas. Un sistema cliente-servidor viejo puede trabar todo el proyecto. Conviene identificarlos en el relevamiento y planificarlos aparte.
No mirar los registros. El acceso Zero Trust genera mucha información útil. Si nadie la revisa ni la envía a un SIEM, se pierde la mitad del valor.
Dejar a los terceros para el final. Proveedores con cuentas VPN abiertas suelen ser el mayor riesgo. Conviene priorizarlos.
No comunicar. Para el usuario cambia la forma de trabajar. Un instructivo simple y un canal de soporte los primeros días evitan buena parte de las quejas.

Contexto regional: normativa de datos en el Cono Sur

Los cuatro países exigen, con distinto grado de detalle, medidas de seguridad sobre los datos personales y capacidad de demostrar quién accedió a qué. Un acceso por aplicación, con registro de cada sesión, facilita mucho ese cumplimiento frente a un VPN que solo registra conexiones a la red.

País	Norma principal	Estado a octubre de 2026	Qué implica para el acceso remoto
Chile	Ley 21.719 de protección de datos y Ley 21.663 Marco de Ciberseguridad	La 21.719 entra en vigencia el 1 de diciembre de 2026; hay un proyecto del Ejecutivo para postergarla a diciembre de 2027 (Cuatrecasas). La 21.663 rige desde 2025 para servicios esenciales y operadores de importancia vital.	Nueva agencia de datos con poder sancionador. Deber de reportar incidentes al CSIRT Nacional para los sujetos de la 21.663.
Argentina	Ley 25.326 de Protección de Datos Personales	Vigente. Hay proyectos de reforma en el Congreso, sin sanción (abogados.com.ar).	Obligación general de adoptar medidas de seguridad y confidencialidad sobre las bases de datos.
Uruguay	Ley 18.331, con las reformas de la Ley 19.670 y el Decreto 64/020	Vigente.	Notificación de vulneraciones de seguridad a los titulares y a la URCDP, y principio de responsabilidad proactiva (IAPP).
Paraguay	Ley 7593/2025 de Protección de Datos Personales	Promulgada en noviembre de 2025, con aplicación plena prevista para noviembre de 2027 (Ferrere).	Primer marco integral del país, con agencia de control propia. Buen momento para diseñar accesos que ya cumplan.

Esta tabla es una referencia general, no asesoramiento legal. Cada empresa debe validar sus obligaciones con su asesor legal, en especial si opera en sectores regulados como banca, salud o servicios esenciales.

Caso real: el ransomware que afectó a municipios de todo el país

El 23 de octubre de 2026, un ataque de ransomware contra los servidores de Program Consultores S.A., empresa cordobesa que provee la plataforma de gestión PGM, dejó sin servicio sistemas de trámites y recaudación en municipios de varias provincias. La empresa atiende a más de 250 municipios y comunas en 11 provincias (La Vanguardia Noticias).

Lo que se sabe hasta ahora, según lo publicado:

El ataque se originó en los servidores centralizados del proveedor, no en la infraestructura de cada municipio.
Un programa malicioso cifró archivos y dejó inoperativos varios servidores. La empresa afirmó que no hubo robo ni filtración de datos (Carlos Paz Vivo).
Hubo reportes de pedidos de rescate y, días después, todavía no había fecha confirmada para la recuperación completa en todos los municipios (Telediario).
La vía de entrada no se hizo pública.

Qué nos enseña

Como no se conoce el vector de entrada, no corresponde afirmar que Zero Trust lo habría evitado. Sí se puede analizar qué controles reducen el impacto de un ataque así, que es lo que más costó en este caso.

Un solo punto de falla para cientos de clientes. Cuando un proveedor concentra la operación de muchos organismos, un compromiso en su red se multiplica. Para el proveedor, segmentar por cliente y por función limita cuántos servidores alcanza un mismo atacante.
Movimiento lateral. El ransomware necesita llegar a muchos servidores para paralizar un servicio. Con acceso por aplicación y sin red plana, una credencial o un equipo comprometido alcanza solo lo que su política permite, no todo el datacenter.
Acceso administrativo. Las cuentas con permisos para administrar servidores son el objetivo más valioso. Publicarlas detrás de un broker Zero Trust, con MFA resistente a phishing, verificación del dispositivo y sesiones registradas, sube mucho el costo para el atacante.
Accesos de terceros y soporte remoto. En una cadena proveedor-cliente suelen existir accesos de soporte en ambos sentidos. Pasarlos a ZTNA, con permisos por aplicación y vencimiento, evita que un incidente de un lado se propague al otro.
Recuperación. Zero Trust no reemplaza las copias de seguridad. Lo que permitió a algunos municipios recuperar sus bases fue contar con infraestructura y copias propias. Backups inmutables y fuera de línea siguen siendo obligatorios.

La lección para cualquier organización que dependa de un proveedor crítico es doble: exigirle controles de acceso y segmentación verificables, y tener un plan propio para operar si ese proveedor cae.

Checklist para evaluar si están listos

Antes de elegir una solución, conviene responder estas preguntas. Si más de la mitad quedan sin respuesta, el primer paso es el relevamiento, no la compra.

¿Tenemos inventario de qué aplicaciones se acceden por VPN y quién las usa?
¿Todos los usuarios tienen MFA, y no por SMS?
¿Hay un proveedor de identidad único para empleados?
¿Sabemos qué terceros tienen acceso remoto hoy, y hasta cuándo?
¿Podemos verificar el estado de los dispositivos que se conectan?
¿Tenemos una política definida para equipos personales?
¿Los registros de acceso se guardan y alguien los revisa?
¿Sabemos cuántos días tardamos en aplicar un parche crítico en el VPN?

Conclusión

El VPN no va a desaparecer de un día para el otro, pero ya no debería ser la puerta principal. Los datos de los últimos dos años muestran que los equipos de borde son un blanco prioritario, y que los parches llegan tarde.

Zero Trust ofrece un camino gradual: identidad fuerte, acceso por aplicación, controles sobre el dispositivo y registro de todo. Empezar por un piloto chico y medible es la mejor forma de demostrar el valor sin poner en riesgo la operación.

BlueSwing ayuda a empresas del Cono Sur a evaluar, diseñar e implementar el paso de VPN a Zero Trust. Más información en blueswing.xyz.