Compartilhar via

Criar uma estratégia de gerenciamento de controle de acesso resiliente com o Microsoft Entra ID

  • Artigo

Observação

As informações contidas neste documento representam a visão atual da Microsoft Corporation acerca das questões discutidas até a data da publicação. Como a Microsoft deve reagir às dinâmicas condições do mercado, essas informações não devem ser interpretadas como um compromisso por parte da Microsoft, e a Microsoft não pode garantir a precisão de qualquer informação apresentada após a data de publicação.

As organizações que confiam em um controle de acesso único, como a autenticação multifator ou um único local de rede, para proteger seus sistemas de TI, estão suscetíveis a falhas de acesso aos seus aplicativos e recursos se esse controle de acesso único ficar indisponível ou for configurado incorretamente. Por exemplo, um desastre natural pode resultar em indisponibilidade de grandes segmentos de infraestrutura de telecomunicações ou de redes corporativas. Um interrupção dessa natureza pode impedir que os usuários finais e administradores sejam capazes de entrar.

Este documento fornece diretrizes sobre as estratégias que uma organização deve adotar para fornecer resiliência, visando reduzir o risco de bloqueio durante interrupções imprevistas com os cenários a seguir:

  • As organizações podem aumentar a resiliência para reduzir o risco de bloqueio antes de uma interrupção, implementando estratégias de mitigação ou planos de contingência.
  • As organizações podem continuar a acessar a aplicativos e recursos que escolherem durante uma interrupção, dispondo de estratégias de mitigação e planos de contingência em vigor.
  • As organizações devem garantir a preservação das informações, como logs, após uma interrupção e antes de reverter quaisquer contingências implementadas.
  • As organizações que ainda não implementaram estratégias de prevenção ou planos alternativos podem ser capazes de implementar opções de emergência para lidar com a interrupção.

Diretrizes principais

Há quatro observações principais neste documento:

  • Evite o bloqueio do administrador usando contas de acesso de emergência.
  • Implemente o MFA usando o acesso condicional em vez da MFA por usuário.
  • Mitigue o bloqueio do usuário usando vários controles de acesso condicional.
  • Reduza o bloqueio do usuário provisionando vários métodos de autenticação ou equivalentes para cada usuário.

Antes de uma interrupção

Mitigar uma interrupção real deve ser o foco primário de uma organização ao lidar com problemas de controle de acesso que podem surgir. A mitigação inclui planejamento para um evento real, além de implementar estratégias para garantir que as operações e os controles de acesso não sejam afetados durante as interrupções.

Por que é necessário um controle de acesso resiliente?

Identidade é o plano de controle dos usuários que acessam aplicativos e recursos. O sistema de identidade controla quais usuários e em quais condições, como requisitos de autenticação ou controles de acesso, os usuários obtêm acesso aos aplicativos. Quando um ou mais requisitos de controle de acesso ou autenticação não estão disponíveis para autenticação dos usuários devido a circunstâncias imprevistas, as organizações podem enfrentar um dos problemas a seguir, ou ambos:

  • Bloqueio do administrador: Os administradores não podem gerenciar o locatário ou serviços.
  • Bloqueio do usuário: Os usuários não podem acessar aplicativos ou recursos.

Contingência de bloqueio de administrador

A Microsoft recomenda que as organizações tenham duas contas de acesso de emergência somente na nuvem atribuídas permanentemente à função Administrador Global. Essas contas são altamente privilegiadas e não são atribuídas a indivíduos específicos. As contas são limitadas a cenários de emergência ou de "acesso de emergência" em que as contas normais não podem ser usadas ou em que todos os outros administradores estão acidentalmente bloqueados. Essas contas devem ser criadas de acordo com as recomendações para as contas de acesso de emergência.

Mitigar bloqueio do usuário

Para mitigar o risco de bloqueio do usuário, use políticas de acesso condicional com vários controles para dar aos usuários uma escolha de como eles acessam aplicativos e recursos. Permitir que um usuário escolha entre, por exemplo, entrar com MFA ou entrar a partir de um dispositivo gerenciado ou entrar a partir da rede corporativa, se um dos controles de acesso não estiver disponível, proporciona ao usuário outras opções para continuar a trabalhar.

Recomendações da Microsoft

