A nuvem se transformou no novo data center da maioria das empresas, e os ambientes multinuvem estão se tornando cada vez mais a regra do que a exceção. As cargas de trabalho na nuvem precisam comunicar-se de forma segura, tanto entre si e quanto com a internet. Infelizmente, as opções disponíveis para manter uma conectividade segura de nuvem para nuvem e da nuvem para a internet, usando firewalls e VPNs para estender a WAN corporativa à nuvem, geram riscos de segurança, complexidade operacional e problemas de desempenho.

Os desafios de estender a WAN corporativa à nuvem

Tradicionalmente, conecta-se dois ambientes diferentes com roteadores. Como esses roteadores são usados como terminais de túneis de VPN ou IPSec e comutadores de rotas, cada um desses ambientes tem acesso a todos os endereços IP dos outros ambientes. Para controlar o acesso entre esses ambientes, são usados firewalls para controlar o acesso estático e garantir que somente IPs específicos de um ambiente tenham acesso a IPs específicos de outros ambientes. Essa é a antiga abordagem de IP e firewall que a maioria das empresas tinha que adotar, porque não havia outra escolha.

Figura

Essa abordagem de IP e firewall gera riscos de segurança porque a conectividade plana de IPs com uma malha completa torna as redes suscetíveis à movimentação lateral das ameaças.

Essa abordagem também gera complexidade operacional devido às cargas de trabalho efêmeras na nuvem. Na medida que os IPs vêm e vão, cada novo IP precisa ser propagado pelos roteadores. Qualquer novo IP precisa ser programado no firewall, e, se houver sobreposição desses IPs, ela tem que ser resolvida para que eles possam conectar-se a essas redes.

Finalmente, essa abordagem apresenta problemas de escala e de desempenho, tais como o escalonamento de rotas, estrangulamento da produção e maior latência.

Esses problemas ficam cada vez mais difíceis de solucionar à medida que mais aplicativos são distribuídos em diversas nuvens, e também devido à adoção de serviços nativos da nuvem, como contêineres, PaaS e arquiteturas sem servidor.

Com a abordagem legada, todo o tráfego direcionado para a internet ou para outras cargas de trabalho em uma nuvem diferente precisa passar por um hub centralizado, e esse hub tem firewalls, proxies Squid, roteadores etc. – semelhante à arquitetura de castelo e fosso dos data centers. As limitações específicas incluem:

Figura

1. Postura de segurança limitada:

Para uma postura de segurança completa, são necessários recursos adicionais, como a proteção de proxy e de dados, já que não é possível fazer a inspeção de SSL em larga escala com firewalls virtuais. Isso resulta em dispositivos virtuais adicionais para proxies Squid, sandboxing etc.

2. Riscos associados a redes de malha completa:

Para permitir a comunicação de cargas de trabalho em um ambiente multinuvem, a arquitetura de IP legada distribui rotas e compartilha informações sobre IPs e sub-redes em diferentes ambientes, criando uma rede plana e regras de firewall estáticas que são fáceis de contornar, e que podem acabar resultando na movimentação lateral de ameaças.

3. Limitação de desempenho do hardware:

O rendimento é limitado pelo elo mais fraco – neste caso, a escala e o desempenho do firewall. Quanto mais serviços de segurança são habilitados nos firewalls, como a inspeção de SSL do conteúdo, mais lento é o desempenho.

4. Custos indiretos de orquestração e administração:

Os firewalls legados exigem máquinas virtuais adicionais para orquestração, políticas, operações e gerenciamento de licenças, o que acrescenta mais níveis de complexidade e custo. A replicação de tudo isso para cada fornecedor de nuvem representa um ônus adicional para as operações com múltiplas nuvens.

5. Pontos cegos causados por múltiplos saltos até o destino:

As abordagens legadas baseadas em IP precisam de várias ferramentas, como firewalls, roteadores SD-WAN, NACLs e grupos de segurança. Cada uma delas requer seu próprio registro, e uma correlação inadequada de registros cria pontos cegos adicionais para as redes e as equipes de segurança.

Estendendo a zero trust às cargas de trabalho na nuvem

Felizmente, nos últimos anos, o desafio da WAN corporativa já foi descartado em termos do acesso dos funcionários. Para superar as deficiências da abordagem de IP e firewall em termos de segurança e desempenho, uma porcentagem cada vez maior de empresas está adotando estratégias de zero trust. Esses mesmos princípios de zero trust, reinventados para as necessidades específicas das cargas de trabalho na nuvem, são o futuro das redes multinuvem.

