Segurança de rede não é segurança de carga de trabalho

Violações, hacks, sequestros, perda de dados e exfiltração são problemas que existem na maioria das arquiteturas de nuvem por um motivo muito simples: a maioria das tecnologias de TI não foi originalmente projetada com a segurança como prioridade. As complexidades relacionadas ao desenvolvimento de aplicativos, sistemas operacionais de carga de trabalho, protocolos de rede e gerenciamento geral de processos foram todas projetadas com diferentes prioridades em mente: funcionalidade e resiliência. Todas essas tarefas precisam funcionar e sobreviver a falhas de elementos na arquitetura geral, mas assegurando esses elementos geralmente foram uma reflexão tardia.

Como a rede é a infraestrutura crítica na arquitetura geral, parece fazer sentido aplicar soluções de segurança e microssegmentação nela.

Independentemente de como os aplicativos são desenvolvidos, de como diferentes sistemas operacionais são criados e implantados e de como tudo isso é virtualizado, abstraído e gerenciado, a maioria desses elementos precisa se comunicar entre si. Se não houver rede, cada aplicativo é uma ilha. E a maioria dos aplicativos atuais é projetada para ser acessada por clientes remotos, por meio de uma rede privada ou pela Internet. Isso é necessário em qualquer tipo de arquitetura de nuvem, e qualquer arquitetura nativa de nuvem simplesmente não funcionará sem uma rede já existente para se comunicar por meio dela. Então, pode-se argumentar que o elemento mais crítico de qualquer arquitetura geral de nuvem é, na verdade, a própria rede.

Devido à natureza crítica da infraestrutura de rede em qualquer arquitetura de nuvem, existem desafios e prioridades que são específicos apenas para a camada de rede de todas as arquiteturas. A rede tem preocupações que são completamente independentes de cargas de trabalho e aplicativos, que dependem da rede. Alguns exemplos dessas preocupações com a rede incluem:

• Confiabilidade (a rede precisa funcionar)
• Resiliência (a falha de um ou mais dispositivos de rede não deve causar uma falha em todo o sistema)
• Engenharia de tráfego e qualidade de serviço (as redes IP são, por design, “sem conexão”, mas deve haver maneiras de projetar e priorizar diferentes tipos de tráfego)
• Escalabilidade (as redes devem ser capazes de evoluir sem atingir o limite de recursos)

Os aplicativos e as cargas de trabalho não precisam estar cientes de nenhum desses detalhes para que possam usar a rede.

Então, o que isso significa para proteger a rede e proteger as cargas de trabalho? Há considerações distintas que vou explorar, especificamente o contraste entre segurança de rede e soluções baseadas em rede, segurança de carga de trabalho e soluções como microssegmentação.

Uma breve história da segurança de rede

Como a segurança é sempre a última a chegar à maioria das arquiteturas de nuvem, segurança e segmentação de rede têm sido tradicionalmente implementados na camada de rede. Como a rede é a infraestrutura crítica na arquitetura geral, parece fazer sentido aplicar soluções de segurança e microssegmentação nela.

Se você reverter o tempo várias décadas, a segurança em redes IP originalmente assumia a forma de listas de controle de acesso (“ACLs”) em roteadores e switches. Os dispositivos de rede geralmente lidam com o tráfego por pacote; portanto, quando os pacotes chegam a um roteador ou switch, essas ACLs são verificadas para tomar decisões sobre permitir ou bloquear o encaminhamento de um pacote.

Essa abordagem foi então terceirizada para dispositivos de rede dedicados — firewalls — que originalmente usavam a mesma abordagem básica. Como todos os pacotes IP contêm informações em seus cabeçalhos que indicam sua origem e destino, além dos números TCP ou UDP que indicam que tipo de dados está presente na carga útil de dados do pacote, um firewall usa essas informações para tomar decisões de encaminhamento com base em suas próprias listas de controle de acesso. Como a rede lida com pacotes, fazia sentido deixar a rede lidar também com segurança e microssegmentação, liberando as equipes de desenvolvimento de aplicativos e sistemas para se concentrarem em outras questões.

No entanto, geralmente é fácil enganar um firewall baseado em pacotes. Não é muito difícil “falsificar” endereços e números de portas TCP/UDP em um pacote IP, o que resulta em um pacote que pode facilmente mascarar o que está contido em sua carga de dados. Portanto, os firewalls baseados em sessão evoluíram para se concentrar no mapeamento de todos os pacotes em um determinado fluxo para uma sessão exclusiva e para monitorar o comportamento dessa sessão com base no aplicativo ao qual eles “acham” que estão associados. Esses firewalls não tinham visibilidade total de cada pacote, mas comparavam o comportamento desses pacotes e sessões com os comportamentos básicos do aplicativo, procurando anomalias.

