Compartilhar via

Tempo de vida da sessão adaptável de Acesso Condicional

  • Artigo

Em implantações complexas, talvez as organizações precisem restringir as sessões de autenticação. Alguns cenários podem incluir:

  • Acesso a recursos de um dispositivo não gerenciado ou compartilhado
  • Acesso a informações confidenciais de uma rede externa
  • Usuários com alto impacto
  • Aplicativos de negócios críticos

O Acesso Condicional fornece controles de política de tempo de vida da sessão, permitindo a você criar políticas direcionadas a casos de uso específicos na organização, sem afetar todos os usuários.

Antes de analisar detalhadamente como configurar a política, vamos examinar a configuração padrão.

Frequência de entrada do usuário

A frequência de entrada define o período de tempo antes que um usuário seja solicitado a entrar novamente ao tentar acessar um recurso.

A configuração padrão do Microsoft Entra ID para a frequência de entrada do usuário é uma janela contínua de 90 dias. Solicitar credenciais aos usuários frequentemente parece uma coisa sensata a se fazer, mas o tiro pode sair pela culatra: os usuários treinados para inserir suas credenciais sem pensar podem fornecê-las involuntariamente a uma solicitação de credencial mal-intencionada.

Pode parecer alarmante não solicitar que um usuário entre novamente e, na verdade, qualquer violação das políticas de TI revogará a sessão. Alguns exemplos incluem, mas não se limitam a: uma alteração de senha, um dispositivo incompatível ou uma desabilitação de conta. Você também pode revogar as sessões de usuários explicitamente usando o PowerShell do Microsoft Graph. A configuração padrão do Microsoft Entra ID resume-se a “não solicitar aos usuários que forneçam as credenciais se a postura de segurança das sessões não tiver passado por alterações.”

A configuração da frequência de entrada funciona com aplicativos que tenham implementado os protocolos OAuth2 ou OIDC de acordo com os padrões. A maioria dos aplicativos nativos da Microsoft para Windows, Mac e Celular, incluindo os aplicativos Web a seguir, está em conformidade com a configuração.

  • Word, Excel, PowerPoint Online
  • OneNote Online
  • Office.com
  • Portal de administração do Microsoft 365
  • Exchange Online
  • SharePoint e OneDrive
  • Cliente Web do Teams
  • Dynamics CRM Online
  • Portal do Azure

A configuração de SIF (frequência de entrada) também funciona com aplicativos SAML de terceiros e aplicativos que implementam os protocolos OAuth2 ou OIDC, desde que eles não removam os próprios cookies e sejam redirecionados periodicamente ao Microsoft Entra para autenticação.

Frequência de entrada do usuário e autenticação multifator

Anteriormente, a frequência de entrada se aplicava somente à autenticação de primeiro fator em dispositivos ingressados no Microsoft Entra, ingressados de forma híbrida no Microsoft Entra e registrados no Microsoft Entra. Não havia uma maneira fácil de os clientes reforçarem a autenticação multifator nesses dispositivos. Com base nos comentários do cliente, a frequência de entrada também se aplica à MFA.

Um diagrama mostrando como a frequência de entrada e a MFA funcionam juntas.

Frequência de entrada do usuário e identidades do dispositivo

Em dispositivos ingressados no Microsoft Entra e ingressados no Microsoft Entra híbrido, desbloquear o dispositivo ou entrar de maneira interativa atualiza o PRT (Token de Atualização Principal) a cada quatro horas. O último carimbo de data/hora de atualização registrado para PRT em comparação com o carimbo de data/hora atual deve estar dentro do tempo alocado na política SIF para PRT para atender ao SIF e conceder acesso a um PRT que tenha uma declaração de MFA existente. Em dispositivos registrados do Microsoft Entra, o desbloqueio/entrada não atenderia à política SIF porque o usuário não está acessando um dispositivo registrado do Microsoft Entra por meio de uma conta Microsoft Entra. No entanto, o plug-in Microsoft Entra WAM pode atualizar um PRT durante a autenticação de aplicativo nativo usando o WAM.

