Zero Trust

¿Qué es Zero Trust?

Zero Trust (Confianza Cero) es un modelo de seguridad basado en el principio de “nunca confiar, siempre verificar”. A diferencia del modelo tradicional de seguridad perimetral, Zero Trust asume que las amenazas pueden existir tanto dentro como fuera de la red, y por tanto ningún usuario, dispositivo o conexión debe ser considerado seguro por defecto.

El modelo lo desarrolló y bautizó John Kindervag en Forrester, en 2009, y en 2010 publicó la presentación que lo popularizó. Su adopción se aceleró con el trabajo remoto y con los ataques por credenciales comprometidas.

Principios Fundamentales

Los Tres Pilares de Zero Trust

Modelo de Madurez CISA

El modelo de madurez Zero Trust de CISA se organiza en cinco pilares y tres capacidades transversales —visibilidad y análisis, automatización y orquestación, y gobernanza—, que atraviesan los cinco. Los pilares son:

1. IDENTITY (Identidad)
   └── MFA, SSO, Identity Governance
   
2. DEVICE (Dispositivos)
   └── MDM, EDR, Device Compliance
   
3. NETWORK (Red)
   └── Microsegmentación, ZTNA, SDP
   
4. APPLICATION (Aplicaciones)
   └── CASB, WAF, API Security
   
5. DATA (Datos)
   └── DLP, Encryption, Classification

Zero Trust vs. Seguridad Tradicional

Modelo Perimetral (Castle-and-Moat)

Filosofía: “Si estás dentro del castillo, eres de confianza”

Problemas:

• VPN = Acceso completo a la red interna
• Un compromiso → movimiento lateral libre
• No protege contra insiders maliciosos
• Ineficaz con trabajo remoto y cloud

Ejemplo de fallo:

Escenario tradicional:
1. Empleado conecta VPN desde casa
2. Malware en su portátil personal
3. VPN da acceso a toda la red corporativa
4. Malware se propaga a servidores críticos
5. Ransomware cifra infraestructura completa

Modelo Zero Trust

Filosofía: “Nunca confíes, siempre verifica”

Ventajas:

• Cada acceso se evalúa individualmente
• Microsegmentación limita movimiento lateral
• Verificación continua durante sesión
• Visibilidad completa de accesos

Mismo escenario con Zero Trust:

Escenario Zero Trust:
1. Empleado intenta conectar desde casa
2. Sistema verifica: identidad + dispositivo + ubicación + comportamiento
3. Dispositivo personal no cumple compliance → acceso denegado a recursos críticos
4. Solo acceso a aplicaciones específicas autorizadas
5. Malware contenido, sin acceso a red corporativa

Componentes Técnicos

Identity and Access Management (IAM)

Single Sign-On (SSO) con MFA Adaptativo

MFA Policy Example:
  conditions:
    - location: "Outside corporate network"
      action: "Require MFA"
    - device_compliance: "Non-compliant"
      action: "Require MFA + Device enrollment"
    - risk_score: ">70"
      action: "Block access + Alert SOC"
    - sensitive_resource: true
      action: "Always require MFA"

Conditional Access Policies

{
  "policy_name": "High-Risk-Access-Control",
  "conditions": {
    "user_risk": ["high", "medium"],
    "sign_in_risk": ["high"],
    "device_platforms": ["all"],
    "locations": ["outside_corporate"]
  },
  "grant_controls": {
    "require": ["mfa", "compliant_device"],
    "block": ["legacy_authentication"]
  },
  "session_controls": {
    "sign_in_frequency": "1h",
    "persistent_browser": "never"
  }
}

Network Segmentation

Microsegmentación

Traditional Network:
┌─────────────────────────────────────┐
│           FLAT NETWORK              │
│  Server A ←→ Server B ←→ Server C   │
│     ↕           ↕           ↕       │
│  Workstation  Database  Application │
└─────────────────────────────────────┘