Posteriormente, surgiram os chamados firewalls de “próxima geração”, que aplicam muito mais inteligência para identificar o que está contido em um pacote, a qual aplicativo ele está associado, a qual usuário está associado e outros detalhes que indicam uma violação de segurança. Mas todos esses detalhes estão ocorrendo em linha na rede, não nas próprias cargas de trabalho de origem ou destino. Os firewalls não têm ideia do que está acontecendo nas cargas de trabalho que estão enviando e recebendo esses pacotes, a menos que estejam se comunicando de alguma forma com alguma ferramenta central que também monitora cargas de trabalho e aplicativos e, em seguida, direciona o tráfego selecionado para o firewall. Mas isso pode ser complexo de implantar, então os firewalls geralmente ficam simplesmente na rede, esperando que os pacotes cheguem.

A segurança da rede é diferente da segurança da carga de trabalho

Paralelamente aos firewalls que tomam decisões sobre quais pacotes podem ou não ser encaminhados, roteadores e switches têm suas próprias preocupações de segurança, que são resultado do mesmo problema básico: a segurança não era a principal preocupação quando os protocolos de rede foram originalmente projetados.

Os protocolos TCP/IP e de roteamento dinâmico usados para encaminhar pacotes, como BGP e OSPF, foram projetados com os mesmos objetivos básicos dos aplicativos e das cargas de trabalho: funcionalidade e resiliência. A segurança não era uma prioridade no início da rede. A segurança e a microssegmentação se tornaram uma prioridade em um estágio posterior da evolução da rede, e as soluções de segurança de rede têm sido usadas para tratar de questões de segurança específicas da rede. A segurança não é apenas uma preocupação com cargas de trabalho e aplicativos. Há questões de segurança na rede que as cargas de trabalho e os aplicativos não têm visibilidade.

Como lembrete, esses são apenas alguns exemplos de desafios de segurança que existem na camada de rede de qualquer arquitetura de nuvem:

• Engenharia de tráfego
• Negação de serviço (DoS)
• Falsificação de ARP
• Autenticação BGP
• Redirecionamento de tráfego
• Ataques do tipo man-in-the-middle
• Propagação de rota falsa
• Sequestro de roteador de primeiro salto
• Sequestro de cookies de sessão

Os itens desta pequena lista são todos questões de segurança específicas para redes, não para cargas de trabalho ou aplicativos. Por exemplo, os desafios da engenharia de tráfego são abordados por tecnologias como o MPLS e pela confiabilidade dos protocolos de distribuição de etiquetas. A negação de serviço é um problema significativo que geralmente é resolvido por meio do uso de comunidades BGP trocadas com colegas de roteamento do ISP. A falsificação de ARP é um problema no qual os roteadores alteram seus mapeamentos entre os endereços da camada 3 e da camada 2, fazendo com que o destino do tráfego seja sequestrado. A autenticação BGP exige algo como RPKI para criptografar as informações trocadas entre pares do BGP, a fim de evitar problemas de roteamento pela Internet. E assim por diante. A rede tem seu próprio vocabulário especializado para lidar com problemas de segurança que são exclusivos da camada de rede de qualquer arquitetura de nuvem.

Esses exemplos são apenas algumas das principais preocupações de segurança das arquiteturas de rede, não das arquiteturas de carga de trabalho ou de aplicativos. As equipes de desenvolvimento de aplicativos e sistemas geralmente não têm visibilidade dessas questões de segurança de rede, porque não deveriam precisar. Quando o sistema operacional de uma carga de trabalho usa iptables, por exemplo, para enviar ou receber um pacote, ela não precisa saber se o BGP está de alguma forma sendo sequestrado entre ISPs na rede em algum lugar. As cargas de trabalho e os aplicativos estão preocupados com a segurança da carga de trabalho e dos aplicativos, não com a segurança da rede.

As soluções de segurança de rede não são soluções de segurança de carga de trabalho

O que isso significa é que ferramentas projetadas para lidar com os desafios de segurança de rede geralmente não são as ferramentas apropriadas para lidar com os desafios de segurança e microssegmentação em cargas de trabalho ou aplicativos. A segurança da carga de trabalho geralmente não precisa ser limitada pela escala: a implantação de milhares de cargas de trabalho em várias nuvens não deve depender de nenhuma ferramenta de camada de rede para, de alguma forma, oferecer segurança em nível de aplicativo a essas cargas de trabalho.

As cargas de trabalho geralmente migram ao vivo através dos limites da camada 3 ou entre nuvens, e as cargas de trabalho não devem depender de ferramentas da camada de rede que, de alguma forma, rastreiem essas migrações para impor segurança da carga de trabalho e microssegmentação. Os aplicativos dependem de dependências entre cargas de trabalho, e essas dependências geralmente não são visíveis para as ferramentas da camada de rede, portanto, definir uma barreira em torno dos aplicativos não deve ser limitada pela falta de visibilidade da rede sobre as dependências completas dos aplicativos.

Alguns fornecedores de rede proporão suas soluções de SDN como soluções para requisitos de microssegmentação e segurança de cargas de trabalho e aplicativos. Mas essas ferramentas residem nas camadas de rede ou hipervisor, e essas ferramentas foram projetadas para abordar as prioridades nessas camadas: como automação, virtualização, análise de rede, sobreposições e tunelamento de rede e autenticação entre protocolos de roteamento dinâmico. As ferramentas de SDN não foram projetadas para fornecer segurança e microssegmentação para cargas de trabalho e aplicativos em grande escala.

