Acceso condicional, políticas y exclusiones

Una política tiene asignaciones (a quién, a qué, bajo qué condiciones) y controles (bloquear, o conceder exigiendo algo, como autenticación multifactor o un dispositivo conforme). Se evalúa después de la primera autenticación, no antes: no es una defensa de primera línea. Si varias políticas aplican a un inicio de sesión, deben cumplirse todas; un control de bloqueo detiene el proceso.

Un detalle de administración: las políticas que apuntan a roles o a grupos se evalúan cuando se emite un token. Así, quien se añade hoy a un grupo no queda sujeto a la política hasta que obtenga un token nuevo, y quien ya tenía un token válido no queda sujeto de forma retroactiva. La recomendación de Microsoft es provocar la evaluación al activar el rol o la membresía, con una herramienta de acceso privilegiado.

Las políticas con ámbito de usuarios no alcanzan a las cuentas de servicio que hacen llamadas como principales de servicio: esas llamadas no se bloquean con una política dirigida a usuarios. Para ellas existe el acceso condicional para identidades de carga de trabajo, y la recomendación para los scripts es sustituir las cuentas de servicio por identidades administradas.

Por eso, cuando alguien dice «excluyamos a las cuentas de servicio de la política», la pregunta es cuál es la cuenta, qué hace y si puede dejar de ser una cuenta de usuario.

Dos políticas pueden cubrir la misma obligación, y entonces una exclusión en una puede ser inocua, pero solo si la otra cubre a la persona. Para saberlo hay que cruzar tres cosas: a quién incluye cada política (por rol o por grupo), a quién excluye y qué cuentas tiene realmente un rol de administrador.

Abre politicas.txt, grupos-de-exclusion.txt y administradores.txt. Las cuentas de emergencia están excluidas a propósito de las políticas de MFA y no cuentan aquí. Entre las demás cuentas con rol de administrador, hay una a la que ninguna política de MFA le exige nada.

Una exclusión es una decisión de riesgo, y las decisiones de riesgo se revisan. Un grupo de exclusión sano tiene un motivo, un responsable y una fecha en la que alguien pregunta si sigue haciendo falta. Los grupos que nacen «mientras tanto» sin fecha acaban siendo permanentes.

Revisa en grupos-de-exclusion.txt el campo revisión de cada grupo. Cuenta los grupos de exclusión que no tienen ninguna revisión prevista.

Si una política de bloqueo está activa, incluye a todos los usuarios y no excluye a las cuentas de emergencia, un error de configuración puede dejar a la organización sin acceso administrativo, justo cuando las cuentas de emergencia debían salvarla. Las que están en solo informe no bloquean, y por eso no necesitan esa exclusión.

Entre las seis políticas de politicas.txt, una de bloqueo activa tiene todos los usuarios incluidos y no excluye a nadie.