Como gerenciar a vida útil das sessões do Microsoft 365 – Parte II

Continuamos buscando o equilibrio entre a experiencia do usuário e a duração da sessão.

Em nossa ultima postagem falamos sobre o gerenciamento da vida útil das sessões, e hoje vamos continuar a abordar esse assunto que é tão importante para aspectos de Segurança do Microsoft 365 e administração dos acessos dos usuários.

Para quem perdeu a primeira parte, recomendo que leia e estude o início dessa série. Aqui está o Link para você acompanhar

hoje vamos nos debruçar sobre:

As políticas de acesso condicional desempenham um papel crítico na segurança cibernética, permitindo um controle granular sobre a “frequência de login” e a “persistência” das sessões da web. Em termos práticos, essas políticas definem com que frequência os usuários precisam se autenticar novamente para acessar uma plataforma. Isso é fundamental para manter um equilíbrio entre segurança e experiência do usuário.

Entendendo as Políticas de Acesso Condicional

Essas políticas são utilizadas para determinar quanto tempo uma sessão de usuário pode durar antes de exigir uma nova autenticação. Elas também permitem especificar comportamentos adicionais, como condições sob as quais uma sessão é considerada “persistente”, ou seja, quando ela pode manter-se ativa por um período mais longo, sem intervenção do usuário.

Impacto de Provedores de Identidade Terceirizados

Se a autenticação é gerenciada por um provedor de identidade (IdP) terceirizado, como o Azure AD ou o Okta, ele geralmente controla o acesso inicial à plataforma. No entanto, uma vez dentro da plataforma, as durações padrão das sessões são aplicadas, sem que o IdP tenha controle direto sobre esse aspecto. Para gerenciar a persistência e a frequência de login dentro da plataforma, é necessário utilizar políticas de acesso condicional internas.

Alternativa à Modificação da Vida Útil do Token de Atualização

Antes de 31 de janeiro de 2021, era possível modificar a vida útil dos tokens de atualização para controlar a persistência das sessões. No entanto, desde então, esse recurso foi removido, tornando as políticas de acesso condicional a principal ferramenta para esse controle. Isso significa que as organizações devem usar recursos como “fatores de risco” para avaliar a confiabilidade da sessão e exigir reautenticações mais frequentes quando necessário.

Se o parâmetro “frequência de login” estiver ativo: um token de atualização mais antigo que a “frequência de login” definida será invalidado durante sua avaliação. O usuário terá que se autenticar novamente e verá a seguinte mensagem:

A funcionalidade de “frequência de login” é uma ferramenta eficaz para controlar a persistência das sessões em clientes compatíveis com OAuth2 e OpenID Connect. Isso inclui aplicativos web e aplicativos thick client da Microsoft, desde que a autenticação moderna esteja ativada.

No entanto, a Microsoft destaca dois pontos importantes a serem considerados ao configurar a política de frequência de login:

1. Impacto em Dispositivos Registrados no Azure AD Se seus dispositivos estiverem ingressados no Azure AD, híbridos ou registrados no Azure AD, quando um usuário desbloquear o dispositivo ou fizer login interativamente, esse evento também é considerado uma autenticação válida. Isso ocorre porque um novo Token de Atualização Primária (PRT) é gerado durante esses eventos. Portanto, ao usar a política de frequência de login, esteja ciente de que eventos de desbloqueio de dispositivos ou login interativo podem satisfazer a política, potencialmente aumentando a persistência sem uma reautenticação explícita do usuário.

2. Conflito com “Lembrar MFA em Dispositivos Confiáveis” Se a configuração “Lembrar MFA em dispositivos confiáveis” estiver ativada, ela pode entrar em conflito com a política de frequência de login. Se você estiver usando a política de frequência de login, é importante desativar essa configuração para evitar comportamentos inesperados, como avisos de reautenticação que podem surpreender os usuários.

Se a configuração “Sessão persistente do navegador” estiver habilitada : a política de acesso condicional substitui a opção Mantenha-me conectado escolhida pelo usuário.

Avaliação de Acesso Contínuo

Para limitar o risco relacionado à janela de 1 hora para tokens de acesso, a Microsoft está atualmente implantando a “ Avaliação de Acesso Contínuo ”.

Esta funcionalidade permitirá revogar um token de acesso e forçar uma reautenticação do usuário em caso de evento ou mudança de contexto para clientes compatíveis.

Em caso de ocorrência de evento : Os serviços passam a ser informados em caso de evento crítico:

