Zero Trust bajo DORA: las 6 decisiones técnicas que marcan la diferencia entre superar la auditoría y repetirla

Cuando una entidad financiera bajo supervisión del BCE me llama para hablar de Zero Trust, la conversación casi siempre empieza igual: ya tienen un proyecto en marcha, llevan meses trabajando, pero la auditoría DORA se acerca y alguien en el comité acaba de preguntar si lo que están construyendo es suficiente para pasar el primer intento.

La respuesta depende de seis decisiones técnicas concretas. No del presupuesto, no del número de herramientas contratadas, no de si han elegido Microsoft o un vendor alternativo. Depende de si tomaron las decisiones correctas en los puntos donde el modelo Zero Trust real diverge del Zero Trust de los folletos.

Estas son las seis, con el razonamiento detrás de cada una.

1. MFA resistente a phishing: la diferencia entre FIDO2 y "tener MFA"

El error más costoso que veo en proyectos Zero Trust para banca es confundir "hemos implantado MFA" con "tenemos autenticación fuerte". MFA basado en SMS o códigos TOTP (aplicaciones de autenticación tipo Google Authenticator o Microsoft Authenticator en modo OTP) es bypasseable con técnicas de phishing adversary-in-the-middle que están documentadas y automatizadas en herramientas disponibles públicamente.

DORA no prescribe tecnologías de autenticación específicas, pero sí exige que la gestión del riesgo TIC sea proporcional a la exposición. Y un supervisor que revise el modelo de amenazas de una entidad financiera — donde el phishing dirigido a empleados con acceso a sistemas de pagos es la vía de ataque más documentada — va a preguntar qué impide que un atacante robe una sesión autenticada con SMS OTP.

La respuesta técnica correcta es FIDO2/passkeys con hardware security keys o autenticación basada en certificados. En el ecosistema Microsoft, esto se traduce en Microsoft Entra ID con claves FIDO2 como Windows Hello for Business con atestación de dispositivo. La clave FIDO2 vincula criptográficamente la autenticación al dominio legítimo: no hay token que interceptar porque el protocolo no funciona en sitios de phishing.

La objeción operativa habitual es el coste de distribución de hardware keys para miles de empleados. La respuesta es que no todos los usuarios necesitan el mismo nivel de protección: los empleados con acceso a sistemas de pagos, los administradores de sistemas críticos y los directivos con acceso a datos regulados sí lo necesitan. El resto puede ir con Authenticator en modo push con detección de número, que aunque no es resistente a phishing sofisticado, eleva significativamente la barra respecto a SMS.

2. La red interna ya no es un factor de seguridad

En el modelo de seguridad perimetral tradicional, estar en la red corporativa era implícitamente una señal de confianza: si pasabas el firewall, eras de los nuestros. Zero Trust elimina ese supuesto por completo, y DORA lo refuerza desde el ángulo regulatorio al exigir que los controles de acceso sean independientes del canal de comunicación.

El problema práctico es que muchas organizaciones que declaran haber implantado Zero Trust siguen teniendo excepciones en sus políticas de Acceso Condicional para rangos de IPs de la red corporativa. "Los usuarios en la oficina no necesitan MFA" es la frase que indica que la arquitectura no es realmente Zero Trust, independientemente de lo que diga el documento de diseño.

La implicación técnica es concreta: ninguna regla de Conditional Access debe conceder acceso basado exclusivamente en ubicación de red. La red puede ser una señal adicional en un conjunto de factores — por ejemplo, para reducir la frecuencia de re-autenticación si el usuario ya cumple otras condiciones — pero no puede ser el factor determinante. Un atacante que compromete la VPN o accede físicamente a un punto de la red interna no debe heredar automáticamente los privilegios de acceso de esa ubicación.

3. Conditional Access basado en señales de riesgo reales, no en reglas estáticas

Una política de Acceso Condicional que dice "si el usuario está en una IP desconocida, exige MFA" es mejor que nada, pero no es Zero Trust maduro. Zero Trust maduro evalúa el riesgo de cada sesión de forma dinámica basándose en múltiples señales correlacionadas: comportamiento del usuario en los últimos días, postura del dispositivo en tiempo real, aplicación a la que accede, sensibilidad de los datos que va a manejar y anomalías de comportamiento detectadas por UEBA.

En el ecosistema Microsoft, esto se implementa con Microsoft Entra ID Protection + Conditional Access con políticas basadas en señal de riesgo de usuario y de inicio de sesión. Entra ID Protection calcula en tiempo real una puntuación de riesgo para cada sesión basándose en inteligencia de amenazas de Microsoft (señales de miles de millones de autenticaciones diarias) y en el comportamiento histórico del usuario específico.

Las políticas que funcionan bajo DORA tienen esta lógica: si el riesgo de inicio de sesión es alto, requiere MFA fuerte y verifica el dispositivo. Si el riesgo es medio, requiere MFA y puede limitar las acciones disponibles. Si el riesgo es bajo y el dispositivo cumple el baseline de seguridad y el usuario tiene comportamiento normal, permite el acceso con la fricción mínima necesaria.

El matiz importante para superar una auditoría DORA es que estas políticas deben estar documentadas, versionadas y con un proceso de revisión periódica. Un auditor no solo va a comprobar que la política existe: va a preguntar cuándo fue revisada por última vez, quién la aprobó y qué evidencia existe de que funciona según lo previsto.

4. Privileged Identity Management sin excepciones: la única regla sin matices

El 80% de las brechas de seguridad en organizaciones financieras que he analizado comparten un patrón: la cuenta comprometida inicialmente tenía privilegios mínimos, pero el atacante escaló privilegios aprovechando una cuenta de administrador con acceso permanente que llevaba meses sin usarse activamente.

