Implementar o gerenciamento de sessões e a avaliação contínua de acesso
Em implementações complexas, as organizações podem ter a necessidade de restringir as sessões de autenticação. Alguns cenários podem incluir:
- Acesso a recursos a partir de um dispositivo não gerenciado ou compartilhado.
- Acesso a informações confidenciais a partir de uma rede externa.
- Usuários executivos ou de alta prioridade.
- Aplicativos de negócios críticos.
Os controles de Acesso Condicional permitem que você crie políticas direcionadas a casos de uso específicos em sua organização sem afetar todos os usuários.
Antes de entrar em detalhes sobre como configurar a política, vamos examinar a configuração padrão.
Frequência de início de sessão do utilizador
A frequência de início de sessão define o período de tempo antes de ser pedido a um utilizador que inicie sessão novamente quando tentar aceder a um recurso.
A configuração predefinida do Microsoft Entra ID para a frequência de início de sessão do utilizador é um período variável de 90 dias. Pedir credenciais aos utilizadores muitas vezes parece uma coisa sensata a fazer, mas pode sair pela culatra: os utilizadores que são treinados para introduzir as suas credenciais sem pensar podem fornecê-las involuntariamente a uma solicitação de credenciais maliciosa.
Pode soar alarmante não pedir para um usuário entrar novamente; na realidade, qualquer violação das políticas de TI revogará a sessão. Alguns exemplos incluem uma alteração de senha, um dispositivo incompatível ou uma conta desativada. Você também pode revogar explicitamente as sessões dos usuários usando o PowerShell. A configuração padrão do Microsoft Entra ID se resume a "não peça aos usuários que forneçam suas credenciais se a postura de segurança de suas sessões não tiver mudado".
A definição de frequência de início de sessão funciona com aplicações que implementaram protocolos OAUTH2 ou OIDC de acordo com as normas. A maioria das aplicações para Windows, Mac e dispositivos móveis, incluindo as seguintes aplicações Web, está em conformidade com a definição.
- Word, Excel, PowerPoint Online
- OneNote Online
- Office.com
- Portal de administração do Microsoft 365
- Exchange Online
- SharePoint e OneDrive
- Cliente Web do Microsoft Teams
- Dynamics CRM Online
- portal do Azure
A configuração de frequência de entrada também funciona com aplicativos SAML, desde que eles não soltem seus próprios cookies e sejam redirecionados de volta para o Microsoft Entra ID para autenticação regularmente.
Frequência de início de sessão do utilizador e autenticação multifator
A frequência de início de sessão aplicava-se anteriormente apenas à primeira autenticação de fator em dispositivos unidos ao Microsoft Entra, híbridos unidos ao Microsoft Entra e registados no Microsoft Entra. Não havia uma maneira fácil para nossos clientes reforçarem a autenticação multifator (MFA) nesses dispositivos. Com base nos comentários dos clientes, a frequência de início de sessão também se aplicará ao MFA.
Frequência de início de sessão do utilizador e identidades do dispositivo
Se tiver dispositivos ingressados no Microsoft Entra, híbridos ingressados no Microsoft Entra, ou registados no Microsoft Entra, quando um utilizador desbloquear o seu dispositivo ou iniciar sessão de forma interativa, este evento satisfará também a política de frequência de início de sessão. Nos dois exemplos a seguir, a frequência de entrada do usuário é definida como uma hora:
Exemplo 1:
- Às 00:00, um usuário entra em seu dispositivo Windows 10 Microsoft Entra e começa a trabalhar em um documento armazenado no SharePoint Online.
- O usuário continua trabalhando no mesmo documento em seu dispositivo por uma hora.
- Às 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:
- Às 00:00, um usuário entra em seu dispositivo Windows 10 Microsoft Entra e começa a trabalhar em um documento armazenado no SharePoint Online.
- Às 00h30, o utilizador levanta-se e faz uma pausa, bloqueando o seu dispositivo.
- Às 00:45, o usuário retorna de sua pausa e desbloqueia o dispositivo.
- Às 01:45, 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 desde que o último login aconteceu às 00:45.
Persistência das sessões de navegação
Uma sessão de browser persistente permite que os utilizadores mantenham a sessão iniciada depois de abrirem e fecharem a janela do browser. O Microsoft Entra ID padrão para persistência de sessão do navegador permite que os usuários em dispositivos pessoais escolham se desejam manter a sessão, mostrando um "Permanecer conectado?" após a autenticação bem-sucedida.
Validação
Use a ferramenta Hipóteses para simular uma entrada do usuário no aplicativo de destino e outras condições com base em como você configurou sua política. Os controles de gerenciamento de sessão de autenticação aparecem no resultado da ferramenta.
Implementação de políticas
Para garantir que sua política funcione conforme o esperado, a prática recomendada é testá-la antes de implementá-la em produção. Idealmente, use um locatário de teste para verificar se sua nova política funciona como pretendido.
Avaliação Contínua de Acesso (CAE)
A expiração e a atualização 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. Esse período de atualização oferece uma oportunidade para reavaliar as políticas de acesso do usuário. Por exemplo: podemos 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íticas ou problemas de segurança realmente requer uma "conversa" entre o emissor do token e a terceira parte confiável (aplicativo habilitado). Esta conversa bidirecional dá-nos duas capacidades importantes. A parte confiável pode ver quando as propriedades mudam, como a localização na rede, e notificar o emissor do token. Ele também fornece ao emissor de token uma maneira de informar à parte confiada para deixar de aceitar tokens para um determinado utilizador devido a violação de conta, desativação ou outras preocupações. O mecanismo para esta conversa é a avaliação contínua de acesso (CAE).
Benefícios
Existem vários benefícios fundamentais na avaliação contínua do acesso.
- Rescisão do usuário ou alteração/redefinição de senha: A revogação da sessão do usuário será aplicada quase em tempo real.
- Alteração de local de rede: as políticas de localização de Acesso Condicional serão aplicadas quase em tempo real.
- A exportação de tokens para uma máquina fora de uma rede confiável pode ser impedida com políticas de local de Acesso Condicional.
Fluxo do processo de avaliação e revogação
- Um cliente compatível com avaliação de acesso contínuo (CAE) apresenta credenciais ou um token de atualização para o Microsoft Entra ID solicitando um token de acesso para algum recurso.
- Um token de acesso é retornado junto com outros artefatos para o cliente.
- Um administrador revoga explicitamente todos os tokens de atualização para o usuário. Um evento de revogação será enviado para o provedor de recursos a partir do Microsoft Entra ID.
- 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 conceder acesso ao recurso ou não.
- No caso do diagrama, o provedor de recursos nega o acesso e envia um desafio de declaração 401+ de volta ao cliente.
- O cliente compatível com CAE entende o desafio de reivindicação 401+. Ele ignora os caches e volta para a etapa 1, enviando seu token de atualização junto com o desafio de declaração de volta para o Microsoft Entra ID. O Microsoft Entra ID reavaliará todas as condições e solicitará que o usuário se autentique novamente nesse caso.