Incorpore os seguintes controles de acesso nas políticas de acesso condicional existentes da organização:

  • Provisione vários métodos de autenticação para cada usuário que dependa de canais de comunicação diferentes, por exemplo, o aplicativo Microsoft Authenticator (baseado na internet), token OATH (gerado no dispositivo) e SMS (telefônico).
  • Implante o Windows Hello para Empresas em dispositivos Windows 10 para atender aos requisitos de MFA diretamente do logon de dispositivo.
  • Use dispositivos confiáveis por meio do Ingresso híbrido do Microsoft Entra ou do Microsoft Intune. Dispositivos confiáveis melhoram a experiência do usuário porque o próprio dispositivo confiável pode atender aos requisitos de autenticação forte de política sem um desafio MFA para o usuário. Em seguida, a MFA será necessária ao registrar um novo dispositivo e ao acessar a aplicativos ou recursos de dispositivos não confiáveis.
  • Use políticas baseadas em risco do Microsoft Entra ID Protection que impedem o acesso quando o usuário ou a entrada estiverem em risco no lugar de políticas fixas de MFA.
  • Se você estiver protegendo o acesso de VPN usando a extensão NPS da autenticação multifator do Microsoft Entra, considere a possibilidade de federar sua solução de VPN como um aplicativo SAML e determinar a categoria do aplicativo conforme recomendado abaixo.

Observação

As políticas baseadas em risco exigem licenças do Microsoft Entra ID P2.

O exemplo a seguir descreve as políticas que você deve criar para fornecer um controle de acesso resiliente para que o usuário acesse os aplicativos e recursos deles. Neste exemplo, será necessário um grupo de segurança AppUsers com os usuários de destino para os quais você quer conceder acesso, um grupo nomeado CoreAdmins com os administradores principais e um grupo chamado EmergencyAccess com as contas de acesso de emergência. Este conjunto de políticas de exemplo concederá aos usuários selecionados no AppUsers acesso aos aplicativos selecionados se eles estiverem conectando por meio de um dispositivo confiável OU fornecerá autenticação forte, por exemplo, MFA. Isso exclui contas de emergência e administradores principais.

Conjunto de políticas de mitigação de acesso condicional definidas:

  • Política 1: Bloquear o acesso a pessoas fora dos grupos de destino
    • Usuários e grupos: inclua todos os usuários. Excluir AppUsers, CoreAdmins, e EmergencyAccess
    • Aplicativos de nuvem: incluir todos os aplicativos
    • Condições: (nenhuma)
    • Controle de concessão: bloco
  • Política 2: conceder acesso a AppUsers exigindo MFA OU dispositivo confiável.
    • Usuários e grupos: incluir AppUsers. Excluir CoreAdmins e EmergencyAccess
    • Aplicativos de nuvem: incluir todos os aplicativos
    • Condições: (nenhuma)
    • Controle de concessão: conceder acesso, exigir a autenticação multifator, exigir que o dispositivo esteja em conformidade. Para vários controles: requerer um dos controles selecionados.

Contingências para bloqueio do usuário

Como alternativa, sua organização também pode criar políticas de contingência. Para criar políticas de contingência, é necessário definir critérios de compensação entre continuidade dos negócios, custos operacionais, custo financeiro e riscos de segurança. Por exemplo, você poderá ativar uma política de contingência apenas para um subconjunto de usuários, um subconjunto de aplicativos, um subconjunto de clientes, ou a partir de um subconjunto dos locais. Políticas de contingência concedem aos administradores e usuários finais acesso a aplicativos e recursos durante uma interrupção quando nenhum método de mitigação foi implementado. A Microsoft recomenda a habilitação de políticas de contingência no modo somente de relatório quando não estiver em uso para que os administradores possam monitorar o impacto potencial das políticas, caso precisem ser ativadas.

