Quem comprou Zero Trust, comprou autenticação

Nunca confiar, verificar sempre

Há uma pergunta que faço de forma recorrente às equipas de gestão de topo: se a vossa arquitetura fosse testada amanhã, o que resistiria? Durante anos, bastou estar ligado à rede da organização para se ser considerado de confiança. Essa lógica acabou com a chegada do trabalho híbrido, da cloud e com o acesso a partir de qualquer dispositivo. O perímetro, tal como o conhecíamos, simplesmente deixou de existir. O Zero Trust responde com um princípio incómodo: nunca confiar implicitamente, validar sempre. A identidade passa a ser o novo perímetro, quer isso agrade ou não aos donos das redes.

Na prática, isto obriga a responder em contínuo a um conjunto de perguntas: quem pede o acesso, a partir de onde, para quê e com que risco. Nenhuma resposta isolada chega, pois é a combinação que decide se o acesso é concedido, limitado ou negado. É também aqui que a maioria das organizações fica. O multifator e a autenticação adaptativa são o degrau mais fácil de vender e de comprar, por isso aparecem em quase todas as apresentações comerciais como “Zero Trust completo”. Não são. São o primeiro degrau de um percurso bem mais longo.

Privilégios e dados: onde a implementação falha

O princípio de least privilege devia garantir que cada utilizador tem apenas o acesso estritamente necessário, mas, na prática, é aqui que mais organizações falham. Numa auditoria que conduzimos recentemente, uma organização apresentava o seu programa de Zero Trust. Quando questionámos quem tinha acesso ao ERP financeiro, a resposta foi “praticamente todo o departamento, por hábito”.

Do ponto de vista do risco, o que interessa não é o número de controlos implementados, mas o que fica exposto quando um deles falha. Sem saber onde estão os dados críticos, quem lhes acede e como são usados, qualquer política de acesso é um exercício de fé. Classificar e monitorizar os dados ao longo do seu ciclo de vida não é um extra, é o que torna tudo o resto possível.

A estes desafios juntam-se ainda sistemas legacy que nunca vão cumprir os requisitos, acessos mantidos por conveniência histórica e contas de serviço com privilégios permanentes que ninguém revê. Pela nossa experiência são a regra, não a exceção.

A NIS2 acelerou a procura por Zero Trust nos últimos dois anos; no entanto, resolveu poucos dos desafios estruturais. Quando um incidente acontece, é a segmentação e a redução de privilégios que limitam os danos.

Validação, segmentação, visibilidade: o teste real

As avaliações de maturidade que a Oramix realiza no terreno mostram, ano após ano, um gap entre o que se apresenta como Zero Trust e o que resiste a um incidente real.

A validação acontece só no login ou ao longo de toda a sessão? A segmentação chega aos sistemas legacy ou só ao que é fácil e novo? Há visibilidade real sobre os dados mais críticos ou apenas um inventário de aplicações desatualizado?

São as respostas a estas questões, e não a lista de funcionalidades de um fabricante, que separam arquiteturas eficientes das que funcionam apenas como uma fachada. A monitorização contínua de comportamentos anómalos, como uma transferência de dados fora de padrão, é o que deteta uma ameaça real, interna ou externa. Já não interessa quem está dentro ou fora da rede, mas quem tenta aceder a quê, em que contexto e com que risco.

Bem feito, o Zero Trust liberta a organização para adotar cloud, trabalho híbrido e inteligência artificial com mais confiança. Mas essa maturidade não vem numa solução de MFA. Exige que a gestão de topo invista na segmentação, na visibilidade dos dados e na validação contínua, não apenas na porta de entrada, onde quase todos ficaram.

Conteúdo co-produzido pela MediaNext e pela Oramix