Blog do Chesley

Entenda por que o teto de políticas existe, como ele evoluiu, o que consome esse espaço sem que você perceba e como arquitetar seu ambiente para jamais atingi-lo.

O que é o Acesso Condicional e por que o limite importa?

O Acesso Condicional (Conditional Access) é o mecanismo central de aplicação de políticas de segurança no Microsoft Entra ID. Ele funciona como um motor de decisão baseado em sinais: identidade do usuário, estado do dispositivo, localização de rede, risco de sessão e aplicativo-alvo são avaliados a cada solicitação de autenticação, e a política determina se o acesso é concedido, bloqueado ou condicionado a controles adicionais como autenticação multifator (MFA) ou dispositivo em conformidade.

Esse modelo de if-then é a base da arquitetura Zero Trust da Microsoft: verificar explicitamente, usar acesso com privilégio mínimo e assumir violação. A cada login, o mecanismo avalia todas as políticas aplicáveis ao usuário, ao recurso e às condições da sessão — e o resultado é a combinação cumulativa de todas elas. Se uma política exige MFA e outra exige dispositivo em conformidade, o usuário precisa satisfazer ambas as exigências.

Esse modelo de avaliação contínua é o que torna o limite de políticas uma questão operacional séria: cada política adicional aumenta o custo computacional de cada evento de login em todo o tenant.

Qual é o limite atual?

A Microsoft documenta oficialmente os limites do serviço Microsoft Entra ID na página Microsoft Entra service limits and restrictions do Microsoft Learn. O limite vigente para políticas de Acesso Condicional é:

240 políticas por tenant

Esse teto abrange todas as políticas independentemente do estado: ativas (On), desativadas (Off) e em modo somente relatório (Report-only). Uma política desativada consome a mesma cota que uma ativa.

Histórico de evolução do limite

O número não foi sempre 240. A Microsoft ajustou o teto ao longo do tempo à medida que a infraestrutura de avaliação evoluiu:

O valor de 195 que aparece frequentemente em artigos mais antigos e em provas de certificação AZ-500 se refere a uma versão anterior do limite — e não ao limite de políticas, mas ao de Named Locations (localizações nomeadas por intervalo de IP), que continua sendo 195. A confusão entre esses dois limites é uma das imprecisões mais comuns encontradas em blogs e guias estrangeiros sobre o tema.

Por que existe um limite?

A razão é arquitetural e tem duas dimensões: desempenho em escala e integridade operacional.

Impacto no tempo de autenticação

Cada solicitação de login processada pelo Microsoft Entra ID precisa ser avaliada contra todas as políticas de Acesso Condicional do tenant — incluindo aquelas desativadas e em modo relatório. Isso ocorre porque o motor precisa determinar quais políticas são aplicáveis àquela sessão específica antes de decidir quais executar.

O processo envolve:

1. Coleta dos sinais da sessão (fase 1 da avaliação)
2. Identificação das políticas aplicáveis com base em usuário, aplicativo, plataforma, localização e condições de risco
3. Avaliação dos controles de concessão (grant controls) para políticas ativas (fase 2)
4. Aplicação dos controles de sessão (session controls)

Quanto mais políticas existem no tenant, maior o trabalho nas fases 1 e 2 — e esse processamento precisa ocorrer em tempo real, sem impacto perceptível para o usuário. A Microsoft conduz avaliações periódicas de capacidade e ajusta o limite quando identifica espaço adicional disponível na infraestrutura, como aconteceu em abril de 2026.

Tamanho do arquivo JSON da política

Cada política de Acesso Condicional é armazenada internamente como um arquivo JSON. Há um limite de tamanho para esse arquivo. Políticas que listam individualmente centenas de GUIDs de usuários, grupos ou aplicativos podem atingir esse limite antes mesmo de chegar ao teto de quantidade de políticas. A documentação oficial recomenda:

• Usar grupos de segurança ou funções de diretório para escopar usuários, em vez de listar GUIDs individualmente
• Usar filtros de aplicativo (filter for applications) para agrupar aplicativos por atributo, em vez de listá-los um a um
• Cada política suporta no máximo 250 aplicativos explicitamente listados. Para o mesmo controle em mais de 250 apps, crie políticas duplicadas (Política A: apps 1–250, Política B: apps 251–500, etc.)

O que consome o limite sem que você perceba

Este é o ponto mais negligenciado em guias e tutoriais: o limite de 240 não pertence inteiramente ao administrador. Partes dele são reservadas ou consumidas automaticamente.

Políticas Gerenciadas pela Microsoft (Microsoft-Managed Policies)

A partir de determinado ponto, a Microsoft passou a criar e implantar automaticamente políticas de Acesso Condicional diretamente nos tenants elegíveis — sem ação do administrador. Essas políticas aparecem com “Microsoft” na coluna “Criado por” no portal do Entra ID.

