Planejar uma implantação de autenticação sem senha resistente a phishing no Microsoft Entra ID

Artigo
03/05/2025

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 de 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 aproximadamente em ordem, mas não precisam ser 100% concluídas antes de passar para outras etapas:

Determine suas personas de usuário

Determine as personas de usuário relevantes para sua organização. Esta etapa é fundamental para o seu projeto, pois diferentes personas têm necessidades diferentes. A Microsoft recomenda que você considere e avalie pelo menos 4 personas de usuário genéricas em sua organização.

Persona de Utilizador	Descrição
Técnicos de informação	Os exemplos incluem a equipe de produtividade do escritório, como marketing, finanças ou recursos humanos. Outros tipos de profissionais da informação podem ser executivos e outros trabalhadores de alta sensibilidade que necessitam de controlos especiais Normalmente têm uma relação 1:1 com seus dispositivos móveis e de computação Pode trazer seus próprios dispositivos (BYOD), especialmente para dispositivos móveis
Trabalhadores da linha de frente	Exemplos incluem trabalhadores de lojas de varejo, trabalhadores de fábricas, trabalhadores da indústria Normalmente funcionam apenas em dispositivos ou quiosques partilhados Não pode ser permitido transportar telemóveis
Profissionais de TI/Trabalhadores de DevOps	Os exemplos incluem administradores de TI para Ative Directory local, ID do Microsoft Entra ou outras contas privilegiadas. outros exemplos seriam trabalhadores de DevOps ou trabalhadores de DevSecOps que gerenciam e implantam automações. Normalmente têm várias contas de usuário, incluindo uma conta de usuário "normal" e uma ou mais contas administrativas Normalmente usam protocolos de acesso remoto, como RDP (Remote Desktop Protocol) e SSH (Secure Shell Protocol), para administrar sistemas remotos Pode funcionar em dispositivos bloqueados com Bluetooth desativado Pode usar contas secundárias para executar scripts e automações não interativas
Trabalhadores altamente regulamentados	Os exemplos incluem trabalhadores do governo federal dos EUA sujeitos aos requisitos da Ordem Executiva 14028 , funcionários do governo estadual e local ou trabalhadores sujeitos a regulamentos de segurança específicos Normalmente, têm uma relação 1:1 com seus dispositivos, mas têm controles regulatórios específicos que devem ser atendidos nesses dispositivos e para autenticação Os telemóveis podem não ser permitidos em áreas seguras Pode aceder a ambientes com ar comprimido sem ligação à Internet Pode funcionar em dispositivos bloqueados com Bluetooth desativado

A Microsoft recomenda que você implante amplamente a autenticação sem senha resistente a phishing em toda a sua organização. Tradicionalmente, os profissionais da informação são o perfil de utilizador mais fácil com o qual começar. Não atrase a implementação de credenciais seguras para operadores de informações enquanto resolve problemas que afetam os profissionais de TI. Adote a abordagem de "não deixe o perfeito ser inimigo do bem" e implante credenciais seguras tanto quanto possível. À medida que mais usuários entram usando credenciais sem senha resistentes a phishing, você reduz 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 de ID do Microsoft Entra especificamente para essa persona de usuário. Esses grupos são usados em etapas posteriores para distribuir credenciais para diferentes tipos de usuários e quando você começa a impor o uso de credenciais sem senha resistentes a phishing.

Planejar a preparação do dispositivo

Os dispositivos são um aspeto essencial de qualquer implantação sem senha resistente a phishing bem-sucedida, uma vez que um dos objetivos das credenciais sem senha resistentes a phishing é proteger as credenciais com o hardware de dispositivos modernos. Primeiro, familiarize-se com a capacidade de suporte FIDO2 para Microsoft Entra ID.

Certifique-se de que os seus dispositivos estão preparados para a ausência de palavra-passe resistente a phishing, aplicando patches nas versões suportadas mais recentes de cada sistema operativo. A Microsoft recomenda que seus dispositivos estejam executando essas versões no mínimo:

Windows 10 22H2 (para Windows Hello for Business)
Windows 11 22H2 (para a melhor experiência do usuário ao usar chaves de acesso)
macOS 13 Ventura |
iOS 17
Androide 14

