Voltar 
A segurança cibernética tem uma má reputação por atrapalhar os negócios. Muitos CIOs e CISOs dedicam grande parte de seu tempo para minimizar o impacto das soluções de segurança no tráfego, ao mesmo tempo em que garantem que elas continuem a fazer seu trabalho e mantenham a rede segura. Com a mudança dos dados e aplicações para a nuvem, esse desafio só aumenta.
Até alguns anos atrás, a equipe de segurança implantava os serviços de segurança em uma série de appliances físicos. Firewall, filtragem de URL, monitoramento de e-mails, verificação de ameaças e funções de prevenção de perda de dados (DLP) podiam rodar cada um em sua própria caixa, por exemplo. Os cinco appliances eram configurados em série, de modo que um pacote de dados fluía para um deles, o appliance executava seu serviço padrão e, em seguida, o pacote seguia para o próximo appliance, que novamente aplicava todas as etapas padrão. A escalabilidade de cada serviço era limitada pelo espaço disponível em seu appliance físico. E quando o hardware estava esgotado, o desempenho das verificações de segurança—e, por extensão, o desempenho do tráfego de rede—ficavam mais lentos. Esses desafios se acentuaram ainda mais com fluxos de tráfego criptografados e a necessidade de descriptografar, verificar e recriptografar o tráfego várias vezes, para cada função.
Muitos clientes tentaram melhorar a escalabilidade mudando para appliances virtuais, mas acabaram encontrando o mesmo problema de “gargalo.” Esteja uma solução rodando na nuvem ou on-premises, a virtualização requer que os administradores atribuam recursos específicos, incluindo CPU, memória e espaço em disco. Algumas plataformas de segurança consolidam uma gama de serviços diferentes. Isso dá ao conjunto de soluções acesso a mais recursos agregados, mas os serviços precisam competir por aquela quantidade finita disponível e, em última análise, o desempenho não é otimizado para nenhum deles. Inerente ao design, este “cabo de guerra” por recursos acaba por forçar uma troca entre o processamento de segurança e o desempenho.
Seja qual for a estratégia, as abordagens físicas, virtuais ou baseadas em cloud normalmente têm apenas um certo espaço para escalar horizontalmente. Depois desse ponto, as limitações de recursos introduzem latência no desempenho das soluções que abrigam. Uma infraestrutura de segurança operando por meio de um pipeline de tráfego com um diâmetro fixo acabará atingindo essas limitações e gargalos. Em última instância, a velocidade da rede sofrerá resultando em uma experiência desagradável para o usuário e, no pior caso possível, correrá o risco de usuários contornarem completamente os controles de segurança, expondo a organização a riscos.
Microsserviços acoplados, mas independentes
À medida que a Netskope dfoi desenvolvendo sua plataforma pronta para SASE (Secure Access Service Edge), projetamos uma arquitetura com o objetivo de superar a latência que degrada o desempenho das soluções de segurança tradicionais. Para atingir esse objetivo, repensamos dois aspectos de como a tecnologia de segurança opera fundamentalmente.
Primeiro, consolidamos os principais recursos de segurança em uma única plataforma unificada, ao mesmo tempo, separamos as funções de segurança individuais no que chamamos na Netskope de “microsserviços”. Processos como prevenção contra perda de dados (DLP), proteção contra ameaças, filtragem de conteúdo da web e Zero Trust Network Access (ZTNA) são executados de forma independente, cada um com seus próprios recursos. Quando as limitações de recursos começam a impactar o desempenho de um dos microsserviços, a Netskope Security Cloud é projetada para aumentar (ou reduzir) automaticamente esse microsserviço, liberando independentemente os recursos necessários.
Por exemplo, é mais provável que a interceptação SSL seja limitada pela entrada-saída (E/S) do sistema, tentando descriptografar o tráfego recebido da rede. Embora a configuração de sessão TLS / SSL seja normalmente limitada para operações de chave assimétrica pela unidade de processamento central (CPU), uma vez que uma sessão é estabelecida, as funções de criptografia e descriptografia simétricas não são mais vinculadas à CPU, pois a maioria das CPUs modernas têm instruções AES nativas. Consequentemente, durante a fase real de transferência de dados, o gargalo se move para o quão rápido os pacotes podem entrar e sair do sistema (E/S, não CPU), com cada cópia de pacote adicionando sobrecarga que aumenta a latência do processamento geral. Por outro lado, o DLP tende a ser mais limitado pela CPU porque seu objetivo é abrir arquivos suspeitos usando tecnologias de processamento intensivo, como vários mecanismos comuns de expressão. Se o desempenho do DLP é restringido pelas limitações da CPU, o design da Netskope aumenta rapidamente a potência do processador especificamente para esse microsserviço, em vez de aumentar a potência da CPU em toda a placa fazendo todos os serviços de segurança competirem.
Isso pode soar um pouco como no passado, em que cada solução de segurança rodava em seu próprio hardware, mas não é. Na verdade, é uma simplificação e abstração drástica por meio da miríade de microsserviços Netskope. Isso leva ao segundo aspecto notável da nossa arquitetura, que é como os microsserviços individuais são independentes, mas permanecem fortemente acoplados. Embora utilizem recursos independentemente, como E/S ou CPU, eles compartilham os resultados de certos processos para que as mesmas cargas de trabalho não sejam desnecessariamente repetidas em vários microsserviços que analisam os mesmos pacotes. Isso oferece eficiência significativa para a forma como a Netskope é capaz de processar grandes volumes de tráfego, vinculando melhor o "contexto" dos resultados de segurança e, por fim, acelerando o desempenho e reduzindo a latência.
Processamento de tráfego mais rápido e segurança mais eficaz
Qualquer produto ou serviço de segurança vai apresentar alguma latência e isso é um fato. Cada solução que atinge um pacote de dados em movimento, com base nas leis da física, fica mais lenta; no entanto, a arquitetura de passagem única da Netskope foi projetada para minimizar a latência de ponta a ponta. Ela consegue isso separando o "conteúdo" dos metadados e realizando atividades repetitivas apenas uma vez, para aproveitar melhor os resultados em cada microsserviço que utiliza essas atividades. Não vou cobrir isso em detalhes neste blog, mas as otimizações da nuvem privada de segurança Netskope, chamada NewEdge, reduzem ainda mais a latência para a melhor experiência possível dos usuários e aplicações. Isso inclui decisões tomadas nos racks integrados que construímos para implementação em nossos data centers, no controle de todo o roteamento de tráfego e dos locais, no peering extensivo com provedores de web, nuvem e SaaS (em todos os data centers), bem como sobre-provisionando massivamente em cada data center e executando a infraestrutura com baixa utilização (e espaço máximo) para acomodar picos de tráfego incomuns ou a adoção por mais clientes.
Voltando ao assunto das atividades repetidas realizadas na Netskope Security Cloud, vamos considerar a “descriptografia” como um exemplo. Cerca de 90% do tráfego que a Netskope lida hoje em dia é criptografado. Embora nossos microsserviços de segurança executem operações diferentes no tráfego depois que ele foi descriptografado, todos eles exigem que o pacote seja