Coautoria de Jeff Brainard e Jason Hofmann
Em mais de uma conversa com clientes de grandes empresas, ouvimos líderes de rede e infraestrutura responsáveis por gerenciar a WAN global de uma organização brincando e referindo-se a si mesmos como “Chief Hairpinning Officer” ou CHO (algo como “Diretor de Grampos de Cabelo”). A primeiro momento, isso é engraçado. No entanto, há mais do que um pouco de verdade nesta afirmação se considerarmos quanto tempo, energia e orçamento os profissionais de redes têm gastado regularmente no gerenciamento de decisões complexas de roteamento. Essas decisões foram fundamentais para unir diferentes sites corporativos e filiais ao data center e, ao mesmo tempo, trabalhar com vários provedores de Internet, a fim de garantir acesso rápido e confiável para seus usuários, além de uma experiência responsiva com as aplicações. Mas a tarefa árdua dos últimos anos foi alinhar esses objetivos de redes com os crescentes requisitos de segurança que as empresas enfrentam. O problema só se agravou com a migração de aplicações e dados para a nuvem e para SaaS, com ataques cada vez mais complexos, combinados com a explosão mais recente no trabalho remoto.
Hoje em dia, a maioria das empresas utiliza uma arquitetura que depende fortemente do “hairpinning”, também muito conhecida como backhaul do tráfego. O “hairpinning”, em um contexto de rede, é o método em que um pacote de dados sai de uma interface e vai em direção à internet, mas em vez de continuar, faz uma "curva fechada" e volta para a mesma interface.Para facilitar o entendimento, basta pensar em um grampo usado para segurar o cabelo de uma pessoa O cenário clássico é a filial, onde nenhum tráfego deve entrar ou sair sem primeiro ter a segurança verificada. A implementação de uma stack de segurança autônoma em cada filial, em dezenas ou até centenas de filiais em todo o mundo, pode ser uma estratégia viável, mas do ponto de vista de custo, complexidade e carga administrativa, seria um pesadelo.
Em vez disso, a abordagem preferida tem sido desviar todas os requests de Internet das filiais (usando um “hairpinning”) para um local central, como o data center, onde está a aplicação de segurança, e só então, após ser verificado, enviar o tráfego para a internet. E isso acontece tanto ao fazer um request de conteúdo da web ou ao interagir com uma aplicação SaaS crítica para os negócios. Na resposta do servidor, o tráfego precisa seguir o mesmo caminho tortuoso de volta do data center à filial e, finalmente, ao desktop do usuário. Não é necessário ser um engenheiro de rede para perceber que essa abordagem afetará a experiência do usuário, adicionando latência e tornando as coisas significativamente mais lentas. Colocando de lado a experiência do usuário e, em última instância, a produtividade da empresa, essa abordagem também sobrecarrega links WAN privados que são caros e difíceis de manter, como as conexões MPLS, nas quais as empresas confiam há muito tempo para unir sua infraestrutura distribuída.
Com a mudança indiscutível de aplicações e dados para a nuvem e o crescente volume e criticidade desse tráfego, uma das grandes vantagens do modelo de segurança em cloud é eliminar a distorção e simplificar drasticamente o design da rede. É também um dos principais motivadores para o mercado de SD-WAN em expansão e o ímpeto para projetos de transformação de rede em grande escala. Este tema foi abordado em outro blog post recente chamado “Como o Netskope NewEdge leva o SD-WAN a um nível superior.” A conclusão que se pode tirar é que os profissionais de redes preferem evitar a prática do “hairpinning” e que no futuro o tráfego será cada vez mais enviado direto para a rede, com uma abordagem de segurança que prioriza a nuvem. Então, por que um cliente selecionaria uma solução de segurança em nuvem que ainda se baseia em uma arquitetura complexa?
Infelizmente, uma das coisas que vimos repetidamente no mercado, e é comum com quase todos os fornecedores de segurança em nuvem, é que eles arquitetaram suas nuvens de maneira totalmente errada. Essencialmente, o que você descobre é que eles estão repetindo os erros inerentes ao design tradicional da WAN corporativa e replicando-os dentro do cloud form fator. Um exemplo disso é o ponto de presença virtual (ou vPOP), uma abordagem conhecida por ser usada por fornecedores como Broadcom / Symantec, Palo Alto, Forcepoint, McAfee e outros. Para verificar esta informação, confira o site dessas empresas e procure frases como "Localização física do cálculo de segurança" ou o termo "vPOP.") Os vPOPs não apenas fornecem uma visão enganosa da cobertura, mas também enganam sobre onde o processamento de tráfego ocorre dentro da rede do fornecedor de segurança na nuvem.
De forma mais simples, os vPOPs fornecem um ponto de entrada e saída para o tráfego. Um exemplo disso, discutido em um blog anterior chamado “Compreender a cobertura não se trata apenas de contar data centers,” apresentou um cenário com um suposto usuário remoto no Quênia. Esse usuário precisaria se conectar a um vPOP em Joanesburgo, na África do Sul, ter seu tráfego enviado para processamento em Frankfurt, na Alemanha, e em seguida, ser mandado de volta para Joanesburgo – isso antes que a solicitação do usuário fosse para a Internet e para a web, nuvem ou para a aplicação SaaS que ele estava tentando acessar. Imagine a latência introduzida com esse vai e vem de tráfego, roteando por grandes distâncias, por várias redes, em última instância, retardando a experiência do usuário até ela virar um “rastejar.” O segredo é que os vPOPs são literalmente redutores de tráfego com as mesmas implicações na complexidade, latência e custo em potencial.
Além disso, quando os fornecedores dependem da infraestrutura de uma nuvem pública, como AWS, Azure ou GCP, eles contam com os data centers de borda desses provedores para fornecer pontos de saída regionais para o tráfego (Palo Alto). Ou pior ainda, e muito mais comum: eles fazem backhaul sobre a congestionada e imprevisível Internet pública e usam um "banco telefônico" de IPs de saída, cada um registrado em um país diferente, para implementar seus vPOPs. O mesmo problema acontece novamente, com o tráfego tendo que ser direcionado por grandes distâncias, desviado para vários locais antes de eventualmente chegar aos poucos—muitas vezes menos de 30—locais únicos no mundo onde os recursos de computação estão localizados e onde o processamento de segurança no tráfego pode ocorrer. Os clientes pensam que estão comprando uma estratégia de nuvem para ir direto para a rede, com as proteções críticas de segurança de que precisam, mas o que estão obtendo na verdade são os mesmos problemas de rede do passado reimplementados dentro da nuvem. Este é o segredo oculto da maioria dos fornecedores de segurança em nuvem.
Outro exemplo de pesadelo na rede de um conhecido fornecedor de segurança na nuvem apareceu recentemente com um cliente com quem estávamos trabalhando na América Latina. Embora o fornecedor anunciasse quatro data centers na região, na verdade ele tinha três vPOPs e uma nuvem pública (ou seja, eram vPOPs no Chile, na Argentina e na Colômbia, e VMs rodando na Google Cloud Platform no Brasil). Enquanto os usuários no Brasil eram atendidos pelo GCP Brasil, todos os outros países da região eram atendidos pelos Estados Unidos. Dessa forma, o tráfego de LATAM tinha que voltar aos Estados Unidos para processamento e aplicação da política de segurança. Não apenas a abordagem deste fornecedor enganou tremendamente em termos de cobertura (parece que eles tinham apenas um data center para LATAM, e não quatro!), mas essa abordagem “dependente de curvas” também introduziu centenas de milissegundos de latência. Piorando a situação, o cliente ainda viu uma diminuição geral do throughput devido a essa alta latência (porque o throughput é inversamente proporcional à latência com TCP), aumentando as taxas de erro e perda de pacotes e diminuindo a confiabilidade geral. Até falar com a Netskope e aprender sobre como projetamos o NewEdge, este cliente estava em cima do muro sobre a adoção da segurança na nuvem e estava perto de dobrar seus dispositivos físicos existentes e a arquitetura WAN com MPLS.
Muitos fornecedores afirmam que os vPOPs são a única maneira de fornecer uma experiência de usuário perfeita para que, por exemplo, os usuários obtenham seus resultados de pesquisa do Google ou anúncios localizados de forma adequada para sua localização ou região específica. A realidade é que qualquer fornecedor que conta com a nuvem pública, em vez de seus próprios data centers para fornecer um serviço de segurança em nuvem, está limitado às cidades e regiões em que seu fornecedor de nuvem oferece serviços de computação (VMs, ou máquinas virtuais), então eles não têm escolha a não ser desviar o tráfego e usar vPOPs para tentar reduzir as chances de que o backhaul não resulte em localização de conteúdo, bloqueio geográfico ou outros problemas resultantes do roteamento para uma região distante.
Já conversamos sobre esse assunto em outros posts do blog, mas a abordagem que a Netskope adotou com o NewEdge é realmente diferente e é por isso que investimos mais de US$ 100 milhões para construir a nuvem privada de segurança de mais alto desempenho do mundo. A NewEdge adota um modelo direto para a rede a fim de agilizar o caminho do tráfego e focar na simplificação da rede, ao mesmo tempo em que obtém confiabilidade e resiliência superiores. Não dependemos de vPOPs ou da nuvem pública, portanto, nosso desempenho é melhor e mais previsível. E cada um de nossos data centers é totalmente computacional, com todos os serviços Netskope Security Cloud disponíveis. Tudo isso garante o acesso mais rápido e com menor latência para os usuários, seja em um café em Milão, em uma filial em Hong Kong ou na sede da empresa em Nova York. Além disso, a natureza altamente conectada da NewEdge, com extenso peering com os provedores de web, nuvem e SaaS com os quais os clientes mais se preocupam, oferece uma vantagem real à NewEdge e aos clientes da Netskope. É hora dos clientes conhecerem o segredo oculto nas redes da maioria dos fornecedores de segurança em nuvem, para garantir que sua seleção de serviços de segurança em cloud não repita os erros do passado, como o uso do “hairpinning.”
Para saber mais sobre Netskope e NewEdge, visite: https://www.netskope.com/platform/newedge
