Arquitectura Zero Trust — Nunca Confíes, Siempre Verifica

Overview

Zero Trust es un modelo de seguridad que elimina el concepto de perímetro de red confiable. En lugar de asumir que el tráfico dentro de la red es seguro, Zero Trust verifica cada solicitud como si proviniera de una red no confiable. Cada usuario, dispositivo y aplicación debe ser autenticado, autorizado y continuamente validado antes de obtener acceso a recursos.

When to Use

• For alternatives, see Complete Guide to LLM Security.

• Tienes una fuerza laboral distribuida con necesidades de acceso remoto

• Estás migrando de una red basada en perímetro a arquitectura nativa de cloud

• Necesitas cumplir con requisitos regulatorios estrictos (SOC 2, ISO 27001, NIST)

• Quieres minimizar el radio de explosión de credenciales comprometidas

Principios Core

Verificar Explícitamente

Autenticar y autorizar cada solicitud de acceso basándose en todos los puntos de datos disponibles: identidad, salud del dispositivo, ubicación y detección de anomalías.

Usar Acceso de Privilegio Mínimo

Otorgar solo los permisos mínimos requeridos para la tarea específica y limitarlos temporalmente cuando sea posible.

Asumir Brecha

Diseñar sistemas como si un atacante ya estuviera dentro. Minimizar el radio de explosión mediante segmentación y encriptación.

Componentes de Arquitectura

Proveedor de Identidad (IdP)

La base de Zero Trust. Todas las decisiones de acceso comienzan con verificación de identidad fuerte.

┌─────────────┐
│   Usuario   │
└──────┬──────┘
       │
       ▼
┌─────────────────┐
│   MFA + Biométrico│  ◀── Paso 1: Verificar identidad
│   Atributos Dispositivo│
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│   Proveedor     │
│   de Identidad  │
│   (OAuth/OIDC)  │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│   Motor de      │  ◀── Paso 2: Evaluar contexto
│   Políticas     │
│   (OPA, Cedar)  │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│   Recurso       │  ◀── Paso 3: Otorgar acceso limitado
└─────────────────┘

Confianza del Dispositivo

Asegurar que solo dispositivos saludables y gestionados puedan acceder a recursos corporativos.

Señal	Qué Verifica	Ejemplo de Herramienta
Detección de endpoint	AV activo, sin malware	CrowdStrike, SentinelOne
Nivel de parcheo del OS	Últimas actualizaciones de seguridad	Intune, Jamf
Encriptación de disco	BitLocker/FileVault activo	Política de cumplimiento de dispositivo
Certificado	Dispositivo gestionado corporativamente	Certificado emitido por MDM

Micro-Segmentación

Dividir la red en zonas pequeñas e aisladas para que una brecha en una no se propague.

┌─────────────────────────────────────────────┐
│                    VPC                        │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐     │
│  │   Web   │  │   API   │  │   BD    │     │
│  │  Tier   │──│  Tier   │──│  Tier   │     │
│  │         │  │         │  │         │     │
│  └─────────┘  └─────────┘  └─────────┘     │
│       │            │            │         │
│  ┌────┴────┐  ┌────┴────┐  ┌────┴────┐     │
│  │  FW L7  │  │  FW L7  │  │  FW L7  │     │
│  │  + WAF  │  │  + AuthZ│  │  + AuthZ│     │
│  └─────────┘  └─────────┘  └─────────┘     │
└─────────────────────────────────────────────┘

Validación Continua

La confianza no es un evento único. Re-evaluar acceso basado en comportamiento.

# Pseudocódigo para evaluación continua de acceso
def evaluate_access(user, resource, context):
    risk_score = 0
    
    if context.location != user.usual_location:
        risk_score += 30
    if context.device_trust_score < 0.8:
        risk_score += 40
    if context.time_of_day not in user.working_hours:
        risk_score += 20
    
    if risk_score > 50:
        return Deny("Sesión de alto riesgo detectada")
    if risk_score > 20:
        return StepUpAuth("Verificación adicional requerida")
    
    return Allow()

