Falhas acesso condicional Entra ID

Falhas acesso condicional Entra ID: esta e a forma mais direta de nomear a diferenca entre policies que parecem amplas no admin center e controles que realmente avaliam os users, guests, apps, protocols e workload identities que importam em producao. Um tenant pode aparentar uma cobertura de Conditional Access limpa e ainda assim deixar uma exposicao real por meio de exclusoes, protocolos legacy, caminhos guest ou service principals que nunca estiveram no scope correto.

Este artigo trata Conditional Access como um problema de evidencia, nao como um problema de screenshot. O objetivo e mostrar o que conta como uma falha real, quais sinais da Microsoft a comprovam, como corrigi-la sem provocar lockout operacional e como validar que o estado mais seguro foi realmente aplicado depois da mudanca. Para uma revisao mais ampla do tenant, comece por Como auditar a seguranca do Microsoft Entra ID (Azure AD): guia pratico.

Falhas acesso condicional Entra ID: o que conta como uma falha real?

Uma falha de Conditional Access e qualquer desalinhamento entre a policy que voce acredita impor e os sign-ins que o Microsoft Entra realmente avalia. A Microsoft descreve Conditional Access como um mecanismo de policy que combina sinais, aplica assignments e conditions e depois concede, bloqueia ou restringe mais o acesso. O mecanismo e poderoso, mas nao se prova sozinho. Uma policy so reduz risco quando mira as identidades e resources corretas, avalia o protocol path relevante e deixa evidencias nos sign-in logs e audit logs.

Na pratica, uma falha normalmente aparece em um destes cenarios:

falta completamente uma policy para um scope sensivel
existe uma policy, mas ela exclui os users ou roles que mais importam
uma policy protege users, mas nao workload identities
uma policy aponta para resources ou client paths errados
uma policy usa um grant fraco demais para a resource protegida
uma policy fica em report-only e nunca chega a enforcement

A Microsoft tambem lembra que Conditional Access e avaliado depois do primeiro fator de autenticacao. Por isso o artigo nao deve tratar Conditional Access como um controle magico “antes da autenticacao”. Ele e uma camada de decisao em torno de um sign-in, e a qualidade dessa decisao depende de scope, telemetry e desenho da policy.

Por Que Conditional Access Ainda Pode Deixar uma Exposicao Real

Muitas equipes pensam em Conditional Access como um estado binario: ligado ou desligado. A exposicao real e mais baguncada. O Microsoft Entra avalia todas as policies que se aplicam a um sign-in, e o usuario precisa satisfazer todos os requisitos aplicaveis antes que o acesso seja concedido. O problema real e que muitos sign-ins que deveriam ser governados nunca chegam a ser “applicable” na pratica.

O primeiro exemplo e a deriva de scope. Equipes de seguranca costumam acreditar que uma policy ampla cobre todos porque usa All users. A Microsoft documenta que All users inclui B2B guests, o que e util, mas isso nao significa que todos os caminhos de identidade estejam cobertos. Workload identities sao uma classe propria de assignment, e policies scopeadas para users nao governam automaticamente service principals. Se o tenant depende de app registrations, automacao ou integracoes backend, isso precisa ser revisado com o mesmo rigor aplicado aos usuarios humanos.

O segundo exemplo e a diferenca entre um grant amplo e um grant forte. Require multifactor authentication e Require authentication strength nao sao o mesmo controle. Se a expectativa do negocio for autenticacao resistente a phishing para roles admin ou aplicativos sensiveis, um simples requirement MFA pode ser mais fraco do que a intencao real. Por isso Seguranca de Identidade Azure: Por que o MFA Sozinho Nao E Suficiente, MFA Fatigue: deteccao e prevencao no Microsoft Entra ID e uma revisao de Conditional Access geralmente precisam caminhar juntas.

O ultimo problema recorrente e a deriva de validacao. Policies acumulam exclusoes, rascunhos em report-only, templates sobrepostas e excecoes de emergencia. O portal continua mostrando muitas policies, mas justamente os sign-ins mais importantes podem seguir passando sem challenge ou sendo avaliados por caminhos mais fracos do que o esperado.

Falhas de Scope: Users, Guests, Roles, Resources e Workload Identities

