De porteiro a vigilante: como unir a segurança pré e pós-autenticação

By Mirko Peters · 2026-08-11

Bem-vindo de volta ao podcast e ao nosso aprofundamento técnico que o acompanha! Se você já sentiu que sua estratégia de segurança de identidade tem um ponto cego logo depois que um usuário…

Automatically translated with AI from the original post. Read the English original

Bem-vindo de volta ao podcast e ao nosso aprofundamento técnico que acompanha o episódio! Se você já sentiu que a estratégia de segurança de identidade tem um ponto cego logo depois que um usuário faz login com sucesso, saiba que você definitivamente não está sozinho. Durante anos, as organizações confiaram fortemente em controles pré-autenticação para manter os invasores do lado de fora, tratando a porta de entrada como a última fronteira da segurança. Mas o que acontece quando um adversário atravessa essa porta com um token válido ou um conjunto de credenciais roubadas? Esse exato dilema foi o centro do nosso episódio recente, Conditional Access with Defender for Identity Signals. Neste post, vamos aprofundar esses conceitos e detalhar como você pode unir seu porteiro pré-autenticação ao seu vigilante pós-autenticação para construir uma arquitetura de identidade realmente resiliente.

O conceito central (TL;DR)

Para entender de verdade a proteção de identidade moderna, você precisa enxergar suas ferramentas como funções especializadas que trabalham juntas em tempo real:

• Conditional Access (CA) é o seu segurança da porta. Ele é excepcionalmente bom em tomar decisões pré-autenticação com base em quem está tentando entrar, de onde está vindo e na postura do dispositivo.
• Defender for Identity (DfI) é o seu sistema de CFTV combinado com a segurança do andar. Ele se destaca no monitoramento do comportamento pós-autenticação, do movimento lateral e das anomalias internas.
• A resiliência real só acontece quando o risco pós-autenticação eleva o atrito pré-autenticação automaticamente e de forma dinâmica—bem ali, durante a sessão.

Modelo mental

Vamos refinar o modelo mental de como esses componentes interagem dentro do seu ecossistema:

• Porteiro (CA): avalia quem está fazendo login, de onde, a postura do dispositivo e o risco no momento do login, e aplica controles de sessão imediatos.
• Vigilante (DfI + M365 Defender): procura movimento lateral, padrões anormais de acesso a recursos, Kerberoasting, abuso de NTLM e escalonamentos de privilégio inesperados.
• Ciclo de realimentação: o vigilante sinaliza comportamento suspeito, o que por sua vez eleva a pontuação de risco do usuário ou risco da sessão. Isso força o porteiro a apertar imediatamente os controles, exigindo MFA adicional, bloqueando o acesso por completo ou restringindo a sessão ativa.

Roteiro de integração (o que habilitar, em ordem)

Fazer esses sistemas conversarem entre si exige uma implantação estruturada. Aqui está o roteiro que você deve seguir:

1. CA com reconhecimento de risco (linha de base)
   • Entra ID Protection: ative a avaliação de risco do usuário e de risco de entrada.
   • Crie políticas de CA:
     • Bloquear quando o risco do usuário = Alto (ou exigir a troca de senha, se seus fluxos de trabalho da central de suporte permitirem).
     • Exigir MFA quando o risco de entrada ≥ Médio.
     • Exigir dispositivo em conformidade para aplicativos de sensibilidade média a alta; use filtros de dispositivo para endpoints não gerenciados, de modo a direcioná-los diretamente para controles de sessão restritos.
2. Deixe o vigilante conversar com o porteiro
   • Garanta que o DfI esteja transmitindo alertas ativamente para o Microsoft 365 Defender e para o Sentinel (se você o usa como SIEM/SOAR).
   • Automatize as ações de "Confirmar comprometido" sobre os usuários para alertas de alta gravidade do DfI. Isso define Risco do usuário = Alto no Entra ID Protection, fazendo com que suas políticas de CA reajam instantaneamente.
   • Caminho de automação: incidente do M365 Defender → Logic App ou Power Automate → API do Graph Security/Identity Protection (/riskDetections, /riskyUsers:confirmCompromised) → Forçar logout (opcional).
   • Ative a Avaliação Contínua de Acesso (CAE) em todos os aplicativos compatíveis (Exchange, SharePoint, Graph), para que as alterações de política realmente encerrem os tokens ativos.
3. Controle de sessão para contenção
   • Para sessões não gerenciadas ou arriscadas, implante o Defender for Cloud Apps (proxy de sessão) diretamente a partir do CA:
     • CA → Usar Conditional Access App Control (monitore primeiro e depois bloqueie a exfiltração de dados, como downloads, copiar e colar, impressão e sincronização).
   • Combine isso com MDE device risk → Intune compliance → CA "Require compliant device" para todas as aplicações sensíveis.
