Melhores práticas para segmentação de carga de trabalho: enxutas e simplificadas ou pesadas e complexas?

A “cibersegurança” abrange uma ampla variedade de tópicos, alguns dos quais incluem prioridades de rede, prioridades de hospedagem, autenticação, identidade, automação, conformidade e muito mais. Microssegmentação é uma parte desse princípio mais amplo, mas muitos ainda acreditam que é um desafio implementá-lo em grande escala.

Todas as cargas de trabalho modernas contêm um firewall e um filtro de porta integrados, como o iptables no Linux. Configurar isso em cargas de trabalho individuais é relativamente simples, mas fazer isso em grandes escalas geralmente é um desafio. E fazer isso na evolução da migração de cargas de trabalho monolíticas para microsserviços torna esse desafio ainda mais difícil de operacionalizar. O resultado é que a segmentação na camada de carga de trabalho da arquitetura geralmente não é feita, simplesmente deixando essa tarefa para a estrutura de rede subjacente implementar. Essa abordagem cria um conflito de prioridades, pois a segmentação de rede geralmente é implementada por motivos diferentes dos exigidos pela segmentação da carga de trabalho.

Dois requisitos principais para segmentação na camada de carga de trabalho nas arquiteturas de nuvem híbrida e de microsserviços são a automação e o suporte a arquiteturas de grande escala. Automação significa remover o elemento humano o máximo possível, pois quanto mais um ser humano estiver envolvido no processo operacional, maior a probabilidade de erros e configurações incorretas ocorrerem. E oferecer suporte a arquiteturas de grande escala significa permitir a automação da segmentação de forma a evitar obstáculos na arquitetura geral após uma determinada escala ser atingida.

Esses requisitos podem ser implementados de duas maneiras: uma abordagem “pesada” ou uma abordagem “leve”. Vamos comparar essas duas abordagens para ver qual faz mais sentido para você e sua organização.

Uma história de duas abordagens para microssegmentação

Vamos primeiro discutir o que consideramos uma abordagem “pesada”. Abordagens mais pesadas, como o Cisco Tetration, por exemplo, se concentram em capturar cada pacote de cada carga de trabalho, realizar análises de rede em toda a malha de rede e exigir uma quantidade significativa de intervenção humana na implementação de políticas de segmentação em grande escala. A operacionalização dessas ferramentas é bastante complexa e, portanto, pode ser descrita como uma abordagem “pesada” para implementar a microssegmentação.

Em contraste, abordagens “leves”, como a Illumio, foram desenvolvido especificamente para microssegmentação. Eles não nasceram como um produto e depois foram modificados para um produto diferente. Eles se concentram exclusivamente na segmentação na camada de carga de trabalho e são deliberadamente agnósticos quanto à forma como a rede subjacente é implementada, deixando a tarefa de análise de rede para as ferramentas de rede. Com essa abordagem, a implementação da política de segmentação é simplificada, com ênfase na automação, exigindo pouca ou nenhuma intervenção humana.

Quando a segmentação quebrará minha arquitetura?

É um truísmo, mas vale a pena repetir: quanto mais complexa a solução, mais cedo ela atingirá um limite superior operacional. Em algum momento, uma solução complexa incorrerá em um eventual obstáculo à escalabilidade da arquitetura geral de segmentação da carga de trabalho.

Soluções mais pesadas e complexas para microssegmentação funcionarão em casos de uso menores, mas, à medida que esses casos de uso crescerem, acabarão reduzindo a sobrecarga operacional e atingindo um limite rígido. Nesse ponto, cargas de trabalho adicionais geralmente ficam desprotegidas e a automação começa a falhar. À medida que a solução executa mais tarefas, a complexidade acaba se tornando uma carga operacional.

Os fornecedores de microssegmentação frequentemente publicam números que refletem seu limite superior de cargas de trabalho gerenciadas, e esses números parecem ser grandes o suficiente para acomodar o crescimento esperado. Porém, à medida que mais organizações adotam arquiteturas de nuvem híbrida, a virtualização cria muito mais cargas de trabalho do que no caso dos hosts bare-metal tradicionais. E as arquiteturas de microsserviços criam um número adicional significativo de entidades endereçáveis por IP em um host, fazendo com que o número total de cargas de trabalho aumente rapidamente. O número de cargas de trabalho gerenciadas não deve ser determinado pelas ferramentas usadas para operacionalizar a segmentação. Para garantir um ciclo ininterrupto de crescimento da carga de trabalho, nunca presuma que um número menor será suficiente.

