Planificación para la autenticación multifactor obligatoria para Azure y otros portales de administración

En Microsoft, nos comprometemos a proporcionar a nuestros clientes el mayor nivel de seguridad. Una de las medidas de seguridad más eficaces disponibles es la autenticación multifactor (MFA). Investigaciones de Microsoft muestran que MFA puede bloquear más del 99,2% de los ataques de compromiso de cuentas.

Por eso, a partir de 2024, aplicaremos MFA obligatorio para todos los intentos de inicio de sesión de Azure. Para más información sobre este requisito, consulte nuestras entradas de blog Autenticación multifactor obligatoria de Azure: Fase 2 a partir de octubre de 2025 y Anuncio de la autenticación multifactor obligatoria para el inicio de sesión de Azure. En este tema se tratan qué aplicaciones y cuentas se ven afectadas, cómo se implementa el cumplimiento en los inquilinos y otras preguntas y respuestas comunes.

No hay ningún cambio para los usuarios si en la organización ya se les aplica MFA, o bien si inician sesión con métodos más seguros, por ejemplo sin contraseña o mediante una clave de paso (FIDO2). Para comprobar que MFA está habilitado, consulte Comprobación de que los usuarios están configurados para MFA obligatorio.

Ámbito de aplicación

El ámbito de aplicación incluye cuándo se planea que se produzca la aplicación, qué aplicaciones planean aplicar MFA, aplicaciones que están fuera del ámbito y qué cuentas tienen un requisito obligatorio de MFA.

Fases de aplicación

La aplicación de MFA para aplicaciones se implementa en dos fases.

Aplicaciones de fase 1

A partir de octubre de 2024, se requiere MFA para las cuentas que inician sesión en Azure Portal, el Centro de administración de Microsoft Entra y el Centro de administración de Microsoft Intune para realizar cualquier operación de creación, lectura, actualización o eliminación (CRUD). La aplicación se implementará gradualmente en todos los inquilinos de todo el mundo. A partir de febrero de 2025, la implementación de la autenticación multifactor (MFA) comienza gradualmente para los inicios de sesión en el Centro de administración de Microsoft 365. La fase 1 no afectará a otros clientes de Azure, como la CLI de Azure, Azure PowerShell, la aplicación móvil de Azure ni las herramientas de IaC.

Aplicaciones de fase 2

A partir del 1 de octubre de 2025, la aplicación de MFA comenzará gradualmente para las cuentas que inician sesión en la CLI de Azure, Azure PowerShell, la aplicación móvil de Azure, las herramientas de IaC y los puntos de conexión de la API REST para realizar cualquier operación de creación, actualización o eliminación. Las operaciones de lectura no requerirán MFA.

Algunos clientes pueden usar una cuenta de usuario en Microsoft Entra ID como cuenta de servicio. Se recomienda migrar estas cuentas de servicio basadas en el usuario para proteger las cuentas de servicio basadas en la nube con identidades de carga de trabajo.

Identificadores y direcciones URL de la aplicación

En la tabla siguiente se enumeran las aplicaciones afectadas, los identificadores de aplicación y las direcciones URL de Azure.

En la tabla siguiente se enumeran las aplicaciones afectadas y las direcciones URL de Microsoft 365.

Accounts

Todas las cuentas que inician sesión para realizar operaciones mencionadas en la sección de aplicaciones deben completar la autenticación multifactor (MFA) cuando comience la aplicación de la normativa. No es necesario que los usuarios usen MFA si acceden a otras aplicaciones, sitios web o servicios hospedados en Azure. Cada aplicación, sitio web o propietario del servicio enumerado anteriormente controla los requisitos de autenticación de los usuarios.

Las cuentas de acceso de emergencia o de emergencia también son necesarias para iniciar sesión con MFA una vez que comienza la aplicación. Se recomienda actualizar estas cuentas para usar la clave de acceso (FIDO2) o configurar la autenticación basada en certificados para MFA. Ambos métodos cumplen el requisito de MFA.

