Implementar o gerenciamento de sessão e a avaliação contínua de acesso

Concluído

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 executivos ou de alta prioridade.
  • Aplicativos comercialmente críticos.

Os controles de Acesso condicional permitem 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. Muitas vezes, pedir credenciais aos usuários parece uma atitude sensata, mas o tiro pode sair pela culatra: Os usuários que são treinados para inserir suas credenciais sem pensar podem fornecê-las involuntariamente a um prompt de credencial mal-intencionado.

Pode parecer alarmante não solicitar que um usuário entre novamente; na verdade, qualquer violação das políticas de TI revogará a sessão. Entre alguns exemplos, temos: uma alteração de senha, um dispositivo incompatível ou um desativamento de conta. Você também pode revogar as sessões de usuários explicitamente usando o PowerShell. A configuração padrão da ID do Microsoft Entra se resume a "não pedir aos usuários que forneçam suas credenciais se a postura de segurança de suas sessões não tiver sido alterada".

A configuração da frequência de entrada funciona com aplicativos que tenham implementado protocolos OAUTH2 ou OIDC de acordo com os padrões. A maioria dos aplicativos para Windows, Mac e dispositivos móveis, incluindo os seguintes aplicativos Web, 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 frequência de login também funciona com aplicativos SAML, desde que eles não desabilitem seus próprios cookies e sejam redirecionados de volta para o Microsoft Entra ID para autenticação de forma consistente.

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

Anteriormente, a frequência de login era aplicada apenas à autenticação de primeiro fator nos dispositivos que eram registrados no Microsoft Entra, Microsoft Entra Híbrido e Microsoft Entra. Não havia uma maneira fácil de os clientes reimporem a MFA (autenticação multifator) nesses dispositivos. Com base no feedback dos clientes, a frequência de login também se aplicará à MFA.

Diagrama do processo de autenticação multifator com frequência de autenticação.

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

Se você tiver dispositivos registrados no Microsoft Entra, Microsoft Entra híbrido ou Microsoft Entra registrado, quando um usuário desbloquear o dispositivo ou fizer login interativamente, esse evento também atenderá à política de frequência de login. Nos dois exemplos a seguir, a frequência de entrada do usuário é definida como uma hora:

Exemplo 1:

  • À 00:00, um usuário faz login em seu dispositivo com Windows 10 associado ao Microsoft Entra 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, o usuário é solicitado a entrar novamente com base no requisito de frequência de entrada na política de Acesso condicional configurada pelo administrador.

Exemplo 2:

  • À 00:00, um usuário faz login em seu dispositivo com Windows 10 associado ao Microsoft Entra 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:45, o usuário é solicitado a entrar novamente 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:45.

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

Uma sessão persistente do navegador permite que os usuários permaneçam conectados depois de fechar e reabrir a janela do navegador. O padrão da ID do Microsoft Entra para persistência de sessão do navegador permite que os usuários em dispositivos pessoais escolham se devem persistir a sessão mostrando um "Permanecer conectado?". após a autenticação bem-sucedida.

Validação

Use a ferramenta What-If para simular um login de usuário no aplicativo de destino e outras condições com base na configuração da sua política. Os controles de gerenciamento de sessão de autenticação aparecem nos resultados da ferramenta.

Captura de tela dos resultados da ferramenta What If de acesso condicional.

Implantação de política

Para garantir que sua política funcione conforme o esperado, a melhor prática é testá-la antes de distribuí-la em produção. O ideal é usar um locatário de teste para verificar se a nova política funciona conforme o esperado.

CAE (Avaliação contínua de acesso)

As expirações e atualizações de tokens são um mecanismo padrão no setor. Quando um aplicativo cliente como o Outlook se conecta a um serviço como o Exchange Online, as solicitações de API são autorizadas usando tokens de acesso OAuth 2.0. Por padrão, os tokens de acesso são válidos por uma hora. Quando expiram, o cliente é redirecionado para o Microsoft Entra ID para atualizá-los. Nesse período de atualização, é possível reavaliar as políticas de acesso de usuários. Por exemplo, é possível optar por não atualizar o token devido a uma política de acesso condicional ou porque o usuário foi desabilitado no diretório.

No entanto, há um atraso entre quando as condições mudam para um usuário e quando as alterações de política são impostas. A resposta oportuna a violações de política ou problemas de segurança realmente requer uma "conversa" entre o emissor do token e a terceira parte confiável (aplicativo habilitado). Essa conversa bidirecional oferece duas funcionalidades importantes. A terceira parte confiável pode conferir quando as propriedades são alteradas, como o local da rede, e fornecer essas informações ao emissor do token. Com isso, o emissor do token pode informar a terceira parte confiável quando ela deve parar de respeitar os tokens de um determinado usuário devido a um comprometimento de conta, uma desabilitação ou outras preocupações. O mecanismo dessa conversa é a CAE (Avaliação Contínua de Acesso).

Benefícios

Há vários benefícios importantes para a avaliação contínua de acesso.

  • Rescisão de usuário ou alteração/redefinição de senha: a revogação da sessão do usuário será imposta quase em tempo real.
  • Alteração do local da rede: as políticas de localização de acesso condicional serão impostas quase em tempo real.
  • A exportação de token para um computador fora de uma rede confiável pode ser evitada com políticas de localização de acesso condicional.

Fluxo do processo de avaliação e revogação

Diagrama do fluxo do processo quando um token de acesso é revogado e um cliente precisa verificar novamente o acesso.

  1. Um cliente compatível com avaliação contínua de acesso (CAE) apresenta credenciais ou um token de atualização para o Microsoft Entra ID solicitando um token de acesso para algum recurso.
  2. Um token de acesso é retornado com outros artefatos ao cliente.
  3. Um administrador revoga explicitamente todos os tokens de atualização do usuário. Um evento de revogação será enviado ao provedor de recursos do Microsoft Entra ID.
  4. Um token de acesso é apresentado ao provedor de recursos. O provedor de recursos avalia a validade do token e verifica se há algum evento de revogação para o usuário. O provedor de recursos usa essas informações para decidir entre conceder ou não o acesso ao recurso.
  5. No caso do diagrama, o provedor de recursos nega o acesso e envia um desafio de declaração 401+ de volta ao cliente.
  6. O cliente compatível com CAE entende o desafio de declaração 401+. Ele ignora os caches e volta para a etapa 1, a fim de enviar o token de atualização com o desafio de declaração novamente ao Microsoft Entra ID. O Microsoft Entra ID reavaliará todas as condições e solicitará que o usuário se reautentique nesse caso.