Zero Trust

Definición

Zero Trust es una arquitectura de seguridad basada en el principio “nunca confíes, siempre verifica.” A diferencia de la seguridad tradicional basada en perímetro (que asume que todo dentro de la red corporativa es seguro), Zero Trust asume que las amenazas existen tanto fuera como dentro de la red. Cada petición de acceso - ya sea de un dispositivo en la oficina, un trabajador remoto, o un microservicio interno - debe ser autenticada, autorizada y continuamente validada antes de otorgar acceso a recursos. La ubicación, red o autenticación previa no otorgan confianza implícita.

La filosofía emergió de la realidad de la computación moderna: las redes son planas, los empleados trabajan remotamente, las aplicaciones corren en la nube, y los atacantes están dentro del perímetro (vía phishing, credenciales comprometidas o ataques de cadena de suministro). El viejo modelo de “castillo-y-foso” (perímetro duro, interior blando) está obsoleto. Zero Trust en cambio construye seguridad alrededor de identidad y contexto - quién hace la petición, desde qué dispositivo, para acceder a qué recurso, bajo qué condiciones. Cada decisión de acceso se toma dinámicamente basada en evaluación de riesgo.

Zero Trust no es un solo producto o tecnología; es una filosofía arquitectónica implementada a través de múltiples tecnologías: autenticación multifactor (MFA), controles de acceso de privilegio mínimo, microsegmentación, monitoreo continuo, gestión de identidad y acceso (IAM), y verificación de salud del dispositivo. Para APIs, esto significa que cada petición debe llevar un token válido y verificado (incluso de servicios internos), las verificaciones de autorización ocurren en cada operación, y todo acceso es registrado para auditoría y detección de anomalías.

Ejemplo

Google BeyondCorp: Google implementó Zero Trust después de los ataques Aurora. Cada petición de empleado - incluso desde una oficina de Google - debe autenticarse vía MFA y pasar verificaciones de salud del dispositivo. No hay VPN o “red interna de confianza.” Los empleados acceden a herramientas internas (email, docs, repositorios de código) vía internet usando controles de acceso basados en identidad. Esto habilita trabajo desde cualquier lugar mientras mantiene la seguridad.

Microservicios de Netflix: Los microservicios de Netflix no se confían entre sí por defecto. Cada llamada de API servicio-a-servicio requiere autenticación mutual TLS (mTLS). El servicio de facturación no puede llamar al servicio de pago sin probar su identidad vía certificados. Esto previene movimiento lateral si un servicio se ve comprometido.

API Bancaria: Una app móvil de un banco hace llamadas de API para verificar saldos de cuenta. Aunque el usuario se autenticó al iniciar sesión, cada petición de API incluye un token JWT fresco. La API valida el token, verifica si está expirado, verifica la firma, y confirma que el usuario aún tiene permisos (cuenta no congelada, usuario no eliminado). La autenticación pasada no otorga acceso futuro.

Sistema de Registros de Salud: Un doctor accediendo a registros de pacientes debe autenticarse con MFA, su dispositivo debe pasar verificaciones de cumplimiento de seguridad (disco cifrado, OS actualizado, sin jailbreak), y el acceso se otorga solo a pacientes que está tratando actualmente. Si las credenciales del doctor son robadas, el dispositivo no conforme del atacante y patrones de acceso inusuales disparan bloqueos.

Infraestructura Cloud: AWS implementa Zero Trust con roles IAM. Una instancia EC2 ejecutando tu app no tiene acceso automático a buckets S3 o bases de datos. Cada instancia debe asumir un rol IAM con permisos explícitamente otorgados. Incluso si un atacante compromete la instancia, no puede acceder a otros recursos sin credenciales IAM válidas.

Analogía

El Sistema de Seguridad del Museo: La seguridad tradicional es como un museo con guardias en la puerta principal. Una vez dentro, puedes deambular por cualquier lugar. Zero Trust es como un museo donde cada sala requiere deslizar una credencial. Tu credencial se verifica contra la lista de acceso actual para esa sala específica, y guardias monitorean cámaras para comportamiento sospechoso incluso si tienes acceso válido.

El Aeropuerto vs. El Hotel: La seguridad tradicional es como un hotel - muestra ID al registrarte, luego deambulas libremente. Zero Trust es como un aeropuerto - muestra ID al registrarte, nuevamente en seguridad, nuevamente en la puerta, y nuevamente al abordar el avión. Cada punto de control verifica tu boleto e identidad independientemente. La verificación pasada no te exime de verificaciones futuras.

