¿Cómo detienen realmente los ataques Conditional Access y PIM?

Las políticas de contraseña detienen ataques de adivinación. No hacen nada contra un token de sesión robado, una solicitud de MFA phished, o una cuenta de administrador permanente que ha estado ahí con derechos de Administrador Global durante dos años. Conditional Access y Privileged Identity Management (PIM) son los dos controles de Azure AD / Entra ID que realmente abordan esas brechas, y funcionan mejor juntos.

Qué está haciendo Conditional Access bajo el capó

Conditional Access es un motor si-esto-entonces-aquello evaluado en el momento del inicio de sesión. El lado "si" (señales) incluye pertenencia a usuario/grupo, estado de cumplimiento del dispositivo, ubicación de red, riesgo de inicio de sesión (de Identity Protection), aplicación a la que se accede, y tipo de aplicación cliente (navegador vs. protocolo heredado). El lado "entonces" (controles) incluye: requerir MFA, requerir un dispositivo compatible, requerir una aplicación cliente aprobada, bloquear el acceso completamente, o requerir aceptación de términos de uso.

Una política que importa en casi todos los inquilinos: bloquear autenticación heredada. Los protocolos como POP, IMAP, y SMTP más antiguo no admiten desafíos MFA modernos, por lo que son lo primero que intentan las herramientas de relleno de credenciales. Verifica los registros de inicio de sesión filtrados por "Client App = Other clients" antes de bloquear — a menudo encontrarás un escáner heredado o una impresora multifunción antigua aún autenticándose con autenticación básica.

Una segunda que vale la pena tener desde el primer día: requerir MFA para todos los usuarios, limitado con un grupo de exclusión solo para cuentas de emergencia. No limites MFA a "solo administradores." Las cuentas de usuarios estándar comprometidas es cómo los atacantes consiguen su primer punto de apoyo antes de que comience la escalada de privilegios.

Riesgo de inicio de sesión vs. riesgo de usuario — señales diferentes, respuestas diferentes

Identity Protection (parte de Entra ID P2) genera dos puntuaciones de riesgo separadas y es fácil confundirlas:

• Riesgo de inicio de sesión — este intento de autenticación específico se ve anómalo (viaje imposible, IP anónima, propiedades de inicio de sesión desconocidas).
• Riesgo de usuario — esta cuenta ha sido marcada por una razón vinculada a la identidad misma (credenciales filtradas encontradas en un corpus de brechas, actividad de compromiso confirmada).

Una política de Conditional Access que responde al riesgo de inicio de sesión típicamente debería desafiar con MFA — si el usuario real puede completar el desafío, déjalo pasar. Una política que responde al riesgo de usuario debería forzar un restablecimiento de contraseña, porque MFA solo no ayuda si la credencial misma ya está quemada.

Por qué el acceso de administrador permanente es el problema mayor

Incluso con Conditional Access impecable, una cuenta que mantiene Administrador Global permanentemente es un objetivo visible en el directorio. Cualquiera que la comprometa hereda control total del inquilino sin pasos adicionales requeridos. PIM elimina la parte "permanente".

Con PIM, los roles de administrador se asignan como elegibles en lugar de activos. El usuario tiene que activar explícitamente el rol, lo que desencadena una justificación requerida, flujo de trabajo de aprobación opcional, reconfirmación MFA, y una ventana con límite de tiempo — comúnmente 1 a 8 horas — después de la cual el rol se desactiva automáticamente. Nadie, incluido el propietario de la cuenta, tiene Administrador Global permanente a menos que lo esté usando activamente.

Una configuración mínima de PIM que sea realmente usable

• Cada rol por encima de Administrador de Helpdesk: elegible, no permanente.
• Administrador Global y Administrador de Rol Privilegiado: requerir aprobación de un segundo administrador, no solo autoactivación.
• Activación MFA requerida, sin excepciones.
• Duración máxima de activación de 4 horas obliga a las personas a reactivar para sesiones de trabajo genuinamente separadas, lo que también produce pistas de auditoría más limpias.
• Revisiones de acceso cada 90 días en todas las asignaciones elegibles — las cuentas se añaden para un proyecto y nunca se eliminan de otra forma.

Dónde los equipos se equivocan

El fallo más común no es el diseño de la política, es la lista de exclusiones. Una política de Conditional Access con un grupo "excluye estos usuarios porque la aplicación no admite MFA" que crece constantemente eventualmente excluye la mitad del inquilino. Rastra las exclusiones como un elemento de backlog con un propietario y una fecha de eliminación, no un depósito permanente.

El segundo fallo son las cuentas de emergencia que no se prueban realmente. Dos cuentas de emergencia, excluidas de Conditional Access y PIM, con contraseñas largas y aleatorias almacenadas sin conexión y alertas en cualquier inicio de sesión — y alguien debería intentar iniciar sesión en ellas trimestralmente para confirmar que aún funcionan.

Conditional Access y PIM no son una casilla de verificación para una auditoría de cumplimiento. Son la diferencia entre una credencial phished siendo un inconveniente y siendo un compromiso total del inquilino. Si estás mapeando controles de identidad como parte de una construcción de Blue Team, los segmentos Cloud y Blue Team de Korra Studio cubren el lado de detección — cómo se ven realmente los eventos de riesgo de Identity Protection en Sentinel y cómo alertar en patrones de activación de PIM imposibles.