MFA sem cobertura total acesso condicional Entra: a lacuna crítica das políticas só de admin

MFA sem cobertura total acesso condicional Entra: o que isso realmente significa

MFA sem cobertura total acesso condicional Entra é uma falha distinta, comum e de severidade crítica no Microsoft Entra ID — e não é o mesmo problema que não ter Acesso Condicional algum. Um locatário pode passar em qualquer lista de verificação do tipo "você tem Acesso Condicional?", exibir uma política que literalmente tem como alvo Todos os usuários e, ainda assim, deixar toda conta sem função administrativa acessível apenas com uma senha. Isso acontece quando o controle de concessão da política exige algo diferente de MFA (conformidade do dispositivo, por exemplo), ou quando a imposição de MFA está espalhada por várias políticas com escopo de função ou de aplicativo, cada uma sólida por si só, mas que nunca somam uma cobertura abrangente.

Este é o parente mais restrito, mais comum e mais perigoso de dois problemas mais conhecidos:

• Nenhuma política de Acesso Condicional de qualquer tipo com alvo em todos os usuários. Essa é a falha de cobertura de base — veja Acesso Condicional: lacunas de cobertura da política baseline no Entra ID para locatários sem nenhuma política cobrindo funções administrativas, todos os usuários, todos os aplicativos de nuvem ou conformidade de dispositivo. Este artigo pressupõe que já existe uma política com alvo em todos os usuários; a lacuna aqui é mais estreita e mais fácil de não perceber — a política existe, mas não exige MFA.
• MFA exigido apenas para administradores. A maior parte do trabalho de fortalecimento do Acesso Condicional começa aqui, e por bons motivos — veja Segurança de identidade no Azure: quando o MFA não basta. Mas uma política de MFA com escopo em administradores, por melhor que seja construída, estruturalmente não consegue proteger as contas às quais nunca foi atribuída. Usuários padrão entram nas mesmas caixas de correio, nos mesmos sites do SharePoint e nos mesmos aplicativos de linha de negócios que os administradores; eles não são um alvo de menor valor, são simplesmente um alvo desprotegido.

É também por isso que a lacuna passa despercebida mesmo em equipes que já fizeram trabalho real de fortalecimento. Uma organização que implantou MFA com escopo administrativo conforme MFA_NOT_ENFORCED_ADMINS ou que restringiu a autenticação de Administrador Global conforme PA_GLOBAL_ADMIN_NOT_MFA fez primeiro o trabalho que parecia mais difícil e supõe, razoavelmente, que o caso mais simples e mais amplo — todos os demais usuários — já esteja coberto por extensão. Estruturalmente não está: políticas com escopo administrativo e políticas para todos os usuários são construídas sobre condições de atribuição diferentes no Entra ID, de modo que concluir uma deixa a cobertura da outra exatamente onde começou, em zero.

Dois modelos separados, duas ações separadas do Secure Score

A Microsoft não modela "exigir MFA" como um controle único. Na galeria de modelos de Acesso Condicional, Exigir autenticação multifator para administradores (Require multifactor authentication for admins) e Exigir autenticação multifator para todos os usuários (Require multifactor authentication for all users) estão listados como dois modelos separados. Ambos aparecem juntos na própria categoria "Secure foundation" da Microsoft — o conjunto que a Microsoft recomenda explicitamente implantar como grupo — e ambos aparecem de novo, ainda como duas entradas separadas, na categoria "Zero Trust". Nenhuma das descrições de modelo afirma cobrir o terreno da outra, em nenhuma das duas listas.

A mesma divisão existe na pontuação. O Identity Secure Score do Microsoft Entra ID acompanha Exigir MFA (autenticação multifator) para funções administrativas (Require multifactor authentication (MFA) for administrative roles) e Garantir que todos os usuários possam concluir a MFA (Ensure all users can complete MFA) como duas ações de melhoria distintas em seu próprio catálogo. Um locatário pode maximizar a primeira e pontuar zero na segunda; o Secure Score não as trata como redundantes, e quem revisa uma exportação de Acesso Condicional também não deveria.