As políticas gerenciadas atualmente incluem:

• Bloquear autenticação herdada (legacy authentication)
• Bloquear fluxo de código de dispositivo (device code flow)
• Exigir MFA para acesso a portais de administração Microsoft
• Exigir MFA para todos os usuários
• Exigir MFA para usuários com MFA por usuário configurado
• Exigir MFA e reautenticação em logins de risco
• Bloquear acesso para usuários de alto risco
• Bloquear agentes de identidade de carga de trabalho de alto risco (Preview)
• Exigir autenticação resistente a phishing para administradores (via Baseline Security Mode)

Essas políticas são criadas inicialmente em estado Report-only e habilitadas automaticamente 45 dias depois, salvo se o administrador as desativar explicitamente. Elas contam no limite do tenant e não podem ser excluídas — apenas desativadas ou modificadas (exclusão de usuários e alternância de estado).

Se o seu tenant está próximo do limite, verifique quantas dessas políticas gerenciadas já foram criadas. Elas podem representar 8 a 10 entradas que você não planejou.

Políticas em modo Report-only e desativadas

Uma prática comum durante projetos de implementação e testes é criar políticas em modo Report-only para monitorar o impacto antes da ativação. Essas políticas também consomem cota. O mesmo vale para políticas antigas que foram desativadas mas nunca excluídas. Em tenants maduros, é comum encontrar dezenas de políticas “órfãs” que acumulam ao longo de anos sem revisão.

Estratégias para manter o número de políticas sob controle

A Microsoft é explícita na documentação: o objetivo não é chegar perto do limite — é manter o menor número possível de políticas que satisfaça os requisitos de segurança da organização.

1. Agrupe aplicativos com os mesmos requisitos

O erro mais comum é criar uma política por aplicativo. Se dez aplicativos exigem MFA para todos os usuários, isso deve ser uma única política com os dez aplicativos incluídos — não dez políticas separadas.

Analise os aplicativos do tenant e classifique-os por perfil de controle:

• Mesmos usuários + mesmo controle = mesma política
• Mesma plataforma + mesmo nível de risco = mesma política

2. Use filtros de aplicativo em vez de listas estáticas

O recurso Filter for applications permite escopar políticas com base em atributos de aplicativos (proprietário, tag, tipo) em vez de listar GUIDs explicitamente. Isso:

• Elimina a necessidade de editar políticas quando novos aplicativos são adicionados
• Evita políticas duplicadas para conjuntos grandes de aplicativos
• Reduz o risco de inconsistências ao adicionar ou remover apps manualmente

3. Use grupos e funções para escopo de usuários

Em vez de listar usuários individualmente (o que infla o tamanho do JSON), use:

• Grupos de segurança para conjuntos estáticos de usuários
• Grupos dinâmicos para escopos baseados em atributos (departamento, cargo, localização)
• Funções de diretório para políticas que se aplicam a administradores específicos

Note que políticas que segmentam funções ou grupos só são avaliadas no momento em que um novo token é emitido. Um usuário recém-adicionado a um grupo não está sujeito à política até que seu token atual expire.

4. Reserve políticas granulares para casos de uso de alto privilégio

A recomendação oficial é usar políticas amplas como base e políticas granulares apenas onde há requisitos específicos: aplicativos críticos, usuários privilegiados, dispositivos sem gestão, acessos externos. Um exemplo válido de política granular é exigir chaves de segurança físicas (FIDO2) para administradores que acessam portais de gestão — um controle que não precisa ser aplicado a todos os usuários.

5. Revise e higienize periodicamente

Estabeleça um processo semestral de revisão do inventário de políticas:

• Políticas em Report-only sem plano de ativação devem ser ativadas ou excluídas
• Políticas desativadas há mais de 6 meses devem ser avaliadas para exclusão
• Políticas criadas para projetos concluídos (migrações, pilotos) devem ser removidas

Implicações de segurança do limite

Políticas de bloqueio têm precedência, mas exceções importam

Quando múltiplas políticas se aplicam a uma sessão, os controles são combinados com AND lógico: o usuário precisa satisfazer todas as exigências. Uma única política de bloqueio de acesso (Block access) é suficiente para impedir o acesso, independentemente das demais políticas.

Por isso, políticas de bloqueio devem ser tratadas com atenção redobrada e testadas em Report-only antes de serem ativadas. O impacto não intencional de uma política mal configurada pode bloquear usuários legítimos — inclusive administradores.

Contas de acesso de emergência (break-glass)

