Padrão em malha

Last reviewed 2023-12-14 UTC

O padrão em malha é baseado no estabelecimento de uma arquitetura de rede híbrida. Essa arquitetura abrange vários ambientes de computação. Nesses ambientes, todos os sistemas podem se comunicar uns com os outros e não se limitam a uma comunicação unidirecional com base nos requisitos de segurança dos aplicativos. Esse padrão de rede é aplicável principalmente à arquiteturas híbridas em camadas, multicloud particionadas ou bursting. Ele também é aplicável ao design da continuidade dos negócios para provisionar um ambiente de recuperação de desastres (DR) no Google Cloud. Em todos os casos, é necessário conectar os ambientes de computação e alinhá-los aos seguintes requisitos de comunicação:

  • As cargas de trabalho podem se comunicar entre si nos limites do ambiente, usando endereços IP privados RFC 1918.
  • A comunicação pode ser iniciada dos dois lados. Os detalhes do modelo de comunicação podem variar com base nos aplicativos e nos requisitos de segurança, como os modelos de comunicação discutidos nas opções de design a seguir.
  • As regras de firewall usadas devem permitir o tráfego entre origens e destinos de endereços IP específicos com base nos requisitos do aplicativo ou aplicativos em que o padrão foi projetado. Idealmente, use uma abordagem de segurança em várias camadas para restringir os fluxos de tráfego de maneira refinada entre ambientes de computação e dentro deles.

Arquitetura

O diagrama a seguir ilustra uma arquitetura de referência de alto nível do padrão em malha.

Os dados em uma arquitetura de rede híbrida fluem de duas sub-redes no Google Cloud para uma carga de trabalho em um ambiente local.

  • Todos os ambientes devem usar um espaço de endereços IP RFC 1918 sem sobreposição.
  • No Google Cloud, é possível implantar cargas de trabalho em uma ou várias VPCs compartilhadas ou não compartilhadas. Para outras opções de design possíveis desse padrão, consulte as variações de design a seguir. A estrutura selecionada das VPCs deve estar alinhada com os projetos e o design da hierarquia de recursos da sua organização.
  • A rede VPC do Google Cloud se estende a outros ambientes de computação. Esses ambientes podem estar no local ou em outra nuvem. Use uma das opções de Conectividade de rede híbrida e multicloud para atender aos requisitos dos seus negócios e aplicativos.
  • Limite as comunicações apenas aos endereços IP permitidos das origens e destinos. Use qualquer um dos seguintes recursos ou uma combinação deles:

    • Regras de firewall ou políticas de firewall.

    • Dispositivo virtual de rede (NVA, na sigla em inglês) com recursos de inspeção de firewall de última geração (NGFW, na sigla em inglês) colocado no caminho da rede.

    • Cloud Next Generation Firewall Enterprise com serviço de prevenção de intrusão (IPS) para implementar inspeção detalhada de pacotes para prevenção de ameaças sem alterar o design ou o roteamento da rede.

Variações

O padrão de arquitetura em malha pode ser combinado com outras abordagens para atender os diferentes requisitos de design, mas ainda considera os requisitos de comunicação padrão. As opções de padrão são descritas nas seções a seguir:

Uma VPC por ambiente

Os motivos comuns para considerar a opção de uma VPC por ambiente são:

  • O ambiente de nuvem requer a separação no nível da rede das redes VPC e dos recursos, em alinhamento com o design da hierarquia de recursos da organização. Se a separação de domínios administrativos for necessária, ela também poderá ser combinada com um projeto separado por ambiente.
    • Para gerenciar centralmente os recursos de rede em uma rede comum e isolar redes entre ambientes diferentes, use uma VPC compartilhada para cada ambiente do Google Cloud, como desenvolvimento, teste e produção.
  • Dimensione os requisitos que podem ir além das cotas de VPC para uma única VPC ou projeto.

Conforme ilustrado no diagrama a seguir, o projeto com uma VPC por ambiente permite que cada VPC se integre diretamente ao ambiente no local ou a outros ambientes de nuvem usando VPNs ou o Cloud Interconnect com vários anexos da VLAN.

Os dados em uma arquitetura de rede híbrida com uma VPC em cada ambiente fluem de duas sub-redes no Google Cloud para uma carga de trabalho em um ambiente no local.

