Autenticación multifactor y acceso condicional

Las credenciales robadas son la principal causa de las brechas de seguridad en la nube. Una contraseña por sí sola puede obtenerse mediante phishing, adivinarse por fuerza bruta o filtrarse en una brecha de seguridad de terceros. La autenticación multifactor (MFA) requiere un segundo factor de verificación que es poco probable que un atacante posea incluso después de obtener una contraseña, lo que reduce considerablemente el riesgo de acceso no autorizado a su entorno de Azure.

Entra ID admite varios factores de verificación de MFA. La opción más segura y recomendada es la aplicación Microsoft Authenticator, que proporciona coincidencia de números y notificaciones push. Otras opciones son una clave de seguridad FIDO2 (token de hardware), un token OATH de software, un mensaje de texto SMS o una llamada de voz. Los SMS y las llamadas de voz se consideran menos seguros y solo deben utilizarse como opciones de respaldo.

La MFA en Entra ID se puede aplicar mediante tres mecanismos. Security defaults es la opción gratuita de un solo clic que aplica MFA a todos los usuarios, pero sin opciones de personalización. La MFA por usuario (heredada) habilita MFA en cuentas de usuario específicas. El enfoque moderno recomendado son las políticas de Conditional Access (Entra ID P1/P2), que aplican MFA únicamente cuando se cumplen determinadas condiciones de riesgo, reduciendo las molestias para los inicios de sesión de bajo riesgo.

Conditional Access (Entra ID P1) es un motor de directivas basado en condiciones: si un usuario (o grupo) intenta acceder a un recurso en determinadas condiciones, entonces se concede o se bloquea el acceso, o se requieren controles adicionales como MFA o un dispositivo compatible. Las condiciones pueden incluir la identidad del usuario, el cumplimiento del dispositivo, la ubicación IP, la aplicación a la que se accede y la puntuación de riesgo de Entra ID Identity Protection.

Una directiva de Conditional Access tiene dos partes: Assignments (a quién y a qué se aplica la directiva) y Access Controls (qué ocurre cuando se activa la directiva). Assignments define los Users/groups, las Cloud apps a las que se accede y las Conditions (ubicación, plataforma del dispositivo y riesgo del inicio de sesión). Access Controls define si se debe Grant (con la posibilidad de requerir MFA, un dispositivo compatible o una aplicación aprobada) o Block el acceso por completo.

Las named locations de Conditional Access permiten definir rangos de IP de confianza (como la red de la oficina corporativa) o países. Un patrón habitual de directiva consiste en requerir MFA cuando un usuario inicia sesión fuera de una ubicación con nombre de confianza, pero permitir el acceso sin pasos adicionales desde una IP de oficina conocida. Esto reduce las molestias para los empleados que trabajan en las instalaciones y refuerza la seguridad de los usuarios remotos o que viajan.

Conditional Access puede requerir que el dispositivo desde el que se accede sea compliant (que cumpla las directivas de cumplimiento de dispositivos de Intune) o que sea un dispositivo corporativo hybrid Azure AD joined. Así se garantiza que, aunque las credenciales sean válidas, los inicios de sesión desde dispositivos personales o no administrados se bloqueen o deban superar controles adicionales. Los controles basados en dispositivos son un pilar fundamental del modelo de seguridad Zero Trust.

Entra ID Identity Protection (P2) utiliza aprendizaje automático para evaluar cada inicio de sesión y asignarle una risk score: baja, media o alta. Entre los factores de riesgo se incluyen los desplazamientos imposibles (iniciar sesión desde dos países en cuestión de minutos), las IP anónimas, las credenciales filtradas y la detección de ataques de password spray. Las directivas de Conditional Access pueden activarse según el nivel de riesgo; por ejemplo, exigir MFA para un riesgo medio y bloquear automáticamente el acceso ante un riesgo alto.

Antes de aplicar una directiva de Conditional Access, puede establecerla en modo Report-Only. En este modo, la directiva evalúa todos los inicios de sesión y registra lo que habría ocurrido (acceso concedido, bloqueado o MFA requerida), pero no aplica realmente los controles. Esto le permite validar el impacto de la directiva en sus usuarios antes de habilitarla y evitar bloqueos inesperados causados por condiciones con un alcance incorrecto.

La herramienta What If de la hoja de Conditional Access permite simular un escenario de inicio de sesión —especificando un usuario, una aplicación, una dirección IP, una plataforma de dispositivo y un nivel de riesgo— y comprobar qué directivas se aplicarían y cuál sería el resultado combinado. Es especialmente útil para solucionar problemas de acceso y validar que el conjunto de directivas produce el resultado esperado para determinados usuarios y condiciones.

Toda organización debería mantener al menos dos break-glass emergency access accounts excluidas de todas las directivas de Conditional Access, incluidos los requisitos de MFA. Estas cuentas solo se utilizan si la infraestructura de MFA falla o si todos los administradores quedan bloqueados. Las credenciales de emergencia deben guardarse en una caja fuerte física, utilizar contraseñas aleatorias y largas, no tener MFA registrada y someterse a una auditoría exhaustiva ante cualquier uso.

Compruebe sus conocimientos sobre los conceptos de Microsoft Azure Fundamentals (AZ-900) tratados en esta lección.

En esta lección ha aprendido que: la MFA requiere un segundo factor además de una contraseña, lo que reduce drásticamente el riesgo de robo de credenciales; las directivas de Conditional Access aplican controles de concesión o bloqueo según las condiciones del usuario, la aplicación, la ubicación y el riesgo; y Identity Protection utiliza una puntuación de riesgo basada en ML para activar controles de acceso automáticos. A continuación, veremos Single Sign-On e External Identities en Entra ID.