SASE: o que é e como se compara a SSE, CASB e DLP

O diretor financeiro abre o notebook no aeroporto, conecta no Wi-Fi do saguão e acessa o ERP, que roda na nuvem. Para chegar lá, o tráfego dele faz uma volta: sai do aeroporto, entra pela VPN no data center da matriz, passa pelo firewall e só então segue para a internet, onde o ERP está.

Essa volta fazia sentido quando o ERP morava no data center. Hoje o sistema está na nuvem, o e-mail também, e metade da equipe trabalha de casa. O firewall da matriz virou um pedágio no meio do caminho de quem nem está na matriz.

SASE é o nome que o mercado deu à arquitetura que tira esse pedágio do caminho.

SASE muda o lugar onde a segurança acontece, do data center para perto de quem acessa. A sigla não resolve a parte difícil: decidir quais dados e quais acessos importam.

De onde veio o termo SASE

O Gartner cunhou a sigla em 2019, e o próprio NIST registra essa origem no guia SP 800-215, de novembro de 2022. Os relatórios daquele ano tratavam da convergência entre rede de longa distância (WAN) e segurança. Um deles, listado no verbete da Wikipédia sobre SASE, tem um título que resume a tese: "The Future of Network Security Is in the Cloud".

Durante anos, a empresa tinha um perímetro: a rede interna, protegida por um firewall na borda. Quem estava dentro era confiável, quem estava fora passava pela VPN para entrar. Os sistemas moravam dentro, então fazia sentido inspecionar tudo na porta.

Esse desenho perdeu o centro de gravidade quando dois movimentos se somaram. As aplicações foram para SaaS e nuvem pública, e as pessoas foram para casa, para a filial e para o celular. O tráfego passou a nascer fora do perímetro e terminar fora dele. Mandar tudo de volta para a matriz só para inspecionar ficou caro e deixou o acesso lento.

No SASE, a inspeção roda numa rede de pontos de presença do provedor, espalhados geograficamente. O usuário se conecta ao ponto mais próximo, e ali acontece o que antes acontecia no firewall da matriz.

O que tem dentro do SASE

O SASE junta dois blocos que antes eram comprados e operados separadamente.

O primeiro bloco é de rede. O SD-WAN decide por qual link cada filial manda o tráfego, escolhe o caminho mais barato ou mais estável e substitui boa parte dos circuitos dedicados que ligavam filial e matriz.

O segundo bloco é de segurança, e reúne quatro funções principais:

• SWG (gateway web seguro): filtra a navegação, bloqueia site malicioso e inspeciona download.
• CASB: enxerga e controla o uso de apps na nuvem, inclusive os que a TI não aprovou. O post sobre o que é CASB detalha os modos de operação.
• ZTNA (acesso de rede zero trust): libera uma aplicação específica para um usuário específico, sem abrir a rede inteira.
• Firewall como serviço: as regras de firewall que antes ficavam num equipamento na borda, agora executadas na nuvem do provedor.

O NIST SP 800-215 lista como serviços mínimos da maioria das ofertas comerciais de SASE o firewall, o gateway web, o antimalware, o IPS, o CASB e o DLP. Juntar essas funções permite administrar tudo com uma política e um console, em vez de manter vários equipamentos com regras que divergem com o tempo.

SSE: a metade de segurança do SASE

Por volta de 2021, segundo o mesmo verbete da Wikipédia, o Gartner separou a parte de segurança e deu outro nome a ela: SSE, Security Service Edge. Na definição de mercado do Gartner, o SSE protege o acesso à web, aos serviços de nuvem e às aplicações privadas, onde quer que estejam o usuário, o aparelho e a aplicação. Em siglas, isso é SWG, CASB e ZTNA, com proteção de dado em linha e por API. O firewall como serviço aparece em parte das ofertas de SSE, e no SASE ele é obrigatório, junto com o SD-WAN.

A separação tem um motivo prático. Muitas empresas já tinham contrato de rede com uma operadora, ou já tinham trocado os circuitos por SD-WAN, e não queriam mexer nisso. O que faltava para elas era a camada de segurança na nuvem. Comprar SSE resolve essa parte sem obrigar a trocar a rede.

Para quem está avaliando, a pergunta útil é qual metade falta. Uma empresa sem filial, com todo mundo remoto, quase não tem o que fazer com SD-WAN. Para ela, SSE é o projeto inteiro. Uma rede de lojas com cem pontos de venda pode ter a dor principal na rede, e a segurança vem junto.

Onde o DLP entra

O DLP roda dentro da camada de inspeção do SSE. Quando o tráfego passa pelo ponto de presença, a mesma etapa que confere o destino e procura malware também olha o conteúdo: um arquivo com lista de clientes subindo para um drive pessoal, uma planilha com CPF colada num formulário externo.

