Zero Trust en una organización multi-cloud: más allá del marketing
Implementación práctica de los principios Zero Trust en una arquitectura con cargas en AWS, GCP y on-premise: identidad como perímetro, dispositivos verificados y políticas continuas.
Qué significa realmente Zero Trust
El término ha sido vaciado por el marketing. La definición operativa útil — la del NIST SP 800-207 — es: ninguna confianza implícita basada en ubicación de red; cada solicitud se evalúa contra identidad, postura del dispositivo, sensibilidad del recurso y contexto, y la decisión se reevalúa de forma continua. No es un producto, es un patrón arquitectónico.
Identidad como nuevo perímetro
Un IdP central (Okta, Entra ID, Google Workspace) federado contra AWS IAM Identity Center y GCP Workforce Identity, MFA resistente a phishing (WebAuthn, no SMS), y SCIM para desaprovisionamiento automático. El día que un empleado deja la empresa, su acceso a todo el estate desaparece en minutos, no en semanas.
Postura del dispositivo y acceso por aplicación
Cloudflare Access, Google BeyondCorp o equivalentes publican aplicaciones internas sin VPN, evaluando en cada request: identidad, MDM/EDR del dispositivo, geolocalización, hora. El usuario nunca entra a una red corporativa — entra a aplicaciones concretas, con un token de corta vida. La VPN tradicional se reserva para casos de acceso a infraestructura, y aun ahí con MFA y segmentación estricta.
Lo más difícil: workloads no humanos
El 80% del esfuerzo va a aplicar los mismos principios a comunicación servicio-a-servicio: SPIFFE/SPIRE para identidad criptográfica de cargas, mTLS por defecto en la malla de servicios, y políticas de autorización (OPA, Cedar) versionadas como código. Sin esto, el Zero Trust del usuario es un escaparate y la red interna sigue siendo plana para los atacantes que llegan al primer pod.