Las identidades de carga de trabajo, como las identidades administradas y las entidades de servicio, no se ven afectadas por ninguna de las dos fases de la aplicación de MFA. Si las identidades de usuario se usan para iniciar sesión como una cuenta de servicio para ejecutar la automatización (incluidos scripts u otras tareas automatizadas), esas identidades de usuario deben iniciar sesión con MFA una vez que comience la aplicación. No se recomiendan las identidades de usuario para la automatización. Debe migrar esas identidades de usuario a identidades de carga de trabajo.

Bibliotecas de cliente

El flujo de concesión de tokens de Credenciales de contraseña de propietario de recursos (ROPC) de OAuth 2.0 no es compatible con MFA. Después de habilitar MFA en la entidad de Microsoft Entra, las API basadas en ROPC que se utilizan en las aplicaciones generan excepciones. Para obtener más información sobre cómo migrar de las APIs basadas en ROPC en las bibliotecas de autenticación de Microsoft (MSAL), consulte Cómo migrar desde ROPC. Para obtener instrucciones de MSAL específicas del idioma, consulte las pestañas siguientes.

La misma guía general de MSAL se aplica a las bibliotecas de identidad de Azure. La UsernamePasswordCredential clase proporcionada en esas bibliotecas usa las API basadas en ROPC de MSAL. Para obtener instrucciones específicas del lenguaje, consulte las pestañas siguientes.

Migración de cuentas de servicio basadas en usuarios a identidades de carga de trabajo

Se recomienda que los clientes detecten cuentas de usuario que se usan como cuentas de servicio y empiecen a migrarlas a identidades de carga de trabajo. Normalmente, en una migración, es necesario actualizar guiones y procesos de automatización para utilizar identidades de carga de trabajo.

Revisar Cómo comprobar que los usuarios están configurados para el MFA obligatorio para identificar todas las cuentas de usuario, incluidas las usadas como cuentas de servicio, que inician sesión en las aplicaciones.

Para más información sobre cómo migrar de cuentas de servicio basadas en usuarios a identidades de carga de trabajo para la autenticación con estas aplicaciones, vea lo siguiente:

• Inicio de sesión en Azure con una identidad administrada mediante la CLI de Azure
• Inicio de sesión en Azure con una entidad de servicio mediante la CLI de Azure
• Iniciar sesión en Azure PowerShell de forma no interactiva para escenarios de automatización se incluyen instrucciones para casos de uso de identidades administradas y entidades de servicio

Algunos clientes aplican directivas de acceso condicional a cuentas de servicio basadas en el usuario. Puede reclamar la licencia basada en usuarios y agregar una licencia de identidades de carga de trabajo para aplicar Acceso Condicional a las identidades de carga de trabajo.

Migración del proveedor de identidades federado a métodos de autenticación externos

La compatibilidad con soluciones MFA externas está en versión preliminar con métodos de autenticación externos y se puede usar para satisfacer el requisito de MFA. La versión preliminar de controles personalizados de Acceso condicional heredado no satisface el requisito de MFA. Debe migrar a la versión preliminar de los métodos de autenticación externos para usar una solución externa con Microsoft Entra ID.

Si usa un Proveedor de identidades federado (IdP), como Servicios de federación de Active Directory (AD FS), y el proveedor de MFA se integra directamente con este IdP federado, el IdP federado debe configurarse para enviar una declaración de MFA. Para obtener más información, consulte Aserciones de entrada esperadas para Microsoft Entra MFA.

Prepárate para la aplicación obligatoria de la autenticación multifactor

Para prepararse para la aplicación de MFA, configure una directiva de acceso condicional que requiera que los usuarios inicien sesión con MFA. Si configuró excepciones o exclusiones en la directiva, ya no se aplican. Si tiene directivas de acceso condicional más restrictivas que tienen como destino Azure y requiere una autenticación más sólida, como MFA resistente a la suplantación de identidad (phishing), se siguen aplicando.

El acceso condicional requiere una licencia P1 o P2 de Microsoft Entra ID. Si no puede usar el acceso condicional, habilite los valores predeterminados de seguridad.

Puede aplicar MFA automáticamente mediante definiciones integradas en Azure Policy. Para más información y seguir una introducción paso a paso para aplicar estas asignaciones de directivas en su entorno, consulte Tutorial: Aplicación del cumplimiento automático de MFA a través de Azure Policy.