Zero Trust Microsegmented:
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Segment A│ │ Segment B│ │ Segment C│
│ HR Apps  │ │ Finance  │ │ Dev/Test │
│ [Policy] │ │ [Policy] │ │ [Policy] │
└────┬─────┘ └────┬─────┘ └────┬─────┘
     │            │            │
     └────────────┼────────────┘
                  │
           [Zero Trust Broker]
                  │
            Verified User

Software-Defined Perimeter (SDP)

SDP Architecture:
                                    
User Device ──► SDP Controller ──► Verify Identity
     │              │                    │
     │              ▼                    │
     │         Policy Engine ◄───────────┘
     │              │
     │              ▼
     └────► SDP Gateway ──► Protected Resource
              (Tunnel)
              
Key: User NEVER sees network topology
     Resources invisible until authorized

Zero Trust Network Access (ZTNA)

Diferencia con VPN tradicional:

Zero Trust y Análisis Forense

Beneficios para Investigaciones

Los entornos con Zero Trust facilitan la investigación, y por una razón concreta:

1. Logging Exhaustivo

{
  "timestamp": "2026-02-02T14:30:22.456Z",
  "user_id": "cfo@empresa.com",
  "action": "file_access",
  "resource": "/finance/reports/Q4-2025.xlsx",
  "device_id": "LAPTOP-ABC123",
  "device_compliance": true,
  "location": {
    "ip": "203.0.113.45",
    "country": "ES",
    "city": "Madrid"
  },
  "risk_score": 15,
  "mfa_method": "authenticator_app",
  "session_id": "sess_abc123def456",
  "policy_applied": "finance_data_access_v2"
}

2. Atribución Precisa

• Cada acción vinculada a identidad verificada
• Dispositivo específico identificado
• Contexto completo de la sesión
• Cadena de decisiones de acceso documentada

3. Detección de Anomalías

## Zero Trust facilita detección automática
anomaly_indicators = {
    "impossible_travel": "Login Madrid 14:30, Login Tokyo 14:45",
    "device_change": "Nuevo dispositivo no registrado",
    "behavior_deviation": "Acceso a recursos nunca utilizados",
    "risk_score_spike": "Score pasó de 15 a 85 en 10 minutos"
}

Caso Forense: Zero Trust como Evidencia

Situación: Empleado acusado de filtrar datos confidenciales a competidor.

Evidencia Zero Trust disponible:

Timeline reconstruido automáticamente:

2026-01-15 09:00:12 - Login exitoso
  Device: LAPTOP-CORP-234
  Location: Oficina Madrid
  MFA: Authenticator App
  Risk Score: 12

2026-01-15 09:15:33 - Acceso denegado
  Resource: /confidential/client-list.xlsx
  Reason: "User not in authorized group"
  Policy: confidential_data_policy_v3

2026-01-15 09:16:01 - Segundo intento denegado
  Alert triggered: "Multiple denied access attempts"

2026-01-15 09:20:45 - Solicitud de acceso
  Ticket: REQ-2026-1234
  Justification: "Needed for client meeting"
  Approved by: Manager (user_mgr@empresa.com)

2026-01-15 09:25:12 - Acceso concedido (temporal)
  Resource: /confidential/client-list.xlsx
  Duration: 2 hours
  Actions logged: View, Download

2026-01-15 09:26:33 - Download detected
  File: client-list.xlsx
  Size: 2.4 MB
  Destination: Local device

Valor forense:

• ✅ Timeline preciso de cada acción
• ✅ Justificación documentada
• ✅ Aprobación con responsable identificado
• ✅ Acción específica (download) registrada
• ✅ Contexto completo para determinar intención

Implementación Práctica

Roadmap de Adopción

Stack Tecnológico Típico

Microsoft Zero Trust Stack

