Autenticación multifactor adaptativa en la auditoría NIS2: Cuando la política sirve como prueba

8 min. de lectura

Una MFA adaptativa que funciona en el inicio de sesión seguirá fallando en una auditoría si nadie puede demostrar qué regla determina cuándo exige el segundo factor. Precisamente esta brecha pasa al primer plano con la NIS2: la directiva no solo exige que exista una autenticación basada en riesgos, sino que la empresa pueda evaluar la eficacia de sus medidas. Quien simplemente active Entra ID, Okta o Duo y deje las reglas de acceso condicional en la cabeza del departamento de TI tendrá una tecnología, pero, en el mejor de los casos, carecerá de una justificación documentada.

Lo más importante en resumen

La política como evidencia: El artículo 21 de la NIS2 exige medidas proporcionales al riesgo y una evaluación de su eficacia. Una MFA adaptativa resulta mucho más sólida en una auditoría si sus reglas se exportan, se versionan y se justifican en función del nivel de protección requerido, aunque la directiva no prescriba explícitamente este formato.
Break-Glass y Number-Matching: Dos configuraciones determinan si la solución resiste en una situación de emergencia: cuentas de emergencia que, aunque queden exentas de las reglas de bloqueo, están vinculadas a un factor robusto y supervisadas, junto con una confirmación mediante comparación de números que neutraliza los ataques de fatiga de MFA.
El mapeo BSI facilita la verificación: Quien contraste la lógica de escalado con el módulo ORP.4 del IT-Grundschutz ofrece al auditor un lenguaje que ya conoce, en lugar de una configuración de herramienta que tendría que interpretar.

Relacionado:La vulnerabilidad que solo la IA encontró / El plan de emergencia que nadie ensayó

Por qué la NIS2 audita la política de MFA, y no la función de MFA

¿Qué es la MFA adaptativa? La autenticación multifactor adaptativa o basada en riesgos evalúa cada inicio de sesión mediante señales de contexto y solo exige el segundo factor cuando el riesgo supera un umbral definido. Un inicio de sesión desde un portátil gestionado en la red de la oficina se permite sin más, mientras que el mismo identificador desde una nueva dirección IP en otro país desencadena una consulta de escalado o se bloquea. La tecnología subyacente está disponible en Entra ID, Okta y Duo desde hace años.

El punto en el que incide la NIS2 no reside únicamente en la tecnología. El artículo 21, apartado 2, de la directiva exige medidas proporcionales al riesgo, acordes con el estado de la técnica, así como conceptos para evaluar su eficacia. La directiva menciona explícitamente la autenticación multifactor como medida adecuada cuando proceda. Para una auditoría, esto desplaza la pregunta clave: ya no se trata tanto de si la MFA está activada, sino de qué regla determina la activación del segundo factor, quién asume la responsabilidad de dicha regla y si el umbral se ajusta al nivel de protección de los sistemas afectados.

Aquí es donde fallan muchas configuraciones que en la práctica funcionan a la perfección. Las reglas existen como directiva de acceso condicional en el tenant, pero nadie las ha exportado jamás como documento, nadie puede mostrar su historial y los valores umbral se han tomado de la configuración predeterminada sin que nadie los haya justificado frente al riesgo propio. La medida existe, pero falta la prueba de su eficacia.

Configurar la política como artefacto exportable

El primer paso práctico es poco espectacular: la política de autenticación debe extraerse de la herramienta y transformarse en un formato que un auditor pueda leer sin acceso de administrador. En Entra ID, se exportan las políticas de acceso condicional a través de Microsoft Graph como JSON; en Okta, mediante la API de políticas, y en Duo, a través de la API de administración. Esta exportación debe versionarse en el mismo repositorio donde se encuentra el resto de la documentación de seguridad.

Más importante que el formato es la justificación que lo acompaña. Para cada condición de step-up debe incluirse una frase que explique por qué se ha elegido ese umbral. Un ejemplo: en el caso de cuentas con acceso a la contabilidad, la verificación step-up se activa ya ante una geolocalización desconocida, porque estos sistemas se clasifican como de alto nivel según el propio análisis de necesidades de protección. Para una wiki interna, basta con una regla más laxa. Esta conexión entre la necesidad de protección y la regla de autenticación es precisamente lo que hace verificable la medida.

Además, es útil contar con un registro de cambios basado en el principio de los cuatro ojos. Quien relaje una regla de autenticación -por ejemplo, porque un departamento se queja de demasiadas verificaciones- no debería hacerlo en silencio dentro del tenant. Una aprobación documentada protege, en caso de incidente, de la acusación de haber debilitado una medida de protección sin justificación. La responsabilidad personal de la dirección según NIS2 convierte esta prueba en algo más que una formalidad.

Qué señales soporta realmente el motor de riesgo

Una MFA adaptativa solo es tan buena como las señales que evalúa. En la práctica, cuatro categorías tienen el mayor peso: el dispositivo y su estado de gestión, el contexto de red y ubicación, el comportamiento de inicio de sesión a lo largo del tiempo y las señales externas de amenazas, como direcciones IP maliciosas conocidas. Lo decisivo no es activar el mayor número posible de señales, sino saber qué afirmación aporta cada señal.

El estado de gestión del dispositivo es la señal individual más fiable. Un inicio de sesión desde un portátil registrado y conforme a través de la gestión de dispositivos móviles es sustancialmente más confiable que desde un dispositivo desconocido, independientemente de la ubicación. Las señales de ubicación, en cambio, son más débiles de lo que parecen: el uso de VPN, redes móviles y viajes generan constantemente nuevas geolocalizaciones que, por sí solas, no implican un ataque. Quien pondera demasiado la ubicación genera frustración sin mejorar la seguridad.

