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

  • Artigo

Nota

As informações contidas neste documento representam a visão atual da Microsoft Corporation sobre os assuntos discutidos a partir da data de publicação. Como a Microsoft deve responder às mudanças nas condições de mercado, isso não deve ser interpretado 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 dependem de um único controle de acesso, como autenticação multifator ou um único local de rede, para proteger seus sistemas de TI estão suscetíveis a falhas de acesso a seus aplicativos e recursos se esse controle de acesso único ficar indisponível ou configurado incorretamente. Por exemplo, um desastre natural pode resultar na indisponibilidade de grandes segmentos de infraestrutura de telecomunicações ou redes corporativas. Essa interrupção pode impedir que usuários finais e administradores possam entrar.

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

  • As organizações podem aumentar sua 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 aplicativos e recursos que escolherem durante uma interrupção, tendo estratégias de mitigação e planos de contingência em vigor.
  • As organizações devem certificar-se de que preservam informações, como logs, após uma interrupção e antes de reverter quaisquer contingências que implementaram.
  • As organizações que 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.

Principais orientações

Há quatro conclusões principais neste documento:

  • Evite o bloqueio do administrador usando contas de acesso de emergência.
  • Implemente MFA usando Acesso Condicional em vez de MFA por usuário.
  • Reduza 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 principal de uma organização ao lidar com problemas de controle de acesso que possam surgir. A mitigação inclui o planejamento de um evento real e a implementação de estratégias para garantir que os controles de acesso e as operações não sejam afetados durante interrupções.

Por que você precisa de um controle de acesso resiliente?

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

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

Contingência de bloqueio do administrador

Para desbloquear o acesso de administrador ao seu inquilino, deve criar contas de acesso de emergência. Essas contas de acesso de emergência, também conhecidas como contas de vidro quebrado, permitem o acesso para gerenciar a configuração do Microsoft Entra quando os procedimentos normais de acesso a contas privilegiadas não estão disponíveis. Pelo menos duas contas de acesso de emergência devem ser criadas seguindo as recomendações de conta de acesso de emergência.

Atenuando o bloqueio do usuário

Para reduzir 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. Ao dar a um utilizador a escolha entre, por exemplo, iniciar sessão com MFA ou iniciar sessão a partir de um dispositivo gerido ou iniciar sessão a partir da rede empresarial, se um dos controlos de acesso não estiver disponível, o utilizador tem outras opções para continuar a trabalhar.

Recomendações da Microsoft

Incorpore os seguintes controles de acesso em suas políticas de Acesso Condicional existentes para a organização:

  • Provisione vários métodos de autenticação para cada usuário que dependem de diferentes canais de comunicação, por exemplo, o aplicativo Microsoft Authenticator (baseado na Internet), token OATH (gerado no dispositivo) e SMS (telefônico).
  • Implante o Windows Hello for Business em dispositivos Windows 10 para atender aos requisitos de MFA diretamente do login do dispositivo.
  • Utilize dispositivos fidedignos através do Microsoft Entra hybrid join ou do Microsoft Intune. Os dispositivos confiáveis melhoram a experiência do usuário porque o próprio dispositivo confiável pode satisfazer os requisitos de autenticação forte da política sem um desafio de MFA para o usuário. A MFA será então necessária ao registrar um novo dispositivo e ao acessar aplicativos ou recursos de dispositivos não confiáveis.
  • Use políticas baseadas em risco da Proteção de ID do Microsoft Entra que impedem o acesso quando o usuário ou entrada está em risco no lugar de políticas de MFA fixas.
  • Se você estiver protegendo o acesso VPN usando a extensão NPS de autenticação multifator do Microsoft Entra, considere federar sua solução VPN como um aplicativo SAML e determinar a categoria do aplicativo conforme recomendado abaixo.

Nota

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

O exemplo a seguir descreve as políticas que você deve criar para fornecer um controle de acesso resiliente para o usuário acessar seus aplicativos e recursos. Neste exemplo, você precisa de um grupo de segurança AppUsers com os usuários de destino aos quais você deseja conceder acesso, um grupo chamado 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 em AppUsers, acesso a aplicativos selecionados se eles estiverem se conectando a partir de um dispositivo confiável OU fornecer autenticação forte, por exemplo, MFA. Exclui contas de emergência e administradores principais.