Para obtener la mejor experiencia de compatibilidad, asegúrese de que los usuarios del inquilino usan la VERSIÓN 2.76 de la CLI de Azure y azure PowerShell versión 14.3 o posterior. De lo contrario, puede esperar ver mensajes de error como se explica en estos temas:

• Solución de errores de MFA en Azure PowerShell
• Solución de errores de MFA en la CLI de Azure

Solicitar más tiempo para prepararse para la implementación de la fase 1 de MFA

Entendemos que algunos clientes pueden necesitar más tiempo a fin de prepararse para este requisito de MFA. Microsoft permite a los clientes con entornos complejos o barreras técnicas posponer la aplicación de la fase 1 para sus inquilinos hasta el 30 de septiembre de 2025.

Para cada inquilino en el que desee posponer la fecha de inicio de la aplicación, un administrador global puede ir a la https://aka.ms/managemfaforazure para seleccionar una fecha de inicio.

Solicitar más tiempo para prepararse para la aplicación de la fase 2 MFA

Microsoft permite a los clientes con entornos complejos o barreras técnicas posponer la aplicación de la fase 2 para sus inquilinos hasta el 1 de julio de 2026. Puede solicitar más tiempo para prepararse para la implementación de MFA de Fase 2 en https://aka.ms/postponePhase2MFA. Elija otra fecha de inicio y haga clic en Aplicar.

Confirmación de la aplicación obligatoria de MFA

Después del cumplimiento, aparece un banner en Azure Portal:

Los registros de inicio de sesión de Microsoft Entra ID muestran la aplicación que haya aplicado MFA como origen del requisito de MFA.

FAQs

Pregunta: Si el inquilino solo se usa para pruebas, ¿se requiere MFA?

Respuesta: Sí, cada inquilino de Azure requerirá MFA, sin ninguna excepción para entornos de prueba.

Pregunta: ¿Cómo afecta este requisito al Centro de administración de Microsoft 365?

Respuesta: MFA obligatoria se implementará en el Centro de administración de Microsoft 365 a partir de febrero de 2025. Obtenga más información sobre el requisito obligatorio de MFA para el Centro de administración de Microsoft 365 en la entrada de blog Anuncio de la autenticación multifactor obligatoria para el Centro de administración de Microsoft 365.

Pregunta: ¿Es obligatorio MFA para todos los usuarios o solo administradores?

Respuesta: Todos los usuarios que inician sesión en cualquiera de las aplicaciones enumeradas anteriormente deben completar MFA, independientemente de los roles de administrador que estén activados o aptos para ellas, o cualquier exclusión de usuario habilitada para ellas.

Pregunta: ¿Necesito completar MFA si elijo la opción Mantener sesión iniciada?

Respuesta: Sí, incluso si elige Mantener sesión iniciada, es necesario completar MFA para poder iniciar sesión en estas aplicaciones.

Pregunta: ¿Se aplica la aplicación a las cuentas de invitado B2B?

Respuesta: Sí, MFA debe cumplirse desde el inquilino de recursos del asociado o el inquilino principal del usuario si está configurado correctamente para enviar notificaciones de MFA al inquilino de recursos mediante el acceso entre inquilinos.

Pregunta: ¿Se aplica el cumplimiento a Azure para el Gobierno de EE. UU. o a las nubes soberanas de Azure?

Respuesta: Microsoft aplica MFA obligatorio solo en la nube pública de Azure. Microsoft no aplica actualmente MFA en Azure para la Administración Pública de EE. UU. ni en otras nubes soberanas de Azure.

Pregunta: ¿Cómo podemos cumplir si aplicamos MFA mediante otro proveedor de identidades o solución de MFA, y no aplicamos mediante Microsoft Entra MFA?

Respuesta: MFA de terceros se puede integrar directamente con microsoft Entra ID. Para obtener más información, consulte Referencia del proveedor de métodos externos de autenticación multifactor de Microsoft Entra. El identificador de Entra de Microsoft se puede configurar opcionalmente con un proveedor de identidades federado. Si es así, la solución del proveedor de identidades debe configurarse correctamente para enviar la notificación multipleauthn a Microsoft Entra ID. Para obtener más información, consulte Satisfacer los controles de autenticación multifactor (MFA) de Microsoft Entra ID con notificaciones de MFA de un IdP federado.