La Bóveda del Banco con Compartimentos: La seguridad antigua es una gran bóveda con una cerradura. Zero Trust es una bóveda con cajas de seguridad individuales, cada una requiriendo su propia llave. Un empleado con acceso a la caja 1 no puede abrir la caja 2 sin la llave específica. Incluso el gerente del banco necesita llaves explícitas para cada caja.

El Sistema de Credenciales del Hospital: El personal del hospital usa credenciales con diferentes colores y chips embebidos. Cada departamento (emergencias, farmacia, quirófanos) tiene lectores de puertas que verifican el chip. La credencial de una enfermera podría otorgar acceso a habitaciones de pacientes pero no a la farmacia. Si una credencial es robada, se desactiva inmediatamente de forma remota, y los logs de acceso ayudan a rastrear dónde fue el ladrón.

Ejemplo de Código

// Implementación de API Zero Trust con múltiples capas de verificación
import express from 'express';
import jwt from 'jsonwebtoken';
import { createHash } from 'crypto';

const app = express();

// Capa 1: Aplicación de TLS/mTLS
app.use((req, res, next) => {
  // Requerir HTTPS
  if (!req.secure && process.env.NODE_ENV === 'production') {
    return res.status(403).json({
      error: 'HTTPS requerido',
      message: 'Todas las peticiones deben usar cifrado TLS'
    });
  }

  // Verificar certificado de cliente (mTLS para servicio-a-servicio)
  if (req.path.startsWith('/internal/')) {
    const cert = req.socket.getPeerCertificate();
    if (!cert || !cert.subject) {
      return res.status(401).json({
        error: 'Certificado de cliente requerido',
        message: 'APIs internas requieren autenticación mutual TLS'
      });
    }
    req.serviceName = cert.subject.CN; // Common Name identifica el servicio
  }

  next();
});

// Capa 2: Autenticación - verificar token JWT
async function authenticate(req, res, next) {
  const token = req.headers.authorization?.replace('Bearer ', '');

  if (!token) {
    return res.status(401).json({
      error: 'Autenticación requerida',
      message: 'Token de autenticación faltante o inválido'
    });
  }

  try {
    const decoded = jwt.verify(token, process.env.JWT_PUBLIC_KEY, {
      algorithms: ['RS256'],
      issuer: 'https://auth.company.com',
      audience: 'api.company.com'
    });

    // Verificar que el token no esté revocado (Zero Trust: verificar cada vez)
    const isRevoked = await checkTokenRevocation(decoded.jti);
    if (isRevoked) {
      return res.status(401).json({
        error: 'Token revocado',
        message: 'Este token ha sido revocado'
      });
    }

    req.user = decoded;
    next();
  } catch (err) {
    return res.status(401).json({
      error: 'Token inválido',
      message: 'Verificación de token falló'
    });
  }
}

// Capa 3: Verificación de Salud del Dispositivo (principio Zero Trust)
async function verifyDeviceHealth(req, res, next) {
  const deviceId = req.headers['x-device-id'];
  const deviceFingerprint = req.headers['x-device-fingerprint'];

  if (!deviceId || !deviceFingerprint) {
    return res.status(403).json({
      error: 'Verificación de dispositivo requerida',
      message: 'Todas las peticiones deben incluir identificación de dispositivo'
    });
  }

  // Verificar estado de cumplimiento del dispositivo
  const device = await getDeviceStatus(deviceId);

  if (!device) {
    return res.status(403).json({ error: 'Dispositivo desconocido' });
  }

  if (device.status === 'compromised' || device.status === 'non_compliant') {
    await logSecurityEvent('blocked_non_compliant_device', {
      deviceId,
      userId: req.user.id,
      reason: device.status
    });

    return res.status(403).json({
      error: 'Dispositivo no conforme',
      message: 'Tu dispositivo no cumple con los requisitos de seguridad'
    });
  }

  req.device = device;
  next();
}

