Zero Trust en banca: Por qué las VPN ya no bastan
Durante décadas, las entidades financieras han protegido sus sistemas con el mismo modelo: un perímetro de red (firewalls + VPN) que separa lo "interno seguro" de lo "externo peligroso". Este modelo está roto.
Por qué el perímetro ya no funciona
| Factor | Realidad 2026 |
|---|---|
| Cloud híbrido | Las aplicaciones ya no están en un solo centro de datos — están en AWS, Azure, GCP y on-premise simultáneamente |
| Trabajo remoto | El trabajo híbrido traslada parte del acceso diario a redes domésticas y públicas, fuera del perímetro |
| APIs abiertas | Las normas técnicas de PSD2 (Reglamento Delegado (UE) 2018/389, art. 30) obligan a todo gestor de cuentas de pago accesibles en línea a mantener al menos una interfaz de acceso para terceros |
| Supply chain | Proveedores TIC acceden a sistemas internos para soporte y operación |
| Movimiento lateral | Una vez dentro del perímetro, un atacante se mueve libremente |
La premisa fundamental
Zero Trust es el modelo de seguridad que NIST formaliza en SP 800-207: la ubicación de red no otorga confianza implícita y cada acceso se autentica y autoriza por separado. En banca y seguros acota el movimiento lateral tras el robo de una credencial; BlueUP lo aplica con identidad criptográfica por servicio.Leer más → Zero Trust parte de un axioma: "nunca confíes, verifica siempre". La NIST SP 800-207 lo formula como decisiones de acceso de mínimo privilegio, petición a petición, ante una red que se considera comprometida: no importa si la petición viene de dentro o fuera de la red, cada acceso se verifica individualmente, en cada interacción.
Qué significa Zero Trust en la práctica
Zero Trust no es un producto. Es un modelo arquitectónico que se implementa con tecnologías específicas:
1. Identidad como perímetro
En vez de confiar en la red, se confía en la identidad criptográfica verificable:
| Modelo clásico | Modelo Zero Trust |
|---|---|
| "Estás en la VPN → eres de confianza" | "Demuestra quién eres con un certificado criptográfico" |
| Firewall decide quién entra | Cada servicio verifica la identidad del solicitante |
| API key estática compartida | Token temporal con privilegios mínimos y fecha de expiración |
2. Cifrado extremo a extremo (mTLS)
Mutual TLS garantiza que ambos extremos de una comunicación verifican la identidad del otro:
Cliente → presenta su certificado → Servidor lo verifica
Servidor → presenta su certificado → Cliente lo verifica
→ Canal cifrado con identidades mutuamente autenticadasEsto es especialmente crítico en banca, donde los datos en tránsito incluyen transacciones, PII y comunicaciones regulatorias.
3. Dark services: Servicios invisibles
El concepto más potente de Zero Trust: los servicios no están expuestos a internet. No tienen IP pública, no responden a escaneos de puertos, no aparecen en Shodan.
| Servicio clásico | Dark service |
|---|---|
Expuesto en api.banco.com:443 | Sin IP pública — invisible a internet |
| Protegido por WAF + firewall | No necesita WAF — no hay superficie de ataque |
| Vulnerable a DDoS | Inmune a DDoS — no hay endpoint que atacar |
| Escaneable con Nmap | Inexistente para escáneres |
¿Cómo accede un usuario legítimo?
A través de un overlay de red (como OpenZiti es el sustrato de conectividad open-source de NetFoundry: identidad X.509, cifrado extremo a extremo y servicios sin IP pública, invisibles por defecto. Sustituir la VPN es uno de sus casos de uso: la identidad se autoriza antes de que exista ruta de datos. En BlueUP sostiene la accesibilidad Zero Trust.Leer más → OpenZiti) que crea túneles cifrados directos entre el usuario autenticado y el servicio. El servicio solo "existe" para quien tiene identidad verificada.
Zero Trust y DORA: Convergencia obligatoria
DORA (Digital Operational Resilience Act) es el Reglamento (UE) 2022/2554 sobre la resiliencia operativa digital del sector financiero. Obliga a bancos, aseguradoras y empresas de inversión de la UE a resistir las perturbaciones y amenazas TIC, responder a ellas y recuperarse. Se aplica desde el 17 de enero de 2025.Leer más → DORA (Reglamento (UE) 2022/2554) no menciona "Zero Trust" explícitamente, pero sus requisitos convergen directamente:| Requisito DORA | Implementación Zero Trust |
|---|---|
| Gestión de riesgos TIC (Art. 5-16) | Inventario de identidades, políticas de acceso granulares |
| Respuesta y recuperación (Art. 11) | Circuit breaker, spooling, reconexión autónoma |
| Cifrado (Art. 9.4.d) | mTLS en el overlay OpenZiti; WireGuard entre nodos del clúster |
| Control de acceso (Art. 9.4.c) | Privilegios mínimos, tokens temporales, four-eyes |
| Monitorización continua (Art. 10) | Alertas automáticas, audit trail inmutable |
Cómo implementa BlueUP la arquitectura Zero Trust
| Componente | Tecnología | Función |
|---|---|---|
| Identidad humana | Keycloak OIDC/PKCE | Autenticación federada sin contraseñas estáticas |
| Identidad workload | SPIRE SVIDs (X.509 o JWT) | Identidad criptográfica rotatoria por servicio |
| Autorización | Biscuit Tokens | Tokens de capacidad con atenuación offline |
| Red | OpenZiti dark services | Servicios invisibles a internet |
| Cifrado | mTLS en el overlay OpenZiti; WireGuard entre nodos del clúster | Verificación mutua en cada conexión del overlay |
| Políticas | OPA (Open Policy Agent) | Evaluación centralizada de políticas de acceso |
Lecturas relacionadas
- DORA 2026: Guía práctica para entidades financieras — El marco regulatorio que ya exige resiliencia operativa.
- IA agéntica y Zero Trust — La próxima generación de cargas de trabajo a proteger.
- Soluciones Banca Privada — Aplicación práctica a banca privada y wealth management.
¿Tu entidad necesita una arquitectura Zero Trust?
Te mostramos cómo proteger tus aplicaciones críticas sin VPN y con capacidades para el cumplimiento de DORA.