O padrão em malha baseia-se no estabelecimento de uma arquitetura de rede híbrida. Essa arquitetura abrange vários ambientes de computação. Nestes ambientes, todos os sistemas podem comunicar entre si e não estão limitados à comunicação unidirecional com base nos requisitos de segurança das suas aplicações. Este padrão de rede aplica-se principalmente às arquiteturas de híbrido em camadas, multinuvem particionada> ou bursting. Também é aplicável à conceção de continuidade do negócio para aprovisionar um ambiente de recuperação de desastres (DR) no Google Cloud. Em todos os casos, requer que ligue os ambientes de computação de uma forma que esteja alinhada com os seguintes requisitos de comunicação:
- As cargas de trabalho podem comunicar entre si através dos limites do ambiente usando endereços IP privados RFC 1918.
- A comunicação pode ser iniciada por qualquer uma das partes. Os detalhes do modelo de comunicações podem variar com base nas aplicações e nos requisitos de segurança, como os modelos de comunicações abordados nas opções de design que se seguem.
- As regras de firewall que usa têm de permitir o tráfego entre origens e destinos de endereços IP específicos com base nos requisitos da aplicação ou das aplicações para as quais o padrão foi concebido. Idealmente, pode usar uma abordagem de segurança com várias camadas para restringir os fluxos de tráfego de forma detalhada, tanto entre como dentro dos ambientes de computação.
Arquitetura
O diagrama seguinte ilustra uma arquitetura de referência de alto nível do padrão em malha.
- Todos os ambientes devem usar um espaço de endereço IP RFC 1918 sem sobreposição.
- No lado Google Cloud , pode implementar cargas de trabalho numa única ou em várias VPCs partilhadas ou VPCs não partilhadas. Para outras opções de design possíveis deste padrão, consulte as variações de design que se seguem. A estrutura selecionada das suas VPCs deve estar alinhada com os projetos e a estrutura hierárquica dos recursos da sua organização.
- A rede VPC do Google Cloud estende-se a outros ambientes de computação. Esses ambientes podem estar nas instalações ou noutra nuvem. Use uma das opções de conetividade de rede híbrida e multicloud que satisfazem os requisitos da sua empresa e aplicação.
Limitar as comunicações apenas aos endereços IP permitidos das suas origens e destinos. Use qualquer uma das seguintes capacidades ou uma combinação das mesmas:
Dispositivo virtual de rede (NVA) com capacidades de inspeção de firewall de próxima geração (NGFW), colocado no caminho de rede.
Firewall de nova geração na nuvem Enterprise com serviço de prevenção de intrusões (IPS) para implementar a inspeção profunda de pacotes para prevenção de ameaças sem alterar o design da rede nem o encaminhamento.
Variantes
O padrão de arquitetura em rede pode ser combinado com outras abordagens para cumprir diferentes requisitos de design, ao mesmo tempo que considera os requisitos de comunicação do padrão. As opções de padrão estão descritas nas secções seguintes:
- Uma VPC por ambiente
- Use uma firewall de camada de aplicação centralizada
- Arquitetura distribuída de confiança zero de microsserviços
Uma VPC por ambiente
Os motivos comuns para considerar a opção de uma VPC por ambiente são os seguintes:
- O ambiente de nuvem requer a separação ao nível da rede das redes e dos recursos da VPC, em conformidade com o design da hierarquia de recursos da sua organização.
Se for necessária a separação administrativa de domínios, também pode ser combinada com um projeto separado por ambiente.
- Para gerir centralmente os recursos de rede numa rede comum e fornecer isolamento de rede entre os diferentes ambientes, use uma VPC partilhada para cada ambiente que tem no Google Cloud, como desenvolvimento, testes e produção.
- Requisitos de escala que podem ter de ir além das quotas da VPC para uma única VPC ou projeto.
Conforme ilustrado no diagrama seguinte, a arquitetura de uma VPC por ambiente permite que cada VPC se integre diretamente com o ambiente nas instalações ou outros ambientes na nuvem através de VPNs ou um Cloud Interconnect com vários anexos de VLAN.
O padrão apresentado no diagrama anterior pode ser aplicado numa zona de destino topologia de rede hub-and-spoke. Nessa topologia, é possível partilhar uma (ou várias) ligação híbrida com todas as VPCs spoke. É partilhada através de uma VPC de trânsito para terminar a conetividade híbrida e as outras VPCs spoke. Também pode expandir este design adicionando NVAs com capacidades de inspeção de firewall de próxima geração (NGFW) na VPC de trânsito, conforme descrito na secção seguinte, "Use uma firewall de camada de aplicação centralizada".
Use uma firewall de camada de aplicação centralizada
Se os seus requisitos técnicos exigirem a consideração da camada de aplicação (camada 7) e a inspeção detalhada de pacotes com capacidades avançadas de firewall que excedam as capacidades da firewall de próxima geração do Google Cloud, pode usar um dispositivo NGFW alojado numa NVA. No entanto, esse NVA tem de cumprir as necessidades de segurança da sua organização. Para implementar estes mecanismos, pode expandir a topologia para transmitir todo o tráfego entre ambientes através de uma firewall de NVA centralizada, conforme mostrado no diagrama seguinte.
Pode aplicar o padrão no seguinte diagrama no design da zona de destino usando uma topologia de hub e raios com dispositivos centralizados:
Conforme mostrado no diagrama anterior, a NVA atua como a camada de segurança do perímetro e serve de base para ativar a inspeção de tráfego inline. Também aplica políticas de controlo de acesso rigorosas. Para inspecionar os fluxos de tráfego leste-oeste e norte-sul, o design de uma NVA centralizada pode incluir vários segmentos com diferentes níveis de controlos de acesso de segurança.
Arquitetura distribuída de confiança zero de microsserviços
Quando são usadas aplicações em contentores, a arquitetura distribuída de confiança zero de microsserviços abordada na secção do padrão refletido também é aplicável a este padrão de arquitetura.
A principal diferença entre este padrão e o padrão espelhado é que o modelo de comunicação entre as cargas de trabalho no Google Cloud e outros ambientes pode ser iniciado a partir de qualquer um dos lados. O tráfego tem de ser controlado e detalhado, com base nos requisitos da aplicação e nos requisitos de segurança, através da Service Mesh.
Práticas recomendadas para padrões de malha
- Antes de mais, decida o design da hierarquia de recursos e o design necessário para suportar qualquer projeto e VPC. Ao fazê-lo, pode ajudar a selecionar a arquitetura de rede ideal que se alinha com a estrutura dos seus Google Cloud projetos.
- Use uma arquitetura distribuída de confiança zero quando usar o Kubernetes no seu ambiente de computação privado e Google Cloud.
- Quando usa NVAs centralizadas no seu design, deve definir vários segmentos com diferentes níveis de controlos de acesso de segurança e políticas de inspeção de tráfego. Baseie estes controlos e políticas nos requisitos de segurança das suas aplicações.
- Ao criar uma solução que inclua NVAs, é importante considerar a elevada disponibilidade (HA) das NVAs para evitar um único ponto de falha que possa bloquear toda a comunicação. Siga as orientações de implementação e conceção de HA e redundância fornecidas pelo Google Cloud fornecedor de segurança que fornece os seus NVAs.
- Para oferecer maior privacidade, integridade dos dados e um modelo de comunicação controlado, exponha as aplicações através de APIs com gateways de API, como o Apigee e o Apigee hybrid com mTLS ponto a ponto. Também pode usar uma VPC partilhada com o Apigee no mesmo recurso da organização.
- Se o design da sua solução exigir a exposição de uma aplicação baseada em Google Cloudà Internet pública, considere as recomendações de design abordadas no artigo Redes para fornecimento de aplicações viradas para a Internet.
- Para ajudar a proteger os Google Cloud serviços nos seus projetos e para ajudar a mitigar o risco de exfiltração de dados, use os VPC Service Controls para especificar perímetros de serviço ao nível do projeto ou da rede VPC. Além disso, pode estender os perímetros de serviço a um ambiente híbrido através de uma VPN autorizada ou do Cloud Interconnect. Para mais informações acerca das vantagens dos perímetros de serviço, consulte o artigo Vista geral dos VPC Service Controls.
- Reveja as práticas recomendadas gerais para padrões de rede híbridos e multicloud.
Se pretender aplicar um isolamento mais rigoroso e um acesso mais detalhado entre as suas aplicações alojadas no Google Cloude noutros ambientes, pondere usar um dos padrões restritos abordados nos outros documentos desta série.