// Capa 4: Autorización Consciente del Contexto
async function authorize(requiredPermissions) {
  return async (req, res, next) => {
    // Verificar permisos de usuario
    const hasPermissions = requiredPermissions.every(p =>
      req.user.permissions.includes(p)
    );

    if (!hasPermissions) {
      return res.status(403).json({
        error: 'Permisos insuficientes',
        required: requiredPermissions
      });
    }

    // Zero Trust: Verificar factores de riesgo contextuales
    const riskScore = await calculateRiskScore({
      userId: req.user.id,
      ip: req.ip,
      location: req.headers['x-geo-location'],
      device: req.device,
      time: new Date(),
      resource: req.path
    });

    // Alto riesgo requiere autenticación step-up
    if (riskScore > 75) {
      const hasRecentMFA = await checkRecentMFA(req.user.id);
      if (!hasRecentMFA) {
        return res.status(403).json({
          error: 'Autenticación step-up requerida',
          message: 'Alto riesgo detectado. Por favor re-autentica con MFA.',
          challenge_url: '/api/auth/mfa-challenge'
        });
      }
    }

    // Registrar decisión de autorización para auditoría
    await logAccess({
      userId: req.user.id,
      resource: req.path,
      action: req.method,
      granted: true,
      riskScore,
      timestamp: new Date()
    });

    next();
  };
}

// Capa 5: Autorización a Nivel de Objeto (nunca omitir)
async function verifyResourceOwnership(req, res, next) {
  const resourceId = req.params.id;
  const resource = await db.findResource(resourceId);

  if (!resource) {
    return res.status(404).json({ error: 'Recurso no encontrado' });
  }

  // Zero Trust: Verificar propiedad en CADA petición
  if (resource.ownerId !== req.user.id && !req.user.permissions.includes('admin')) {
    await logSecurityEvent('unauthorized_access_attempt', {
      userId: req.user.id,
      resourceId,
      ownerId: resource.ownerId
    });

    return res.status(403).json({
      error: 'Prohibido',
      message: 'No tienes acceso a este recurso'
    });
  }

  req.resource = resource;
  next();
}

// Endpoint de API Zero Trust
app.get('/api/sensitive-data/:id',
  authenticate,              // Capa 2: ¿Quién eres?
  verifyDeviceHealth,        // Capa 3: ¿Tu dispositivo es seguro?
  authorize(['read:data']),  // Capa 4: ¿Qué puedes hacer?
  verifyResourceOwnership,   // Capa 5: ¿Puedes acceder a ESTE recurso?
  async (req, res) => {
    // Todas las capas pasadas - otorgar acceso
    res.json({
      data: req.resource,
      metadata: {
        accessGrantedAt: new Date(),
        riskScore: req.riskScore
      }
    });
  }
);

// Helper: Calcular puntuación de riesgo basada en contexto
async function calculateRiskScore(context) {
  let score = 0;

  // Dirección IP inusual
  const isKnownIP = await checkIPReputation(context.ip);
  if (!isKnownIP) score += 30;

  // Ubicación inusual
  const normalLocation = await getUserNormalLocation(context.userId);
  if (context.location !== normalLocation) score += 25;

  // Acceso fuera de horas
  const hour = context.time.getHours();
  if (hour < 6 || hour > 22) score += 15;

  // Dispositivo no conforme
  if (context.device.lastSecurityScan > 7 * 24 * 60 * 60 * 1000) score += 20;

  // Recurso sensible
  if (context.resource.includes('admin') || context.resource.includes('payment')) {
    score += 10;
  }

  return Math.min(score, 100);
}

Diagrama

graph TB
    subgraph User["Usuario / Cliente"]
        U[Dispositivo de Usuario]
        A[Aplicación]
    end

    subgraph ZeroTrust["Plano de Control Zero Trust"]
        DP[Verificación de Postura de Dispositivo
Versión OS, cifrado, nivel de parche]
        IA[Identidad y Autenticación
MFA, SSO, verificación JWT]
        CA[Análisis de Contexto
Ubicación, tiempo, comportamiento]
        PA[Motor de Políticas
Decisiones basadas en riesgo]
    end

    subgraph Authorization["Capa de Autorización"]
        RBAC[Acceso Basado en Roles
Verificación de permisos]
        ABAC[Acceso Basado en Atributos
Contexto + Puntuación de riesgo]
        OLA[Auth Nivel Objeto
Propiedad de recurso]
    end

    subgraph Resources["Recursos Protegidos"]
        API1[API: Datos de Usuario]
        API2[API: Pagos]
        DB[(Base de Datos)]
        S3[Almacenamiento de Archivos]
    end

    subgraph Monitoring["Monitoreo Continuo"]
        SIEM[SIEM / Analíticas]
        Audit[Logs de Auditoría]
        Alert[Alertas y Respuesta]
    end

    U --> DP
    U --> IA

    DP --> PA
    IA --> PA
    CA --> PA

    PA -->|Puntuación Riesgo < 50| RBAC
    PA -->|Riesgo 50-75| ABAC
    PA -->|Riesgo > 75| MFA[Requerir MFA Step-Up]

    RBAC --> OLA
    ABAC --> OLA
    MFA --> OLA

    OLA -->|Autorizado| API1
    OLA -->|Autorizado| API2
    OLA -->|Denegado| Block[403 Prohibido]

    API1 --> DB
    API2 --> DB
    API1 --> S3

    DP --> Audit
    IA --> Audit
    PA --> Audit
    OLA --> Audit

    Audit --> SIEM
    SIEM --> Alert
    Alert -.Auto-Bloqueo de Amenazas.-> PA

    style DP fill:#e6f3ff
    style IA fill:#e6f3ff
    style PA fill:#ffe6e6
    style RBAC fill:#fffbe6
    style ABAC fill:#fffbe6
    style OLA fill:#fffbe6
    style Block fill:#ffcccc
    style SIEM fill:#f3e6ff