Conjunto de políticas de mitigação de Acesso Condicional:

  • Política 1: Bloquear o acesso a pessoas fora dos grupos-alvo
    • Usuários e grupos: incluem todos os usuários. Excluir AppUsers, CoreAdmins e EmergencyAccess
    • Aplicações na nuvem: inclua todas as aplicações
    • Condições: (Nenhum)
    • Controle de concessão: Bloco
  • Política 2: Conceda acesso a AppUsers que exijam MFA OU dispositivo confiável.
    • Usuários e grupos: inclua AppUsers. Excluir CoreAdmins e EmergencyAccess
    • Aplicações na nuvem: inclua todas as aplicações
    • Condições: (Nenhum)
    • Controle de concessão: conceda acesso, exija autenticação multifator, exija que o dispositivo esteja em conformidade. Para vários controles: Requer um dos controles selecionados.

Contingências para bloqueio de usuário

Como alternativa, sua organização também pode criar políticas de contingência. Para criar políticas de contingência, você deve definir critérios de compensação entre continuidade de negócios, custo operacional, custo financeiro e riscos de segurança. Por exemplo, você pode ativar uma política de contingência apenas para um subconjunto de usuários, para um subconjunto de aplicativos, para um subconjunto de clientes ou de um subconjunto de locais. As políticas de contingência dão 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 habilitar as políticas de contingência no modo somente relatório quando não estiverem em uso, para que os administradores possam monitorar o impacto potencial das políticas caso precisem ser ativadas.

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

  1. Determine seus aplicativos de missão crítica com antecedência: Quais são os aplicativos aos quais você deve dar acesso, mesmo com uma postura de risco/segurança menor? Crie uma lista desses aplicativos e certifique-se de que suas outras partes interessadas (negócios, segurança, jurídico, liderança) concordem que, se todo o controle de acesso desaparecer, esses aplicativos ainda devem continuar a ser executados. Você provavelmente acabará com categorias de:
    • Aplicativos de missão crítica de categoria 1 que não podem ficar indisponíveis por mais do que alguns minutos, por exemplo, aplicativos que afetam diretamente a receita da organização.
    • Categoria 2 aplicativos importantes que a empresa precisa estar acessível dentro de algumas horas.
    • Aplicativos de baixa prioridade de categoria 3 que podem suportar uma interrupção de alguns dias.
  2. Para aplicativos nas categorias 1 e 2, a Microsoft recomenda que você planeje previamente o tipo de nível de acesso que deseja permitir:
    • Deseja permitir acesso total ou sessão restrita, como limitar downloads?
    • Deseja permitir o acesso a parte do aplicativo, mas não ao aplicativo inteiro?
    • Deseja permitir o acesso do operador de informações e bloquear o acesso do administrador até que o controle de acesso seja restaurado?
  3. Para esses aplicativos, a Microsoft também recomenda que você planeje quais vias de acesso você abrirá deliberadamente e quais serão fechadas:
    • Deseja permitir o acesso apenas do navegador e bloquear clientes avançados que podem salvar dados offline?
    • Deseja permitir o acesso apenas para usuários dentro da rede corporativa e manter os usuários externos bloqueados?
    • Pretende permitir o acesso a partir de determinados países ou regiões apenas durante a interrupção?
    • Você deseja que as políticas de contingência, especialmente para aplicativos de missão crítica, falhem ou sejam bem-sucedidas 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 a autenticação multifator do Microsoft Entra, MFA de terceiros, controles baseados em risco ou baseados em dispositivo. Para minimizar interrupções inesperadas quando uma política de contingência está habilitada, a política deve permanecer no modo somente 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 Insights de Acesso Condicional. Quando sua organização decide ativar seu plano de contingência, os administradores podem habilitar a política e desabilitar as políticas regulares baseadas em controle.

Importante