Reconhecer sua exposição durante uma interrupção ajuda a reduzir o risco e é uma parte crítica do processo de planejamento. Para criar o plano de contingência, primeiro determine os seguintes requisitos de negócios da sua organização:

  1. Determinar seus aplicativos de missão crítica antecipadamente: quais são os aplicativos aos quais você deve conceder acesso, mesmo com uma postura de risco/segurança menor? Crie uma lista desses aplicativos e certifique-se de que todos os outros stakeholders (lideranças jurídicas, de negócios e segurança) concordam que se todos os controle de acesso forem perdidos, esses aplicativos ainda devem continuar em execução. Isso provavelmente resultará nas seguintes categorias:
    • Categoria 1 - aplicativos críticos que não podem permanecer indisponíveis por mais de alguns minutos, por exemplo, aplicativos que afetam diretamente a receita da organização.
    • Categoria 2 - aplicativos importantes que a empresa precisa que estejam acessíveis em algumas horas.
    • Categoria 3 - aplicativos de baixa prioridade que podem resistir a uma interrupção de alguns dias.
  2. Para aplicativos na categoria 1 e 2, a Microsoft recomenda que você planeje previamente que tipo de nível de acesso você deseja permitir:
    • Você quer permitir acesso completo ou sessão restrita, como limitar downloads?
    • Você quer permitir o acesso a parte do aplicativo, mas não ao aplicativo inteiro?
    • Você quer permitir o acesso de trabalhador de informações e bloquear o acesso de administrador até que o controle de acesso seja restaurado?
  3. Para esses aplicativos, a Microsoft também recomenda planejar quais caminhos de acesso você deliberadamente abrirá e quais deles fechará:
    • Você quer permitir acesso somente para navegador e bloquear clientes avançados que podem salvar os dados offline?
    • Você quer permitir acesso somente para usuários dentro da rede corporativa e manter os usuários de fora bloqueados?
    • Você quer permitir o acesso de certos países ou regiões somente durante a interrupção?
    • Você quer que as políticas para as políticas de contingência, especialmente para aplicativos críticos, falhem ou tenham êxito se um controle de acesso alternativo não estiver disponível?

Recomendações da Microsoft

Uma política de Acesso Condicional de contingência é uma política de backup que omite controles com base em risco ou com base em dispositivo, MFA de terceiros e autenticação multifator do Microsoft Entra. Para minimizar a interrupção inesperada quando uma política de contingência estiver habilitada, a política deverá permanecer no modo somente de relatório quando não estiver em uso. Os administradores podem monitorar o impacto potencial de suas políticas de contingência usando a pasta de trabalho de Insights de Acesso Condicional. Quando sua organização decidir ativar seu plano de contingência, os administradores poderão habilitar a política e desabilitar as políticas comuns baseadas em controle.

Importante

Desabilitar políticas que impõem segurança nos usuários, mesmo temporariamente, reduzirá a postura de segurança enquanto o plano de contingência estiver vigente.

  • Configure um conjunto de políticas de fallback se uma interrupção em um mecanismo de controle de acesso ou um tipo de credencial afete o acesso aos seus aplicativos. Configure uma política em um estado somente relatório que requer ingresso no domínio como um controle, como um backup para uma política ativa que requer um provedor MFA de terceiros.
  • Reduza o risco de atores maliciosos detectarem senhas, quando a MFA não é necessária, seguindo as práticas no white paper sobre diretrizes de senha.
  • Implante a Redefinição de Senha de Autoatendimento (SSPR) do Microsoft Entra e a Proteção de Senha do Microsoft Entra para certificar-se de que os usuários não usem uma senha comum e os termos que você quer vetar.
  • Use as políticas que restringem o acesso dentro dos aplicativos se um determinado nível de autenticação não for atingido, em vez de simplesmente fazer fallback para acesso completo. Por exemplo:
    • Configure uma política de backup que envia a declaração de sessão restrita para Exchange e SharePoint.
    • Se sua organização usa o Microsoft Defender para Aplicativos de Nuvem, considere fazer fallback para uma política que envolve o Defender para Aplicativos de Nuvem e, então, permita acesso somente leitura, mas não uploads.
  • Dê um nome às suas políticas para garantir que seja fácil encontrá-las durante uma interrupção. Inclua os seguintes elementos no nome da política:
    • Um número de rótulo para a política.
    • Texto a ser exibido, essa política é somente para emergências. Por exemplo: ENABLE IN EMERGENCY
    • A interrupção à qual ela se aplica. Por exemplo: Durante a interrupção do MFA
    • Um número de sequência para mostrar a ordem em que você deve ativar as políticas.
    • Os aplicativos aos quais ela se aplica.
    • Os controles aos quais ela se aplica.
    • As condições às quais ela se aplica.

Esse padrão de nomenclatura para as políticas de contingência é o seguinte:

EMnnn - ENABLE IN EMERGENCY: [Disruption][i/n] - [Apps] - [Controls] [Conditions]

