Dia 27: Conditional Access e Zero Trust no Microsoft 365

O modelo de segurança tradicional baseia-se num perímetro defensivo: tudo o que está dentro da rede é confiável, tudo o que está fora é suspeito. Este paradigma deixou de funcionar quando os utilizadores passaram a trabalhar a partir de qualquer lado, ao aceder a recursos na nuvem a partir de dispositivos diversos. O Zero Trust inverte essa lógica — nunca confiar, verificar sempre. No Microsoft 365, o Conditional Access é o motor que materializa esse princípio, ao avaliar cada pedido de autenticação em tempo real com base em identidade, dispositivo, localização e risco.

1. Introdução ao Zero Trust

Zero Trust não é um produto nem uma licença — é uma arquitectura de segurança que assume que a rede já está comprometida. Cada acesso é concedido explicitamente, com o menor privilégio possível, e validado continuamente. A Microsoft adoptou o Zero Trust como base da sua estratégia de segurança, ao integrá-lo no Entra ID (antigo Azure AD), no Defender e no Intune.

No contexto do Microsoft 365, Zero Trust traduz-se em três pilares concretos: verificar explicitamente cada pedido de acesso, aplicar acesso de menor privilégio, e assumir violação — ao segmentar acessos, ao encriptar dados e ao monitorizar actividade. O Conditional Access é a ferramenta principal que implementa estes pilares, ao substituir as políticas estáticas de rede por políticas dinâmicas baseadas em sinais.

2. Princípios Zero Trust

O modelo Zero Trust assenta em três princípios fundamentais que orientam todas as decisões de acesso:

A diferença face ao modelo tradicional é radical: em vez de autenticar uma vez no início da sessão e confiar no utilizador durante horas, o Zero Trust reavalia continuamente. Um utilizador autenticado de manhã pode ter o acesso revogado à tarde se o seu dispositivo deixar de estar conforme ou se for detectado comportamento suspeito.

3. Conditional Access Avançado

O Conditional Access avalia sinais em tempo real para decidir se concede, bloqueia ou restringe o acesso. Os sinais incluem: utilizador e grupo, localização (IP nomeado ou país), plataforma de dispositivo, estado de conformidade (Intune), risco de sessão e risco de utilizador. Com base nesses sinais, a política aplica controlos: exigir MFA, bloquear, conceder com condições, ou aplicar controlos de sessão.

As políticas avançadas combinam múltiplos sinais. Por exemplo: um administrador que acede ao Exchange Admin Center a partir de um IP desconhecido, num dispositivo não gerido, recebe acesso apenas com MFA + sessão restrita (sem transferências, sem acesso a delegações). Um utilizador comum num dispositivo conforme, dentro do horário laboral e num país familiar, obtém acesso sem MFA adicional.

Os controlos de sessão permitem restrições granulares durante a sessão: limitar transferências, bloquear cópia para a área de transferência, impor sessões de curta duração, ou exigir avaliação contínua. Estas restrições são aplicadas pelo Defender for Cloud Apps, que actua como proxy reverso entre o utilizador e a aplicação.

4. Risk-Based Access

O Entra ID Identity Protection calcula dois tipos de risco: user risk (probabilidade de a conta estar comprometida, baseada em fugas de credenciais e detecções anómalas) e risco de início de sessão (probabilidade de a autenticação actual não ser legítima, baseada em localização, dispositivo, velocidade impossível e outros padrões). Cada nível tem uma classificação: baixo, médio, alto.

As políticas de Conditional Access podem usar estes sinais como condição. Uma política típica bloqueia acessos com risco de sessão alto, exige MFA para risco médio, e permite risco baixo sem MFA adicional. O user risk elevado pode exigir reposição de palavra-passe obrigatória antes de qualquer acesso. A remediação automática via reposição automatizada de palavra-passe reduz a carga do apoio técnico.