A desativação de políticas que impõem segurança aos seus usuários, mesmo temporariamente, reduzirá sua postura de segurança enquanto o plano de contingência estiver em vigor.

  • Configure um conjunto de políticas de fallback se uma interrupção em um tipo de credencial ou um mecanismo de controle de acesso afetar o acesso aos seus aplicativos. Configure uma política no estado somente relatório que exija Ingresso no Domínio como um controle, como um backup para uma política ativa que requer um provedor de MFA de terceiros.
  • Reduza o risco de agentes mal-intencionados adivinharem senhas, quando a MFA não for necessária, seguindo as práticas no white paper de orientação de senhas.
  • Implante o Microsoft Entra Self-Service Password Reset (SSPR) e o Microsoft Entra Password Protection para garantir que os usuários não usem senhas e termos comuns que você optar por banir.
  • Use políticas que restrinjam o acesso dentro dos aplicativos se um determinado nível de autenticação não for atingido, em vez de simplesmente retornar ao acesso total. Por exemplo:
    • Configure uma política de backup que envie a declaração de sessão restrita para o Exchange e o SharePoint.
    • Se a sua organização usa o Microsoft Defender for Cloud Apps, considere voltar a adotar uma política que envolva o Defender for Cloud Apps e, em seguida, permita acesso somente leitura, mas não uploads.
  • Nomeie 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 para mostrar, esta política é apenas para emergências. Por exemplo: ATIVAR EM CASO DE EMERGÊNCIA
    • A perturbação a que se aplica. Por exemplo: Durante a interrupção da MFA
    • Um número de sequência para mostrar a ordem em que você deve ativar as políticas.
    • As aplicações às quais se aplica.
    • Os controlos que irá aplicar.
    • As condições que exige.

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 Acesso Condicional de Contingência para restaurar o Acesso a Aplicativos de Colaboração de missão crítica, é uma contingência corporativa típica. Nesse cenário, a organização normalmente requer MFA para todos os acessos do Exchange Online e do SharePoint Online, e a interrupção nesse caso é o provedor de MFA para o cliente tem uma interrupção (se a autenticação multifator Microsoft Entra, provedor de MFA local ou MFA de terceiros). Esta política atenua esta interrupção, permitindo que utilizadores específicos acedam a estas aplicações a partir de dispositivos Windows fidedignos apenas quando estão a aceder à aplicação a partir da sua rede empresarial fidedigna. Também excluirá contas de emergência e administradores principais dessas restrições. 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 aos aplicativos devido à interrupção. Este exemplo requer um local de rede nomeado CorpNetwork e um grupo de segurança ContingencyAccess com os usuários de destino, um grupo chamado CoreAdmins com os administradores principais e um grupo chamado EmergencyAccess com as contas de acesso de emergência. A contingência requer quatro políticas para fornecer o acesso desejado.

