Empiece por los administradores y aplíqueles, mediante Conditional Access, la authentication strength integrada Phishing-resistant MFA. Solo permite Windows Hello for Business o una credencial de plataforma, una clave de seguridad FIDO2 o la autenticación basada en certificados de Entra (multifactor). Los SMS y las aprobaciones push dejan de satisfacer la política para esas cuentas en los recursos que cubre, aunque la solicitud de contraseña se mantiene (véase Qué falla).
Por qué empezar por los administradores
La descripción general de autenticación de Microsoft señala que el MFA basado en SMS, OTP por correo electrónico o aplicaciones de autenticación es vulnerable al phishing remoto, en el que los atacantes roban contraseñas o códigos de un solo uso sin tocar el dispositivo del usuario. Microsoft recomienda en su lugar Windows Hello for Business, passkeys (FIDO2), claves de seguridad FIDO2 o autenticación basada en certificados. Una cuenta de administrador es donde más cuesta que roben un código, y un equipo pequeño solo tiene unas pocas que migrar.
Tenga cuidado con la opción integrada intermedia. Según la documentación de authentication strengths, la strength Passwordless MFA incluye el inicio de sesión desde el teléfono con Microsoft Authenticator. La strength Phishing-resistant no lo incluye.
Prepare el tenant
Las passkeys (FIDO2) están disponibles en todas las ediciones de Entra ID sin licencia adicional. Conditional Access requiere Entra ID P1.
La configuración está en Entra ID > Security > Authentication methods > Policies > Passkey (FIDO2). Necesita como mínimo el rol de Authentication Policy Administrator. Hay tres detalles importantes:
- Adoptar los perfiles de passkeys es un paso sin retorno. Después no puede deshacerlo, y su configuración global actual pasa a un perfil Default. Se admiten hasta tres perfiles, incluido Default.
- Allow self-service set up debe estar en Yes, o los usuarios no podrán registrar una passkey a través de Security info. Es un ajuste global, no de cada perfil.
- El registro exige haber completado MFA en los últimos cinco minutos.
Para los administradores, el ejemplo de la propia documentación es un perfil con tipo de passkey Device-bound y Enforce attestation en Yes. Device-bound significa que la clave privada nunca sale de un único dispositivo físico, como una clave de seguridad o Microsoft Authenticator. Las passkeys sincronizadas no admiten attestation, y Microsoft indica que deben tratarse como resistentes al phishing, pero con el nivel de seguridad de otros autenticadores sin attestation. El texto del NIST exige en AAL3, su nivel más alto, un autenticador resistente al phishing con una clave no exportable, así que las claves device-bound son la opción que más se acerca entre las que ofrece Entra.
Aplique la política con una authentication strength
Cree una política de Conditional Access, seleccione como destino sus roles de administrador o un grupo y, en los controles de concesión, elija Require authentication strength. Seleccione Phishing-resistant MFA. No puede combinarla con Require multifactor authentication en la misma política, porque la strength de MFA integrada equivale a ese control.
Las strengths integradas no se pueden editar, y Microsoft las actualiza cuando aparecen métodos nuevos. Si necesita un conjunto fijo de métodos permitidos, cree una strength personalizada.
No hace falta desactivar el SMS para todo el mundo. La strength se sitúa sobre la política de Authentication methods y la restringe para un escenario concreto. El resto de la plantilla puede conservar la contraseña y la aprobación push para los recursos habituales, mientras que los administradores quedan sujetos a la política más estricta.
Qué falla
Un administrador sigue escribiendo primero una contraseña. Conditional Access se evalúa después de la autenticación inicial, de modo que la strength solo exige entonces un método resistente al phishing.
Si un usuario inicia sesión con una contraseña como método principal y la strength exige Windows Hello for Business, no se le solicita. Debe reiniciar la sesión, seleccionar Sign-in options y elegir el método requerido. Incluya esto en sus instrucciones para administradores.
Dos controles actúan en momentos distintos. Enforce attestation se aplica solo en el registro, así que una passkey registrada sin attestation no se bloquea al iniciar sesión una vez que lo activa. Vuelva a registrar después las claves de los administradores. Las restricciones de claves por AAGUID se aplican tanto al registro como al inicio de sesión, de modo que retirar un AAGUID permitido anteriormente bloquea a todos los que registraron ese modelo.
El solapamiento de perfiles es permisivo y afecta al registro y al inicio de sesión en el nivel de la política de passkeys. Cuando un usuario entra en varios perfiles, se permite una passkey si cumple íntegramente al menos uno de ellos, sin ningún orden concreto. Un administrador que además pertenezca a un grupo "todas, sincronizadas o device-bound" puede, por tanto, registrar y usar una passkey sincronizada en lo que respecta a la política de passkeys. Las fuentes no indican si la strength de Conditional Access la acepta, así que pruebe ese caso.
Tras adoptar los perfiles, revise el perfil Default en Enable and target. Si su destino es All users y permite passkeys sincronizadas, redirija el destino a grupos que no contengan a sus administradores. No excluya en su lugar a los administradores en la política de Passkey (FIDO2): un grupo excluido queda bloqueado por completo para el registro y el inicio de sesión con FIDO2, y eso prevalece sobre cualquier inclusión.
El sign-in frequency y la strength pueden cumplirse en momentos distintos. Con una strength de passkey y un sign-in frequency de 1 hora, un inicio de sesión con passkey de hace 24 horas más un desbloqueo del dispositivo con Windows Hello hoy satisfacen ambos requisitos. Si para los administradores se apoya en frecuencias cortas, pruebe este caso.
Temporary Access Pass aparece en la strength de MFA, pero no en la resistente al phishing. Es una inferencia nuestra, que las fuentes no recogen: un flujo de recuperación o de arranque basado en Temporary Access Pass no satisfará la política, por lo que necesitará una exclusión o una política aparte. Decídalo antes de aplicar la política, no durante el incidente.
Por dónde empezar
- Haga una lista de todas las cuentas con un rol de administrador y elija dos o tres para el grupo piloto.
- Adopte los perfiles de passkeys, revise el destino del perfil Default, cree un perfil de administrador con Device-bound y Enforce attestation en Yes, y aplíquelo solo al grupo piloto.
- Registre al menos dos autenticadores por administrador piloto, por ejemplo una clave de seguridad y Windows Hello, y compruebe que el inicio de sesión funciona con cada uno.
- Cree la política de Conditional Access con la strength Phishing-resistant MFA para el grupo piloto. Como práctica general (las páginas de Microsoft utilizadas aquí no tratan las cuentas break-glass), excluya las cuentas de acceso de emergencia y asigne a cada una su propia clave FIDO2.
- Amplíe a todos los administradores. Elimine las passkeys registradas antes de aplicar attestation solo cuando cada administrador haya vuelto a registrar una clave con attestation, para que nadie quede bloqueado.
- Haga que se pruebe el resultado. Nuestro equipo de consultoría puede revisar la política, y una prueba de penetración muestra si alguna vía de administración sigue aceptando un método más débil.