A Microsoft recomenda explicitamente excluir contas de acesso de emergência de todas as políticas de Acesso Condicional, incluindo as gerenciadas pela Microsoft. Essas contas são o último recurso em cenários onde todos os administradores são bloqueados por erro de configuração. Se estiverem cobertas por uma política de bloqueio ou MFA sem acesso ao segundo fator, o tenant pode ficar inacessível.

Boas práticas para contas de emergência:

• Criar no mínimo duas contas, armazenadas em locais físicos seguros e distintos
• Usar autenticação com credenciais longas e complexas, sem dependência de MFA por aplicativo
• Monitorar ativamente qualquer uso dessas contas via alertas no Microsoft Sentinel ou no Entra ID
• Excluí-las explicitamente de todas as políticas, inclusive das gerenciadas

Contas de serviço e identidades de carga de trabalho

Políticas de Acesso Condicional com escopo de usuários não se aplicam a entidades de serviço (service principals). Para cobrir identidades não humanas — aplicativos, scripts, pipelines de CI/CD — é necessário criar políticas específicas para identidades de carga de trabalho (workload identities), disponíveis com licença Microsoft Entra Workload ID.

Contas de serviço tradicionais (contas de usuário usadas por sistemas) devem ser migradas para identidades gerenciadas (managed identities) sempre que possível, eliminando credenciais estáticas e tornando o controle de acesso mais preciso.

Como verificar o uso atual do limite no seu tenant

Via Portal do Microsoft Entra

1. Acesse https://entra.microsoft.com
2. Navegue até Proteção > Acesso Condicional > Políticas
3. O número total de políticas listadas (independentemente do estado) é o consumo atual do limite

Via Microsoft Graph API

http

GET https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies?$count=true

Com o cabeçalho ConsistencyLevel: eventual, a resposta incluirá o total de políticas no campo @odata.count.

Via PowerShell (módulo Microsoft.Graph)

powershell

# Instalar o módulo se necessário
Install-Module Microsoft.Graph -Force
# Conectar com os escopos necessários
Connect-MgGraph -Scopes "Policy.Read.All"
# Obter todas as políticas e contar
$policies = Get-MgIdentityConditionalAccessPolicy -All
$policies.Count
# Detalhar por estado
$policies | Group-Object -Property State | Select-Object Name, Count

A saída agrupada por estado (enabled, disabled, enabledForReportingButNotEnforced) permite identificar rapidamente onde o espaço está sendo consumido.

Planejamento para tenants com alto volume de políticas

Se o seu tenant já está acima de 150 políticas, é hora de iniciar um projeto de consolidação antes de atingir o limite. Algumas abordagens:

Auditoria por matriz de controle: construa uma planilha cruzando usuários × aplicativos × controles. Políticas com a mesma combinação de controle e escopo de usuário podem ser candidatas à fusão.

Uso de grupos dinâmicos para escopo: agrupe usuários por atributo (ex: departamento = Financeiro) e use o grupo nas políticas. Quando um colaborador entra ou sai do departamento, a política se ajusta automaticamente sem edição manual.

Templates de política como código: exporte políticas via Graph API em JSON e versione-as em um repositório Git. Isso facilita revisões periódicas, comparações entre estados e rollback de configurações.

Modo Report-only como etapa obrigatória: qualquer nova política deve ser criada em Report-only e analisada via logs de login antes da ativação. Isso evita criações especulativas que ficam no tenant indefinidamente.

Conclusão

O limite de políticas de Acesso Condicional não é um obstáculo arbitrário — é um reflexo direto do custo de processamento de cada evento de autenticação no tenant. Tenants com arquiteturas de políticas bem pensadas raramente se aproximam do teto, pois a consolidação inteligente de regras é, ao mesmo tempo, uma boa prática de segurança e de performance.

Os pontos que mais frequentemente surpreendem administradores:

• Políticas desativadas e em Report-only consomem cota da mesma forma que políticas ativas
• As políticas gerenciadas pela Microsoft são criadas automaticamente e não podem ser excluídas
• O limite de 195 citado em muitas fontes refere-se a Named Locations, não a políticas — uma distinção crítica para quem planeja a arquitetura do tenant
• O teto atual na documentação oficial é 240 políticas, mas o comportamento real observado em abril de 2026 indica capacidade de até 244

A recomendação da Microsoft é inequívoca: mantenha o número de políticas tão baixo quanto possível, priorize políticas amplas com controles abrangentes e reserve granularidade para cenários de alto risco e alto privilégio.

Referências oficiais utilizadas neste artigo:

• Microsoft Entra service limits and restrictions — Microsoft Learn
• Plan a Conditional Access deployment — Microsoft Learn
• Build Conditional Access policies — Microsoft Learn
• Microsoft-managed Conditional Access policies — Microsoft Learn
• Conditional Access: Network signals — Microsoft Learn
• Manage emergency access accounts — Microsoft Learn