Ignorar os problemas conhecidos de risco do usuário
Ignorar o risco do usuário no Microsoft Entra ID Protection define o ator no histórico de risco do usuário no ID Protection como <nome do administrador com um hiperlink que aponta para a folha do usuário>.
No momento há um problema conhecido causando latência no fluxo para ignorar o risco do usuário. Se você tiver uma política de risco do usuário, ela deixará de ser aplicada aos usuários descartados alguns minutos após clicar em Ignorar o risco de usuário. No entanto, há atrasos conhecidos na experiência do usuário que atualizam o "Estado de risco" de usuários descartados. Como alternativa, atualize a página no nível do navegador para ver o Estado de risco mais recente do usuário.
Perguntas frequentes
Por que um usuário está em risco?
O artigo Como: investigar o risco fornece uma explicação de por que um usuário está em risco e como investigar mais.
Por que minha entrada foi bloqueada, mas o ID Protection não gerou uma detecção de risco?
As entradas podem ser bloqueadas por vários motivos. É importante observar que o ID Protection apenas gera detecções de risco quando as credenciais corretas são usadas na solicitação de autenticação. Se um usuário fornecer credenciais incorretas, isso não será sinalizado pelo ID Protection, pois não haverá risco de comprometimento de credenciais, a menos que um ator mal-intencionado use as credenciais corretas. Alguns motivos pelos quais um usuário pode ser impedido de entrar, mas que não geram uma detecção do ID Protection incluem:
- O IP pode ser bloqueado devido a atividades mal-intencionadas do endereço IP. A mensagem bloqueadas por IP não diferenciam se as credenciais estavam corretas ou não. Se o IP estiver bloqueado e as credenciais corretas não forem usadas, isso não vai gerar uma detecção do ID Protection.
- O Smart Lock pode bloquear a entrada na conta após várias tentativas com falha.
- Uma Política de Acesso Condicional pode ser imposta, usando condições diferentes de nível de risco para bloquear uma solicitação de autenticação.
Como posso obter um relatório de detecções de um tipo específico?
Vá para a exibição de detecções de risco e filtre por Tipo de detecção. Em seguida, você pode baixar esse relatório no formato .CSV ou .JSON usando o botão Download na parte superior. Para saber mais, veja o artigo Como: Investigar risco.
Por que não é possível definir meus níveis de risco para cada detecção de risco?
Os níveis de risco no ID Protection baseiam-se na precisão da detecção e são alimentados por nosso aprendizado de máquina supervisionado. Para personalizar qual experiência é apresentada aos usuários, os administradores podem configurar políticas de acesso condicional baseadas em risco.
Por que o local de uma entrada não corresponde àquele de onde o usuário realmente entrou?
O mapeamento de localização geográfica do IP é um desafio de toda a indústria. Se você achar que a localização listada no relatório de entradas não corresponde à localização real, entre em contato com o suporte da Microsoft.
Como posso fechar as detecções de risco específicas como fazia na interface do usuário antiga?
Você pode fornecer comentários sobre as detecções de risco confirmando a entrada vinculada como comprometida ou segura. Os comentários fornecidos na entrada assinalam todas as detecções feitas nessa entrada. Se desejar fechar as detecções que não estejam vinculadas a uma entrada, você poderá fornecer esse comentário no nível do usuário. Para obter mais informações, veja o artigo Como: Fornecer comentários de risco no Microsoft Entra ID Protection.
Até que ponto posso voltar no tempo para entender o que está acontecendo com meu usuário?
- A exibição de usuários suspeitos mostra a posição de risco de um usuário baseado em todas as entradas passadas.
- A exibição de entradas suspeitas mostra as entradas em risco nos últimos 30 dias.
- A exibição de detecções de risco mostra as detecções de risco feitas nos últimos 90 dias.
Como posso saber mais sobre uma detecção específica?
Todas as detecções de riscos são documentadas no artigo O que é risco. Você pode passar o mouse sobre o símbolo (i) ao lado da detecção para saber mais sobre uma detecção.
Como funcionam os mecanismos de feedback no ID Protection?
Confirmar como comprometido (em uma entrada) – Informa ao Microsoft Entra ID Protection que a entrada não foi executada pelo proprietário da identidade e indica um comprometimento.
Depois de receber seus comentários, movemos o estado de risco de entrada e de usuário para Confirmado como comprometido e o nível de risco para Alto.
Além disso, fornecemos as informações para nossos sistemas de aprendizado de máquina para futuras melhorias na avaliação de risco.
Observação
Se o usuário já foi corrigido, não clique em Confirmar como comprometido porque isso muda o estado de risco de entrada e de usuário para Confirmado como comprometido e o nível de risco para Alto.
Confirmar como seguro (em uma entrada) – Informa ao Microsoft Entra ID Protection que a entrada foi executada pelo proprietário da identidade e não indica um comprometimento.
Depois de receber esses comentários, movemos o estado de risco de entrada (não o de usuário) para Confirmado como seguro e o nível de risco para Nenhum.
Além disso, fornecemos as informações para nossos sistemas de aprendizado de máquina para futuras melhorias na avaliação de risco.
Observação
Hoje, a seleção de confirmação de segurança em uma entrada não impede que entradas futuras com as mesmas propriedades sejam sinalizados como suspeitas. A melhor maneira de treinar o sistema para aprender as propriedades de um usuário é usar a política de Acesso Condicional com risco de entrada e MFA. Quando uma entrada suspeita é solicitada para MFA e o usuário responde com êxito à solicitação, a entrada pode ter êxito e ajudar a treinar o sistema em relação ao comportamento legítimo do usuário.
Se você achar que o usuário não foi comprometido, use Ignorar o risco do usuário no nível do usuário em vez de usar Confirmado como seguro no nível da entrada. Um comando Ignorar o risco de usuário no nível do usuário fecha o risco do usuário e todas as últimas entradas suspeitas e detecções de risco.
Por que estou vendo um usuário com uma pontuação de risco baixa (ou acima), mesmo se não há entradas suspeitas ou detecções de risco mostradas no ID Protection?
Já que o risco de usuário é cumulativo por natureza e não expira, um usuário poderá ter um risco de usuário baixo ou superior, mesmo quando não há entradas suspeitas ou detecções de risco recentes mostradas no ID Protection. Isso poderá ocorrer se a única atividade mal-intencionada de um usuário tiver ocorrido depois do período de tempo no qual armazenamos os detalhes de entradas suspeitas e detecções de risco. Não expiramos o risco do usuário porque os agentes mal-intencionados são conhecidos por permanecer no ambiente dos clientes por longos períodos de tempo antes de aumentar o ataque. Os clientes podem avaliar a linha do tempo do risco do usuário para entender por que um usuário está correndo risco acessando Centro de administração do Microsoft Entra > Proteção > Proteção de Identidade > Usuários arriscados > selecionar um usuário em risco > gaveta de detalhes > Guia do histórico de riscos. Se você acreditar que o usuário não está comprometido, use Ignorar risco do usuário através da API do Graph.
Por que uma entrada tem uma pontuação de "risco de entrada (agregação)" alta quando as detecções associadas a ela são de risco baixo ou médio?
A pontuação de risco de agregação alta pode ser baseada em outros recursos de entrada ou o fato de que mais de uma detecção foi acionada para essa entrada. E, por outro lado, uma entrada pode ter um risco de entrada (agregação) médio, mesmo se as detecções associadas com a entrada são de alto risco.
Qual é a diferença entre as detecções de “Atividade de endereço IP anônimo” e “Endereço IP anônimo”?
A origem da detecção de “Endereço IP anônimo” é o Microsoft Entra ID Protection, enquanto a detecção de “Atividade de endereço IP anônimo” é integrada do Microsoft Defender for Cloud Apps. Embora eles tenham nomes muito parecidos e possam se sobrepor nesses sinais, eles têm detecções de back-end distintas.