Observação

O carimbo de data/hora capturado do logon do usuário não é necessariamente o mesmo que o último carimbo de data/hora registrado da atualização do PRT devido ao ciclo de atualização de quatro horas. O caso é o mesmo quando um PRT expirou e um log-in de usuário o atualiza por quatro horas. Nos exemplos a seguir, suponha que a política SIF esteja definida como uma hora e o PRT seja atualizado à 00:00.

Exemplo 1: quando você continua a trabalhar no mesmo documento no SPO por uma hora

  • À 00:00, um usuário entra em seu dispositivo ingressado no Microsoft Entra do Windows 11 e inicia o trabalho em um documento armazenado no SharePoint Online.
  • O usuário continua trabalhando no mesmo documento em seu próprio dispositivo por uma hora.
  • À 01:00, será solicitado que o usuário entre novamente. A solicitação é baseada no requisito de frequência de entrada na política de Acesso Condicional configurada pelo administrador do usuário.

Exemplo 2: ao pausar o trabalho com uma tarefa em segundo plano em execução no navegador, interaja novamente após o tempo de política SIF ter passado

  • À 00:00, um usuário entra em seu dispositivo ingressado no Microsoft Entra do Windows 11 e inicia o upload de um documento no SharePoint Online.
  • À 00:10, o usuário se levanta e faz um intervalo, bloqueando o dispositivo. O upload em segundo plano continua no SharePoint Online.
  • Às 02:45, o usuário retorna do intervalo e desbloqueia o dispositivo. O upload em segundo plano mostra a conclusão.
  • Às 02:45, será solicitado que o usuário entre quando interagir novamente. Essa solicitação é com base no requisito de frequência de entrada da política de Acesso condicional configurada pelo administrador, uma vez que a última entrada ocorreu à 00:00.

Se o aplicativo cliente (em detalhes da atividade) for um navegador, adiaremos a imposição de frequência de entrada de eventos/políticas nos serviços em segundo plano até a próxima interação do usuário. Em clientes confidenciais, a imposição de frequência de entrada em entradas não interativas é adiada até a próxima entrada interativa.

Exemplo 3: com ciclo de atualização de quatro horas do token de atualização principal do desbloqueio

Cenário 1 – O usuário retorna dentro do ciclo

  • À 00:00, um usuário entra em seu dispositivo ingressado no Microsoft Entra do Windows 11 e inicia o trabalho em um documento armazenado no SharePoint Online.
  • À 00:30, o usuário se levanta e faz um intervalo, bloqueando o dispositivo.
  • À 00:45, o usuário retorna do intervalo e desbloqueia o dispositivo.
  • À 01:00, será solicitado que o usuário entre novamente. Este prompt se baseia no requisito de frequência de entrada da política de Acesso Condicional configurada pelo administrador, uma hora após a entrada inicial.

Cenário 2 – O usuário retorna um ciclo externo

  • À 00:00, um usuário entra em seu dispositivo ingressado no Microsoft Entra do Windows 11 e inicia o trabalho em um documento armazenado no SharePoint Online.
  • À 00:30, o usuário se levanta e faz um intervalo, bloqueando o dispositivo.
  • Às 04:45, o usuário retorna do intervalo e desbloqueia o dispositivo.
  • Às 05:45, será solicitado que o usuário entre novamente. A solicitação é baseada no requisito de frequência de entrada na política de Acesso Condicional configurada pelo administrador do usuário. Agora é uma hora após o PRT ter sido atualizado às 04:45, e mais de quatro horas desde a entrada inicial à 00:00.

Sempre exigir reautenticação

Há cenários em que os clientes podem querer exigir uma nova autenticação, sempre que um usuário executar ações específicas como:

  • Acessar aplicativos confidenciais.
  • Proteger recursos por trás de provedores de VPN ou NaaS (rede como um serviço).
  • Proteger a elevação de privilégios de uma função no PIM.
  • Proteger as entradas de usuário em computadores da Área de Trabalho Virtual do Azure.
  • Proteger contra usuários suspeitos e entradas suspeitas Identificado pela Proteção do Microsoft Entra ID.
  • Protegendo ações confidenciais do usuário, como o registro do Microsoft Intune.

