Acesso Condicional Modo Somente Relatório, Exclusões

Acesso Condicional Modo Somente Relatório, Exclusões Obsoletas: O Que "Aplicada" Realmente Significa

Acesso Condicional em modo somente relatório e exclusões obsoletas são os dois motivos mais comuns pelos quais uma política de Acesso Condicional aparece como "Ativada" no Microsoft Entra admin center enquanto não bloqueia absolutamente nada. Ambas as condições são fáceis de passar despercebidas numa revisão rápida do portal, porque a política continua existindo, continua com as condições corretas configuradas e continua aparecendo na lista de políticas:

A política — ou uma alteração feita nela — está em modo somente relatório, que avalia os sign-ins e registra o resultado, mas nunca concede, bloqueia ou desafia o acesso.
A política está em vigor, mas sua lista de exclusões cresceu além do motivo estreito e documentado para o qual foi criada, de modo que os sign-ins mais importantes passam por ela sem serem tocados.

Nenhum dos dois é um bug. Ambos são recursos do Microsoft Entra suportados e intencionais. A lacuna é operacional: ninguém verificou de novo se a exceção ainda era necessária. Falhas acesso condicional Entra ID: quais erros deixam uma exposição real cobre o escopo mais amplo e o panorama de controles — políticas ausentes, workload identities, legacy authentication. Este artigo permanece estreito: o que acontece depois que uma política existe, quando seu estado de aplicação ou sua lista de exclusões se afasta silenciosamente do que o tenant acredita estar protegido.

Modo Somente Relatório: O Não-Controle Silencioso

Report-only é um estado por política no Acesso Condicional. A Microsoft o documenta como uma forma de os administradores "testarem a maioria das políticas de Acesso Condicional antes de habilitá-las" — durante o sign-in, o sistema avalia a política, mas não aplica grant controls nem session controls, e os usuários nunca são solicitados a fazer MFA, verificação de conformidade de dispositivo ou bloqueados por uma política em report-only.

⚠️

⚠️ Aviso: Report-only não é uma versão mais fraca de "Ativada". Para fins de aplicação, ela é funcionalmente "Desativada" — a política produz evidência em log, não controle de acesso.

Por que o report-only vai de estado de teste a permanente

O mecanismo que torna isso perigoso na prática não é o rollout inicial — a maioria das equipes escalona deliberadamente novas políticas em report-only para uma janela de revisão. O risco é o desvio depois disso: uma política que estava em vigor pode ser silenciosamente puxada de volta para report-only por qualquer pessoa com direitos de Conditional Access Administrator. A própria documentação da Microsoft é explícita ao afirmar que o modo report-only nunca aplica grant controls ou session controls, independentemente do estado anterior da política: "durante o sign-in, o sistema avalia as políticas em modo report-only, mas não as aplica." Esse único botão, alterado durante uma sessão de troubleshooting ou uma exceção de acesso emergencial e nunca revertido, remove silenciosamente um controle que todo dashboard e toda lista de políticas continua mostrando como configurado.

A orientação da Microsoft é validar mudanças em uma política existente e já em vigor clonando-a para uma cópia em report-only, em vez de alternar o botão da política original — comparar os resultados da cópia com a política ativa e depois descartar a cópia quando estiver satisfeito. Quando esse padrão não é seguido, a própria política original acaba ficando em report-only — às vezes indefinidamente.

Exclusões Obsoletas e Excessivas: Como a Cobertura Se Corrói com o Tempo

Exclusões existem por motivos operacionais reais: um escritório remoto que ainda não consegue atender a um requisito de localização, um dispositivo legacy pendente de substituição, uma conta break-glass. A própria orientação da Microsoft sobre gerenciar usuários excluídos é explícita ao afirmar que isso começa pequeno e vira um problema:

"Frequentemente, quando você configura uma exclusão pela primeira vez, há uma pequena lista de usuários que contornam a política. Com o tempo, mais usuários são adicionados à exclusão, e a lista cresce. Em algum momento, você precisa revisar a lista e confirmar que cada um desses usuários ainda é elegível para a exclusão."

Três formas como as listas de exclusão ficam piores do que parecem