Identity:          Microsoft Entra ID + Conditional Access
Device:            Intune + Defender for Endpoint
Network:           Azure Private Link + NSGs
Applications:      Entra Private Access + Defender for Cloud Apps (antes App Proxy y MCAS)
Data:              Microsoft Purview Information Protection
Monitoring:        Microsoft Sentinel

Google Zero Trust Stack (BeyondCorp)

Identity:          Cloud Identity + Context-Aware Access
Device:            Endpoint Verification + Chrome Enterprise
Network:           VPC Service Controls + IAP
Applications:      Chrome Enterprise Premium (antes BeyondCorp Enterprise)
Data:              Sensitive Data Protection + Cloud KMS
Monitoring:        Google Security Operations (antes Chronicle)

Alternativas abiertas o de código disponible

Identity:          Keycloak + FIDO2
Device:            osquery + Fleet
Network:           Tailscale + WireGuard
Applications:      OAuth2 Proxy + Pomerium
Data:              Vault (HashiCorp, hoy de IBM; sus versiones nuevas van bajo BSL, que es *source-available*, no open source)
Monitoring:        Wazuh (TheHive ya no se publica como open source)

Configuración Ejemplo: Conditional Access

## Política de acceso condicional de Microsoft Entra ID (antes Azure AD).
## Pseudocódigo: los identificadores reales de Graph son mfa, compliantDevice,
## domainJoinedDevice y block, y se aplican vía conditionalAccessGrantControls.
policy:
  name: "Zero-Trust-Finance-Access"
  state: "enabled"
  
  conditions:
    users:
      include: ["Finance-Team"]
      exclude: ["Emergency-Access-Accounts"]
    
    applications:
      include: ["SAP", "Oracle-Finance", "Banking-Portal"]
    
    # NO se excluye la red corporativa: eximirla reproduce el modelo de
    # perímetro que este artículo enseña a NO construir (ver "Error 1").
    # La única exclusión razonable son las cuentas de emergencia, ya arriba.
    locations:
      include: ["All"]
    
    device_platforms:
      include: ["Windows", "macOS", "iOS", "Android"]
    
    client_apps:
      include: ["Browser", "Modern-Auth-Apps"]
      exclude: ["Legacy-Auth"]
    
    user_risk: ["high", "medium"]
    sign_in_risk: ["high", "medium"]
  
  grant_controls:
    operator: "AND"
    built_in_controls:
      - "mfa"
      - "compliant_device"
      - "hybrid_azure_ad_joined"
  
  session_controls:
    sign_in_frequency:
      value: 1
      type: "hours"
    persistent_browser_session:
      mode: "never"

Beneficios de Seguridad

Reducción de Superficie de Ataque

Métricas de Mejora Típicas

Lo que una arquitectura Zero Trust bien implantada cambia, en términos cualitativos:

- Reduce el alcance de una credencial robada, que deja de abrir la red entera
- Acorta la detección, porque cada acceso se registra con su contexto
- Acota la contención: se revoca una sesión, no se aísla un segmento completo
- Deja trazabilidad de los accesos privilegiados, que antes solían quedar fuera del registro

⚠️ No se publican aquí porcentajes de mejora —«60 % menos brechas», «75 % menos MTTD»— porque circulan sin emisor, sin universo y sin metodología: no hay forma de saber contra qué línea base se miden ni en qué organizaciones. Es la misma razón por la que este artículo tampoco da una cifra de adopción.

Desafíos de Implementación

Obstáculos Comunes

1. Aplicaciones Legacy

Problema: Apps antiguas no soportan autenticación moderna. Solución: Application proxies, identity-aware proxies.

2. Resistencia Organizacional

Problema: Usuarios ven Zero Trust como fricción. Solución: UX fluida, SSO, MFA sin contraseña.

3. Complejidad Técnica

Problema: Integración de múltiples componentes. Solución: Plataformas unificadas, adopción gradual.

4. Coste Inicial

Problema: Inversión significativa en tecnología. Solución: ROI demostrable, reducción de costes de incidentes.

Errores de Implementación