PIM (Privileged Identity Management) resuelve este problema eliminando los accesos privilegiados permanentes. En lugar de que un administrador de sistemas tenga rol de Owner en una suscripción de Azure de forma indefinida, PIM convierte ese acceso en temporal y bajo demanda: el administrador solicita el rol cuando lo necesita, el sistema puede requerir aprobación del responsable, y el acceso expira automáticamente después del tiempo definido — típicamente entre 1 y 8 horas.

El resultado es que un atacante que compromete una cuenta de administrador fuera de una ventana de activación no tiene acceso privilegiado. Tiene que volver a activar PIM, lo que genera un alert inmediato si la activación no coincide con una solicitud legítima esperada.

La regla de implementación es absoluta: ninguna cuenta humana debe tener roles privilegiados asignados permanentemente. Sin excepciones para el CISO, sin excepciones para el equipo de guardia, sin excepciones para las cuentas de servicio heredadas que "siempre han funcionado así". Cada excepción que se aprueba es un vector de ataque documentado que el auditor DORA puede señalar.

Las cuentas de break-glass — accesos de emergencia para cuando PIM no está disponible — son la única excepción válida, y deben estar monitorizadas con alertas en tiempo real sobre cualquier uso.

5. Correlación de señales en Sentinel desde el primer día

Zero Trust sin capacidad de detección es arquitectura sin inteligencia. Puedes tener las mejores políticas de Conditional Access del mundo y si no estás correlacionando las señales de autenticación, movimiento lateral y exfiltración en un SIEM centralizado, no sabrás cuando alguien está abusando sistemáticamente de los controles que has implantado.

DORA lo convierte en obligación regulatoria: exige capacidades de detección y respuesta a incidentes con tiempos de respuesta documentados y un proceso de mejora continua basado en lecciones aprendidas. Un SOC que detecta incidentes en 72 horas — que era el promedio del sector hace tres años — no cumple el estándar de resiliencia operativa que DORA define.

La configuración correcta en Microsoft Sentinel para un entorno Zero Trust sobre Entra ID tiene tres componentes críticos:

• Conectores nativos activos desde el día 1: Entra ID, Defender for Endpoint, Defender for Cloud Apps, Defender for Identity. Sin datos de estos cuatro orígenes, el 80% de los incidentes de identidad y movimiento lateral no son detectables.
• Reglas de detección mapeadas a MITRE ATT&CK: específicamente las tácticas de Initial Access (T1078 - Valid Accounts), Credential Access (T1110 - Brute Force, T1557 - Adversary-in-the-Middle) y Lateral Movement (T1550 - Use Alternate Authentication Material). Estas son las rutas de ataque que más frecuentemente se activan en entornos financieros con identidad comprometida.
• UEBA habilitado: la detección de anomalías de comportamiento es lo que permite identificar una cuenta legítima comprometida que está siendo utilizada de forma anómala pero dentro de los límites de las reglas de acceso configuradas. Una cuenta que accede a SharePoint a las 3 de la madrugada desde un dispositivo que nunca ha accedido antes a ese recurso puede pasar todas las comprobaciones de Conditional Access y aun así ser una señal de compromiso.

6. Automatizar la notificación de incidentes: los plazos de DORA no son negociables

DORA establece plazos de notificación de incidentes graves que son incompatibles con procesos manuales: notificación inicial al regulador en menos de 4 horas, informe intermedio en 72 horas, informe final en un mes. En la práctica, cuando ocurre un incidente de seguridad significativo, los equipos SOC están gestionando la respuesta técnica y conteniendo el daño — no tienen capacidad residual para generar informes regulatorios en paralelo.

La solución es automatizar los playbooks de notificación en Microsoft Sentinel de forma que cuando una alerta supera el umbral de severidad que define "incidente grave" bajo DORA, el sistema genera automáticamente la notificación inicial en el formato requerido por el supervisor, la envía a los destinatarios correctos y registra el timestamp como evidencia. El equipo SOC confirma o deniega la notificación, pero no la redacta bajo presión durante una crisis.

Este es uno de los controles que más frecuentemente falta en los proyectos Zero Trust que reviso. La arquitectura técnica puede ser impecable, pero si el proceso de notificación sigue siendo manual, la entidad incumple DORA aunque nunca haya tenido un incidente grave — porque el regulador puede auditar el proceso en cualquier momento.

El resultado cuando estas seis decisiones se toman bien

En el proyecto Zero Trust que describimos en el caso de estudio 002, la entidad financiera partía de un Secure Score del 42% y sin MFA universal. Nueve meses después de implementar la arquitectura con estas seis decisiones en el centro del diseño, el Secure Score estaba en el 87% y la primera auditoría DORA se superó sin observaciones críticas. Cero incidentes de seguridad graves durante todo el período de transformación.

El matiz que el CISO destacó en la revisión post-auditoría no fue el resultado del Secure Score — era el esperado con esa arquitectura. Fue que el auditor no encontró excepciones a las políticas. En proyectos donde Zero Trust se implanta con concesiones al confort operativo — "este equipo no necesita PIM", "esta aplicación legacy no soporta MFA fuerte" — esas excepciones son exactamente donde los auditores focalizan su atención, y con razón: son los vectores reales de ataque que la arquitectura no protege.

Zero Trust bajo DORA no es más difícil que Zero Trust sin regulación. Lo que la regulación aporta es claridad: fuerza a tomar estas seis decisiones sin postergarlas ni diluirlas, lo que en la práctica produce una arquitectura más limpia y más fácil de defender ante cualquier auditor, interno o externo.