Zero Trust: principios para dejar de confiar en la red

Cerradura digital sobre código binario representando seguridad

Zero Trust se ha convertido en uno de los términos más vendidos por proveedores de seguridad en los últimos años. Cada producto se presenta como “la solución Zero Trust definitiva”. La realidad es que Zero Trust no es un producto, es una arquitectura que se implementa con muchas piezas. Cubrimos los principios reales detrás del nombre, la diferencia con seguridad perimetral, y errores típicos en su adopción.

El cambio de paradigma

La seguridad perimetral clásica asume:

  • Hay una “red interna confiable” detrás del firewall.
  • Una “red externa peligrosa” fuera.
  • Si estás dentro, eres confiable; si estás fuera, autenticas para entrar.

Este modelo lleva décadas. Funcionaba en oficinas con desktops cableados y datacenter local. Pero falla en 2023:

  • Empleados trabajando desde casa, cafeterías, viajes — el “perímetro” desaparece.
  • SaaS y cloud — recursos críticos viven fuera del firewall.
  • Atacantes que comprometen un único endpoint dentro del perímetro y se mueven lateralmente con confianza implícita.
  • Fugas internas — el modelo de “dentro = confiable” no protege contra abusos legítimos de credenciales válidas.

Zero Trust elimina la suposición de confianza por ubicación. Cada solicitud se verifica como si viniera de una red no confiable, independientemente de dónde se origina.

Los cinco principios

Distintas fuentes formulan Zero Trust ligeramente diferente. Una síntesis clara:

1. Verificar explícitamente

Cada acceso requiere autenticación y autorización fuerte. No hay “tickets de confianza” implícitos. Combinar identidad de usuario, identidad del dispositivo, contexto (hora, ubicación, comportamiento) y riesgo evaluado.

En la práctica: MFA siempre, no solo en login inicial; tokens de corta duración; reautenticación para acciones sensibles.

2. Mínimo privilegio

Cada identidad recibe los permisos mínimos necesarios para su función actual, no más. Y los recibe just-in-time — concedidos cuando se necesitan, retirados después.

En la práctica: roles granulares, permisos temporales para tareas administrativas, revisión periódica de permisos acumulados.

3. Asumir compromiso

Diseña pensando que ya hay un atacante dentro de la red. La pregunta no es “¿cómo evito que entren?” sino “¿qué puede hacer un atacante que ya entró antes de que lo detecte?”.

En la práctica: microsegmentación, monitoreo de movimientos laterales, detección de anomalías de comportamiento.

4. Validar el dispositivo

No basta con que el usuario sea legítimo — el dispositivo desde el que accede también debe estar en estado conocido y conforme. Sin parche crítico, sin antivirus, sin disco cifrado: acceso restringido o negado.

En la práctica: MDM/EDR que reporta postura del dispositivo; políticas de acceso condicionadas a esa postura.

5. Visibilidad y analítica continua

Sin telemetría rica y análisis continuo, los principios anteriores son aspiraciones. Logs centralizados, métricas de comportamiento normal, alertas sobre desviaciones.

En la práctica: SIEM, UEBA (User and Entity Behavior Analytics), respuesta automatizada a indicadores claros.

El caso BeyondCorp de Google

BeyondCorp es la implementación más documentada y referenciada de Zero Trust. Google lo construyó tras el incidente de 2009 (operación Aurora). Los principios prácticos:

  • Eliminado el VPN para empleados internos. Acceso a aplicaciones internas se hace vía Internet con autenticación fuerte.
  • Identidad del dispositivo comprobada en cada acceso (certificados x509 instalados en cada dispositivo corporativo).
  • Acceso condicional basado en postura del dispositivo, identidad del usuario, contexto.
  • Sin “red de confianza”. La red corporativa interna recibe el mismo trato que Internet pública.

Para Google funcionó porque tenían escala para construir la infraestructura. Para empresas más pequeñas, productos como Cloudflare Access, Tailscale, ZScaler, o Microsoft Entra Conditional Access ofrecen capas similares sin construir desde cero.

Errores comunes en adopción

Después de varios proyectos, los errores que más se repiten:

  • Comprar un producto y declarar Zero Trust. Ningún producto te da Zero Trust. La implementación involucra cambios en identidad, dispositivos, red, aplicaciones y procesos.
  • Empezar por todo a la vez. Cubrir cada aplicación con políticas Zero Trust desde el día uno colapsa al equipo. Empieza por una aplicación crítica o un grupo de usuarios.
  • Olvidar el factor humano. MFA agresivo y reautenticaciones frecuentes pueden ser legítimas pero también enfurecer a usuarios. Encuentra el balance — fricción donde importa, no en todo.
  • MFA sin verificar el dispositivo. MFA sobre un dispositivo comprometido sigue siendo vulnerable. Si solo añades MFA, no estás haciendo Zero Trust completo.
  • Sin telemetría de comportamiento. Sin visibilidad continua, los principios son teóricos. Inversión en logging y análisis es parte fundamental.
  • No proteger los servicios entre sí. Microservicios que confían unos en otros porque “están en la misma VPC” reproducen el modelo perimetral a escala interna. Servicio-a-servicio también necesita autenticación mutua (mTLS) y autorización.

Roadmap pragmático

Una secuencia razonable para empezar:

  1. MFA universal para todos los empleados, todos los servicios. Es la pieza más impactante con esfuerzo más manejable.
  2. Single Sign-On centralizado (Authentik, Okta, Microsoft Entra) — reduce friction y permite políticas consistentes.
  3. Identidad del dispositivo vía MDM y certificados.
  4. Eliminar VPN para apps internas web vía un proxy de identidad (Cloudflare Access, Authentik con forward auth).
  5. Microsegmentación de la red interna con políticas explícitas — empezar por separar producción de desarrollo.
  6. Service-to-service mTLS vía service mesh (Istio, Linkerd) o sidecar manual.
  7. SIEM y detección continua sobre todo lo anterior.

Cada paso es proyecto en sí mismo. Una organización media tarda 2-4 años en cubrir el roadmap completo.

Conclusión

Zero Trust es un cambio cultural y arquitectónico, no una compra. Bien implementado, reduce drásticamente el blast radius de incidentes y se adapta mejor a la realidad de trabajo distribuido y cloud. Mal implementado — comprando un producto y declarando victoria — solo añade fricción sin mejorar protección. Empieza por el principio que más impacto tenga en tu contexto, mide, y avanza incremental.

Síguenos en jacar.es para más sobre arquitectura de seguridad, identidad y modelos modernos de defensa.

Entradas relacionadas