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.

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.

• 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.

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. Sem a verificação de identidade adequada, uma organização não tem certeza de que está integrando a pessoa que deseja. A ID verificada do Microsoft Entra pode fornecer verificação de identidade de alta garantia. As organizações podem trabalhar com um IDV (parceiro de verificação de identidade) para verificar as identidades de novos usuários remotos no processo de integração. Depois do processamento da ID de um usuário emitida pelo governo, o IDV pode fornecer uma ID verificada que afirma a identidade do usuário. O novo usuário apresenta essa ID verificada de afirmação de identidade para a organização contratante para estabelecer a confiança e confirmar que a organização está integrando a pessoa certa. As organizações podem adicionar a verificação facial na ID Verificada do Microsoft Entra, que adiciona uma camada de correspondência facial à verificação, garantindo que o usuário confiável esteja apresentando a ID verificada de afirmação de identidade nesse momento.

Depois de verificar a identidade por meio do processo de revisão, os novos contratados recebem uma TAP (senha de acesso temporária) que podem usar para inicializar sua 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
• Usar a verificação facial com a ID Verificada do Microsoft Entra para desbloquear verificações de alta garantia em escala
• Habilitar a política de aprovação de acesso temporário

Consulte os links a seguir para obter detalhes de licenciamento para a ID Verificada do Microsoft Entra:

• Preço da verificação facial com ID Verificada do Microsoft Entra
• Planos e preços do Microsoft Entra

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, você pode provisionar chaves de segurança FIDO2 usando a API do Microsoft Graph.

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:

Use as diretrizes a seguir para habilitar credenciais portáteis recomendadas e alternativas para as personas de usuário relevantes para sua organização:

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:

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:

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:

1. Operadores de informações
2. Trabalhadores na linha de frente
3. Profissionais de TI/operadores de DevOps
4. 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:

1. 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
2. 45 dias após a imposição: repita a mensagem
3. 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
4. 15 dias após a imposição: repita a mensagem, informe-os sobre como entrar em contato com o suporte técnico
5. 7 dias após a imposição: repita a mensagem, informe-os sobre como entrar em contato com o suporte técnico
6. 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. 1º a 15 de junho: implantação e campanhas de registro de coorte da onda 1
2. 16 a 30 de junho: implantação e campanhas de registro de coorte da onda 2
3. 1º a 15 de julho: implantação e campanhas de registro de coorte da onda 3
4. 16 a 31 de julho: imposição do coorte da onda 1 ativada
5. 1º a 15 de agosto: imposição do coorte da onda 2 ativada
6. 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:

1. Operadores de informações no Windows e iOS
2. Operadores de informações no macOS e Android
3. Profissionais de TI no iOS e Android
4. É executado em iOS e Android
5. FLWs no Windows e macOS
6. 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.

¹ 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.

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:

1. Examine as diretrizes de implantação do Microsoft Entra ID Protection: Planejar uma implantação de Proteção de ID
2. Configurar os logs de risco para exportar para um SIEM
3. Investigue e aja mediante qualquer risco médio para o usuário
4. 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.

Próximas etapas

Considerações para personas específicas em uma implantação de autenticação sem senha resistente a phishing no Microsoft Entra ID