Users, directory roles e exclusions

O primeiro passo da revisao e mapear quem as policies realmente atingem. Conditional Access pode incluir ou excluir todos os users, users e groups selecionados, directory roles, guests e external users, alem de workload identities. Um tenant com boa cobertura user ainda pode deixar roles privilegiadas ou exclusions privilegiadas mal governadas. Isso e ainda mais relevante quando o acesso privilegiado ja esta amplo demais, como em Gerenciamento de Acesso Privilegiado no Azure: Riscos sem PIM.

Emergency access accounts sao o exemplo mais claro de exclusion intencional. A Microsoft recomenda exclui-las das policies de Conditional Access para evitar lockout do tenant, mas essa recomendacao nao justifica exclusoes por conveniencia. Cada exclusion precisa de um motivo estreito, um owner e monitoramento ativo. Se a mesma break-glass serve para administracao normal, a falha e operacional, nao teorica.

Guests e external users

O acesso guest e externo merece revisao propria, e nao uma suposicao rapida de que All users ja resolveu tudo. O Microsoft Entra permite segmentar tipos especificos de guests e external users, e o comportamento externo tambem depende de cross-tenant trust settings. Por exemplo, ao usar authentication strengths para external users, a Microsoft documenta que o resource tenant tambem avalia a confianca MFA do home tenant. Isso significa que a cobertura guest nao e apenas uma questao de existir uma policy. E uma questao de scope e trust. Por isso Contas de Convidado Azure: Riscos do Tenant geralmente faz parte da mesma revisao.

Resources, apps e user actions

Outra falha de scope aparece quando o tenant protege o conjunto errado de resources. Policies podem ser atribuidas a todas as resources ou a resources selecionadas. Se o tenant protege os admin portals da Microsoft, mas nao os aplicativos de negocio ou SaaS que os users realmente acessam primeiro, a historia de controle fica incompleta. O mesmo problema aparece quando a equipe se satisfaz com um screenshot de uma cloud app em vez de verificar o verdadeiro resource path que um atacante reutilizaria apos roubo de credenciais ou sessao. Ataques que abusam de sessoes validas ou de caminhos OAuth costumam se encadear com essas falhas; por isso Device Code Phishing: como o OAuth Device Flow compromete contas Entra ID e um artigo claramente relacionado.

Workload identities

Service principals e workload identities sao o ponto cego mais comum em tenants que, no resto, parecem maduros. A Microsoft documenta que chamadas feitas por service principals nao sao bloqueadas por policies de Conditional Access scopeadas a users e que deve ser usado Conditional Access para workload identities quando essas identidades precisarem de tratamento por policy. Na pratica, isso significa que um tenant pode exibir uma boa cobertura MFA para users e, ao mesmo tempo, deixar identidades de automacao e de aplicacao fora do modelo de Conditional Access.

Isso nao significa que toda workload identity deva receber a mesma policy. Significa que o tenant deve provar que sabe quais workload identities existem, quais ficam fora por design e quais ainda dependem de padroes mais fracos que deveriam migrar para managed identities sempre que possivel.

Falhas de Controle: MFA, Authentication Strengths, Legacy Authentication e Risk Policies

Cobertura MFA nao e a mesma coisa que desenho forte de autenticacao

Um tenant pode ter muitas policies exigindo MFA e ainda assim deixar acessos de alto valor em metodos mais fracos do que o esperado. A Microsoft documenta authentication strengths como um controle de Conditional Access que restringe quais combinacoes de metodos podem ser usadas para acessar uma resource. Essa distincao importa sempre que o objetivo da policy for mais forte do que “qualquer MFA serve”. Para roles admin ou aplicativos sensiveis, a diferenca entre um grant MFA amplo e uma exigencia resistente a phishing ou passwordless deve ser explicita.

Legacy authentication continua sendo uma falha real quando ainda esta acessivel

Legacy authentication precisa ser tratada com precisao porque costuma ser descrita de forma vaga demais. A Microsoft afirma que protocolos legacy nao suportam MFA nem transmitem estado do dispositivo. A Microsoft tambem recomenda bloquear requests de autenticacao que usem esses protocolos e observa que esses caminhos continuam muito presentes em campanhas de password spraying e credential stuffing.