É crucial diferenciar os dois tipos de risco: o user risk reflecte o estado da conta ao longo do tempo, enquanto o risco de início de sessão avalia uma autenticação específica. Um utilizador pode ter user risk baixo mas risco de início de sessão alto se tentar aceder a partir de um país não habitual sem MFA prévia.

5. Continuous Access Evaluation

Tradicionalmente, um token de acesso OAuth2 vale durante toda a sua duração (tipicamente 60-90 minutos). Se o utilizador for desactivado, o token continua válido até expirar. O Continuous Access Evaluation (CAE) muda isto: os clientes compatíveis com CAE (Outlook, Teams, SharePoint) verificam continuamente se o token ainda é válido, ao consultar eventos críticos no Entra ID.

Os eventos que disparam revogação imediata incluem: conta desactivada, palavra-passe alterada, risco de utilizador elevado, sessão revogada administrativamente, e alteração de conformidade do dispositivo. O acesso é cortado em segundos, não em minutos. Isto reduz drasticamente a janela de exposição em caso de compromisso.

O CAE exige licença Entra ID P1 ou superior e clientes compatíveis. Nem todas as aplicações suportam CAE — as aplicações legadas que dependem de tokens de longa duração sem avaliação contínua mantêm o comportamento tradicional. Verificar a documentação de cada serviço antes de assumir CAE activo.

6. Configuração Prática PME

Para uma PME com Microsoft 365 Business Premium (que inclui Entra ID P1), recomenda-se implementar quatro políticas base, por esta ordem:

Antes de activar qualquer política, ligar o modo apenas-relatório durante 7-14 dias para analisar o impacto sem bloquear acessos legítimos. O modo apenas-relatório permite ver quem seria afectado e ajustar exclusões antes de impor a política. Activar políticas em modo bloqueador sem este período de observação é a causa mais comum de bloqueio em massa.

A verificação via PowerShell confirma quais políticas estão activas e em que modo:

# Listar políticas de Conditional Access
Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessPolicy | 
  Select-Object DisplayName, State, @{N="Grant";E={$_.GrantControls.BuiltinControls}} |
  Format-Table -AutoSize

7. Erros Comuns e Lista de Verificação

A implementação de Conditional Access tem armadilhas recorrentes. Estes são os erros mais frequentes em PME:

Outros erros comuns: activar políticas em modo bloqueador sem período de observação; não testar com utilizadores reais antes de alargar; esquecer aplicações legadas que usam protocolos sem suporte para MFA; não documentar a lógica de cada política, ao tornar a resolução de problemas impossível meses depois; criar políticas sobrepostas que entram em conflito (a política mais restritiva prevalece, mas o utilizador pode não perceber porque é bloqueado).

Lista de verificação para implementação:

• Contas de emergência criadas e excluídas de todas as políticas
• modo apenas-relatório activado 7-14 dias antes de bloquear
• MFA exigida para todos os utilizadores (ao incluir administradores, com exclusão)
• Protocolos legados (IMAP, POP, SMTP) bloqueados
• Com conformidade de dispositivo exigida para acesso a dados sensíveis
• Políticas de risco (início de sessão e utilizador) activadas
• CAE activado nos clientes compatíveis (Outlook, Teams, SharePoint)
• Documentação de cada política: nome, sinais, controlos, justificação
• Revisão trimestral de exclusões e políticas
• Nomenclatura consistente: [Política] – [Sinais] – [Controlo] (ex: “MFA – Todos – Require”)

O Zero Trust não é um projecto com data de fim — é um processo contínuo. Começar com as quatro políticas base, medir o impacto, ajustar, e ir afinando com base nos sinais que o Entra ID fornece. A maturidade chega com iteração, não com uma implementação completa no primeiro dia.

Artigos relacionados:

• Dia 4: Autenticação Moderna — MFA, Conditional Access e Passwordless
• Segurança, Compliance e Microsoft Purview no Microsoft 365 em 2026: Guia para Administradores PME