4. Proteções de identidades privilegiadas
   • O PIM deve impor acesso Just-in-Time; exija MFA + dispositivo em conformidade + nenhum estado de usuário arriscado antes que a elevação seja permitida.
   • Implemente uma política de CA para Bloquear funções privilegiadas se o risco do usuário for ≥ Baixo (sim, mesmo com risco Baixo) para forçar a triagem imediata antes que uma função administrativa possa ser assumida.

“Se isto, então aquilo”: mapeie os sinais do DfI para as ações do CA

Mapear sinais de detecção específicos do Defender for Identity para ações automatizadas de Acesso Condicional e de resposta une a observação passiva à defesa ativa:

Comece executando essas regras no modo auditoria/monitoramento por 1 a 2 semanas e, à medida que a confiança aumentar, mude as respostas para o modo aplicação (enforce) por classe de alerta.

Políticas de exemplo (práticas e mínimas)

Para colocar essas estratégias em produção, aqui estão quatro políticas fundamentais que você deve configurar:

1. Bloquear quando o risco do usuário = Alto
   • Atribuir: todos os usuários (excluindo contas de emergência), todos os aplicativos em nuvem
   • Condições: risco do usuário = Alto
   • Concessão: Bloquear acesso
2. Step-up com base no risco de entrada
   • Atribuir: todos os usuários, aplicativos de alto valor (portais de administração, Exchange, SharePoint, Centro de administração do Entra)
   • Condições: risco de entrada ≥ Médio
   • Concessão: Exigir MFA + Exigir dispositivo em conformidade (ou dispositivo gerenciado)
3. Conter sessão não gerenciada
   • Atribuir: todos os usuários, SharePoint/OneDrive/Teams
   • Estado do dispositivo: Híbrido/Em conformidade = ignorar; Não gerenciado = aplicar
   • Sessão: Usar Controle de Aplicativos de Acesso Condicional (bloquear downloads)
4. Proteção de elevação privilegiada
   • Atribuir: funções de diretório = funções administrativas privilegiadas
   • Condições: risco do usuário ≥ Baixo OU risco de entrada ≥ Médio
   • Concessão: Exigir MFA + Exigir dispositivo em conformidade; Bloquear se o risco for ≥ Alto

Playbooks de automação (prontos para implementar)

A automação é o diferencial que reduz seu Mean Time to Contain (MTTC). Aqui estão dois playbooks que você pode criar hoje:

Playbook A: alerta de alta severidade do DfI → conter a identidade

• Gatilho: incidente do M365 Defender marcado com IdentityThreatHigh
• Ações:
  1. Graph API – confirmar usuário comprometido (define o risco do usuário como Alto)
  2. Entra ID – revogar tokens de atualização imediatamente
  3. Intune/MDE – isolar dispositivo (se houver um único dispositivo principal associado)
  4. ServiceNow/JSM – criar um ticket de incidente com a linha do tempo e os artefatos coletados
  5. Notificar o SOC e o responsável pelo usuário por meio de um cartão adaptável no Teams com um botão de reversão em um clique, caso haja falsos positivos

Playbook B: rajada anômala de acesso ao SharePoint

• Gatilho: alerta do Defender “Download incomum de arquivo”
• Ações:
  1. Marcar o usuário com UnderInvestigation por meio de atributos de extensão do AAD
  2. Direcionar o usuário para uma política de CA que o encaminhe ao App Control (bloqueando downloads e impressão)
  3. Iniciar uma retenção de eDiscovery nos sites afetados do SharePoint (opcional, conforme as necessidades de conformidade)
  4. Expirar automaticamente a contenção em 72 horas, a menos que o SOC a prorroge manualmente

Caça e consultas úteis

A caça proativa ajuda você a identificar lacunas antes que os invasores as explorem. Use estas consultas no Advanced Hunting do M365 Defender:

Aumento de acesso a sites do SharePoint por um usuário em comparação com a linha de base de 30 dias:

let lookback=30d;
let recent=1h;
let baseline = CloudAppEvents
    | where Timestamp between (ago(lookback) .. ago(recent))
    | where Application == "SharePoint" and ActionType == "FileAccessed"
    | summarize uniqSites=dcount(SiteUrl) by AccountUpn;
CloudAppEvents
| where Timestamp >= ago(recent)
| where Application == "SharePoint" and ActionType in ("FileDownloaded","FileAccessed")
| summarize curSites=dcount(SiteUrl), dls=sumif(1, ActionType=="FileDownloaded") by AccountUpn
| join kind=leftouter baseline on AccountUpn
| where curSites > 3 * coalesce(uniqSites,1) or dls > 500

Picos de risco de entrada diretamente associados a alertas posteriores do DfI:

let riskySignIns = IdentityLogonEvents
| where RiskLevelDuringSignIn in ("medium","high")
| project AccountUpn, Timestamp, RiskLevelDuringSignIn;
let dfiAlerts = IdentityDirectoryEvents
| where EventType startswith "DefenderForIdentity"
| project AccountUpn, DfiTime=Timestamp, AlertType=EventType;
riskySignIns
| join kind=inner dfiAlerts on AccountUpn
| where DfiTime between (Timestamp .. Timestamp + 4h)

