Zero Trust en banca: arquitectura práctica para entornos regulados
El viejo modelo de seguridad, ese del castillo con su foso donde todo lo de dentro es de confianza, lleva años agonizando. Con el trabajo remoto, el cloud y los agentes de IA, el perímetro ya no existe. En su lugar se impone una filosofía distinta: Zero Trust en banca, donde no se confía en nada por defecto y todo se verifica continuamente.
Qué es Zero Trust y por qué la banca lo necesita
Zero Trust se resume en una frase: nunca confíes, siempre verifica. Cada acceso a cada recurso se valida en función de la identidad, el dispositivo, el contexto y el riesgo, sin asumir que estar dentro de la red equivale a ser legítimo. Para la banca, que maneja datos críticos y es objetivo constante de ataques, este enfoque ya no es opcional.
El detonante suele ser doble: la sofisticación de los ataques y la presión regulatoria. Un atacante que logra entrar no debería poder moverse libremente, y Zero Trust está diseñado precisamente para impedir ese movimiento lateral.
Pilares de una arquitectura Zero Trust
Verificación de identidad fuerte
La identidad es el nuevo perímetro. Autenticación multifactor, validación continua y gestión rigurosa de accesos, incluidas las identidades no humanas, son la base sobre la que se construye todo lo demás.
Microsegmentación
Dividir la red en segmentos pequeños y controlados limita el daño de una brecha. Si un atacante compromete un segmento, no obtiene acceso a todo. Es la traducción técnica del principio de contención.
Privilegio mínimo
Cada usuario y cada servicio recibe solo los permisos imprescindibles, durante el tiempo imprescindible. Esto enlaza con la gestión del riesgo de ciberseguridad: cuanto menor es el privilegio, menor es el impacto potencial.
Zero Trust, DORA y NIS2
Implantar Zero Trust en banca facilita el cumplimiento de marcos como el reglamento DORA y NIS2, que exigen control de accesos, resiliencia y capacidad de contener incidentes. No es que Zero Trust cumpla la norma por ti, pero su arquitectura responde directamente a muchas de sus exigencias.
Por dónde empezar a implantar Zero Trust
Zero Trust no se implanta de golpe ni se compra en una caja. Es un viaje que conviene recorrer por fases. Cuando acompaño a una entidad financiera, suelo empezar por la identidad: reforzar la autenticación multifactor y eliminar las cuentas compartidas, porque la mayoría de los incidentes graves empiezan con una credencial robada. Una vez que sabemos con certeza quién accede, tiene sentido avanzar hacia la microsegmentación de la red y el control fino de privilegios.
El error que más veo es intentar segmentarlo todo el primer día. Es inabarcable y genera rechazo. Prefiero identificar primero los activos más críticos, los que de verdad duelen si caen, y construir alrededor de ellos los primeros perímetros de confianza cero. Desde ahí, el modelo se extiende de forma natural al resto de la organización sin paralizar la operación.
Cómo se prueba que el Zero Trust funciona
Una arquitectura de confianza cero solo vale lo que demuestran sus pruebas. No basta con diseñarla: hay que atacarla para comprobar que aguanta. Aquí es donde encaja el pentesting avanzado que exige la regulación financiera, y que desarrollaré en un próximo artículo sobre las pruebas de penetración dirigidas por amenazas de DORA. Un ejercicio de TLPT bien hecho pone a prueba precisamente si la microsegmentación y la verificación continua resisten a un atacante real.
Cuando esas pruebas encuentran un camino lateral que no debería existir, no es un fracaso: es exactamente para lo que sirven. Mejor descubrir el fallo en un ejercicio controlado que en un ataque real. Esa mentalidad, la de buscar activamente los puntos débiles, es inseparable de la filosofía Zero Trust.
Mi conclusión es que en banca la confianza cero ha dejado de ser una moda para convertirse en una necesidad regulatoria y operativa. La banca digital ya no tiene un perímetro claro que defender, así que la única estrategia sensata es asumir que el atacante puede estar ya dentro y verificar cada paso. No es desconfianza por desconfianza: es prudencia diseñada en la arquitectura.
Una confusión habitual que me encuentro es pensar que Zero Trust es un producto que se compra e instala. No lo es: es un principio de diseño que se aplica capa a capa. Empieza por identificar qué quieres proteger —los datos y servicios críticos— y construye alrededor controles de identidad fuertes, segmentación de la red y verificación continua de cada acceso. En banca, donde conviven sistemas heredados con plataformas modernas, este enfoque gradual es la única forma realista de avanzar sin paralizar la operativa.
El otro gran malentendido es creer que Zero Trust degrada la experiencia del usuario. Bien implementado ocurre lo contrario: la autenticación adaptativa pide más garantías solo cuando el riesgo lo justifica, y el resto del tiempo el acceso fluye con normalidad. Esa proporcionalidad entre seguridad y usabilidad es, para mí, la señal de que el modelo se ha implantado con criterio y no como una traba burocrática más.
Conclusión: confianza ganada, no asumida
Zero Trust en banca no es un producto que se compra, sino una estrategia que se implanta por capas y con paciencia. Mi recomendación es empezar por la identidad y avanzar de forma incremental. En un sector donde un fallo se mide en millones y en confianza perdida, asumir confianza por defecto es un lujo que nadie puede permitirse.
Preguntas frecuentes sobre Zero Trust en banca
Es un modelo de seguridad basado en el principio nunca confíes, siempre verifica. Cada acceso a cada recurso se valida según identidad, dispositivo, contexto y riesgo, sin asumir que estar dentro de la red equivale a ser legítimo.
Porque maneja datos críticos y es objetivo constante de ataques sofisticados, y porque la presión regulatoria lo empuja. Zero Trust impide el movimiento lateral de un atacante que logre entrar, limitando el daño.
La verificación de identidad fuerte (incluidas las identidades no humanas), la microsegmentación de la red para contener brechas y el privilegio mínimo, otorgando solo los permisos imprescindibles durante el tiempo imprescindible.
Sí. Su arquitectura responde directamente a muchas exigencias de DORA y NIS2 sobre control de accesos, resiliencia y contención de incidentes, aunque no sustituye por sí sola el trabajo de cumplimiento normativo.
¿Tienes que aplicar esto bajo DORA, NIS2 o ENS? Cuéntame el caso.
Agendar 20 minutos