Controles, sesión, acceso condicional, frecuencia de inicio de sesión, ubicaciones con nombre: qué revoca realmente un token activo

Controles, sesión de acceso condicional, frecuencia de inicio de sesión, ubicaciones con nombre: qué controla realmente cada uno

Si buscaste controles sesión acceso condicional frecuencia de inicio de sesión ubicaciones con nombre, casi con toda seguridad persigues una sola pregunta: ¿endurecer un control de sesión expulsa realmente a alguien que ya tiene la sesión iniciada? La respuesta corta es no. Un control de sesión describe lo que ocurre la próxima vez que Microsoft Entra ID evalúa la sesión — no accede a un token de acceso ya emitido para revocarlo retroactivamente.

La referencia de controles de sesión de Microsoft enumera ocho: restricciones aplicadas por la aplicación, control de aplicaciones de acceso condicional, frecuencia de inicio de sesión, sesión de navegador persistente, personalización de la evaluación continua de acceso, deshabilitar los valores predeterminados de resiliencia, exigir protección de token para las sesiones de inicio de sesión, y usar el perfil de seguridad de Global Secure Access. Dos de ellos — la frecuencia de inicio de sesión y la sesión de navegador persistente — se comportan con el tiempo de formas documentadas en una página aparte, las directivas de duración de sesión adaptativas, donde Microsoft también indica que «el acceso condicional es una funcionalidad de Microsoft Entra ID P1 o P2 que requiere una licencia premium».

Si auditas estos ajustes a través de Microsoft Graph en lugar del portal, la visión es aún más estrecha. El recurso v1.0 conditionalAccessSessionControls expone exactamente cinco propiedades — applicationEnforcedRestrictions, cloudAppSecurity, disableResilienceDefaults, persistentBrowser, signInFrequency — por lo que un script que enumere los controles de sesión v1.0 no verá en absoluto la protección de token ni el interruptor de CAE.

El valor predeterminado es más permisivo de lo que la mayoría de los administradores supone. Microsoft lo indica claramente: «La configuración predeterminada de Microsoft Entra ID para la frecuencia de inicio de sesión del usuario es una ventana móvil de 90 días». La justificación es explícita — «no pedir a los usuarios que proporcionen sus credenciales si la postura de seguridad de sus sesiones no ha cambiado».

Cómo funciona: cuándo se evalúa realmente una directiva

Esta es la frase que gobierna todo lo demás. De la documentación de señales de red de Microsoft:

Las directivas de acceso condicional se evalúan cuando: un usuario inicia sesión por primera vez en una aplicación web, móvil o de escritorio. Una aplicación móvil o de escritorio que usa autenticación moderna utiliza un token de actualización para adquirir un nuevo token de acceso. De forma predeterminada, esta comprobación se produce una vez por hora.

Y, para los navegadores: «en las aplicaciones web, las directivas se aplican en el inicio de sesión inicial y son válidas durante toda la vida de la sesión en la aplicación web». Microsoft añade la consecuencia práctica: «De forma predeterminada, Microsoft Entra ID emite tokens cada hora. Después de que los usuarios abandonan la red corporativa, en el plazo de una hora la directiva se aplica para las aplicaciones que usan autenticación moderna».

Por lo tanto, una directiva de ubicación es una comprobación en el momento de la renovación, no un disparador en tiempo real — a menos que entre en juego la evaluación continua de acceso.

Frecuencia de inicio de sesión, incluida la opción «Cada vez»

La frecuencia de inicio de sesión «especifica durante cuánto tiempo un usuario puede acceder a un recurso antes de que se le pida volver a iniciar sesión». Elegir Cada vez no significa de forma continua. Microsoft: «Cuando seleccionas Cada vez, la directiva exige una reautenticación completa cuando se evalúa la sesión. Este requisito significa que si el usuario cierra y abre su navegador durante la vida de la sesión, es posible que no se le solicite la reautenticación». El control también «tiene en cuenta cinco minutos de desfase de reloj cuando se selecciona cada vez, de modo que no solicite a los usuarios más de una vez cada cinco minutos».

La aplicación también se difiere para todo lo que no sea interactivo: «Si la aplicación cliente (en los detalles de actividad) es un navegador, el sistema difiere la aplicación de la frecuencia de inicio de sesión de eventos y directivas en los servicios en segundo plano hasta la siguiente interacción del usuario. En los clientes confidenciales, el sistema difiere la aplicación de la frecuencia de inicio de sesión en los inicios de sesión no interactivos hasta el siguiente inicio de sesión interactivo».