Isso muda onde o DLP de rede fica, e muda pouco no resto. A ferramenta ainda precisa saber o que é sensível. Os tipos de DLP, o modo monitorar antes de bloquear e a ligação com a LGPD estão explicados no post sobre o que é DLP, e valem do mesmo jeito dentro de uma plataforma SASE.

O ganho está na visibilidade. Como todo o tráfego passa pelo mesmo ponto, o DLP enxerga também o que sai de casa e da filial, e não só o que sai da matriz.

DLP, CASB, SSE e SASE lado a lado

As quatro siglas aparecem juntas em proposta comercial e confundem quem compra. Elas estão em níveis diferentes: duas são funções, duas são pacotes.

O SSE inclui as funções de CASB e de DLP de rede, e o SASE inclui o SSE. O DLP de endpoint fica fora dos dois, instalado no próprio aparelho.

ZTNA x VPN: o que muda no acesso remoto

A VPN tradicional coloca o aparelho do usuário dentro da rede. Depois de conectado, ele enxerga tudo o que a rede deixa enxergar, e um notebook comprometido vira um ponto de entrada com acesso amplo. O post sobre quando a VPN ainda faz sentido cobre os casos em que ela segue sendo a escolha certa.

O ZTNA inverte a lógica. O usuário pede uma aplicação, o serviço confere quem ele é, de qual aparelho está vindo e se esse aparelho está em ordem, e libera só aquela aplicação. O resto da rede continua invisível para ele.

Esse é o princípio do Zero Trust. A publicação NIST SP 800-207, de agosto de 2020, diz que a arquitetura "assumes there is no implicit trust granted to assets or user accounts" com base em localização de rede. O SASE leva essa ideia para a infraestrutura: o ponto de presença é onde a confiança é conferida a cada acesso.

O ZTNA depende de identidade bem feita. Se o login não tem MFA e as contas de ex-funcionários continuam ativas, o ZTNA vai liberar a aplicação certa para a pessoa errada com toda a precisão.

Quando a sua empresa não precisa de SASE

O SASE resolve um problema de distribuição: muita gente, em muitos lugares, acessando muitas aplicações. Sem essa distribuição, o projeto custa mais do que entrega.

Ainda não é a hora quando a empresa tem um escritório só, ou nenhum. Ela usa três ou quatro apps na nuvem, todos com login único, e não tem aplicação interna que precise ser publicada para quem está fora. Nesse caso, configurar bem o SSO, exigir MFA, revisar quem tem acesso a quê e usar os controles que o próprio provedor de e-mail e de arquivos já oferece cobre a maior parte do risco.

O quadro muda quando aparecem as filiais, quando o número de apps SaaS passa de algumas dezenas ou quando a área de TI descobre que não sabe quais serviços a equipe usa. Esse último sinal tem nome, shadow IT, e costuma ser o que puxa a conversa sobre CASB e, depois, sobre SASE.

Como avaliar se a empresa está pronta para SASE

Antes de pedir proposta, vale responder estas perguntas por escrito. Elas mostram qual metade do SASE você precisa e o que vai travar o projeto.

1. Mapeie de onde as pessoas acessam. Escritório, casa, filial, cliente, celular. Se quase todo o acesso vem de um lugar só, o ganho do SASE é pequeno.
2. Liste as aplicações e onde cada uma mora. SaaS, nuvem pública, data center próprio. Aplicação interna exposta por VPN é candidata direta a ZTNA.
3. Confira a identidade antes de tudo. Login único, MFA para todos e desligamento de conta no mesmo dia da demissão. Sem isso, o SASE inspeciona o tráfego de uma identidade em que você não confia.
4. Defina quais dados importam. Sem classificação mínima (o que é público, interno e restrito), a camada de DLP vai gerar alerta demais ou não vai bloquear nada.
5. Separe rede de segurança no orçamento. Se o contrato de rede vence daqui a dois anos, comece pelo SSE e deixe o SD-WAN para depois.
6. Planeje a convivência com a VPN. Migre por aplicação, começando pelas de menor risco, e desligue a VPN só quando a última aplicação tiver saído dela.
7. Decida quem lê os registros. Um console único só ajuda se alguém olha os alertas toda semana e tem autonomia para mudar a política.

O que a sigla não decide

SASE é uma decisão de arquitetura sobre onde inspecionar o tráfego. Ele acaba com a volta do diretor financeiro pelo data center e dá visibilidade sobre o que sai de casa e da filial.

Quem pode acessar o ERP, quais planilhas são confidenciais e quais apps a equipe pode usar continuam sendo decisões da empresa. O ponto de presença aplica a cada acesso as regras que saem dessas listas, e sem elas a plataforma inspeciona o tráfego sem saber o que proteger.