Entra ID Protection na prática: automatizando políticas de risco de login com Microsoft Graph PowerShell

Se sua organização já migrou identidades para o Microsoft Entra ID (antigo Azure AD), você provavelmente já ouviu falar do Entra ID Protection: o módulo que detecta sinais de risco em tempo real — logins de localizações atípicas, credenciais vazadas, impossible travel, entre outros — e alimenta o Conditional Access para decidir se bloqueia, exige MFA ou libera o acesso. O problema é que configurar isso só pelo portal funciona bem para poucas políticas, mas não escala quando você precisa padronizar, auditar ou replicar configurações entre tenants. Neste artigo eu mostro como fazer essa automação com PowerShell e o Microsoft Graph SDK — do diagnóstico de usuários arriscados até a criação da política de Conditional Access baseada em risco.

O que é risco de usuário x risco de login

O Entra ID Protection trabalha com dois conceitos distintos, e entendê-los é o primeiro passo antes de automatizar qualquer coisa:

• User risk (risco do usuário): calculado com base em sinais acumulados, como credenciais vazadas (leaked credentials) encontradas pela Microsoft em bases de dados comprometidas na internet.[1]
• Sign-in risk (risco do login): avaliado em tempo real em cada tentativa de autenticação — por exemplo, login anônimo via proxy, propriedades de login atípicas ou impossible travel.[1]

Os dois níveis de risco possíveis são low, medium, high e none, e cada um pode ser usado como condição em uma política de Conditional Access separadamente.[5]

Atenção às licenças: políticas de risco (via Conditional Access ou Identity Protection) e os relatórios completos de riscos exigem Microsoft Entra ID P2 (ou Microsoft Entra Suite). Com Entra ID Free ou P1, você só vê informações limitadas de usuários e logins arriscados, sem o detalhamento completo nem a possibilidade de criar políticas de risco.[6] Confira isso antes de tentar replicar os passos abaixo em produção.

Pré-requisitos

• Microsoft Entra ID P2 (ou trial/Microsoft Entra Suite) no tenant.
• Módulo Microsoft.Graph.Identity.SignIns instalado:

Install-Module Microsoft.Graph.Identity.SignIns -Scope CurrentUser

• Conta com a role Conditional Access Administrator ou Security Administrator.
• Permissões delegadas necessárias: IdentityRiskyUser.ReadWrite.All, Policy.Read.All, Policy.ReadWrite.ConditionalAccess.[1]

Passo 1 — Investigar usuários e logins com risco detectado

Antes de criar qualquer política automática, é fundamental revisar o que já está sendo detectado — isso evita bloquear usuários legítimos por falso positivo.[1] Conecte-se ao Graph com as permissões corretas e liste os riscos:

Connect-MgGraph -Scopes "IdentityRiskyUser.ReadWrite.All","Policy.Read.All","Policy.ReadWrite.ConditionalAccess"

Import-Module Microsoft.Graph.Identity.SignIns

# Lista usuários marcados como arriscados
Get-MgRiskyUser

# Lista detecções de risco específicas (logins, eventos)
Get-MgRiskDetection

O Get-MgRiskyUser retorna o nível de risco atual de cada conta (riskLevel), o estado (riskState) e o histórico de detecções — dados que hoje só ficam completos com licenciamento P2.[3][6]

Passo 2 — Remediar ou confirmar um usuário manualmente

Depois de investigar, você pode confirmar que um usuário está de fato comprometido ou dispensar o risco (falso positivo) via Update-MgRiskyUser:

# Confirma que o usuário está comprometido
Update-MgRiskyUser -RiskyUserId "<id-do-usuario>" -RiskState "confirmedCompromised"

# Ou descarta o risco detectado (falso positivo)
Update-MgRiskyUser -RiskyUserId "<id-do-usuario>" -RiskState "dismissed"

Esse passo manual é importante antes de automatizar políticas de bloqueio em massa: você quer ter certeza de que o sinal de risco é confiável no seu ambiente antes de deixá-lo tomar decisões automaticamente.[1]

Passo 3 — Criar a política de Conditional Access baseada em risco

Com o cenário mapeado, a política de risco é criada via New-MgIdentityConditionalAccessPolicy. O exemplo abaixo exige MFA para logins com risco médio ou alto, permitindo autorremediação (o usuário comprova a identidade via MFA e a sessão é liberada):