En los dispositivos unidos existe un segundo reloj: «desbloquear el dispositivo o iniciar sesión de forma interactiva actualiza el token de actualización principal (PRT) cada cuatro horas». El propio ejemplo práctico de Microsoft muestra una directiva SIF de una hora que solicita al usuario a las 05:45 — cinco horas y 45 minutos después del inicio de sesión inicial a las 00:00 — porque el PRT se actualizó a las 04:45.

La evaluación continua de acceso es lo que realmente revoca

La evaluación continua de acceso (CAE) es lo que convierte una directiva en una revocación casi en tiempo real, y lo hace para una lista cerrada de eventos críticos: se elimina o deshabilita una cuenta de usuario; se cambia o restablece una contraseña; se habilita el MFA para el usuario; un administrador revoca explícitamente todos los tokens de actualización; se detecta un riesgo de usuario alto mediante ID Protection. La latencia indicada por Microsoft: «el objetivo para la evaluación de eventos críticos es que la respuesta sea casi en tiempo real, pero puede observarse una latencia de hasta 15 minutos debido al tiempo de propagación del evento; sin embargo, la aplicación de la directiva de ubicaciones IP es instantánea».

La contrapartida son tokens más largos: «la vida del token aumenta a una duración larga, de hasta 28 horas, en las sesiones CAE». Sin clientes compatibles con CAE, «la vida predeterminada del token de acceso sigue siendo de 1 hora». Y, algo crítico para este artículo: «la frecuencia de inicio de sesión se respeta con o sin CAE».

La brecha: dónde un token activo sobrevive a tu directiva

1. Las ubicaciones con nombre basadas en país son invisibles para CAE

Esta es la línea de mayor valor en toda la documentación de CAE:

CAE solo tiene visibilidad de las ubicaciones con nombre basadas en IP. CAE no tiene visibilidad de otras condiciones de ubicación como las IP de confianza de MFA o las ubicaciones basadas en país/región. Cuando un usuario procede de una IP de confianza de MFA, una ubicación de confianza que incluye IP de confianza de MFA, o una ubicación de país/región, CAE no se aplicará después de que ese usuario se mueva a una ubicación diferente. En esos casos, Microsoft Entra emite un token de acceso de una hora sin comprobación instantánea de aplicación de IP.

Por lo tanto, una directiva de «bloquear el acceso desde fuera de estos países» hace que el tenant vuelva al modelo horario anterior a CAE. La recomendación de Microsoft es inequívoca: «No uses las condiciones de ubicación de país/región ni la función de IP de confianza disponible en la página de configuración del servicio de autenticación multifactor de Microsoft Entra».

2. Demasiados rangos de IP desactivan silenciosamente la aplicación de ubicación en tiempo real

«Cuando la suma de todos los rangos de IP especificados en las directivas de ubicación supera los 5000, CAE no puede aplicar en tiempo real el flujo de cambio de ubicación del usuario. En este caso, Microsoft Entra emite un token CAE de una hora». El umbral es a nivel de tenant — la suma de todas las directivas de ubicación, no un límite por directiva — por lo que se supera por acumulación y no por una sola edición. Solo se degrada la aplicación de ubicación: «CAE continúa aplicando todos los demás eventos y directivas excepto los eventos de cambio de ubicación del cliente». Los límites estructurales también son finitos: no más de 195 ubicaciones con nombre, no más de 2000 rangos de IP por ubicación con nombre, y solo máscaras CIDR mayores que /8.

3. Las rutas de salida divididas activan la excepción de variación de IP

Cuando la IP que ve Entra y la IP que ve el proveedor de recursos difieren — proxies, VPN de túnel dividido, SD-WAN, SNAT, IPv6 — «Microsoft Entra interpreta que el cliente sigue estando en una ubicación permitida y que se le debe conceder acceso. Por lo tanto, Microsoft Entra emite un token de una hora que suspende las comprobaciones de dirección IP en el recurso hasta que expira el token». Ese es el modo estándar, activado de forma predeterminada. La alternativa más estricta de Microsoft, que su página de CAE aún etiqueta como versión preliminar pública, es la aplicación estricta de ubicación: «detener inmediatamente el acceso si la dirección IP detectada por el proveedor de recursos no está permitida por la directiva de acceso condicional».

4. Las cookies de navegador persistente sobreviven a la directiva

La advertencia de Microsoft sobre la persistencia es directa: «En los navegadores persistentes, las cookies permanecen almacenadas en el dispositivo del usuario incluso después de cerrar el navegador. Estas cookies pueden acceder a artefactos de Microsoft Entra, que siguen siendo utilizables hasta que expira el token, independientemente de las directivas de acceso condicional aplicadas al entorno del recurso». Un proxy adversary-in-the-middle que recolecta esa cookie hereda exactamente esta propiedad — consulta repetición de tokens AiTM y detección de viajes imposibles en Entra ID y phishing con device code para saber cómo se produce el robo en primer lugar.