Eles também podem propor firewalls — sejam de hardware ou instâncias virtualizadas em um hipervisor — como soluções para os requisitos de segurança da carga de trabalho e dos aplicativos, argumentando que os firewalls de próxima geração fornecem visibilidade total da camada 7 do tráfego da rede. No entanto, qualquer firewall só é útil quando os pacotes chegam até ele. Os firewalls não têm a capacidade de influenciar o comportamento de aplicativos ou cargas de trabalho em sua origem, mas apenas esperam que os pacotes cheguem à porta do firewall. Os firewalls reforçam a segurança da rede e microssegmentação à medida que o tráfego está em trânsito — tráfego norte-sul. Eles não impõem a segurança de aplicativos ou cargas de trabalho na origem — tráfego leste-oeste. Ambas as soluções são necessárias para uma verdadeira Confiança zero arquitetura precisa ser realizada, mas uma camada da arquitetura não pode fornecer segurança total e microssegmentação para a outra.

As equipes de rede não devem ser encarregadas da segurança da carga de trabalho ou dos aplicativos

As equipes de rede se concentram nas tarefas de rede, que são diferentes das tarefas de carga de trabalho ou de aplicativos. Essas tarefas envolvem termos relevantes para essas equipes, como traduções e mecanismos de encaminhamento das camadas 2 e 3, protocolos de roteamento como BGP e OSPF e como eles interagem entre si e seus próprios mecanismos de autenticação. As soluções para problemas de rede de camada 2, como spanning tree e ECMP, também têm suas próprias prioridades de segurança. Ferramentas de rede, como SDN e dispositivos de rede virtualizados implantados em hipervisores, estão focadas em questões específicas das prioridades de rede. Em nenhuma dessas soluções, os riscos de segurança dentro de uma carga de trabalho em si são uma prioridade.

O que tudo isso significa é que, ao projetar soluções de segurança e microssegmentação para cargas de trabalho, essas soluções devem ser implantadas lá: na carga de trabalho. As ferramentas de rede têm prioridades que diferem das preocupações com a carga de trabalho ou com o aplicativo. As ferramentas de segurança de rede sempre existirão, com foco na aplicação do tráfego norte-sul, dentro e fora da malha geral da rede. Essas ferramentas de rede serão implantadas em dispositivos de rede. A segurança da carga de trabalho deve ser implantada nas próprias cargas de trabalho, e elas se concentrarão em impor o tráfego leste-oeste, entre cargas de trabalho e entre aplicativos.

Manter cada camada da arquitetura geral focada nas prioridades específicas de sua própria camada permitirá que cada uma seja agnóstica em relação à outra, sem que nenhuma camada imponha limitações sobre como a outra opera ou se expande. O resultado é uma arquitetura Zero Trust totalmente realizada.

Muitas arquiteturas nativas da nuvem seguem as melhores práticas de segurança e implantarão soluções de segurança de carga de trabalho nas próprias cargas de trabalho. Mas os velhos hábitos são difíceis de perder, e muitas vezes quando os ambientes de TI existentes são migrados dos data centers para serviços em nuvem, a abordagem tradicional de usar soluções de rede para tentar reforçar a segurança da carga de trabalho também será migrada, resultando em uma camada de rede que geralmente não atende aos requisitos de segurança leste-oeste entre cargas de trabalho e aplicativos. O resultado não é Zero Trust.

É aqui que o Illumio se encaixa na arquitetura geral de segurança. Diferentemente das abordagens tradicionais de segmentação de rede, o Illumio permite que a segurança e a microssegmentação sejam aplicadas diretamente na entidade que você está tentando proteger e segmentar: a carga de trabalho em si. Isso permite que a segurança e a microssegmentação da carga de trabalho e dos aplicativos se expandam e evoluam sem depender de onde elas residem na rede. E isso permite que as cargas de trabalho residam ou migrem para qualquer lugar entre data centers locais ou provedores de nuvem.

Uma arquitetura multinuvem criará uma ampla malha de rede, com acessibilidade em todas as topologias de rede subjacentes. A segurança e a microssegmentação devem seguir a mesma diretriz, fornecendo uma solução consistente e escalável na mesma malha de rede, de ponta a ponta. Zero Trust significa que o limite de confiança de segurança é estendido a cada carga de trabalho e aplicativo que precisa ser protegido, e essa meta não deve ser limitada pela tentativa de viabilizar essa meta em qualquer camada diferente da arquitetura de nuvem.

Para saber mais sobre esses tópicos e como a Illumio resolve a segurança de cargas de trabalho e aplicativos:

• Assista a este vídeo de visão geral rápida sobre A evolução da segmentação
• Confira este webinar sob demanda: Desbloqueie a segurança da rede: segmentação simplificada