Políticas de acesso condicional no Active Directory na nuvem para ambientes híbridos: guia prático

Uma multinacional brasileira com 3.200 funcionários distribuídos entre São Paulo, Belo Horizonte e home office descobriu, durante um pentest interno, que credenciais vazadas de um fornecedor terceirizado permitiram acesso ao SharePoint Online sem qualquer barreira além de senha. O Active Directory local sincronizava com o Azure AD, mas nenhuma política de acesso condicional estava ativa. O relatório foi claro: o perímetro de rede havia desaparecido, e a identidade era o novo plano de controle.

Esse cenário não é exceção. Segundo o Microsoft Digital Defense Report 2023, 90% dos ataques bem-sucedidos começam com comprometimento de identidade. Em ambientes híbridos, onde o AD local convive com o Azure AD, a superfície de ataque se expande: sincronização de hash de senha, writeback de dispositivo, Application Proxy expondo apps legados. A resposta não está em firewalls, mas em decisões de acesso baseadas em contexto — o coração do acesso condicional.

O acesso condicional no Azure AD (agora Microsoft Entra ID) avalia sinais em tempo real — quem é o usuário, de onde vem, qual dispositivo, qual app, qual o risco — e aplica controles: permitir, exigir MFA, exigir dispositivo gerenciado, exigir app cliente aprovado, limitar sessão ou bloquear. Neste guia, você verá como estruturar essas políticas para ambientes híbridos, do design à operação contínua.

Fundamentos: identidade como plano de controle

No modelo Zero Trust, a identidade é o novo perímetro. O acesso condicional materializa esse princípio ao mover a decisão de acesso do “rede confiável” para “identidade verificada + dispositivo confiável + contexto de risco baixo”. Cada tentativa de entrada gera um token de avaliação que percorre as políticas na ordem de prioridade (menor número = maior prioridade). A primeira política que corresponde ao escopo (usuários/grupos, apps, condições) vence e seus controles são aplicados.

Em ambientes híbridos, a sincronização via Azure AD Connect é a base. Se você usa Password Hash Sync (PHS), o Azure AD avalia risco de credenciais vazadas comparando hashes com bases públicas. Se usa Pass-through Authentication (PTA) ou Federação (AD FS), o risco de entrada ainda é avaliado, mas o risco de usuário (credencial vazada) depende de PHS ou de feed externo. Para acesso condicional pleno, PHS + Seamless SSO costuma ser o equilíbrio ideal entre segurança e experiência.

Dispositivos são o segundo pilar. Hybrid Azure AD Join (dispositivos ingressados no AD local e registrados no Azure AD) permite políticas que exigem “dispositivo híbrido” como condição. Para gestão moderna, o Intune gerencia conformidade (criptografia, PIN, versão de OS, ausência de jailbreak). A política então diz: “Se app = SharePoint E usuário ∈ Grupo_Vendas E dispositivo ≠ Conforme → Exigir MFA + Bloquear download”.

Arquitetura de políticas: camadas e nomenclatura

Uma estrutura escalável usa camadas nomeadas por função, não por tecnologia. Exemplo:

1. CA-001-BreakGlass-Exclude — Prioridade 1. Escopo: Todos os usuários, Todos os apps. Condição: Usuário ∈ BreakGlass_Admins. Controle: Conceder acesso (sem MFA, sem dispositivo). Modo: Ativado.
2. CA-010-Admin-MFA-Phib-Resistant — Prioridade 10. Escopo: Diretório roles (Global Admin, Security Admin, etc.), Todos os apps. Condição: Qualquer. Controle: Exigir MFA resistente a phishing (FIDO2, Windows Hello for Business, Cert-based auth).
3. CA-020-AllUsers-MFA-Register — Prioridade 20. Escopo: Todos os usuários (exceto BreakGlass), Todos os apps. Condição: Risco de entrada = Alto ou Médio. Controle: Exigir MFA.
4. CA-030-SensitiveApps-DeviceCompliance — Prioridade 30. Escopo: Todos os usuários, Apps: SharePoint, Teams, Exchange, Aplicativos LOB via App Proxy. Condição: Dispositivo ≠ Conforme. Controle: Bloquear acesso.
5. CA-040-LegacyAuth-Block — Prioridade 40. Escopo: Todos os usuários, Apps: Office 365 (Exchange ActiveSync, IMAP, POP, SMTP Auth). Condição: Cliente = Exchange ActiveSync / Outros clientes. Controle: Bloquear.
6. CA-050-Guest-External-Collab — Prioridade 50. Escopo: Usuários convidados (B2B), Apps selecionados. Condição: Localização ≠ NamedLocations_Corp. Controle: Exigir MFA + Limitar sessão a 1 hora.

