Segurança SASE: controlo onde o trabalho acontece

A segurança SASE tornou-se relevante porque a fronteira da empresa deixou de coincidir com o perímetro do escritório. Utilizadores trabalham a partir de casa, em deslocação ou numa filial; aplicações críticas vivem em cloud pública, SaaS e datacenters privados; os dados circulam fora da rede tradicional. Manter o mesmo modelo de segurança baseado apenas num firewall central cria atrasos, zonas sem visibilidade e políticas difíceis de aplicar de forma coerente.

Para uma empresa portuguesa de média dimensão, a questão não é adoptar uma sigla nova. É garantir que cada acesso a uma aplicação, cada dispositivo e cada ligação entre localizações estão sujeitos ao controlo certo, sem transformar a operação diária num obstáculo. É aqui que uma arquitectura SASE bem desenhada faz diferença.

O que é a segurança SASE, na prática

SASE significa Secure Access Service Edge. É um modelo de arquitectura que aproxima capacidades de rede e de cibersegurança do utilizador, da aplicação e dos dados, em vez de obrigar todo o tráfego a passar pelo datacenter ou pela sede para ser inspeccionado.

Na prática, conjuga normalmente conectividade WAN definida por software, ou SD-WAN, com serviços de segurança entregues a partir da cloud. Estes serviços incluem firewall como serviço, gateway web seguro, acesso à rede com confiança zero, protecção contra ameaças, controlo de aplicações cloud e prevenção de perda de dados.

O objectivo não é substituir automaticamente todos os equipamentos existentes. É aplicar uma política de acesso consistente, independentemente de o utilizador estar no escritório de Lisboa, numa delegação, em casa ou ligado a uma aplicação SaaS. A decisão de permitir, limitar ou bloquear deixa de depender apenas da localização IP e passa a considerar identidade, postura do dispositivo, risco, aplicação e contexto.

Esta mudança é especialmente relevante para organizações que cresceram por camadas: VPN para acesso remoto, firewall na sede, políticas distintas por filial, licenças isoladas para protecção de endpoints e regras manuais para aplicações cloud. Cada ferramenta pode funcionar isoladamente. O problema surge quando ninguém consegue comprovar, com rapidez, quem acedeu a quê, a partir de onde e sob que política.

Porque o perímetro tradicional já não chega

Uma VPN convencional cria frequentemente acesso à rede antes de validar a necessidade de acesso a uma aplicação concreta. Isto aumenta a superfície de ataque e facilita movimentos laterais se uma credencial for comprometida. Um utilizador externo que apenas precisa de aceder a um ERP ou a um servidor de ficheiros não deve receber visibilidade desnecessária sobre a rede interna.

O modelo de confiança zero, aplicado através de ZTNA - Zero Trust Network Access -, inverte esta lógica. O acesso é concedido aplicação a aplicação, após validação da identidade e das condições definidas pela empresa. Um dispositivo sem gestão, um sistema operativo desactualizado ou uma autenticação considerada suspeita podem exigir validação adicional ou ver o acesso bloqueado.

Também a experiência do utilizador pesa na decisão. Quando o tráfego para Microsoft 365, outras plataformas SaaS ou aplicações alojadas na cloud regressa obrigatoriamente à sede para ser inspeccionado, aumentam a latência e a dependência da ligação central. Uma arquitectura SASE pode encaminhar esse tráfego pelo ponto de presença mais adequado, mantendo a inspecção de segurança próxima do utilizador.

Mas há uma condição: não basta mover políticas para a cloud. É necessário definir que tráfego deve seguir cada percurso, que aplicações exigem prioridade, onde estão os dados sensíveis e como se mantém a continuidade em caso de falha de ligação ou indisponibilidade de um serviço.

Os controlos que devem trabalhar em conjunto

A eficácia não vem da acumulação de funcionalidades. Vem da integração operacional entre controlos, identidades e processos de resposta. Numa implementação madura, quatro áreas merecem atenção particular:

• Identidade e autenticação: integração com o directório empresarial, autenticação multifactor e perfis de acesso por função. A identidade é o novo ponto de controlo, mas tem de estar bem governada.
• Acesso a aplicações: substituição progressiva de acessos VPN amplos por acesso ZTNA, limitado às aplicações e recursos necessários para cada função.
• Protecção do tráfego e dos dados: inspecção de navegação, controlo de aplicações SaaS, filtragem de conteúdo malicioso e políticas de DLP adequadas à classificação da informação.
• Visibilidade e resposta: registos centralizados, alertas úteis, correlação com endpoint e processos claros para investigar e conter incidentes.

A existência destes controlos não dispensa firewall de nova geração, protecção de endpoints, backup imutável ou segmentação interna. SASE não é uma solução milagrosa nem elimina a necessidade de segurança no datacenter. É uma camada de arquitectura que organiza o acesso distribuído e reduz pontos cegos entre rede, cloud e utilizadores.