Essas versões oferecem o melhor suporte para recursos integrados nativamente, como chaves de acesso, Windows Hello for Business e macOS Platform Credential. 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átil	Pode ser usado em todos os dispositivos. Pode utilizar credenciais portáteis para iniciar sessão noutro dispositivo ou para registar credenciais noutros dispositivos.	O tipo de credencial mais importante para se registrar para a maioria dos usuários, pois eles podem ser usados em todos os dispositivos e fornecer 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 for Business para entrar em um aplicativo no navegador Microsoft Edge no mesmo PC	Eles têm dois benefícios principais sobre as credenciais portáteis: Proporcionam redundância. Se os usuários perderem seu dispositivo portátil, esquecê-lo em casa ou tiverem outros problemas, a credencial local fornecerá um método de backup para continuar a trabalhar em seu dispositivo de computação. Eles fornecem uma ótima experiência de usuário. Com uma credencial local, os usuários não precisam tirar os telefones do bolso, escanear códigos QR ou executar outras tarefas que retardam a autenticação e adicionam atrito. As credenciais de resistência a phishing disponíveis localmente ajudam os utilizadores a iniciar sessão mais facilmente nos dispositivos que utilizam regularmente.

Para novos usuários, o processo de registro e inicialização leva um usuário sem credenciais corporativas existentes e verifica sua identidade. Ele os 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 pode impor autenticação resistente a phishing para usuários no Microsoft Entra ID.
Para os usuários existentes, essa fase permite que os usuários se registrem diretamente para credenciais sem senha resistentes a phishing 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 for um administrador que implanta sistemas sem senha resistentes a phishing para utilizadores existentes, talvez possa pular à seção integração: Etapa 2 de inicialização de 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 autoregistrar para obter credenciais fortes, é benéfico permitir isso. No mínimo, deve ativar a política Passkey (FIDO2) para que os utilizadores possam registar-se para chaves de acesso e chaves de segurança, se as preferirem.

Esta secção centra-se nas fases 1 a 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 se algo acontecer com seu método principal, como quando um dispositivo é perdido ou roubado. Por exemplo, é uma boa prática para os usuários ter chaves de acesso registradas no telefone e localmente em sua estação de trabalho no Windows Hello for Business.

Nota

É 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 para os usuários ter chaves de acesso registradas em seu telefone e localmente em sua estação de trabalho no Windows Hello for Business.

Nota

Esta orientação foi concebida para o suporte atualmente existente para chaves de acesso no Microsoft Entra ID, que inclui chaves de acesso 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 chaves de acesso sincronizadas. Para obter mais informações, consulte Visualização pública: expandindo o suporte a chaves de acesso no Microsoft Entra ID. Este guia será atualizado para incluir orientações de chave de acesso sincronizadas, uma vez disponíveis. Por exemplo, muitas organizações podem se beneficiar de confiar na sincronização para a fase 3 no diagrama anterior em vez de inicializar credenciais totalmente novas.

Etapa 1 de integração: Verificação de identidade

Para usuários remotos que não provaram sua identidade, a integração corporativa é um desafio significativo. Sem uma verificação de identidade adequada, uma organização não pode ter certeza absoluta de que está integrando a pessoa que pretende. O Microsoft Entra Verified ID pode fornecer verificação de identidade de alta garantia. As organizações podem trabalhar com um parceiro de verificação de identidade (IDV) para verificar as identidades de novos usuários remotos no processo de integração. Depois de processar a ID emitida pelo governo de um usuário, 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 à organização contratante para estabelecer confiança e confirmar que a organização está integrando a pessoa certa. As organizações podem adicionar o Face Check com o Microsoft Entra Verified ID, que adiciona uma camada de correspondência facial à verificação, garantindo que o utilizador de confiança apresenta o ID Verificado que afirma a identidade naquele momento.

Depois de verificar sua identidade através do processo de verificação, os novos contratados recebem um Passe de Acesso Temporário (TAP) que eles podem usar para inicializar sua primeira credencial portátil.

Consulte os seguintes guias para habilitar a integração do Microsoft Entra Verified ID e a emissão da TAP:

Consulte os links a seguir para obter detalhes de licenciamento para o Microsoft Entra Verified ID:

