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

Quando você implanta e operacionaliza a autenticação sem senha resistente a phishing em seu ambiente, recomendamos uma abordagem baseada na persona do usuário. Diferentes métodos sem senha resistentes a phishing são mais eficazes do que outros para determinadas personas do usuário. Este guia de implantação ajuda você a ver quais tipos de métodos e planos de distribuição fazem sentido para as personas do usuário em seu ambiente. A abordagem de implantação sem senha resistente a phishing geralmente tem 6 etapas, que fluem mais ou menos em ordem, mas não precisam ser 100% concluídas antes de passar para as outras etapas:

Determine as personas do usuário

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

Persona do usuário Descrição
Operadores de informações
  • Os exemplos incluem as equipes de produtividade da empresa, como marketing, finanças ou recursos humanos.
  • Outros tipos de operadores de informações podem ser executivos e outros trabalhadores de alta confidencialidade que precisam de controles especiais
  • Normalmente há uma relação 1:1 com seus dispositivos móveis e de computação
  • O modo trazer seus próprios dispositivos (BYOD), principalmente para celulares
  • Trabalhadores na linha de frente
  • Exemplos incluem trabalhadores de lojas de varejo, trabalhadores de fábricas, trabalhadores da indústria de manufatura
  • Normalmente funcionam apenas em dispositivos compartilhados ou quiosques
  • Pode não ser permitido transportar telefones celulares
  • Profissionais de TI/operadores de DevOps
  • Os exemplos incluem administradores de TI para o Active Directory local, Microsoft Entra ID ou outras contas privilegiadas. Outros exemplos seriam profissionais de DevOps ou de DevSecOps que gerenciam e implantam automações.
  • Normalmente, existem várias contas de usuário, incluindo uma conta de usuário "normal" e uma ou mais contas administrativas
  • Comumente 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 automações e scripts não interativos
  • Trabalhadores altamente regulamentados
  • Os exemplos incluem funcionários 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
  • Telefones celulares podem não ser permitidos em áreas seguras
  • Pode acessar ambientes isolados sem conectividade com a Internet
  • Pode funcionar em dispositivos bloqueados com Bluetooth desativado
  • A Microsoft recomenda que você implante vastamente a autenticação sem senha resistente a phishing em toda a organização. Tradicionalmente, os operadores de informações são a persona do usuário mais fácil para começar. Faça a distribuição de credenciais seguras para os operadores de informações enquanto resolve os problemas que afetam os profissionais de TI. Adote a abordagem de "não deixar que o perfeito seja inimigo do bom" e implante credenciais seguras o máximo que puder. Quanto mais usuários entrarem usando as credenciais sem senha resistentes a phishing, mais você reduzirá a superfície de ataque do seu ambiente.

    A Microsoft recomenda que você defina suas personas e, em seguida, coloque cada persona em um grupo do Microsoft Entra ID, especificamente para essa persona do usuário. Esses grupos são usados em etapas posteriores para distribuir credenciais para diferentes tipos de usuários e quando você começar a impor o uso de credenciais sem senha resistentes a phishing.

    Planejar a preparação do dispositivo

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

    Prepare os dispositivos com a proteção resistente a phishing sem senha, corrigindo as versões mais recentes com suporte de cada sistema operacional. A Microsoft recomenda que seus dispositivos executem no mínimo estas versões:

    • Windows 10 22H2 (para Windows Hello para Empresas)
    • Windows 11 22H2 (para a melhor experiência de usuários que usarem as chaves de acesso)
    • macOS 13 Ventura
    • iOS 17
    • Android 14

    Essas versões fornecem o melhor suporte para recursos integrados nativamente, como senhas, Windows Hello para Empresas e Credencial da Plataforma macOS. Sistemas operacionais mais antigos podem exigir autenticadores externos, como chaves de segurança FIDO2, para oferecer suporte à autenticação sem senha resistente a phishing.

    Registrar usuários para credenciais resistentes a phishing

    O registro de credenciais e a inicialização são as primeiras grandes atividades voltadas para o usuário final em seu projeto de implantação sem senha resistente a phishing. Esta seção aborda a distribuição de credenciais portáteis e locais.

    Credenciais Descrição Benefícios
    Portáteis Pode ser usado em vários dispositivos. Você pode usar credenciais portáteis para entrar em outro dispositivo ou para registrar credenciais em outros dispositivos. O tipo mais importante de credencial a ser registrado para a maioria dos usuários, pois podem ser usadas em vários dispositivos e fornecem autenticação resistente a phishing em muitos cenários.
    Local Você pode usar credenciais locais para autenticar em um dispositivo sem precisar depender de hardware externo, como usar o reconhecimento biométrico do Windows Hello para Empresas para entrar em um aplicativo no navegador Microsoft Edge no mesmo computador Elas têm dois benefícios principais em relação às credenciais portáteis:
  • Fornecem 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 trabalhando em seu dispositivo de computação.
  • Eles oferecem uma ótima experiência do usuário. Com uma credencial local, os usuários não precisam tirar os telefones do bolso, escanear códigos QR ou realizar outras tarefas que retardam a autenticação e adicionam atrito. As credenciais resistentes a phishing disponíveis localmente ajudam os usuários a fazer login com mais facilidade nos dispositivos que usam regularmente.
    • Para novos usuários, o processo de registro e inicialização pega um usuário sem credenciais corporativas existentes e verifica sua identidade. Ele inicializa em sua primeira credencial portátil e usa essa credencial portátil para inicializar outras credenciais locais em cada um de seus dispositivos de computação. Após o registro, o administrador poderá impor a autenticação resistente a phishing para usuários no Microsoft Entra ID.
    • Para usuários existente, essa fase obriga os usuários a se registrarem para credenciais sem senha resistentes a phishing diretamente em seus dispositivos existentes ou usando credenciais de MFA existentes para inicializar credenciais sem senha resistentes a phishing. O objetivo final é o mesmo dos novos usuários: a maioria dos usuários deve ter pelo menos uma credencial portátil e, em seguida, credenciais locais em cada dispositivo de computação. Se você for um administrador que implanta senhas resistentes a phishing para usuários existentes, poderá pular para a seção Etapa 2 da integração: inicializar uma credencial portátil.

    Antes de começar, a Microsoft recomenda habilitar a chave de acesso e outras credenciais para usuários corporativos no locatário. Se os usuários estiverem motivados a se registrar para credenciais fortes, permita que façam isso. No mínimo, você deverá habilitar a política de chave de acesso (FIDO2) para que os usuários possam se registrar para chaves de acesso e chaves de segurança, se preferirem.

    Esta seção se concentra nas fases 1-3:

    Diagrama que mostra as três primeiras fases do processo de planejamento.

    Os usuários devem ter pelo menos dois métodos de autenticação registrados. Com outro método registrado, o usuário tem um método de backup disponível, caso aconteça algo com seu método principal, como quando um dispositivo é perdido ou roubado. Por exemplo, é uma boa prática que os usuários tenham chaves de acesso registradas em seus telefones e localmente em suas estações de trabalho no Windows Hello para Empresas.

    Observação

    É sempre recomendável que os usuários tenham pelo menos dois métodos de autenticação registrados. Isso garante que o usuário tenha um método de backup disponível se algo acontecer com seu método principal, como em casos de perda ou roubo de dispositivo. Por exemplo, é uma boa prática que os usuários tenham senhas registradas em seus telefones e localmente em suas estações de trabalho no Windows Hello para Empresas.

    Observação

    Essas diretrizes são adaptadas ao suporte atualmente existente para senhas no Microsoft Entra ID, que inclui senhas associadas ao dispositivo no Microsoft Authenticator e chaves de acesso associadas ao dispositivo em chaves de segurança físicas. O Microsoft Entra ID planeja adicionar suporte para senhas sincronizadas. Para obter mais informações, consulte Visualização pública: expandir o suporte à chave de acesso no Microsoft Entra ID. Este guia será atualizado para incluir orientações de chave de acesso sincronizadas, assim que estiverem disponíveis. Por exemplo, muitas organizações podem se beneficiar da sincronização para a fase 3 no diagrama anterior, em vez de inicializar credenciais totalmente novas.

    Etapa 1 da integração: verificação de identidade

    Para usuários remotos que não comprovaram sua identidade, a integração corporativa é um desafio significativo. A ID Verificada do Microsoft Entra pode ajudar os clientes que desejam verificação de ID de alta garantia. Ela pode usar atestados com base na ID emitida pelo governo como uma forma de estabelecer a confiança da identidade do usuário.

    Nesta fase, os usuários podem ser direcionados para um serviço de parceiro de verificação de identidade. Eles passam por um processo de revisão determinado pela organização e pelo serviço de parceiro de verificação escolhido pela organização. No final desse processo, os usuários recebem uma Senha de Acesso Temporária (TAP) que pode ser usado para inicializar a primeira credencial portátil.

    Consulte os guias a seguir para habilitar a integração de ID verificada do Microsoft Entra e a emissão de TAP:

    Observação

    A ID Verificada do Microsoft Entra faz parte da licença do Microsoft Entra Suite.

    Algumas organizações podem escolher outros métodos além da ID verificada do Microsoft Entra para integrar usuários e emitir sua primeira credencial. A Microsoft recomenda que essas organizações continuem a usar TAPs ou outras maneiras de permitir que um usuário se integre sem uma senha. Por exemplo, provisione chaves de segurança FIDO2 usando a API do Microsoft Graph (versão prévia).

    Etapa 2 de integração: inicializar uma credencial portátil

    Para inicializar os usuários existentes para credenciais sem senha resistentes a phishing, primeiro determine se os usuários já estão registrados na MFA tradicional. Os usuários com métodos tradicionais de MFA registrados podem ser direcionados com políticas de registro sem senha resistentes a phishing. Eles podem usar a MFA tradicional para se registrar para a primeira credencial portátil resistente a phishing e, em seguida, se registrar para credenciais locais, conforme necessário.

    Para novos usuários ou usuários sem MFA, passe por um processo de emissão de uma Senha de Acesso Temporária (TAP) para os usuários. Você pode emitir um TAP da mesma forma que fornece aos novos usuários sua primeira credencial ou usando integrações de ID verificada do Microsoft Entra. Depois que os usuários tiverem um TAP, eles estarão prontos para inicializar sua primeira credencial resistente a phishing.

    É importante que a primeira credencial sem senha do usuário seja uma credencial portátil que possa ser usada para autenticar em outros dispositivos de computação. Por exemplo, as senhas podem ser usadas para autenticar localmente em um telefone iOS, mas também podem ser usadas para autenticar em um PC com Windows usando um fluxo de autenticação entre dispositivos. Essa funcionalidade entre dispositivos permite que essa chave de acesso portátil seja usada para inicializar o Windows Hello para Empresas no computador Windows.

    Também é importante que cada dispositivo no qual o usuário trabalha regularmente tenha uma credencial disponível localmente para oferecer ao usuário a experiência de usuário mais tranquila possível. As credenciais disponíveis localmente reduzem o tempo necessário para autenticar porque os usuários não precisam usar vários dispositivos e há menos etapas. O uso do TAP da Etapa 1 para registrar uma credencial portátil que inicialize essas outras credenciais permite que o usuário use credenciais resistentes a phishing nativamente nos vários dispositivos que possuem.

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

    Persona do usuário Credencial portátil recomendada Credenciais portáteis alternativas
    Operador de informações Chave de acesso (Aplicativo Authenticator) Chave de segurança, cartão inteligente
    Trabalhador da linha de frente Chave de segurança Chave de acesso (aplicativo do Authenticator), cartão inteligente
    Profissional de TI/DevOps Chave de acesso (Aplicativo Authenticator) Chave de segurança, cartão inteligente
    Trabalhador altamente regulamentado Certificado (cartão inteligente) Chave de acesso (aplicativo do Authenticator), chave de segurança

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

    Método Diretrizes
    Chaves de acesso
  • A Microsoft recomenda que os usuários entrem no Microsoft Authenticator diretamente para inicializar uma chave de acesso no aplicativo.
  • Os usuários podem usar o TAP para entrar no Microsoft Authenticator diretamente em seu dispositivo iOS ou Android.
  • As chaves de acesso estão desabilitadas por padrão no Microsoft Entra ID. Você pode habilitar senhas na política de métodos de autenticação.
  • Registrar 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 as chaves de segurança FIDO2 na política de métodos de autenticação.
  • Considere registrar as chaves em nome de seus usuários com as APIs de provisionamento do Microsoft Entra ID. Para obter mais informações sobre como usar esse recurso, confira: Provisionar chaves de segurança FIDO2 usando a API do Microsoft Graph (versão prévia).
  • Autenticação baseada em certificado (CBA)/Cartões inteligentes
  • A autenticação baseada em certificado é mais complicada de configurar do que as senhas ou outros métodos. Considere usá-lo apenas se necessário.
  • Como configurar a autenticação baseada em certificado do Microsoft Entra.
  • Configure as políticas de CBA do Microsoft Entra ID e PKI local, para que os usuários concluam a autenticação multifator para entrar. A configuração geralmente exige o OID (Identificador de Objeto de Política) de cartão inteligente e as configurações de associação de afinidades necessárias. Para configurações de 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 um relacionamento 1:1, o que beneficia a experiência diária do usuário. Esse tipo de credencial é comum para operadores de informações e profissionais de TI, mas não para trabalhadores na linha de frente que compartilham dispositivos. Os usuários que compartilham apenas dispositivos devem usar apenas credenciais portáteis.

    Sua organização precisa determinar qual tipo de credencial é preferencial para cada persona de usuário neste estágio. A Microsoft recomenda:

    Persona do usuário Credencial local recomendada – Windows Credencial local recomendada - macOS Credencial local recomendada - iOS Credencial local recomendada - Android Credencial local recomendada - Linux
    Operador de informações Windows Hello para Empresas Chave do Secure Enclave de Logon Único (SSO) da Plataforma Chave de acesso (Aplicativo Authenticator) Chave de acesso (Aplicativo Authenticator) N/A (use a credencial portátil)
    Trabalhador da linha de frente N/A (use a credencial portátil) N/A (use a credencial portátil) N/A (use a credencial portátil) N/A (use a credencial portátil) N/A (use a credencial portátil)
    Profissional de TI/DevOps Windows Hello para Empresas Chave do Secure Enclave para o SSO da plataforma Chave de acesso (Aplicativo Authenticator) Chave de acesso (Aplicativo Authenticator) N/A (use a credencial portátil)
    Trabalhador altamente regulamentado Windows Hello para Empresas ou CBA CBA ou chave do Secure Enclave no SSO da plataforma Chave de acesso (Aplicativo Authenticator) ou CBA Chave de acesso (Aplicativo Authenticator) ou CBA N/A (use o cartão inteligente)

    Use as diretrizes a seguir para habilitar as credenciais locais recomendadas em seu ambiente para as personas de usuário relevantes para sua organização:

    Método Diretrizes
    Windows Hello para Empresas
  • A Microsoft recomenda usar o método Cloud Kerberos Trust para implantar o Windows Hello para Empresas. Para obter mais informações, consulte o Guia de implantação da Confiança do Kerberos na Nuvem. O método Cloud Kerberos Trust se aplica a qualquer ambiente no qual os usuários são sincronizados do Active Directory local para o Microsoft Entra ID. Ele ajuda usuários sincronizados em computadores que ingressaram no Microsoft Entra ou no Microsoft Entra híbrido.
  • O Windows Hello para Empresas só deve ser usado quando cada usuário em um computador estiver entrando nesse computador como ele mesmo. Ele não deve ser usado em dispositivos de quiosque que usam uma conta de usuário compartilhada.
  • Windows Hello para Empresas dá suporte a até 10 usuários por dispositivo. Se seus dispositivos compartilhados precisarem oferecer suporte a mais usuários, use uma credencial portátil, como chaves de segurança.
  • A biometria é opcional, mas recomendada. Para obter mais informações, consulte Preparar usuários para provisionar e usar o Windows Hello para Empresas.
  • Chave do Secure Enclave para o SSO da plataforma
  • O SSO da plataforma oferece suporte a 3 métodos diferentes de autenticação de usuário (chave do Secure Enclave, cartão inteligente e senha). Implante o método de chave Secure Enclave para espelhar seu Windows Hello para Empresas em Macs.
  • O SSO da plataforma requer que os Macs estejam registrados 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 do MDM se você usar outro serviço MDM em 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 usuários usam o TAP para entrar no Microsoft Authenticator diretamente em seu dispositivo iOS ou Android.
  • As senhas 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.
  • Registrar chaves de acesso no Authenticator em dispositivos Android ou iOS.
  • Considerações específicas da persona

    Cada persona tem seus próprios desafios e considerações que geralmente surgem durante implantações sem senha resistentes a phishing. Ao identificar quais personas você precisa acomodar, leve em consideração esses fatores do planejamento do projeto de implantação. Os links a seguir têm orientações específicas para cada persona:

    Promova o uso de credenciais resistentes a phishing

    Esta etapa aborda como facilitar a adoção de credenciais resistentes a phishing pelos usuários. Você deve testar a estratégia de implantação, planejar a distribuição e comunicar o plano aos usuários finais. Em seguida, crie relatórios e monitore o progresso antes de aplicar credenciais resistentes a phishing em toda a sua organização.

    Estratégia de teste e implantação

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

    • Crie uma lista de usuários de teste e adotantes iniciais. Esses usuários devem representar suas diferentes personas, e não apenas os administradores de TI.
    • Crie um grupo do Microsoft Entra ID e adicione seus usuários de teste a esse grupo.
    • Habilite suas políticas de métodos de autenticação no Microsoft Entra ID e defina o escopo do grupo de teste para os métodos habilitados.
    • Meça a distribuição de registro para os usuários piloto usando o relatório Atividade dos Métodos de Autenticação.
    • Crie políticas de Acesso Condicional para impor o uso de credenciais sem senha resistentes a phishing em cada tipo de sistema operacional, e direcione ao seu grupo piloto.
    • Meça o sucesso da imposição usando o Azure Monitor e as Pastas de Trabalho.
    • Reúna comentários dos usuários sobre o sucesso da distribuição.

    Planejar estratégia de distribuição

    A Microsoft recomenda direcionar o uso com base em quais personas de usuário estão mais prontas para implantação. Normalmente, isso significa implantar para usuários nesta ordem, mas isso pode mudar dependendo da sua organização:

    1. Operadores de informações
    2. Trabalhadores na linha de frente
    3. Profissionais de TI/operadores de DevOps
    4. Trabalhadores altamente regulamentados

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

    Planear as comunicações com os usuários finais

    A Microsoft fornece modelos de comunicação para usuários finais. O material de distribuição da autenticação inclui pôsteres personalizáveis e modelos de email para informar os usuários sobre a implantação da autenticação sem senha resistente a phishing. Use os seguintes modelos para se comunicar com seus usuários para que eles entendam a implantação sem senha resistente a phishing:

    As comunicações devem ser repetidas várias vezes para ajudar a capturar o maior número possível de usuários. Por exemplo, sua organização pode optar por comunicar as diferentes fases e cronogramas com um padrão como este:

    1. 60 dias após a imposição: envie uma mensagem sobre o valor dos métodos de autenticação resistentes a phishing e incentive os usuários a se inscreverem proativamente
    2. 45 dias após a imposição: repita a mensagem
    3. 30 dias após a aplicação: mensagem avisando que em 30 dias a aplicação resistente a phishing começará, incentive os usuários a se inscreverem proativamente
    4. 15 dias após a imposição: repita a mensagem, informe-os sobre como entrar em contato com o suporte técnico
    5. 7 dias após a imposição: repita a mensagem, informe-os sobre como entrar em contato com o suporte técnico
    6. 1 dia após a imposição: informe-os de que a imposição ocorrerá em 24 horas, e também sobre como entrar em contato com o suporte técnico

    A Microsoft recomenda a comunicação com os usuários por meio de outros canais além do email. Outras opções podem incluir mensagens do Microsoft Teams, pôsteres em sala de descanso e programas de campeões em que funcionários selecionados são treinados para defender o programa para seus colegas.

    Relatórios e monitoramento

    Os relatórios do Microsoft Entra ID (como Atividade de Métodos de Autenticação e detalhes de eventos de entrada para autenticação multifator do Microsoft Entra) fornecem insights técnicos e de negócios que podem ajudar você a medir e impulsionar a adoção.

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

    • Registro mostra o número de usuários capazes de autenticar com credenciais sem senha resistentes a phishing, bem como outros métodos de autenticação. Você pode ver gráficos que mostram quais os métodos de autenticação que os usuários registraram e o registro recente de cada método.
    • Uso mostra quais métodos de autenticação foram usados para entrar.

    Os proprietários de aplicativos técnicos e de negócios devem possuir e receber relatórios com base nos requisitos da organização.

    • Acompanhe a distribuição de credenciais sem senha resistentes a phishing com os relatórios de atividades de registro de Métodos de Autenticação.
    • Acompanhe a adoção do usuário de credenciais sem senha resistentes a phishing com os Métodos de Autenticação, relatórios de atividades de login e logs de login.
    • Use o relatório de atividade de entrada para acompanhar os métodos de autenticação usados para entrar nos diversos aplicativos. Selecione a linha do usuário. Selecione Detalhes da autenticação para exibir o método de autenticação e sua atividade de entrada correspondente.

    O Microsoft Entra ID adiciona entradas aos logs de auditoria quando:

    • Um administrador altera os métodos de autenticação.
    • Um usuário faz qualquer tipo de alteração em suas credenciais dentro do Microsoft Entra ID.

    O Microsoft Entra ID retém a maioria dos dados de auditoria por 30 dias. Recomendamos a retenção mais longa para auditoria, análise de tendências e outras necessidades de negócios.

    Acesse dados de auditoria no centro de administração ou na API do Microsoft Entra e faça o download em seus sistemas de análise. Se você precisar de uma retenção mais longa, exporte e consuma logs em uma ferramenta SIEM (Gerenciamento de eventos e informações de segurança), como o Microsoft Azure Sentinel, Splunk ou Sumo Logic.

    Monitore o volume de tíquetes de suporte técnico

    Seu suporte técnico de TI pode fornecer um sinal inestimável sobre o progresso da implantação, portanto, a Microsoft recomenda rastrear o volume de tíquetes do suporte técnico ao executar uma implantação sem senha resistente a phishing.

    À medida que o volume de tíquetes de suporte técnico aumenta, você deve diminuir o ritmo de suas implantações, comunicações com usuários e ações de imposição. À medida que o volume de tíquetes diminui, você pode aumentar essas atividades novamente. O uso dessa abordagem requer que você mantenha flexibilidade no seu plano de distribuição.

    Por exemplo, execute suas implantações e, em seguida, as imposições em ondas que têm intervalos de datas em vez de datas específicas:

    1. 1º a 15 de junho: implantação e campanhas de registro de coorte da onda 1
    2. 16 a 30 de junho: implantação e campanhas de registro de coorte da onda 2
    3. 1º a 15 de julho: implantação e campanhas de registro de coorte da onda 3
    4. 16 a 31 de julho: imposição do coorte da onda 1 ativada
    5. 1º a 15 de agosto: imposição do coorte da onda 2 ativada
    6. 16 a 31 de agosto: imposição do coorte da onda 3 ativada

    Ao executar essas diferentes fases, pode ser necessário desacelerar, dependendo do volume de tíquetes de suporte técnico abertos e, em seguida, retomar quando o volume diminuir. Para executar essa estratégia, a Microsoft recomenda que você crie um grupo de segurança do Microsoft Entra ID para cada onda e adicione cada grupo às suas políticas, uma de cada vez. Essa abordagem ajuda a evitar a sobrecarga em suas equipes de suporte.

    Impor métodos resistentes a phishing para entradas

    Esta seção se concentra na fase 4.

    Diagrama que destaca a fase de imposição da implantação.

    A fase final de uma implantação sem senha resistente a phishing é impor o uso de credenciais resistentes a phishing. Os principais mecanismos para fazer isso no Microsoft Entra ID são os pontos fortes de autenticação do Acesso Condicional. A Microsoft recomenda que você aborde a imposição de cada persona com base em uma metodologia do par usuário/dispositivo. Por exemplo, uma implementação de imposição pode seguir este padrão:

    1. Operadores de informações no Windows e iOS
    2. Operadores de informações no macOS e Android
    3. Profissionais de TI no iOS e Android
    4. É executado em iOS e Android
    5. FLWs no Windows e macOS
    6. Profissionais de TI no Windows e macOS

    A Microsoft recomenda que você crie um relatório de todos os pares usuário/dispositivo usando dados de entrada do seu locatário. Você pode usar ferramentas de consulta como o Azure Monitor e as Pastas de Trabalho. No mínimo, tente identificar todos os pares de usuário/dispositivo que correspondem a essas categorias.

    Para cada usuário, crie uma lista de quais sistemas operacionais eles usam regularmente para trabalhar. Mapeie a lista à preparação para a imposição de entrada resistente a phishing nesse par de usuário/dispositivo.

    Tipo de SO Pronto para a imposição Não está pronto para a imposição
    Windows 10 e posteriores 8.1 e anteriores, Windows Server
    iOS 17 e posteriores 16 e anteriores
    Android 14 e posteriores 13 e anteriores
    macOS 13 e posteriores (Ventura) 12 e anteriores
    VDI Depende1 Depende1
    Outro Depende1 Depende1

    1 Para cada par de usuários/dispositivos em que a versão do dispositivo não estiver imediatamente pronta para a imposição, determine como lidar com a necessidade de impor a resistência ao phishing. Considere as seguintes opções para sistemas operacionais mais antigos, infraestrutura de área de trabalho virtual (VDI) e outros sistemas operacionais, como Linux:

    • Imponha a resistência a phishing usando hardware externo – chaves de segurança FIDO2
    • Imponha a resistência a phishing usando hardware externo – cartões inteligentes
    • Imponha a resistência a phishing usando credenciais remotas, como chaves de acesso, no fluxo de autenticação entre dispositivos
    • Imponha a resistência a phishing usando credenciais remotas dentro de túneis RDP (principalmente para VDI)

    A principal tarefa é medir por meio de dados quais usuários e personas estão prontos para a imposição em plataformas específicas. Inicie suas ações de imposição em pares de usuários/dispositivos que estiverem prontos para a imposição, a fim de "interromper o sangramento" e reduzir o volume de autenticação de phishing que ocorre em seu ambiente.

    Em seguida, passe para outros cenários em que os pares usuário/dispositivo exigem esforços de preparação. Percorra a lista de pares usuários/dispositivos até aplicar a autenticação resistente a phishing em todos os aspectos.

    Crie um conjunto de grupos do Microsoft Entra ID para distribuir a imposição gradualmente. Reutilize os grupos da etapa anterior se você usou a abordagem de distribuição baseada em ondas.

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

    Política Nome do grupo direcionado na política Política – Condição da plataforma de dispositivo Política – Controle de subsídios
    1 Usuários prontos para senhas resistentes a phishing do Windows Windows Exigir força de autenticação: MFA resistente a phishing
    2 Usuários prontos para credenciais sem senha resistentes a phishing do macOS macOS Exigir força de autenticação: MFA resistente a phishing
    3 Usuários prontos para credenciais sem senha resistentes a phishing do iOS iOS Exigir força de autenticação: MFA resistente a phishing
    4 Usuários prontos para Android sem senha resistentes a phishing Android Exigir força de autenticação: MFA resistente a phishing
    5 Outros usuários prontos para credenciais sem senha resistentes a phishing Qualquer, exceto Windows, macOS, iOS ou Android Exigir força de autenticação: MFA resistente a phishing

    Adicione cada usuário a cada grupo ao determinar se o dispositivo e o sistema operacional estão prontos ou se eles não têm um dispositivo desse tipo. No final da distribuição, cada usuário deve estar em um dos grupos.

    Responda ao risco para usuários sem senha

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

    • Atividade de um endereço IP anônimo
    • Usuário comprometido confirmado pelo administrador
    • Token anormal
    • Endereço IP mal-intencionado
    • Inteligência contra ameaças do Microsoft Entra
    • Navegador suspeito
    • Attacker in the Middle
    • Possível tentativa de acessar o PRT (token de atualização primário)
    • E outras: Detecções de risco mapeadas para riskEventType

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

    1. Examine as diretrizes de implantação do Microsoft Entra ID Protection: Planejar uma implantação de Proteção de ID
    2. Configurar os logs de risco para exportar para um SIEM
    3. Investigue e aja mediante qualquer risco médio para o usuário
    4. Configurar uma política de acesso condicional para bloquear usuários de alto risco

    Após implantar o Microsoft Entra ID Protection, considere usar a proteção por token do Acesso Condicional. À medida que os usuários fazem login com credenciais sem senha resistentes a phishing, os ataques e as detecções continuam a evoluir. Por exemplo, quando as credenciais do usuário não podem mais ser facilmente roubadas, os invasores podem tentar infiltrar os tokens dos dispositivos do usuário. A proteção por token ajuda a mitigar esse risco associando tokens ao hardware do dispositivo para o qual foram emitidos.

    Próximas etapas

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