5. La condición de plataforma del dispositivo es una entrada no verificada

«El acceso condicional identifica la plataforma del dispositivo mediante información proporcionada por el dispositivo, como las cadenas de user agent. Debido a que las cadenas de user agent se pueden modificar, esta información no está verificada». Una condición de plataforma es un mecanismo de ámbito, no un control de autenticación. La recomendación de Microsoft es usarla «junto con las directivas de cumplimiento de dispositivos de Microsoft Intune o como parte de una instrucción de bloqueo».

6. Las ediciones de directivas no se aplican retroactivamente

«Los cambios realizados por los administradores en las directivas de acceso condicional y en la pertenencia a grupos pueden tardar hasta un día en surtir efecto… Se realiza cierta optimización en las actualizaciones de directivas, lo que reduce el retraso a dos horas». Endurecer una directiva después de un incidente no expulsa las sesiones que ya existen. Merece la pena nombrar dos puntos ciegos más: «CAE no admite cuentas de usuario invitado», y «Teams se compone de varios servicios; los servicios de llamadas y chat no se ajustan a las directivas de acceso condicional basadas en IP».

Detección

Empieza por la configuración y luego pasa a la telemetría.

Import-Module Microsoft.Graph.Identity.SignIns
Connect-MgGraph -Scopes 'Policy.Read.All'

# Policies with no session controls at all, and those relying on country locations
Get-MgIdentityConditionalAccessPolicy |
    Select-Object DisplayName, State,
        @{n='SessionControls';e={ $_.SessionControls | ConvertTo-Json -Depth 4 -Compress }},
        @{n='Locations';e={ $_.Conditions.Locations | ConvertTo-Json -Depth 3 -Compress }}

# Named locations: which are IP-based (CAE-visible) and which are trusted
Get-MgIdentityConditionalAccessNamedLocation |
    Select-Object Id, DisplayName, AdditionalProperties

Ambos cmdlets solo necesitan Policy.Read.All; Microsoft cita Global Reader, Security Reader, Security Administrator y Conditional Access Administrator entre los roles de menor privilegio para estas lecturas. Las llamadas REST equivalentes son GET /identity/conditionalAccess/policies y GET /identity/conditionalAccess/namedLocations.

En la respuesta de Graph, una ubicación basada en IP es #microsoft.graph.ipNamedLocation con isTrusted e ipRanges[].cidrAddress; una ubicación de país es #microsoft.graph.countryNamedLocation con countriesAndRegions e includeUnknownCountriesAndRegions. Solo el primer tipo es aplicado en vivo por CAE. Un control de navegador persistente aparece como persistentBrowser con un mode de always o never, y la frecuencia de inicio de sesión como signInFrequency con un frequencyInterval de timeBased o everyTime.

La tabla SigninLogs de Azure Monitor contiene toda esta información. Una consulta de partida para el problema de la ruta dividida:

SigninLogs
| where TimeGenerated > ago(7d)
| where isnotempty(IPAddressFromResourceProvider)
| where IPAddressFromResourceProvider != IPAddress
| summarize Sessions = count(),
            Users = dcount(UserPrincipalName)
        by AppDisplayName, IPAddress, IPAddressFromResourceProvider, ConditionalAccessStatus
| order by Sessions desc

La referencia de la tabla SigninLogs de Microsoft describe IPAddressFromResourceProvider como «la dirección IP que un usuario usó para llegar a un proveedor de recursos, utilizada para determinar el cumplimiento del acceso condicional en algunas directivas… Este valor suele ser nulo» — nulo es el caso saludable, lo que significa que ambas vistas coinciden. Su equivalente en el portal es la columna Dirección IP (vista por el recurso) en los registros de inicio de sesión, y Microsoft ofrece una plantilla de libro pública, Continuous Access Evaluation Insights, para mostrar las mismas discrepancias.

Remediación

1. Convierte las ubicaciones críticas para la aplicación en ubicaciones con nombre basadas en IP. Microsoft: «Si quieres que tus directivas de ubicación se apliquen en tiempo real mediante la evaluación continua de acceso, usa únicamente la condición de ubicación de acceso condicional basada en IP y configura todas las direcciones IP, incluidas tanto IPv4 como IPv6, que puedan ver tu proveedor de identidad y tu proveedor de recursos». Reserva las ubicaciones por país solo para el bloqueo grueso, y recuerda que una ubicación marcada como de confianza «no se puede eliminar sin antes quitar la designación de confianza».

