1.  Introducción

Recientemente Microsoft anunció que la MFA (Autenticación multifactor) para los usuarios será obligatoria a partir de Julio de 2024, debido a que tenemos procesos que corren con usuarios que no son personales necesitaremos deshabilitar el MFA para que dichos procesos sigan corriendo con normalidad. Para ellos una de las opciones más sencillas que no implica hacer cambios en los procesos es habilitar el acceso condicional y excluir a dichos usuarios del MFA.

En Power Platform, cuando te enfrentas a la necesidad de configurar excepciones de MFA para cuentas no humanas (como las utilizadas en Power Automate), es importante considerar el uso de Service Principals o Managed Identities como alternativas más seguras y manejables. En algún momento escribiré más en profundidad acerca de estas 2 opciones.

Service Principals son ideales para escenarios donde se requiere una identidad no humana para ejecutar flujos, especialmente donde se emplean pipelines de DevOps para mover flujos entre entornos de desarrollo, prueba y producción. Esto asegura que el flujo no dependa de la cuenta de un usuario individual, que podría ser desactivada si la persona cambia de rol o deja la organización, evitando interrupciones en la operación​.

Por otro lado, Managed Identities son una excelente opción cuando se necesita integrar la seguridad de la identidad directamente con otros recursos de Azure, como máquinas virtuales o aplicaciones web. Estas identidades pueden ser gestionadas automáticamente por Azure, lo que simplifica la administración de credenciales y las rotaciones de claves, eliminando la necesidad de almacenar secretos en código o configuraciones. Esto es particularmente útil en aplicaciones o servicios que necesitan acceder a otros recursos de Azure, como Azure Key Vault​, Functions o cualquier otro servicio que se os ocurra.

Sin embargo, no siempre es posible o práctico usar Service Principals o Managed Identities en Power Platform debido a limitaciones en la integración con ciertos conectores o la necesidad de cumplir con políticas de seguridad específicas. En estos casos, la configuración de excepciones de MFA puede ser necesaria, aunque esto debería ser cuidadosamente gestionado para minimizar riesgos​

En el enlace de abajo viene el anuncio de Microsoft donde indica la obligatoriedad de la MFA a partir de Julio de 2024:

https://learn.microsoft.com/es-es/partner-center/announcements/2024-may#mfa-implementation

2.  Condiciones previas

Antes de poder habilitar el acceso condicional debemos cumplir una serie de condiciones:

1.      Es necesario tener al menos una licencia Microsoft Entra ID P1.

2. Debemos tener en el tenant los valores predeterminados de seguridad predeterminados desactivamos.

Para deshabilitar los valores predeterminados de seguridad en el tenant de Microsoft, siga estos pasos:

1. Iniciar sesión en el Centro de administración de Microsoft Entra

2. Haga clic en Identidad > información general > propiedades

3. Seleccione Administrar valores predeterminados de seguridad

4. Establezca los valores predeterminados de seguridad en Deshabilitado

5. Seleccione un motivo para deshabilitar los valores predeterminados de seguridad (seleccionamos Acceso Condicional)

6. Haga clic en Guardar

7. Confirme que los valores predeterminados de seguridad aparecen como Su organización no está protegida por valores predeterminados de seguridad

2.  Configurar Acceso Condicional

Una vez el acceso condicional este habilitado tenemos que crear una directiva para excluir a los usuarios que sean impersonales para que no usen la MFA. Los pasos a seguir son los siguientes

1. Inicie sesión en el Centro de administración de Microsoft Entra al menos como Administrador de acceso condicional.

2. Vaya a Protección>Acceso condicional>Directivas.

3. Seleccione Nueva directiva.

4.

5. Asigne un nombre a la directiva. Se recomienda que las organizaciones creen un estándar significativo para los nombres de sus directivas.

6. En Assignments (Asignaciones), seleccione Users or workload identities (Identidades de usuario o de carga de trabajo).

a. En Incluir, seleccione Todos los usuarios

b. En Excluir, seleccione Usuarios y grupos y, luego, elija las cuentas de acceso de emergencia de la organización.

7. En Recursos de destino>Aplicaciones en la nube>Incluir, seleccione Todas las aplicaciones en la nube.

a. En Excluir, seleccione las aplicaciones que no requieren autenticación multifactor.

8. En Controles de acceso>Conceder, seleccione Conceder acceso, Requerir autenticación multifactor y Seleccionar.

9. Confirme la configuración y establezca Habilitar directiva en Solo informe.

10.  Seleccione Crear para crear la directiva.

Después de que los administradores confirmen la configuración mediante el modo de solo informe, podrán pasar el botón de alternancia Habilitar directiva de Solo informe a Activar.

¿Cuándo aplicar estas excepciones?

Al considerar cuándo se debe utilizar la exclusión de MFA en servicios de Power Platform, como Power Automate, las conclusiones principales son las siguientes:

1. Cuentas de Servicio No Humanas: La exclusión de MFA es más justificada para cuentas que no están asociadas a usuarios individuales, sino a procesos automatizados que requieren acceso continuo sin interrupciones. Estas cuentas suelen ser críticas para la operación de flujos y la automatización de tareas donde una interrupción por un desafío de MFA podría causar fallos en procesos importantes.
2. Limitaciones Técnicas en la Integración: En escenarios donde no es factible utilizar Service Principals o Managed Identities debido a limitaciones en los conectores o en la infraestructura, la exclusión de MFA puede ser una solución temporal. Sin embargo, esta debe ser evaluada cuidadosamente para evitar crear brechas de seguridad.
3. Flujos Críticos: Para flujos que tienen un impacto significativo en la operación empresarial y que deben mantenerse activos sin interrupciones, la exclusión de MFA podría ser necesaria para garantizar la continuidad del servicio. Sin embargo, es muy importante implementar controles adicionales para mitigar los riesgos, como la monitorización de accesos y la implementación de políticas de acceso condicional específicas.
4. Entornos de Desarrollo y Prueba: En entornos no productivos donde la seguridad no es tan crítica como en producción, podría considerarse la exclusión de MFA para facilitar el desarrollo y las pruebas. Aun así, es recomendable que estas excepciones se gestionen cuidadosamente y se limiten a los entornos de desarrollo, no a producción.
5. Proceso de Revisión Regular: Cualquier exclusión de MFA debe ser revisada periódicamente para asegurarse de que sigue siendo necesaria y que no ha introducido vulnerabilidades innecesarias en el sistema. Esto incluye auditar regularmente el acceso y evaluar si las cuentas pueden migrar a una solución más segura como Managed Identities o Service Principals.

Artículos relacionados

Solicitar MFA para todos los usuarios con acceso condicional - Microsoft Entra ID | Microsoft Learn