Segurança SASE e os requisitos de NIS2

A pressão regulatória, incluindo a directiva NIS2, reforça a necessidade de demonstrar gestão de risco, controlo de acessos, continuidade e capacidade de resposta a incidentes. Embora uma plataforma SASE não garanta conformidade por si só, pode fornecer evidência operacional importante: políticas aplicadas, tentativas de acesso bloqueadas, actividade anómala, utilização de aplicações cloud e trajectos de tráfego.

O valor está na disciplina de governança activa. Quem aprova excepções? Com que periodicidade se revêm os privilégios? O que acontece quando um colaborador muda de função ou sai da empresa? Como se reage quando uma conta legítima apresenta comportamento incompatível com o seu perfil habitual? Estas perguntas têm de ter resposta em processos e não apenas em licenças adquiridas.

Para direcções financeiras e executivas, a leitura deve ser igualmente objectiva. A arquitectura pode reduzir a dispersão de ferramentas e a dependência de infra-estrutura central, mas implica custos recorrentes, trabalho de integração e uma revisão séria do modelo de acesso. O custo total de propriedade deve incluir operação, formação, migração, gestão de identidades, ligações redundantes e suporte sob SLA, não apenas o preço por utilizador.

Como implementar sem criar uma nova fonte de risco

Uma migração apressada pode interromper aplicações legadas, degradar comunicações de voz ou bloquear fluxos críticos que nunca foram devidamente documentados. Por isso, a adopção deve ser faseada e medida contra requisitos operacionais concretos.

1. Diagnóstico do tráfego, das identidades e das dependências

O primeiro passo é perceber quem acede a que aplicações, a partir de que localizações e com que dispositivos. É também o momento de identificar VPNs excessivamente permissivas, aplicações expostas à Internet, regras de firewall redundantes e dados que circulam sem classificação.

Não se trata apenas de inventariar tecnologia. Uma equipa de IT deve mapear processos críticos, períodos de maior utilização e impactos aceitáveis de indisponibilidade. Sem esta base, é impossível definir prioridades de migração ou níveis de serviço realistas.

2. Arquitectura orientada ao risco e à continuidade

A arquitectura deve separar perfis de utilizador, aplicações privadas, navegação web, tráfego entre filiais e acesso de terceiros. Um fornecedor externo, por exemplo, não deve receber as mesmas permissões de um administrador de sistemas, mesmo que ambos utilizem autenticação multifactor.

Nesta fase definem-se políticas, redundância de conectividade, integração com SIEM quando aplicável e requisitos de desempenho. Também se avalia a compatibilidade com ambientes híbridos, equipamentos de rede existentes e aplicações que dependem de protocolos antigos. Por vezes, a melhor decisão é manter temporariamente um controlo local enquanto se moderniza a aplicação que o exige.

3. Implementação controlada por grupos piloto

Começar por um grupo piloto permite validar latência, experiência de acesso, políticas de autenticação e capacidade de suporte. Os utilizadores escolhidos devem representar cenários reais: equipas remotas, comerciais, administradores, pessoal de filiais e utilizadores de aplicações intensivas.

Cada alteração deve ter critérios de sucesso e plano de reversão. A redução de chamados não é o único indicador: importa medir tentativas bloqueadas, tempos de autenticação, qualidade de ligação a aplicações críticas e cobertura efectiva dos dispositivos geridos.

4. Operação contínua e melhoria das políticas

Depois da entrada em produção, começa o trabalho que muitas organizações subestimam. Políticas de acesso envelhecem, novas aplicações SaaS aparecem sem aprovação formal e os perfis de risco alteram-se. A operação exige monitorização, revisão periódica de privilégios, tratamento de alertas e relatórios compreensíveis para IT e gestão.

É neste ponto que um parceiro com responsabilidade sobre a stack tem vantagem sobre fornecedores isolados. Na ITPOINT, o foco não é entregar uma subscrição e transferir o problema para a equipa interna. É alinhar arquitectura, implementação e operação com responsabilidades definidas, suporte próximo e SLA contratual.

O critério certo para decidir

A segurança SASE é uma decisão acertada quando a empresa precisa de proteger acesso distribuído, reduzir dependência de VPNs tradicionais, obter visibilidade sobre aplicações cloud e aplicar políticas consistentes em várias localizações. Não é necessariamente a primeira prioridade para uma organização com poucos utilizadores, aplicações exclusivamente locais e uma rede simples, desde que os controlos actuais sejam bem operados e testados.

A pergunta útil não é se a empresa precisa de SASE porque o mercado fala nisso. É se consegue controlar, auditar e manter disponível o acesso às aplicações de que depende sem criar excepções permanentes. Quando a resposta é não, vale a pena começar pelo diagnóstico: é aí que se transforma uma tendência tecnológica num plano operacional com risco, custo e resultados mensuráveis.