O exemplo a seguir: Exemplo A - Política de Contingência de Acesso para restaurar o acesso aos aplicativos de colaboração críticos, é uma contingência corporativa típica. Nesse cenário, a organização normalmente requer MFA para todos os acessos do Exchange Online e SharePoint Online e a interrupção nesse caso se dá porque o provedor de MFA do cliente tem uma interrupção (quer seja a MFA do Microsoft Entra, provedor de MFA local ou a MFA de terceiros). Essa política mitiga essa interrupção, permitindo que os usuários de destino específicos acessem esses aplicativos em dispositivos confiáveis do Windows somente quando eles estão acessando o aplicativo a partir da rede corporativa confiável deles. Ela também exclui contas de emergência e administradores principais nessas restrições. Assim, os usuários de destino terão acesso ao Exchange Online e ao SharePoint Online, enquanto outros usuários ainda não terão acesso a aplicativos devido à interrupção. Este exemplo exige um local de rede nomeado CorpNetwork e um grupo de segurança ContingencyAccess com os usuários de destino, um grupo nomeado CoreAdmins com os administradores principais e um grupo nomeado EmergencyAccess com as contas de acesso de emergência. A contingência requer quatro políticas para fornecer o acesso exigido.

Exemplo A - políticas de CA de contingência para restaurar o acesso aos aplicativos de colaboração críticos:

  • Política 1: Exigir dispositivos ingressados no domínio para Exchange e SharePoint
    • Nome: EM001 - HABILITAR EM CASO DE EMERGÊNCIA: Interrupção do MFA [1/4] - Exchange SharePoint - Exigir ingresso híbrido do Microsoft Entra
    • Usuários e grupos: inclua ContingencyAccess. Excluir CoreAdmins e EmergencyAccess
    • Exchange Online e SharePoint Online
    • Condições: quaisquer
    • Controle de concessão: exigir ingresso no domínio
    • Estado: somente relatório
  • Política 2: Bloquear as plataformas que não sejam Windows
    • Nome: EM002-ENABLE IN EMERGENCY: interrupção do MFA[2/4] - Exchange SharePoint - bloquear acesso, exceto Windows
    • Usuários e grupos: inclua todos os usuários. Excluir CoreAdmins e EmergencyAccess
    • Exchange Online e SharePoint Online
    • Condições: Plataforma de dispositivo inclui todas as plataformas, excluir Windows
    • Controle de concessão: bloco
    • Estado: somente relatório
  • Política 3: Bloquear redes que não sejam CorpNetwork
    • Nome: EM003-ENABLE IN EMERGENCY: interrupção do MFA[3/4] - Exchange SharePoint - bloquear acesso, exceto rede corporativa
    • Usuários e grupos: inclua todos os usuários. Excluir CoreAdmins e EmergencyAccess
    • Exchange Online e SharePoint Online
    • Condições: locais incluem qualquer local, excluir CorpNetwork
    • Controle de concessão: bloco
    • Estado: somente relatório
  • Política 4: bloquear EAS explicitamente
    • Nome: EM004-habilitar em emergência: interrupção do MFA [4/4]-Exchange - bloquear EAS para todos os usuários
    • Usuários e grupos: incluir todos os usuários
    • Aplicativos de nuvem: incluir o Exchange Online
    • Condições: Aplicativos cliente: Exchange Active Sync
    • Controle de concessão: bloco
    • Estado: somente relatório

Ordem de ativação:

  1. Exclua ContingencyAccess, CoreAdmins e EmergencyAccess da política de MFA existente. Verifique se um usuário em ContingencyAccess pode acessar o SharePoint Online e o Exchange Online.
  2. Habilite a Política 1: Verifique se os usuários em dispositivos ingressados no domínio que não estão nos grupos de exclusão são capazes de acessar o Exchange Online e o SharePoint Online. Verifique se os usuários no grupo de exclusão podem acessar o SharePoint Online e Exchange de qualquer dispositivo.
  3. Habilite a Política 2: Verifique se os usuários que não estão no grupo de exclusão não podem acessar o SharePoint Online e o Exchange Online de seus dispositivos móveis. Verifique se os usuários no grupo de exclusão podem acessar o SharePoint e o Exchange de qualquer dispositivo (Windows/iOS/Android).
  4. Habilite a Política 3: Verifique se os usuários que não estão nos grupos de exclusão não podem acessar o SharePoint e o Exchange fora da rede corporativa, mesmo com uma máquina ingressada no domínio. Verifique se os usuários no grupo de exclusão podem acessar o SharePoint e o Exchange de qualquer rede.
  5. Habilite a Política 4: Verifique se todos os usuários não podem acessar o Exchange Online de aplicativos de email nativo em dispositivos móveis.
  6. Desabilite a política MFA existente para o SharePoint Online e o Exchange Online.

