O Conditional Access (Acesso Condicional) é o mecanismo central de controlo de acesso do Microsoft Entra ID. Permite definir políticas do tipo “Se [condição] → Então [controlo]” — por exemplo, exigir MFA quando um utilizador acede a partir de um país não esperado, ou bloquear completamente o acesso de dispositivos não geridos a aplicações sensíveis.

No contexto da NIS2 / Decreto-Lei n.º 125/2025, o Conditional Access é uma das ferramentas mais directas para cumprir a exigência de autenticação forte e controlo de acesso baseado em risco. Este artigo guia a configuração das políticas essenciais para uma PME ou entidade pública portuguesa.

ℹ Requisito de licença

O Conditional Access requer Microsoft Entra ID P1 (incluído no Microsoft 365 Business Premium, E3 e superior). Para funcionalidades avançadas baseadas em risco (sign-in risk, user risk), é necessário Entra ID P2 (incluído no E5 ou Entra ID P2 standalone). Sem licença P1, utiliza os Security Defaults — protecção básica mas sem granularidade.

1. Como funciona o Conditional Access

Cada política de Conditional Access é avaliada em dois momentos: quando o utilizador tenta autenticar e quando pede acesso a um recurso. A estrutura de uma política é sempre a mesma:

Componente O que define Exemplos
Atribuições — Utilizadores A quem se aplica a política Todos os utilizadores, grupo específico, função de directório
Atribuições — Recursos Que aplicações ou serviços Todas as aplicações cloud, Exchange Online, SharePoint
Condições Sinais adicionais de contexto Localização, plataforma, risco de sign-in, cliente
Controlos de Acesso O que acontece se a política disparar Conceder com MFA, bloquear, exigir dispositivo conforme

⚠ Regra importante: quando várias políticas se aplicam ao mesmo utilizador, todas têm de ser satisfeitas (lógica AND). Se uma política exige MFA e outra exige dispositivo conforme, o utilizador tem de cumprir ambas para obter acesso.

2. Antes de começar — criar contas break-glass

Este passo é obrigatório antes de criar qualquer política. Uma configuração incorrecta pode bloquear todos os administradores do tenant. As contas break-glass (ou de emergência) são contas excluídas de todas as políticas de Conditional Access — garantem sempre uma via de acesso de recuperação.

Como criar e proteger contas break-glass

  1. Criar 2 contas com nomes tipo [email protected] e [email protected]
  2. Atribuir a função Global Administrator a ambas
  3. Usar domínio .onmicrosoft.com — nunca o domínio personalizado (que pode ter problemas DNS)
  4. Definir password longa e aleatória (mínimo 24 caracteres); guardar em cofre físico ou gestor de passwords offline
  5. Não registar MFA nestas contas — a autenticação faz-se apenas com password
  6. Criar grupo de segurança CA-Excluded-BreakGlass e adicionar ambas as contas
  7. Monitorizar logins destas contas com alerta no Microsoft Sentinel ou via regra no Azure Monitor

⚠ Crítico: Em todas as políticas de Conditional Access que vais criar, exclui sempre o grupo CA-Excluded-BreakGlass. Sem esta exclusão, uma política mal configurada pode bloquear o acesso total ao tenant.

3. Política 1 — MFA para todos os utilizadores

Esta é a política base recomendada pela Microsoft e exigida pela NIS2. Aplica MFA a todos os utilizadores em todos os recursos cloud. Começa em modo Report-only para validar o impacto antes de activar.

Caminho: entra.microsoft.com → Protection → Conditional Access → Policies → + New policy

Campo Valor a configurar
Name CA01 - Require MFA - All Users - All Apps
Users > Include All users
Users > Exclude Grupo CA-Excluded-BreakGlass
Target resources > Include All resources (antigo “All cloud apps”)
Grant Grant access → Require multifactor authentication
Enable policy Report-only (primeiro) → On (após validação)

✓ Dica: Antes de passar de Report-only para On, vai a Sign-in logs e filtra por “Conditional Access: Report-only”. Verifica quantos utilizadores teriam sido afectados e se existem contas de serviço não previstas que precisam de ser excluídas.

4. Política 2 — MFA reforçada para administradores

Contas com funções administrativas são o alvo preferencial de atacantes. Esta política exige MFA resistente a phishing (FIDO2, Windows Hello for Business ou certificado) para todas as funções administrativas privilegiadas — um nível acima da MFA básica exigida aos utilizadores normais.

Campo Valor a configurar
Name CA02 - Require Phish-Resistant MFA - Admins
Users > Include Directory roles: Global Administrator, Security Administrator, Exchange Administrator, SharePoint Administrator, Helpdesk Administrator, Conditional Access Administrator, User Administrator, Privileged Role Administrator
Users > Exclude Grupo CA-Excluded-BreakGlass
Target resources > Include All resources
Grant Grant access → Require authentication strength → Phishing-resistant MFA
Enable policy Report-only → On

⚠ Atenção: Antes de activar, confirma que todos os administradores têm um método resistente a phishing registado (FIDO2 key, Windows Hello ou certificado). Caso contrário, ficam bloqueados. Usa um Temporary Access Pass (TAP) para permitir o registo inicial sem MFA.

5. Política 3 — Bloquear países não autorizados

