Planejar uma implantação de autenticação sem senha resistente a phishing no Microsoft Entra ID
Quando você implanta e operacionaliza a autenticação sem senha resistente a phishing em seu ambiente, recomendamos uma abordagem baseada na persona do usuário. Diferentes métodos sem senha resistentes a phishing são mais eficazes do que outros para determinadas personas do usuário. Este guia de implantação ajuda você a ver quais tipos de métodos e planos de distribuição fazem sentido para as personas do usuário em seu ambiente. A abordagem de implantação sem senha resistente a phishing geralmente tem 6 etapas, que fluem mais ou menos em ordem, mas não precisam ser 100% concluídas antes de passar para as outras etapas:
Determine as personas do usuário
Determine as personas do usuário relevantes para sua organização. Esta etapa é fundamental para seu projeto porque diferentes personas têm necessidades diferentes. A Microsoft recomenda que você considere e avalie pelo menos 4 personas do usuário genéricas em sua organização.
Persona do usuário | Descrição |
---|---|
Operadores de informações | |
Trabalhadores na linha de frente | |
Profissionais de TI/operadores de DevOps | |
Trabalhadores altamente regulamentados |
A Microsoft recomenda que você implante vastamente a autenticação sem senha resistente a phishing em toda a organização. Tradicionalmente, os operadores de informações são a persona do usuário mais fácil para começar. Faça a distribuição de credenciais seguras para os operadores de informações enquanto resolve os problemas que afetam os profissionais de TI. Adote a abordagem de "não deixar que o perfeito seja inimigo do bom" e implante credenciais seguras o máximo que puder. Quanto mais usuários entrarem usando as credenciais sem senha resistentes a phishing, mais você reduzirá a superfície de ataque do seu ambiente.
A Microsoft recomenda que você defina suas personas e, em seguida, coloque cada persona em um grupo do Microsoft Entra ID, especificamente para essa persona do usuário. Esses grupos são usados em etapas posteriores para distribuir credenciais para diferentes tipos de usuários e quando você começar a impor o uso de credenciais sem senha resistentes a phishing.
Planejar a preparação do dispositivo
Os dispositivos são um aspecto essencial de qualquer implantação sem senha resistente a phishing bem-sucedida, pois um dos objetivos das credenciais sem senha resistentes a phishing é proteger as credenciais com o hardware dos dispositivos modernos. Primeiro, familiarize-se com o suporte do FIDO2 para o Microsoft Entra ID.
Prepare os dispositivos com a proteção resistente a phishing sem senha, corrigindo as versões mais recentes com suporte de cada sistema operacional. A Microsoft recomenda que seus dispositivos executem no mínimo estas versões:
- Windows 10 22H2 (para Windows Hello para Empresas)
- Windows 11 22H2 (para a melhor experiência de usuários que usarem as chaves de acesso)
- macOS 13 Ventura
- iOS 17
- Android 14
Essas versões fornecem o melhor suporte para recursos integrados nativamente, como senhas, Windows Hello para Empresas e Credencial da Plataforma macOS. Sistemas operacionais mais antigos podem exigir autenticadores externos, como chaves de segurança FIDO2, para oferecer suporte à autenticação sem senha resistente a phishing.
Registrar usuários para credenciais resistentes a phishing
O registro de credenciais e a inicialização são as primeiras grandes atividades voltadas para o usuário final em seu projeto de implantação sem senha resistente a phishing. Esta seção aborda a distribuição de credenciais portáteis e locais.
Credenciais | Descrição | Benefícios |
---|---|---|
Portáteis | Pode ser usado em vários dispositivos. Você pode usar credenciais portáteis para entrar em outro dispositivo ou para registrar credenciais em outros dispositivos. | O tipo mais importante de credencial a ser registrado para a maioria dos usuários, pois podem ser usadas em vários dispositivos e fornecem autenticação resistente a phishing em muitos cenários. |
Local | Você pode usar credenciais locais para autenticar em um dispositivo sem precisar depender de hardware externo, como usar o reconhecimento biométrico do Windows Hello para Empresas para entrar em um aplicativo no navegador Microsoft Edge no mesmo computador | Elas têm dois benefícios principais em relação às credenciais portáteis: |
- Para novos usuários, o processo de registro e inicialização pega um usuário sem credenciais corporativas existentes e verifica sua identidade. Ele inicializa em sua primeira credencial portátil e usa essa credencial portátil para inicializar outras credenciais locais em cada um de seus dispositivos de computação. Após o registro, o administrador poderá impor a autenticação resistente a phishing para usuários no Microsoft Entra ID.
- Para usuários existente, essa fase obriga os usuários a se registrarem para credenciais sem senha resistentes a phishing diretamente em seus dispositivos existentes ou usando credenciais de MFA existentes para inicializar credenciais sem senha resistentes a phishing. O objetivo final é o mesmo dos novos usuários: a maioria dos usuários deve ter pelo menos uma credencial portátil e, em seguida, credenciais locais em cada dispositivo de computação. Se você for um administrador que implanta senhas resistentes a phishing para usuários existentes, poderá pular para a seção Etapa 2 da integração: inicializar uma credencial portátil.
Antes de começar, a Microsoft recomenda habilitar a chave de acesso e outras credenciais para usuários corporativos no locatário. Se os usuários estiverem motivados a se registrar para credenciais fortes, permita que façam isso. No mínimo, você deverá habilitar a política de chave de acesso (FIDO2) para que os usuários possam se registrar para chaves de acesso e chaves de segurança, se preferirem.
Esta seção se concentra nas fases 1-3:
Os usuários devem ter pelo menos dois métodos de autenticação registrados. Com outro método registrado, o usuário tem um método de backup disponível, caso aconteça algo com seu método principal, como quando um dispositivo é perdido ou roubado. Por exemplo, é uma boa prática que os usuários tenham chaves de acesso registradas em seus telefones e localmente em suas estações de trabalho no Windows Hello para Empresas.
Observação
É sempre recomendável que os usuários tenham pelo menos dois métodos de autenticação registrados. Isso garante que o usuário tenha um método de backup disponível se algo acontecer com seu método principal, como em casos de perda ou roubo de dispositivo. Por exemplo, é uma boa prática que os usuários tenham senhas registradas em seus telefones e localmente em suas estações de trabalho no Windows Hello para Empresas.
Observação
Essas diretrizes são adaptadas ao suporte atualmente existente para senhas no Microsoft Entra ID, que inclui senhas associadas ao dispositivo no Microsoft Authenticator e chaves de acesso associadas ao dispositivo em chaves de segurança físicas. O Microsoft Entra ID planeja adicionar suporte para senhas sincronizadas. Para obter mais informações, consulte Visualização pública: expandir o suporte à chave de acesso no Microsoft Entra ID. Este guia será atualizado para incluir orientações de chave de acesso sincronizadas, assim que estiverem disponíveis. Por exemplo, muitas organizações podem se beneficiar da sincronização para a fase 3 no diagrama anterior, em vez de inicializar credenciais totalmente novas.
Etapa 1 da integração: verificação de identidade
Para usuários remotos que não comprovaram sua identidade, a integração corporativa é um desafio significativo. A ID Verificada do Microsoft Entra pode ajudar os clientes que desejam verificação de ID de alta garantia. Ela pode usar atestados com base na ID emitida pelo governo como uma forma de estabelecer a confiança da identidade do usuário.
Nesta fase, os usuários podem ser direcionados para um serviço de parceiro de verificação de identidade. Eles passam por um processo de revisão determinado pela organização e pelo serviço de parceiro de verificação escolhido pela organização. No final desse processo, os usuários recebem uma Senha de Acesso Temporária (TAP) que pode ser usado para inicializar a primeira credencial portátil.
Consulte os guias a seguir para habilitar a integração de ID verificada do Microsoft Entra e a emissão de TAP:
- Integrar novos funcionários remotos usando a verificação de ID
- Habilitar a política de aprovação de acesso temporário
Observação
A ID Verificada do Microsoft Entra faz parte da licença do Microsoft Entra Suite.
Algumas organizações podem escolher outros métodos além da ID verificada do Microsoft Entra para integrar usuários e emitir sua primeira credencial. A Microsoft recomenda que essas organizações continuem a usar TAPs ou outras maneiras de permitir que um usuário se integre sem uma senha. Por exemplo, provisione chaves de segurança FIDO2 usando a API do Microsoft Graph (versão prévia).
Etapa 2 de integração: inicializar uma credencial portátil
Para inicializar os usuários existentes para credenciais sem senha resistentes a phishing, primeiro determine se os usuários já estão registrados na MFA tradicional. Os usuários com métodos tradicionais de MFA registrados podem ser direcionados com políticas de registro sem senha resistentes a phishing. Eles podem usar a MFA tradicional para se registrar para a primeira credencial portátil resistente a phishing e, em seguida, se registrar para credenciais locais, conforme necessário.
Para novos usuários ou usuários sem MFA, passe por um processo de emissão de uma Senha de Acesso Temporária (TAP) para os usuários. Você pode emitir um TAP da mesma forma que fornece aos novos usuários sua primeira credencial ou usando integrações de ID verificada do Microsoft Entra. Depois que os usuários tiverem um TAP, eles estarão prontos para inicializar sua primeira credencial resistente a phishing.
É importante que a primeira credencial sem senha do usuário seja uma credencial portátil que possa ser usada para autenticar em outros dispositivos de computação. Por exemplo, as senhas podem ser usadas para autenticar localmente em um telefone iOS, mas também podem ser usadas para autenticar em um PC com Windows usando um fluxo de autenticação entre dispositivos. Essa funcionalidade entre dispositivos permite que essa chave de acesso portátil seja usada para inicializar o Windows Hello para Empresas no computador Windows.
Também é importante que cada dispositivo no qual o usuário trabalha regularmente tenha uma credencial disponível localmente para oferecer ao usuário a experiência de usuário mais tranquila possível. As credenciais disponíveis localmente reduzem o tempo necessário para autenticar porque os usuários não precisam usar vários dispositivos e há menos etapas. O uso do TAP da Etapa 1 para registrar uma credencial portátil que inicialize essas outras credenciais permite que o usuário use credenciais resistentes a phishing nativamente nos vários dispositivos que possuem.
A tabela a seguir lista recomendações para diferentes personas:
Persona do usuário | Credencial portátil recomendada | Credenciais portáteis alternativas |
---|---|---|
Operador de informações | Chave de acesso (Aplicativo Authenticator) | Chave de segurança, cartão inteligente |
Trabalhador da linha de frente | Chave de segurança | Chave de acesso (aplicativo do Authenticator), cartão inteligente |
Profissional de TI/DevOps | Chave de acesso (Aplicativo Authenticator) | Chave de segurança, cartão inteligente |
Trabalhador altamente regulamentado | Certificado (cartão inteligente) | Chave de acesso (aplicativo do Authenticator), chave de segurança |
Use as diretrizes a seguir para habilitar credenciais portáteis recomendadas e alternativas para as personas de usuário relevantes para sua organização:
Método | Diretrizes |
---|---|
Chaves de acesso | |
Chaves de segurança | |
Autenticação baseada em certificado (CBA)/Cartões inteligentes |
Etapa 3 de integração: inicializar credenciais locais em dispositivos de computação
Depois que os usuários registrarem uma credencial portátil, eles estarão prontos para inicializar outras credenciais em cada dispositivo de computação que usam regularmente em um relacionamento 1:1, o que beneficia a experiência diária do usuário. Esse tipo de credencial é comum para operadores de informações e profissionais de TI, mas não para trabalhadores na linha de frente que compartilham dispositivos. Os usuários que compartilham apenas dispositivos devem usar apenas credenciais portáteis.
Sua organização precisa determinar qual tipo de credencial é preferencial para cada persona de usuário neste estágio. A Microsoft recomenda:
Persona do usuário | Credencial local recomendada – Windows | Credencial local recomendada - macOS | Credencial local recomendada - iOS | Credencial local recomendada - Android | Credencial local recomendada - Linux |
---|---|---|---|---|---|
Operador de informações | Windows Hello para Empresas | Chave do Secure Enclave de Logon Único (SSO) da Plataforma | Chave de acesso (Aplicativo Authenticator) | Chave de acesso (Aplicativo Authenticator) | N/A (use a credencial portátil) |
Trabalhador da linha de frente | N/A (use a credencial portátil) | N/A (use a credencial portátil) | N/A (use a credencial portátil) | N/A (use a credencial portátil) | N/A (use a credencial portátil) |
Profissional de TI/DevOps | Windows Hello para Empresas | Chave do Secure Enclave para o SSO da plataforma | Chave de acesso (Aplicativo Authenticator) | Chave de acesso (Aplicativo Authenticator) | N/A (use a credencial portátil) |
Trabalhador altamente regulamentado | Windows Hello para Empresas ou CBA | CBA ou chave do Secure Enclave no SSO da plataforma | Chave de acesso (Aplicativo Authenticator) ou CBA | Chave de acesso (Aplicativo Authenticator) ou CBA | N/A (use o cartão inteligente) |
Use as diretrizes a seguir para habilitar as credenciais locais recomendadas em seu ambiente para as personas de usuário relevantes para sua organização:
Método | Diretrizes |
---|---|
Windows Hello para Empresas | |
Chave do Secure Enclave para o SSO da plataforma | |
Chaves de acesso |
Considerações específicas da persona
Cada persona tem seus próprios desafios e considerações que geralmente surgem durante implantações sem senha resistentes a phishing. Ao identificar quais personas você precisa acomodar, leve em consideração esses fatores do planejamento do projeto de implantação. Os links a seguir têm orientações específicas para cada persona:
- Operadores de informações
- Trabalhadores na linha de frente
- Profissionais de TI/operadores de DevOps
- Trabalhadores altamente regulamentados
Promova o uso de credenciais resistentes a phishing
Esta etapa aborda como facilitar a adoção de credenciais resistentes a phishing pelos usuários. Você deve testar a estratégia de implantação, planejar a distribuição e comunicar o plano aos usuários finais. Em seguida, crie relatórios e monitore o progresso antes de aplicar credenciais resistentes a phishing em toda a sua organização.
Estratégia de teste e implantação
A Microsoft recomenda que você teste a estratégia de implantação criada na etapa anterior com um conjunto de testes e usuários piloto. Essa fase inclui as etapas a seguir:
- Crie uma lista de usuários de teste e adotantes iniciais. Esses usuários devem representar suas diferentes personas, e não apenas os administradores de TI.
- Crie um grupo do Microsoft Entra ID e adicione seus usuários de teste a esse grupo.
- Habilite suas políticas de métodos de autenticação no Microsoft Entra ID e defina o escopo do grupo de teste para os métodos habilitados.
- Meça a distribuição de registro para os usuários piloto usando o relatório Atividade dos Métodos de Autenticação.
- Crie políticas de Acesso Condicional para impor o uso de credenciais sem senha resistentes a phishing em cada tipo de sistema operacional, e direcione ao seu grupo piloto.
- Meça o sucesso da imposição usando o Azure Monitor e as Pastas de Trabalho.
- Reúna comentários dos usuários sobre o sucesso da distribuição.
Planejar estratégia de distribuição
A Microsoft recomenda direcionar o uso com base em quais personas de usuário estão mais prontas para implantação. Normalmente, isso significa implantar para usuários nesta ordem, mas isso pode mudar dependendo da sua organização:
- Operadores de informações
- Trabalhadores na linha de frente
- Profissionais de TI/operadores de DevOps
- Trabalhadores altamente regulamentados
Use as seções a seguir para criar comunicações ao usuário final para cada grupo de persona, escopo e distribuição do recurso de registro de chaves de acesso e relatórios e monitoramento de usuários para acompanhar o progresso da distribuição.
Planear as comunicações com os usuários finais
A Microsoft fornece modelos de comunicação para usuários finais. O material de distribuição da autenticação inclui pôsteres personalizáveis e modelos de email para informar os usuários sobre a implantação da autenticação sem senha resistente a phishing. Use os seguintes modelos para se comunicar com seus usuários para que eles entendam a implantação sem senha resistente a phishing:
- Entrada sem senha com o Microsoft Authenticator
- Registrar o método de verificação de redefinição de senha para uma conta corporativa ou de estudante
- Redefinir sua senha corporativa ou de estudante usando informações de segurança
- Configurar a chave de segurança como seu método de verificação
- Entrar em suas contas usando o aplicativo Microsoft Authenticator
- Entrar em sua conta corporativa ou de estudante usando o método de verificação em duas etapas
- Entrada na conta corporativa ou de estudante bloqueada por restrições de locatário
As comunicações devem ser repetidas várias vezes para ajudar a capturar o maior número possível de usuários. Por exemplo, sua organização pode optar por comunicar as diferentes fases e cronogramas com um padrão como este:
- 60 dias após a imposição: envie uma mensagem sobre o valor dos métodos de autenticação resistentes a phishing e incentive os usuários a se inscreverem proativamente
- 45 dias após a imposição: repita a mensagem
- 30 dias após a aplicação: mensagem avisando que em 30 dias a aplicação resistente a phishing começará, incentive os usuários a se inscreverem proativamente
- 15 dias após a imposição: repita a mensagem, informe-os sobre como entrar em contato com o suporte técnico
- 7 dias após a imposição: repita a mensagem, informe-os sobre como entrar em contato com o suporte técnico
- 1 dia após a imposição: informe-os de que a imposição ocorrerá em 24 horas, e também sobre como entrar em contato com o suporte técnico
A Microsoft recomenda a comunicação com os usuários por meio de outros canais além do email. Outras opções podem incluir mensagens do Microsoft Teams, pôsteres em sala de descanso e programas de campeões em que funcionários selecionados são treinados para defender o programa para seus colegas.
Relatórios e monitoramento
Os relatórios do Microsoft Entra ID (como Atividade de Métodos de Autenticação e detalhes de eventos de entrada para autenticação multifator do Microsoft Entra) fornecem insights técnicos e de negócios que podem ajudar você a medir e impulsionar a adoção.
No painel de atividades Métodos de autenticação, você pode exibir o registro e o uso.
- Registro mostra o número de usuários capazes de autenticar com credenciais sem senha resistentes a phishing, bem como outros métodos de autenticação. Você pode ver gráficos que mostram quais os métodos de autenticação que os usuários registraram e o registro recente de cada método.
- Uso mostra quais métodos de autenticação foram usados para entrar.
Os proprietários de aplicativos técnicos e de negócios devem possuir e receber relatórios com base nos requisitos da organização.
- Acompanhe a distribuição de credenciais sem senha resistentes a phishing com os relatórios de atividades de registro de Métodos de Autenticação.
- Acompanhe a adoção do usuário de credenciais sem senha resistentes a phishing com os Métodos de Autenticação, relatórios de atividades de login e logs de login.
- Use o relatório de atividade de entrada para acompanhar os métodos de autenticação usados para entrar nos diversos aplicativos. Selecione a linha do usuário. Selecione Detalhes da autenticação para exibir o método de autenticação e sua atividade de entrada correspondente.
O Microsoft Entra ID adiciona entradas aos logs de auditoria quando:
- Um administrador altera os métodos de autenticação.
- Um usuário faz qualquer tipo de alteração em suas credenciais dentro do Microsoft Entra ID.
O Microsoft Entra ID retém a maioria dos dados de auditoria por 30 dias. Recomendamos a retenção mais longa para auditoria, análise de tendências e outras necessidades de negócios.
Acesse dados de auditoria no centro de administração ou na API do Microsoft Entra e faça o download em seus sistemas de análise. Se você precisar de uma retenção mais longa, exporte e consuma logs em uma ferramenta SIEM (Gerenciamento de eventos e informações de segurança), como o Microsoft Azure Sentinel, Splunk ou Sumo Logic.
Monitore o volume de tíquetes de suporte técnico
Seu suporte técnico de TI pode fornecer um sinal inestimável sobre o progresso da implantação, portanto, a Microsoft recomenda rastrear o volume de tíquetes do suporte técnico ao executar uma implantação sem senha resistente a phishing.
À medida que o volume de tíquetes de suporte técnico aumenta, você deve diminuir o ritmo de suas implantações, comunicações com usuários e ações de imposição. À medida que o volume de tíquetes diminui, você pode aumentar essas atividades novamente. O uso dessa abordagem requer que você mantenha flexibilidade no seu plano de distribuição.
Por exemplo, execute suas implantações e, em seguida, as imposições em ondas que têm intervalos de datas em vez de datas específicas:
- 1º a 15 de junho: implantação e campanhas de registro de coorte da onda 1
- 16 a 30 de junho: implantação e campanhas de registro de coorte da onda 2
- 1º a 15 de julho: implantação e campanhas de registro de coorte da onda 3
- 16 a 31 de julho: imposição do coorte da onda 1 ativada
- 1º a 15 de agosto: imposição do coorte da onda 2 ativada
- 16 a 31 de agosto: imposição do coorte da onda 3 ativada
Ao executar essas diferentes fases, pode ser necessário desacelerar, dependendo do volume de tíquetes de suporte técnico abertos e, em seguida, retomar quando o volume diminuir. Para executar essa estratégia, a Microsoft recomenda que você crie um grupo de segurança do Microsoft Entra ID para cada onda e adicione cada grupo às suas políticas, uma de cada vez. Essa abordagem ajuda a evitar a sobrecarga em suas equipes de suporte.
Impor métodos resistentes a phishing para entradas
Esta seção se concentra na fase 4.
A fase final de uma implantação sem senha resistente a phishing é impor o uso de credenciais resistentes a phishing. Os principais mecanismos para fazer isso no Microsoft Entra ID são os pontos fortes de autenticação do Acesso Condicional. A Microsoft recomenda que você aborde a imposição de cada persona com base em uma metodologia do par usuário/dispositivo. Por exemplo, uma implementação de imposição pode seguir este padrão:
- Operadores de informações no Windows e iOS
- Operadores de informações no macOS e Android
- Profissionais de TI no iOS e Android
- É executado em iOS e Android
- FLWs no Windows e macOS
- Profissionais de TI no Windows e macOS
A Microsoft recomenda que você crie um relatório de todos os pares usuário/dispositivo usando dados de entrada do seu locatário. Você pode usar ferramentas de consulta como o Azure Monitor e as Pastas de Trabalho. No mínimo, tente identificar todos os pares de usuário/dispositivo que correspondem a essas categorias.
Para cada usuário, crie uma lista de quais sistemas operacionais eles usam regularmente para trabalhar. Mapeie a lista à preparação para a imposição de entrada resistente a phishing nesse par de usuário/dispositivo.
Tipo de SO | Pronto para a imposição | Não está pronto para a imposição |
---|---|---|
Windows | 10 e posteriores | 8.1 e anteriores, Windows Server |
iOS | 17 e posteriores | 16 e anteriores |
Android | 14 e posteriores | 13 e anteriores |
macOS | 13 e posteriores (Ventura) | 12 e anteriores |
VDI | Depende1 | Depende1 |
Outro | Depende1 | Depende1 |
1 Para cada par de usuários/dispositivos em que a versão do dispositivo não estiver imediatamente pronta para a imposição, determine como lidar com a necessidade de impor a resistência ao phishing. Considere as seguintes opções para sistemas operacionais mais antigos, infraestrutura de área de trabalho virtual (VDI) e outros sistemas operacionais, como Linux:
- Imponha a resistência a phishing usando hardware externo – chaves de segurança FIDO2
- Imponha a resistência a phishing usando hardware externo – cartões inteligentes
- Imponha a resistência a phishing usando credenciais remotas, como chaves de acesso, no fluxo de autenticação entre dispositivos
- Imponha a resistência a phishing usando credenciais remotas dentro de túneis RDP (principalmente para VDI)
A principal tarefa é medir por meio de dados quais usuários e personas estão prontos para a imposição em plataformas específicas. Inicie suas ações de imposição em pares de usuários/dispositivos que estiverem prontos para a imposição, a fim de "interromper o sangramento" e reduzir o volume de autenticação de phishing que ocorre em seu ambiente.
Em seguida, passe para outros cenários em que os pares usuário/dispositivo exigem esforços de preparação. Percorra a lista de pares usuários/dispositivos até aplicar a autenticação resistente a phishing em todos os aspectos.
Crie um conjunto de grupos do Microsoft Entra ID para distribuir a imposição gradualmente. Reutilize os grupos da etapa anterior se você usou a abordagem de distribuição baseada em ondas.
Direcione cada grupo com uma política de Acesso Condicional específica. Essa abordagem ajuda você a distribuir seus controles de imposição gradualmente por par de usuário/dispositivo.
Política | Nome do grupo direcionado na política | Política – Condição da plataforma de dispositivo | Política – Controle de subsídios |
---|---|---|---|
1 | Usuários prontos para senhas resistentes a phishing do Windows | Windows | Exigir força de autenticação: MFA resistente a phishing |
2 | Usuários prontos para credenciais sem senha resistentes a phishing do macOS | macOS | Exigir força de autenticação: MFA resistente a phishing |
3 | Usuários prontos para credenciais sem senha resistentes a phishing do iOS | iOS | Exigir força de autenticação: MFA resistente a phishing |
4 | Usuários prontos para Android sem senha resistentes a phishing | Android | Exigir força de autenticação: MFA resistente a phishing |
5 | Outros usuários prontos para credenciais sem senha resistentes a phishing | Qualquer, exceto Windows, macOS, iOS ou Android | Exigir força de autenticação: MFA resistente a phishing |
Adicione cada usuário a cada grupo ao determinar se o dispositivo e o sistema operacional estão prontos ou se eles não têm um dispositivo desse tipo. No final da distribuição, cada usuário deve estar em um dos grupos.
Responda ao risco para usuários sem senha
O Microsoft Entra ID Protection ajuda as organizações a detectar, investigar e corrigir riscos baseados em identidade. O Microsoft Entra ID Protection fornece detecções importantes e úteis para seus usuários, mesmo depois que eles mudam para o uso de credenciais sem senha resistentes a phishing. Por exemplo, algumas detecções relevantes para usuários resistentes a phishing incluem:
- Atividade de um endereço IP anônimo
- Usuário comprometido confirmado pelo administrador
- Token anormal
- Endereço IP mal-intencionado
- Inteligência contra ameaças do Microsoft Entra
- Navegador suspeito
- Attacker in the Middle
- Possível tentativa de acessar o PRT (token de atualização primário)
- E outras: Detecções de risco mapeadas para riskEventType
A Microsoft recomenda que os clientes do Microsoft Entra ID Protection tomem as seguintes medidas para proteger melhor seus usuários sem senha resistentes a phishing:
- Examine as diretrizes de implantação do Microsoft Entra ID Protection: Planejar uma implantação de Proteção de ID
- Configurar os logs de risco para exportar para um SIEM
- Investigue e aja mediante qualquer risco médio para o usuário
- Configurar uma política de acesso condicional para bloquear usuários de alto risco
Após implantar o Microsoft Entra ID Protection, considere usar a proteção por token do Acesso Condicional. À medida que os usuários fazem login com credenciais sem senha resistentes a phishing, os ataques e as detecções continuam a evoluir. Por exemplo, quando as credenciais do usuário não podem mais ser facilmente roubadas, os invasores podem tentar infiltrar os tokens dos dispositivos do usuário. A proteção por token ajuda a mitigar esse risco associando tokens ao hardware do dispositivo para o qual foram emitidos.