Como o Conditional Access e PIM Realmente Interrompem Ataques?

Políticas de senha interrompem ataques de adivinhação. Elas não fazem nada contra um token de sessão roubado, um prompt MFA phishado, ou uma conta admin permanente que está lá há dois anos com direitos de Global Administrator. Conditional Access e Privileged Identity Management (PIM) são os dois controles do Azure AD / Entra ID que realmente cobrem essas lacunas, e funcionam melhor juntos.

O que Conditional Access faz nos bastidores

Conditional Access é um mecanismo se-isto-então-aquilo avaliado no momento do sign-in. O lado "se" (sinais) inclui associação de usuário/grupo, estado de conformidade do dispositivo, localização de rede, risco de sign-in (do Identity Protection), aplicativo sendo acessado e tipo de app cliente (navegador vs. protocolo herdado). O lado "então" (controles) inclui: exigir MFA, exigir um dispositivo compatível, exigir um app cliente aprovado, bloquear acesso completamente, ou exigir aceitação de termos de uso.

Uma política importante em quase todo tenant: bloquear autenticação herdada. Protocolos como POP, IMAP e SMTP mais antigos não suportam desafios MFA modernos, então são a primeira coisa que ferramentas de credential-stuffing tentam. Verifique logs de sign-in filtrados por "Client App = Other clients" antes de bloquear — você costuma encontrar algum scanner herdado ou uma impressora multifuncional antiga ainda se autenticando com basic auth.

Um segundo importante de ter desde o primeiro dia: exigir MFA para todos os usuários, com escopo de um grupo de exclusão apenas para contas de break-glass. Não escope MFA para "apenas admins". Contas de usuário padrão comprometidas é como os atacantes conseguem seu primeiro acesso antes mesmo da escalação de privilégios.

Risco de sign-in vs. risco de usuário — sinais diferentes, respostas diferentes

Identity Protection (parte do Entra ID P2) gera dois scores de risco separados e é fácil confundi-los:

• Risco de sign-in — esta tentativa de autenticação específica parece anômala (viagem impossível, IP anônimo, propriedades de sign-in desconhecidas).
• Risco de usuário — esta conta foi sinalizada por um motivo relacionado à identidade em si (credenciais vazadas encontradas em um corpo de breach, atividade de comprometimento confirmada).

Uma política de Conditional Access respondendo ao risco de sign-in deve tipicamente desafiar com MFA — se o usuário real conseguir completar o desafio, deixe-o passar. Uma política respondendo ao risco de usuário deve forçar uma redefinição de senha, porque MFA sozinho não ajuda se a credencial em si já está queimada.

Por que acesso permanente de admin é o problema maior

Mesmo com um Conditional Access impecável, uma conta que mantém Global Administrator permanentemente é um alvo sentado em plena vista no diretório. Qualquer um que a comprometa herda controle total do tenant sem nenhum passo adicional necessário. PIM remove a parte "permanente".

Com PIM, papéis de admin são atribuídos como elegíveis em vez de ativos. O usuário tem que ativar explicitamente o papel, o que dispara uma justificativa exigida, fluxo de aprovação opcional, re-confirmação MFA, e uma janela limitada no tempo — comumente 1 a 8 horas — depois da qual o papel se desativa automaticamente. Ninguém, incluindo o proprietário da conta, tem Global Admin permanente a menos que esteja o usando ativamente.

Uma configuração mínima de PIM que é realmente usável

• Todo papel acima de Helpdesk Administrator: elegível, não permanente.
• Global Administrator e Privileged Role Administrator: exigir aprovação de um segundo admin, não apenas auto-ativação.
• MFA de ativação obrigatória, sem exceções.
• Duração máxima de ativação de 4 horas força as pessoas a reativar para sessões de trabalho genuinamente separadas, o que também produz trilhas de auditoria mais limpas.
• Análises de acesso a cada 90 dias em todas as atribuições elegíveis — contas são adicionadas para um projeto e nunca removidas caso contrário.

Onde as equipes erram nisso

A falha mais comum não é design de política, é a lista de exclusão. Uma política de Conditional Access com um grupo "exclua estes usuários porque o app não suporta MFA" em constante crescimento eventualmente exclui metade do tenant. Rastreie exclusões como um item de backlog com um proprietário e uma data de remoção, não um balde permanente.

A segunda falha são contas de break-glass que não são realmente testadas. Duas contas de emergência, excluídas de Conditional Access e PIM, com senhas aleatórias longas armazenadas offline e alertas em qualquer sign-in — e alguém deve tentar fazer login nelas trimestralmente para confirmar que ainda funcionam.

Conditional Access e PIM não são uma caixa para uma auditoria de conformidade. Eles são a diferença entre uma credencial phishada ser um incômodo e ser um comprometimento completo de tenant. Se você está mapeando controles de identidade como parte de uma construção de Blue Team, os segmentos Cloud e Blue Team do Korra Studio cobrem o lado de detecção — como eventos de risco de Identity Protection realmente se parecem no Sentinel e como alertar em padrões de ativação PIM impossíveis.