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 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 Utilizador | Description |
|---|---|
| Técnicos de informação | |
| Trabalhadores da linha de frente | |
| Profissionais de TI/Trabalhadores de DevOps | |
| Trabalhadores altamente regulamentados |
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 a persona do usuário mais fácil de 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 | Description | 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. |
| Locais | 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: |
- 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 você for um administrador que implanta senhas sem senha resistentes a phishing para usuários existentes, talvez você possa pular para a seção Etapa 2 de integração: inicializando 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, você deve 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 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 usuário confiável esteja apresentando o ID Verificado de afirmação de 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:
- Integre novos funcionários remotos usando a verificação de ID
- Usando o Face Check com o Microsoft Entra Verified ID para desbloquear verificações de alta garantia em escala
- Ativar a política de Passe de Acesso Temporário
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 | |
| Chaves de segurança | |
| Autenticação baseada em cartão inteligente/certificado (CBA) |
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 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 (use credencial portátil em vez disso) |
| Trabalhador da linha de frente | N/D (use credencial portátil em vez disso) | N/D (use credencial portátil em vez disso) | N/D (use credencial portátil em vez disso) | N/D (use credencial portátil em vez disso) | N/D (use credencial portátil em vez disso) |
| Profissional de TI/DevOps | Windows Hello para empresas | Chave de enclave seguro SSO da plataforma | Chave de acesso (aplicativo autenticador) | Chave de acesso (aplicativo autenticador) | N/D (use credencial portátil em vez disso) |
| Trabalhador altamente regulamentado | Windows Hello para Empresas 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 | |
| Chave de enclave seguro 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, 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:
- Trabalhadores da informação
- Trabalhadores da linha de frente
- Profissionais de TI/trabalhadores de DevOps
- Trabalhadores altamente regulamentados
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 a distribuição de registro para seus usuários 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 em quais personas de usuário estão mais prontas para 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 com o usuário final para cada grupo de persona, escopo e distribuição, o recurso de registro de chaves de acesso e relatórios e monitoramento de usuários para acompanhar o progresso da implantaçã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 cartazes personalizáveis e modelos de e-mail 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:
- Início de sessão sem palavra-passe 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 do trabalho ou da escola usando informações de segurança
- Configurar uma chave de segurança como método de verificação
- Iniciar sessão nas contas com a aplicação Microsoft Authenticator
- Inicie sessão na sua conta escolar ou profissional utilizando o seu método de verificação em dois passos
- Início de sessão na conta escolar ou profissional bloqueado por restrições de inquilino
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 após a aplicação: mensagem de 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 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 após a aplicação: informá-los de que a aplicação ocorrerá em 24 horas, informá-los sobre como entrar em contato com o help desk
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
Os relatórios de ID do Microsoft Entra (como Métodos de Autenticação, Atividade e detalhes de eventos de entrada para 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 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.
- Rastreie a distribuição de credenciais sem senha resistentes a phishing com relatórios de atividades de registro de Métodos de Autenticação.
- Acompanhe a adoção pelo usuário de credenciais sem senha resistentes a phishing com os Métodos de Autenticação, inicie sessão em relatórios de atividade e inicie sessão em registos.
- 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 usuário; selecione Detalhes da autenticação para visualizar o método de autenticação e sua atividade de entrada 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 tíquetes do suporte técnico
O 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 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 a flexibilidade em seu plano de implantação.
Por exemplo, você pode executar suas implantações e, em seguida, 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: Aplicação da coorte da 1ª onda habilitada
- 1 a 15 de agosto: Aplicação da coorte da 2ª onda habilitada
- 16 a 31 de agosto: Aplicação da coorte da 3ª onda habilitada
À 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.
Aplique métodos resistentes a phishing para iniciar sessão
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 que você aborde a imposição para cada persona com base em uma metodologia de par usuário/dispositivo. Por exemplo, uma distribuiçã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
- FLWs em iOS e Android
- FLWs no Windows e macOS
- Profissionais de TI no Windows e macOS
A Microsoft recomenda que crie um relatório de todos os seus pares utilizador/dispositivo utilizando dados de início de sessão do seu inquilino. 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.
Para cada usuário, crie uma lista de quais sistemas operacionais eles usam regularmente para trabalhar. Mapeie a lista para a prontidão para a imposição de entrada resistente a phishing para esse par usuário/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 e anteriores |
| macOS | 13+ (Ventura) | 12 e anteriores |
| VDI | Depende1 | Depende1 |
| Outro | Depende1 | Depende1 |
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
- Aplique a resistência a phishing usando 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 suas ações de imposição em pares de usuário/dispositivo que estão prontos para imposição para "parar o sangramento" e reduzir a quantidade de autenticação phishable 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 de utilizadores/dispositivos até impor a autenticação resistente a phishing em toda a linha.
Crie um conjunto de grupos de ID do Microsoft Entra para implementar a aplicação gradualmente. Reutilize os grupos da etapa anterior se tiver usado a abordagem de distribuição baseada em ondas.
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 | Usuários prontos sem senha resistentes a phishing do Windows | Windows | Exigir força de autenticação – MFA resistente a phishing |
| 2 | Usuários prontos sem senha resistentes a phishing do macOS | macOS | Exigir força de autenticação – MFA resistente a phishing |
| 3 | Usuários prontos sem senha resistentes a phishing do iOS | iOS | Exigir força de autenticação – MFA resistente a phishing |
| 4 | Usuários prontos sem senha resistentes a phishing do Android | Android | Exigir força de autenticação – MFA resistente a phishing |
| 5 | Outros utilizadores prontos para phishing sem 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
- Usuário confirmado pelo administrador 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 do 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.