Algumas organizações podem escolher outros métodos além da ID Verificada do Microsoft Entra para integrar os usuários e emitir-lhes sua primeira credencial. A Microsoft recomenda que essas organizações ainda usem TAPs ou outra maneira que permita que um usuário 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 usuários existentes para credenciais sem senha resistentes a phishing, primeiro determine se os usuários já estão registrados para MFA tradicional. Os utilizadores com métodos tradicionais de MFA registados podem ser alvo de políticas de registo sem palavra-passe resistentes a phishing. Eles podem usar seu MFA tradicional para se registrar para sua primeira credencial portátil resistente a phishing e, em seguida, passar a se registrar para credenciais locais, conforme necessário.

Para novos usuários ou usuários sem MFA, passe por um processo para emitir aos usuários um Passe de Acesso Temporário (TAP). Você pode emitir um TAP da mesma forma que dá aos novos usuários sua primeira credencial ou usando integrações de ID Verificada do Microsoft Entra. Assim 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 autenticação em outros dispositivos de computação. Por exemplo, as chaves de acesso podem ser usadas para autenticar localmente em um telefone iOS, mas também podem ser usadas para autenticar em um PC Windows usando um fluxo de autenticação entre dispositivos. Esse recurso entre dispositivos permite que essa chave de acesso portátil seja usada para inicializar o Windows Hello for Business no PC com Windows.

Também é importante que cada dispositivo em que o usuário trabalha regularmente tenha uma credencial disponível localmente para dar ao usuário a experiência de usuário mais suave 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. Usar a TAP da Etapa 1 para registrar uma credencial portátil que pode inicializar essas outras credenciais permite que o usuário use credenciais resistentes a phishing nativamente nos vários dispositivos que pode possuir.

A tabela a seguir lista recomendações para diferentes personas:

Persona do usuário	Credencial portátil recomendada	Credenciais portáteis alternativas
Técnico de informação	Chave de acesso (aplicativo autenticador)	Chave de segurança, cartão inteligente
Trabalhador da linha de frente	Chave de segurança	Chave de acesso (aplicativo autenticador), cartão inteligente
Profissional de TI/DevOps	Chave de acesso (aplicativo autenticador)	Chave de segurança, cartão inteligente
Trabalhador altamente regulamentado	Certificado (cartão inteligente)	Chave de acesso (aplicativo autenticador), 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	Orientação
Chaves de acesso	A Microsoft recomenda que os usuários entrem no Microsoft Authenticator diretamente para inicializar uma chave de acesso no aplicativo. Os utilizadores podem utilizar a sua TAP para iniciar sessão no Microsoft Authenticator diretamente no seu dispositivo iOS ou Android. As chaves de acesso são desativadas por padrão no Microsoft Entra ID. Você pode habilitar chaves de acesso na política de métodos de autenticação. Registre chaves de acesso no Authenticator em dispositivos Android ou iOS.
Chaves de segurança	As chaves de segurança são desativadas por padrão no Microsoft Entra ID. Você pode habilitar chaves de segurança FIDO2 na política de métodos de autenticação. Considere registrar chaves em nome de seus usuários com as APIs de provisionamento do Microsoft Entra ID. Para obter mais informações, consulte Provisionar chaves de segurança FIDO2 usando a API do Microsoft Graph.
Autenticação baseada em cartão inteligente/certificado (CBA)	A autenticação baseada em certificado é mais complicada de configurar do que chaves de acesso ou outros métodos. Considere usá-lo apenas se necessário. Como configurar a autenticação baseada em certificado do Microsoft Entra. Certifique-se de configurar as suas políticas de PKI local e CBA do Microsoft Entra ID para que os utilizadores realmente concluam a autenticação multifatorial para aceder. A configuração geralmente requer o OID (Policy Object Identifier) do cartão inteligente e as configurações de vinculação de afinidade necessárias. Para obter configurações CBA mais avançadas, consulte Noções básicas sobre a política de vinculação de autenticaçã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 uma relação 1:1, o que beneficia sua experiência de usuário diária. Esse tipo de credencial é comum para profissionais de informações e profissionais de TI, mas não para trabalhadores da 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 é preferido para cada persona de usuário neste estágio. A Microsoft recomenda:

