Zero Trust Architecture

Durante años, la seguridad de muchas empresas se basó en una idea simple: dentro de la red corporativa se confía; fuera, no. Firewall en el perímetro, VPN para entrar “dentro”, y una vez dentro, acceso relativamente amplio a servicios internos. Ese modelo se ha vuelto frágil: usuarios remotos, dispositivos personales, cloud, y ataques que una vez dentro del perímetro se mueven lateralmente sin mucha resistencia. Zero Trust es un enfoque distinto: nadie es de confianza por defecto, ni por estar “dentro” de la red ni por estar “fuera”. Cada acceso se verifica, se autoriza y se limita según identidad, dispositivo y contexto.

En este artículo explico qué es Zero Trust, por qué tiene sentido en redes internas y cómo aplicarlo en la práctica sin tener que rehacer todo de golpe.

El modelo tradicional: confiar en la red

En el modelo clásico:

• Perímetro: Un firewall (o varios) separa “internet” de “red interna”. Lo que está dentro se considera más seguro.
• VPN: Los usuarios remotos se conectan por VPN y “entran” a la red interna; desde ahí acceden a servicios como si estuvieran en la oficina.
• Confianza implícita: Una vez dentro (físicamente o por VPN), se asume que el usuario o el dispositivo son legítimos y se les da acceso amplio a recursos internos.

Problemas de este modelo:

• Un solo punto de compromiso: Si un atacante entra (phishing, credenciales robadas, dispositivo infectado), está “dentro” y puede moverse lateralmente (pasar de un servidor a otro, de un usuario a otro) con poca verificación adicional.
• Red interna = zona de confianza: Cualquier servicio que escuche solo en la red interna asume que quien se conecta es de fiar. No hay verificación de identidad por solicitud.
• Dispositivos y redes heterogéneas: Hoy la “red interna” se extiende a casas, cafés y clouds. El perímetro ya no es claro; confiar en “estar dentro” deja de tener sentido.

Qué es Zero Trust

Zero Trust no es un producto sino un principio: never trust, always verify. Es decir:

• No confíes en la red: Que una petición venga “de la red interna” no basta para dar acceso. La red no es la frontera de confianza.
• Verifica cada acceso: Cada solicitud (a un API, a un servicio, a un archivo) debe estar asociada a una identidad verificada (usuario, servicio, dispositivo) y a un contexto (rol, ubicación, estado del dispositivo, etc.).
• Mínimo privilegio: Solo se concede el acceso estrictamente necesario para esa identidad y ese contexto, y por el tiempo necesario.
• Asume brecha: Diseña como si el atacante ya estuviera dentro. Segmenta, limita el movimiento lateral y exige verificación continua.

En la práctica, Zero Trust implica:

• Identidad como eje: autenticación fuerte (MFA), identidad de dispositivos y de servicios, no solo “IP interna”.
• Autorización por solicitud: Cada acceso a un recurso se autoriza según políticas (quién es, qué rol tiene, desde dónde, con qué dispositivo).
• Segmentación: La red y los servicios se dividen en segmentos; el acceso entre segmentos también se verifica y se limita.
• Visibilidad y monitoreo: Logs, métricas y alertas para detectar comportamientos anómalos (accesos inusuales, movimiento lateral).

Cómo aplicarlo en la práctica

No hace falta “implementar Zero Trust” de golpe. Se puede ir por fases:

1. Identidad y MFA: Asegurar que todo acceso a sistemas críticos pase por identidad verificada (SSO, MFA). Sin MFA, un atacante con credenciales robadas tiene las mismas capacidades que el usuario legítimo.
2. Acceso a aplicaciones, no a la red: En lugar de dar acceso “a la red” por VPN y dejar que el usuario navegue por todo lo interno, exponer aplicaciones concretas (por ejemplo, mediante un proxy o un acceso app-by-app) y exigir autenticación y autorización por aplicación.
3. Políticas de acceso: Definir quién puede acceder a qué (por rol, por grupo, por contexto). Revisar y reducir permisos amplios (“todos los de la red interna”).
4. Segmentación: Separar entornos (dev, staging, prod) y servicios críticos; que el acceso entre segmentos pase por controles (firewall de aplicación, API gateway, identidad de servicio).
5. Dispositivos y estado: Donde sea posible, considerar el estado del dispositivo (parcheado, sin malware conocido, cumplimiento de política) como parte del contexto de autorización.
6. Logs y monitoreo: Registrar accesos y decisiones de autorización; alertar ante patrones anómalos (acceso desde ubicación nueva, muchos fallos de auth, acceso a recursos sensibles inusual).

Herramientas y servicios que suelen aparecer en diseños Zero Trust: proveedores de identidad (Okta, Auth0, Azure AD), proxies de acceso (Zscaler, Cloudflare Access), segmentación de red (microsegmentación), y gestión de dispositivos (MDM). Pero el núcleo es el principio: no confiar en la red, verificar identidad y contexto, y dar el mínimo acceso necesario.

Mi perspectiva personal

Zero Trust no es “comprar un producto Zero Trust”; es cambiar el modelo mental: dejar de asumir que “estar dentro de la red” es suficiente para confiar. En redes internas, eso implica que cada servicio y cada acceso se piensen con “¿quién está pidiendo esto y por qué debería tener permiso?”, no con “viene de la IP interna”.

Aplicarlo de forma gradual (identidad y MFA primero, luego políticas por aplicación, luego segmentación) suele ser más realista que un big bang. El objetivo es que, incluso si un atacante obtiene credenciales o está “dentro” de la red, el daño esté limitado: no puede moverse libremente porque cada salto exige verificación y solo tiene el acceso que las políticas permiten para esa identidad y ese contexto.

En resumen: nadie es de confianza por defecto. La confianza se gana en cada solicitud, con identidad, contexto y mínimo privilegio. Eso es Zero Trust en esencia.