Zero Trust: el modelo de seguridad que asume que ya fuiste comprometido

Introducción al Problema#

Durante décadas, la arquitectura de seguridad empresarial se construyó sobre un supuesto implícito pero fundamentalmente incorrecto: todo lo que está dentro de la red corporativa es confiable. El firewall perimetral separa el mundo exterior (hostil) del interior (seguro). Una vez adentro — ya sea por estar físicamente en la oficina o conectado a la VPN — tenés acceso a los sistemas internos.

Este modelo tiene un nombre: castle-and-moat (castillo con foso). El castillo es la red interna, el foso es el firewall. Si cruzás el foso, estás en terreno seguro.

El problema es que ese supuesto colapsó hace años y todavía muchas organizaciones operan como si siguiera siendo válido. El trabajo remoto masificó el acceso desde redes domésticas no controladas. La nube movió sistemas críticos fuera del perímetro. Las integraciones con terceros y proveedores abrieron múltiples puntos de entrada. Y los atacantes aprendieron que es más fácil robar credenciales legítimas que atravesar el firewall — si pueden comprometer las credenciales de un usuario de VPN, están "adentro del foso" con las mismas credenciales que el empleado.

Zero Trust parte de la premisa opuesta: nunca confiar, siempre verificar (never trust, always verify). No existe una red "de confianza". Cada acceso a cada recurso debe ser verificado explícitamente, independientemente de desde dónde provenga.

Caso Real o Ejemplo Cotidiano#

En diciembre 2023, un proveedor externo de software de gestión de cambios para MGM Resorts tenía acceso VPN a la red interna de la empresa para soporte remoto. Las credenciales de ese acceso fueron comprometidas mediante ingeniería social. Con esas credenciales, los atacantes entraron a la red interna, se movieron lateralmente durante días — porque "adentro" todo era confiable — y terminaron comprometiendo sistemas críticos de operación hotelera.

En una arquitectura Zero Trust, ese escenario hubiera tenido múltiples puntos de corte:

• El acceso del proveedor hubiera estado microsegmentado: solo a los sistemas específicos que necesitaba, no a "la red".
• Cada acceso desde ese proveedor hubiera requerido verificación del dispositivo, no solo las credenciales.
• El movimiento lateral hubiera sido bloqueado porque cada recurso interno requiere re-verificación de identidad.
• La sesión larga sin re-autenticación hubiera sido detectada como anómala por el motor de confianza continua.

El perímetro no falló — las credenciales legítimas lo atravesaron correctamente. Falló el supuesto de que una vez adentro, todo era confiable.

Riesgos para la Empresa#

Explicación Técnica Sencilla#

Los tres principios de Zero Trust#

1. VERIFICAR EXPLÍCITAMENTE
   Todo acceso debe autenticarse y autorizarse
   en base a TODOS los datos disponibles:
   identidad del usuario + estado del dispositivo
   + ubicación + servicio + comportamiento.
   
2. MENOR PRIVILEGIO
   Cada usuario/aplicación tiene acceso solo
   a lo que necesita, solo cuando lo necesita.
   Acceso just-in-time, never-standing-privileges.

3. ASUMIR COMPROMISO
   Diseñá la arquitectura como si ya estuvieras
   comprometido. Segmentá para limitar el radio
   de explosión. Monitoreá para detectar movimiento.

VPN vs ZTNA: la evolución clave#

Microsegmentación: el foso dentro del castillo#

Si el modelo perimetral es "un foso grande alrededor del castillo", la microsegmentación es "un foso alrededor de cada habitación del castillo". Cada sistema, aplicación o segmento de red tiene su propio perímetro:

Sin microsegmentación:
  Atacante compromete PC de usuario → accede a servidores de base de datos
  → accede a sistemas de backup → accede a controladores de dominio
  
Con microsegmentación:
  Atacante compromete PC de usuario → bloqueado en el siguiente salto
  Necesita credenciales específicas + dispositivo válido + justificación
  para cada sistema siguiente. El radio de explosión = un endpoint.

Identidad como nuevo perímetro#