Métricas que comprovam que funciona

Ao reportar à liderança, você precisa de métricas que demonstrem redução tangível de risco. Acompanhe estes indicadores-chave de desempenho:

• Tempo médio para contenção (MTTC) em incidentes de identidade (tempo desde a geração do alerta até a aplicação da CA) ↓
• Tempo de permanência do invasor (tempo desde a primeira ação suspeita até a remediação completa) ↓
• Sessões arriscadas bloqueadas (eventos disparados por política) ↑ enquanto a taxa de falsos positivos ↓
• Idade do backlog de usuários de risco (casos abertos há mais de 24 horas) ↓
• Latência de revogação de tokens (medida em segundos) ↓
• Falhas de elevação privilegiada por risco (detectadas cedo, antes que ocorram danos) ↑ e depois estabilizando com o tempo
• Secure Score em Identidade, Dispositivos e Aplicativos ↑ sem aumento correspondente de chamados na central de suporte

Estratégia de implantação em 30/60/90 dias

Evite tentar mudar tudo de uma vez. Use este cronograma em fases:

Dias 0–30 (Fundamentos)

• Ative as configurações de risco de usuário e de entrada no Entra e implante as políticas de referência do CA em modo de auditoria, depois passe para o modo de imposição.
• Integre o Defender for Identity ao M365 Defender; valide os alertas e o mapeamento das entidades principais.
• Ative a Avaliação Contínua de Acesso (CAE) para os aplicativos compatíveis e integre o risco de dispositivo do MDE à conformidade do Intune.

Dias 31–60 (Feedback e Contenção)

• Crie os Playbooks A e B no Logic Apps e teste-os extensivamente em estado de dry-run.
• Faça um piloto do App Control para sessões não gerenciadas com 2 a 3 equipes de negócio colaborativas.
• Implemente a política de proteção de elevação do PIM.

Dias 61–90 (Imposição e Medição)

• Mude seus playbooks automatizados para o modo enforce total em alertas de alta confiança.
• Crie uma pasta de trabalho de segurança de identidade (no Sentinel ou no Power BI) acompanhando as métricas listadas acima.
• Realize um exercício trimestral de purple team para validar seu MTTC, a velocidade de revogação de tokens e as mudanças de política do CA em um cenário de fogo real.

Armadilhas comuns (e padrões mais seguros)

Fique atento a estes erros comuns durante a implementação:

• Armadilha: Depender apenas do risco de entrada do CA → Correção: Reaja também ao risco de usuário e aos alertas pós-autenticação do DfI.
• Armadilha: Não ter o CAE configurado, permitindo que tokens desatualizados mantenham sessões comprometidas ativas → Correção: Ative o CAE e incorpore a revogação de tokens diretamente nos seus playbooks automatizados.
• Armadilha: Bloquear downloads de arquivos de forma ampla em toda a empresa, gerando revolta dos usuários → Correção: Aplique o App Control de forma seletiva, somente quando as sessões forem não gerenciadas ou arriscadas.
• Armadilha: Tempestades de alertas e falsos positivos causados por fluxos agressivos de comprometimento automático → Correção: Condicione suas automações a uma verificação de múltiplos sinais (por exemplo, alerta de alta severidade do DfI + volume incomum de downloads + acesso fora do horário).
• Armadilha: Contas de acesso de emergência (break-glass) bloqueadas por engano por políticas automatizadas de risco → Correção: Exclua duas contas break-glass com monitoramento intenso e rotacione suas credenciais trimestralmente.

Artefatos de copiar e colar

Para ajudar a comunicar essas mudanças em toda a organização, use estes trechos prontos:

Resumo de uma linha para executivos (CAB):

Conseguimos conectar o comportamento do usuário após o login às nossas decisões de controle de acesso. Se uma conta começar a agir de forma incomum, aplicamos atrito de segurança ou bloqueamos o acesso durante a sessão. Isso reduz drasticamente o tempo de permanência do invasor sem desacelerar o trabalho do dia a dia.

Nota de mudança para administradores:

• Novas políticas de Acesso Condicional podem solicitar MFA adicional ou bloquear o acesso quando um risco anômalo for detectado. Tokens de autenticação ativos agora podem ser revogados durante a sessão com base em telemetria. Contas break-glass permanecem explicitamente excluídas. Monitore a pasta de trabalho Identity Resilience para analisar o impacto.

Cartão de notificação automatizado para o Teams, voltado ao proprietário:

• “Identificamos atividade incomum de arquivos originada da sua conta. Aplicamos proteções temporárias (como a desativação de downloads em dispositivos não gerenciados). Se foi você, basta clicar em Confirmar; se não foi, clique em Reportar imediatamente.”