A frequência de entrada definida como sempre funciona melhor quando o recurso tem a lógica de quando um cliente deve obter um novo token. Esses recursos redirecionam o usuário de volta para o Microsoft Entra-somente quando a sessão expira.

Os administradores devem limitar o número de aplicativos nos quais impõem uma política que exige que os usuários se reautentiquem sempre. Consideramos cinco minutos de distorção de relógio quando sempre que estiver selecionado na política, para que não solicitemos aos usuários mais do que uma vez a cada cinco minutos. Disparar a reautenticação com muita frequência pode aumentar o atrito de segurança a um ponto que faça com que os usuários se cansem da MFA e abram a porta para tentativas de phishing. Os aplicativos Web geralmente fornecem uma experiência menos disruptiva do que suas versões para desktop quando a exigência de reautenticação sempre está habilitada.

Cenários de disponibilidade geral com suporte:

Os recursos de visualização pública fevereiro de 2024 permitem que os administradores exijam autenticação com:

Quando os administradores selecionarem Sempre, isso exigirá reautenticação total quando a sessão for avaliada.

Persistência de sessões de navegação

Uma sessão persistente do Browser permite que os usuários permaneçam conectados depois de fechar e reabrir a janela do navegador.

O padrão do Microsoft Entra para persistência de sessão de navegador permite que os usuários em dispositivos pessoais escolham se querem manter a sessão mostrando o prompt “Permanecer conectado?” depois de se autenticarem. Se a persistência do Browser estiver configurada no AD FS usando as diretrizes no artigo Configurações de logon único do AD FS, também vamos obedecer a essa política e manter a sessão do Microsoft Entra. Você também pode configurar se os usuários em seu locatário veem o prompt "Permanecer conectado?" alterando a configuração apropriada no painel de identidade visual da empresa.

Em Browsers persistentes, os cookies permanecem armazenados no dispositivo do usuário mesmo depois de fechar o navegador. Esses cookies podem ter acesso a artefatos do Microsoft Entra e esses artefatos podem ser usados até que o token expire, independentemente das políticas de Acesso Condicional colocadas no ambiente de recursos. Portanto, o cache de token pode estar violando diretamente as políticas de segurança desejadas para autenticação. Embora possa parecer conveniente armazenar tokens além da sessão atual, isso pode criar uma vulnerabilidade de segurança permitindo o acesso não autorizado a artefatos do Microsoft Entra.

Configurar controles da sessão de autenticação

Acesso Condicional é um recurso do Microsoft Entra ID P1 ou P2 e requer uma licença Premium. Se você quiser saber mais sobre Acesso Condicional, consulte O que é Acesso Condicional no Microsoft Entra ID?

Aviso

Se você estiver usando o recurso de tempo de vida de token configurável, atualmente em versão preliminar pública, observe que não há suporte para a criação de duas políticas diferentes para a mesma combinação de usuário ou aplicativo: uma com esse recurso e outra com o recurso de tempo de vida de token configurável. A Microsoft desativou o recurso de tempo de vida de token configurável para atualização e tempos de vida de token de sessão em 30 de janeiro de 2021, substituindo-o pelo recurso de gerenciamento de sessão de autenticação de Acesso Condicional.

Antes de habilitar a Frequência de Entrada, verifique se outras configurações de reautenticação estão desabilitadas em seu locatário. Se "Lembrar MFA em dispositivos confiáveis" estiver habilitado, certifique-se de desabilitá-lo antes de usar a Frequência de Entrada, pois usar essas duas configurações em conjunto pode levar à solicitação de usuários inesperadamente. Para saber mais sobre solicitações de reautenticação e tempo de vida da sessão, consulte o artigo Otimizar solicitações de reautenticação e entender o tempo de vida da sessão para a autenticação multifator do Microsoft Entra.

Próximas etapas