Lacunas de cobertura da politica baseline de Acesso Condicional Entra ID sao a forma mais basica de falha de Conditional Access que existe: nao uma politica mal configurada, nao uma exclusao ampla demais, mas nenhuma politica cobrindo roles de admin, todos os usuarios, todos os apps de nuvem ou conformidade de dispositivo. Um tenant pode ter uma duzia de politicas de Conditional Access no admin center — bloqueio de legacy authentication, regras de sign-in baseadas em risco, excecoes especificas de app — e ainda assim ter zero cobertura em qualquer uma dessas quatro baselines. Falhas acesso condicional Entra ID: quais erros deixam uma exposicao real cobre scope drift, exclusoes e legacy authentication dentro de politicas ja existentes. Este artigo trata da pergunta que vem antes de tudo isso: existe sequer uma politica baseline?
Lacunas de Cobertura da Politica Baseline de Acesso Condicional Entra ID: os Quatro Pontos Cegos
A propria orientacao de deployment de Conditional Access da Microsoft e explicita ao dizer que um tenant deveria conseguir apontar para um conjunto pequeno de politicas baseline que se aplicam amplamente, e nao uma pilha de excecoes estreitas. Como a Microsoft coloca em sua orientacao de planejamento de deployment, organizacoes deveriam criar uma politica que mire todos os usuarios, todos os resources sem exclusoes de app, e exija autenticacao multifator — porque isso "garante que voce nao precise atualizar politicas de Conditional Access toda vez que integrar uma nova aplicacao". Um tenant a quem falte qualquer uma das quatro lacunas abaixo nao alcancou essa baseline, independentemente de quantas outras politicas tenha configurado.
Nenhuma politica mirando roles de admin (CA_NO_POLICY_ADMINS)
A politica comum de Conditional Access da Microsoft para administradores recomenda exigir MFA resistente a phishing em pelo menos quatorze roles altamente privilegiadas: Global Administrator, Privileged Role Administrator, Security Administrator, Conditional Access Administrator, User Administrator, e outras com impacto em todo o tenant. Sem uma politica que mire especificamente essas directory roles — em vez de depender de uma politica generica de MFA para todos os usuarios que pode estar excluida ou com scope insuficiente para sign-ins de admin —, uma credencial de administrador comprometida nao enfrenta nenhum controle de acesso adicional.
Nenhuma politica mirando todos os usuarios (CA_NO_POLICY_ALL_USERS)
Uma politica que mira grupos ou apps especificos nao e o mesmo que uma politica que mira All users. A documentacao da Microsoft sobre user assignment em Conditional Access observa que All users em um assignment de Conditional Access inclui B2B guests alem de members, o que e exatamente o ponto: cobertura parcial de usuarios, construida grupo por grupo, tende a deixar de fora justamente o tipo de conta que ninguem lembrou de adicionar. Um tenant com MFA forte para o time de marketing e nada para contratados ou funcionarios recem-integrados tem essa lacuna, mesmo que a lista de politicas parega completa.
Nenhuma cobertura de todos os cloud apps (CA_NO_ALL_APPS_COVERAGE)
A orientacao de deployment de Conditional Access da Microsoft afirma claramente que "do ponto de vista de seguranca, e melhor criar uma politica que inclua All resources (anteriormente 'All cloud apps')" especificamente porque escopo app por app significa que toda nova aplicacao SaaS integrada comeca desprotegida ate que alguem lembre de adiciona-la a uma politica. Um tenant que escreveu uma politica de Conditional Access apenas para o Exchange Online e o portal do Azure deixou qualquer outro resource — incluindo apps OAuth de terceiros e o Microsoft Graph — fora de qualquer avaliacao de Conditional Access, ja que sign-ins para resources nao mirados nao sao governados por nada.
Nenhuma exigencia de conformidade de dispositivo (CA_NO_DEVICE_COMPLIANCE)
A Microsoft documenta uma politica de Conditional Access que exige que dispositivos acessando resources estejam marcados como compliant com as politicas de compliance do Intune da organizacao, ou Microsoft Entra hybrid joined. Sem ela, sign-ins que satisfazem MFA vindos de dispositivos nao gerenciados, sem patches ou pessoais alcancam os mesmos resources que sign-ins de um laptop corporativo hardened e com compliance verificada — MFA prova quem esta se autenticando, nao que o dispositivo usado seja seguro o suficiente para confiar na sessao.
⚠️ Aviso: Essas quatro lacunas sao independentes entre si. Um tenant pode exigir MFA para todos os usuarios e ainda assim nao ter nenhuma politica especifica para admins, ou cobrir todo cloud app para MFA enquanto nao exige conformidade de dispositivo em lugar nenhum. Cada uma precisa ser verificada individualmente — passar em uma nao implica que as outras estejam cobertas.
Por Que "Temos Conditional Access" Nao Significa que a Cobertura Baseline Existe
Duas coisas rotineiramente dao aos tenants uma falsa confianca de que essas quatro lacunas baseline estao fechadas quando nao estao.
Security Defaults nao e um substituto, e desaparece no momento em que qualquer politica personalizada e criada. A Microsoft ativa Security Defaults automaticamente para novos tenants para fornecer uma baseline minima de MFA, mas Security Defaults e politicas de Conditional Access sao mutuamente exclusivos — nao podem estar ativados ao mesmo tempo. A armadilha: um admin que cria uma unica politica estreita de Conditional Access (por exemplo, bloqueando legacy auth para um departamento) desativa silenciosamente o Security Defaults em todo o tenant no processo, mesmo que essa unica politica nao faca nada para cobrir roles de admin, todos os usuarios, todos os apps ou conformidade de dispositivo. O tenant termina com menos protecao baseline do que tinha antes, enquanto o admin center continua mostrando "Conditional Access: configurado". Fortalecimento do Tenant Azure: Corrigindo Configuracoes Padrao Inseguras cobre essa e outras armadilhas de configuracao padrao em tenants novos.
Politicas gerenciadas pela Microsoft cobrem uma fatia mais estreita do que "baseline" sugere, e comecam em report-only. Desde o final de 2023, a Microsoft implanta automaticamente um conjunto de politicas de Conditional Access gerenciadas pela Microsoft em tenants elegiveis, incluindo requisitos de MFA para admins e para todos os usuarios. Isso e uma melhoria genuina, mas dois limites importam para este artigo: primeiro, a politica gerenciada focada em admin mira especificamente sign-ins para portais de admin da Microsoft (portal do Azure, Microsoft 365 admin center, Entra admin center e similares), nao sign-ins de roles de admin para aplicacoes de negocio arbitrarias; segundo, a Microsoft cria essas politicas em modo report-only por padrao, que avalia mas nao aplica. Um tenant que depende da politica gerenciada sem nunca verificar se ela saiu do report-only tem a mesma exposicao pratica de nao ter politica nenhuma — um modo de falha distinto, mas adjacente, ao drift de report-only coberto em modo report-only de conditional access, exclusoes obsoletas.
Deteccao
Deteccao de lacunas de cobertura baseline significa enumerar o que realmente existe no conjunto de politicas de Conditional Access do tenant — nao o que o tenant pretendia configurar.
| Sinal | Onde verificar | O que informa |
|---|---|---|
Scope de conditions.users da politica em todas as politicas | Microsoft Graph GET /identity/conditionalAccess/policies, ou Get-MgIdentityConditionalAccessPolicy (Policy.Read.All) | Se alguma politica ativada inclui All users/roles versus apenas grupos especificos — a verificacao direta para CA_NO_POLICY_ALL_USERS e CA_NO_POLICY_ADMINS |
conditions.users.includeRoles da politica preenchido com IDs de directory roles de admin | Mesma query Graph, filtrada por status enabled | Confirma que existe uma politica que mira especificamente directory roles privilegiadas, e nao apenas uma regra generica de MFA para todos os usuarios que poderia estar excluida para admins |
Valor de conditions.applications.includeApplications da politica | Mesma query Graph | All significa que existe cobertura de All resources/All cloud apps; qualquer outro valor significa que a politica esta escopada para apps especificos e todo app nao listado fica desprotegido |
grantControls da politica contendo compliantDevice ou domainJoinedDevice | Mesma query Graph | Confirma se alguma politica aplicada realmente exige conformidade de dispositivo ou hybrid join, em vez de apenas MFA |
Valor de state da politica (enabled vs. enabledForReportingButNotEnforced) | Mesma query Graph, ou a aba Report-only no admin center | Distingue uma politica aplicada de uma politica gerenciada pela Microsoft ou personalizada que ainda esta em report-only — uma politica em report-only nao fecha a lacuna |
| Conditional Access gap analyzer workbook | Entra admin center → Monitoring & health → Workbooks → secao Conditional Access (requer Reports Reader e um Log Analytics workspace) | Construido especificamente para revelar usuarios, aplicacoes e locais nomeados sem nenhuma politica de Conditional Access aplicada, usando evidencia real de sign-in em vez de texto de politica |
Campo conditionalAccessStatus em entradas de sign-in log | Sign-in logs do Entra admin center, ou GET /auditLogs/signIns | notApplied em um sign-in de uma role de admin, um usuario padrao ou um dispositivo nao gerenciado e a confirmacao em runtime de que a lacuna baseline correspondente e real, nao teorica |
💡 Dica: revisao de politica antes da revisao de sign-in. Um gap analyzer workbook ou uma query de sign-in log so mostra evidencia para identidades e apps que realmente se autenticaram durante a janela de observacao. Enumerar o conjunto de politicas via Graph primeiro diz definitivamente se as quatro politicas baseline existem, independentemente de alguem ter ou nao acionado a lacuna naquele dia.
Remediacao
- Implante primeiro uma politica dedicada de MFA para roles de admin. Mire o conjunto documentado de roles altamente privilegiadas (Global Administrator, Privileged Role Administrator, Security Administrator, Conditional Access Administrator, e o restante da lista de admin roles da common policy da Microsoft), exija MFA ou uma authentication strength mais forte, e exclua apenas contas break-glass — veja Contas de Acesso de Emergencia Break Glass Entra ID antes de criar essa exclusao.
- Implante uma politica baseline para todos os usuarios com scope
All userseAll resources. Evite escopo app por app ou grupo por grupo para a camada baseline; adicione politicas mais estreitas e mais fortes por cima para apps especificos de alto valor, em vez de tentar enumerar todo app que precisa da baseline. - Adicione uma exigencia de conformidade de dispositivo ou hybrid join no minimo para as mesmas roles de admin e o conjunto de resources sensiveis cobertos acima, usando politicas de compliance do Intune como fonte de enforcement.
- Verifique se existem politicas gerenciadas pela Microsoft e se ainda estao em report-only. Se estiverem, promova-as para enforcement apos uma janela de revisao validada, ou substitua-as por politicas proprias do tenant que cubram o escopo mais amplo descrito neste artigo em vez de apenas portais de admin da Microsoft.
- Se o Security Defaults foi desativado silenciosamente por uma politica estreita anterior, nao apenas o reative — substitua-o pelas politicas baseline explicitas acima; Security Defaults e Conditional Access personalizado continuam mutuamente exclusivos, e reativa-lo removeria justamente a politica mais estreita que motivou a pergunta em primeiro lugar.
- Valide com a ferramenta What If e o gap analyzer workbook para uma conta de admin representativa, um usuario padrao representativo e um dispositivo nao gerenciado representativo antes de considerar a lacuna fechada — configuracao de politica e enforcement confirmado nao sao a mesma evidencia.
Como o EtcSec Detecta Isso
Os checks de Azure/Entra do EtcSec mapeiam diretamente para as quatro lacunas deste artigo: CA_NO_POLICY_ADMINS e CA_NO_POLICY_ALL_USERS sinalizam a ausencia de qualquer politica ativada mirando roles de admin ou todos os usuarios respectivamente, CA_NO_ALL_APPS_COVERAGE sinaliza a ausencia de uma politica escopada para todos os cloud apps/resources, e CA_NO_DEVICE_COMPLIANCE sinaliza a ausencia de qualquer grant control de conformidade de dispositivo. AZ_SECURITY_DEFAULTS_NO_CA captura a armadilha especifica descrita acima: Security Defaults desativado sem uma baseline compensatoria de Conditional Access em vigor.
ℹ️ Nota: o EtcSec verifica automaticamente essa vulnerabilidade em toda auditoria de AD/Azure. Execute uma auditoria gratuita para verificar seu ambiente.
Leituras Relacionadas
- Falhas acesso condicional Entra ID: quais erros deixam uma exposicao real
- Como auditar a seguranca do Microsoft Entra ID (Azure AD): guia pratico
- Contas de Acesso de Emergencia Break Glass Entra ID: Ausentes, Nao Monitoradas, Nao Excluidas
- Seguranca de Identidade Azure: Por que o MFA Sozinho Nao E Suficiente
- MFA Fatigue: deteccao e prevencao no Microsoft Entra ID
- Fortalecimento do Tenant Azure: Corrigindo Configuracoes Padrao Inseguras
Referencias Primarias
- Plan your Microsoft Entra Conditional Access deployment
- Require MFA for all users with Conditional Access
- Conditional Access Setup: Users, Groups, and Workload Identities
- Targeting resources in Conditional Access policies
- Require MFA for administrators with Conditional Access
- Common Conditional Access policy: Require MFA for admins accessing Microsoft admin portals
- How to require compliant devices with Conditional Access
- Require administrators use compliant or hybrid joined devices
- Microsoft-managed Conditional Access policies for enhanced security
- Automatic Conditional Access policies in Microsoft Entra streamline identity protection
- Configure Security Defaults for Microsoft Entra ID
- Conditional Access gap analyzer workbook
- Get-MgIdentityConditionalAccessPolicy (Microsoft.Graph.Identity.SignIns)
- List conditionalAccessPolicies — Microsoft Graph v1.0
Explore as paginas de identidade que sustentam este tema