Patrones de Implementación

BeyondCorp (Modelo Zero Trust de Google)

• Todo el acceso es mediado por un proxy de acceso
• El inventario y salud del dispositivo son prerequisitos
• La identidad del usuario está vinculada a un proveedor de identidad corporativo
• No se requiere VPN; el acceso es independiente de la ubicación

Perímetro Definido por Software (SDP)

• La red está oscura hasta que la autenticación tiene éxito
• Un broker de confianza valida la identidad antes de revelar IPs de recursos
• Todas las conexiones están encriptadas (mTLS)

Acceso de Red Zero Trust (ZTNA)

• Reemplaza VPN con acceso a nivel de aplicación
• Los usuarios obtienen acceso solo a aplicaciones específicas, no a toda la red
• Opciones de despliegue basadas en agente o sin agente

Pasos Prácticos de Implementación

1. Inventariar activos — datos, aplicaciones, dispositivos y segmentos de red
2. Mapear flujos de transacciones — cómo usuarios y servicios interactúan
3. Arquitecturar Zero Trust — diseñar puntos de aplicación de políticas
4. Desplegar proveedor de identidad — con MFA y acceso condicional
5. Implementar micro-segmentación — en las capas de aplicación y red
6. Monitorear y mejorar — usar SIEM y UEBA para detección de anomalías

Errores Comunes

• Comprar un producto y llamarlo Zero Trust — es una arquitectura, no un SKU
• Ignorar la experiencia de usuario — la fricción excesiva conduce a IT en la sombra
• Enfocarse solo en usuarios, no en servicios — el tráfico servicio-a-servicio también necesita identidad
• Sobre-segmentar — demasiadas zonas crean complejidad operacional
• Sin visibilidad — no puedes validar lo que no puedes monitorear

Troubleshooting

• Authentication bypass in tests: ensure test users cannot reach production endpoints. Use separate credentials and environments for CI.
• False positives in scanning tools: tune rules against the risk profile. Distinguish between reachable vulnerabilities and theoretical issues.
• Secrets appear in logs: configure log filters to redact tokens, passwords, and keys. Audit log sinks for sensitive patterns.
• CSP breaks legitimate functionality: use report-only mode first, then enforce. Iterate on allowed sources based on real violations.
• Incident response stalls: run tabletop exercises. Document escalation paths, evidence collection steps, and communication templates in advance.

FAQ

¿Zero Trust es solo para grandes empresas? No. Equipos pequeños pueden implementar principios core: MFA, privilegio mínimo y micro-segmentación con herramientas nativas de cloud.

¿Zero Trust reemplaza el firewall? Los firewalls se convierten en un punto de aplicación entre muchos. El perímetro se disuelve; cada recurso se convierte en su propio perímetro.

¿Cómo mido la madurez Zero Trust? Usa el Modelo de Madurez Zero Trust de CISA o el marco Zero Trust eXtended de Forrester. Ambos proveen etapas claras de legacy a avanzado.

¿Cómo empiezo con esto en un proyecto existente?

Empieza con una parte pequeña y aislada de tu codebase. Aplica los conceptos de esta guía a un módulo o servicio. Mide el impacto, luego expande a otras áreas.

¿Qué herramientas necesito?

Las herramientas mencionadas throughout esta guía se listan en cada sección. La mayoría son open-source y ampliamente adoptadas. Consulta los recursos relacionados para instrucciones de setup.

¿Cómo mido el éxito después de implementar esto?

Define métricas claras antes de empezar: benchmarks de rendimiento, tasas de error o indicadores de mantenibilidad. Compara antes y después. Itera basándote en datos, no en suposiciones.

Temas Avanzados

Escenario: Implementacion de Zero Trust para Microservicios