Para organizações sem necessidade de acesso internacional, bloquear por país é uma redução de superfície de ataque simples e eficaz. Esta política bloqueia todos os países excepto Portugal (adapta conforme necessário — ex: incluir Espanha para equipas com mobilidade ibérica).

Passo 1 — Criar a Named Location

Caminho: Conditional Access → Named locations → + Countries location

  1. Name: Allowed Countries - PT
  2. Seleccionar: Portugal (adicionar outros países se necessário)
  3. Guardar

Passo 2 — Criar a política de bloqueio

Campo Valor a configurar
Name CA03 - Block Access - Non-Allowed Countries
Users > Include All users
Users > Exclude Grupo CA-Excluded-BreakGlass
Target resources > Include All resources
Conditions > Locations > Include Any location
Conditions > Locations > Exclude Named location: Allowed Countries – PT
Grant Block access
Enable policy Report-only → On (validar primeiro nos logs!)

6. Política 4 — Exigir dispositivo conforme (Intune)

Esta política requer que o dispositivo esteja inscrito no Microsoft Intune e marcado como conforme com as políticas de compliance definidas. É a implementação prática do conceito Zero Trust para endpoints — sem gestão de dispositivo, sem acesso.

ℹ Pré-requisito: Requer Microsoft Intune (incluído no Microsoft 365 Business Premium ou E3+). Os dispositivos têm de estar inscritos e com políticas de compliance configuradas antes de activar esta política.

Campo Valor a configurar
Name CA04 - Require Compliant Device - All Apps
Users > Include All users
Users > Exclude Grupo CA-Excluded-BreakGlass
Target resources > Include All resources
Grant Grant access → Require device to be marked as compliant
Enable policy Report-only (validar impacto com cuidado)

7. Política 5 — MFA para gestão do Azure

A Microsoft impõe obrigatoriamente MFA para acesso ao portal Azure, Microsoft Entra Admin Center e Microsoft Intune Admin Center desde outubro de 2024 (Fase 1) e para Azure CLI/PowerShell desde outubro de 2025 (Fase 2). Mesmo assim, é boa prática ter uma política explícita para documentar e controlar este requisito no teu tenant.

Campo Valor a configurar
Name CA05 - Require MFA - Azure Management
Users > Include All users
Users > Exclude Grupo CA-Excluded-BreakGlass
Target resources > Include Select resources → Windows Azure Service Management API
Grant Grant access → Require multifactor authentication
Enable policy On

8. Modo Relatório — testar antes de activar

O modo Report-only permite simular o impacto de uma política sem a aplicar. Os eventos aparecem nos logs com o resultado “Report-only: Would have required MFA” sem afectar os utilizadores. É a forma correcta de validar antes de activar.

Como analisar os logs de Report-only

  1. Aceder a entra.microsoft.com → Monitoring → Sign-in logs
  2. Filtrar coluna Conditional Access por Report-only: Would have required MFA
  3. Identificar contas de serviço ou aplicações legadas que falhariam
  4. Excluir essas contas ou aplicações da política antes de activar
  5. Usar a ferramenta What If (Conditional Access → What If) para simular cenários específicos

✓ Boas práticas de activação: Mantém as políticas em Report-only durante 5 a 7 dias úteis antes de activar. Escolhe uma sexta-feira de manhã para activar — se houver problemas, há tempo para resolver antes do fim de semana e os utilizadores estão disponíveis para contacto.

9. Erros comuns e como evitá-los

Erro Consequência Prevenção
Não criar break-glass accounts antes Bloqueio total do tenant Criar e testar break-glass ANTES de qualquer política
Activar directamente sem Report-only Bloqueio de contas de serviço e aplicações legadas Usar sempre Report-only 5-7 dias antes
Não excluir contas de serviço Falha em scripts, sync, automatismos Identificar todas as service accounts nos logs antes de activar
Bloquear por país sem validar VPN/proxies Bloqueio de utilizadores com VPN em país estrangeiro Verificar IPs de saída de VPNs corporativas e adicionar às Named Locations
Exigir dispositivo conforme sem Intune configurado Bloqueio de todos os utilizadores Confirmar inscrição e compliance de dispositivos antes de activar

10. Monitorizar e auditar políticas

Após activar as políticas, é necessário monitorizar regularmente para detectar problemas e garantir que as políticas estão a funcionar como esperado.

O que monitorizar Onde Frequência
Sign-ins bloqueados por CA Entra ID → Sign-in logs → filtrar “Failure” Diária (primeiras 2 semanas)
Logins das contas break-glass Sign-in logs → filtrar por conta breakglass Alerta automático imediato
Alterações às políticas CA Entra ID → Audit logs → categoria “Policy” Semanal
Utilizadores sem MFA registado Entra ID → Users → Authentication methods Mensal
CA Insights e políticas em Report-only Conditional Access → Insights and reporting Mensal

Resumo — As 5 políticas a implementar

Política Utilizadores Controlo Prioridade
CA01 – MFA All Users Todos Require MFA CRÍTICO
CA02 – Phish-Resistant Admins Administradores Phishing-resistant MFA CRÍTICO
CA03 – Block Non-PT Countries Todos Block access ALTA
CA04 – Compliant Device Todos Require compliant device ALTA
CA05 – MFA Azure Mgmt Todos Require MFA (Azure API) ALTA

Este artigo foi útil?

Duarte Spínola

Deixe um Comentário