Exclusões de usuários individuais ou de grupos legacy on-premises não oferecem visibilidade contínua. Os usuários frequentemente não sabem que estão excluídos, e se a exclusão usa um grupo sincronizado on-premises ou dinâmico, os administradores têm visibilidade limitada sobre quem está nele ou por quê.
A associação self-service a grupos pode transformar uma exclusão em um bypass. Se o grupo de exclusão permite entrada self-service (um padrão legítimo para o cenário do "funcionário viajante"), qualquer usuário que descubra o grupo pode se adicionar a ele.
A elegibilidade não é revisada de novo. Um usuário excluído por causa de um dispositivo legacy já substituído, ou uma exclusão de contratado que sobreviveu ao contrato, permanece excluído indefinidamente porque nada força uma nova revisão.

O controle compensatório: grupos atribuídos mais revisões de acesso recorrentes

O controle compensatório recomendado pela Microsoft é sustentar cada exclusão com um grupo de segurança do Microsoft Entra dedicado, de associação Atribuída (não uma lista de usuários individuais, não um grupo legacy sincronizado), e anexar uma Revisão de Acesso recorrente a esse grupo. O padrão documentado para uma exclusão baseada em localização é uma revisão que roda semanalmente, nunca termina, exige autoatestação de cada membro e remove automaticamente quem não responder. Para uma exclusão de legacy authentication, o padrão recomendado é uma revisão recorrente com donos de unidades de negócio como revisores e resultados aplicados automaticamente. Ambos os padrões exigem uma licença Microsoft Entra ID P2, Microsoft Entra ID Governance ou Enterprise Mobility + Security E5 — Revisões de Acesso não estão disponíveis em níveis inferiores, o mesmo patamar de licenciamento que destrava PIM e Identity Protection (ver Recursos do Azure AD Premium P2: PIM, Identity Protection e Access Reviews que Ninguem Ativou).

💡

💡 Dica: Se um grupo de exclusão não tem uma Revisão de Acesso anexada, trate isso como o próprio achado — não "essa exclusão ainda faz sentido hoje", mas "nada neste tenant jamais voltará a fazer essa pergunta".

As exclusões também têm um ponto cego de escopo que a maioria dos revisores não verifica: exclusões de recurso em políticas de "Todos os recursos". A Microsoft está lançando, a partir de 15 de junho de 2026, uma mudança de aplicação que fecha exatamente essa lacuna. Anteriormente, quando uma política de "Todos os recursos" tinha qualquer exclusão de recurso, sign-ins que solicitavam apenas um conjunto estreito de "baseline scopes" (openid, profile, email, offline_access, User.Read e alguns escopos de diretório semelhantes) eram silenciosamente isentos da aplicação por completo — mesmo que o administrador que criou a política acreditasse que "Todos os recursos" significava tudo. Clientes públicos como o Azure CLI ou o VS Code, e web apps confidenciais que solicitam apenas esses escopos, passavam sem serem verificados. Atacantes que abusam de fluxos OAuth solicitando escopos mínimos, de forma semelhante ao que acontece no device code phishing, são exatamente o tipo de sign-in que essa lacuna poderia ter deixado passar despercebido. Este é um caso em que a própria telemetria da Microsoft confirmou que exclusões no nível de recurso estavam gerando lacunas de cobertura mais amplas e não intencionais do que os tenants percebiam — exatamente o mesmo modo de falha deste artigo, só que na camada de escopo em vez da camada de usuário.

Detecção

A detecção aqui é um exercício de correlação entre evidências de sign-in e histórico de mudanças de política, não um alerta único.