Essa numeração deixa espaço para inserir políticas intermediárias sem renumerar tudo. Documente cada política em wiki interna com: dono, justificativa, data de criação, data de revisão, grupo de teste, métricas de impacto (logins bloqueados, desafios MFA, falsos positivos).

Sinais de risco e Identity Protection

O Azure AD Identity Protection (requer licença P2) alimenta dois sinais críticos para acesso condicional: Risco de entrada (probabilidade de a autenticação não ser do dono da identidade — ex.: viagem impossível, IP anônimo, token replay) e Risco de usuário (probabilidade de a identidade estar comprometida — ex.: credencial vazada em dark web).

Políticas baseadas em risco são mais inteligentes que regras estáticas de IP. Exemplo: “Se Risco de entrada = Alto → Exigir MFA + Exigir mudança de senha”. O usuário legítimo resolve o desafio; o atacante para. O risco de usuário dispara remediação automática: “Se Risco de usuário = Alto → Exigir redefinição de senha no próximo login”.

Configure Named Locations para IPs corporativos (escritórios, VPN egress) e marque como “Trusted”. Países de alto risco podem ser marcados como “Block” ou usados como condição: “Se Localização = País_Alto_Risco → Bloquear”. Evite bloquear por IP apenas; combine com risco de entrada para reduzir falsos positivos em viagens legítimas.

Dispositivos: do Hybrid Join ao Intune

Para ambientes híbridos, o caminho recomendado é:

1. Hybrid Azure AD Join via GPO/Intune para dispositivos Windows 10/11 ingressados no AD local. Isso garante que o dispositivo tenha identidade no Azure AD e PRT (Primary Refresh Token) para SSO.
2. Intune Enrollment automático (co-management ou full MDM) para receber perfis de conformidade.
3. Compliance Policy no Intune: BitLocker ativo, TPM 2.0, PIN complexo, OS version ≥ 22H2, Defender ativo, sem jailbreak/root.
4. Conditional Access exige “Dispositivo marcado como conforme” para apps sensíveis.

Dispositivos pessoais (BYOD) entram via Azure AD Register (não Join) e podem ser gerenciados com App Protection Policies (MAM) sem MDM full. A política de acesso condicional então usa controle de sessão: “Use app cliente aprovado (Outlook, Teams, Edge) + Políticas de proteção de app”. Isso isola dados corporativos no app sem gerenciar o dispositivo todo.

Tabela de decisão rápida para tipo de dispositivo e controle recomendado:

Aplicativos legados e Application Proxy

Muitas empresas mantêm apps on-premises (intranet, ERP antigo, SharePoint 2016) expostos via Azure AD Application Proxy. O conector instalado na rede local faz outbound para o Azure, sem abrir portas de entrada. O acesso condicional protege esses apps igual aos apps na nuvem: o usuário autentica no Azure AD, a política avalia sinais, e só então o token é emitido para o conector acessar o app local.

Atenção: apps que usam Integrated Windows Authentication (IWA/Kerberos) precisam de Kerberos Constrained Delegation (KCD) configurado no conector. Apps baseados em header ou formulários funcionam nativamente. Para apps que não suportam headers modernos, o Microsoft Entra Private Access (Global Secure Access) oferece alternativa baseada em Zero Trust Network Access (ZTNA), mas exige licenciamento específico.

Teste o fluxo com um grupo piloto antes de abrir para todos. Monitore logs do conector (Event Viewer → Applications and Services Logs → Microsoft → AadApplicationProxy → Connector) e logs de entrada no Azure AD (Sign-in logs → filtrar por App = “SeuAppOnPrem”).

Operação contínua: monitoramento, relatórios e revisão

Políticas de acesso condicional não são “configure e esqueça”. O Conditional Access Insights Workbook (no Azure AD → Monitoring → Workbooks) mostra: cobertura de políticas (% de logins cobertos), resultados (Sucesso, Falha, MFA desafiado, Bloqueado), latência de avaliação, e top usuários/apps impactados. Agende revisão mensal com:

• Análise de falsos positivos: usuários legítimos bloqueados ou desafiados excessivamente.
• Lacunas de cobertura: apps ou usuários sem política aplicável (exceto break-glass).
• Novos apps registrados no Enterprise Applications que precisam de política.
• Mudanças no cenário de risco: novas Named Locations, atualização de compliance policy no Intune.
• Validação de contas break-glass: alerta se usadas, revisão de senha a cada 90 dias.

Use Log Analytics / Microsoft Sentinel para correlacionar logs de entrada com alertas de Identity Protection, Defender for Identity (antigo Azure ATP) e Defender for Cloud Apps. Crie regras de detecção: “Mais de 5 falhas de MFA em 10 min para mesmo usuário” ou “Entrada de país novo para admin global”.