Persona de Utilizador	Credencial local recomendada - Windows	Credencial local recomendada - macOS	Credencial local recomendada - iOS	Credencial local recomendada - Android	Credencial local recomendada - Linux
Técnico de informação	Windows Hello para empresas	Chave de Enclave Segura de Logon Único (SSO) da Plataforma	Chave de acesso (aplicativo autenticador)	Chave de acesso (aplicativo autenticador)	N/D (utilize uma credencial portátil)
Trabalhador da linha de frente	N/D (utilize uma credencial portátil)	N/D (utilize uma credencial portátil)	N/D (utilize uma credencial portátil)	N/D (utilize uma credencial portátil)	N/D (utilize uma credencial portátil)
Profissional de TI/DevOps	Windows Hello para empresas	Chave do enclave seguro para SSO da plataforma	Chave de acesso (aplicativo autenticador)	Chave de acesso (aplicativo autenticador)	N/D (utilize uma credencial portátil)
Trabalhador altamente regulamentado	Windows Hello for Business ou CBA	Plataforma SSO Secure Enclave Key ou CBA	Chave de acesso (aplicativo autenticador) ou CBA	Chave de acesso (aplicativo autenticador) ou CBA	N/D (em vez disso, utilize um 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	Orientação
Windows Hello para empresas	A Microsoft recomenda o uso do método Cloud Kerberos Trust para implantar o Windows Hello for Business. Para obter mais informações, consulte o guia de implantação de confiança do Cloud Kerberos. O método Cloud Kerberos Trust aplica-se a qualquer ambiente onde os usuários são sincronizados do Ative Directory local para o Microsoft Entra ID. Ajuda os utilizadores sincronizados em PCs que estão associados ao Microsoft Entra ou estão em modo híbrido com o Microsoft Entra. O Windows Hello para Empresas só deve ser utilizado quando cada utilizador num PC inicia sessão nesse PC como ele próprio. Ele não deve ser usado em dispositivos de quiosque que usam uma conta de usuário compartilhada. O Windows Hello para Empresas suporta até 10 utilizadores por dispositivo. Se os seus dispositivos partilhados precisarem de suportar mais utilizadores, utilize uma credencial portátil, como chaves de segurança. A biometria é opcional, mas recomendada. Para obter mais informações, consulte Preparar os usuários para provisionar e usar o Windows Hello for Business.
Chave de enclave seguro SSO da plataforma	O SSO da plataforma suporta 3 métodos diferentes de autenticação de usuário (chave Secure Enclave, cartão inteligente e senha). Implante o método de chave Secure Enclave para espelhar seu Windows Hello for Business em seus Macs. O SSO da plataforma requer que os Macs estejam inscritos no Gerenciamento de Dispositivos Móveis (MDM). Para obter instruções específicas para o Intune, consulte Configurar o SSO da plataforma para dispositivos macOS no Microsoft Intune. Consulte a documentação do fornecedor de MDM se você usar outro serviço MDM em seus Macs.
Chaves de acesso	A Microsoft recomenda a mesma opção de registro de dispositivo para inicializar chaves de acesso no Microsoft Authenticator (em vez da opção de registro entre dispositivos). Os utilizadores utilizam o TAP para iniciar sessão no Microsoft Authenticator diretamente no seu dispositivo iOS ou Android. As chaves de acesso são desabilitadas por padrão no Microsoft Entra ID, habilite-as na política de métodos de autenticação. Para obter mais informações, consulte Habilitar chaves de acesso no Microsoft Authenticator. Registre chaves de acesso no Authenticator em dispositivos Android ou iOS.

Considerações específicas das personas

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, você deve considerar essas considerações no planejamento do projeto de implantação. Os links a seguir têm orientações específicas para cada persona:

Impulsione o uso de credenciais resistentes a phishing

Esta etapa aborda como tornar mais fácil para os usuários adotarem credenciais resistentes a phishing. Você deve testar sua estratégia de implantação, planejar a distribuição e comunicar o plano aos usuários finais. Em seguida, você pode criar relatórios e monitorar o progresso antes de impor credenciais resistentes a phishing em toda a organização.

Testar a estratégia de implantação

A Microsoft recomenda que você teste a estratégia de implantação criada na etapa anterior com um conjunto de usuários piloto e de teste. Esta fase deve incluir as seguintes etapas:

Crie uma lista de usuários de teste e primeiros usuários. Esses usuários devem representar suas diferentes personas de usuário, e não apenas administradores de TI.
Crie um grupo de ID do Microsoft Entra e adicione seus usuários de teste ao grupo.
Habilite suas políticas de métodos de autenticação na ID do Microsoft Entra e defina o escopo do grupo de teste para os métodos habilitados.
Meça o lançamento do registo para os seus utilizadores piloto usando o Relatório de Atividade de 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 segmente seu grupo piloto.
Meça o sucesso da imposição usando o Azure Monitor e as Pastas de Trabalho.
Reúna feedback dos usuários sobre o sucesso da implantação.

Planejar a estratégia de implantação

A Microsoft recomenda direcionar o uso com base nas personas de utilizador que estão mais prontas para a implantação. Normalmente, isso significa implantar para usuários nessa ordem, mas isso pode mudar dependendo da sua organização:

Técnicos de informação
Trabalhadores da linha de frente
Profissionais de TI/trabalhadores de DevOps
Trabalhadores altamente regulamentados

Use as seções a seguir para criar comunicações para o usuário final para cada grupo de persona, definir o escopo e a implementação do recurso de registro de chaves de acesso, e realizar relatórios e monitoramento de usuários para acompanhar o progresso da implantação.

Preparação para o uso com o Manual Sem Palavra-passe Phishing-Resistant (Pré-visualização)

Opcionalmente, as organizações podem optar por exportar os seus logs de entrada do Microsoft Entra ID para o Azure Monitor para retenção de longo prazo, deteção de ameaças e outros fins. A Microsoft lançou uma pasta de trabalho que as organizações com logs no Azure Monitor podem usar para ajudar em várias fases de uma implantação de autenticação sem senha resistente a phishing. A pasta de trabalho sem senha Phishing-Resistant pode ser acessada aqui: aka.ms/PasswordlessWorkbook. Escolha a pasta de trabalho intitulada Phishing-Resistant Implantação sem senha (Visualização):

A pasta de trabalho tem duas secções principais:

Fase de preparação para inscrição
Fase de preparação para a aplicação

Fase de preparação para inscrição

Utilize o separador Fase de preparação para registo para analisar os registos de entrada no seu inquilino, determinando quais utilizadores estão prontos para o registo e quais podem ser impedidos de se registarem. Por exemplo, com a guia Fase de preparação para inscrição, você pode selecionar iOS como a plataforma do sistema operacional e, em seguida, Chave de acesso do aplicativo autenticador como o tipo de credencial para a qual você gostaria de avaliar sua preparação. Em seguida, você pode clicar nas visualizações da pasta de trabalho para filtrar os usuários que devem ter problemas de registro e exportar a lista:

A aba Fase de Preparação para Inscrição do livro de trabalho pode ajudá-lo a avaliar sua prontidão para os seguintes sistemas operativos e credenciais:

Windows
- Windows Hello para empresas
- Chave de Segurança FIDO2
- Chave de acesso do aplicativo autenticador
- Autenticação Certificate-Based / Cartão Inteligente
macOS
- Chave de enclave seguro SSO da plataforma
- Chave de Segurança FIDO2
- Chave de acesso do aplicativo autenticador
- Autenticação Certificate-Based / Cartão Inteligente
iOS
- Chave de Segurança FIDO2
- Chave de acesso do aplicativo autenticador
- Autenticação Certificate-Based / Cartão Inteligente
Androide
- Chave de Segurança FIDO2
- Chave de acesso do aplicativo autenticador
- Autenticação Certificate-Based / Cartão Inteligente

Use cada lista exportada para triar usuários que possam ter problemas de registro. As respostas a problemas de registro devem incluir ajudar os usuários a atualizar as versões do sistema operacional do dispositivo, substituir dispositivos antigos e escolher credenciais alternativas onde a opção preferida não é viável. Por exemplo, sua organização pode optar por fornecer chaves de segurança FIDO2 físicas para usuários do Android 13 que não podem usar chaves de acesso no aplicativo Microsoft Authenticator.

Da mesma forma, use o relatório de preparação para a inscrição para ajudá-lo a criar listas de utilizadores que estão prontos para iniciar as comunicações e campanhas de inscrição, em conformidade com a sua estratégia geral de distribuição de .

Fase de preparação para a aplicação da legislação

A primeira etapa da fase de preparação para aplicação é a criação de uma política de Acesso Condicional no modo Report-Only. Esta política preencherá os seus registos de acessos com dados sobre se o acesso teria sido ou não bloqueado caso colocasse utilizadores/dispositivos no âmbito da imposição resistente ao phishing. Crie uma nova política de Acesso Condicional no seu inquilino com estas definições:

Configurações	Valor
Atribuição de Usuário/Grupo	Todos os utilizadores, excluindo contas de vidro quebrado
Atribuição de Apps	Todos os recursos
Controles de subvenção	Exigir força de autenticação - MFA resistente a phishing
Ativar a política	Apenas relatórios

Crie essa política o mais cedo possível em sua implantação, de preferência antes mesmo de iniciar suas campanhas de inscrição. Isso garantirá que você tenha um bom conjunto de dados históricos de quais usuários e logins teriam sido bloqueados pela política se ela fosse imposta.

Em seguida, use a pasta de trabalho para analisar onde os pareamentos de utilizador/dispositivo estão prontos para implementação. Transfira listas de utilizadores que estão prontos para execução e adicione-os a grupos criados em conformidade com as suas políticas de aplicação de . Comece por selecionar a política de Acesso Condicional no modo de leitura apenas no filtro de política:

O relatório fornecerá uma lista de utilizadores que teriam conseguido satisfazer com sucesso o requisito de autenticação sem palavra-chave resistente a phishing em cada plataforma de dispositivos. Baixe cada lista e coloque os usuários apropriados no grupo de imposição que se alinha à plataforma do dispositivo.

Repita esse processo ao longo do tempo, até chegar ao ponto em que cada grupo de imposição contém a maioria ou todos os usuários. Por fim, deverá ser capaz de ativar a política apenas de relatório para aplicar a todos os utilizadores e plataformas de dispositivos no inquilino. Depois de atingir esse estado concluído, você pode remover as políticas de imposição individuais para cada sistema operacional do dispositivo, reduzindo o número de políticas de Acesso Condicional necessárias.

Investigando usuários que não estão prontos para aplicação

Use a guia Análise de Dados Adicionais para investigar por que certos utilizadores não estão prontos para implementação em diferentes plataformas. Selecione a caixa Política Não Satisfeita para filtrar os dados para entradas de utilizador que teriam sido bloqueadas pela política de Acesso Condicional em modo de somente relatório.

Use os dados fornecidos por este relatório para determinar quais usuários teriam sido bloqueados, em quais sistemas operacionais de dispositivo eles estavam, que tipo de aplicativos cliente eles estavam usando e quais recursos eles estavam tentando acessar. Esses dados devem ajudá-lo a direcionar esses usuários para várias ações de correção ou registro, para que eles possam ser efetivamente movidos para o escopo de aplicação.

Planejar comunicações com o usuário final

A Microsoft fornece modelos de comunicação para usuários finais. O material de distribuição de autenticação inclui modelos de e-mail personalizáveis para informar os usuários sobre a implantação de 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:

As comunicações devem ser repetidas várias vezes para ajudar a capturar o maior número possível de utilizadores. 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 aplicaçã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 aplicação: repetir mensagem
30 dias antes da aplicação: mensagem de que dentro de 30 dias começará a aplicação resistente ao phishing, encoraje os utilizadores a registarem-se antecipadamente
15 dias após a aplicação: repita a mensagem, informe-os sobre como entrar em contato com o suporte técnico
7 dias após a aplicação: repita a mensagem, informe-os sobre como entrar em contato com o suporte técnico
1 dia antes da reafirmação: informá-los de que a reafirmação ocorrerá em 24 horas, informá-los sobre como entrar em contato com o balcão de ajuda

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, cartazes de sala de intervalo e programas de campeão, onde funcionários selecionados são treinados para defender o programa para seus colegas.

Relatórios e monitorização

Utilize a Pasta de trabalho sem senha Phishing-Resistant abordada anteriormente para ajudar com o monitoramento e a geração de relatórios sobre a sua distribuição. Além disso, use os relatórios discutidos abaixo ou confie neles se não puder usar a pasta de trabalho sem senha Phishing-Resistant.

Os relatórios de ID do Microsoft Entra (como Atividade de Métodos de Autenticação e detalhes dos eventos de início de sessão para a autenticação multifator do Microsoft Entra) fornecem informações técnicas e de negócios que podem ajudá-lo a medir e impulsionar a adoção.

No painel de atividade Métodos de autenticação, você pode exibir o registro e o uso.

O registro mostra o número de usuários capazes de autenticação sem senha resistente a phishing e outros métodos de autenticação. Você pode ver gráficos que mostram quais métodos de autenticação os usuários registraram e o registro recente para cada método.
O uso mostra quais métodos de autenticação foram usados para iniciar sessão.

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 implementação de credenciais sem senha e resistentes a phishing através de relatórios de atividade de registo dos Métodos de Autenticação.
Acompanhe a adoção de credenciais sem senha resistentes a phishing pelos utilizadores através dos relatórios de atividade e registos de início de sessão dos Métodos de Autenticação.
Use o relatório de atividade de entrada para controlar os métodos de autenticação usados para entrar nos vários aplicativos. Selecione a linha do utilizador; selecione Detalhes de Autenticação para visualizar o método de autenticação e a sua atividade de início de sessão correspondente.

O Microsoft Entra ID adiciona entradas aos logs de auditoria quando essas condições ocorrem:

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 uma retenção mais longa para auditoria, análise de tendências e outras necessidades de negócios.

Aceda aos dados de auditoria no centro de administração ou API do Microsoft Entra e transfira para os seus sistemas de análise. Se você precisar de retenção mais longa, exporte e consuma logs em uma ferramenta de Gerenciamento de Informações e Eventos de Segurança (SIEM), como Microsoft Sentinel, Splunk ou Sumo Logic.

Monitorar o volume de pedidos do serviço de atendimento

O seu suporte técnico de TI pode fornecer um sinal inestimável sobre o progresso da implantação, por isso a Microsoft recomenda acompanhar o volume de pedidos do suporte ao executar uma implantação de sistema 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 a flexibilidade em seu plano de implantação.

Por exemplo, pode executar as suas implementações e, em seguida, as suas aplicações em ondas que têm intervalos de datas em alternativa a datas específicas.

1 a 15 de junho: lançamento e campanhas de inscrição da coorte da Onda 1
16 a 30 de junho: implantação e campanhas de inscrição da coorte da Onda 2
1 a 15 de julho: implantação e campanhas de registo da coorte da Onda 3
16 a 31 de julho: Ativação do reforço da coorte da 1ª onda
1 a 15 de agosto: Implementação da coorte da 2ª onda habilitada
16 a 31 de agosto: Ativação da coorte da onda 3 implementada

À medida que você executa essas diferentes fases, talvez seja necessário diminuir a velocidade 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 sobrecarregar suas equipes de suporte.

Esta secção centra-se na fase 4.

A fase final de uma implantação sem senha resistente a phishing é impor o uso de credenciais resistentes a phishing. O principal mecanismo para fazer isso no Microsoft Entra ID são os pontos fortes da autenticação de Acesso Condicional. A Microsoft recomenda abordar a imposição para cada persona com base numa metodologia de par utilizador/dispositivo. Por exemplo, uma implementação de cumprimento pode seguir este padrão:

Trabalhadores da informação no Windows e iOS
Trabalhadores de informação no macOS e Android
Profissionais de TI no iOS e Android
FLWs em iOS e Android
FLWs no Windows e macOS
Profissionais de TI no Windows e macOS

A Microsoft recomenda criar um relatório de todos os seus pares utilizador-dispositivo utilizando dados de início de sessão do seu locatário. Você pode usar ferramentas de consulta como o Azure Monitor e Pastas de Trabalho. No mínimo, tente identificar todos os pares de usuário/dispositivo que correspondam a essas categorias.

Use o Phishing-Resistant Livro de Trabalho Sem Senha coberto anteriormente para ajudar na fase de implementação, se possível.

Para cada usuário, crie uma lista de quais sistemas operacionais eles usam regularmente para trabalhar. Mapeie a lista para verificar a prontidão da imposição de autenticação resistente a phishing para esse par de utilizador/dispositivo.

Tipo de SO	Pronto para a aplicação	Não está pronto para aplicação
Windows	Mais de 10	8.1 e versões anteriores, Windows Server
iOS	17+	16 e anteriores
Android	14+	13 ou anteriores
macOS	13+ (Ventura)	12 e anteriores
VDI	Depende¹	Depende¹
Outro	Depende¹	Depende¹

1 Para cada par de utilizador/dispositivo em que a versão do dispositivo não esteja imediatamente pronta para aplicação, determine como abordar a necessidade de reforçar 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:

Reforçar a resistência a phishing usando hardware externo – chaves de segurança FIDO2
Reforçar a resistência à phishing usando hardware externo – cartões inteligentes
Aplique a resistência a phishing usando credenciais remotas, como chaves de acesso no fluxo de autenticação entre dispositivos
Melhore a capacidade de resistência a phishing utilizando credenciais remotas dentro de túneis RDP (especialmente para VDI)

A principal tarefa é medir, por meio de dados, quais usuários e personas estão prontos para aplicação em plataformas específicas. Comece as suas ações de imposição em pares de utilizador/dispositivo que estão prontos para imposição, para "parar o sangramento" e reduzir a quantidade de autenticação suscetível a phishing que ocorre no seu ambiente.

Em seguida, passe para outros cenários em que os pares usuário/dispositivo exigem esforços de preparação. Analise a lista de pares de utilizadores/dispositivos até impor a autenticação resistente a phishing de forma abrangente.

Crie um conjunto de grupos de ID do Microsoft Entra para implementar a aplicação de políticas gradualmente. Reutilize os grupos da etapa anterior se tiver usado a abordagem de distribuição baseada em ondas.

Políticas recomendadas de imposição de acesso condicional

Segmente cada grupo com uma política de Acesso Condicional específica. Essa abordagem ajuda você a implementar seus controles de imposição gradualmente por par usuário/dispositivo.

Política	Nome do grupo visado na política	Política – Condição da plataforma do dispositivo	Política – Controlo de subvenções
1	Utilizadores do Windows preparados para operar sem senha e resistentes ao phishing	Windows	Exigir força de autenticação – MFA resistente a phishing
2	Utilizadores do macOS preparados para autenticação sem senha e resistência a phishing	macOS	Exigir força de autenticação – MFA resistente a phishing
3	Utilizadores prontos para um sistema sem senha e resistente ao phishing no iOS	iOS	Exigir força de autenticação – MFA resistente a phishing
4	Utilizadores do Android prontos para um sistema sem senha resistente a phishing	Android	Exigir força de autenticação – MFA resistente a phishing
5	Outros utilizadores prontos para resistência ao phishing sem necessidade de palavra-passe	Qualquer um, exceto Windows, macOS, iOS ou Android	Exigir força de autenticação – MFA resistente a phishing

Adicione cada usuário a cada grupo à medida que você determina se o dispositivo e o sistema operacional deles 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 utilizadores sem palavra-passe

O Microsoft Entra ID Protection ajuda as organizações a detetar, investigar e corrigir riscos baseados em identidade. O Microsoft Entra ID Protection fornece deteções importantes e úteis para seus usuários, mesmo depois que eles passam a usar credenciais sem senha resistentes a phishing. Por exemplo, algumas deteções relevantes para utilizadores resistentes a phishing incluem:

Atividade do endereço IP anônimo
Administrador confirmou que o usuário foi comprometido.
Token anômalo
Endereço IP malicioso
Inteligência de ameaças do Microsoft Entra
Navegador suspeito
Atacante no meio
Possível tentativa de acessar o PRT (Primary Refresh Token)
E outros: Deteções de risco mapeadas para riskEventType

A Microsoft recomenda que os clientes do Microsoft Entra ID Protection tomem as seguintes ações para proteger melhor seus usuários sem senha resistentes a phishing:

Revise as diretrizes de implantação do Microsoft Entra ID Protection: Planejar uma implantação da Proteção de ID
Configure seus logs de risco para exportar para um SIEM
Investigar e agir em relação a qualquer risco médio de um utilizador
Configurar uma política de Acesso Condicional para bloquear usuários de alto risco

Depois de implantar a Proteção de ID do Microsoft Entra, considere usar a proteção de token de Acesso Condicional. À medida que os utilizadores iniciam sessão com credenciais sem palavra-passe resistentes a phishing, os ataques e as deteções continuam a evoluir. Por exemplo, quando as credenciais do usuário não podem mais ser facilmente roubadas, os invasores podem passar a tentar exfiltrar tokens dos dispositivos do usuário. A proteção de tokens ajuda a mitigar esse risco vinculando tokens ao hardware do dispositivo para o qual foram emitidos.

Próximos passos