Pregunta: ¿Afectará la MFA obligatoria a mi capacidad de sincronizar con Microsoft Entra Connect o Microsoft Entra Cloud Sync?

Respuesta: No. La cuenta de servicio de sincronización no se ve afectada por el requisito obligatorio de la MFA. Solo las aplicaciones enumeradas anteriormente requieren MFA para el inicio de sesión.

Pregunta: ¿Puedo optar por no participar?

Respuesta: No hay forma de rechazarlo. Este movimiento de seguridad es fundamental para la seguridad y la seguridad de la plataforma Azure y se repite en los proveedores de nube. Por ejemplo, consulte Secure by Design: AWS para mejorar los requisitos de MFA en 2024.

Hay disponible una opción a fin de posponer la fecha de inicio de aplicación para los clientes. Los administradores globales pueden ir al Azure Portal para posponer la fecha de inicio del cumplimiento de su inquilino. Los administradores globales deben tener acceso elevado antes de aplazar la fecha de inicio de la aplicación de la autenticación multifactor (MFA) en esta página. Deben realizar esta acción para cada inquilino que necesite un aplazamiento.

Pregunta: ¿Puedo probar MFA antes de que Azure aplique la directiva para asegurarse de que no se interrumpe nada?

Respuesta: Sí, puede probar su MFA a través del proceso de configuración manual de MFA. Le animamos a configurarlo y probarlo. Si usa el acceso condicional para aplicar la MFA, puede usar plantillas de acceso condicional para probar la directiva. Para obtener más información, consulte Requerir autenticación multifactor para los administradores que acceden a los portales de administración de Microsoft. Si ejecuta una edición gratuita de Microsoft Entra ID, puede habilitar los valores predeterminados de seguridad.

Pregunta: ¿Qué ocurre si ya tengo MFA habilitado, ¿qué ocurre a continuación?

Respuesta: Los clientes que ya requieren MFA para sus usuarios que acceden a las aplicaciones enumeradas anteriormente no ven ningún cambio. Si solo necesita MFA para un subconjunto de usuarios, los usuarios que aún no usen MFA tendrán que usar MFA cuando inicien sesión en las aplicaciones.

Pregunta: ¿Cómo puedo revisar la actividad de MFA en microsoft Entra ID?

Respuesta: Para revisar los detalles sobre cuándo se pide a un usuario que inicie sesión con MFA, use los registros de inicio de sesión de Microsoft Entra. Para obtener más información, consulte Detalles del evento de inicio de sesión para la autenticación multifactor de Microsoft Entra.

Pregunta: ¿Qué ocurre si tengo una situación de emergencia crítica?

Respuesta: Se recomienda actualizar estas cuentas para usar la clave de acceso (FIDO2) o configurar la autenticación basada en certificados para MFA. Ambos métodos cumplen el requisito de MFA.

Pregunta: ¿Qué ocurre si no recibo un correo electrónico sobre cómo habilitar MFA antes de que se aplique y, a continuación, me bloquean. ¿Cómo debo resolverlo?

Respuesta: Los usuarios no deben bloquearse, pero pueden recibir un mensaje que les pida que habilite MFA una vez que se haya iniciado la aplicación de MFA para su inquilino. Si el usuario está bloqueado, puede deberse a otros problemas. Para obtener más información, consulte Cuenta bloqueada.

Contenido relacionado

Revise los temas siguientes para obtener más información sobre cómo configurar e implementar MFA:

• Cómo posponer la aplicación de la normativa para un inquilino donde los usuarios no pueden firmar
• Cómo verificar que los usuarios están configurados para MFA obligatorio
• Tutorial: Protección de eventos de inicio de sesión de usuario con la autenticación multifactor de Microsoft Entra
• Protección de eventos de inicio de sesión con Microsoft Entra multifactor
• Planear una implementación de autenticación multifactor de Microsoft Entra
• Métodos de MFA resistentes a la suplantación de identidad (phishing)
• Autenticación multifactor de Microsoft Entra
• Métodos de autenticación