Sinal	Onde encontrar	O que indica
Resultado por política na aba Report-only de uma entrada do log de sign-in	Entra admin center → detalhes do log de sign-in	Se aquele sign-in específico teria passado, falhado ou exigido uma ação caso a política estivesse em vigor
`appliedConditionalAccessPolicies[].result` via Microsoft Graph	`GET /auditLogs/signIns` (valores de report-only exigem o header `Prefer: include-unknown-enum-members`)	Versão programática da aba acima — os valores de enum são `success`, `failure`, `notApplied`, `notEnabled`, `reportOnlySuccess`, `reportOnlyFailure`, `reportOnlyNotApplied`, `reportOnlyInterrupted`
`enforcedGrantControls` / `enforcedSessionControls` no mesmo objeto	Microsoft Graph `appliedConditionalAccessPolicy`	Confirma quais controles realmente se aplicaram a um sign-in específico, em comparação com os controles que a política está configurada para exigir
Workbook Conditional Access Insights and Reporting	Entra admin center, exige Entra ID P1 + um workspace do Log Analytics recebendo sign-in logs	Comparação agregada report-only vs. em vigor ao longo de um período, conjunto de apps e conjunto de usuários — a forma mais rápida de encontrar uma política que está em report-only muito além de uma janela de teste
Visualização Policy impact (preview)	Entra admin center, role Security Reader ou superior	Snapshot de 24h/7d/1 mês do impacto potencial e existente de uma política, sem construir uma consulta de workbook
Audit log: mudanças de estado "Enable policy"	Entra admin center → Audit logs, filtrado para atualizações de política de Acesso Condicional	O evento específico para alertar: qualquer transição de Ativada → Report-only em uma política anteriormente em vigor
Associação ao grupo de exclusão + resultados/audit logs de Revisão de Acesso	ID Governance → Access reviews → Results / Audit logs	Quem foi removido vs. aprovado automaticamente vs. nunca respondeu — a evidência real de que uma exclusão obsoleta existia
`membershipType` do grupo de exclusão	Endpoint `groups` do Microsoft Graph ou Entra admin center	Sinaliza grupos de exclusão que são legacy sincronizados on-premises ou dinâmicos em vez de Atribuídos — o padrão que a Microsoft aponta como redutor de visibilidade

🚨 Perigo: Uma política com zero eventos reportOnlyFailure ou Failure não é necessariamente bem ajustada. Também pode significar que as exclusões da política são tão amplas que quase nada está de fato sendo avaliado contra ela.

Remediação (Remediation)

Fechar o desvio de report-only

Levante o estado atual de habilitação de cada política e a data da última alteração. Qualquer política em report-only sem uma data documentada de fim da janela de revisão é a lacuna — não apenas "isso é um teste novo", mas "existe alguém responsável por promover isso a Enforced."
Alerte especificamente sobre eventos de audit log de Ativada → Report-only. Essa transição é rara, deliberada e perigosa quando acontece em uma política anteriormente em vigor — ela nunca deveria ocorrer silenciosamente.

Fechar o desvio de exclusões

Substitua exclusões de usuário individual e de grupo legacy sincronizado por grupos de segurança do Entra dedicados e de associação Atribuída. Este é o pré-requisito para o próximo passo; Revisões de Acesso têm como alvo grupos, não listas de usuários ad hoc.
Anexe uma Revisão de Acesso recorrente a cada grupo de exclusão, seguindo os padrões documentados da Microsoft: autoatestação com remoção automática para exclusões de viagem/localização, revisão por donos com aplicação automática para exclusões de legacy auth ou dispositivo. Isso exige licenciamento Entra ID P2 ou Entra ID Governance.
Revise cada política de "Todos os recursos" que tenha uma exclusão de recurso contra o lançamento de aplicação de baseline scopes de 15 de junho de 2026. Decida deliberadamente — habilite a nova aplicação antecipadamente pelas configurações de Baseline scopes, ou use "Customize behavior" para os aplicativos específicos que realmente precisam da isenção legacy — em vez de deixar o rollout padrão da Microsoft decidir silenciosamente.
Revalide com evidência, não com suposição. Depois de qualquer promoção de report-only para em vigor ou limpeza de grupo de exclusão, confirme o resultado nos sign-in logs para contas representativas excluídas e incluídas, não apenas na tela de configuração da política.

Como o EtcSec Detecta Isso

As verificações Azure/Entra do EtcSec mapeiam diretamente para os dois modos de falha deste artigo: CA_POLICY_REPORT_ONLY sinaliza políticas de Acesso Condicional ainda em modo report-only, CA_EXCESSIVE_EXCLUSIONS e CA_GROUP_EXCLUSION_LARGE sinalizam políticas cujo escopo de exclusão cresceu muito em relação à sua intenção, e CA_USER_EXCLUSIONS_STALE sinaliza exclusões no nível de usuário que não mostram evidência de revisão recente. Como os dois modos de falha são sobre desvio em vez de um erro de configuração único, o valor está em rodar a auditoria de novo periodicamente — um tenant que passou nessa verificação há seis meses pode falhar silenciosamente hoje sem que uma única política tenha sido apagada ou uma única configuração alterada.

ℹ️

ℹ️ Nota: O EtcSec verifica automaticamente essa vulnerabilidade em todo audit de AD/Azure. Execute um audit gratuito para verificar seu ambiente.

Acesso Condicional Modo Somente Relatório, Exclusões Obsoletas: Políticas Que Não Estão Realmente em Vigor