Como a zero trust não confia em nenhuma rede, as informações de IP e roteamento nunca são transmitidas. A conectividade das cargas de trabalho é permitida em nível granular com base na identidade e no contexto, portanto, não há necessidade de criar regras estáticas de firewall para restringir o acesso a IPs entre os ambientes.

Figura

O Zscaler Internet Access (ZIA) e o Zscaler Private Access (ZPA) são líderes de mercado, garantindo a segurança do acesso à internet e a aplicativos privados pelo usuário final. A Workload Communications da Zscaler, habilitada pelo Cloud Connector, amplia essas soluções para garantir o acesso seguro das cargas de trabalho à internet (ZIA for workloads) e o acesso privado a cargas de trabalho privadas remotas (com o ZPA for workloads). Essa nova e revolucionária abordagem aumenta a segurança, reduz a complexidade operacional e melhora o desempenho dos aplicativos.

Caso de uso 1: Habilitando a zero trust nas comunicações entre as cargas de trabalho e a internet

O Cloud Connector permite que as cargas de trabalho se conectem diretamente à nuvem da Zscaler para obter acesso à internet. Todos os serviços de segurança, como proxy de SSL, proteção de dados e proteção avançada contra ameaças, são executados nativamente na Zero Trust Exchange. Com essa arquitetura, é possível aplicar a mesma política de segurança a todas as cargas de trabalho que acessam a internet a partir de qualquer nuvem. Isso é fundamentalmente diferente das arquiteturas legadas, nas quais é necessário construir uma arquitetura de castelo e fosso com firewalls e proxies Squid em cada nuvem.

Caso de uso 2: Habilitando a zero trust para comunicações entre cargas de trabalho em um ambiente multinuvem

O Cloud Connector permite que as cargas de trabalho se conectem diretamente à nuvem da Zscaler. Cargas de trabalho de qualquer nuvem (AWS, Azure, data center) podem se comunicar entre si através da Zero Trust Exchange. A Zero Trust Exchange usa identidade e contexto para verificar a confiabilidade primeiro, e só então estabelece a conexão. Isso é fundamentalmente diferente das arquiteturas legadas, que requerem o roteamento de IP entre esses ambientes de nuvem.

Caso de uso 3: Habilitando a zero trust para comunicações entre cargas de trabalho dentro de uma VPC/VNET

A Zscaler Workload Segmentation executa a segmentação a nível granular, dentro de uma máquina virtual, de cada aplicativo ou processo individual. Um agente de segmentação de cargas de trabalho fornece a identidade do software, gerando impressões digitais ao nível do processo. A aprendizagem de máquina automatizada descobre todos os caminhos disponíveis para um determinado processo ou aplicativo e faz recomendações sobre os caminhos permitidos, descartando todos os caminhos desnecessários que aumentam o risco de movimentação lateral de ameaças. Isso difere muito das arquiteturas legadas, onde são usadas ACLs (Listas de Controle de Acesso) e SG (Grupos de Segurança) estáticos que o atacante pode contornar com facilidade "pegando carona" em uma regra existente.

Como a zero trust resolve as limitações de IP e firewall

Figura

Quando examinamos as arquiteturas legadas, o problema básico mais comum é a conectividade de IP. Tradicionalmente, rede e segurança são vistas como funcionalidades separadas. A conectividade (roteamento de IP) é ativada primeiro, e em seguida a segurança (filtragem por firewall) é ativada. Alguns fornecedores integram ambas em um único hardware, mas a abordagem e a arquitetura são as mesmas.

A Zero Trust Exchange da Zscaler adota uma abordagem fundamentalmente diferente: a segurança vem em primeiro lugar, e depois a conectividade. Por que criar uma conectividade desnecessária que vai precisar ser bloqueada mais tarde?

Na abordagem de zero trust da Zscaler, não se confia em ninguém. A única conectividade padrão para o aplicativo de origem é a Zero Trust Exchange, mas não para o aplicativo de destino. Todo o tráfego das cargas de trabalho é encaminhado para o Cloud Connector, que então as conecta à Zero Trust Exchange.

A Zero Trust Exchange percorre as seguintes etapas antes que a origem e o destino sejam conectados:

Figura

Etapa 1: Quem é você?

A Zero Trust Exchange verifica de onde vêm as cargas de trabalho, como um Cloud Connector autenticado e registrado, por exemplo, ou um cliente VPC ou VNET.

Etapa 2: Para onde você vai?

Você pode definir a política com base no destino – a Zero Trust Exchange verifica se o destino é um aplicativo autorizado ou não.