Exemplo A - Políticas de Acesso Condicional de Contingência para restaurar o Acesso a Aplicativos de Colaboração de missão crítica:

  • Política 1: Exigir dispositivos ingressados no domínio para Exchange e SharePoint
    • Nome: EM001 - ATIVAR EM CASO DE EMERGÊNCIA: MFA Disruption[1/4] - Exchange SharePoint - Exigir a junção híbrida do Microsoft Entra
    • Usuários e grupos: incluem ContingencyAccess. Excluir CoreAdmins e EmergencyAccess
    • Aplicativos na nuvem: Exchange Online e SharePoint Online
    • Condições: Qualquer
    • Controle de concessão: Exigir ingresso no domínio
    • Estado: Apenas relatório
  • Política 2: Bloquear plataformas diferentes do Windows
    • Nome: EM002 - ATIVAR EM CASO DE EMERGÊNCIA: MFA Disruption[2/4] - Exchange SharePoint - Bloquear acesso, exceto Windows
    • Usuários e grupos: incluem todos os usuários. Excluir CoreAdmins e EmergencyAccess
    • Aplicativos na nuvem: Exchange Online e SharePoint Online
    • Condições: A plataforma do dispositivo inclui todas as plataformas, exclui o Windows
    • Controle de concessão: Bloco
    • Estado: Apenas relatório
  • Política 3: Bloquear redes que não sejam CorpNetwork
    • Nome: EM003 - ATIVAR EM CASO DE EMERGÊNCIA: MFA Disruption[3/4] - Exchange SharePoint - Bloquear acesso, exceto Rede Corporativa
    • Usuários e grupos: incluem todos os usuários. Excluir CoreAdmins e EmergencyAccess
    • Aplicativos na nuvem: Exchange Online e SharePoint Online
    • Condições: Locais Incluem qualquer local, excluem CorpNetwork
    • Controle de concessão: Bloco
    • Estado: Apenas relatório
  • Política 4: Bloquear EAS explicitamente
    • Nome: EM004 - ATIVAR EM CASO DE EMERGÊNCIA: MFA Disruption[4/4] - Exchange - Bloquear EAS para todos os usuários
    • Usuários e grupos: incluir todos os usuários
    • Aplicativos na nuvem: inclua o Exchange Online
    • Condições: Aplicativos cliente: Exchange Ative Sync
    • Controle de concessão: Bloco
    • Estado: Apenas 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. Habilitar Política 1: verifique se os usuários em dispositivos ingressados no domínio que não estão nos grupos de exclusão podem acessar o Exchange Online e o SharePoint Online. Verifique se os usuários no grupo Excluir podem acessar o SharePoint Online e o Exchange de qualquer dispositivo.
  3. Habilitar 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 a partir de seus dispositivos móveis. Verifique se os usuários no grupo Excluir podem acessar o SharePoint e o Exchange de qualquer dispositivo (Windows/iOS/Android).
  4. Habilitar 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 associada a um domínio. Verifique se os usuários no grupo Excluir podem acessar o SharePoint e o Exchange de qualquer rede.
  5. Habilitar Política 4: verifique se todos os usuários não podem obter o Exchange Online dos aplicativos de email nativos em dispositivos móveis.
  6. Desabilite a política de MFA existente para o SharePoint Online e o Exchange Online.

Neste próximo exemplo, Exemplo B - Políticas de acesso condicional de contingência para permitir o acesso móvel ao 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 só ser permitido a partir de dispositivos compatíveis. A interrupção neste caso é que há um problema com a avaliação da conformidade do dispositivo e a interrupção está acontecendo em um momento sensível em que a equipe de vendas precisa acessar o Salesforce para fechar negócios. Essas políticas de contingência concedem aos usuários críticos acesso ao Salesforce a partir de um dispositivo móvel para que eles possam continuar a fechar negócios e não interromper os negócios. Neste exemplo, SalesforceContingency contém todos os funcionários de vendas que precisam manter o acesso e SalesAdmins contém administradores necessários do Salesforce.

Exemplo B - Políticas de Acesso Condicional de Contingência:

  • Política 1: Bloquear todos os que não fazem parte da equipe SalesContingency
    • Nome: EM001 - ATIVAR EM CASO DE EMERGÊNCIA: INTERRUPÇÃO DA CONFORMIDADE DO DISPOSITIVO[1/2] - Salesforce - Bloquear todos os usuários, exceto SalesforceContingency
    • Usuários e grupos: incluem todos os usuários. Excluir SalesAdmins e SalesforceContingency
    • Aplicativos na nuvem: Salesforce.
    • Condições: Nenhuma
    • Controle de concessão: Bloco
    • Estado: Apenas relatório
  • Política 2: Bloquear a equipe de vendas de qualquer plataforma que não seja móvel (para reduzir a área de ataque da superfície)
    • Nome: EM002 - ATIVAR EM CASO DE EMERGÊNCIA: Interrupção da conformidade do dispositivo[2/2] - Salesforce - Bloquear todas as plataformas, exceto iOS e Android
    • Usuários e grupos: inclua o SalesforceContingency. Excluir SalesAdmins
    • Aplicativos na nuvem: Salesforce
    • Condições: A plataforma do dispositivo inclui todas as plataformas, exclui iOS e Android
    • Controle de concessão: Bloco
    • Estado: Apenas relatório

Ordem de ativação:

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

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

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