En Zero Trust, la identidad del usuario (y del dispositivo) reemplaza la IP de red como base de confianza:

Acceso a recurso en modelo tradicional:
  ¿Estás en la red interna? → Sí → Acceso concedido

Acceso a recurso en Zero Trust:
  ¿Quién sos? (MFA + certificado)
  ¿Qué dispositivo usás? (MDM health check, OS actualizado, EDR activo)
  ¿Desde dónde? (geolocalización, ASN, patrón histórico)
  ¿A qué necesitás acceso? (aplicación específica, no red)
  ¿Tiene sentido en contexto? (hora, volumen, patrón de comportamiento)
  → Solo entonces: Acceso concedido, con sesión limitada

Cómo Prevenirlo#

1. Inventariá los accesos de terceros antes de cambiar cualquier cosa. El mayor riesgo inmediato en la mayoría de las organizaciones son los accesos VPN de proveedores, partners e integradores que tienen acceso amplio a la red interna "para soporte". Listá todos estos accesos, revisá qué pueden alcanzar, y empezá a restringirlos — aunque todavía no tengas ZTNA, podés segmentar a qué llegan.

2. Implementá MFA en todos los accesos remotos sin excepciones. Zero Trust sin MFA es imposible. El primer paso concreto, antes de cualquier arquitectura, es MFA universal para acceso remoto. Sin MFA, la identidad es verificable solo por contraseña — insuficiente para cualquier modelo de confianza.

3. Evaluá Cloudflare Zero Trust o Tailscale como primer paso de ZTNA. Ambas tienen tiers gratuitos o muy accesibles para equipos pequeños. Permiten migrar un servicio a la vez desde la VPN tradicional a acceso por aplicación con verificación de identidad y dispositivo. No es una migración todo-o-nada — podés empezar por los accesos más críticos (servidor de BD, sistema de nómina, acceso de terceros).

4. Adoptá el principio de menor privilegio en cuentas de servicio y usuarios. Auditá qué acceso tiene cada cuenta: ¿los empleados de soporte de Mesa de Ayuda necesitan acceso a las bases de datos de producción? ¿Las aplicaciones tienen acceso de escritura a carpetas que solo necesitan leer? Reducir privilegios existentes es Zero Trust sin infraestructura nueva.

5. Incorporá el estado del dispositivo como condición de acceso. Configurá políticas en el Identity Provider (Entra ID, Okta) que bloqueen el acceso desde dispositivos que no cumplan condiciones mínimas: OS actualizado, EDR activo, disco cifrado. Esto evita que un dispositivo personal comprometido use credenciales corporativas válidas para acceder a sistemas internos.

6. Definí una política de re-autenticación para sesiones largas. Configurar sesiones que no expiran es una deuda de seguridad. En sistemas críticos, forzá re-autenticación cada 4-8 horas o ante cambios de contexto (nueva IP, horario inusual). Esto no es "ser paranoico" — es la base del modelo de confianza continua de Zero Trust.

Herramientas Recomendadas#

Cloudflare Zero Trust (cloudflare.com/zero-trust): Suite completa de ZTNA + Secure Web Gateway + DNS filtering. El tier gratuito cubre hasta 50 usuarios con todas las capacidades de acceso por aplicación, reemplazo de VPN y filtrado de tráfico. Para organizaciones más grandes, los precios son muy competitivos frente a soluciones legacy. La integración con cualquier IdP (Google Workspace, Microsoft Entra, Okta) es directa. Punto de entrada recomendado para organizaciones sin experiencia previa en Zero Trust.

Zscaler Private Access (zscaler.com): Solución enterprise de referencia para ZTNA. Los usuarios nunca se conectan a la red corporativa — se conectan a Zscaler, que actúa como proxy inteligente hacia las aplicaciones específicas que están autorizados a usar. Sin VPN, sin exposición de red. Liderazgo en Gartner SSE. Solución para organizaciones medianas y grandes con equipo de seguridad dedicado.