Etapa 3: Qual é o seu nível de risco?

Você pode ter uma política baseada na VPC/VNET de origem. Somente VPCs corporativas têm acesso a determinados destinos; as VPCs/VNETs parceiras, consideradas arriscadas, não podem acessar esses destinos.

Etapa 4: O que você está transportando?

Para destinos não confiáveis na internet, você pode habilitar o proxy de SSL completo e inspecionar tudo o que vem da origem para o destino – e vice-versa.

Etapa 5: Estabelecer a conexão

Para destinos na internet, definimos o proxy e estabelecemos a conexão com o destino. Para acessar aplicativos privados, temos uma conexão de dentro para fora desde o Application Connector no destino. A Zero Trust Exchange é o ponto de encontro e estabelece essa conexão.

Principais benefícios da aplicação da zero trust às cargas de trabalho na nuvem

Figura

1. Proteção de todas as cargas de trabalho contra ameaças:

Evitar o comprometimento das cargas de trabalho:
A inspeção é feita em todas as comunicações de cargas de trabalho com a internet, o que as protege contra ameaças, como botnets, conteúdo ativo malicioso e fraude.

Prevenção da movimentação lateral das ameaças através das nuvens:
Com a conectividade de zero trust, cada ambiente (datacenter, regiões da nuvem etc.) é isolado e todos os demais destinos localizados em outros ambientes não são roteados. Isso evita qualquer movimentação lateral das ameaças através dos ambientes.

Evitar a movimentação lateral de ameaças dentro de um datacenter ou de uma região da nuvem:
A microssegmentação baseada em identidade ao nível do processo evita qualquer movimentação lateral de ameaças dentro de um datacenter ou de uma região da nuvem.

2. Garantir a segurança dos dados em SaaS e nuvens públicas:

Figura

Garantir a segurança dos dados em nuvens públicas:
Assegurar o acesso às cargas de trabalho, segundo o princípio do menor privilégio, minimizando os direitos (CIEM) e reduzindo o risco de comprometimento através da correção de erros de configuração (CSPM).

Garantir a segurança dos dados em SaaS:
Obter visibilidade em operações da TI invisível para impedir a utilização de aplicativos não autorizados e evitar o excesso de compartilhamentos (API CASB).

DLP em linha:
Prevenir violações ou exfiltração de dados ao garantir que todo o tráfego de cargas de trabalho que passa pela internet seja inspecionado pelo DLP.

3. Hiperescala para aumentar o desempenho e a escala:
A Zscaler tem mais de 150 POPs do serviço da Zero Trust Exchange. Esses POPs têm direitos de rede equiparados aos de todos os principais provedores de nuvem, e cada um deles tem uma capacidade operacional de terabytes. Por padrão, o Cloud Connector se conecta ao POP que tem a melhor disponibilidade e que está mais próximo.

4. Solução pronta para DevOps e totalmente automatizada:
O gerenciamento e as políticas são administrados de forma centralizada e aplicados na nuvem – todas e quaisquer atualizações dos Cloud Connectors são controladas pela Zscaler. A orquestração habilitada por Terraform pode ser prontamente integrada ao pipeline de CI/CD da Devops. As automações nativas da plataforma, como os modelos do Cloudformation e Azure Resource Manager (ARM), também são fornecidas com disponibilidade imediata.

5. Registro completo e transmissão de registros:
Todo o tráfego que sai de qualquer Cloud Connector, incluindo o tráfego para a Zero Trust Exchange, é registrado e pode ser transmitido para um agregador SIEM/log de sua escolha. Uma filtragem mais sofisticada é disponibilizada para fazer a transmissão para locais críticos.

Implementação de Cloud Connectors

O Cloud Connector pode ser implementado em cada VPC/VNET se for necessário fazer o isolamento de uma VPC/VNET, ou então ele pode ser implementado em um local central, caso seja necessário fazer o isolamento de um grupo de VPCs/VNETs. Os modelos de implementação têm flexibilidade para suportar tanto implementações centralizadas quanto distribuídas.

Figura

Em resumo, as cargas de trabalho são consideradas como imagens-espelho dos usuários. Ao adotar uma arquitetura zero trust para garantir a segurança das comunicações das cargas de trabalho, você protege suas cargas de trabalho e dados, elimina superfícies de ataque e bloqueia a movimentação lateral das ameaças. Convidamos você a juntar-se a nós nesta jornada de zero trust para transformar sua conectividade na nuvem. Para agendar uma demonstração, entre em contato conosco via [email protected].