Implementación de la administración de sesiones y la evaluación continua de acceso
En las implementaciones complejas, las organizaciones pueden tener la necesidad de restringir las sesiones de autenticación. Estos son algunos de los escenarios en que esto podría suceder:
- El acceso a los recursos desde un dispositivo no administrado o compartido.
- El acceso a información confidencial desde una red externa.
- Usuarios ejecutivos o de prioridad alta.
- Aplicaciones empresariales críticas.
Los controles de acceso condicional permiten crear directivas dirigidas a casos de uso específicos dentro de la organización sin afectar a todos los usuarios.
Antes de entrar en detalles sobre cómo configurar la directiva, examinemos la configuración predeterminada.
Frecuencia de inicio de sesión del usuario
La frecuencia de inicio de sesión define el período que transcurre hasta que se pida a un usuario que vuelva a iniciar sesión cuando intenta acceder a un recurso.
La configuración predeterminada de Microsoft Entra ID de la frecuencia de inicio de sesión del usuario es un período sucesivo de 90 días. Pedir credenciales a los usuarios a menudo parece algo sensato, pero puede resultar contraproducente: los usuarios que están capacitados para escribir sus credenciales sin pensarlo pueden suministrarlas sin querer a una petición de credenciales malintencionada.
Puede parecer alarmante no pedir a un usuario que vuelva a iniciar sesión; en realidad, cualquier infracción de las directivas de TI revocará la sesión. Algunos ejemplos incluyen un cambio de contraseña, un dispositivo que no cumple con las normas o la operación de deshabilitación de la cuenta. También puede explícitamente revocar sesiones de usuarios mediante PowerShell. La configuración predeterminada del ID de Microsoft Entra se resume en "no pedir a los usuarios que proporcionen sus credenciales si el estado de seguridad de sus sesiones no ha cambiado".
La configuración de la frecuencia de inicio de sesión funciona con aplicaciones que han implementado los protocolos OAUTH2 u OIDC de acuerdo con los estándares. La mayoría de las aplicaciones para Windows, Mac y dispositivos móviles, incluidas las siguientes aplicaciones web, cumplen la configuración.
- Word, Excel y PowerPoint Online
- OneNote Online
- Office.com
- Portal de Administración de Microsoft 365
- Exchange Online
- SharePoint y OneDrive
- Cliente web de Teams
- Dynamics CRM Online
- Portal de Azure
La configuración de la frecuencia de inicio de sesión también funciona con aplicaciones SAML, siempre y cuando no se eliminen sus propias cookies y se redirijan de nuevo a Microsoft Entra ID regularmente para la autenticación.
Frecuencia de inicio de sesión de usuario y autenticación multifactor
Antes, la frecuencia de inicio de sesión se aplicaba solo a la autenticación del primer factor en los dispositivos unidos a Microsoft Entra, unidos a Microsoft Entra híbrido y registrados en Microsoft Entra. No había ninguna manera fácil de que nuestros clientes reforzaran la autenticación multifactor (MFA) en esos dispositivos. En función de los comentarios de los clientes, la frecuencia de inicio de sesión se aplicará también a la autenticación multifactor.
Frecuencia de inicio de sesión de usuario e identidades de dispositivos
Si tiene dispositivos unidos a Microsoft Entra, unidos a Microsoft Entra híbrido o registrados en Microsoft Entra, cuando un usuario desbloquea su dispositivo o inicia sesión de forma interactiva, este evento también cumplirá la directiva de frecuencia de inicio de sesión. En los dos ejemplos siguientes, la frecuencia de inicio de sesión de usuario está establecida en una hora:
Ejemplo 1:
- A las 00:00, un usuario inicia sesión en su dispositivo unido a Windows 10 Microsoft Entra y empieza a trabajar en un documento almacenado en SharePoint Online.
- El usuario trabaja en el mismo documento en su dispositivo durante una hora.
- A la 01:00, se solicita al usuario que vuelva a iniciar sesión según el requisito de frecuencia de inicio de sesión en la directiva de acceso condicional configurada por su administrador.
Ejemplo 2:
- A las 00:00, un usuario inicia sesión en su dispositivo unido a Windows 10 Microsoft Entra y empieza a trabajar en un documento almacenado en SharePoint Online.
- A las 00:30, el usuario se pone al día y realiza un bloqueo de interrupción en el dispositivo.
- A las 00:45, el usuario vuelve de su descanso y desbloquea el dispositivo.
- A la 01:45, se solicita al usuario que vuelva a iniciar sesión según el requisito de frecuencia de inicio de sesión de la directiva de acceso condicional configurada por su administrador, ya que el último inicio de sesión se produjo a las 00:45.
Persistencia de las sesiones de exploración
Una sesión persistente del explorador permite a los usuarios permanecer con la sesión iniciada después de cerrar y volver a abrir la ventana del explorador. El valor predeterminado de Microsoft Entra ID para la persistencia de la sesión del explorador permite a los usuarios de dispositivos personales elegir si desean conservar la sesión mostrando una opción "¿Mantener la sesión iniciada?". tras una autenticación correcta.
Validación
Utilice la herramienta What-If para simular un inicio de sesión del usuario en la aplicación de destino y otras condiciones según la configuración de la directiva. Los controles de administración de la sesión de autenticación se muestran en el resultado de la herramienta.
Implementación de directivas
Para asegurarse de que la directiva funciona como cabría esperar, el procedimiento recomendado es probarla antes de implementarla en producción. Lo ideal es usar un inquilino de prueba para comprobar si la nueva directiva funciona según lo previsto.
Evaluación continua del acceso (CAE)
La expiración y actualización de los tokens es un mecanismo estándar del sector. Cuando una aplicación cliente como Outlook se conecta a un servicio como Exchange Online, las solicitudes de API se autorizan mediante tokens de acceso de OAuth 2.0. De manera predeterminada, los tokens de acceso son válidos durante una hora; cuando expiran, se redirige al cliente a Microsoft Entra ID para actualizarlos. Ese período de actualización proporciona una oportunidad para volver a evaluar las directivas de acceso de los usuarios. Por ejemplo: podemos optar por no actualizar el token debido a una directiva de acceso condicional o porque el usuario se ha deshabilitado en el directorio.
Sin embargo, hay un retraso entre el momento en que cambian las condiciones de un usuario y el momento en que se aplican los cambios de directiva. La respuesta oportuna a las infracciones de las directivas o a los problemas de seguridad requiere realmente una "conversación" entre el emisor de los tokens y el usuario de confianza (aplicación iluminada). Esta conversación bidireccional nos proporciona dos funcionalidades importantes. El usuario de confianza puede ver cuándo cambian las propiedades, como la ubicación de red, e indicárselo al emisor del token. También proporciona al emisor del token una manera de indicar al usuario de confianza que deje de respetar los tokens de un usuario determinado debido a que la cuenta esté en peligro, se haya deshabilitado u otros problemas. El mecanismo para esta conversación es la evaluación continua de acceso (CAE).
Ventajas
Hay varias ventajas clave para la evaluación continua de acceso.
- Terminación del usuario y cambio o restablecimiento de la contraseña: la revocación de la sesión de usuario se aplicará casi en tiempo real.
- Cambio de ubicación de red: las directivas de ubicación del acceso condicional se aplicarán casi en tiempo real.
- La exportación de tokens a una máquina fuera de una red de confianza se puede evitar con las directivas de ubicación del acceso condicional.
Flujo del proceso de evaluación y revocación
- Un cliente compatible con la evaluación continua de acceso (CAE) presenta credenciales o un token de actualización a Microsoft Entra ID para solicitar un token de acceso para algún recurso.
- Se devuelve un token de acceso junto con otros artefactos al cliente.
- El administrador revoca explícitamente todos los tokens de actualización de un usuario. Se enviará un evento de revocación al proveedor de recursos desde Microsoft Entra ID.
- Se presenta un token de acceso al proveedor de recursos. El proveedor de recursos evalúa la validez del token y comprueba si hay algún evento de revocación para el usuario. El proveedor de recursos utiliza esta información para decidir si se concede acceso al recurso.
- En el caso del diagrama, el proveedor de recursos deniega el acceso y envía un error 401+ y un desafío de notificaciones al cliente.
- El cliente compatible con CAE comprende el desafío de 401 notificaciones o más. Omite las cachés y vuelve al paso 1, enviando su token de actualización junto con el desafío de notificaciones de vuelta a Microsoft Entra ID. A continuación, Microsoft Entra ID volverá a evaluar todas las condiciones y solicitará al usuario que vuelva a autenticarse en este caso.