Acceso condicional (Conditional access)
En identidad cloud, el acceso condicional es la política que evalúa las circunstancias de un inicio de sesión y decide qué exigir o qué denegar. En lugar de un único sí o no en la contraseña, pregunta qué usuario, desde qué dispositivo, en qué ubicación, para llegar a qué aplicación y con qué riesgo estimado, y aplica el control que corresponde a la respuesta.
Cómo funciona
Una política empareja condiciones con controles. Las condiciones cubren el usuario o grupo, la aplicación de destino, el estado del dispositivo y si está gestionado, la ubicación de red, el tipo de cliente y las señales de riesgo derivadas del inicio de sesión y del propio usuario. Los controles incluyen exigir un segundo factor, exigir un dispositivo conforme o gestionado, exigir una credencial de determinada solidez, limitar la sesión o bloquear sin más.
Dos controles hacen un trabajo desproporcionado. Exigir un dispositivo gestionado convierte una contraseña robada en nada, porque la máquina del atacante no puede cumplirlo. Exigir una credencial resistente al phishing, como una passkey, elimina el ataque por proxy. Todo lo demás es afinar.
Qué sale mal
El hueco es el hallazgo, siempre. Una política que exige segundo factor a todo el mundo salvo a un grupo de exclusión, y un grupo de exclusión que ha crecido hasta incluir cuentas de servicio, directivos y a cualquiera que se quejase, significa que la política protege justo a quien nadie iba a atacar. Los grupos de exclusión son lo primero que enumeramos.
Los protocolos heredados son lo segundo. Los protocolos de correo y de cliente antiguos no saben presentar una credencial moderna y por tanto no se les puede plantear un desafío, así que allí donde siguen siendo alcanzables la política entera se esquiva eligiendo otro endpoint, que es exactamente lo que hace el password spraying contra un tenant.
Lo tercero es lo que la política no cubre: la sesión que ya emitió. El acceso condicional se evalúa en la autenticación, así que un token capturado después por un proxy adversary-in-the-middle se usa desde la máquina y la red del atacante sin una evaluación nueva, salvo que estén activadas la evaluación continua y la protección de token. Esa es la diferencia entre una política que parece sólida sobre el papel y una que detiene el ataque que de verdad ejecutamos.
Dónde aparece esto en una auditoría
Enumeramos todas las políticas, todas las exclusiones y todos los caminos heredados habilitados, y después probamos la combinación más débil que todavía autentica, no la prevista. El informe da el nombre de la política, la condición concreta que nos dejó pasar y la sesión que obtuvimos, y separa una política ausente de una política con un agujero, porque esas dos cosas tienen dueños distintos. Las reglas basadas en ubicación se prueban desde fuera de la geografía esperada, porque con frecuencia son el único control sobre una aplicación de alto valor. Esto forma parte de cómo probamos la política de inicio de sesión de Microsoft 365 contra un ataque real.