O padrão mostrado no diagrama anterior pode ser aplicado a uma topologia de rede hub e spoke da zona de destino. Nessa topologia, uma ou várias conexões híbridas podem ser compartilhadas com todas as redes VPCs spoke. Ela é compartilhada usando uma VPC de trânsito para encerrar a conectividade híbrida e outras VPCs spoke. Você também pode expandir esse design adicionando um NVA com recursos de inspeção de firewall de última geração (NGFW) na VPC de trânsito, conforme descrito na próxima seção, "Usar um firewall de camada do aplicativo centralizado".

Usar um firewall de camada do aplicativo centralizado

Se os requisitos técnicos exigirem considerar a camada do aplicativo (Camada 7) e uma inspeção detalhada de pacotes com recursos avançados de firewall que ultrapassem os recursos do firewall de última geração, é possível usar um aplicativo NGFW hospedado em um NVA. No entanto, esse NVA precisa atender aos requisitos de segurança da sua organização. Para implementar esses mecanismos, estenda a topologia para passar todo o tráfego entre ambientes por um firewall NVA centralizado, conforme o diagrama a seguir.

Você pode aplicar o padrão do diagrama a seguir ao design da zona de destino usando uma topologia de hub e spoke com dispositivos centralizados:

Os dados de duas VPCs compartilhadas no Google Cloud fluem por um NVA para uma rede VPC de trânsito e para uma carga de trabalho em um ambiente local.

Conforme exibido no diagrama anterior, o NVA atua como a camada de segurança do perímetro e serve como base para permitir a inspeção do tráfego inline. Ele também aplica políticas rígidas de controle de acesso. Para inspecionar os fluxos de tráfego leste-oeste e norte-sul, o design de um NVA centralizado pode incluir vários segmentos com diferentes níveis de controles de acesso de segurança.

Arquitetura distribuída de microsserviços de confiança zero

Quando aplicativos em contêineres são usados, a arquitetura distribuída de microsserviços de confiança zero discutida na seção padrão espelhado também é aplicável a esse padrão de arquitetura.

A principal diferença entre esse padrão e o padrão espelhado é que o modelo de comunicação entre as cargas de trabalho no Google Cloud e em outros ambientes podem ser iniciadas nos dois lados. O tráfego deve ser controlado e refinado, com base nos requisitos de aplicativos e de segurança usando a Malha de serviço.

Práticas recomendadas para padrões em malha

  • Antes de fazer qualquer coisa, decida o design da hierarquia de recursos, e o design necessário para oferecer suporte a todos os projetos e à VPC. Isso pode ajudar você a selecionar a arquitetura de rede ideal para a estrutura dos projetos do Google Cloud.
  • Use uma arquitetura distribuída de confiança zero ao usar o Kubernetes no ambiente de computação privado e no Google Cloud.
  • Ao usar NVAs centralizados no projeto, é preciso definir vários segmentos com diferentes níveis de controles de acesso de segurança e políticas de inspeção de tráfego. Baseie esses controles e políticas nos requisitos de segurança dos aplicativos. Para mais informações, consulte Dispositivos de rede centralizados no Google Cloud.

  • Ao projetar uma solução que inclua NVAs, é importante considerar a alta disponibilidade deles para evitar um ponto único de falha que possa bloquear toda a comunicação. Siga o design de alta disponibilidade e redundância e as orientações de implementação fornecidas pelo Fornecedor de segurança do Google Cloud, que fornece os NVAs.

  • Para oferecer maior privacidade, integridade de dados e um modelo de comunicação controlado, exponha aplicativos usando APIs com gateways de API, como Apigee e Apigee híbrida com mTLS de ponta a ponta. Também é possível usar a VPC compartilhada com a Apigee no mesmo recurso da organização.

  • Se o design da sua solução exigir a exposição de um aplicativo baseado no Google Cloud à Internet pública, considere as recomendações de design discutidas em Rede para entrega de aplicativos voltados à Internet.

  • Para ajudar a proteger os serviços do Google Cloud nos seus projetos e reduzir o risco de exfiltração de dados, use o VPC Service Controls para especificar perímetros de serviço no nível do projeto ou da rede VPC. Além disso, você pode estender perímetros de serviço para um ambiente híbrido usando uma VPN autorizada ou o Cloud Interconnect. Para mais informações sobre os benefícios dos perímetros de serviço, consulte Visão geral do VPC Service Controls.

  • Reveja as práticas recomendadas gerais para padrões de rede híbrida e multicloud.

Se você pretende aplicar um isolamento mais rigoroso e um acesso mais granular entre os aplicativos hospedados no Google Cloud e em outros ambientes, considere usar um dos padrões controlados que serão abordados nos outros documentos desta série.