Security Service Edge: quatro princípios básicos para a jornada SASE

No passado discutimos sobre redes para tratar de questões de segurança, mas isso não funciona mais em um mundo onde as redes migraram para a nuvem. Para atender as demandas de segurança neste novo cenário, o Gartner criou o termo Security Service Edge (SSE) para definir um conceito importante para o entendimento da jornada rumo à arquitetura de acesso seguro de borda de serviço ou SASE.

O SSE se refere às mudanças que precisam ser feitas na stack de segurança para alcançar com sucesso uma arquitetura SASE. Dessa forma, SSE reúne as ferramentas de segurança essenciais, que são: Cloud Access Security Broker (CASB), Security Web Gateway (SWG), Firewall-as-a-Service e Zero Trust Network Access (ZTNA).

Entretanto, vale dar um passo atrás e entender o que precisa acontecer com a SSE além da discussão dos requisitos tecnológicos básicos, e examinar sua relevância para grandes iniciativas em torno das arquiteturas SASE e zero trust. SSE: como manter os dados seguros — Anos atrás, os dispositivos de inspeção de segurança mais importantes eram firewalls, web proxies locais, sistemas de informação de segurança e gerenciamento de eventos (SIEM) e ferramentas de segurança para dispositivos do usuário. Entretanto, agora, quando a quantidade de dados fora do firewall corporativo está crescendo rapidamente - e o firewall corporativo não consegue entender o tráfego na nuvem - e muitos pontos finais que se conectam tanto aos recursos e dados da web quanto aos corporativos são BYOD, os pontos de verificação legados não podem fornecer uma imagem completa do que está acontecendo com os dados.

A segurança na nuvem como questão de princípio — Para analisar como a SSE aborda o que a segurança deve fazer neste novo mundo onde é crucial manter os dados protegidos na nuvem, quatro princípios básicos devem ser seguidos:

A segurança deve seguir os dados — No momento existe muito tráfego que um proxy web ou firewall tradicional não consegue entender ou mesmo enxergar. Além disso, há usuários em todos os lugares, aplicações que estão em múltiplas nuvens, e dados que são acessados de qualquer lugar. Portanto, torna-se vital ter um ponto de inspeção de segurança que acompanhe os dados para onde quer que eles vão e que esteja hospedado na nuvem para que seus benefícios possam chegar aos usuários e aplicações.

A segurança deve ser capaz de decodificar o tráfego na nuvem — Isso significa que a segurança deve ser capaz de visualizar e interpretar o tráfego JSON (utilizado para estruturar dados em formato de texto e permitir a troca de dados entre aplicações de forma simples, leve e rápida) da API, algo que os tradicionais proxies web e firewalls não são capazes de fazer.

A segurança deve permitir uma compreensão do contexto do acesso aos dados —Existe a necessidade de ir além do simples controle de quem tem acesso à informação e avançar para controles e políticas de acessos contínuos e em tempo real que se adaptem continuamente. Esta adaptação deve ser baseada em fatores como os próprios usuários, dispositivos utilizados por eles, aplicações que acessam, atividades, instâncias das aplicações (empresarial ou pessoal), criticidade dos dados, geolocalização, horários e as ameaças presentes. Tudo isso faz parte da compreensão, em tempo real, do contexto em que eles estão tentando acessar os dados.

A segurança não pode reduzir a velocidade da rede — O usuário precisa obter seus dados rapidamente, e a rede precisa ser confiável. Se a segurança retardar o acesso ou a operabilidade, a produtividade será afetada e os funcionários começarão a negociar controles de segurança para velocidade e confiabilidade da rede. Pode-se pensar que manter a segurança rapidamente é tão simples quanto mover os controles de segurança para a nuvem, mas não é fácil assim. Por fim, a nuvem acaba percorrendo um caminho sujo chamado Internet, e isso pode causar toda uma série de problemas de roteamento e exposição. É aqui que entram as redes privadas, que podem garantir uma rota suave e eficiente de ida e volta do usuário final ao destino.

SSE permite recuperar a liderança — Devido a todas essas necessidades, o perímetro tradicional desapareceu, e é necessário deslocar o ponto de inspeção. O SSE fornece esse ponto de inspeção, ou melhor, muitos pontos de inspeção distribuídos que estão tão próximos quanto possível de onde e como os dados são acessados, seja na nuvem ou em uma aplicação privada.

Isto tem profundas implicações na forma como são projetadas a segurança e a infraestrutura e explica porque SSE e SASE são agora necessários para organizá-las. Na verdade, deve-se se avaliar dessa forma: Se 90% dos gastos com segurança estão direcionados para proteger o que está instalado em um ponto físico, mas 50% das aplicações e 90% dos usuários estão fora desse local, a segurança está sendo esticada como uma tira de borracha. Claramente, não vai funcionar uma vez que esta estratégia criará estresse para o negócio e levará a uma eventual quebra de segurança.

Vale destacar que o último princípio mencionado acima é relativo à rede. É necessário assumir que, enquanto os dados corporativos antes estavam na rede interna, e isto era seguro, agora, muitos dados e usuários estão fora desta rede, então é necessário que se vá além dela. Isto não evita a necessidade de segurança da rede, nem marginaliza a importância de processos como o controle de acesso. Isso significa, entretanto, que alguns limites estão começando a se distorcer e tem que ser levados em consideração.

Com SSE, os pontos de inspeção da Internet estão operacionais, as capacidades de inspeção de nuvem, web e dados estão consolidadas e o mais importante, são acionadas todas ao mesmo tempo, garantindo a segurança da rede contra possíveis invasões.

. Por: Jason Clark, Chief Security Officer & Chief Strategy Officer, Netskope.

Enviar Imprimir