Zero Trust en banca: Por qué las VPN ya no son suficientes
Durante 25 años, 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 40-60% del personal accede desde fuera del perímetro |
| APIs abiertas | PSD2, Open Banking y regulación obligan a exponer interfaces |
| 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
Modelo arquitectónico bajo el axioma "nunca confíes, verifica siempre". Cada acceso se verifica individualmente con identidad criptográfica, en cada interacción — sin importar si la petición viene de dentro o fuera de la red. Leer más → Zero Trust parte de un axioma: "nunca confíes, verifica siempre". 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 Sustrato de conectividad open-source de NetFoundry: túneles cifrados, servicios dark sin IP pública, política de servicio identity-first. 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
Digital Operational Resilience Act: reglamento UE 2022/2554 sobre resiliencia operativa digital. Exige a entidades financieras de la UE resistir, responder y recuperarse de incidentes TIC. En vigor desde 17 enero 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 |
| Resiliencia operativa (Art. 9) | Circuit breaker, spooling, reconexión autónoma |
| Cifrado (Art. 9.3.b) | mTLS extremo a extremo, sin datos en claro |
| 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 (Ed25519) | 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 extremo a extremo | Verificación mutua en cada conexión |
| 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 cumplimiento DORA nativo.