Aprobado en la auditoría

Conformidad del dispositivo como señal obligatoria para sistemas sensibles
Number-Matching obligatorio contra la fatiga de MFA
Política exportada y versionada con referencia a la necesidad de protección
Cuentas Break-Glass monitorizadas con alertas

Rechazado en la auditoría

Umbrales estándar sin justificación documentada
Confirmación push con simple toque sin código
Cuentas de emergencia sin registro propio
Cambios en reglas sin aprobación e historial

Number-Matching y Break-Glass: dos perillas con peso en auditoría

Dos configuraciones determinan de forma desproporcionada si una MFA adaptativa está presente en la auditoría. La primera es el tipo de confirmación. Una notificación por push que el usuario acepta con un toque invita al llamado ataque de fatiga de MFA: el atacante genera solicitudes continuas hasta que alguien, abrumado, confirma. Microsoft, Okta y Duo ofrecen en cambio una comparación de números, donde el usuario debe introducir o confirmar en la app el número mostrado en la pantalla de inicio de sesión. Esta mecánica ha estado disponible desde hace tiempo en los tres proveedores y debería ser obligatoria, no opcional.

La segunda perilla son las cuentas Break-Glass. Cada MFA adaptativa necesita accesos de emergencia excluidos de las reglas de acceso condicional bloqueantes, para que un error en la configuración no aísle completamente a la empresa. Excluir no significa dejar sin protección: estas cuentas deberían estar vinculadas a un factor especialmente fuerte, idealmente un token de hardware FIDO2 o un certificado, en lugar de simplemente evitar la verificación basada en riesgos. Dado que son un punto de ataque conocido y privilegiado, deben incluir su propia y detallada registración, para que cada uso active inmediatamente una alerta. Una cuenta excluida sin vinculación fuerte ni supervisión es un hallazgo recurrente en auditorías.

El mapeo del BSI como lenguaje común con el auditor

El último paso traduce la configuración al lenguaje que ya utiliza el auditor. El IT-Grundschutz del BSI, en el módulo ORP.4 Gestión de identidades y autorizaciones, establece requisitos que se prestan bien como marco de referencia para una MFA adaptativa. ORP.4 no es un mapeo dedicado a MFA, pero sí abarca autenticación, control de autorizaciones y accesos de emergencia. Quien refleje sus reglas de Step-up, los requisitos de dispositivos y las cuentas de emergencia frente a estas exigencias no entrega capturas de pantalla de herramientas, sino una asignación en un lenguaje que el auditor conoce.

Este mapeo no tiene por qué ser complejo. Una tabla que asocie cada exigencia básica con la regla específica de política y la ubicación del documento de prueba suele bastar en la mayoría de las auditorías. Esto traslada la conversación de la pregunta sobre si la medida corresponde al estado actual de la tecnología, a la ya respondida sobre cómo se implementa. Esa precisamente es la diferencia entre una MFA adaptativa que solo funciona y otra que actúa como control.

Preguntas frecuentes

¿Es suficiente una MFA estándar activada para cumplir con NIS2?

Técnicamente cumple con una exigencia básica, pero a menudo no es suficiente para un informe sólido. El artículo 21 de NIS2 exige medidas adecuadas al riesgo y una evaluación de su eficacia. Una MFA sin una política documentada y justificada según el nivel de protección necesario existe, pero es difícil demostrar su eficacia. La variante adaptativa con reglas exportables y versionadas facilita este informe.

¿Qué distingue a la MFA adaptativa de la MFA normal en el contexto de auditoría?

La MFA normal requiere siempre el mismo segundo factor en cada inicio de sesión. La MFA adaptativa decide dependiendo del contexto y puede documentar esta decisión como regla. Precisamente esta lógica documentable la hace más valiosa en una auditoria NIS2, ya que muestra claramente la conexión entre riesgo y medida.

¿Cuál es la norma del BSI relevante para la MFA adaptativa?

El módulo ORP.4 del IT-Grundschutz sobre gestión de identidades y autorizaciones ofrece un marco de referencia adecuado, aunque no tenga un capítulo propio sobre MFA adaptativa. Quien refleje las reglas de Step-up y las cuentas de emergencia frente a las exigencias de ORP.4 traduce la configuración de herramientas a un lenguaje que el BSI ya usa en las conversaciones de auditoría.

¿Cómo se evita que la MFA adaptativa bloquee a los empleados?

Mediante un despliegue escalonado y una ponderación razonable de señales. Las señales de ubicación deberían tener menos peso que el estado de administración de dispositivos, ya que el uso de VPN y viajes generan constantemente nuevas geolocalizaciones. Un piloto con un grupo limitado de usuarios muestra antes del despliegue general dónde se han establecido umbrales demasiado altos.

¿Por qué son las cuentas Break-Glass un tema de auditoría?

Porque están intencionalmente excluidas de directrices bloqueantes, lo que las convierte en puntos de ataque privilegiados. La exclusión es necesaria, pero debe estar vinculada a un factor especialmente fuerte, como un token FIDO2. Una cuenta de emergencia sin vinculación fuerte ni registración detallada es un hallazgo típico en una auditoría.

¿Debe versionarse la política MFA?

Para una prueba sólida, sí. Una política versionada con historial de cambios y aprobación por dos personas demuestra que las medidas de protección no se han debilitado de forma descontrolada. Dada la responsabilidad personal de la dirección según NIS2, esta prueba es mucho más que una formalidad.