A formulacao defensavel e esta: legacy authentication e uma falha quando esses protocolos continuam acessiveis para identidades ou resources que o tenant acredita estar protegendo com requisitos modernos de Conditional Access. Alguns tenants fecham essa falha com uma policy dedicada de bloqueio. Outros se apoiam em grants mais amplos para todos os client apps. Uma boa revisao nao consiste em decorar template. Consiste em provar, com sign-in logs, que clientes legacy estao bloqueados ou ausentes. Se o tenant ja revisa a fraqueza do primeiro fator, conecte esse trabalho a Password Spraying: deteccao e prevencao em Active Directory e Entra ID.

Risk policies nao estao implicitas em uma boa maturidade de Conditional Access

Um tenant sem policies de sign-in risk ou user risk nao esta automaticamente mal configurado, porque essas policies dependem das capacidades do Microsoft Entra ID Protection e do nivel de licenca adequado. Mas, se a narrativa de seguranca afirma que o acesso e adaptado ao risco, o tenant precisa provar que esses controles existem e sao aplicados. A Microsoft documenta sign-in risk policies separadamente e deixa clara a dependencia de P2. Se o tenant nao licencia ou nao usa essa capacidade, isso deve ser dito com clareza, em vez de sugerir um controle inexistente. Veja tambem Azure Identity Protection: Politicas de Risco.

Deteccao

A deteccao de falhas de acesso condicional Entra ID e um exercicio de correlacao, nao um alerta baseado em um unico campo.

Os sign-in logs do Microsoft Entra sao a principal fonte de prova. Para sign-ins interativos e nao interativos, revise pelo menos estas dimensoes:

Sinal	Por que importa
`conditionalAccessStatus`	Mostra se o Conditional Access teve sucesso, falhou ou nao foi aplicado. `notApplied` nao e automaticamente um bug, mas vira falha quando o sign-in deveria estar no scope correto.
`appliedConditionalAccessPolicies`	Mostra quais policies realmente avaliaram o sign-in. E mais util do que assumir qual policy deveria ter se aplicado.
`clientAppUsed`	Identifica caminhos legacy como IMAP, POP, SMTP, Exchange ActiveSync e outros clients que normalmente deveriam estar bloqueados ou ausentes.
`riskLevelDuringSignIn` e campos de risco relacionados	Uteis quando o tenant afirma aplicar enforcement baseado em risco e precisa demonstrar isso.
contexto de resource e app	Ajuda a distinguir se o sign-in atingiu o conjunto de resources que a policy deveria proteger.
sign-ins interativos vs nao interativos	Necessario porque caminhos legacy e caminhos conduzidos por servicos costumam ser perdidos quando a equipe olha apenas para o interativo.

A nuance importante e a seguinte: um sign-in bem-sucedido com conditionalAccessStatus = notApplied nao basta sozinho. A pergunta real e se aquele sign-in deveria ter sido governado segundo o proprio desenho do tenant.

Revise audit logs para detectar policy drift

Os audit logs sao a segunda fonte de prova. Use-os para revisar criacao de policies, atualizacoes, mudancas de enablement, transicoes para report-only, mudancas de exclusions e exclusoes de policy. Se um tenant muda o scope de Conditional Access repetidamente sem manter evidencias do por que, a falha real e tanto de governance drift quanto de policy design.

Revise o estado da policy, nao apenas o texto

O modo report-only e a ferramenta What If sao uteis, mas respondem perguntas diferentes. report-only ajuda a estimar impacto sem enforcement. What If ajuda a simular quais policies se aplicariam a um sign-in de user ou de service principal. Nenhum dos dois substitui evidencia de producao. Uma revisao madura usa ambos e depois confirma o resultado em dados reais de sign-in.

Remediation e remediacao

A remediacao deve fechar primeiro as falhas de scope e de controle com maior impacto.