Neste exemplo, Exemplo B - políticas de acesso condicional de contingência para permitir o acesso móvel à Salesforce, o acesso de um aplicativo de negócios é restaurado. Nesse cenário, o cliente normalmente exige que seus funcionários de vendas acessem o Salesforce (configurado para logon único com o Microsoft Entra ID) a partir de dispositivos móveis para serem permitidos apenas em dispositivos compatíveis. A interrupção nesse caso é que há um problema com a avaliação da conformidade do dispositivo e a interrupção está acontecendo durante um período sensível em que a equipe de vendas precisa de acesso à Salesforce para fechar negócios. Essas políticas de contingência concederão aos usuários críticos o acesso à Salesforce a partir de um dispositivo móvel para possibilitar que eles continuem a fechar negócios e não interrompam os negócios. Neste exemplo, SalesforceContingency contém todos os funcionários de vendas que precisam manter o acesso e SalesAdmins contém os administradores necessários da Salesforce.

Exemplo B - políticas de acesso condicional de contingência:

  • Política 1: bloquear todos que não estejam na equipe do SalesContingency
    • Nome: EM001-ENABLE IN EMERGENCY: interrupção de conformidade do dispositivo [1/2] - Salesforce - bloquear todos os usuários, exceto SalesforceContingency
    • Usuários e grupos: inclua todos os usuários. Excluir SalesAdmins e SalesforceContingency
    • Aplicativos de nuvem: Salesforce.
    • Condições: nenhuma
    • Controle de concessão: bloco
    • Estado: somente relatório
  • Política 2: Bloquear a equipe de vendas de qualquer plataforma que não seja móvel (para reduzir a área da superfície do ataque)
    • Nome: EM002 - ENABLE IN EMERGENCY: interrupção de conformidade do dispositivo [2/2] - Salesforce - bloquear todas as plataformas, exceto iOS e Android
    • Usuários e grupos: inclua SalesforceContingency. Excluir SalesAdmins
    • Aplicativos de nuvem: Salesforce
    • Condições: Plataforma de dispositivo inclui todas as plataformas, excluir iOS e Android
    • Controle de concessão: bloco
    • Estado: somente relatório

Ordem de ativação:

  1. Exclua SalesAdmins e SalesforceContingency da política de conformidade de dispositivo existente para a Salesforce. Verifique se um usuário do grupo SalesforceContingency pode acessar a Salesforce.
  2. Habilitar a Política 1: Verifique se os usuários fora de SalesContingency não podem acessar a Salesforce. Verifique se os usuários em SalesAdmins e SalesforceContingency podem acessar a Salesforce.
  3. Habilite a política 2: Verifique se os usuários no grupo de SalesContingency não podem acessar a Salesforce dos laptops Windows/Mac deles, mas ainda podem acessar dos dispositivos móveis deles. Verifique se SalesAdmin ainda pode acessar a Salesforce de qualquer dispositivo.
  4. Desabilite a política de conformidade do dispositivo existente para a Salesforce.

Contingências para bloqueio de usuário de recursos locais (extensão NPS)

Se você estiver protegendo o acesso de VPN usando a extensão NPS da autenticação multifator do Microsoft Entra, considere a possibilidade de federar sua solução de VPN como um aplicativo SAML e determinar a categoria do aplicativo conforme recomendado abaixo.

Se você tiver implantado a extensão NPS da autenticação multifator do Microsoft Entra para proteger recursos locais, como VPN e Gateway de Área de Trabalho Remota, com a MFA, é importante considerar com antecedência se você está preparado para desabilitar a MFA em um caso de emergência.

Nesse caso, você pode desabilitar a extensão NPS. Como resultado, o servidor NPS verificará somente a autenticação primária e não imporá a MFA aos usuários.

Desabilitar extensão NPS:

  • Exporte a chave do registro HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AuthSrv\Parameters como um backup.
  • Exclua os valores de registro para "AuthorizationDLLs" e "ExtensionDLLs", não para a chave de parâmetros.
  • Reinicie o serviço de serviço de diretiva de rede (IAS) para que as alterações entrem em vigor
  • Determine se a autenticação primária para VPN foi bem-sucedida.

Depois que o serviço for recuperado e você estiver pronto para impor o MFA aos usuários novamente, habilite a extensão do NPS:

  • Importar a chave do registro do backup HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AuthSrv\Parameters
  • Reinicie o serviço de serviço de diretiva de rede (IAS) para que as alterações entrem em vigor
  • Determine se a autenticação primária, bem como a autenticação secundária para VPN, foi bem-sucedida.
  • Examine o servidor NPS e o log de VPN para determinar quais usuários entraram durante a janela de emergência.

