Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Quando você implanta e operacionaliza a autenticação sem senha resistente a phishing em seu ambiente, recomendamos uma abordagem baseada em persona do usuário, mas isso pode variar dependendo de outros aspectos como o setor em que você está e o orçamento que você pode ter. Este guia de implantação ajuda você a ver quais tipos de métodos e planos de distribuição fazem sentido para os usuários em sua organização. A abordagem de implantação sem senha resistente a phishing tem várias etapas, mas não precisa ter 100% concluídas antes de passar para 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 as personas de usuário a seguir em sua organização.
| Persona do usuário | Descrição |
|---|---|
| Administradores e usuários altamente regulamentados | |
| Não-administradores |
A Microsoft recomenda que você implante vastamente a autenticação sem senha resistente a phishing em toda a organização. Recomendamos que você inicie sua implantação primeiro com uma das personas de usuário.
A Microsoft recomenda que você categorize seus usuários com base nessas personas e coloque os usuários em um grupo do Microsoft Entra ID 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çar a impor o uso de credenciais sem senha resistentes a phishing.
Usando grupos, você pode continuar a integrar novas partes da organização simultaneamente. 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.
Planejar a preparação do dispositivo
Os dispositivos são um aspecto essencial de qualquer implantação sem senha resistente a phishing bem-sucedida. Para garantir que seus dispositivos estejam prontos para a configuração de segurança resistente a phishing sem senha, atualize para as últimas versões suportadas de cada um dos sistemas operacionais. Para usar credenciais resistentes a phishing, seus dispositivos devem estar executando essas versões no mínimo:
- 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 se integram nativamente a recursos como chaves de acesso, 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.
Para obter mais detalhes, familiarize-se com o suporte FIDO2 para Microsoft Entra ID. Você pode usar a pasta de trabalho sem senha resistente a phishing (versão prévia) para entender a preparação do dispositivo em seu locatário.
Jornada resistente a phishing
Como parte da implantação de credenciais resistentes a phishing, você precisará considerar como os usuários são integrados, como eles obtêm suas credenciais portáteis e locais e como as credenciais resistentes a phishing são impostas em sua organização.
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.
Na tabela abaixo, você encontrará os diferentes tipos de credenciais e os métodos de autenticação associados que podem ser configurados na ID do Entra.
| Credenciais | Descrição | Benefícios | Métodos de autenticação |
|---|---|---|---|
| Portáteis | Pode ser usado em vários dispositivos. Você pode usar credenciais portáteis para entrar em outro dispositivo ou para registrar credenciais em outros dispositivos. | O tipo mais importante de credencial a ser registrado para a maioria dos usuários, pois podem ser usadas em vários dispositivos e fornecem autenticação resistente a phishing em muitos cenários. | |
| Local | Você pode usar credenciais locais para autenticar em um dispositivo sem precisar contar com hardware externo. | As credenciais locais fornecem uma ótima experiência do usuário, pois o usuário não precisa sair do dispositivo para se autenticar com êxito usando o gesto de desbloqueio do próprio dispositivo, como id facial ou face/impressão digital/PIN do Windows Hello para Empresas. |
- Para novos usuários, o processo de registro e inicialização conduz os usuários que não possuem 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 pode impor a autenticação resistente a phishing para usuários na ID do Microsoft Entra.
- Para usuários existentes, eles devem registrar-se para autenticação sem senha resistente a phishing em seus dispositivos existentes ou usar credenciais MFA existentes para configurar credenciais sem senha resistentes a phishing.
A meta final é a mesma para ambos os tipos de 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.
Observação
É sempre recomendável que os usuários tenham pelo menos dois métodos de autenticação registrados. Isso garante que o usuário tenha um método de backup disponível se algo acontecer com seu método principal, como em casos de perda ou roubo de dispositivo. Por exemplo, é uma boa prática que os usuários tenham uma chave de passagem registrada e uma credencial local, como o Windows Hello para Empresas, em sua estação de trabalho
Etapa 1: Verificação de identidade
Para usuários remotos que não provaram sua identidade, como novas contratações, 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:
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: 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. É uma prática recomendada usar a integração de ID verificada do Microsoft Entra para registrar um método de autenticação resistente a phishing usando um TAP (Passagem de Acesso Temporário).
Para novos usuários ou usuários sem MFA, passe por um processo para emitir aos usuários um TAP. 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 capacidade entre dispositivos permite que senhas portáteis sejam usadas para inicializar o Windows Hello para Empresas no computador Windows, ao usar um dispositivo associado ao Microsoft Entra ID e login pela Web para Windows.
A tabela a seguir lista as credenciais portáteis recomendadas para personas diferentes:
| Persona do usuário | Credencial portátil recomendada | Credenciais portáteis alternativas |
|---|---|---|
| Administradores e usuários altamente regulamentados | chaves de segurança FIDO2 | Chave de acesso para Microsoft Authenticator, autenticação baseada em certificado (Cartão Inteligente) |
| Qualquer outro usuário | Chave de acesso sincronizada | Chave de segurança FIDO2, chaves de passagem para o aplicativo Microsoft Authenticator |
A credencial de autenticação passkey pode ser definida para grupos de usuários específicos usando perfis de passkey. Um perfil passkey deve ser configurado para cada persona com a credencial portátil recomendada selecionada.
Use as diretrizes a seguir para habilitar credenciais portáteis recomendadas e alternativas para as personas de usuário relevantes para sua organização:
| Método | Diretrizes |
|---|---|
| chaves de segurança FIDO2 | |
| Chave de acesso sincronizada | |
| Chave de passagem no Microsoft Authenticator | |
| Autenticação baseada em certificado (CBA)/Cartões inteligentes |
Etapa 3: Inicializar credenciais locais
É recomendável 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 autenticação porque os usuários não precisam usar vários dispositivos e os usuários usam o gesto de desbloqueio do dispositivo para se autenticar.
Depois que o usuário tiver obtido sua credencial portátil, ele poderá ser usado para inicializar sua credencial local, o que permite que o usuário use credenciais resistentes a phishing nativamente em outros dispositivos que ele possa possuir.
Observação
Os usuários que compartilham dispositivos devem usar apenas credenciais portáteis.
Use a tabela abaixo para determinar qual tipo de credencial local é preferencial para cada persona de usuário:
| Persona do usuário | Credencial local recomendada – Windows | Credencial local recomendada - macOS | Credencial local recomendada - iOS | Credencial local recomendada - Android | Credencial local recomendada - Linux |
|---|---|---|---|---|---|
| Administradores e trabalhadores altamente regulamentados | Windows Hello para Empresas ou CBA | CBA ou chave do Secure Enclave no SSO da plataforma | Chave de acesso no Microsoft Authenticator ou CBA | Chave de acesso no Microsoft Authenticator ou CBA | N/A (use o cartão inteligente) |
| Não-administradores | Windows Hello para Empresas | Chave do Secure Enclave de Logon Único (SSO) da Plataforma | Chave de acesso sincronizada | Chave de acesso sincronizada | N/A (use a credencial portátil) |
Use as diretrizes a seguir para habilitar as credenciais locais recomendadas em seu ambiente para as personas de usuário relevantes para sua organização:
| Método | Diretrizes |
|---|---|
| Windows Hello para Empresas | |
| Credencial de Plataforma para macOS | |
| Chave de passagem no Microsoft Authenticator |
Considerações específicas da persona
Dentro de cada perfil, pode haver funções específicas, que terão seus próprios desafios e considerações. Você pode considerar a tabela abaixo, que contém diretrizes específicas para funções específicas em sua organização.
| Personagem | Funções de exemplo |
|---|---|
| Administradores | |
| Não administradores |
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 de usuário, e não apenas administradores, e usar tipos de dispositivo compatíveis.
- 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 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 piloto com administradores primeiro e, em seguida, implantação amplamente em grupos de usuários não administradores, mas isso pode mudar dependendo das necessidades da sua organização.
Use as seções a seguir para criar comunicações para o usuário final para cada grupo de personas, definir o escopo e implementar o recurso de registro de chave de acesso, assim como relatórios e monitoramento do usuário para rastrear o progresso da implementação.
Prontidão para condução com o Phishing-Resistant Workbook sem senha (Prévia)
Opcionalmente, as organizações podem optar por exportar seus logs de entrada do Microsoft Entra ID para o Azure Monitor para retenção de longo prazo, busca de ameaças e outras finalidades. A Microsoft lançou uma pasta de trabalho que as organizações com logs no Azure Monitor podem usar para ajudar com várias fases de uma implantação de sistema sem senha resistente ao phishing. A pasta de trabalho Phishing-Resistant sem senha pode ser acessada aqui: aka.ms/PasswordlessWorkbook. Escolha a pasta de trabalho intitulada Phishing-Resistant Implantação sem Senha (versão prévia):
A pasta de trabalho tem duas seções principais:
- Fase de preparação do registro
- Fase de preparação para a imposição
Fase de preparação do registro
Use a guia Fase de Preparação para Registro para analisar os logs de entrada em seu locatário, determinando quais usuários estão prontos para registro e quais usuários podem ser impedidos de se registrar. Por exemplo, com a guia Fase de Preparação de Registro, você pode selecionar o iOS como a plataforma do sistema operacional e, em seguida, passar a chave no Microsoft Authenticator 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 provavelmente terão problemas de registro e exportar a lista.
A guia Fase de Preparação para Inscrição da pasta de trabalho pode ajudar você a avaliar a prontidão para os seguintes sistemas operacionais e credenciais:
- Windows
- Windows Hello para Empresas
- Chave de segurança FIDO2
- Certificate-Based Autenticação/Cartão Inteligente
- macOS
- Chave do Secure Enclave para o SSO da plataforma
- Chave de segurança FIDO2
- Certificate-Based Autenticação/Cartão Inteligente
- Ios
- Chave de acesso sincronizada
- Chave de segurança FIDO2
- Chave de passagem no Microsoft Authenticator
- Certificate-Based Autenticação/Cartão Inteligente
- Android
- Chave de acesso sincronizada
- Chave de segurança FIDO2
- Chave de passagem no Microsoft Authenticator
- Certificate-Based Autenticação/Cartão Inteligente
Use cada lista exportada para triagem de usuários que podem 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 em que a opção preferencial não seja 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 passagem sincronizadas.
Da mesma forma, use o relatório de preparação de registro para ajudá-lo a criar listas de usuários que estão prontos para iniciar as comunicações e campanhas de registro, em alinhamento com sua estratégia de distribuição geral.
Fase de preparação para a imposição
Depois que os usuários estiverem prontos para autenticação resistente a phishing apenas, você poderá implementar a autenticação resistente a phishing, o que significa que eles precisarão executar MFA com credenciais resistentes a phishing para acessar recursos conforme sua política.
A primeira etapa da fase de preparação de imposição é criar uma política de Acesso Condicional no modo Report-Only. Essa política preencherá seus registros de acesso com dados sobre se o acesso seria ou não bloqueado caso você incluísse usuários/dispositivos no escopo da aplicação de medidas resistentes a phishing. Crie uma nova política de Acesso Condicional em seu locatário com estas configurações:
| Configurações | Valor |
|---|---|
| Atribuição de usuário/grupo | Todos os usuários, excluindo contas de quebra de vidro |
| Atribuição de Aplicativo | Todos os recursos |
| Conceder controles | Exigir força de autenticação – MFA resistente a phishing |
| Habilitar política | Somente relatório |
Crie essa política o mais cedo possível em sua implementação, de preferência antes mesmo de iniciar suas campanhas de inscrição. Isso garantirá que você tenha um bom conjunto de dados histórico de quais usuários e logons seriam bloqueados pela política caso fosse imposta.
Em seguida, use a pasta de trabalho para analisar onde os pares de usuário/dispositivo estão prontos para aplicação. Baixe listas de usuários que estão prontos para imposição e adicione-os a grupos criados em alinhamento com suas políticas de imposição. Comece selecionando a política de Acesso Condicional somente leitura no filtro de política:
O relatório fornecerá uma lista de usuários que teriam sido capazes de passar com êxito o requisito sem senha resistente a phishing em cada plataforma de dispositivo. Baixe cada lista e coloque os usuários apropriados em um 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. Eventualmente, você deve ser capaz de habilitar a política somente de relatório para fornecer imposição para todos os usuários e plataformas de dispositivo no locatário. Depois de atingir esse estado concluído, você poderá 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 não preparados para aplicação
Use a guia Análise de Dados Adicionais para investigar por que determinados usuários não estão prontos para imposição em várias plataformas. Selecione a caixa Política Não Satisfeita para filtrar os dados para entradas do usuário que teriam sido bloqueadas pela política de Acesso Condicional somente relatório.
Use os dados fornecidos por este relatório para determinar quais usuários teriam sido bloqueados, em qual sistema operacional do dispositivo eles estavam, em 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 imposiçã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 de autenticação inclui modelos de email 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:
- Chaves de acesso para suporte técnico
- Chaves de acesso em breve
- Registrar-se para a chave de acesso no Authenticator
- Lembrete para se registrar para a chave de acesso no Authenticator
As comunicações devem ser repetidas várias vezes para ajudar a capturar o maior número possível de usuários. Por exemplo, sua organização pode optar por comunicar as diferentes fases e cronogramas com um padrão como este:
- 60 dias após a imposição: envie uma mensagem sobre o valor dos métodos de autenticação resistentes a phishing e incentive os usuários a se inscreverem proativamente
- 45 dias após a imposição: repita a mensagem
- 30 dias após a aplicação: mensagem avisando que em 30 dias a aplicação resistente a phishing começará, incentive os usuários a se inscreverem proativamente
- 15 dias após a imposição: repita a mensagem, informe-os sobre como entrar em contato com o suporte técnico
- 7 dias após a imposição: repita a mensagem, informe-os sobre como entrar em contato com o suporte técnico
- 1 dia após a imposição: informe-os de que a imposição ocorrerá em 24 horas, e também sobre como entrar em contato com o suporte técnico
A Microsoft recomenda a comunicação com os usuários por meio de outros canais além do email. Outras opções podem incluir mensagens do Microsoft Teams, pôsteres em sala de descanso e programas de campeões em que funcionários selecionados são treinados para defender o programa para seus colegas.
Relatórios e monitoramento
Use a Phishing-Resistant Passwordless Workbook abordada anteriormente para ajudar no monitoramento e no relatório sobre seu lançamento. Além disso, use os relatórios discutidos abaixo ou confie neles se você não puder usar a pasta de trabalho sem senha do Phishing-Resistant.
Os relatórios do Microsoft Entra ID (como Atividade de Métodos de Autenticação e detalhes de eventos de entrada para autenticação multifator do Microsoft Entra) fornecem insights técnicos e de negócios que podem ajudar você a medir e impulsionar a adoção.
No painel de atividades Métodos de autenticação, você pode exibir o registro e o uso.
- Registro mostra o número de usuários capazes de autenticar com credenciais sem senha resistentes a phishing, bem como outros métodos de autenticação. Você pode ver gráficos que mostram quais os métodos de autenticação que os usuários registraram e o registro recente de cada método.
- Uso mostra quais métodos de autenticação foram usados para entrar.
Os proprietários de aplicativos técnicos e de negócios devem possuir e receber relatórios com base nos requisitos da organização.
- Acompanhe a distribuição de credenciais sem senha resistentes a phishing com os relatórios de atividades de registro de Métodos de Autenticação.
- Acompanhe a adoção do usuário de credenciais sem senha resistentes a phishing com os Métodos de Autenticação, relatórios de atividades de login e logs de login.
- Use o relatório de atividade de entrada para acompanhar os métodos de autenticação usados para entrar nos diversos aplicativos. Selecione a linha do usuário. Selecione Detalhes da autenticação para exibir o método de autenticação e sua atividade de entrada correspondente.
O Microsoft Entra ID adiciona entradas aos logs de auditoria quando:
- Um administrador altera os métodos de autenticação.
- Um usuário faz qualquer tipo de alteração em suas credenciais dentro do Microsoft Entra ID.
O Microsoft Entra ID retém a maioria dos dados de auditoria por 30 dias. Recomendamos a retenção mais longa para auditoria, análise de tendências e outras necessidades de negócios.
Acesse dados de auditoria no centro de administração ou na API do Microsoft Entra e faça o download em seus sistemas de análise. Se você precisar de uma retenção mais longa, exporte e consuma logs em uma ferramenta SIEM (Gerenciamento de eventos e informações de segurança), como o Microsoft Azure Sentinel, Splunk ou Sumo Logic.
Monitore o volume de tíquetes de suporte técnico
Seu suporte técnico de TI pode fornecer um sinal inestimável sobre o progresso da implantação, portanto, a Microsoft recomenda rastrear o volume de tíquetes do suporte técnico ao executar uma implantação sem senha resistente a phishing.
À medida que o volume de tíquetes de suporte técnico aumenta, você deve diminuir o ritmo de suas implantações, comunicações com usuários e ações de imposição. À medida que o volume de tíquetes diminui, você pode aumentar essas atividades novamente. O uso dessa abordagem requer que você mantenha flexibilidade no seu plano de distribuição.
Por exemplo, execute suas implantações e, em seguida, as imposições em ondas que têm intervalos de datas em vez de datas específicas:
- 1º a 15 de junho: implantação e campanhas de registro de coorte da onda 1
- 16 a 30 de junho: implantação e campanhas de registro de coorte da onda 2
- 1º a 15 de julho: implantação e campanhas de registro de coorte da onda 3
- 16 a 31 de julho: imposição do coorte da onda 1 ativada
- 1º a 15 de agosto: imposição do coorte da onda 2 ativada
- 16 a 31 de agosto: imposição do coorte da onda 3 ativada
Ao executar essas diferentes fases, pode ser necessário desacelerar, dependendo do volume de tíquetes de suporte técnico abertos e, em seguida, retomar quando o volume diminuir. Para executar essa estratégia, a Microsoft recomenda que você crie um grupo de segurança do Microsoft Entra ID para cada onda e adicione cada grupo às suas políticas, uma de cada vez. Essa abordagem ajuda a evitar a sobrecarga em suas equipes de suporte.
Impor métodos resistentes a phishing para entradas
A fase final de uma implantação sem senha resistente a phishing é impor o uso de credenciais resistentes a phishing.
Etapa 4: Implementação de resistência contra phishing em sistemas
Para impor credenciais resistentes ao phishing na ID do Microsoft Entra, o principal mecanismo é a utilização das forças 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:
- Administradores no Windows e no iOS
- Administradores no macOS e Android
- Qualquer outro usuário no Windows e no macOS
- Qualquer outro usuário no iOS e Android
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.
Use o Passwordless WorkbookPhishing-Resistant 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 à preparação para a imposição de entrada resistente a phishing nesse par de usuário/dispositivo.
| Tipo de SO | Pronto para a imposição | Não está pronto para a imposição |
|---|---|---|
| Windows | 10 e posteriores | 8.1 e anteriores, Windows Server |
| iOS | 17 e posteriores | 16 e anteriores |
| Android | 14 e posteriores | 13 e anteriores |
| macOS | 13 e posteriores (Ventura) | 12 e anteriores |
| VDI | Depende1 | Depende1 |
| Outro | Depende1 | Depende1 |
1 Para cada par de usuários/dispositivos em que a versão do dispositivo não estiver imediatamente pronta para a imposição, determine como lidar com a necessidade de impor a resistência ao phishing. Considere as seguintes opções para sistemas operacionais mais antigos, infraestrutura de área de trabalho virtual (VDI) e outros sistemas operacionais, como Linux:
- Imponha a resistência a phishing usando hardware externo – chaves de segurança FIDO2
- Imponha a resistência a phishing usando hardware externo – cartões inteligentes
- Imponha a resistência a phishing usando credenciais remotas, como chaves de acesso, no fluxo de autenticação entre dispositivos
- Imponha a resistência a phishing usando credenciais remotas dentro de túneis RDP (principalmente para VDI)
A principal tarefa é medir por meio de dados quais usuários e personas estão prontos para a imposição em plataformas específicas. Inicie suas ações de imposição em pares de usuários/dispositivos que estiverem prontos para a imposição, a fim de "interromper o sangramento" e reduzir o volume de autenticação de phishing que ocorre em seu ambiente.
Em seguida, passe para outros cenários em que os pares usuário/dispositivo exigem esforços de preparação. Percorra a lista de pares usuários/dispositivos até aplicar a autenticação resistente a phishing em todos os aspectos.
Crie um conjunto de grupos do Microsoft Entra ID para distribuir a imposição gradualmente. Reutilize os grupos da etapa anterior se você usou a abordagem de distribuição baseada em ondas.
Políticas recomendadas de acesso condicional para aplicação
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.
| Policy | Nome do grupo direcionado na política | Política – Condição da plataforma de dispositivo | Política – Controle de subsídios |
|---|---|---|---|
| 1 | Usuários prontos para senhas resistentes a phishing do Windows | Windows | Exigir força de autenticação: MFA resistente a phishing |
| 2 | Usuários prontos para credenciais sem senha resistentes a phishing do macOS | macOS | Exigir força de autenticação: MFA resistente a phishing |
| 3 | Usuários prontos para credenciais sem senha resistentes a phishing do iOS | iOS | Exigir força de autenticação: MFA resistente a phishing |
| 4 | Usuários prontos para Android sem senha resistentes a phishing | Android | Exigir força de autenticação: MFA resistente a phishing |
| 5 | Outros usuários prontos para credenciais sem senha resistentes a phishing | Qualquer, exceto Windows, macOS, iOS ou Android | Exigir força de autenticação: MFA resistente a phishing |
Adicione cada usuário a cada grupo ao determinar se o dispositivo e o sistema operacional estão prontos ou se eles não têm um dispositivo desse tipo. No final da distribuição, cada usuário deve estar em um dos grupos.
Responda ao risco para usuários sem senha
O Microsoft Entra ID Protection ajuda as organizações a detectar, investigar e corrigir riscos baseados em identidade. O Microsoft Entra ID Protection fornece detecções importantes e úteis para seus usuários, mesmo depois que eles mudam para o uso de credenciais sem senha resistentes a phishing. Por exemplo, algumas detecções relevantes para usuários resistentes a phishing incluem:
- Atividade de um endereço IP anônimo
- Usuário comprometido confirmado pelo administrador
- Token anormal
- Endereço IP mal-intencionado
- Inteligência contra ameaças do Microsoft Entra
- Navegador suspeito
- Attacker in the Middle
- Possível tentativa de acessar o PRT (token de atualização primário)
- E outras: Detecções de risco mapeadas para riskEventType
A Microsoft recomenda que os clientes do Microsoft Entra ID Protection tomem as seguintes medidas para proteger melhor seus usuários sem senha resistentes a phishing:
- Examine as diretrizes de implantação do Microsoft Entra ID Protection: Planejar uma implantação de Proteção de ID
- Configurar os logs de risco para exportar para um SIEM
- Investigue e aja mediante qualquer risco médio para o usuário
- Configurar uma política de Acesso Condicional para bloquear usuários de alto risco
Após implantar o Microsoft Entra ID Protection, considere usar a proteção por token do Acesso Condicional. À medida que os usuários fazem login com credenciais sem senha resistentes a phishing, os ataques e as detecções continuam a evoluir. Por exemplo, quando as credenciais do usuário não podem mais ser facilmente roubadas, os invasores podem tentar infiltrar os tokens dos dispositivos do usuário. A proteção por token ajuda a mitigar esse risco associando tokens ao hardware do dispositivo para o qual foram emitidos.