Se você implantou a extensão NPS de autenticação multifator do Microsoft Entra para proteger recursos locais, como VPN e Gateway de Área de Trabalho Remota, com MFA - você deve considerar com antecedência se estiver pronto para desabilitar o MFA em caso de emergência.

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

Desative a extensão NPS:

  • Exporte a chave de registo HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AuthSrv\Parameters como cópia de segurança.
  • Exclua os valores do Registro para "AuthorizationDLLs" e "ExtensionDLLs", não a chave Parameters.
  • Reinicie o serviço de Política de Rede (IAS) para que as alterações entrem em vigor
  • Determine se a autenticação primária para VPN é bem-sucedida.

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

  • Importe a chave do Registro do backup HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AuthSrv\Parameters
  • Reinicie o serviço de Política de Rede (IAS) para que as alterações entrem em vigor
  • Determine se a autenticação primária e secundária para VPN é bem-sucedida.
  • Revise o servidor NPS e o log de VPN para determinar quais usuários entraram durante a janela de emergência.

Implante a sincronização de hash de senha mesmo se você estiver federado ou usar autenticação de passagem

O bloqueio do usuário também pode ocorrer se as seguintes condições 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 Ative Directory, AD FS ou um componente dependente) não estão disponíveis.

Para ser mais resiliente, a sua organização deve ativar a sincronização do hash de palavras-passe, uma vez que lhe permitirá mudar para a sincronização do hash de palavras-passe se os sistemas de identidade no local estiverem inativos.

Recomendações da Microsoft

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

Importante

Não é necessário converter usuários de autenticação federada para autenticação 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 única interrupção no controle de acesso. No entanto, se você optou por criar um plano de contingência, poderá ativar suas políticas de contingência durante a interrupção do controle de acesso:

  1. Habilite suas políticas de contingência que concedem aos usuários segmentados acesso a aplicativos específicos a partir de redes específicas.
  2. Desative suas políticas regulares baseadas em controle.

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 apenas com senhas. Nenhuma salvaguarda constitui um risco de segurança considerável que deve ser cuidadosamente ponderado. As organizações devem:

  1. Como parte de sua estratégia de controle de alterações, documente todas as alterações e o estado anterior para poder reverter quaisquer contingências implementadas assim que os controles de acesso estiverem totalmente operacionais.
  2. Suponha que agentes mal-intencionados tentarão coletar senhas por meio de spray de senha ou ataques de phishing enquanto você desabilitou o MFA. Além disso, os agentes mal-intencionados podem já ter senhas que anteriormente não concederam acesso a nenhum recurso que possa ser tentado durante essa janela. Para usuários críticos, como executivos, você pode reduzir parcialmente esse risco redefinindo suas senhas antes de desabilitar a MFA para eles.
  3. Arquive todas as atividades de início de sessão para identificar quem acede ao quê durante o período em que o MFA esteve desativado.
  4. Triagem de todas as deteções de risco relatadas durante esta janela.

Depois de uma interrupção

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

  1. Ativar as políticas regulares
  2. Desative suas políticas de contingência de volta ao modo somente relatório.
  3. Reverta quaisquer 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 novos detalhes de credenciais como parte dos procedimentos da sua conta de acesso de emergência.
  5. Continue a Triagem de todas as deteções de risco relatadas após a interrupção por atividades suspeitas.
  6. Revogue todos os tokens de atualização que foram emitidos para atingir um conjunto de usuários. Revogar todos os tokens de atualização é importante para contas privilegiadas usadas durante a interrupção e fazê-lo as forçará a se autenticar novamente e atender ao controle das políticas restauradas.

Opções de emergência

Em caso de emergência e a sua organização não tiver implementado anteriormente um plano de mitigação ou contingência, siga as recomendações na secção Contingências para bloqueio de utilizadores se já utilizar políticas de Acesso Condicional para impor a MFA. Se sua organização estiver usando políticas herdadas de MFA por usuário, você poderá considerar a seguinte alternativa:

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

Importante

Se você ampliar os endereços IP confiáveis para desbloquear o acesso, as deteções de risco associadas a endereços IP (por exemplo, viagens impossíveis ou locais desconhecidos) não serão geradas.

Nota

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

Mais informações