O Que É o Azure Identity Protection?
O Azure Identity Protection, agora Microsoft Entra ID Protection, é a camada de detecção e resposta a risco para identidades do Microsoft Entra. Ele avalia sinais que podem indicar comprometimento de conta e os expõe como risco do usuário, risco de login, usuários de risco e detecções de risco.
O ponto operacional importante é que a detecção sozinha não contém um ataque. Um tenant pode mostrar usuários de risco e logins de risco no portal e, ainda assim, permitir que o atacante continue, se nenhuma política exigir remediação, autenticação multifator, reautenticação, troca de senha ou bloqueio. Este artigo se concentra exatamente nessa lacuna: o risco é visível, mas a resposta do tenant está ausente, incompleta ou com escopo estreito demais.
A orientação atual da Microsoft coloca os controles baseados em risco no Acesso Condicional. As políticas de risco legadas do Identity Protection ainda existem em alguns tenants, mas a documentação da Microsoft afirma que as políticas legadas de risco do usuário e de risco de login devem ser migradas para o Acesso Condicional e estão programadas para aposentadoria em 1º de outubro de 2026.
Como o Azure Identity Protection Funciona
O Identity Protection usa dois conceitos de risco intimamente relacionados:
Risco de login é a probabilidade de que uma solicitação específica de autenticação não tenha sido feita pelo dono legítimo da identidade. Ele é avaliado durante o login e pode ser usado como condição de Acesso Condicional.
Risco do usuário é a probabilidade de que a própria conta do usuário esteja comprometida. Ele pode persistir além de um único login e pode exigir troca de senha, revogação de sessão, investigação do administrador ou dispensa.
A Microsoft documenta detecções de risco como credenciais vazadas, endereço IP anônimo, viagem atípica, propriedades de login incomuns, endereço IP malicioso, regras suspeitas de manipulação de caixa de entrada, password spray, token anômalo e outros sinais. Algumas detecções são em tempo real, enquanto outras são calculadas offline e podem aparecer depois. Esse tempo importa operacionalmente: um evento de risco pode surgir depois que a autenticação original já foi concluída.
Por Que as Políticas de Risco Falham na Prática
O Identity Protection rende menos do que poderia quando as equipes tratam o dashboard como se fosse o controle. Modos de falha comuns incluem:
- nenhuma política de Acesso Condicional usa condições de risco de login ou risco do usuário
- políticas permanecem em modo somente relatório depois dos testes
- políticas de risco cobrem usuários piloto, mas não usuários privilegiados nem a população geral
- contas de emergência são excluídas sem monitoramento compensatório
- usuários híbridos não conseguem concluir a autorremediação porque o password writeback não está disponível onde é necessário
- notificações de usuário de risco vão para uma caixa de entrada que ninguém revisa
- analistas podem dispensar risco sem um padrão de evidência documentado
- service principals são confundidos com cobertura de Acesso Condicional voltada a usuários
O último ponto é importante. As políticas de risco do usuário e de risco de login visam logins de usuários. O risco de workload identity e de service principal exige um modelo de controle diferente e não deve ser considerado coberto por políticas de risco do usuário humano.
A Cadeia de Ataque Sem Resposta a Risco
Cenário 1 – Credenciais Vazadas
As credenciais de um usuário aparecem em dados de vazamento ou são avaliadas como arriscadas por outro motivo. O Identity Protection eleva o risco do usuário, mas nenhuma política de risco do usuário exige remediação. A conta permanece utilizável até que outro controle bloqueie o atacante.
Cenário 2 – Login de Risco Que Ainda Assim É Concluído
Um login tem risco médio ou alto por causa de sinais como infraestrutura anônima, propriedades de login incomuns ou viagem atípica. Se nenhuma política de risco de login se aplica, a sessão ainda pode ser concluída. Existe um registro de log, mas o atacante já obteve acesso.
Cenário 3 – Password Spray Contra Contas Cloud
Uma campanha de password spray gera ruído amplo de autenticação e pode produzir detecções de risco. Se os logins bem-sucedidos não forem forçados a uma autenticação step-up ou bloqueados conforme a política, o atacante mantém as sessões bem-sucedidas.
Cenário 4 – Risco Dispensado Sem Investigação
Um usuário de risco é dispensado porque o alerta é inconveniente ou ruidoso. Se o processo de dispensa não exige evidências, o tenant pode normalizar um comprometimento real e remover justamente o sinal de que os defensores precisariam.
Detecção
Sinais de Risco a Monitorar
| Sinal | O Que Indica | Uso Operacional |
|---|---|---|
| Credenciais vazadas | Credenciais associadas à conta foram encontradas em material comprometido conhecido | Tratar como evidência de comprometimento de conta até revisão |
| Endereço IP anônimo | O login veio de infraestrutura de anonimização | Correlacionar com dispositivo, localização e histórico do usuário |
| Viagem atípica | A geografia do login é inconsistente com a atividade recente | Revisar padrões de viagem impossíveis ou suspeitos |
| Propriedades de login incomuns | O login difere do comportamento normal do usuário | Útil quando combinado com contexto de dispositivo e localização |
| Endereço IP malicioso | A infraestrutura de origem está associada a atividade maliciosa | Maior urgência para usuários privilegiados |
| Password spray | É detectado um comportamento amplo de tentativa de senhas | Correlacionar com bloqueios, falhas e logins bem-sucedidos |
| Token anômalo | O comportamento do token parece suspeito | Revisar atividade da sessão e revogar quando apropriado |
Eventos e Relatórios a Revisar
A detecção deve incluir:
- relatório de usuários de risco
- relatório de detecções de risco
- logs de login com nível de risco e detalhe do risco
- resultados de Acesso Condicional para logins de risco
- logs de auditoria para dispensa de risco, redefinição de senha, mudanças de política e ações de admin
- contexto de função privilegiada para as identidades afetadas
Um login de alto risco de um Administrador Global não tem a mesma prioridade operacional que um evento de baixo risco em uma conta de teste inativa. O alerta deve incluir função, dispositivo, localização, aplicativo, resultado da política e desfecho da sessão.
Remediação
O Identity Protection se torna útil quando o risco aciona uma resposta. Um dashboard sem Acesso Condicional aplicado é apenas visibilidade.
1. Configurar Políticas de Risco Separadas
A Microsoft recomenda não combinar condições de risco do usuário e risco de login na mesma política de Acesso Condicional. Crie políticas separadas para que cada condição de risco tenha um caminho de resposta claro.
Para risco de login, a Microsoft recomenda exigir autenticação multifator para risco médio e alto. Para risco do usuário, a Microsoft recomenda exigir remediação de risco quando o risco do usuário é alto. As organizações podem escolher limites mais rigorosos, mas precisam equilibrar segurança, falsos positivos e interrupção do usuário.
2. Usar o Modo Somente Relatório, Depois Aplicar
O modo somente relatório é útil para o rollout. Ele não é um estado final. Revise quais usuários, aplicativos e cenários seriam afetados, corrija quebras esperadas e depois mude a política para Ativado. Mantenha um registro datado do rollout para que políticas em modo somente relatório não se tornem permanentes sem uso real.
3. Fazer a Autorremediação Funcionar
A autorremediação depende de pré-requisitos. Os usuários precisam estar registrados para autenticação multifator do Microsoft Entra antes de conseguirem cumprir uma remediação baseada em MFA. Usuários híbridos podem exigir password writeback para cenários seguros de troca de senha. Se esses pré-requisitos estiverem ausentes, os usuários podem ficar bloqueados e precisar de intervenção do administrador.
4. Definir o Fluxo de Trabalho do Analista
Uma política de risco não substitui a investigação. Defina quem pode:
- confirmar o comprometimento do usuário
- dispensar risco do usuário
- redefinir senhas
- revogar sessões
- desbloquear usuários
- aprovar exceções
- atualizar os limites de risco do Acesso Condicional
Cada ação deve seguir um padrão de evidência. Dispensar um risco porque o usuário diz que estava viajando não é o mesmo que validar dispositivo, IP, método de autenticação e atividade da sessão.
5. Revisar Exceções e Contas de Serviço
Contas de acesso de emergência podem precisar de tratamento especial, mas as exceções devem ser poucas e fortemente monitoradas. Contas de serviço e workload identities não devem ser silenciosamente excluídas da conversa sobre risco; elas podem precisar de Acesso Condicional para workload identity, managed identities, rotação de credenciais ou monitoramento diferente.
Sequência de Implantação Segura
Uma implantação segura não começa bloqueando todo o tenant sem evidências. Comece com políticas em modo somente relatório para a população pretendida, revise o impacto da política, corrija os pré-requisitos de registro e password writeback, e depois aplique a política em estágios. Identidades privilegiadas devem ser priorizadas porque um login de risco bem-sucedido de um administrador tem um raio de impacto muito maior do que o mesmo evento em uma conta de baixo privilégio.
Mantenha o rollout mensurável. Acompanhe quantos logins de risco teriam sido bloqueados ou desafiados, quantos usuários conseguiram se autorremediar, quais contas estão excluídas e quais incidentes exigiram ação do administrador. Esses números ajudam a distinguir um programa de proteção funcional de uma política que existe, mas não pode ser aplicada com segurança.
Validação Após Ativar a Resposta a Risco
Valide o controle tanto pela perspectiva do portal quanto pela perspectiva do atacante:
- confirme que as políticas de risco de login e risco do usuário estão ativadas, não apenas configuradas
- confirme que os usuários-alvo incluem identidades privilegiadas e usuários normais no escopo
- confirme que os usuários excluídos estão documentados e monitorados
- revise os logins de risco recentes e verifique se o resultado de política pretendido foi aplicado
- confirme que logins bem-sucedidos de alto risco são raros, explicáveis e investigados
- confirme que os administradores conseguem confirmar comprometimento, dispensar risco, revogar sessões e redefinir credenciais usando fluxos de trabalho documentados
- teste o roteamento de alertas para que as notificações de usuário de risco cheguem à equipe de resposta
- revise se workload identities precisam de Acesso Condicional ou monitoramento separado
Se o tenant detecta risco, mas permite que usuários de risco continuem sem remediação, o controle está incompleto.
Como o EtcSec Detecta Isso
O EtcSec audita se as detecções de risco estão vinculadas a um caminho de resposta aplicado.
A categoria Risk Protection destaca a ausência de política de risco de login, a ausência de política de risco do usuário e uma resposta fraca do tenant, em que a atividade de risco é visível, mas a aplicação está ausente ou incompleta.
Essa é exatamente a lacuna operacional de que este artigo trata: detecções de risco sem contenção.
Controles Relacionados
O Identity Protection funciona melhor quando combinado com Segurança de Identidade Azure: Quando o MFA Não Basta, Falhas acesso condicional Entra ID: quais erros deixam uma exposicao real, Gerenciamento de Acesso Privilegiado no Azure: Riscos sem PIM, Contas de Convidado Azure: Riscos do Tenant e Registros de Aplicativo Azure: Apps com Privilegios Excessivos. Caso contrário, o tenant pode detectar risco, mas ainda deixar caminhos adjacentes de privilégio e aplicativo fáceis de explorar.
Referências Principais
Explore as paginas de identidade que sustentam este tema