Como configurar acesso condicional sem bloquear a operação

Um colaborador pode ter uma palavra-passe válida e, ainda assim, representar um risco. Basta que o acesso aconteça a partir de um equipamento não gerido, de uma localização improvável ou através de um método de autenticação fraco. É por isso que configurar acesso condicional deixou de ser uma tarefa isolada de administração Microsoft 365: é uma decisão de segurança operacional que afeta utilizadores, aplicações, suporte e continuidade de negócio.

Para empresas que trabalham num modelo híbrido, com portáteis fora da rede, aplicações SaaS e equipas distribuídas, a antiga lógica de confiar na rede interna já não chega. O acesso condicional permite tomar decisões em tempo real com base no contexto do pedido de acesso. Mas uma política mal desenhada pode bloquear uma direção comercial em viagem, impedir uma integração crítica ou criar uma carga desnecessária para a equipa de TI.

A regra é simples: não se começa por bloquear. Começa-se por conhecer, testar e aplicar o controlo de forma progressiva.

O que significa configurar acesso condicional

O acesso condicional, normalmente implementado através do Microsoft Entra ID, avalia sinais antes de conceder acesso a recursos empresariais. Entre esses sinais estão a identidade do utilizador, o grupo a que pertence, a aplicação pedida, a localização, o nível de risco da sessão e o estado de conformidade do dispositivo.

A política combina esses sinais com decisões concretas. Pode exigir autenticação multifator, obrigar a utilização de um equipamento gerido, limitar sessões, bloquear protocolos antigos ou impedir totalmente o acesso. Na prática, transforma uma pergunta genérica - “este utilizador tem credenciais?” - numa validação mais útil: “este pedido de acesso é aceitável para este recurso, neste momento e nestas condições?”.

Isto não substitui a gestão de identidades, a gestão de endpoints, o EDR ou a proteção de dados. Coordena-os. Se o Intune não consegue confirmar que um portátil está cifrado e atualizado, por exemplo, a política de acesso condicional não deve assumir que esse equipamento é seguro.

Antes de criar políticas, faça o diagnóstico

A maior parte dos incidentes causados por acesso condicional não resulta da tecnologia. Resulta de decisões tomadas sem inventário, sem proprietários definidos e sem perceber dependências operacionais.

O diagnóstico deve identificar quem acede, a quê, a partir de onde e com que dispositivos. Não basta olhar para utilizadores internos. É necessário mapear contas de administração, contas de emergência, convidados B2B, equipas externas, contas de serviço e integrações que usam autenticação legada.

Também importa classificar aplicações. O correio eletrónico e o SharePoint podem suportar regras mais exigentes do que uma aplicação antiga que ainda depende de protocolos específicos. Isso não significa aceitar o risco indefinidamente. Significa definir uma medida transitória, um responsável e uma data para corrigir a dependência.

Nesta fase, é útil responder a quatro questões operacionais:

• Que aplicações são críticas para faturação, produção, logística ou atendimento?
• Que utilizadores necessitam de acesso fora de Portugal, em mobilidade ou a partir de equipamentos partilhados?
• Que dispositivos são geridos e conseguem reportar conformidade?
• Que contas técnicas podem falhar se forem sujeitas a MFA interativa?

Sem estas respostas, uma política global parece eficiente no portal de administração, mas pode gerar indisponibilidade num processo de negócio que ninguém tinha documentado.

Como configurar acesso condicional por fases

A implementação segura deve seguir uma sequência controlada. Na ITPOINT, esta é a diferença entre ativar uma funcionalidade e operar uma arquitectura de segurança com responsabilidade definida.

1. Proteja as contas administrativas primeiro

As contas com privilégios elevados são o primeiro alvo de qualquer atacante e devem ser tratadas de forma diferente de um utilizador comum. Exija MFA resistente a phishing sempre que possível, limite o acesso a dispositivos geridos e reduza o número de administradores permanentes.

Mantenha pelo menos duas contas de emergência, protegidas, monitorizadas e excluídas apenas das políticas estritamente necessárias. Estas contas não são uma excepção informal. Devem ter proprietário, credenciais guardadas segundo um procedimento definido, registo de utilização e testes regulares. Uma conta de emergência que nunca foi validada não é um plano de contingência.

2. Aplique MFA a todos os utilizadores, num modo de reporte

A autenticação multifator é a política com maior impacto na redução de comprometimento de identidades. Contudo, antes de impor o requisito, coloque a política num modo de reporte. Este modo permite verificar quem seria afectado sem bloquear acessos reais.