BeyondCorp Enterprise (cloud.google.com/beyondcorp): La implementación de Google del modelo Zero Trust que inventaron para uso interno después del incidente Operation Aurora (2010). Se integra nativamete con Google Workspace y Google Cloud. Incluye evaluación de confianza del dispositivo, acceso a aplicaciones internas y on-premise via ZTNA, y controles de DLP. Opción natural para organizaciones centradas en Google Cloud.

Tailscale (tailscale.com): Solución de VPN mesh basada en WireGuard con filosofía Zero Trust. Cada dispositivo se conecta directamente a otros dispositivos autorizados (sin servidor central de routing), usando identidades de Google/GitHub/Microsoft como base de autenticación. El tier gratuito cubre 3 usuarios con dispositivos ilimitados. Ideal para equipos técnicos pequeños, acceso entre servidores, y como primer paso hacia reemplazar VPN tradicional con acceso por dispositivo verificado.

Checklist Final#

• Se tiene un inventario completo de todos los accesos VPN externos (empleados remotos, proveedores, integradores)
• MFA está habilitado para el 100% de los accesos remotos, sin excepciones
• Los accesos de terceros están restringidos a los sistemas que necesitan, no a la red completa
• Existe una política de menor privilegio documentada y revisada en los últimos 12 meses
• Las cuentas de servicio tienen acceso mínimo necesario (no admin por defecto)
• El estado de salud del dispositivo se valida como condición de acceso (OS actualizado, EDR activo)
• Las sesiones de acceso remoto tienen tiempo de vida limitado y re-autenticación forzada
• Se evaluó al menos una solución ZTNA como alternativa o complemento a la VPN actual
• Existe segmentación de red que evita movimiento lateral sin re-autenticación
• Los logs de acceso están centralizados y tienen retención mínima de 90 días
• El equipo comprende la diferencia entre "conectado a la VPN" y "acceso autorizado al recurso"

CVE / Vulnerabilidades Relacionadas#

CVE-2025-12480 — Bypass de autenticación en solución VPN corporativa#

CVE-2025-12480 afecta a un appliance VPN corporativo de uso extendido, permitiendo a un atacante no autenticado en la red pública bypassear el mecanismo de autenticación y obtener acceso a la red interna sin credenciales válidas. Esta clase de vulnerabilidad ilustra perfectamente el problema estructural del modelo perimetral: si el dispositivo que guarda el foso tiene una vulnerabilidad explotable desde internet, el "adentro es confiable" se convierte en un vector de ataque.

Lección operativa: Los dispositivos perimetrales (VPN gateways, firewalls, proxies) deben ser los primeros en la cola de parches — son el objetivo de mayor valor para los atacantes porque un compromiso exitoso da acceso implícito a todo lo que está "adentro". CISA y organismos equivalentes publican regularmente alertas sobre CVEs activamente explotados en dispositivos de red perimetrales; suscribirse a esas alertas y tener un SLA de parcheo de 24-72hs para estas categorías no es opcional.

La ironía que Zero Trust resuelve estructuralmente: si cada acceso interno requiere re-verificación, el compromiso del gateway VPN no da acceso automático a los sistemas internos — el atacante igual tiene que autenticarse contra cada recurso.

Conclusión y CTA#

El perímetro de red murió como concepto de seguridad. No mañana, no cuando termines la migración a la nube — murió cuando el primer empleado empezó a trabajar desde su casa con su notebook personal, cuando el primer proveedor se conectó a VPN para "hacer soporte", cuando el primer sistema crítico se movió a SaaS.

Zero Trust no es un producto que comprás e instalás. Es un modelo de diseño que implementás incrementalmente, empezando por los accesos más críticos y de mayor riesgo. El primer paso no cuesta nada: inventariá quién tiene acceso a qué, activá MFA universal, y revisá si los accesos de terceros están justificados y restringidos al mínimo necesario.

¿Querés evaluar el estado de tu arquitectura de acceso y trazar un roadmap de migración a Zero Trust? Hablá con nuestro equipo o seguí con el siguiente artículo: Seguridad en la nube: los errores más costosos en AWS, Azure y Google Cloud.