Para automatizar a microssegmentação em qualquer arquitetura de nuvem híbrida em evolução, a solução não deve falhar depois que um número maior for atingido.

Automação ≠ Humanos

A automação exige uma arquitetura enxuta e simplificada. Uma grande porcentagem das violações de segurança em qualquer ambiente de nuvem se deve a erros honestos cometidos pelos administradores. À medida que os ciclos de vida das cargas de trabalho se tornam mais dinâmicos e o local onde elas residem nos segmentos de rede se torna cada vez mais efêmero, é mais importante automatizar os processos de segurança e remover o risco significativo introduzido pela intervenção humana no processo operacional.

A Illumio, como exemplo de abordagem leve, usa o conceito de etiquetas quadridimensionais e delimitação de aplicativos para simplificar e automatizar o processo de aplicação da segmentação a uma carga de trabalho no momento de sua criação. Ele permite sugerir limites de segmentação automaticamente ou permitir que o administrador defina esses limites. Isso reduz significativamente o risco de que a intervenção humana possa, inadvertidamente, introduzir um erro.

A maioria das soluções pesadas, como o Tetration, inclui opções para aplicar tags às cargas de trabalho para rastreá-las independentemente do endereçamento IP. Dito isso, o processo é “pesado”, complexo e requer uma quantidade significativa de interação humana inicial e experiência para ser operacionalizado. E, como você pode imaginar, quanto mais um processo exigir intervenção e experiência humana, maior o risco de erro não intencional.

Ao planejar a automatização da segmentação da carga de trabalho, tenha em mente esta regra: quanto mais complexo o processo, maior o risco.

Introduza microsserviços, espere mais cargas de trabalho

A migração do desenvolvimento de aplicativos de cargas de trabalho monolíticas para microsserviços introduz o efeito de aumentar significativamente o número de cargas de trabalho que precisam ser gerenciadas. Com o advento da virtualização, um único host bare-metal poderia gerenciar várias VMs, cada uma com seu próprio endereço IP. E agora, com o advento dos microsserviços, cada uma dessas VMs pode hospedar muitas construções em contêineres, resultando em ainda mais endereços IP.

Se cada entidade em uma rede com um endereço IP for definida como uma carga de trabalho, um ambiente de microsserviços pode fazer com que o número de cargas de trabalho exploda. O grande número de cargas de trabalho que precisam ser monitoradas exige uma solução que possa escalar para números muito grandes.

A visualização é fundamental

Monitorar uma carga de trabalho significa duas coisas básicas: aplicar políticas e visualizar. Mas como você visualiza o que os aplicativos estão fazendo uns com os outros em um grande número de cargas de trabalho? A visualização da comunicação da carga de trabalho não pode depender de segmentação de rede. No caso dos microsserviços, a necessidade de visualização vai além do tráfego de VM para VM e precisa incluir a comunicação entre pods, nós e serviços ao usar o Kubernetes ou o OpenShift para orquestrar os ciclos de vida dos contêineres.

Soluções pesadas, como a Tetration, podem impor políticas em um ambiente em contêineres, mas a visualização do tráfego de aplicativos dentro dessas construções é limitada. Essas soluções geralmente podem criar um mapa visual do tráfego entre os hosts, mas a visualização para aí e o tráfego entre construções em contêineres dentro de um host está ausente. Por outro lado, uma solução leve amplia a visibilidade desde hosts bare-metal até VMs e todas as construções em contêineres em qualquer host. Todas as cargas de trabalho, sejam monolíticas ou em contêineres, são totalmente visíveis quando a Illumio, por exemplo, constrói sua mapa de dependência de aplicativos.

Visualizar todo o tráfego e o comportamento de todos os aplicativos, independentemente de como eles estão hospedados, é essencial à medida que suas cargas de trabalho evoluem na nuvem híbrida e em diferentes recursos de computação, tanto em data centers locais quanto em estruturas de nuvem pública. A visualização se torna mais importante à medida que esses detalhes se tornam mais complexos e dinâmicos, a fim de criar e aplicar política declarativa legível por humanos.

A linha de fundo

Ao decidir como implementar a segmentação da carga de trabalho em escala e de forma automatizada, uma abordagem enxuta e simplificada é a única opção viável. Da mesma forma que implantar uma lancha às vezes é uma escolha melhor do que implantar um navio de guerra se o objetivo for velocidade e agilidade na água, o mesmo se aplica à forma como a microssegmentação é implantada em nuvens híbridas modernas e estruturas de computação. Reduza a complexidade e mantenha a solução “leve”, não “pesada”.