Analise os registos durante tempo suficiente para abranger períodos normais de trabalho, fechos financeiros, deslocações e utilização fora de horário. Corrija métodos de autenticação desatualizados, comunique o processo aos utilizadores e prepare o suporte para os primeiros dias após a ativação.

O objetivo não é apenas ativar MFA. É reduzir chamadas de suporte e garantir que os métodos aprovados são adequados ao nível de risco. Uma notificação push sem validação de número pode ser suficiente em alguns contextos, mas não oferece a mesma proteção que uma chave de segurança ou autenticação baseada no dispositivo para funções administrativas.

3. Exija dispositivos conformes nos recursos certos

Depois de estabilizar a MFA, avance para políticas baseadas no estado do dispositivo. O princípio é directo: dados empresariais sensíveis não devem ser acedidos livremente a partir de equipamentos sem cifragem, antivírus, atualizações ou gestão centralizada.

A aplicação desta regra depende da realidade da empresa. Num ambiente com todos os portáteis inscritos no Intune, pode exigir conformidade para o Microsoft 365 e aplicações de negócio. Num cenário com fornecedores externos ou BYOD, pode ser preferível permitir acesso limitado no navegador, com controlo de sessão, em vez de sincronização local de ficheiros.

A decisão deve equilibrar segurança e produtividade. Bloquear todos os dispositivos pessoais pode ser correcto para uma empresa com informação regulada. Noutra organização, o acesso web restrito pode ser uma solução temporária enquanto se formaliza uma política de ambiente de trabalho moderno.

4. Reduza a superfície de ataque progressivamente

Com MFA e dispositivos geridos estabilizados, pode introduzir controlos adicionais: bloqueio de autenticação legada, restrições por país ou localização, políticas de risco de início de sessão e regras específicas para aplicações críticas.

O bloqueio de autenticação legada merece atenção particular. POP, IMAP, SMTP autenticado e clientes antigos podem contornar mecanismos modernos de MFA. Antes de bloquear, identifique impressoras, scanners, aplicações ERP e sistemas de monitorização que possam depender destes protocolos. Depois, substitua a autenticação básica por métodos modernos ou contas técnicas com permissões mínimas.

As restrições geográficas também exigem prudência. Bloquear países onde a empresa não opera reduz ruído e tentativas automatizadas, mas não deve ser tratado como controlo principal. Um atacante pode usar um endereço IP português comprometido, e um colaborador pode precisar de acesso legítimo durante uma viagem. A localização é um sinal adicional, não uma garantia.

Políticas que normalmente criam problemas

Uma política demasiado ampla, aplicada a “todos os utilizadores” e “todas as aplicações”, é tentadora. É também uma das formas mais rápidas de gerar um incidente operacional. As exclusões devem ser mínimas, temporárias e documentadas, mas as inclusões precisam de ser específicas no início.

Outro erro comum é ignorar contas não humanas. Uma conta de serviço não deve receber uma excepção permanente apenas porque deixou de funcionar após uma alteração. Deve ser revista: precisa mesmo de iniciar sessão de forma interativa? Pode usar identidade gerida, certificado ou outro método adequado? Tem apenas as permissões necessárias?

Também não basta criar políticas e deixá-las sem acompanhamento. O acesso condicional depende de alterações contínuas: novos colaboradores, fusões de empresas, aplicações SaaS, equipamentos substituídos e requisitos de conformidade. Sem governança activa, as exceções acumulam-se e o modelo perde eficácia.

Monitorização, suporte e responsabilidade operacional

Depois de configurar acesso condicional, acompanhe os registos de início de sessão, os resultados das políticas e os pedidos de suporte. Procure bloqueios recorrentes, dispositivos marcados como não conformes, tentativas de autenticação legada e acessos anómalos a contas privilegiadas.

Defina igualmente indicadores que façam sentido para a gestão: percentagem de utilizadores com MFA forte, número de dispositivos conformes, contas administrativas sem acesso permanente, exceções ativas e tempo médio para corrigir uma falha de conformidade. Estes dados permitem transformar segurança numa disciplina mensurável, em vez de uma colecção de regras técnicas.

A implementação deve ter dono. A equipa de segurança define requisitos, a equipa de infraestrutura garante integração com dispositivos e aplicações, e o negócio valida impactos e exceções. Quando estas responsabilidades não estão claras, os bloqueios acabam por ser resolvidos com permissões excessivas, precisamente o oposto do que a política pretendia evitar.

Configurar acesso condicional é estabelecer uma fronteira que acompanha o utilizador, o dispositivo e o risco, não apenas a rede. Quando é desenhado com diagnóstico, testes, SLA de suporte e revisão contínua, deixa de ser um conjunto de bloqueios e passa a ser um controlo real de continuidade operacional.