Laboratorio de acceso condicional: entrenador de MFA y políticas de acceso
Diseña y ajusta un conjunto de políticas de acceso condicional, repite inicios de sesión simulados y puntúa los ataques frenados frente a los usuarios bloqueados.
Abrir la herramienta →La herramienta interactiva se abre en inglés.
La mayoría de las brechas de identidad entran por un hueco en las políticas de acceso: un protocolo heredado que se salta el MFA, un administrador que sigue con SMS, una exclusión que nadie recuerda haber añadido. Aquí eres el ingeniero de identidad de Aldermoor Freight, una empresa de transporte ficticia, y heredas un conjunto de políticas a medio terminar. A lo largo de 5 rondas fijas la fortaleza del MFA y los controles de dispositivo, ubicación, riesgo y sesión para empleados, administradores, contratistas, cuentas de emergencia (break-glass) y cuentas de servicio, en la suite de correo, un ERP financiero, el portal de administración y una aplicación heredada con autenticación básica. Después, una repetición what-if lanza hasta 26 inicios de sesión simulados (un viajero, un administrador en un dispositivo no gestionado, fatiga de MFA, reutilización de tokens desde un país nuevo, un cliente IMAP heredado, una entidad de servicio, el uso de break-glass, un contratista con BYOD) y muestra qué política se aplicó y si cada uno se bloqueó, se le pidió MFA o se permitió. Se te puntúa por los ataques frenados frente a los usuarios bloqueados, con penalizaciones por cuatro errores clásicos, y terminas con un conjunto de políticas y un plan de despliegue que puedes adaptar. Es un laboratorio Pro.
- Toma la decisión de diseño de la ronda y edita las políticas: asignaciones, condiciones, controles de concesión y de sesión.
- Lanza la repetición what-if y mira qué inicios de sesión se bloquean, cuáles reciben un desafío de MFA y cuáles pasan.
- Corrige lo que se rompa: los inicios de sesión de rondas anteriores siguen en la repetición, así que un cambio que rompe la ronda 1 aparece después.
- Revisa el informe final y exporta tu conjunto de políticas y el plan de despliegue en Markdown. Un enlace con ?seed= repite el mismo tenant.
Preguntas frecuentes
¿Qué es el laboratorio de acceso condicional?
Un laboratorio de formación en el navegador en el que gestionas el conjunto de políticas de acceso de una empresa ficticia. A lo largo de 5 rondas (MFA de base y autenticación heredada, administradores, riesgo y ubicación, contratistas y BYOD, cuentas de servicio y break-glass) tomas una decisión de diseño, editas políticas y repites contra ellas inicios de sesión simulados para ver a quién se bloquea, a quién se le pide MFA y a quién se permite el acceso. Los inicios de sesión anteriores siguen en la repetición, así que un cambio que rompe la ronda 1 aparece más tarde.
¿Qué son las políticas de acceso condicional?
Son reglas «si… entonces» que tu proveedor de identidad comprueba en cada inicio de sesión: si este usuario, en esta aplicación, bajo estas condiciones (dispositivo, ubicación, riesgo, aplicación cliente), entonces se bloquea, o se concede el acceso solo con estos controles (MFA, un dispositivo conforme, Términos de uso) y con estos límites de sesión. Microsoft Entra las llama políticas de acceso condicional; otros proveedores de identidad las llaman políticas de acceso, de inicio de sesión o de autenticación. El laboratorio es neutral respecto al proveedor y usa el modelo común.
¿Cómo se combinan varias políticas?
Se aplican a la vez todas las políticas habilitadas cuyas asignaciones y condiciones coinciden con el inicio de sesión. Si cualquiera de ellas dice Block, el inicio de sesión se bloquea, digan lo que digan las demás. Si no, hay que cumplir todos los controles de concesión de todas las políticas que coinciden, así que «exigir MFA» en una política y «exigir dispositivo conforme» en otra significa ambas cosas. Gana el control de sesión más estricto. Las políticas en modo report-only se evalúan y registran, pero nunca se aplican. Si no coincide ninguna política, el inicio de sesión se permite solo con contraseña.
¿Por qué excluir las cuentas break-glass y cómo protegerlas igualmente?
Las cuentas break-glass (de acceso de emergencia) existen para el día en que fallan tus controles normales: una caída del MFA, una política errónea, un problema de federación. Como un Block siempre gana, cualquier política amplia de bloqueo, riesgo, ubicación o dispositivo que las incluya puede dejarte fuera de tu propio tenant. Exclúyelas de esas políticas, pero no las dejes sin protección: dales una política dedicada que exija MFA resistente al phishing con llaves guardadas fuera de línea y alerta de cada inicio de sesión.
¿Por qué bloquear la autenticación heredada por separado?
Los protocolos heredados (IMAP, POP, SMTP AUTH y otros clientes de autenticación básica) no pueden hacer MFA moderno ni informar del estado del dispositivo. Una política de exigir MFA limitada a navegadores y aplicaciones modernas nunca los ve, así que una contraseña obtenida por password spraying funciona por IMAP aunque el MFA esté «activado». Bloquea los clientes heredados de forma explícita, para todos los tipos de usuario y todas las aplicaciones, y antes mueve dispositivos como las impresoras con escaneo a correo a un relé autenticado.
¿Qué es el MFA resistente al phishing y por qué lo necesitan los administradores?
Los métodos resistentes al phishing, como las llaves de seguridad FIDO2, las passkeys y la autenticación basada en certificados, están ligados al sitio real, así que la fatiga de MFA (bombardear con notificaciones push hasta que alguien aprueba), los proxies de phishing en tiempo real y los SIM swaps no funcionan contra ellos. Una política que solo dice «exigir MFA» permite que un administrador la cumpla con SMS, el método más débil. Usa un requisito de fortaleza de autenticación para los administradores y las cuentas break-glass.
¿El MFA detiene la reutilización de tokens?
Por sí solo, no. Un token o una cookie de sesión robados ya llevan la marca de MFA del inicio de sesión original, así que una política de exigir MFA queda satisfecha. Lo que detiene la reutilización es bloquear el riesgo alto de inicio de sesión, forzar un nuevo inicio de sesión con la frecuencia de inicio de sesión (fijada en «cada vez» para los inicios de sesión de riesgo), no permitir sesiones persistentes del navegador en dispositivos no gestionados o exigir un dispositivo conforme que la máquina del atacante no pueda cumplir.
¿Cuál es la diferencia entre el riesgo de inicio de sesión y el riesgo de usuario?
El riesgo de inicio de sesión puntúa un inicio de sesión concreto: una ubicación desconocida, una IP anónima, un token anómalo. El riesgo de usuario puntúa la cuenta: credenciales filtradas o un compromiso confirmado. Un patrón habitual es exigir un MFA nuevo ante un riesgo de inicio de sesión medio, bloquear el riesgo alto de inicio de sesión y, ante un riesgo de usuario alto, exigir MFA más un cambio seguro de contraseña, para que el usuario real pueda resolverlo sin llamar al service desk.
¿Cómo deben tratarse las cuentas de servicio y las identidades de carga de trabajo?
Las entidades de servicio y las identidades de carga de trabajo no pueden hacer MFA, aceptar Términos de uso ni demostrar que el dispositivo es conforme, así que una política de MFA de usuario que las incluya rompe la automatización. Mantenlas fuera de las políticas de usuario y protégelas con un bloqueo para cualquier inicio de sesión fuera de las ubicaciones de salida de confianza, credenciales de vida corta como certificados o identidades administradas, y detecciones de riesgo.
¿Qué errores clásicos señala el laboratorio?
Cuatro, cada uno con su penalización: bloquear una cuenta break-glass; dejar en report-only una política que habría detenido un ataque; excluir por accidente un grupo entero (como All Staff), lo que saca a cientos de personas de un control; y permitir que los administradores cumplan el MFA con SMS. Cada uno viene con su corrección en la retroalimentación de la ronda y en el informe final.
¿Cómo funcionan la dificultad, las semillas y la puntuación?
Rookie juega los inicios de sesión básicos con las notas de los compañeros visibles desde el principio. Pro añade más inicios de sesión y comprobaciones y hereda un tenant con una exclusión de grupo accidental; las notas aparecen tras tu primer what-if. Elite añade los inicios de sesión más difíciles (SIM swap, una reutilización silenciosa de token de riesgo medio, adivinación de contraseñas sobre break-glass) y un tenant heredado más desordenado, sin notas hasta que publicas. Cada ronda puntúa un 45 % por ataques frenados, un 35 % por usuarios reales que entran y un 20 % por comprobaciones de calidad, menos las penalizaciones por errores; la nota final es un 80 % las rondas y un 20 % las decisiones de diseño. El valor ?seed= fija las personas, los inicios de sesión y las decisiones de diseño, para que un compañero pueda repetir tu tenant exacto.
¿Algo de esto es real?
No. Aldermoor Freight, su gente y el dominio aldermoor.example son inventados, todas las direcciones IP son de los rangos de documentación del RFC 5737 y los inicios de sesión se generan en tu navegador. El laboratorio modela cómo se combinan las decisiones de acceso condicional; no se conecta a ningún proveedor de identidad.
¿Es gratis?
No, es un laboratorio Pro. Con una cuenta gratuita tienes 3 usos de prueba; después necesitas Pro.