Hairpinning: o segredinho sujo da maioria dos fornecedores de segurança na nuvem

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. 

What is hairpinning?

Most enterprises today leverage an architecture that relies heavily on “hairpinning” or what’s also commonly referred to as traffic backhauling. In a networking context, hairpinning refers to the way a packet travels to an interface, goes out towards the internet but instead of continuing on, makes a “hairpin turn”—just think of the everyday instrument used to hold a person’s hair in place—and comes back in on the same interface. The classic scenario is the branch office, where no traffic should enter or exit without first getting security checked. Deploying a standalone security stack at every branch, across dozens or even hundreds of branch locations around the world, could be a viable strategy but from a cost, complexity, and administrative burden perspective it would be a nightmare. 

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.

The evolution of hairpinning to WAN/SD-WAN

With the unarguable shift of applications and data to the cloud, and the growing volume and criticality of this traffic, one of the great attractions of the cloud security model is to eliminate hairpinning and dramatically simplify network design. It’s also one of the key drivers for the booming SD-WAN market and the impetus for large-scale network transformation projects. This was covered in another recent blog titled “How Netskope NewEdge Takes SD-WAN to the Next Level.” The conclusion one can draw is that networking professionals would prefer to avoid hairpinning and the future will increasingly be about sending their traffic direct-to-net with a cloud-first approach to security. So why then would a customer select a cloud security solution that relies on a hairpinning network architecture?

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. 

The power of NewEdge

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 a Netskope e a NewEdge, visite: https://www.netskope.com/netskope-one/newedge