A conta do usuário foi excluída ou desativada
A senha de um usuário foi alterada ou redefinida
A autenticação multifator está habilitada para o usuário
O administrador revoga explicitamente todos os tokens de atualização de um usuário
Alto risco do usuário detectado pela Proteção de Identidade do Azure AD

Se tal evento ocorrer, o serviço forçará o usuário a se autenticar novamente.

Em caso de alteração de contexto: os serviços Exchange Online, SharePoint Online, Teams e Graph recuperam uma cópia das políticas de acesso condicional. No caso de uma mudança de contexto detectada pelo serviço, isso forçará o usuário a se autenticar novamente.

Esta funcionalidade está atualmente disponível apenas para a condição “localização” e para locais nomeados baseados em IP.

Paralelamente a esta melhoria da postura de segurança, a Microsoft alterou os valores padrão dos tempos de vida dos tokens de acesso :

Para cliente compatível com CAE: Entre 20 e 28 horas dependendo do serviço
Para um cliente não compatível com CAE: Cerca de 1h

O aumento do tempo de vida dos tokens de acesso pode representar um problema de segurança porque a extração de um token de acesso com um tempo de vida longo o tornaria explorável por um longo período (exceto em um terminal presente nos locais nomeados), o que não está realmente na lógica de a Confiança Zero. Apostemos que em breve a Microsoft fará evoluir a abordagem.

No meu locatário, a vida útil do token de acesso é sempre de uma hora.

Configuração do tempo de vida do token de acesso

Com a introdução da Avaliação Contínua de Acesso, pode ser interessante pensar nos tempos de vida dos tokens de acesso, caso os valores padrão definidos pela Microsoft não sejam adequados para você (1h para cliente não-CAE compatível e até 28h para cliente CAE compatível).

Para modificá-los é necessário definir uma política de tokens e aplicá-la:

Por padrão para todos os aplicativos
Ou para uma aplicação específica

Essa criação é feita hoje via PowerShell . Um exemplo abaixo:


$policy = New-AzureADPolicy -Definition @('{"TokenLifetimePolicy":{"Version":1,"AccessTokenLifetime":"00:15:00"}}') -DisplayName "TokenLifetimePolicy-15min" -IsOrganizationDefault $false -Type "TokenLifetimePolicy"


Get-AzureADPolicy | Select *


$sp = Get-AzureADServicePrincipal -Filter "DisplayName eq 'Office 365 Exchange Online'"
Add-AzureADServicePrincipalPolicy -Id $sp.ObjectId -RefObjectId $policy.Id

Porém, é importante ressaltar que TODOS os novos tokens de acesso respeitarão esse novo valor .

Padrões de resiliência

A Microsoft lançou no final de 2020 o Backup de autenticação do Azure AD .

Esta funcionalidade permite a renovação das sessões atuais em caso de interrupção do serviço de autenticação primário (<0,01% do tempo de acordo com os SLAs da Microsoft), com o contexto conhecido da autenticação anterior.

Durante tal evento, as políticas de acesso condicional compatíveis são reavaliadas antes de regenerar o token. As seguintes condições não são suportadas hoje:

Associação ao grupo
Associação de função
Risco de login
Risco do usuário
Localização do país (resolvendo novas coordenadas IP ou GPS)

A Microsoft introduziu recentemente padrões de resiliência para controlar políticas de acesso condicional não suportadas que podem ser ignoradas como parte de uma interrupção. Se os padrões de resiliência estiverem desativados e qualquer uma das condições acima não puder ser avaliada, o acesso será negado.

Os padrões de resiliência são habilitados automaticamente e podem ser desabilitados em políticas de acesso condicional.

Observe que o Backup de Autenticação do EntraID é compatível com a Avaliação de Acesso Contínuo. Um token de acesso que deveria ser revogado em circunstâncias normais também será revogado se o serviço de autenticação primário for interrompido.

Quais práticas recomendadas para controlar o tempo de vida das sessões?

Use políticas de acesso condicional para impor uma frequência de login com base em populações (usuários x administradores), serviços e contexto
Imponha uma frequência de login padrão
Deixe a opção Mantenha-me conectado disponível para os usuários (mas informe os usuários)
Habilitar avaliação de acesso contínuo (use locais nomeados por IP e não IP confiável)
Desabilitar durações padrão de resiliência para os acessos mais sensíveis

Blog do Chesley

Sempre uma novidade!