Aspectos Legales y Compliance

Normativa Española

Esquema Nacional de Seguridad (ENS)

El Real Decreto 311/2022 establece:

• Art. 14: análisis y gestión de riesgos (el art. 12 es la política de seguridad y los requisitos mínimos)
• Anexo II, op.acc: Control de acceso con principio de mínimo privilegio
• Anexo II, mp.com: Protección de comunicaciones
• Categoría ALTA: exige el conjunto más amplio de medidas del Anexo II —control de acceso, segmentación y monitorización— que en la práctica se solapan con los principios de Zero Trust, aunque el real decreto no emplea ese término

RGPD y Zero Trust

• Art. 25: privacidad desde el diseño → Zero Trust encaja con el principio, sin que eso equivalga a cumplirlo
• Art. 32: medidas apropiadas al riesgo → aporta material para acreditar la diligencia
• Art. 33: Notificación de brechas → Logging facilita detección

Valor Probatorio del Logging Zero Trust

Qué refuerza el peso probatorio de los registros

No son requisitos legales de validez —la LEC no los establece como tal—, sino buenas prácticas que hacen más difícil impugnar los logs con éxito:

1. Integridad: logs firmados o en un almacén inmutable
2. Completitud: registro de las acciones relevantes
3. Trazabilidad: cadena de eventos reconstruible
4. Autenticidad: vinculación verificable entre usuario y acción

Valor probatorio de los registros de acceso

Un registro de autenticación multifactor aporta más que un registro de contraseña: acredita que se superó un segundo factor vinculado a un dispositivo concreto. Pero no cierra la coartada del tercero, y conviene no escribirlo así en un dictamen. Hay al menos tres vías por las que ese registro sale limpio sin que el titular haya hecho nada: el robo del token de sesión, que se produce después del MFA y por eso no lo activa; la fatiga MFA, cuando el usuario aprueba un aviso push que no ha pedido; y la interceptación del código en tránsito. Un aviso push aprobado no es, en abstracto, el factor más débil —Microsoft lo sitúa por encima del TOTP y de la telefonía en su jerarquía—, pero sí es el que más fácilmente se obtiene por insistencia. En particular, es el factor más débil de todos: acredita que alguien pulsó, no qué autorizaba. Para que ese valor se sostenga en juicio, el registro debe preservarse con su marca temporal, con el identificador del dispositivo o del token empleado, y con hash del volcado: sin esas tres cosas, la contraparte podrá sostener que los logs se generaron o alteraron después.

Zero Trust en Investigaciones Forenses

Metodología de Análisis

Herramientas de Análisis

Microsoft Sentinel Queries (KQL)

// Detectar accesos anómalos en entorno Zero Trust
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0  // Successful logins
| extend RiskLevel = tostring(RiskLevelDuringSignIn)
| where RiskLevel in ("high", "medium")
| summarize 
    AccessCount = count(),
    UniqueIPs = dcount(IPAddress),
    UniqueDevices = dcount(DeviceDetail.deviceId),
    Countries = make_set(LocationDetails.countryOrRegion)
    by UserPrincipalName, bin(TimeGenerated, 1h)
| where UniqueIPs > 3 or UniqueDevices > 2
| order by AccessCount desc

Splunk Zero Trust Dashboard

index=zerotrust sourcetype=access_logs
| eval risk_category=case(
    risk_score>=80, "critical",
    risk_score>=60, "high", 
    risk_score>=40, "medium",
    true(), "low"
)
| stats count by user, resource, risk_category, _time
| where risk_category IN ("critical", "high")
| sort -count

Caso Práctico: Investigación con Zero Trust

Escenario: Sospecha de exfiltración de datos por empleado.

Análisis Zero Trust:

FASE 1: Identificación de Accesos Sospechosos

Query: Accesos fuera de horario laboral + descarga masiva
Resultado:
- 2026-01-20 23:45: Login desde IP doméstica
- 2026-01-20 23:47: 47 archivos descargados en 3 minutos
- 2026-01-20 23:52: Logout