Notas de Seguridad

Mejores Prácticas

1. Verificar Cada Petición: Nunca asumas que una autenticación previa exitosa otorga acceso futuro. Valida tokens, permisos y contexto en cada llamada de API.

2. Autenticación Multifactor (MFA): Requiere MFA para todos los usuarios, especialmente para operaciones privilegiadas. Usa TOTP, llaves de hardware (FIDO2), o biometría.

3. Acceso de Privilegio Mínimo: Otorga a usuarios/servicios solo los permisos mínimos necesarios. Denegar por defecto, permitir explícitamente. Revisa permisos trimestralmente.

4. Verificaciones de Postura de Dispositivo: Verifica que los dispositivos cumplan requisitos de seguridad (disco cifrado, OS actualizado, sin jailbreak, software de seguridad instalado) antes de otorgar acceso.

5. Microsegmentación: Aísla cargas de trabajo y servicios. Usa políticas de red, grupos de seguridad y service meshes para prevenir movimiento lateral.

6. Monitoreo Continuo: Registra todos los intentos de acceso (exitosos y fallidos). Usa herramientas SIEM para detectar anomalías y responder automáticamente.

7. Autorización Consciente del Contexto: Toma decisiones de autorización basadas en múltiples factores: identidad, dispositivo, ubicación, tiempo, sensibilidad del recurso, patrones de comportamiento.

8. Mutual TLS (mTLS): Para comunicación servicio-a-servicio, usa mTLS para verificar identidades tanto de cliente como de servidor vía certificados.

9. Acceso Just-In-Time (JIT): Otorga privilegios elevados solo cuando sea necesario, por tiempo limitado. Auto-revoca después de que expire la ventana de tiempo.

10. Zero Trust Network Access (ZTNA): Reemplaza VPNs con acceso basado en identidad. Los usuarios se autentican en un plano de control que intermedia conexiones a recursos específicos.

Errores Comunes

Confiar en Redes Internas: Asumir que APIs internas no necesitan autenticación porque están “detrás del firewall.” Las redes modernas son planas; asume brecha.

Omitir Autorización Después de Autenticación: Verificar identidad pero no verificar permisos. El Usuario A accede a datos del Usuario B porque la API solo verifica si la petición está autenticada.

Cachear Decisiones de Autorización: Almacenar “usuario X puede acceder a recurso Y” y reutilizarlo. Los permisos cambian; siempre verifica en tiempo real.

Sin Verificación de Dispositivo: Permitir acceso desde cualquier dispositivo, incluyendo teléfonos o laptops comprometidos. Implementa verificaciones de postura de dispositivo.

VPN como Control de Seguridad: Tratar VPN como control de seguridad. Las VPNs otorgan acceso a red, no acceso basado en identidad. Usa ZTNA en su lugar.

Políticas Estáticas: Usar reglas de acceso fijas que no se adaptan al riesgo. Implementa políticas dinámicas conscientes del contexto.

Sin Monitoreo: Desplegar arquitectura Zero Trust pero no registrar o monitorear acceso. Sin visibilidad, no puedes detectar abuso o brechas.

Confiar en Llamadas Servicio-a-Servicio: Permitir a microservicios internos llamarse entre sí sin autenticación. Implementa mTLS o autenticación de service mesh.

Sin Revocación de Tokens: Emitir tokens de larga duración sin forma de revocarlos. Implementa listas de revocación de tokens o tiempos de expiración cortos.

Complejidad Sin Aceptación: Implementar Zero Trust sin educación de usuario, causando fricción y soluciones alternativas de Shadow IT.

Estándares y RFCs

Términos Relacionados