Vida útil adaptável da sessão 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 de forte impacto
  • Aplicativos de negócios críticos

O acesso condicional fornece controles de política de vida útil adaptável da sessão, permitindo 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 início de sessão do usuário

A frequência de entrada define o período antes que um usuário seja solicitado a iniciar sessão 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 tangente: 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 conta desabilitada. 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 dispositivos móveis, 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 Microsoft 365
  • Exchange Online
  • SharePoint e OneDrive
  • Cliente Web do Teams
  • Dynamics CRM Online
  • Portal do Azure

A frequência de entrada (SIF) funciona com aplicativos SAML de terceiros e aplicativos que implementam os protocolos OAuth2 ou OIDC, desde que não descartem os próprios cookies e sejam redirecionados regularmente ao Microsoft Entra ID 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 em feedbacks de clientes, 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 de forma híbrida, 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 no PRT em comparação com o carimbo de data/hora atual deve estar dentro do tempo alocado na política de SIF para PRT a fim de atender à SIF e permitir acesso a um PRT que tenha um requerimento de MFA existente. Em dispositivos registrados do Microsoft Entra, o desbloqueio/entrada não atenderia à política de SIF porque o usuário não está acessando um dispositivo registrado do Microsoft Entra por meio de uma conta do Microsoft Entra. No entanto, o plugin Microsoft Entra WAM pode atualizar um PRT durante a autenticação de aplicativos nativos 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 expira e um logon de usuário o atualiza por quatro horas. Nos exemplos a seguir, suponha que a política de SIF esteja definida para uma hora e o PRT seja atualizado às 00h00.

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

  • Às 00h00, 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.
  • Às 1h00, será solicitado que o usuário inicie a sessão novamente. Essa solicitação é baseada no requisito da frequência de entrada da 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 Browser, interaja novamente após o tempo da política de SIF ter decorrido

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

Se o aplicativo cliente (em detalhes da atividade) for um Browser, adiaremos a imposição da 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 da frequência de entrada em sessões sem interação é adiada até a próxima entrada interativa.

Exemplo 3: com o 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

  • Às 00h00, 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.
  • Às 00h30, o usuário se levanta e faz um intervalo, bloqueando o dispositivo.
  • Às 00h45, o usuário retorna do intervalo e desbloqueia o dispositivo.
  • Às 1h00, será solicitado que o usuário inicie a sessão novamente. Essa solicitação se baseia no requisito da 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 fora do ciclo

  • Às 00h00, 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.
  • Às 00h30, o usuário se levanta e faz um intervalo, bloqueando o dispositivo.
  • Às 04h45, o usuário retorna do intervalo e desbloqueia o dispositivo.
  • Às 05h45, será solicitado que o usuário inicie a sessão novamente. Essa solicitação é baseada no requisito da frequência de entrada da política de acesso condicional configurada pelo administrador do usuário. Agora se passou uma hora depois que o PRT foi atualizado às 04h45, e mais de quatro horas desde a entrada inicial à 00h00.

Sempre exigir uma nova autenticação

Há cenários em que convém aos clientes 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 serviço).
  • Proteger a elevação de função com privilégios no PIM.
  • Proteger as entradas de usuários em computadores da Área de Trabalho Virtual do Azure.
  • Proteger contra usuários suspeitos e entradas suspeitas identificados pelo Microsoft Entra ID Protection.
  • Proteger 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 exigindo que os usuários sempre se autentiquem novamente. Consideramos uma diferença de cinco minutos no relógio quando “sempre” estiver selecionado na política, para que não solicitemos aos usuários mais do que uma vez a cada cinco minutos. Acionar uma nova autenticação com muita frequência pode aumentar o atrito de segurança ao ponto de fazer com que os usuários se cansem da MFA e abram a porta para tentativas de phishing. Os aplicativos Web costumam fornecer uma experiência menos disruptiva do que suas versões para desktop quando a exigência de nova autenticação “sempre” está habilitada.

Cenários de disponibilidade geral com suporte:

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

Quando os administradores selecionarem Sempre, isso exigirá uma nova autenticaçã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 ID para persistência de sessão do Browser permite que os usuários em dispositivos pessoais escolham se querem manter a sessão mostrando a solicitação "Permanecer conectado?" depois de se autenticarem com êxito. 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 no seu locatário veem a solicitação "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, que 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

O acesso condicional é um recurso do Microsoft Entra ID P1 ou P2 e requer uma licença Premium. Se quiser saber mais sobre o acesso condicional, confira O que é acesso condicional no Microsoft Entra ID?

Aviso

Se você estiver usando o recurso de vida útil de token configurável, atualmente em visualização 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 vida útil de token configurável. A Microsoft desativou o recurso de vida útil de token configurável para atualização e vidas úteis 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 nova autenticação estão desabilitadas no seu locatário. Se a opção "Lembrar MFA em dispositivos confiáveis" estiver habilitada, certifique-se de desabilitá-la 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 nova autenticação e vida útil da sessão, confira o artigo Otimizar as solicitações de nova autenticação e entender a vida útil da sessão da autenticação multifator do Microsoft Entra.

Próximas etapas