Sistema: 15 microservicios en Kubernetes, 500 usuarios
Objetivo: Arquitectura Zero Trust (sin confianza implicita)

Principios:
  1. Nunca confiar, siempre verificar
  2. Acceso de minimo privilegio
  3. Asumir compromiso (breach)
  4. Verificar explicitamente

Capas de arquitectura:
  | Capa | Componente | Implementacion |
  |------|-----------|----------------|
  | Identidad | OIDC + MFA | Keycloak + WebAuthn |
  | Dispositivo | Device posture check | Tanium / Intune |
  | Red | mTLS entre servicios | SPIFFE/SPIRE |
  | Aplicacion | RBAC + ABAC | OPA (Open Policy Agent) |
  | Datos | Cifrado en reposo + transito | KMS + TLS 1.3 |
  | Monitoreo | Audit log + SIEM | ELK + Falco |

mTLS entre servicios (SPIFFE):
  # Cada servicio obtiene una identidad criptografica
  # SPIRE agent en cada nodo emite SVID
  # Los servicios se autentican mutuamente via mTLS
  # No hay IPs confiables: la identidad es criptografica

  Servicio A -> mTLS -> Servicio B
    A presenta su SVID
    B verifica SVID contra trust bundle
    B presenta su SVID
    A verifica SVID contra trust bundle
    Comunicacion cifrada con TLS 1.3

Policy enforcement (OPA):
  # Reglas declarativas en Rego
  allow {
    input.user.role == "admin"
    input.action == "read"
    input.resource.environment == "production"
  }

  allow {
    input.user.team == input.resource.team
    input.action == "update"
  }

  # Denegar por defecto, permitir explicitamente
  # Cada request pasa por OPA sidecar

Flujo de acceso:
  Usuario -> IdP (OIDC + MFA) -> Token JWT
  Usuario -> API Gateway (valida JWT) -> Servicio A
    Servicio A -> OPA (policy check) -> autoriza?
    Servicio A -> mTLS -> Servicio B
    Servicio B -> OPA (policy check) -> autoriza?
    Servicio B -> DB (cifrado, minimo privilegio)

Fases de migracion:
  Fase 1: Identidad (OIDC + MFA para todos)
  Fase 2: Segmentacion de red (network policies K8s)
  Fase 3: mTLS entre servicios (SPIFFE/SPIRE)
  Fase 4: Policy enforcement (OPA sidecars)
  Fase 5: Monitoreo continuo (audit log + SIEM)

Lecciones:
  - Zero Trust es un viaje, no un switch
  - Empieza con identidad y MFA
  - mTLS elimina la confianza basada en red
  - OPA centraliza las politicas de autorizacion
  - Monitoreo continuo: asume que estas comprometido

Cuanto dura una migracion a Zero Trust?

Para una organizacion mediana (50-200 servicios), espera 12-18 meses. Fase 1 (identidad + MFA) toma 1-3 meses. Fase 2 (segmentacion de red) toma 2-4 meses. Fase 3 (mTLS) toma 3-6 meses. Fase 4 (policy enforcement) toma 2-4 meses. Fase 5 (monitoreo) es continua. Empieza con los servicios mas criticos primero.

End of document. Review and update quarterly.

Errores Comunes en Producción

• Tratar la guía como un checklist para completar una vez en lugar de una práctica por evolucionar.
• Adoptar cada recomendación de golpe en lugar de comenzar con un cambio medido.
• Saltar la evaluación de madurez e imponer prácticas avanzadas a un equipo no preparado.
• No actualizar runbooks y expectativas de guardia al introducir nuevas prácticas.
• Ignorar datos reales de incidentes al priorizar qué partes de la guía aplicar primero.
• No asignar un responsable que revise decisiones trimestralmente.
• Copiar ejemplos sin adaptarlos a las herramientas y restricciones reales del equipo.
• Olvidar medir resultados antes de agregar la siguiente mejora.