Ataques baseados em identidade deixam de ser teóricos. Campanhas de phishing da IA, roubo de tokens e proxies adversários mudaram fundamentalmente o design do Acesso Condicional. A detecção sem recuperação forçada é insuficiente. A proteção moderna da identidade deve focar na contenção imediata e na remediação.
A Microsoft introduziu recentemente um novo controle de subvenções no Acesso Condicional chamado Exigir remediação de riscos. Esse controle muda a forma como as organizações podem responder ao risco detectado pelo usuário.
Este artigo explica o que ela faz, como difere das políticas tradicionais de usuários arriscadas e por que ela é importante em cenários de ataque modernos.
Requisito de licenciamento
Exigir remediação de riscos depende das capacidades de Proteção de ID do Microsoft Entra e, portanto, exige o licenciamento Microsoft Entra ID P2 para os usuários mencionados.
A política de remediação gerenciada da Microsoft não pode funcionar sem o Entra ID P2 porque a avaliação de risco do usuário e os fluxos automatizados de remediação fazem parte da Proteção de Identidade.Índice
Como o risco era tratado anteriormente
Historicamente, a Microsoft Entra ID Protection também oferecia suas próprias políticas de risco integradas, separadas do Acesso Condicional. Essas políticas de Proteção de Identidade permitiram que administradores configurassem respostas de login arriscado e de usuário arriscado diretamente dentro da lâmina de Proteção de Identidade.
No entanto, essas apólices legadas de risco de Proteção de Identidade serão aposentadas em 1º de outubro deste ano. Portanto, transferir totalmente a fiscalização baseada em risco para o Acesso Condicional não é mais opcional. É uma transição arquitetônica obrigatória para organizações que dependem do risco do usuário e controles de risco de login.
Em muitos ambientes, a configuração normalmente era a seguinte:
- Política de login arriscada para todos os usuários
Controle de subsídios: Exigir MFA - Política de usuário arriscado apenas para usuários
internos Conceder controle: Exigir mudança
de senha Usuários convidados excluídos, já que o risco vem do inquilino de origem e sem licença não pode ser remediado.
Quando os ataques de phishing da AiTM aumentaram, controles adicionais frequentemente foram adicionados:
- Bloqueie o acesso quando o risco do usuário ou de login for alto
Embora essa abordagem funcione, ela tem limitações:
- A MFA nem sempre remedia o risco do usuário
- A mudança de senha pressupõe autenticação baseada em senha
- Usuários sem senha não são tratados de forma consistente
- Bloquear aumenta a pressão do helpdesk
- Os fluxos de remediação variam dependendo do método de autenticação
O resultado é frequentemente sobrecarga operacional e comportamento inconsistente entre os tipos de identidade.
O que a remediação de riscos faz
A Microsoft Entra ID Protection gerencia o fluxo de remediação apropriado com base na ameaça observada e no método de autenticação do usuário. Ao contrário das políticas de usuário legadas e arriscadas, onde os administradores configuravam explicitamente a mudança de senha ou requisitos de MFA, a lógica de remediação é selecionada dinamicamente pela plataforma com base no risco detectado e no modelo de autenticação em uso.
O novo Exigir controle de concessão de remediação de riscos introduz a lógica de remediação gerenciada da Microsoft.
É importante entender explicitamente que esse controle remedia o risco do usuário, não o risco de login. Se uma política for configurada para avaliar o risco de assinatura, esse controle de concessão não libera esse sinal. Ele foi projetado para resolver riscos associados ao objeto do usuário, conforme determinado pela Microsoft Entra ID Protection.
Quando o risco do usuário é detectado:
- O usuário deve remediar imediatamente
- A sessão atual é revogada
- O usuário é forçado a fazer login novamente
- O risco é eliminado após a reautenticação bem-sucedida
Quando esse controle de concessão é selecionado, o Acesso Condicional se aplica automaticamente:
- Exigir força de autenticação
- Frequência de login definida para Toda vez
Essas configurações são aplicadas automaticamente por dois motivos importantes:
- Os usuários devem ser solicitados a se reautenticar após a revogação de suas sessões. Sem a frequência de login configurada como Every time, um token previamente emitido ainda poderia atender aos requisitos da sessão.
- Exigir força de autenticação garante que tanto usuários baseados por senha quanto sem senha estejam devidamente cobertos pela política de remediação. Isso garante a aplicação consistente entre os modelos de autenticação.
Se um usuário acabou de fazer login e o risco for detectado depois, ele é solicitado novamente imediatamente. Não há período de espera. Sem janela de graça.
A remediação torna-se imediata e determinística.
https://learn.microsoft.com/pt-br/entra/identity/conditional-access/concept-conditional-access-grant
Como a remediação difere entre métodos de autenticação
Autenticação
Com senha: Usuário arriscado tem uma detecção ativa de risco, como credencial vazada, spray de senha ou histórico de sessão envolvendo uma senha comprometida. O usuário é solicitado a realizar uma alteração de senha segura e, ao concluir, suas sessões anteriores são revogadas.
Autenticação
Sem senha: Usuário arriscado tem uma detecção ativa de risco, mas não envolve uma senha comprometida. Possíveis detecções de risco incluem token anômalo, viagem impossível ou propriedades de registro desconhecidas. As sessões do usuário são revogadas e ele é solicitado a fazer login novamente.
O que a Microsoft afirma sobre esse controle
A Microsoft descreve esse recurso como uma política de remediação gerenciada pela Microsoft que acomoda todos os métodos de autenticação, incluindo autenticação baseada e sem senha.
Quando um usuário é obrigado a remediar riscos:
- As sessões são revogadas
- A força de autenticação é aplicada
- A frequência de entrada é definida como Toda vez
- O usuário deve autenticar com sucesso novamente
Somente após a reautenticação bem-sucedida o risco do usuário é considerado remediado.
Isso garante que a remediação seja orientada pela autenticação e consistente entre os modelos de autenticação.
Por que isso importa em cenários de ataque modernos
Ataques modernos de phishing, como o AiTM, não apenas roubam credenciais. Eles capturam os tokens da sessão. Se uma sessão permanecer válida após a detecção de risco, os atacantes podem continuar operando.
A remediação de riscos exige resolver isso por meio de:
- Revogação de sessões ativas
- Forçando a reautenticação imediata
- Aplicando a força de autenticação
- Eliminação do risco somente após verificação bem-sucedida
Isso interrompe cenários de replay de tokens e reduz a janela de oportunidade para os atacantes.
Ela fecha uma lacuna em que a detecção de risco sozinha não foi suficiente para invalidar sessões ativas.
Impacto no projeto de Acesso Condicional
Com esse novo controle disponível, o design de Acesso Condicional pode ser simplificado e padronizado. Em vez de sobrepor controles compensatórios ao longo do tempo, as organizações podem alinhar a resposta ao risco com um modelo claro de remediação primeiro e bloqueio quando necessário.
Em vez de combinar:
- Registro arriscado exigindo MFA
- Usuário arriscado que exige mudança de senha
- Alto risco exigindo bloqueio
As organizações podem se mover para:
- Detecção de riscos que requer remediação de riscos
- Risco confirmado ou extremo que exige bloqueio
Isso separa a remediação da negação total e reduz a dependência de fluxos de recuperação baseados em senha.
Para organizações que adotam autenticação sem senha como parte de uma estratégia de segurança Zero Trust ou baseada em baseline, isso é particularmente importante. A remediação não está mais atrelada a construções de senhas legadas, mas sim à força de autenticação e controle de sessão.
Considerações importantes antes de permitir
Antes de implementar Exigir remediação de riscos:
- Revise a configuração da força de autenticação
- Entenda o impacto da reautenticação forçada
- Validar a estratégia de comunicação do usuário
- Teste no modo apenas de relatório
- Monitore os relatórios de Proteção de Identidade após a implementação
Embora poderoso, esse controle altera a experiência do usuário e o comportamento das sessões. Recomenda-se uma implementação controlada.
Considerações adicionais sobre plataforma:
- Se um usuário for designado tanto a uma política com Exigir remediação de riscos quanto a outra política que impõe Exigir mudança de senha ou Bloqueio, pode ocorrer um conflito. Isso pode resultar em o usuário sendo forçado a seguir múltiplos caminhos de remediação ou bloqueado completamente. Garanta que cada usuário seja alvo de apenas uma política de remediação por vez.
- A definição Exigir remediação de risco resolve apenas o risco do usuário. Não resolve o risco de registro de registro.
- O ID de Carga de Trabalho Arriscado não é suportado por esse controle de concessão.
- Usuários externos e convidados devem continuar se auto-remediando por meio de reset seguro da senha. O Microsoft Entra ID não suporta revogação de sessões para usuários externos e convidados porque o risco deles se origina em seu inquilino residencial.
- O controle de subsídios Exigir Remediação de Riscos está disponível no Azure para ambientes do governo dos EUA.
Considerações finais
A remediação de riscos em ambientes modernos de identidade não pode mais depender exclusivamente de mecanismos reativos, como redefinição manual de senha ou aplicação isolada de MFA. O cenário atual exige uma mudança estrutural de abordagem, migrando de um modelo de bloqueio pontual para um modelo de auto-remediação controlada, orquestrada por plataforma e orientada por risco contextual.
Em um ambiente amplamente impactado por ataques de Adversary-in-the-Middle (AiTM), roubo e replay de tokens de sessão, a simples alteração de credenciais não é suficiente para neutralizar a ameaça. Nesses casos, o atacante pode já possuir tokens válidos emitidos anteriormente, mantendo acesso persistente mesmo após a troca de senha.
Portanto, controles como:
- Invalidação imediata de sessões ativas
- Revogação de tokens
- Forçar reautenticação baseada em risco
- Reavaliação dinâmica de condições de acesso
tornam-se elementos essenciais de uma estratégia de contenção eficaz.
Se a estratégia atual de mitigação ainda está centrada predominantemente em redefinição de senha e aplicação de MFA tradicional, é importante reconhecer que esse modelo já não cobre adequadamente vetores modernos de comprometimento de sessão. O novo modelo de remediação baseado em sinal de risco oferece uma abordagem mais consistente, resiliente e alinhada às ameaças contemporâneas.
Segurança, hoje, não se limita à capacidade de detectar comportamentos suspeitos. O diferencial competitivo está na capacidade de:
- Aplicar recuperação de forma automática
- Garantir consistência entre todos os métodos de autenticação
- Reduzir tempo de exposição
- Evitar complexidade operacional desnecessária
Sob uma perspectiva arquitetural, a remediação eficiente exige uma estrutura de Acesso Condicional limpa, centralizada e sustentável, onde:
- A lógica de decisão baseada em risco está consolidada em políticas claras
- A invalidação de sessões ocorre automaticamente diante de sinais críticos
- Tokens comprometidos são revogados de forma transparente
- Estratégias passwordless (FIDO2, Passkeys, Windows Hello for Business) são plenamente suportadas
Em resumo, a maturidade de segurança não está apenas na detecção do risco, mas na capacidade da plataforma de responder de forma orquestrada, automática e sustentável — protegendo identidades sem comprometer a experiência do usuário ou a governança operacional.
Referências
- Exigir controle de subsídios
de remediação de riscos https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-grant#require-risk-remediation - Exigir remediação de riscos com a Microsoft managed remediation preview
https://learn.microsoft.com/en-us/entra/id-protection/concept-identity-protection-policies#require-risk-remediation-with-microsoft-managed-remediation-preview - https://www.vansurksum.com/2026/02/20/require-risk-remediation-in-entra-conditional-access/
Blog do Chesley 