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
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 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 (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 |
Caso de uso: IDColab
IDColab implementa Zero Trust para permitir que talleres mecánicos compartan datos con aseguradoras y peritos:
- Sin VPN, agentes ni plugins en el navegador
- Las aplicaciones internas del taller se exponen solo a usuarios con identidad OIDC verificada
- Cifrado mTLS de extremo a extremo con OpenZiti
- El taller nunca abre puertos en su firewall
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 |
📩 ¿Tu entidad necesita una arquitectura Zero Trust?
Te mostramos cómo proteger tus aplicaciones críticas sin VPN y con cumplimiento DORA nativo.