2. Enumera cada IP de salida — ambas vistas. Incluye las direcciones que ve Entra durante la autenticación y las direcciones que ven Exchange Online, SharePoint Online, Teams y Microsoft Graph. No infles la lista: «No añadas IP de salida no dedicadas o no enumerables a las reglas de acceso condicional de ubicaciones con nombre de confianza, ya que puede debilitar la seguridad». Mantén el total a nivel de tenant por debajo de 5000 rangos.

3. Corrige correctamente el punto ciego del proxy. Con un proxy en la nube o una VPN, «la dirección IP que usa Microsoft Entra ID al evaluar una directiva es la dirección IP del proxy. La cabecera X-Forwarded-For (XFF)… no se usa porque no hay validación de que provenga de una fuente de confianza». Microsoft recomienda la restauración de la IP de origen de Global Secure Access, o un control basado en dispositivo en lugar de una lista de IP.

4. Solo entonces considera la aplicación estricta de ubicación. Valida primero con el libro de CAE y el filtro Dirección IP (vista por el recurso). La advertencia de Microsoft: «Si el tráfico hacia Microsoft Entra ID o un recurso compatible con CAE pasa por una IP de salida compartida o indefinible, no habilites la aplicación estricta de ubicación en tus directivas de acceso condicional». Despliega grupo por grupo.

5. Configura el navegador persistente en never — y aplícale el ámbito correcto. Graph documenta la restricción directamente en la propiedad: «Se deben seleccionar todas las aplicaciones para que este control de sesión funcione correctamente». Una directiva de navegador persistente con ámbito limitado a un subconjunto de aplicaciones no hace lo que su nombre implica.

6. No te apoyes únicamente en la condición de plataforma. Combina Device platforms con el cumplimiento de Intune o la condición Filter for devices. Ten en cuenta que la condición antigua Device state está en desuso, y que «el estado del dispositivo y los filtros para dispositivos no se pueden usar juntos en una directiva de acceso condicional».

7. Resuelve dos conflictos conocidos antes de habilitar la frecuencia de inicio de sesión. Deshabilita primero «Recordar MFA en dispositivos de confianza» — «usar estos dos ajustes juntos puede solicitar a los usuarios de forma inesperada» — y no mezcles los controles de sesión con la antigua función de duración de token configurable, que «Microsoft retiró… para las duraciones de los tokens de actualización y de sesión el 30 de enero de 2021».

8. Revoca explícitamente durante un incidente. Como las ediciones de directivas tardan hasta un día (dos horas con optimización) en llegar a los proveedores de recursos, usa la acción directa:

Import-Module Microsoft.Graph.Users.Actions

# A UPN can also be used as -UserId.
Revoke-MgUserSignInSession -UserId $userId

Revoke-MgUserSignInSession «invalida todos los tokens de actualización emitidos a las aplicaciones para un usuario (y las cookies de sesión en el navegador del usuario), restableciendo la propiedad de usuario signInSessionsValidFromDateTime a la fecha y hora actuales». Necesita como mínimo User.RevokeSessions.All. El equivalente en el portal es Revoke Session en la página de perfil del usuario. Confirma que tus cuentas break-glass están excluidas de cualquier directiva de ubicación antes de endurecerla.

9. Añade protección de token donde el cliente lo admita. La protección de token «intenta reducir los ataques que usan el robo de tokens garantizando que un token solo se pueda usar desde el dispositivo previsto», y la columna TokenProtectionStatusDetails de SigninLogs indica si un token de inicio de sesión estaba vinculado a su dispositivo.

Cómo lo detecta EtcSec

Una auditoría de Azure de EtcSec lee tus directivas de acceso condicional y ubicaciones con nombre a través de Microsoft Graph y señala las brechas de configuración detrás de cada escenario anterior: CA_NO_SESSION_CONTROLS cuando ninguna directiva habilitada establece una frecuencia de inicio de sesión ni un modo de navegador persistente, CA_PERSISTENT_BROWSER_ENABLED cuando se permite que las cookies del navegador persistan, CA_NO_NAMED_LOCATIONS y CA_NO_TRUSTED_LOCATIONS cuando el tenant no tiene vocabulario de ubicación para que CAE lo aplique, CA_NO_LOCATION_BLOCK cuando ninguna directiva bloquea por ubicación, y CA_NO_PLATFORM_FILTER cuando ninguna directiva delimita por plataforma de dispositivo. Estos se combinan naturalmente con la revisión más amplia en brechas de acceso condicional de Entra ID, brechas de cobertura de directivas base, y la guía integral de auditoría de seguridad de Entra ID.