Automatize a documentação com PowerShell / Microsoft Graph: exporte todas as políticas (Get-MgIdentityConditionalAccessPolicy), gere relatório em Markdown/HTML, versiona no Git. Exemplo de script para listar políticas com prioridade e estado:

Connect-MgGraph -Scopes "Policy.Read.ConditionalAccess"
$policies = Get-MgIdentityConditionalAccessPolicy
$policies | Select-Object Id, DisplayName, State, Conditions, GrantControls, SessionControls | Sort-Object @{Expression={$_.Conditions.Applications.IncludeApplications}; Descending=$false} | Format-Table -AutoSize

Integração com fornecedores e identidades externas (B2B)

Colaboração com parceiros exige políticas específicas. O Entra External ID (antigo Azure AD B2B) permite convidar usuários externos com suas próprias identidades (Microsoft, Google, SAML/WS-Fed, Email OTP). A política CA-050-Guest-External-Collab (acima) é ponto de partida. Adicione:

• Access Reviews recorrentes (mensais/trimestrais) para revisar acessos de convidados a grupos/apps.
• Entitlement Management para pacotes de acesso com aprovação, expiração e revisão automática.
• Cross-tenant access settings (configurações de acesso entre tenants) para confiar em MFA do tenant do parceiro (“Trust MFA from partner tenant”) e reduzir desafios duplicados.

Para fornecedores com acesso a sistemas críticos (ex.: ERP via App Proxy), considere Privileged Identity Management (PIM) para acesso just-in-time: o fornecedor solicita ativação de role “ERP_Vendor_Support” por 4 horas, com aprovação do gestor interno e MFA obrigatório. Auditoria completa no log de PIM.

Resposta a incidentes e break-glass

Quando uma política mal configurada bloqueia todos os admins (já aconteceu em grandes empresas), as contas break-glass são a única entrada. Requisitos:

• Mínimo 2 contas (redundância).
• Senha de 32+ caracteres gerada aleatoriamente, armazenada em cofre físico (envelope lacrado assinado) e/or digital (Passwordstate, 1Password Business, CyberArk).
• Excluídas de TODAS as políticas de acesso condicional (CA-001).
• Alertas de uso: regra no Sentinel/Log Analytics → “Sign-in log where UserPrincipalName in (breakglass1@, breakglass2@) → Severity High → Alert SOC”.
• Revisão trimestral: validar senha, testar login, rotacionar se usado.

Simule incidente: “Política CA-030 bloqueia todos os dispositivos por erro de compliance policy”. O time de resposta usa break-glass, desabilita CA-030, corrige compliance policy, reabilita. Documente no runbook de incidente de identidade.

Checklist de implementação faseada

1. Fase 1 - Fundação (semanas 1-2): Habilitar PHS + Seamless SSO, configurar Named Locations, criar contas break-glass, habilitar Identity Protection (modo monitoramento).
2. Fase 2 - Piloto (semanas 3-4): Aplicar CA-010 (Admin MFA resistente) e CA-020 (MFA por risco) em grupo piloto (TI + Segurança). Modo Report-only → Ativado após validação.
3. Fase 3 - Apps sensíveis (semanas 5-6): Hybrid Azure AD Join + Intune enrollment para notebooks do piloto. Aplicar CA-030 (Device Compliance) para SharePoint/Teams/Exchange no piloto.
4. Fase 4 - Bloqueio de auth legada (semana 7): CA-040 em piloto → todos. Monitorar falhas de apps antigos (ex.: multifuncionais scan-to-email).
5. Fase 5 - Expansão e B2B (semanas 8-10): Rollout para toda a empresa. Configurar CA-050 para convidados. Access Reviews para B2B.
6. Fase 6 - Operação contínua (contínuo): Workbook mensal, revisão trimestral de políticas, automação de exportação, testes de break-glass.

Para aprofundar na implementação de identidade híbrida com suporte especializado, a active directory na nuvem empresarial em Vila Nova Conceicao oferece arquitetura e migração guiada.

Conclusão prática

Políticas de acesso condicional bem desenhadas transformam a identidade no plano de controle efetivo do ambiente híbrido. Comece com camadas claras, contas break-glass protegidas, piloto controlado e monitoramento contínuo via workbook e Sentinel. A segurança não está na política perfeita, mas no ciclo de feedback: medir, ajustar, automatizar documentação e testar break-glass. O próximo passo é agendar a revisão trimestral no calendário da equipe de identidade — e garantir que o envelope lacrado das contas de emergência continue intacto.

Para complementar a estratégia de identidade, revise também as boas práticas de cibersegurança para pequenas empresas e o guia de como proteger sua empresa contra ransomware. A superfície de ataque reduzida começa com identidade forte e acesso condicional aplicado em camadas.

Checklist prático

Perguntas frequentes