Implantar sincronização de hash de senha, mesmo se você for federado ou usar a autenticação de passagem

O bloqueio do usuário também pode ocorrer se as condições a seguir forem verdadeiras:

  • Sua organização usa uma solução de identidade híbrida com autenticação de passagem ou federação.
  • Seus sistemas de identidade locais (como o Active Directory, AD FS ou um componente dependente) não estão disponíveis.

Para ser mais resiliente, sua organização deve habilitar a sincronização de hash de senha, pois ela permite mudar para usar a sincronização de hash de senha se os sistemas de identidade locais estiverem inoperantes.

Recomendações da Microsoft

Habilite a sincronização de hash de senha usando o assistente do Microsoft Entra Connect, independentemente se sua organização usa a autenticação de passagem ou de federação.

Importante

Não é necessário converter os usuários de autenticação federada para gerenciada para usar a sincronização de hash de senha.

Durante uma interrupção

Se você optou por implementar um plano de mitigação, poderá sobreviver automaticamente a uma interrupção de controle de acesso único. No entanto, se você optou por criar um plano de contingência, poderá ativar suas políticas de contingência durante a interrupção de controle de acesso:

  1. Habilite as políticas de contingência que concedam a usuários de destino o acesso a aplicativos específicos, a partir de redes específicas.
  2. Desabilite as políticas com base em controle regulares.

Recomendações da Microsoft

Dependendo de quais mitigações ou contingências são usadas durante uma interrupção, sua organização pode estar concedendo acesso com apenas senhas. Nenhuma garantia é um risco de segurança considerável que deve ser avaliado com cuidado. Organizações devem:

  1. Como parte da sua estratégia de controle de alterações, documente todas as alterações e o estado anterior para poder reverter quaisquer contingências implementadas, tão logo os controles de acesso estejam totalmente operacionais.
  2. Suponha que atores mal-intencionados tentarão coletar senhas por meio de ataques de pulverização de senha ou de phishing enquanto você tiver desabilitado a MFA. Além disso, os atores maliciosos podem já ter senhas que anteriormente não concediam acesso a qualquer recurso que podem ser tentadas durante essa janela. Para usuários críticos como executivos, você pode mitigar parcialmente esse risco, redefinindo as senhas deles antes de desabilitar a MFA para eles.
  3. Arquive todas as atividades de entrada para identificar quem acessa o que durante o tempo em que MFA estava desabilitada.
  4. Triagem de todos os eventos de risco relatados durante essa janela.

Após uma interrupção

Desfaça as alterações feitas como parte do plano de contingência ativado quando for restaurado o serviço que causou a interrupção.

  1. Habilitar as políticas regulares
  2. Desabilite suas políticas de contingência de volta para o modo somente de relatório.
  3. Reverta todas as outras alterações feitas e documentadas durante a interrupção.
  4. Se você usou uma conta de acesso de emergência, lembre-se de regenerar as credenciais e proteger fisicamente os detalhes das novas credenciais como parte dos procedimentos de conta de acesso de emergência.
  5. Continue a Triagem de todos os eventos de risco relatados após a interrupção por atividade suspeita.
  6. Revogue todos os tokens de atualização que foram emitidos visando um conjunto de usuários. A revogação de todos os tokens de atualização é importante para contas com privilégios usadas durante a interrupção e fazer isso as forçará a autenticarem-se novamente e cumprirem o controle das políticas restauradas.

Opções de emergência

No caso de uma emergência, se sua organização não implementou previamente um plano de contingência ou mitigação, siga as recomendações na seção Contingências para bloqueio do usuário se eles já usam políticas de acesso condicional para impor a MFA. Se sua organização estiver usando políticas herdadas de MFA por usuário, você pode considerar a seguinte alternativa:

  • Se você tiver o endereço IP de saída de rede corporativa, é possível adicioná-las como IPs confiáveis para habilitar a autenticação somente para a rede corporativa.
  • Se você não tem o inventário de endereços IP de saída ou se precisa habilitar o acesso dentro e fora da rede corporativa, é possível adicionar todo o espaço de endereços IPv4 como IPs confiáveis especificando 0.0.0.0/1 e 128.0.0.0/1.

Importante

Se você expandir os endereços IP confiáveis para desbloquear o acesso, detecções de risco associadas a endereços IP (por exemplo, viagem impossível ou localizações desconhecidas) não serão geradas.

Observação

A configuração de IPs confiáveis para autenticação multifator do Microsoft Entra só está disponível com licenças do Microsoft Entra P1 ou P2.

Saiba mais