Avaliação contínua de acesso
A expiração e a atualização do token 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, tokens de acesso são válidos por uma hora. Quando expiram, o cliente é redirecionado ao Azure AD 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.
Os clientes mostraram-se preocupados com o atraso quando as condições mudam para um usuário e quando as alterações de política são impostas. O Azure AD experimentou a abordagem "objeto contundente" de tempos de vida reduzidos de token, mas descobriu que eles podem prejudicar as experiências do usuário e a confiabilidade sem eliminar riscos.
A resposta oportuna a violações de política ou problemas de segurança realmente exige uma "conversa" entre o emissor do token (Azure AD) e a terceira parte confiável (aplicativo habilitado). Essa conversa bidirecional nos dá dois recursos importantes. A terceira parte confiável pode ver quando as propriedades são alteradas, como o local de rede, e informar o emissor do token. Ela também proporciona ao emissor do token uma maneira de dizer à terceira parte confiável para parar de respeitar os tokens de um determinado usuário devido a comprometimento da conta, desabilitação ou outras preocupações. O mecanismo para essa conversa é a avaliação contínua de acesso (CAE). A meta para avaliação de eventos críticos é ter uma resposta quase em tempo real, mas é possível observar uma latência de até 15 minutos devido ao tempo de propagação do evento. No entanto, a imposição da política de localização de IP é instantânea.
A implementação inicial da avaliação contínua de acesso se concentra no Exchange, no Teams e no SharePoint Online.
Para preparar seus aplicativos para usar a CAE, consulte Como usar APIs habilitadas para avaliação contínua de acesso nos seus aplicativos.
No momento, a avaliação de acesso contínuo não está disponível nos locatários do Azure Governamental GCC High.
Principais benefícios
- Término do 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 de local de rede: as políticas de local de acesso condicional serão impostas quase em tempo real.
- A exportação de tokens para um computador fora de uma rede confiável pode ser impedida com políticas de localização de acesso condicional.
Cenários
Há dois cenários que compõem a avaliação contínua de acesso, a avaliação de evento crítico e a avaliação de política de acesso condicional.
Avaliação de evento crítico
A avaliação contínua de acesso é implementada habilitando serviços, como o Exchange Online, o SharePoint Online e o Teams, para se inscrever em eventos críticos no Azure AD. Esses eventos podem então ser avaliados e impostos quase em tempo real. A avaliação de evento crítico não depende de políticas de Acesso Condicional, portanto, está disponível em qualquer locatário. Os seguintes eventos são avaliados no momento:
- A conta de usuário foi excluída ou desabilitada
- A senha de um usuário é alterada ou redefinida
- A autenticação multifator é habilitada para o usuário
- O administrador revoga explicitamente todos os tokens de atualização para um usuário
- Alto risco de usuário detectado pelo Azure AD Identity Protection
Esse processo habilita o cenário em que os usuários perdem o acesso a arquivos organizacionais, emails, calendário ou tarefas do SharePoint Online e ao Teams a partir de aplicativos de cliente do Microsoft 365 em minutos após um evento crítico.
Observação
O Teams e o SharePoint Online não são compatíveis com eventos de risco do usuário.
Avaliação da política de acesso condicional
O Exchange Online, o SharePoint Online, Teams e MS Graph podem sincronizar as principais políticas de acesso condicional para avaliação dentro do próprio serviço.
Esse processo permite o cenário em que os usuários perdem o acesso a arquivos organizacionais, emails, calendário ou tarefas de aplicativos clientes Microsoft 365 ou SharePoint Online imediatamente após as alterações do local de rede.
Observação
Nem todas as combinações de aplicativos cliente e provedores de recursos são compatíveis. Consulte as tabelas a seguir. A primeira coluna desta tabela refere-se aos aplicativos Web iniciados por meio do navegador da Web (ou seja, PowerPoint iniciado no navegador da Web), enquanto as quatro colunas restantes se referem aos aplicativos nativos em execução em cada plataforma descrita. Além disso, as referências ao "Office" abrangem o Word, o Excel e o PowerPoint.
| Outlook Web | Outlook Win32 | Outlook iOS | Outlook Android | Outlook Mac | |
|---|---|---|---|---|---|
| SharePoint Online | Com suporte | Com suporte | Com suporte | Com suporte | Com suporte |
| Exchange Online | Com suporte | Com suporte | Com suporte | Com suporte | Com suporte |
| Aplicativos Web do Office | Aplicativos do Office Win32 | Office para iOS | Office para Android | Office para Mac | |
|---|---|---|---|---|---|
| SharePoint Online | Sem suporte * | Com suporte | Com suporte | Com suporte | Com suporte |
| Exchange Online | Sem suporte | Com suporte | Com suporte | Com suporte | Com suporte |
| OneDrive Web | OneDrive Win32 | OneDrive iOS | OneDrive Android | OneDrive Mac | |
|---|---|---|---|---|---|
| SharePoint Online | Com suporte | Sem suporte | Com suporte | Com suporte | Sem suporte |
| Equipes web | Equipes Win32 | Equipes iOS | Equipes Android | Equipes Mac | |
|---|---|---|---|---|---|
| Equipes Service | Suporte parcial | Suporte parcial | Suporte parcial | Suporte parcial | Suporte parcial |
| SharePoint Online | Suporte parcial | Suporte parcial | Suporte parcial | Suporte parcial | Suporte parcial |
| Exchange Online | Suporte parcial | Suporte parcial | Suporte parcial | Suporte parcial | Suporte parcial |
* Os tempos de vida do token para aplicativos Web do Office são reduzidos para uma hora quando uma política de acesso condicional é definida.
Recursos do cliente
Desafio de declaração do lado do cliente
Antes da avaliação contínua de acesso, os clientes repetiriam o token de acesso a partir do cache, desde que ele não tenha expirado. Com a CAE, apresentamos um novo caso em que um provedor de recursos pode rejeitar um token quando ele não expirou. Para informar os clientes para ignorarem seu cache, mesmo que os tokens em cache não tenham expirado, introduzimos um mecanismo chamado desafio de declaração para indicar que o token foi rejeitado e um novo token de acesso precisa ser emitido pelo Azure AD. A CAE exige uma atualização do cliente para reconhecer o desafio de declaração. A versão mais recente dos seguintes aplicativos dá suporte ao desafio de declaração:
| Web | Win32 | iOS | Android | Mac | |
|---|---|---|---|---|---|
| Outlook | Com suporte | Com suporte | Com suporte | Com suporte | Com suporte |
| Teams | Com suporte | Com suporte | Com suporte | Com suporte | Com suporte |
| Office | Sem suporte | Com suporte | Com suporte | Com suporte | Com suporte |
| OneDrive | Com suporte | Com suporte | Com suporte | Com suporte | Com suporte |
Tempo de vida do Token
Como o risco e a política são avaliados em tempo real, os clientes que negociam as sessões de reconhecimento de avaliação contínua de acesso não confiam mais nas políticas de tempo de vida do token de acesso estático. Essa alteração significa que a política de tempo de vida do token configurável não é respeitada para clientes que negociam sessões com reconhecimento de CAE.
O tempo de vida do token é aumentado para ser de longa duração, até 28 horas, em sessões de CAE. A revogação é motivada por eventos críticos e avaliação de políticas, não apenas por um período de tempo arbitrário. Essa alteração aumenta a estabilidade dos aplicativos sem afetar a postura de segurança.
Se você não estiver usando clientes compatíveis com CAE, o tempo de vida do token de acesso padrão continuará sendo de uma hora. O padrão só será alterado se você tiver configurado o tempo de vida do token de acesso com a versão prévia do recurso Tempo de vida de token configurável (CTL).
Exemplos de diagramas de fluxo
Fluxo de eventos de revogação do usuário
- Um cliente compatível com CAE apresenta credenciais ou um token de atualização para o Azure AD solicitando um token de acesso para algum recurso.
- Um token de acesso é retornado junto com outros artefatos para o cliente.
- O administrador revoga explicitamente todos os tokens de atualização para o usuário. Um evento de revogação será enviado ao provedor de recursos a partir do Azure AD.
- 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 ou não acesso ao recurso.
- Nesse caso, 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 compreende o desafio de declaraçã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 ao Azure AD. O Azure AD reavaliará todas as condições e solicitará que o usuário se autentique novamente nesse caso.
Fluxo de alteração de condição do usuário
No exemplo a seguir, um administrador de acesso condicional configurou uma política de acesso condicional com base na localização para somente permitir acesso a partir de intervalos de IP específicos:
- Um cliente compatível com CAE apresenta credenciais ou um token de atualização para o Azure AD solicitando um token de acesso para algum recurso.
- O Azure AD avalia todas as políticas de acesso condicional para ver se o usuário e o cliente atendem às condições.
- Um token de acesso é retornado junto com outros artefatos para o cliente.
- O usuário sai de um intervalo de IP permitido.
- O cliente apresenta um token de acesso ao provedor de recursos de fora de um intervalo de IP permitido.
- O provedor de recursos avalia a validade do token e verifica a política de localização sincronizada do Azure AD.
- Nesse caso, o provedor de recursos nega o acesso e envia um desafio de declaração 401+ de volta ao cliente. O cliente é desafiado porque não está vindo de um intervalo de IP permitido.
- O cliente compatível com CAE compreende o desafio de declaraçã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 ao Azure AD. Nesse caso, o Azure AD reavalia todas as condições e negará o acesso.
Habilitar ou desabilitar o CAE
A configuração de CAE foi movida na folha do Acesso Condicional. Novos clientes CAE poderão acessar e alternar o CAE diretamente ao criar políticas de Acesso Condicional. No entanto, alguns clientes existentes deverão passar pela migração antes que possam começar a acessar o CAE por meio do Acesso Condicional.
Migração
Os clientes que definiram as configurações de CAE em Segurança, devem migrar as configurações para uma nova política de Acesso Condicional. Use as etapas a seguir para migrar suas configurações de CAE para uma política de Acesso Condicional.
- Entre no portal do Azure como administrador global, administrador de segurança ou administrador de acesso condicional.
- Navegue até Azure Active Directory>Segurança>Avaliação contínua de acesso.
- Em seguida, você verá a opção para Migrar sua política. Essa ação é a única à qual você terá acesso neste momento.
- Navegue até Acesso Condicional e você encontrará uma nova política denominada Política de Autoridade de Certificação criada das configurações de CAE com as configurações definidas. Os administradores podem optar por personalizar essa política ou criar uma política própria pra substituí-la.
A tabela a seguir descreve a experiência de migração de cada grupo de clientes com base nas configurações de CAE definidas anteriormente.
| Configuração de CAE existente | A migração é necessária | Habilitar automaticamente para CAE | A experiência de migração esperada |
|---|---|---|---|
| Novos locatários que não configuraram nada na experiência antiga. | Não | Sim | A configuração de CAE antiga ficará oculta, considerando que esses clientes provavelmente não viam a experiência antes da disponibilidade geral. |
| Os locatários habilitados explicitamente para todos os usuários com a experiência antiga. | Não | Sim | A configuração de CAE antiga ficará esmaecida. Como esses clientes habilitaram explicitamente essa configuração para todos os usuários, eles não precisam migrar. |
| Locatários que habilitaram explicitamente alguns usuários em seus locatários com a experiência antiga. | Sim | Não | As configurações antigas da CAE ficarão esmaecidas. Se você clicar em Migrar, o assistente para nova política de acesso condicional será iniciado, que inclui Todos os usuários, exceto os usuários e os grupos copiados da CAE. Também define o novo controle de sessão Personalizar avaliação de acesso contínuo como Desabilitado. |
| Locatários que desabilitam explicitamente a versão prévia. | Sim | Não | As configurações antigas da CAE ficarão esmaecidas. Se você clicar em Migrar, o assistente para nova política de acesso condicional será iniciado, que inclui Todos os usuários e define o novo controle de sessão Personalizar a Avaliação contínua de acesso como Desabilitado. |
Mais informações sobre a avaliação de acesso contínuo como um controle de sessão podem ser encontradas na seção Personalizar a avaliação de acesso contínuo.
Limitações
Tempo efetivo de atualização da política e associação ao grupo
As alterações feitas nas políticas de acesso condicional e na associação de grupo feitas pelos administradores podem levar até um dia para efetivação. O atraso é da replicação entre o Azure AD e os provedores de recursos, como Exchange Online e SharePoint Online. Foram feitas algumas otimizações nas atualizações de políticas que reduzem o atraso para duas horas. No entanto, elas ainda não abrangem todos os cenários.
Quando a política de acesso condicional ou as alterações de associação de grupo precisam ser aplicadas imediatamente a determinados usuários, você tem duas opções.
- Executar o comando do PowerShell revoke-mgusersign para revogar todos os tokens de atualização de um usuário especificado.
- Selecione "Revogar sessão" na página de perfil do usuário no portal do Azure para revogar a sessão do usuário e garantir que as políticas atualizadas serão aplicadas imediatamente.
Variação de endereço IP
O provedor de identidade e os provedores de recursos podem ver endereços IP diferentes. Essa incompatibilidade pode acontecer por causa de:
- Implementações de proxy de rede em sua organização
- Configurações incorretas de IPv4/IPv6 entre o provedor de identidade e o provedor de recursos
Exemplos:
- Seu provedor de identidade vê um endereço IP do cliente enquanto o provedor de recursos vê outro endereço IP do cliente depois de passar por um proxy.
- O endereço IP que seu provedor de identidade vê faz parte de um intervalo de IP permitido na política, mas o endereço IP do provedor de recursos não.
Para evitar loops infinitos por causa desses cenários, o Azure AD emite um token da CAE de uma hora e não impõe a alteração da localização do cliente. Nesse caso, a segurança é melhorada em comparação com os tradicionais tokens de uma hora, pois ainda estamos avaliando os outros eventos, além dos eventos de alteração da localização do cliente.
Políticas de localização compatíveis
A CAE só tem insight sobre localizações nomeadas baseadas no IP. A CAE não tem informações sobre outras condições de localização, como IPs confiáveis de MFA ou localizações baseadas em países. Quando o usuário vier de um IP confiável de MFA, localização confiável que inclui IPs confiáveis de MFA ou localização de países, a CAE não será imposta depois que o usuário se mudar para uma localização diferente. Nesses casos, o Azure AD emitirá um token de acesso de uma hora sem verificação instantânea de imposição de IP.
Importante
Se você deseja que suas políticas de localização sejam aplicadas em tempo real por avaliação de acesso contínua, use apenas a Condição de localização de acesso condicional baseada em IP e configure todos os endereços IP, incluindo IPv4 e IPv6, que podem ser vistos pelo provedor de identidade e provedor de recursos. Não use as condições de localização de país ou o recurso de IPs confiáveis que estão disponíveis na página de configurações do serviço de Autenticação multifator do Azure AD.
Limitações de localização nomeada
Quando a soma de todos os intervalos de IP especificados nas políticas de localização excede 5.000, o fluxo de local de alteração do usuário não será imposto por CAE em tempo real. Nesse caso, o Azure AD emitirá um token CAE de uma hora. A CAE continuará a impor todos os outros eventos e políticas, além dos eventos de alteração de local do cliente. Com essa alteração, você ainda mantém uma postura de segurança mais forte em comparação aos tokens de uma hora tradicionais, já que outros eventos serão avaliados quase em tempo real.
Configurações do Office e do Web Account Manager
| Canal de atualizações do Office | DisableADALatopWAMOverride | DisableAADWAM |
|---|---|---|
| Canal Empresarial Semestral | Se definido como habilitado ou 1, não haverá compatibilidade com a CAE. | Se definido como habilitado ou 1, não haverá compatibilidade com a CAE. |
| Canal Atual ou Canal Empresarial Mensal |
Há compatibilidade com a CAE independentemente da configuração | Há compatibilidade com a CAE independentemente da configuração |
Para obter uma explicação sobre os canais de atualizações do Office, consulte Visão geral dos canais de atualizações para aplicativos Microsoft 365. Recomenda-se que as organizações não desabilitem o Gerenciador de contas da Web (WAM).
Coautoria em aplicativos do Office
Quando vários usuários estão colaborando em um documento ao mesmo tempo, o acesso deles ao documento pode não ser revogado imediatamente pela CAE com base nos eventos de alteração de política. Nesse caso, o usuário perde o acesso completamente após:
- fechar o documento
- fechar o aplicativo do Office
- Após uma hora, quando uma política de IP de acesso condicional é definida
Para reduzir ainda mais esse tempo, um administrador do SharePoint pode reduzir o tempo de vida máximo das sessões de coautoria para os documentos armazenados no SharePoint Online e no OneDrive for Business configurando uma política de local de rede no SharePoint Online. Depois que essa configuração for alterada, o tempo de vida máximo das sessões de coautoria será reduzido para 15 minutos e poderá ser ajustado ainda mais usando o comando "Set-SPOTenant –IPAddressWACTokenLifetime" do PowerShell do SharePoint Online.
Habilitar depois que um usuário for desabilitado
Se você habilitar um usuário logo após a desabilitação, haverá latência antes que a conta seja reconhecida como habilitada nos serviços downstream da Microsoft.
- O SharePoint Online e o Teams geralmente têm um atraso de 15 minutos.
- O Exchange Online geralmente tem um atraso de 35-40 minutos.
Notificações por push
Uma política de endereço IP não é avaliada antes que as notificações por push sejam liberadas. Esse cenário existe porque as notificações por push são de saída e não têm um endereço IP associado a ser avaliado. Se um usuário clicar nessa notificação por push, por exemplo, um email no Outlook, as políticas de endereço IP da CAE ainda serão impostas antes que o email possa ser exibido. As notificações por push exibem uma pré-visualização da mensagem que não está protegida por uma política de endereço IP. Todas as outras verificações da CAE são feitas antes do envio da notificação por push. Se um usuário ou dispositivo tiver seu acesso removido, a imposição ocorrerá dentro do período documentado.
Perguntas frequentes
Como a CAE funcionará com a frequência de entrada?
A frequência de entrada será respeitada com ou sem CAE.