Este artigo inclui respostas para perguntas frequentes sobre o Microsoft Entra ID Protection. As seções de perguntas frequentes incluem: detecções, credenciais vazadas, correção, licenciamento e usuários B2B.
Para obter mais informações, consulte a visão geral da Proteção contra IDs do Microsoft Entra.
Detections
Como posso simular o risco para entender por que um usuário está sendo sinalizado?
Temos um guia de como simular o risco. Este guia fornece várias opções para simular diferentes tipos de risco. Você também pode usar a ferramenta WhatIf de Acesso Condicional para ver como as políticas específicas são aplicadas. We also recommend turning on Conditional Access policies in Report-Only mode to understand how policies work in the tenant without affecting your users' ability to access the resources they need.
Acabei de receber um alerta de alto risco, mas eles não estão aparecendo na pasta de trabalho "Análise de impacto de políticas baseadas em risco". Why?
Se o usuário tiver um alto risco atribuído, mas ainda não tiver entrado, você não os verá neste relatório. O relatório usa apenas logs de entrada para preencher esses dados.
E se as credenciais incorretas foram usadas para tentar entrar?
O Identity Protection gera detecções de risco somente quando as credenciais corretas são usadas. Se credenciais incorretas forem usadas em uma entrada, isso não representará o risco de comprometimento de credenciais.
A sincronização de hash de senha é necessária?
Detecções de risco como credenciais vazadas exigem a presença de hashes de senha para ocorrer. Para obter mais informações sobre a sincronização de hash de senha, consulte Implementar a sincronização de hash de senha com o Microsoft Entra Connect Sync.
Por que as detecções de risco são geradas para contas desabilitadas?
Primeiro, é importante saber que as contas de usuário em um estado desabilitado podem ser reenabled. Se as credenciais de uma conta desabilitada forem comprometidas e a conta for reabilitada, atores ruins podem usar essas credenciais para obter acesso. O Identity Protection gera detecções de risco para atividades suspeitas contra essas contas desabilitadas para alertar os clientes sobre o possível comprometimento da conta.
Se uma conta não estiver mais em uso e não for reenabled, os clientes deverão considerar excluí-la para evitar o comprometimento. Nenhuma detecção de risco é gerada para contas excluídas.
Tentei classificar o relatório detecções de risco usando a coluna "Tempo de detecção", mas não está funcionando.
Sorting by Detection time in the Risk detections report might not always give the correct result because of a known technical constraint. To sort by Detection time, open the report in the Microsoft Entra admin center and select Download to export the data as a CSV file and sort accordingly.
Onde a Microsoft encontra credenciais vazadas? Com que frequência eles são processados?
A Microsoft encontra credenciais vazadas em diversos locais, incluindo:
- Sites públicos de colagem em que os atores mal-intencionados normalmente publicam tal material.
- Agências de aplicação de leis.
- Outros grupos da Microsoft fazendo pesquisas na deep web.
As credenciais vazadas são processadas imediatamente após serem encontradas, normalmente em vários lotes por dia.
Por que não vejo credenciais vazadas?
As credenciais vazadas são processadas sempre que a Microsoft encontra um novo lote disponível publicamente. Devido à natureza confidencial, as credenciais vazadas são excluídas logo após o processamento. Only new leaked credentials found after you enable password hash synchronization (PHS) are processed against your tenant. A confirmação com os pares de credenciais encontrados anteriormente não é feita.
Para ver como as credenciais vazadas podem aparecer na Proteção de ID para seu locatário, tente simular credenciais vazadas no GitHub para Identidades de Carga de Trabalho. Para obter mais informações, consulte Simular detecções de risco no Microsoft Entra ID Protection.
Se não houver eventos de risco de credenciais vazadas, isso ocorreu devido aos seguintes motivos:
- Você não tem a sincronização de hash de senha habilitada para seu locatário.
- A Microsoft não encontrou pares de credenciais vazadas que correspondam aos seus usuários.
Remediation
Quando a Proteção contra IDs faz o autormediate do risco de entrada sem uma política baseada em risco em vigor?
A Proteção contra ID automatiza o risco de entrada quando o usuário fornece imediatamente um segundo fator, como a MFA (autenticação multifator) após sua entrada arriscada. Fornecer esse segundo fator compõe uma autenticação forte.
O ID Protection também opera dois modelos para avaliação de risco em entradas. O primeiro é o modelo em tempo real que usa informações limitadas para fazer uma determinação rápida durante a entrada. O segundo é um modelo offline que usa outros dados de entrada depois que a entrada é concluída. O modelo offline pode fechar o risco quando reavalia a pontuação de risco como segura. Essa avaliação se aplica a detecções offline e em tempo real de qualquer nível de risco.
Quando a Proteção contra IDs faz o autormediar o risco do usuário sem uma política baseada em risco em vigor?
A Proteção contra IDs requena usuários com baixo risco de usuário após seis meses sem elevação de risco do usuário. Usuários arriscados com risco médio ou alto não são resolvidos automaticamente sem uma política de risco ou demissão de administrador.
E se eu não usar o Microsoft Entra para autenticação multifator?
Se você não usar a autenticação multifator do Microsoft Entra, ainda poderá ver o risco de entrada corrigido em seu ambiente se você usar um provedor de MFA que não seja da Microsoft. Métodos de autenticação externa possibilitam corrigir o risco ao usar um provedor de MFA que não seja da Microsoft.
Quais são os melhores controles de Acesso Condicional para contas sem senha?
Confira nossas diretrizes sobre como implantar a autenticação sem senha resistente a phishing: Introdução a uma implantação de autenticação sem senha resistente a phishing
Devemos adicionar "Impor frequência de entrada – todas as vezes" às nossas políticas de Acesso Condicional para alto risco?
Essa configuração depende da tolerância a riscos da sua organização. Algumas organizações podem optar por bloquear o alto risco. Impor a entrada sempre pode levar à entrada ou à fadiga da MFA, o que pode aumentar a chance de um ataque de phishing.
We also recommend turning on Conditional Access policies in Report-Only mode to understand how policies work in the tenant without affecting your users' ability to access the resources they need. Você também pode verificar a análise de impacto da pasta de trabalho de políticas baseadas em risco na Proteção contra IDs.
E se eu estiver em um ambiente híbrido?
O risco do usuário pode ser auto remediado usando uma alteração de senha segura se a redefinição de senha de autoatendimento estiver habilitada com write-back de senha. Se apenas a sincronização de hash de senha estiver habilitada, considere habilitar a redefinição de senha local para corrigir o risco do usuário.
Para obter mais informações, consulte Como corrigir riscos e desbloquear usuários.
Se eu implantar uma política de risco, o sistema fará o autoremediar os usuários de forma diferente ou será necessário refazer as correções passadas?
O sistema depende dos controles de concessão especificados na política de Acesso Condicional para todas as correções. Essa abordagem orientada por políticas oferece mais controle sobre o acesso aos recursos. Se a política de risco do usuário exigir um bloco, o Acesso Condicional imporá isso. Se a política de risco de entrada exigir MFA, o Acesso Condicional imporá um novo desafio de MFA (quando não houver nenhuma declaração de MFA em um token existente). Portanto, se Alice sempre teve suas entradas arriscadas autoremediadas graças a outra política de MFA, nada muda em sua experiência de usuário quando você implanta uma política de risco que requer MFA.
Licensing
Que licença preciso para usar o Microsoft Entra ID Protection?
Há vários recursos no Microsoft Entra ID Protection que exigem licenças diferentes. Por exemplo, você pode obter informações limitadas no relatório de entradas arriscadas com a licença do Microsoft Entra ID Free, mas obtém acesso total a esses relatórios com o Microsoft Entra ID P2 ou a licença do Microsoft Entra Suite. Para obter mais informações, consulte os requisitos de licença da Proteção contra IDs do Microsoft Entra.
O Microsoft Entra ID Protection também usa sinais de produtos do Microsoft Defender licenciados separadamente. Para obter mais informações, confira O que é o Microsoft Entra ID Protection?.
B2B users
Por que não é possível corrigir usuários de colaboração B2B suspeitos no meu diretório?
A avaliação e a correção de risco para usuários B2B ocorrem em seu diretório inicial, para que os usuários convidados não apareçam no relatório de usuários arriscados no diretório de recursos. Os administradores no diretório de recursos não podem forçar uma redefinição de senha segura para esses usuários.
O que fazer se um usuário de colaboração B2B for bloqueado devido a uma política baseada em risco em minha organização?
Se um usuário B2B arriscado em seu diretório for bloqueado por sua política baseada em risco, o usuário precisará corrigir esse risco em seu diretório base. Os usuários podem corrigir seus riscos executando uma redefinição de senha segura em seu diretório inicial. Se eles não tiverem a redefinição de senha de autoatendimento habilitada em seu diretório inicial, eles precisarão entrar em contato com a equipe de TI de sua própria organização para que um administrador descarte manualmente o risco ou redefina sua senha. Para obter mais informações, consulte Correção do risco do usuário.
Como impedir que políticas baseadas em risco afetem usuários de colaboração B2B?
A exclusão de usuários B2B das políticas de Acesso Condicional baseadas em risco da sua organização impede que os usuários B2B sejam afetados pela avaliação de risco. Para excluir os usuários B2B, crie um grupo no Microsoft Entra ID que contenha todos os usuários convidados da sua organização. Em seguida, adicione esse grupo como uma exclusão para suas políticas internas de risco de usuário e de risco de entrada da Proteção de ID e quaisquer políticas de Acesso Condicional que usem o risco de entrada como condição.