$params = @{
  displayName = "Risco de login - Exigir MFA (medio/alto)"
  state       = "enabled"
  conditions  = @{
    signInRiskLevels = @("high", "medium")
    applications = @{
      includeApplications = @("All")
    }
    users = @{
      includeUsers = @("All")
      excludeUsers = @("<id-conta-break-glass>")
    }
  }
  grantControls = @{
    operator        = "OR"
    builtInControls = @("mfa")
  }
}

New-MgIdentityConditionalAccessPolicy -BodyParameter $params

Se preferir bloquear em vez de pedir MFA (cenário mais agressivo, recomendado só depois de validar o comportamento em modo "somente relatório"), basta trocar builtInControls para @("block").[5]

Ponto crítico de segurança: sempre exclua as contas de emergência/break-glass das políticas de risco. Se o Identity Protection classificar erroneamente uma conta administrativa crítica como de alto risco e bloquear o acesso, você pode ficar sem nenhum admin conseguindo entrar no tenant para corrigir a própria política.[1]

Passo 4 — Testar em modo "somente relatório" antes de aplicar

Uma prática recomendada é subir a política com state = "enabledForReportingButNotEnforced" em vez de "enabled". Isso permite observar, pelos relatórios "Impacto da Política" no Centro de Administração do Entra, quantos logins reais seriam afetados antes de aplicar o bloqueio ou a exigência de MFA de verdade.[6]

$params.state = "enabledForReportingButNotEnforced"
New-MgIdentityConditionalAccessPolicy -BodyParameter $params

Depois de alguns dias observando o relatório por política, você promove a política para "enabled" com confiança.

Passo 5 — Auditoria recorrente via script

Para manter governança contínua, um script simples agendado (via Agendador de Tarefas ou Azure Automation) pode listar periodicamente usuários de risco alto ainda não tratados, e notificar a equipe de segurança:

Connect-MgGraph -Scopes "IdentityRiskyUser.ReadWrite.All"

$riscosAltos = Get-MgRiskyUser | Where-Object { $_.RiskLevel -eq "high" -and $_.RiskState -eq "atRisk" }

if ($riscosAltos) {
    $riscosAltos | Select-Object UserPrincipalName, RiskLevel, RiskLastUpdatedDateTime |
        Export-Csv -Path "C:\Relatorios\usuarios_risco_alto.csv" -NoTypeInformation
}

Esse relatório em CSV pode alimentar um alerta por e-mail ou um ticket automático — fechando o ciclo entre detecção, decisão automatizada (Conditional Access) e acompanhamento humano.

Conclusão

O Entra ID Protection entrega sinais de risco valiosos, mas o valor real aparece quando esses sinais alimentam decisões automáticas via Conditional Access — e PowerShell com o Microsoft Graph SDK é o caminho para padronizar isso entre múltiplas políticas ou tenants, em vez de clicar manualmente no portal. Os pontos-chave:

• Separe risco de usuário (acumulado) de risco de login (em tempo real) — são condições diferentes na política.
• Exige Entra ID P2 para políticas de risco completas; valide o licenciamento antes de planejar o rollout.
• Sempre exclua contas break-glass das políticas de risco.
• Suba em modo "somente relatório" antes de aplicar bloqueio/MFA de verdade, e use o relatório de impacto por política para validar.
• Automatize a auditoria recorrente de usuários de risco alto com Get-MgRiskyUser para não depender só do portal.

Com esses passos, Identity Protection deixa de ser só um painel bonito no portal e passa a ser parte ativa e auditável da estratégia de Zero Trust do ambiente Microsoft 365/Azure.

Sources

[1] https://learn.microsoft.com/en-us/entra/id-protection/how-to-deploy-identity-protection — Plan a Microsoft Entra ID Protection deployment
[3] https://learn.microsoft.com/en-us/powershell/module/microsoft.graph.identity.signins/get-mgriskyuser?view=graph-powershell-1.0 — Get-MgRiskyUser (Microsoft Graph PowerShell)
[5] https://learn.microsoft.com/en-us/graph/tutorial-riskdetection-api — Identify and remediate risk using ID Protection APIs
[6] https://learn.microsoft.com/en-us/entra/architecture/id-protection-guide-introduction — Microsoft Entra ID Protection PoC guidance (licensing table)