FASE 2: Contexto de Seguridad

Device: Personal laptop (no corporativo)
MFA: aviso push aprobado  ← NO acredita quién pulsó: ver fatiga MFA
Risk Score: 72 (elevated)
Policy Applied: "After-hours-restricted-access"
Alert Generated: "Bulk download outside business hours"

FASE 3: Análisis Comportamental

Baseline usuario:
- Horario típico: 09:00-18:00
- Descargas mensuales promedio: 12 archivos
- Dispositivos habituales: 2 (laptop corp + móvil)

Anomalías detectadas:
- ⚠️ Horario: 23:45 (nunca trabaja de noche)
- ⚠️ Dispositivo: Nuevo, no registrado
- ⚠️ Volumen: 47 archivos (4x promedio mensual)
- ⚠️ Velocidad: 3 minutos (sugiere automatización)

FASE 4: Conclusión Forense

La combinación de factores indica actividad altamente sospechosa:
- Acceso **aparentemente** legítimo: credenciales válidas y segundo factor superado, que es justo lo que un token robado o una fatiga de MFA producen
- Comportamiento anómalo en varias dimensiones a la vez
- La telemetría permitió reconstruir la sesión; quién estaba al otro lado sigue siendo una inferencia que hay que sostener con más artefactos

Tendencias Futuras

Hacia dónde va el modelo

AI-Powered Zero Trust

Next-Gen Zero Trust Features:
  - Real-time behavioral biometrics
  - Predictive risk scoring
  - Autonomous policy adjustment
  - Natural language policy creation
  - Automated incident response

Zero Trust for AI/ML

Emerging requirement:
- AI models need Zero Trust too
- Model access control and auditing
- Training data protection
- Inference monitoring
- Model integrity verification

Regulación Emergente

Directiva NIS2 (EU):

• Exige medidas que tengan en cuenta el estado de la técnica, el coste de aplicación y el riesgo — no «estado del arte» sin más
• Su considerando 89 menciona expresamente los principios de confianza cero
• Multas de hasta 10 M€ o el 2 % para entidades esenciales; 7 M€ o el 1,4 % para las importantes

DORA (Digital Operational Resilience Act):

• Obligatorio para sector financiero EU
• Requiere controles de acceso granulares
• Procedimientos de registro obligatorios, con el detalle ajustado a su finalidad y uso — no «registrar exhaustivamente todo»

Conclusión

Zero Trust representa un cambio de paradigma en seguridad que beneficia enormemente al análisis forense digital. Sus principios de verificación continua, mínimo privilegio y logging exhaustivo proporcionan:

• Mucha más visibilidad de las acciones sobre los sistemas, con la advertencia del NIST de que siempre queda tráfico opaco
• Vinculación de eventos a identidades autenticadas, que no es lo mismo que atribuirlos a una persona
• Contexto enriquecido para cada decisión de acceso
• Timeline automático de actividades sospechosas
• Evidencia de alta calidad para procesos judiciales

Para peritos informáticos, los entornos Zero Trust simplifican significativamente las investigaciones:

• Menos tiempo reconstruyendo eventos
• Más certeza en la atribución
• Mejor cadena de evidencias
• Detección temprana de anomalías

Para abogados especializados en derecho digital, Zero Trust ofrece:

• Material con el que acreditar la diligencia ante un regulador
• Evidencia más sólida para un litigio
• Los arts. 25 y 32 del RGPD exigen medidas apropiadas al riesgo: adoptar Zero Trust no certifica el cumplimiento ni reduce por sí solo la responsabilidad

La adopción de Zero Trust no es solo una mejora de seguridad, sino una inversión en capacidad forense que puede ser determinante cuando ocurren incidentes de seguridad.

Última actualización: 29 de agosto de 2026 Categoría: Técnico Código: ZTR-001