A ação referente a todos os usuários também é pontuada como porcentagem do total de usuários protegidos, não como aprovação/reprovação binária. No exemplo prático da própria Microsoft, ter 5 usuários protegidos de um total de 100 usuários rende cerca de 0,53% de um máximo possível de 10,71% para esse controle — o que significa que a maioria dos locatários que "começaram" o MFA para todos os usuários ainda carrega a maior parte da exposição que o controle deveria fechar.

Como a cobertura fragmentada esconde a lacuna

O modelo de MFA para administradores e o modelo de MFA para todos os usuários não têm o mesmo escopo, e essa diferença é exatamente como uma lacuna sobrevive a uma revisão superficial de políticas:

• Exigir autenticação multifator para administradores (Require multifactor authentication for admins) faz a atribuição em Funções de diretório, e apenas para uma lista definida de funções internas — Administrador Global, Administrador de Aplicativos, Administrador de Autenticação, Administrador de Função com Privilégios, Administrador de Segurança e outras nomeadas explicitamente na documentação da Microsoft. O aviso da própria Microsoft é direto: "Conditional Access policies support built-in roles. Conditional Access policies are not enforced for other role types including administrative unit-scoped or custom roles." Uma função personalizada de "Suporte de TI" com permissões elevadas, ou uma função atribuída apenas no nível da unidade administrativa, é invisível para essa política mesmo enquanto ela está habilitada e sendo imposta.
• Exigir autenticação multifator para todos os usuários (Require multifactor authentication for all users) faz a atribuição em Incluir: Todos os usuários, com exclusões limitadas a contas break-glass e contas de serviço de sincronização de diretório. Não há condição de função pela qual um usuário possa escapar.

Como as duas políticas usam modelos de atribuição diferentes, um locatário pode acumular várias políticas de MFA genuinamente impostas — uma com escopo em Administradores Globais, uma com escopo em um aplicativo financeiro específico, uma disparada apenas por entrada arriscada — e mesmo assim nunca ter implantado a única política cujo Incluir é literalmente Todos os usuários, cujos Recursos de destino são Todos os recursos e cujo controle de concessão exige MFA. Cada política individual é real; nenhuma delas, mesmo somadas, equivale à linha de base que a Microsoft recomenda. Entra ID: lacunas no Acesso Condicional cobre o padrão mais amplo de exclusões e divergências de escopo que fazem um conjunto de Acesso Condicional parecer completo enquanto deixa exposição real em produção. Azure: gerenciamento de acesso privilegiado e os riscos sem PIM cobre a falha paralela do lado privilegiado, onde funções administrativas permanentes e lacunas de PIM agravam a mesma fraqueza subjacente pelo outro lado.

Detection

Confirmar essa lacuna não exige adivinhação — o Microsoft Entra ID registra o estágio exato de autenticação alcançado em cada entrada, por usuário e por aplicativo.

Conforme a própria orientação da Microsoft para encontrar lacunas de MFA em administradores: "Any sign-in where Authentication requirement is Single-factor authentication means there was no multifactor authentication policy that was required for the sign-in." Essa orientação foi escrita especificamente para administradores, mas o campo em si não tem escopo de função — é uma propriedade do evento de entrada, então a mesma verificação se aplica a qualquer população de usuários, administradores ou não.

authenticationRequirement é exposto no recurso signIn no endpoint beta do Microsoft Graph — não está presente no recurso signIn estável da v1.0 — e oferece suporte a $filter com os operadores eq e startsWith:

GET https://graph.microsoft.com/beta/auditLogs/signIns?$filter=authenticationRequirement%20eq%20%27singleFactorAuthentication%27

O filtro está codificado em porcentagem — %20 para os espaços, %27 para as aspas — de modo que a requisição funciona tanto colada em um cliente de linha de comando quanto no Graph Explorer. Sem codificação, os espaços brutos fazem ferramentas como o curl rejeitarem a URL localmente, antes mesmo de ela ser enviada.

Ou com o módulo beta do SDK do Microsoft Graph PowerShell:

Import-Module Microsoft.Graph.Beta.Reports
Connect-MgGraph -Scopes "AuditLog.Read.All","Directory.Read.All"

