8 min. de lectura<\/p>\n
Una MFA adaptativa que funciona en el inicio de sesi\u00f3n seguir\u00e1 fallando en una auditor\u00eda si nadie puede demostrar qu\u00e9 regla determina cu\u00e1ndo exige el segundo factor.<\/strong> Precisamente esta brecha pasa al primer plano con la NIS2: la directiva no solo exige que exista una autenticaci\u00f3n 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\u00e1 una tecnolog\u00eda, pero, en el mejor de los casos, carecer\u00e1 de una justificaci\u00f3n documentada.<\/p>\n Lo m\u00e1s importante en resumen<\/p>\n Relacionado:<\/span>La vulnerabilidad que solo la IA encontr\u00f3<\/a> \/<\/span> El plan de emergencia que nadie ensay\u00f3<\/a><\/p>\n \u00bfQu\u00e9 es la MFA adaptativa?<\/strong> La autenticaci\u00f3n multifactor adaptativa o basada en riesgos eval\u00faa cada inicio de sesi\u00f3n mediante se\u00f1ales de contexto y solo exige el segundo factor cuando el riesgo supera un umbral definido. Un inicio de sesi\u00f3n desde un port\u00e1til gestionado en la red de la oficina se permite sin m\u00e1s, mientras que el mismo identificador desde una nueva direcci\u00f3n IP en otro pa\u00eds desencadena una consulta de escalado o se bloquea. La tecnolog\u00eda subyacente est\u00e1 disponible en Entra ID, Okta y Duo desde hace a\u00f1os.<\/p>\n El punto en el que incide la NIS2 no reside \u00fanicamente en la tecnolog\u00eda. El art\u00edculo 21, apartado 2, de la directiva exige medidas proporcionales al riesgo, acordes con el estado de la t\u00e9cnica, as\u00ed como conceptos para evaluar su eficacia. La directiva menciona expl\u00edcitamente la autenticaci\u00f3n multifactor como medida adecuada cuando proceda. Para una auditor\u00eda, esto desplaza la pregunta clave: ya no se trata tanto de si la MFA est\u00e1 activada, sino de qu\u00e9 regla determina la activaci\u00f3n del segundo factor, qui\u00e9n asume la responsabilidad de dicha regla y si el umbral se ajusta al nivel de protecci\u00f3n de los sistemas afectados.<\/p>\n Aqu\u00ed es donde fallan muchas configuraciones que en la pr\u00e1ctica funcionan a la perfecci\u00f3n. Las reglas existen como directiva de acceso condicional en el tenant, pero nadie las ha exportado jam\u00e1s como documento, nadie puede mostrar su historial y los valores umbral se han tomado de la configuraci\u00f3n predeterminada sin que nadie los haya justificado frente al riesgo propio. La medida existe, pero falta la prueba de su eficacia.<\/p>\n El primer paso pr\u00e1ctico es poco espectacular: la pol\u00edtica de autenticaci\u00f3n 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\u00edticas de acceso condicional a trav\u00e9s de Microsoft Graph como JSON; en Okta, mediante la API de pol\u00edticas, y en Duo, a trav\u00e9s de la API de administraci\u00f3n. Esta exportaci\u00f3n debe versionarse en el mismo repositorio donde se encuentra el resto de la documentaci\u00f3n de seguridad.<\/p>\n M\u00e1s importante que el formato es la justificaci\u00f3n que lo acompa\u00f1a. Para cada condici\u00f3n de step-up debe incluirse una frase que explique por qu\u00e9 se ha elegido ese umbral. Un ejemplo: en el caso de cuentas con acceso a la contabilidad, la verificaci\u00f3n step-up se activa ya ante una geolocalizaci\u00f3n desconocida, porque estos sistemas se clasifican como de alto nivel seg\u00fan el propio an\u00e1lisis de necesidades de protecci\u00f3n. Para una wiki interna, basta con una regla m\u00e1s laxa. Esta conexi\u00f3n entre la necesidad de protecci\u00f3n y la regla de autenticaci\u00f3n es precisamente lo que hace verificable la medida.<\/p>\n Adem\u00e1s, es \u00fatil contar con un registro de cambios basado en el principio de los cuatro ojos. Quien relaje una regla de autenticaci\u00f3n -por ejemplo, porque un departamento se queja de demasiadas verificaciones- no deber\u00eda hacerlo en silencio dentro del tenant. Una aprobaci\u00f3n documentada protege, en caso de incidente, de la acusaci\u00f3n de haber debilitado una medida de protecci\u00f3n sin justificaci\u00f3n. La responsabilidad personal de la direcci\u00f3n seg\u00fan NIS2 convierte esta prueba en algo m\u00e1s que una formalidad.<\/p>\n Una MFA adaptativa solo es tan buena como las se\u00f1ales que eval\u00faa. En la pr\u00e1ctica, cuatro categor\u00edas tienen el mayor peso: el dispositivo y su estado de gesti\u00f3n, el contexto de red y ubicaci\u00f3n, el comportamiento de inicio de sesi\u00f3n a lo largo del tiempo y las se\u00f1ales externas de amenazas, como direcciones IP maliciosas conocidas. Lo decisivo no es activar el mayor n\u00famero posible de se\u00f1ales, sino saber qu\u00e9 afirmaci\u00f3n aporta cada se\u00f1al.<\/p>\n El estado de gesti\u00f3n del dispositivo es la se\u00f1al individual m\u00e1s fiable. Un inicio de sesi\u00f3n desde un port\u00e1til registrado y conforme a trav\u00e9s de la gesti\u00f3n de dispositivos m\u00f3viles es sustancialmente m\u00e1s confiable que desde un dispositivo desconocido, independientemente de la ubicaci\u00f3n. Las se\u00f1ales de ubicaci\u00f3n, en cambio, son m\u00e1s d\u00e9biles de lo que parecen: el uso de VPN, redes m\u00f3viles y viajes generan constantemente nuevas geolocalizaciones que, por s\u00ed solas, no implican un ataque. Quien pondera demasiado la ubicaci\u00f3n genera frustraci\u00f3n sin mejorar la seguridad.<\/p>\n Aprobado en la auditor\u00eda<\/p>\n Rechazado en la auditor\u00eda<\/p>\n Dos configuraciones determinan de forma desproporcionada si una MFA adaptativa est\u00e1 presente en la auditor\u00eda. La primera es el tipo de confirmaci\u00f3n. Una notificaci\u00f3n 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\u00f3n de n\u00fameros, donde el usuario debe introducir o confirmar en la app el n\u00famero mostrado en la pantalla de inicio de sesi\u00f3n. Esta mec\u00e1nica ha estado disponible desde hace tiempo en los tres proveedores y deber\u00eda ser obligatoria, no opcional.<\/p>\n 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\u00f3n no a\u00edsle completamente a la empresa. Excluir no significa dejar sin protecci\u00f3n: estas cuentas deber\u00edan estar vinculadas a un factor especialmente fuerte, idealmente un token de hardware FIDO2 o un certificado, en lugar de simplemente evitar la verificaci\u00f3n basada en riesgos. Dado que son un punto de ataque conocido y privilegiado, deben incluir su propia y detallada registraci\u00f3n, para que cada uso active inmediatamente una alerta. Una cuenta excluida sin vinculaci\u00f3n fuerte ni supervisi\u00f3n es un hallazgo recurrente en auditor\u00edas.<\/p>\n El \u00faltimo paso traduce la configuraci\u00f3n al lenguaje que ya utiliza el auditor. El IT-Grundschutz del BSI, en el m\u00f3dulo ORP.4 Gesti\u00f3n 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\u00ed abarca autenticaci\u00f3n, 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\u00f3n en un lenguaje que el auditor conoce.<\/p>\n Este mapeo no tiene por qu\u00e9 ser complejo. Una tabla que asocie cada exigencia b\u00e1sica con la regla espec\u00edfica de pol\u00edtica y la ubicaci\u00f3n del documento de prueba suele bastar en la mayor\u00eda de las auditor\u00edas. Esto traslada la conversaci\u00f3n de la pregunta sobre si la medida corresponde al estado actual de la tecnolog\u00eda, a la ya respondida sobre c\u00f3mo se implementa. Esa precisamente es la diferencia entre una MFA adaptativa que solo funciona y otra que act\u00faa como control.<\/p>\n T\u00e9cnicamente cumple con una exigencia b\u00e1sica, pero a menudo no es suficiente para un informe s\u00f3lido. El art\u00edculo 21 de NIS2 exige medidas adecuadas al riesgo y una evaluaci\u00f3n de su eficacia. Una MFA sin una pol\u00edtica documentada y justificada seg\u00fan el nivel de protecci\u00f3n necesario existe, pero es dif\u00edcil demostrar su eficacia. La variante adaptativa con reglas exportables y versionadas facilita este informe.<\/p>\n La MFA normal requiere siempre el mismo segundo factor en cada inicio de sesi\u00f3n. La MFA adaptativa decide dependiendo del contexto y puede documentar esta decisi\u00f3n como regla. Precisamente esta l\u00f3gica documentable la hace m\u00e1s valiosa en una auditoria NIS2, ya que muestra claramente la conexi\u00f3n entre riesgo y medida.<\/p>\n El m\u00f3dulo ORP.4 del IT-Grundschutz sobre gesti\u00f3n de identidades y autorizaciones ofrece un marco de referencia adecuado, aunque no tenga un cap\u00edtulo 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\u00f3n de herramientas a un lenguaje que el BSI ya usa en las conversaciones de auditor\u00eda.<\/p>\n Mediante un despliegue escalonado y una ponderaci\u00f3n razonable de se\u00f1ales. Las se\u00f1ales de ubicaci\u00f3n deber\u00edan tener menos peso que el estado de administraci\u00f3n 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\u00f3nde se han establecido umbrales demasiado altos.<\/p>\n Porque est\u00e1n intencionalmente excluidas de directrices bloqueantes, lo que las convierte en puntos de ataque privilegiados. La exclusi\u00f3n es necesaria, pero debe estar vinculada a un factor especialmente fuerte, como un token FIDO2. Una cuenta de emergencia sin vinculaci\u00f3n fuerte ni registraci\u00f3n detallada es un hallazgo t\u00edpico en una auditor\u00eda.<\/p>\n Para una prueba s\u00f3lida, s\u00ed. Una pol\u00edtica versionada con historial de cambios y aprobaci\u00f3n por dos personas demuestra que las medidas de protecci\u00f3n no se han debilitado de forma descontrolada. Dada la responsabilidad personal de la direcci\u00f3n seg\u00fan NIS2, esta prueba es mucho m\u00e1s que una formalidad.<\/p>\n M\u00e1s del MBF Media Netzwerk<\/p>\n\n
Por qu\u00e9 la NIS2 audita la pol\u00edtica de MFA, y no la funci\u00f3n de MFA<\/h2>\n
Configurar la pol\u00edtica como artefacto exportable<\/h2>\n
Qu\u00e9 se\u00f1ales soporta realmente el motor de riesgo<\/h2>\n
\n
\n
Number-Matching y Break-Glass: dos perillas con peso en auditor\u00eda<\/h2>\n
El mapeo del BSI como lenguaje com\u00fan con el auditor<\/h2>\n
Preguntas frecuentes<\/h2>\n
\u00bfEs suficiente una MFA est\u00e1ndar activada para cumplir con NIS2?<\/h3>\n
\u00bfQu\u00e9 distingue a la MFA adaptativa de la MFA normal en el contexto de auditor\u00eda?<\/h3>\n
\u00bfCu\u00e1l es la norma del BSI relevante para la MFA adaptativa?<\/h3>\n
\u00bfC\u00f3mo se evita que la MFA adaptativa bloquee a los empleados?<\/h3>\n
\u00bfPor qu\u00e9 son las cuentas Break-Glass un tema de auditor\u00eda?<\/h3>\n
\u00bfDebe versionarse la pol\u00edtica MFA?<\/h3>\n
Recomendaciones de lectura de la redacci\u00f3n<\/h3>\n
\n