Estabeleca uma baseline ampla para users e resources. O tenant deve conseguir apontar quais policies base protegem o acesso normal dos users nas resources que realmente importam, e nao apenas em um admin portal ou aplicativo favorito.
Revise exclusions antes de adicionar novas policies. Se exclusions ja escondem administradores, guests ou grupos de alto valor, novas policies podem criar ilusao de progresso enquanto deixam a exposicao real intocada.
Bloqueie ou elimine caminhos de legacy authentication. Onde Conditional Access estiver disponivel, use scope de policy e validacao para bloquear legacy authentication. Onde ainda existirem dependencias de servico ou aplicativo, documente-as explicitamente e trate-as como excecoes a remover, nao como suposicoes permanentes de desenho.
Separe cobertura user de cobertura workload identity. Se o tenant depende de service principals, automacao ou identidades de aplicativo, precisa existir uma trilha de revisao separada para workload identities. Nao assuma que policies de users fizeram esse trabalho por voce.
Use authentication strengths quando o objetivo de acesso for mais forte do que MFA generico. Aplicativos sensiveis, acessos externos e roles privilegiadas geralmente precisam de algo mais forte do que um grant MFA amplo.
Adicione risk policies somente quando o tenant puder operalas de verdade. Se a avaliacao de risco sustentada por P2 faz parte da narrativa de seguranca, a evidencia precisa mostrar isso. Se nao estiver licenciada ou implantada, o artigo deve tratar isso como uma limitacao consciente, e nao como maturidade oculta.

Validacao Depois de Mudancas de Policy

E aqui que o trabalho de Conditional Access costuma falhar com mais frequencia.

Primeiro, use What If para verificar a aplicacao esperada das policies para users representativos, roles admin, guests e service principals. Depois, use report-only quando fizer sentido para entender o blast radius antes do enforcement. Por fim, confirme o resultado real nos sign-in logs depois que a policy estiver habilitada.

Essa validacao deve responder perguntas concretas:

os users pretendidos estao passando pelas policies pretendidas?
as contas excluidas continuam excluidas de forma intencional e monitorada?
os sign-ins guest seguem o caminho de policy esperado?
workload identities continuam fora de controles scopeados para users?
as tentativas via clients legacy agora falham ou desapareceram?
se authentication strengths foram introduzidas, os sign-ins afetados mostram na pratica a forca esperada?

Um tenant que nao consegue responder a essas perguntas com evidencias de sign-in e audit nao terminou sua remediacao.

Evidencias para Manter Entre Revisoes

Conditional Access deriva em silencio, por isso o pacote de evidencias importa.

Manter	Por que importa
export de policy ou screenshots com assignments, exclusions e grant controls	Prova o que o tenant pretendia impor naquele momento.
amostras de sign-in logs para identidades representativas dentro e fora do scope	Prova o que o Microsoft Entra realmente avaliou.
audit logs de mudancas de policy	Preserva quem alterou scope, modo, exclusions ou logica de grant.
registro de excecoes para emergency accounts, guests ou dependencias legacy	Distingue excecoes deliberadas de falhas acidentais.
inventario de workload identities	Prova que identidades nao humanas foram revistas separadamente, em vez de presumidas como cobertas.

Esse conjunto de evidencias e o que permite que a proxima revisao meca drift em vez de recomecar a partir de screenshots dispersos. Se o tenant tambem precisar de um enquadramento mais amplo para compliance, Requisitos NIS2 para seguranca de identidade: o que equipes de AD e Entra precisam comprovar e o artigo complementar certo, nao um substituto desta revisao tecnica.

Como EtcSec Ajuda a Medir Falhas de Acesso Condicional

Aqui o EtcSec deve ser posicionado de forma estreita: nao como um detector magico de sign-ins, mas como uma forma de medir de novo, ao longo do tempo, condicoes estruturais de falha em Conditional Access.

Para este artigo, os findings relevantes sao os que ja correspondem a problemas reais de policy design:

CA_NO_MFA_REQUIREMENT
CA_NO_LEGACY_AUTH_BLOCK
CA_NO_RISK_BASED_SIGNIN
LEGACY_AUTH_ALLOWED

Esse mapeamento e util porque sustenta revisoes recorrentes. O tenant pode reauditar depois de mudancas de policy e confirmar se as mesmas falhas estruturais continuam presentes, em vez de tratar Conditional Access como uma configuracao unica de partida.

Falhas acesso condicional Entra ID: quais erros deixam uma exposicao real

Falhas acesso condicional Entra ID: o que conta como uma falha real?

Por Que Conditional Access Ainda Pode Deixar uma Exposicao Real