Get-MgBetaAuditLogSignIn `
  -Filter "authenticationRequirement eq 'singleFactorAuthentication'" `
  -Top 50 `
  -Property UserPrincipalName, AppDisplayName, CreatedDateTime, AuthenticationRequirement

Remediation

1. Implantar o modelo de MFA para todos os usuários da Microsoft

Verifique primeiro se a Microsoft já colocou um no locatário. As políticas gerenciadas pela Microsoft são criadas e implantadas pela Microsoft diretamente em locatários elegíveis, e uma delas se chama Multifactor authentication for all users (Autenticação multifator para todos os usuários) — ela "covers all users in your organization and requires them to use multifactor authentication whenever they sign in." Ela chega inerte: "The policy is automatically created in your tenant in a Report-only state." A Microsoft então a habilita "no less than 30 days after they're introduced in your tenant if they're left in the Report-only state," notificando os locatários duas semanas antes. Filtre por Microsoft na coluna Created by antes de construir uma duplicata.

Caso contrário, use a galeria de modelos de Acesso Condicional, ou construa a política equivalente diretamente:

• Em Atribuições → Usuários, defina Incluir: Todos os usuários.
• Em Excluir, adicione somente as contas break-glass / de acesso de emergência documentadas da sua organização e, se você usa sincronização de identidade híbrida, a função "Directory Synchronization Accounts" — não uma exclusão ampla de "equipe de TI" que silenciosamente recria a lacuna.
• Em Recursos de destino, defina Incluir: Todos os recursos, sem exclusões de aplicativo.
• Em Conceder, escolha Exigir força de autenticação e selecione a Multifactor authentication strength interna.

2. Implantar em modo somente relatório e confirmar que ele realmente sai desse modo

Revise o impacto projetado por meio de Impacto da política ou da pasta de trabalho "Conditional Access Insights and Reporting" antes de mudar Habilitar política para On — é assim que você identifica uma conta break-glass, de serviço ou de autenticação herdada que seria bloqueada inesperadamente. Uma política deixada em modo somente relatório por tempo indeterminado, ou uma lista de exclusões que cresceu silenciosamente além do escopo original, não impõe nada e ainda assim aparece como "On" — verifique isso depois da implantação, não apenas na criação.

3. Validar a cobertura com a ferramenta What If

Execute a ferramenta What If para uma amostra de usuários comuns, sem função administrativa — não apenas para as contas de administrador já cobertas pela outra política —, para confirmar que a nova política de fato se aplica a elas. Políticas habilitadas e políticas em modo somente relatório entram ambas em uma execução de avaliação, então uma política ainda em somente relatório aparecerá aqui. Leia a saída como uma simulação, e não como uma garantia: a Microsoft observa que a ferramenta "doesn't test for Conditional Access service dependencies," e que condições que você deixa sem especificar são condições que ela não consegue avaliar.

4. Não deixe isso substituir o MFA com escopo administrativo, nem o contrário

Se a política de MFA com escopo administrativo também ainda não estiver implantada, trate-a como uma segunda ação, separada. Veja Segurança de identidade no Azure: quando o MFA não basta e Azure: gerenciamento de acesso privilegiado e os riscos sem PIM. Implantar uma política não substitui a outra; ambas estão na própria lista "Secure foundation" da Microsoft por um motivo.

5. Ir além do MFA de base assim que a cobertura estiver estável

Assim que a cobertura ampla de MFA estiver imposta e estável, passe da força de autenticação de base Multifactor authentication strength para métodos resistentes a phishing ou sem senha, para os usuários que conseguem suportá-los — veja Entra ID: mudança no registro de MFA sem senha.

Como a EtcSec detecta isso

A auditoria de Azure/Entra da EtcSec verifica especificamente MFA_NOT_ENFORCED_ALL: uma configuração de Acesso Condicional em que nenhuma política com alvo em todos os usuários e em todos (ou praticamente todos) os aplicativos de nuvem carrega um controle de concessão que exija MFA ou uma força de autenticação equivalente a MFA. Ela é avaliada de forma independente de MFA_NOT_ENFORCED_ADMINS, PA_GLOBAL_ADMIN_NOT_MFA e CA_NO_POLICY_ALL_USERS — resolver uma dessas verificações não resolve esta.