Padrões de arquitetura de rede segura híbrida e multinuvem

Last reviewed 2025-01-23 UTC

Esta página oferece uma vista de página única de todas as páginas em Crie arquiteturas híbridas e multinuvem com Google Cloud. Pode imprimir esta página ou guardá-la em formato PDF através da função de impressão do navegador e escolhendo a opção Guardar como PDF. Esta página não apresenta um painel do índice (ToC) no lado direito.

Este documento é o terceiro de três documentos num conjunto. Aborda padrões de arquitetura de rede híbrida e multicloud. Esta parte explora vários padrões de arquitetura de rede segura comuns que pode usar para arquiteturas híbridas e multicloud. Descreve os cenários mais adequados para estes padrões de rede e fornece práticas recomendadas para a respetiva implementação com o Google Cloud.

O conjunto de documentos para padrões de arquitetura híbrida e multicloud consiste nas seguintes partes:

• Crie arquiteturas híbridas e multicloud: aborda o planeamento de uma estratégia para criar uma configuração híbrida e multicloud com o Google Cloud.
• Padrões de arquitetura híbrida e multicloud: aborda padrões de arquitetura comuns a adotar como parte de uma estratégia híbrida e multicloud.
• Padrões de arquitetura de rede segura híbrida e multicloud: aborda padrões de arquitetura de rede híbrida e multicloud de uma perspetiva de rede (este documento).

A ligação de ambientes de computação privados de forma Google Cloud segura e fiável é essencial para qualquer arquitetura híbrida e de várias nuvens bem-sucedida. A conetividade de rede híbrida e o padrão de arquitetura de rede na nuvem que escolher para uma configuração híbrida e multinuvem têm de cumprir os requisitos exclusivos das suas cargas de trabalho empresariais. Também tem de se adequar aos padrões de arquitetura que pretende aplicar. Embora possa ter de adaptar cada design, existem padrões comuns que pode usar como modelo.

Os padrões de arquitetura de rede neste documento não devem ser considerados alternativas ao design da zona de destino em Google Cloud. Em alternativa, deve conceber e implementar os padrões de arquitetura que selecionar como parte do Google Cloud design geral da zona de destino, que abrange as seguintes áreas:

• Identidades
• Gestão de recursos
• Segurança
• Trabalhar em rede
• Monitorização

As diferentes aplicações podem usar diferentes padrões de arquitetura de rede, que são incorporados como parte de uma arquitetura de zona de destino. Numa configuração de várias nuvens, deve manter a consistência do design da zona de destino em todos os ambientes.

Esta série contém as seguintes páginas:

• Considerações de design
• Padrões de arquitetura
  • Padrão espelhado
  • Padrão de malha
  • Padrões restritos
    • Saída controlada
    • Entrada com portão
    • Saída e entrada com portão
  • Transferência
• Práticas recomendadas gerais

Colaboradores

Autor: Marwan Al Shawi | Partner Customer Engineer

Outros colaboradores:

• Saud Albazei | Customer Engineer, Application Modernization
• Anna Berenberg | Engineering Fellow
• Marco Ferrari | Arquiteto de soluções na nuvem
• Victor Moreno | Gestor de produtos, redes na nuvem
• Johannes Passing | Arquiteto de soluções na nuvem
• Mark Schlagenhauf | Redator técnico, redes
• Daniel Strebel | EMEA Solution Lead, Application Modernization
• Ammett Williams | Developer Relations Engineer

Padrões de arquitetura

Os documentos desta série abordam padrões de arquitetura de rede concebidos com base nos modelos de comunicação necessários entre aplicações residentes no Google Cloud e noutros ambientes (nas instalações, noutras nuvens ou ambos).

Estes padrões devem ser incorporados na arquitetura geral da zona de destino da organização, que pode incluir vários padrões de rede para responder aos requisitos específicos de comunicação e segurança de diferentes aplicações.

Os documentos desta série também abordam as diferentes variações de design que podem ser usadas com cada padrão de arquitetura. Os seguintes padrões de rede podem ajudar a cumprir os requisitos de comunicação e segurança das suas aplicações:

• Padrão espelhado
• Padrão de malha
• Padrões restritos
  • Saída controlada
  • Entrada com portão
  • Saída controlada e entrada controlada
• Padrão de transferência

Padrão espelhado

O padrão refletido baseia-se na replicação do design de um determinado ambiente ou ambientes existentes para um novo ambiente ou ambientes. Por conseguinte, este padrão aplica-se principalmente a arquiteturas que seguem o padrão híbrido de ambiente. Nesse padrão, executa os seus fluxos de trabalho de desenvolvimento e teste num ambiente, enquanto executa os seus fluxos de trabalho de preparação e produção noutro.

O padrão espelhado pressupõe que as cargas de trabalho de teste e de produção não devem comunicar diretamente entre si. No entanto, deve ser possível gerir e implementar ambos os grupos de cargas de trabalho de forma consistente.

Se usar este padrão, associe os dois ambientes de computação de forma a estar em conformidade com os seguintes requisitos:

• A integração contínua/implementação contínua (CI/CD) pode implementar e gerir cargas de trabalho em todos os ambientes de computação ou em ambientes específicos.
• A monitorização, a gestão de configuração e outros sistemas administrativos devem funcionar em todos os ambientes de computação.
• As cargas de trabalho não podem comunicar diretamente entre ambientes de computação. Se necessário, a comunicação tem de ser feita de forma detalhada e controlada.

Arquitetura

O diagrama de arquitetura seguinte mostra uma arquitetura de referência de alto nível deste padrão que suporta CI/CD, monitorização, gestão de configuração, outros sistemas administrativos e comunicação de cargas de trabalho:

A descrição da arquitetura no diagrama anterior é a seguinte:

• As cargas de trabalho são distribuídas com base nos ambientes funcionais (desenvolvimento, testes, CI/CD e ferramentas administrativas) em VPCs separadas no lado Google Cloud .
• A VPC partilhada é usada para cargas de trabalho de desenvolvimento e testes. É usada uma VPC adicional para as ferramentas de CI/CD e administrativas. Com VPCs partilhadas:
  • As aplicações são geridas por equipas diferentes por ambiente e por projeto de serviço.
  • O projeto anfitrião administra e controla a comunicação de rede e os controlos de segurança entre os ambientes de desenvolvimento e teste, bem como para fora da VPC.
• A VPC de CI/CD está ligada à rede que executa as cargas de trabalho de produção no seu ambiente de computação privado.
• As regras de firewall permitem apenas tráfego permitido.
  • Também pode usar a firewall de nova geração do Google Cloud Enterprise com o serviço de prevenção de intrusões (IPS) para implementar a inspeção profunda de pacotes para a prevenção de ameaças sem alterar o design nem o encaminhamento. A firewall de nova geração empresarial do Google Cloud funciona através da criação de pontos finais de firewall zonais geridos pela Google que usam tecnologia de interceção de pacotes para inspecionar de forma transparente as cargas de trabalho quanto às assinaturas de ameaças configuradas. Também protege as cargas de trabalho contra ameaças.
• Permite a comunicação entre as VPCs em peering através de endereços IP internos.
  • A interligação neste padrão permite que os sistemas de CI/CD e administrativos implementem e geram cargas de trabalho de desenvolvimento e testes.
• Considere estas práticas recomendadas gerais.

Estabelece esta ligação de CI/CD através de uma das opções de conetividade de rede híbrida e multicloud discutidas que satisfazem os requisitos da sua empresa e aplicações. Para lhe permitir implementar e gerir cargas de trabalho de produção, esta ligação oferece acessibilidade à rede privada entre os diferentes ambientes de computação. Todos os ambientes devem ter um espaço de endereço IP RFC 1918 sem sobreposição.

Se as instâncias nos ambientes de desenvolvimento e testes precisarem de acesso à Internet, considere as seguintes opções:

• Pode implementar o Cloud NAT na mesma rede do projeto anfitrião de VPC partilhada. A implementação na rede do projeto anfitrião da VPC partilhada ajuda a evitar que estas instâncias sejam diretamente acessíveis a partir da Internet.
• Para o tráfego Web de saída, pode usar o Secure Web Proxy. O proxy oferece várias vantagens.

Para mais informações sobre as Google Cloud ferramentas e as capacidades que ajudam a criar, testar e implementar no Google Cloud e em ambientes híbridos e multicloud, consulte o blogue DevOps e CI/CD no Google Cloud explicados.

Variantes

Para cumprir diferentes requisitos de design, ao mesmo tempo que considera todos os requisitos de comunicação, o padrão de arquitetura refletido oferece estas opções, que são descritas nas secções seguintes:

• VPC partilhada por ambiente
• Firewall de camada de aplicação centralizada
• Topologia de hub e raios
• Arquitetura distribuída de confiança zero de microsserviços

VPC partilhada por ambiente

A opção de design de VPC partilhada por ambiente permite a separação ao nível da aplicação ou do serviço em todos os ambientes, incluindo CI/CD e ferramentas administrativas que podem ser necessárias para cumprir determinados requisitos de segurança organizacionais. Estes requisitos limitam a comunicação, o domínio administrativo e o controlo de acesso para diferentes serviços que também têm de ser geridos por diferentes equipas.

Este design alcança a separação através do fornecimento de isolamento ao nível da rede e do projeto entre os diferentes ambientes, o que permite uma comunicação mais detalhada e o controlo de acesso da gestão de identidade e de acesso (IAM).

Do ponto de vista da gestão e das operações, este design oferece a flexibilidade necessária para gerir as aplicações e as cargas de trabalho criadas por diferentes equipas por ambiente e por projeto de serviço. As redes VPC e as respetivas funcionalidades de segurança podem ser aprovisionadas e geridas por equipas de operações de rede com base nas seguintes estruturas possíveis:

• Uma equipa gere todos os projetos anfitriões em todos os ambientes.
• As diferentes equipas gerem os projetos anfitriões nos respetivos ambientes.

As decisões sobre a gestão de projetos anfitriões devem basear-se na estrutura da equipa, nas operações de segurança e nos requisitos de acesso de cada equipa. Pode aplicar esta variação de design à rede VPC partilhada para cada opção de design da zona de destino do ambiente. No entanto, tem de considerar os requisitos de comunicação do padrão refletido para definir que comunicação é permitida entre os diferentes ambientes, incluindo a comunicação através da rede híbrida.

Também pode aprovisionar uma rede de VPC partilhada para cada ambiente principal, conforme ilustrado no diagrama seguinte:

Firewall de camada de aplicação centralizado

Em alguns cenários, os requisitos de segurança podem exigir a consideração da camada de aplicação (camada 7) e da inspeção detalhada de pacotes com mecanismos avançados de firewall que excedam as capacidades da firewall de nova geração da nuvem. Para cumprir os requisitos e as normas de segurança da sua organização, pode usar um dispositivo NGFW alojado num dispositivo virtual de rede (NVA). Vários Google Cloud parceiros de segurança oferecem opções adequadas para esta tarefa.

Conforme ilustrado no diagrama seguinte, pode colocar a NVA no caminho da rede entre a nuvem virtual privada e o ambiente de computação privado através de várias interfaces de rede.

Este design também pode ser usado com várias VPCs partilhadas, conforme ilustrado no diagrama seguinte.

A NVA nesta conceção atua como a camada de segurança do perímetro. Também servem de base para ativar a inspeção de tráfego inline e aplicar políticas de controlo de acesso rigorosas.

Para uma estratégia de segurança multicamadas robusta que inclua regras de firewall da VPC e capacidades de serviço de prevenção de intrusões, inclua uma inspeção de tráfego adicional e um controlo de segurança nos fluxos de tráfego leste-oeste e norte-sul.

Nota: nas regiões da nuvem suportadas e quando for tecnicamente viável para o seu design, é possível implementar NVAs sem precisar de várias redes VPC ou interfaces de dispositivos. Esta implementação baseia-se na utilização do equilíbrio de carga e das capacidades de encaminhamento baseado em políticas. Estas capacidades permitem um mecanismo independente da topologia e orientado por políticas para integrar NVAs na sua rede na nuvem. Para mais detalhes, consulte o artigo Implemente dispositivos virtuais de rede (NVAs) sem várias VPCs.

Topologia de hub e raios

Outra variação de design possível é usar VPCs separadas (incluindo VPCs partilhadas) para o desenvolvimento e diferentes fases de teste. Nesta variação, conforme mostrado no diagrama seguinte, todos os ambientes de preparação ligam-se à VPC administrativa e de CI/CD numa arquitetura de hub and spoke. Use esta opção se tiver de separar os domínios administrativos e as funções em cada ambiente. O modelo de comunicação centralizado pode ajudar com os seguintes requisitos:

• As aplicações precisam de aceder a um conjunto comum de serviços, como monitorização, ferramentas de gestão de configuração, CI/CD ou autenticação.
• É necessário aplicar um conjunto comum de políticas de segurança ao tráfego de entrada e saída de forma centralizada através do hub.

Para mais informações sobre as opções de design de hub-and-spoke, consulte os artigos Topologia de hub-and-spoke com dispositivos centralizados e Topologia de hub-and-spoke sem dispositivos centralizados.

Conforme mostrado no diagrama anterior, a comunicação entre VPCs e a conetividade híbrida passam pela VPC do hub. Como parte deste padrão, pode controlar e restringir a comunicação na VPC do hub para se alinhar com os seus requisitos de conetividade.

Como parte da arquitetura de rede de hub e raios, seguem-se as principais opções de conetividade (entre os raios e as VPCs do hub) no Google Cloud:

• Intercâmbio de redes da VPC
• VPN
• Usar um dispositivo virtual de rede (NVA)
  • Com várias interfaces de rede
  • Com o Network Connectivity Center (NCC)

Para mais informações sobre a opção que deve considerar no seu design, consulte o artigo Arquitetura de rede centralizada. Um fator de influência fundamental para selecionar a VPN em vez da interligação de VPC entre os raios e a VPC central é quando a transitividade do tráfego é necessária. A transitividade do tráfego significa que o tráfego de um spoke pode alcançar outros spokes através do hub.

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

As arquiteturas híbridas e multicloud podem exigir vários clusters para atingir os respetivos objetivos técnicos e empresariais, incluindo a separação do ambiente de produção dos ambientes de desenvolvimento e teste. Por conseguinte, os controlos de segurança do perímetro de rede são importantes, especialmente quando são necessários para agir em conformidade com determinados requisitos de segurança.

Não basta suportar os requisitos de segurança das arquiteturas de microsserviços distribuídos atuais baseadas na nuvem. Também deve considerar arquiteturas distribuídas de confiança zero. A arquitetura distribuída de confiança zero de microsserviços suporta a sua arquitetura de microsserviços com a aplicação de políticas de segurança, autenticação e identidade da carga de trabalho ao nível do microsserviço. A confiança é baseada na identidade e aplicada a cada serviço.

Ao usar uma arquitetura de proxy distribuída, como uma malha de serviços, os serviços podem validar eficazmente os autores das chamadas e implementar políticas de controlo de acesso detalhadas para cada pedido, o que permite um ambiente de microsserviços mais seguro e escalável. O Cloud Service Mesh oferece-lhe a flexibilidade de ter uma malha comum que pode abranger as suas implementações Google Cloud e no local. A malha usa políticas de autorização para ajudar a proteger as comunicações entre serviços.

Também pode incorporar o adaptador do Apigee para o Envoy, que é uma implementação da gateway de API do Apigee simples num cluster do Kubernetes, com esta arquitetura. O Apigee Adapter for Envoy é um proxy de serviços e de limite de código aberto concebido para aplicações prioritárias na nuvem.

Para mais informações sobre este tópico, consulte os seguintes artigos:

• Arquitetura distribuída de confiança zero
• Ambiente híbrido do GKE Enterprise
• Associar à Google
  • Ligue um cluster do GKE Enterprise no local a uma Google Cloud rede.
• Configure uma malha híbrida ou multinuvem
  • Implemente o Cloud Service Mesh em ambientes e clusters.

Práticas recomendadas para o padrão espelhado

• Os sistemas de CI/CD necessários para implementar ou reconfigurar implementações de produção têm de estar altamente disponíveis, o que significa que todos os componentes da arquitetura têm de ser concebidos para fornecer o nível esperado de disponibilidade do sistema. Para mais informações, consulte a secção sobre a Google Cloud fiabilidade da infraestrutura.
• Para eliminar erros de configuração em processos repetidos, como atualizações de código, a automatização é essencial para padronizar as suas compilações, testes e implementações.
• A integração de NVAs centralizadas neste design pode exigir a incorporação de vários segmentos com diferentes níveis de controlos de acesso de segurança.
• 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 design de HA e redundância fornecidas pelo fornecedor da NVA.
• Se não exportar as rotas IP no local através do peering de VPC ou da VPN para a VPC de desenvolvimento e testes, pode restringir a acessibilidade da rede dos ambientes de desenvolvimento e testes ao ambiente no local. Para mais informações, consulte o artigo Troca de rotas personalizadas do intercâmbio da rede da VPC.
• Para cargas de trabalho com endereçamento IP privado que podem exigir acesso às APIs Google, pode expor as APIs Google através de um ponto final do Private Service Connect numa rede VPC. Para mais informações, consulte o artigo Entrada restrita, nesta série.
• Reveja as práticas recomendadas gerais para padrões de arquitetura de rede híbrida e multicloud.

Padrão de malha

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, multicloud particionado, 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.
• Do 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:

  • Regras de firewall ou políticas de firewall.

  • 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 da 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 de 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 sobre as 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.

Padrões com restrições

O padrão gated baseia-se numa arquitetura que expõe aplicações e serviços selecionados de forma detalhada, com base em APIs ou pontos finais expostos específicos entre os diferentes ambientes. Este guia categoriza este padrão em três opções possíveis, cada uma determinada pelo modelo de comunicação específico:

• Saída controlada

• Entrada com portão

• Saída e entrada controladas (controladas bidirecionalmente em ambas as direções)

Conforme mencionado anteriormente neste guia, os padrões de arquitetura de rede descritos aqui podem ser adaptados a várias aplicações com requisitos diversos. Para responder às necessidades específicas de diferentes aplicações, a arquitetura da sua zona de destino principal pode incorporar um padrão ou uma combinação de padrões em simultâneo. A implementação específica da arquitetura selecionada é determinada pelos requisitos de comunicação específicos de cada padrão restrito.

Nota: em geral, o padrão gated pode ser aplicado ou incorporado com a opção de design da zona de destino que expõe os serviços num modelo de consumidor-produtor.

Esta série aborda cada padrão restrito e as respetivas opções de design possíveis. No entanto, uma opção de design comum aplicável a todos os padrões protegidos é a arquitetura distribuída de confiança zero para aplicações contentorizadas com arquitetura de microsserviços. Esta opção é baseada no Cloud Service Mesh, Apigee e Apigee Adapter for Envoy, uma implementação de gateway do Apigee simples num cluster do Kubernetes. O Apigee Adapter for Envoy é um proxy de serviço e de limite popular de código aberto concebido para aplicações baseadas na nuvem. Esta arquitetura controla as comunicações seguras permitidas entre serviços e a direção da comunicação ao nível do serviço. As políticas de comunicação de tráfego podem ser concebidas, otimizadas e aplicadas ao nível do serviço com base no padrão selecionado.

Os padrões restritos permitem a implementação da firewall de nova geração da Google Cloud Enterprise com o serviço de prevenção de intrusões (IPS) para realizar uma inspeção detalhada de pacotes para prevenção de ameaças sem modificações de conceção nem de encaminhamento. Essa inspeção está sujeita às aplicações específicas acedidas, ao modelo de comunicação e aos requisitos de segurança. Se os requisitos de segurança exigirem a camada 7 e a inspeção profunda de pacotes com mecanismos de firewall avançados que excedam as capacidades da firewall de nova geração do Google Cloud, pode usar uma firewall de nova geração (NGFW) centralizada alojada num dispositivo virtual de rede (NVA). Vários Google Cloud parceiros de segurança oferecem dispositivos NGFW que podem cumprir os seus requisitos de segurança. A integração de NVAs com estes padrões restritos pode exigir a introdução de várias zonas de segurança no design da rede, cada uma com níveis de controlo de acesso distintos.

Saída controlada

A arquitetura do padrão de rede de saída restrita baseia-se na exposição de APIs selecionadas do ambiente nas instalações ou de outro ambiente na nuvem a cargas de trabalho implementadas no Google Cloud. Faz isso sem os expor diretamente à Internet pública a partir de um ambiente nas instalações ou de outros ambientes na nuvem. Pode facilitar esta exposição limitada através de um gateway ou um proxy de API, ou um equilibrador de carga que funcione como uma fachada para cargas de trabalho existentes. Pode implementar a funcionalidade de gateway de API num segmento de rede de perímetro isolado, como uma rede de perímetro.

O padrão de rede de saída controlada aplica-se principalmente (mas não se limita) a padrões de arquitetura de aplicações hierárquicas e padrões de arquitetura de aplicações particionadas. Quando implementa cargas de trabalho de back-end numa rede interna, a rede de saída restrita ajuda a manter um nível de segurança mais elevado no seu ambiente de computação no local. O padrão requer que associe ambientes de computação de uma forma que cumpra os seguintes requisitos de comunicação:

• As cargas de trabalho que implementa no Google Cloud podem comunicar com o gateway de API ou o balanceador de carga (ou um ponto final do Private Service Connect) que expõe a aplicação através de endereços IP internos.
• Não é possível aceder a outros sistemas no ambiente de computação privada diretamente a partir de Google Cloud.
• A comunicação do ambiente de computação privado para quaisquer cargas de trabalho implementadas em Google Cloud não é permitida.
• O tráfego para as APIs privadas noutros ambientes só é iniciado a partir do ambiente Google Cloud .

O foco deste guia é em ambientes híbridos e multicloud ligados através de uma rede híbrida privada. Se os requisitos de segurança da sua organização o permitirem, é possível aceder diretamente às chamadas API para APIs de destino remotas com endereços IP públicos através da Internet. No entanto, tem de considerar os seguintes mecanismos de segurança:

• API OAuth 2.0 com Transport Layer Security (TLS).
• Limitação de velocidade.
• Políticas de proteção contra ameaças.
• TLS mútuo configurado para o back-end da sua camada de API.
• Filtragem da lista de autorizações de endereços IP configurada para permitir apenas a comunicação com origens e destinos de API predefinidos de ambos os lados.

Para proteger um proxy de API, considere estes outros aspetos de segurança. Para mais informações, consulte Práticas recomendadas para proteger as suas aplicações e APIs com o Apigee.

Arquitetura

O diagrama seguinte mostra uma arquitetura de referência que suporta os requisitos de comunicação indicados na secção anterior:

Os dados fluem através do diagrama anterior da seguinte forma:

• No Google Cloud lado, pode implementar cargas de trabalho em nuvens privadas virtuais (VPCs). As VPCs podem ser únicas ou múltiplas (partilhadas ou não partilhadas). A implementação deve estar alinhada com os projetos e a estrutura hierárquica de recursos da sua organização.
• As redes VPC do ambiente Google Cloud são expandidas para os outros ambientes de computação. Os ambientes podem estar nas instalações ou noutra nuvem. Para facilitar a comunicação entre ambientes através de endereços IP internos, use uma conetividade de rede híbrida e multicloud adequada.

• Para limitar o tráfego que tem origem em endereços IP de VPC específicos e se destina a gateways remotos ou equilibradores de carga, use a filtragem da lista de autorizações de endereços IP. O tráfego de retorno destas ligações é permitido quando usa regras de firewall com estado. Pode usar qualquer combinação das seguintes capacidades para proteger e limitar as comunicações apenas aos endereços IP de origem e de destino permitidos:

  • Regras de firewall ou políticas de firewall.

  • Dispositivo virtual de rede (NVA) com capacidades de inspeção de firewall de próxima geração (NGFW) que são colocadas no caminho da rede.

  • Firewall de nova geração do Google Cloud 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.

• Todos os ambientes partilham um espaço de endereço IP RFC 1918 sem sobreposição.

Variantes

O padrão de arquitetura de saída controlada pode ser combinado com outras abordagens para cumprir diferentes requisitos de design que ainda consideram os requisitos de comunicação deste padrão. O padrão oferece as seguintes opções:

• Use Google Cloud o gateway de API e o frontend global
• Exponha serviços remotos através do Private Service Connect

Use Google Cloud gateway de API e frontend global

Com esta abordagem de design, a exposição e a gestão das APIs residem em Google Cloud. Conforme mostrado no diagrama anterior, pode fazê-lo através da implementação do Apigee como plataforma de API. A decisão de implementar um gateway de API ou um equilibrador de carga no ambiente remoto depende das suas necessidades específicas e da configuração atual. O Apigee oferece duas opções para o aprovisionamento da conetividade:

• Com o intercâmbio de VPCs
• Sem intercâmbio de VPC

Google Cloud As capacidades de front-end globais, como o Cloud Load Balancing, o Cloud CDN (quando acedido através do Cloud Interconnect) e o Cross-Cloud Interconnect, melhoram a velocidade com que os utilizadores podem aceder a aplicações com back-ends alojados nos seus ambientes nas instalações e noutros ambientes na nuvem.

A otimização das velocidades de fornecimento de conteúdo é alcançada através do fornecimento dessas aplicações a partir de Google Cloud pontos de presença (PoP). Google Cloud Os PoPs estão presentes em mais de 180 trocas de Internet e em mais de 160 instalações de interconexão em todo o mundo.

Para ver como os PoPs ajudam a fornecer APIs de elevado desempenho quando usa o Apigee com a CDN da Google Cloud para realizar o seguinte, veja o vídeo Fornecer APIs de elevado desempenho com o Apigee e a CDN da Google Cloud no YouTube:

• Reduzir a latência.
• Alojamento de APIs a nível global.
• Aumente a disponibilidade para o pico de tráfego.

O exemplo de design ilustrado no diagrama anterior baseia-se no Private Service Connect sem intercâmbio de VPC.

A rede de saída neste design é estabelecida através do seguinte:

• Um balanceador de carga (LB no diagrama), onde os pedidos do cliente terminam, processa o tráfego e, em seguida, encaminha-o para um back-end do Private Service Connect.
• Um back-end do Private Service Connect permite que um balanceador de carga envie pedidos de clientes através de uma ligação do Private Service Connect associada a uma associação do serviço do produtor ao serviço publicado (instância de tempo de execução do Apigee) através de grupos de pontos finais da rede (NEGs) do Private Service Connect. Google Cloud

A rede de saída é estabelecida através do seguinte:

• Um ponto final do Private Service Connect que faz referência a uma associação de serviço associada a um balanceador de carga interno (ILB no diagrama) na VPC do cliente.

• O ILB é implementado com grupos de pontos finais de rede de conetividade híbrida (NEGs de conetividade híbrida).

• Os serviços híbridos são acedidos através do NEG de conetividade híbrida através de uma conetividade de rede híbrida, como uma VPN ou o Cloud Interconnect.

Para mais informações, consulte os artigos Configure um balanceador de carga de rede de proxy interno regional com conetividade híbrida e Padrões de implementação do Private Service Connect.

Nota: consoante os seus requisitos, as APIs dos back-ends no local podem ser expostas através do Apigee Hybrid, um gateway de API ou um proxy de terceiros, ou um equilibrador de carga.

Exponha serviços remotos através do Private Service Connect

Use a opção Private Service Connect para expor serviços remotos nos seguintes cenários:

• Não está a usar uma plataforma de API ou quer evitar ligar toda a sua rede VPC diretamente a um ambiente externo pelos seguintes motivos:
  • Tem restrições de segurança ou requisitos de conformidade.
  • Tem uma sobreposição de intervalo de endereços IP, como num cenário de fusão e aquisição.
• Para ativar comunicações unidirecionais seguras entre clientes, aplicações e serviços nos ambientes, mesmo quando tem um prazo curto.
• Pode ter de fornecer conetividade a várias VPCs de consumidor através de uma VPC de produtor de serviços (VPC de trânsito) para oferecer modelos de serviços multi-inquilinos ou de inquilino único altamente escaláveis, para alcançar serviços publicados noutros ambientes.

A utilização do Private Service Connect para aplicações consumidas como APIs fornece um endereço IP interno para as aplicações publicadas, o que permite o acesso seguro na rede privada em regiões e através da conetividade híbrida. Esta abstração facilita a integração de recursos de diversas nuvens e ambientes nas instalações através de um modelo de conetividade híbrido e de várias nuvens. Pode acelerar a integração de aplicações e expor aplicações em segurança que residam num ambiente no local ou noutro ambiente de nuvem através do Private Service Connect para publicar o serviço com acesso detalhado. Neste caso, pode usar a seguinte opção:

• Uma associação de serviço que faz referência a um Network Load Balancer de proxy interno regional ou a um Application Load Balancer interno.
  • O equilibrador de carga usa um grupo de pontos finais de rede híbrida (NEG de conetividade híbrida) numa VPC de produtor que atua neste design como uma VPC de trânsito.

No diagrama anterior, as cargas de trabalho na rede VPC da sua aplicação podem alcançar os serviços híbridos em execução no seu ambiente nas instalações ou noutros ambientes na nuvem através do ponto final do Private Service Connect, conforme ilustrado no diagrama seguinte. Esta opção de design para comunicações unidirecionais oferece uma opção alternativa ao intercâmbio com uma VPC de trânsito.

Como parte do design no diagrama anterior, vários front-ends, back-ends ou pontos finais podem ligar-se à mesma associação de serviços, o que permite que várias redes VPC ou vários consumidores acedam ao mesmo serviço. Conforme ilustrado no diagrama seguinte, pode tornar a aplicação acessível a várias VPCs. Esta acessibilidade pode ajudar em cenários de serviços multiinquilinos em que o seu serviço é consumido por várias VPCs de consumidores, mesmo que os respetivos intervalos de endereços IP se sobreponham.

A sobreposição de endereços IP é um dos problemas mais comuns ao integrar aplicações que residem em ambientes diferentes. A ligação do Private Service Connect no diagrama seguinte ajuda a evitar o problema de sobreposição de endereços IP. Isto é feito sem necessidade de aprovisionamento nem gestão de componentes de rede adicionais, como o Cloud NAT ou uma NVA, para realizar a tradução de endereços IP. Para ver um exemplo de configuração, consulte o artigo Publique um serviço híbrido através do Private Service Connect.

O design tem as seguintes vantagens:

• Evita potenciais dependências de escalabilidade partilhadas e capacidade de gestão complexa em grande escala.
• Melhora a segurança através do controlo detalhado da conetividade.
• Reduz a coordenação de endereços IP entre o produtor e o consumidor do serviço e o ambiente externo remoto.

A abordagem de design no diagrama anterior pode ser expandida em fases posteriores para integrar o Apigee como a plataforma de API através das opções de design de rede abordadas anteriormente, incluindo a opção Private Service Connect.

Pode tornar o ponto final do Private Service Connect acessível a partir de outras regiões através do acesso global do Private Service Connect.

O cliente que se liga ao ponto final do Private Service Connect pode estar na mesma região que o ponto final ou numa região diferente. Esta abordagem pode ser usada para oferecer alta disponibilidade em serviços alojados em várias regiões ou para aceder a serviços disponíveis numa única região a partir de outras regiões. Quando um ponto final do Private Service Connect é acedido por recursos alojados noutras regiões, são aplicadas cobranças de saída inter-regionais ao tráfego destinado a pontos finais com acesso global.

Nota: para alcançar verificações de bem-estar distribuídas e facilitar a ligação de várias VPCs a ambientes no local através de várias ligações híbridas, encadeie um Application Load Balancer interno com um Application Load Balancer externo. Para mais informações, consulte o artigo Encadeamento explícito de Google Cloud balanceadores de carga de nível 7 com o PSC.

Práticas recomendadas

• Considerar o Apigee e o Apigee Hybrid como a sua solução de plataforma de API oferece várias vantagens. Fornece uma camada de proxy e uma abstração ou fachada para as APIs de serviços de back-end combinadas com capacidades de segurança, limitação de taxas, quotas e estatísticas.
  • Use o Apigee Adapter for Envoy com uma arquitetura de implementação do Apigee Hybrid com o Kubernetes, quando aplicável aos seus requisitos e à arquitetura.
• As VPCs e a conceção do projeto Google Cloud devem ser orientadas pela sua hierarquia de recursos e pelos requisitos do modelo de comunicação segura.
• Quando são usadas APIs com gateways de API, também deve usar uma lista de autorizações de endereços IP. Uma lista de autorizações limita as comunicações aos endereços IP específicos de origens e destinos dos consumidores de API e gateways de API que podem estar alojados em ambientes diferentes.
• Use regras de firewall da VPC ou políticas de firewall para controlar o acesso aos recursos do Private Service Connect através do ponto final do Private Service Connect.
• Se uma aplicação estiver exposta externamente através de um balanceador de carga de aplicações, considere usar o Google Cloud Armor como uma camada adicional de segurança para proteção contra DDoS e ameaças de segurança da camada de aplicação.

• Se as instâncias precisarem de acesso à Internet, use o Cloud NAT na VPC da aplicação (consumidor) para permitir que as cargas de trabalho acedam à Internet. Desta forma, evita atribuir endereços IP públicos externos a instâncias de VM em sistemas implementados atrás de um gateway de API ou um equilibrador de carga.

  • Para o tráfego Web de saída, pode usar o Google Cloud Secure Web Proxy. O proxy oferece várias vantagens.

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

Entrada restrita

A arquitetura do padrão de entrada restrita baseia-se na exposição de APIs selecionadas de cargas de trabalho em execução no ambiente de computação privado sem as expor à Internet pública. Google Cloud Este padrão é a contrapartida do padrão de saída restrita e é adequado para cenários de híbrido de limite, híbrido hierárquico e multinuvem particionada.

Tal como no padrão de saída controlada, pode facilitar esta exposição limitada através de um gateway de API ou um equilibrador de carga que sirva de fachada para cargas de trabalho ou serviços existentes. Deste modo, torna-o acessível a ambientes de computação privados, ambientes nas instalações ou noutro ambiente de nuvem, da seguinte forma:

• As cargas de trabalho que implementa no ambiente de computação privada ou noutros ambientes de nuvem podem comunicar com o gateway de API ou o balanceador de carga através de endereços IP internos. Não é possível aceder a outros sistemas implementados emGoogle Cloud .
• A comunicação de Google Cloud para o ambiente de computação privado ou para outros ambientes de nuvem não é permitida. O tráfego só é iniciado a partir do ambiente privado ou de outros ambientes na nuvem para as APIs em Google Cloud.

Arquitetura

O diagrama seguinte mostra uma arquitetura de referência que cumpre os requisitos do padrão de entrada restrita.

A descrição da arquitetura no diagrama anterior é a seguinte:

• No lado Google Cloud , implementa cargas de trabalho numa VPC de aplicação (ou várias VPCs).
• A rede do ambiente Google Cloud estende-se a outros ambientes de computação (nas instalações ou noutra nuvem) através da conetividade de rede híbrida ou multinuvem para facilitar a comunicação entre ambientes.
• Opcionalmente, pode usar uma VPC de trânsito para realizar o seguinte:
  • Forneça camadas de segurança de perímetro adicionais para permitir o acesso a APIs específicas fora da VPC da sua aplicação.
  • Encaminhe o tráfego para os endereços IP das APIs. Pode criar regras de firewall da VPC para impedir que algumas origens acedam a determinadas APIs através de um ponto final.
  • Inspecione o tráfego da camada 7 na VPC de trânsito integrando um dispositivo virtual de rede (NVA).
• Aceda às APIs através de um gateway de API ou de um equilibrador de carga (proxy ou equilibrador de carga da aplicação) para fornecer uma camada de proxy e uma camada de abstração ou fachada para as APIs de serviço. Se precisar de distribuir o tráfego por várias instâncias do gateway de API, pode usar um Network Load Balancer de encaminhamento interno.
• Forneça acesso limitado e detalhado a um serviço publicado através de um ponto final do Private Service Connect usando um balanceador de carga através do Private Service Connect para expor uma aplicação ou um serviço.
• Todos os ambientes devem usar um espaço de endereço IP RFC 1918 sem sobreposição.

O diagrama seguinte ilustra a conceção deste padrão através do Apigee como plataforma de API.

No diagrama anterior, a utilização do Apigee como plataforma de API oferece as seguintes funcionalidades e capacidades para ativar o padrão de entrada controlada:

• Funcionalidade de gateway ou proxy
• Capacidades de segurança
• Limitação de velocidade
• Google Analytics

No design:

• A conetividade de rede no sentido ascendente (para tráfego proveniente de outros ambientes) passa por um ponto final do Private Service Connect na VPC da sua aplicação que está associado à VPC do Apigee.
• Na VPC da aplicação, é usado um balanceador de carga interno para expor as APIs da aplicação através de um ponto final do Private Service Connect apresentado na VPC do Apigee. Para mais informações, consulte o artigo Arquitetura com o peering de VPC desativado.

• Configure regras de firewall e filtragem de tráfego na VPC da aplicação. Ao fazê-lo, concede um acesso detalhado e controlado. Também ajuda a impedir que os sistemas alcancem diretamente as suas aplicações sem passar pelo ponto final do Private Service Connect e pela gateway de API.

  Além disso, pode restringir o anúncio da sub-rede de endereços IP internos da carga de trabalho de back-end na VPC da aplicação à rede no local para evitar a acessibilidade direta sem passar pelo ponto final do Private Service Connect e pela gateway de API.

Determinados requisitos de segurança podem exigir a inspeção de segurança do perímetro fora da VPC da aplicação, incluindo o tráfego de conetividade híbrida. Nestes casos, pode incorporar uma VPC de trânsito para implementar camadas de segurança adicionais. Estas camadas, como NVAs de firewalls de próxima geração (NGFWs) com várias interfaces de rede ou o firewall de próxima geração do Google Cloud Enterprise com serviço de prevenção de intrusões (IPS), realizam uma inspeção detalhada de pacotes fora da VPC da sua aplicação, conforme ilustrado no diagrama seguinte:

Conforme ilustrado no diagrama anterior:

• A conetividade de rede no sentido ascendente (para tráfego proveniente de outros ambientes) passa por uma VPC de trânsito separada em direção ao ponto final do Private Service Connect na VPC de trânsito associada à VPC do Apigee.
• Na VPC da aplicação, é usado um balanceador de carga interno (ILB no diagrama) para expor a aplicação através de um ponto final do Private Service Connect na VPC do Apigee.

Pode aprovisionar vários pontos finais na mesma rede VPC, conforme mostrado no diagrama seguinte. Para abranger diferentes exemplos de utilização, pode controlar os diferentes caminhos de rede possíveis através do Cloud Router e das regras de firewall da VPC. Por exemplo, se estiver a ligar a sua rede no local a Google Cloud através de várias ligações de rede híbrida, pode enviar algum tráfego do local para APIs Google específicas ou serviços publicados através de uma ligação e o resto através de outra ligação. Além disso, pode usar o acesso global do Private Service Connect para fornecer opções de comutação por falha.

Variantes

O padrão de arquitetura de entrada restrita 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. O padrão oferece as seguintes opções:

• Aceda às APIs Google a partir de outros ambientes

• Exponha back-ends de aplicações a outros ambientes através do Private Service Connect

• Use uma arquitetura de hub e spoke para expor back-ends de aplicações a outros ambientes

Aceda às APIs Google a partir de outros ambientes

Para cenários que requerem acesso a serviços Google, como o Cloud Storage ou o BigQuery, sem enviar tráfego através da Internet pública, o Private Service Connect oferece uma solução. Conforme mostrado no diagrama seguinte, permite a acessibilidade às APIs Google suportadas e aos serviços (incluindo o Google Maps, o Google Ads e oGoogle Cloud) a partir de ambientes no local ou noutras nuvens através de uma ligação de rede híbrida com o endereço IP do ponto final do Private Service Connect. Para mais informações sobre o acesso às APIs Google através de pontos finais do Private Service Connect, consulte o artigo Acerca do acesso às APIs Google através de pontos finais.

No diagrama anterior, a sua rede no local tem de estar ligada à rede VPC de trânsito (consumidor) através de túneis do Cloud VPN ou de uma ligação VLAN do Cloud Interconnect.

As APIs Google podem ser acedidas através de pontos finais ou servidores de back-end. Os pontos finais permitem segmentar um pacote de APIs Google. Os backends permitem segmentar uma API Google regional específica.

Nota: os pontos finais do Private Service Connect estão registados no Service Directory para APIs Google, onde pode armazenar, gerir e publicar serviços.

Exponha back-ends de aplicações a outros ambientes através do Private Service Connect

Em cenários específicos, conforme realçado pelo padrão híbrido hierárquico, pode ter de implementar back-ends em Google Cloud , ao mesmo tempo que mantém os front-ends em ambientes de computação privados. Embora menos comum, esta abordagem é aplicável quando se lida com frontends pesados e monolíticos que podem depender de componentes antigos. Em alternativa, mais frequentemente, quando gere aplicações distribuídas em vários ambientes, incluindo no local e noutras nuvens, que requerem conetividade a back-ends alojados na Google Cloud nuvem híbrida.

Nesta arquitetura, pode usar um gateway de API local ou um equilibrador de carga no ambiente privado nas instalações ou noutros ambientes de nuvem para expor diretamente o frontend da aplicação à Internet pública. A utilização do Private Service Connect no Google Cloud facilita a conetividade privada aos back-ends expostos através de um ponto final do Private Service Connect, idealmente através de APIs predefinidas, conforme ilustrado no diagrama seguinte:

O design no diagrama anterior usa uma implementação do Apigee Hybrid que consiste num plano de gestão no Google Cloud e num plano de runtime alojado no seu outro ambiente. Pode instalar e gerir o plano de execução numa gateway de API distribuída numa das plataformas Kubernetes suportadas no seu ambiente no local ou noutros ambientes de nuvem. Com base nos seus requisitos para cargas de trabalho distribuídas em vários ambientes, pode usar o Apigee no Google Cloud com o Apigee Hybrid. Google Cloud Google Cloud Para mais informações, consulte o artigo Gateways de API distribuídos.

Use uma arquitetura de hub and spoke para expor backends de aplicações a outros ambientes

A exposição de APIs de backends de aplicações alojados em Google Cloud em diferentes redes VPC pode ser necessária em determinados cenários. Conforme ilustrado no diagrama seguinte, uma VPC de hub serve como um ponto central de interligação para as várias VPCs (raios), permitindo a comunicação segura através da conetividade híbrida privada. Opcionalmente, podem ser usadas capacidades de gateway de API local noutros ambientes, como o Apigee Hybrid, para terminar pedidos de clientes localmente onde o front-end da aplicação está alojado.

Conforme ilustrado no diagrama anterior:

• Para oferecer capacidades de inspeção da camada 7 da NGFW adicionais, a NVA com capacidades de NGFW é integrada opcionalmente no design. Pode ser necessário ter estas capacidades para agir em conformidade com requisitos de segurança específicos e as normas da política de segurança da sua organização.

• Esta conceção pressupõe que as VPCs spoke não requerem comunicação direta de VPC para VPC.

  • Se for necessária a comunicação entre raios, pode usar o NVA para facilitar essa comunicação.
  • Se tiver diferentes back-ends em diferentes VPCs, pode usar o Private Service Connect para expor estes back-ends à VPC do Apigee.
  • Se o peering de VPC for usado para a conetividade a montante e a jusante entre VPCs spoke e a VPC hub, tem de considerar a limitação de transitividade da rede VPC através do peering de VPC. Para ultrapassar esta limitação, pode usar qualquer uma das seguintes opções:
    • Para interligar as VPCs, use uma NVA.
    • Quando aplicável, considere o modelo do Private Service Connect.
    • Para estabelecer a conetividade entre a VPC do Apigee e os back-ends localizados noutrosGoogle Cloud projetos na mesma organização sem componentes de rede adicionais, use a VPC partilhada.

• Se forem necessárias NVAs para a inspeção de tráfego, incluindo o tráfego dos seus outros ambientes, a conetividade híbrida a ambientes nas instalações ou outros ambientes na nuvem deve ser terminada na VPC de trânsito híbrida.

• Se o design não incluir a NVA, pode terminar a conetividade híbrida na VPC do hub.

• Se forem necessárias determinadas funcionalidades de balanceamento de carga ou capacidades de segurança, como adicionar a proteção DDoS ou o WAF do Google Cloud Armor, pode implementar opcionalmente um balanceador de carga de aplicações externo no perímetro através de uma VPC externa antes de encaminhar pedidos de clientes externos para os back-ends.

Práticas recomendadas

• Para situações em que os pedidos de clientes da Internet têm de ser recebidos localmente por um front-end alojado num ambiente privado no local ou noutro ambiente de nuvem, considere usar o Apigee Hybrid como uma solução de gateway de API. Esta abordagem também facilita uma migração simples da solução para um ambiente totalmente Google Cloudalojado, mantendo a consistência da plataforma de API (Apigee).
• Use o Apigee Adapter for Envoy com uma arquitetura de implementação do Apigee Hybrid com o Kubernetes, quando aplicável aos seus requisitos e à arquitetura.
• A conceção de VPCs e projetos no Google Cloud deve seguir os requisitos da hierarquia de recursos e do modelo de comunicação segura, conforme descrito neste guia.
• A incorporação de uma VPC de trânsito neste design oferece a flexibilidade de aprovisionar medidas de segurança de perímetro adicionais e conectividade híbrida fora da VPC da carga de trabalho.
• Use o Private Service Connect para aceder às APIs e aos serviços Google a partir de ambientes no local ou de outros ambientes na nuvem através do endereço IP interno do ponto final numa rede de conetividade híbrida. Para mais informações, consulte o artigo Aceda ao ponto final a partir de anfitriões no local.
• Para ajudar a proteger os serviços nos seus projetos e 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. Google Cloud
  • Quando necessário, pode estender os perímetros de serviço a um ambiente híbrido através de uma VPN ou do Cloud Interconnect. Para mais informações sobre as vantagens dos perímetros de serviço, consulte a Vista geral dos VPC Service Controls.
• Use regras de firewall da VPC ou políticas de firewall para controlar o acesso ao nível da rede aos recursos do Private Service Connect através do ponto final do Private Service Connect. Por exemplo, as regras de firewall de saída na VPC da aplicação (consumidor) podem restringir o acesso das instâncias de VM ao endereço IP ou à sub-rede dos seus pontos finais. Para mais informações sobre as regras de firewall da VPC em geral, consulte o artigo Regras de firewall da VPC.
• 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 design de HA e redundância fornecidas pelo fornecedor da NVA.
• Para reforçar a segurança do perímetro e proteger o gateway de API implementado no ambiente respetivo, pode implementar opcionalmente mecanismos de equilíbrio de carga e firewall de aplicações Web no seu outro ambiente de computação (híbrido ou outra nuvem). Implemente estas opções na rede de perímetro que está diretamente ligada à Internet.
• Se as instâncias precisarem de acesso à Internet, use o Cloud NAT na VPC da aplicação para permitir que as cargas de trabalho acedam à Internet. Ao fazê-lo, pode evitar atribuir instâncias de VMs com endereços IP públicos externos em sistemas implementados atrás de um gateway de API ou um equilibrador de carga.
• Para o tráfego Web de saída, use o Secure Web Proxy. O proxy oferece várias vantagens.
• Reveja as práticas recomendadas gerais para padrões de rede híbridos e multicloud.

Saída controlada e entrada controlada

O padrão de saída controlada e entrada controlada usa uma combinação de saída controlada e entrada controlada para cenários que exigem a utilização bidirecional de APIs selecionadas entre cargas de trabalho. As cargas de trabalho podem ser executadas no Google Cloud, em ambientes privados no local ou noutros ambientes de nuvem. Neste padrão, pode usar gateways de API, pontos finais do Private Service Connect ou balanceadores de carga para expor APIs específicas e, opcionalmente, fornecer autenticação, autorização e auditorias de chamadas de API.

A principal distinção entre este padrão e o padrão de malha reside na sua aplicação a cenários que requerem apenas a utilização da API bidirecional ou a comunicação com origens e destinos de endereços IP específicos, por exemplo, uma aplicação publicada através de um ponto final do Private Service Connect. Uma vez que a comunicação está restrita às APIs expostas ou a endereços IP específicos, as redes nos ambientes não têm de estar alinhadas no seu design. Os cenários aplicáveis comuns incluem, entre outros:

• Fusões e aquisições.
• Integrações de aplicações com parceiros.
• Integrações entre aplicações e serviços de uma organização com diferentes unidades organizacionais que gerem as suas próprias aplicações e as alojam em diferentes ambientes.

A comunicação funciona da seguinte forma:

• As cargas de trabalho que implementar no Google Cloud podem comunicar com o gateway de API (ou endereços IP de destino específicos) através de endereços IP internos. Não é possível aceder a outros sistemas implementados no ambiente de computação privado.
• Por outro lado, as cargas de trabalho que implementa noutros ambientes de computação podem comunicar com o gateway de API do lado Google Cloud(ou um endereço IP de ponto final publicado específico) através de endereços IP internos. Não é possível contactar outros sistemas implementados em Google Cloud .

Arquitetura

O diagrama seguinte mostra uma arquitetura de referência para o padrão de saída controlada e entrada controlada:

A abordagem de design no diagrama anterior tem os seguintes elementos:

• No Google Cloud lado, implementa cargas de trabalho numa VPC (ou numa VPC partilhada) sem as expor diretamente à Internet.
• A rede do ambiente Google Cloud é expandida para outros ambientes de computação. Esse ambiente pode estar no local ou noutra nuvem. Para expandir o ambiente, use um padrão de comunicação de conetividade híbrida e multinuvem adequado para facilitar a comunicação entre ambientes, para que possam usar endereços IP internos.
• Opcionalmente, ao ativar o acesso a endereços IP de destino específicos, pode usar uma VPC de trânsito para ajudar a adicionar uma camada de segurança de perímetro fora da VPC da aplicação.
  • Pode usar a firewall de nova geração do Google Cloud ou os dispositivos virtuais de rede (NVAs) com firewalls de nova geração (NGFWs) na VPC de trânsito para inspecionar o tráfego e permitir ou proibir o acesso a determinadas APIs a partir de origens específicas antes de chegar à VPC da aplicação.
• As APIs devem ser acedidas através de um gateway de API ou de um equilibrador de carga para fornecer uma camada de proxy e uma abstração ou uma fachada para as APIs de serviço.
• Para aplicações consumidas como APIs, também pode usar o Private Service Connect para fornecer um endereço IP interno para a aplicação publicada.
• Todos os ambientes usam um espaço de endereço IP RFC 1918 sem sobreposição.

Uma aplicação comum deste padrão envolve a implementação de back-ends de aplicações (ou um subconjunto de back-ends de aplicações) no Google Cloud , enquanto aloja outros componentes de back-end e front-end em ambientes nas instalações ou noutras nuvens (padrão híbrido em camadas ou padrão multinuvem particionada). À medida que as aplicações evoluem e migram para a nuvem, surgem frequentemente dependências e preferências por serviços na nuvem específicos.

Por vezes, estas dependências e preferências levam à distribuição de aplicações e backends por diferentes fornecedores de nuvem. Além disso, algumas aplicações podem ser criadas com uma combinação de recursos e serviços distribuídos por ambientes nas instalações e vários ambientes na nuvem.

Para aplicações distribuídas, as capacidades de conetividade híbrida e multicloud do Cloud Load Balancing externo podem ser usadas para terminar pedidos de utilizadores e encaminhá-los para front-ends ou back-ends noutros ambientes. Este encaminhamento ocorre através de uma ligação de rede híbrida, conforme ilustrado no diagrama seguinte. Esta integração permite a distribuição gradual de componentes da aplicação em diferentes ambientes. Os pedidos do front-end para os serviços de back-end alojados no Google Cloud comunicamde forma segura através da ligação de rede híbrida estabelecida facilitada por um balanceador de carga interno (ILB no diagrama).

A utilização do Google Cloud design no diagrama anterior ajuda com o seguinte:

• Facilita a comunicação bidirecional entre Google Cloud, nas instalações e outros ambientes na nuvem através de APIs predefinidas em ambos os lados que se alinham com o modelo de comunicação deste padrão.
• Para fornecer front-ends globais para aplicações viradas para a Internet com componentes de aplicações distribuídos (front-ends ou back-ends) e para alcançar os seguintes objetivos, pode usar as capacidades avançadas de equilíbrio de carga e segurança Google Cloud distribuídas em pontos de presença (PoPs):
• Reduza as despesas de capital e simplifique as operações através de serviços geridos sem servidor.
• Otimize as ligações aos back-ends das aplicações a nível global para melhorar a velocidade e a latência.
  • Google Cloud A rede entre clouds permite a comunicação entre várias clouds entre componentes de aplicações através de ligações privadas ideais.
• Coloque em cache conteúdo estático de elevada procura e melhore o desempenho das aplicações que usam o Cloud Load Balancing global, fornecendo acesso ao Cloud CDN.
• Proteja os front-ends globais das aplicações viradas para a Internet usando as capacidades do Google Cloud Armor que oferecem distribuição global de firewall de aplicação Web (WAF) e serviços de mitigação de DDoS.
• Opcionalmente, pode incorporar o Private Service Connect no seu design. Ao fazê-lo, permite o acesso privado e detalhado às APIs de serviços ou aos seus serviços publicados a partir de outros ambientes sem atravessar a Internet pública. Google Cloud

Variantes

Os padrões de arquitetura de saída restrita e entrada restrita podem ser combinados com outras abordagens para cumprir diferentes requisitos de design, ao mesmo tempo que consideram os requisitos de comunicação deste padrão. Os padrões oferecem as seguintes opções:

• Gateways de API distribuídos
• Comunicação API bidirecional através do Private Service Connect
• Comunicação bidirecional através de pontos finais e interfaces do Private Service Connect

Gateways de API distribuídos

Em cenários como o baseado no padrão de multicloud particionado, as aplicações (ou os componentes das aplicações) podem ser criadas em diferentes ambientes de nuvem, incluindo um ambiente privado no local. O requisito comum é encaminhar os pedidos do cliente para o front-end da aplicação diretamente para o ambiente onde a aplicação (ou o componente de front-end) está alojada. Este tipo de comunicação requer um equilibrador de carga local ou um gateway de API. Estas aplicações e os respetivos componentes também podem exigir capacidades específicas da plataforma de API para integração.

O diagrama seguinte ilustra como o Apigee e o Apigee Hybrid são concebidos para satisfazer esses requisitos com um gateway de API localizado em cada ambiente. A gestão da plataforma de API está centralizada no Google Cloud. Este design ajuda a aplicar medidas de controlo de acesso rigorosas em que apenas os endereços IP pré-aprovados (APIs de destino e de destino ou endereços IP do ponto final do Private Service Connect) podem comunicar entre si e os outros ambientes. Google Cloud

A lista seguinte descreve os dois caminhos de comunicação distintos no diagrama anterior que usam o gateway de API do Apigee:

• Os pedidos do cliente chegam ao frontend da aplicação diretamente no ambiente que aloja a aplicação (ou o componente de frontend).
• Os gateways de API e os proxies em cada ambiente processam os pedidos de API de clientes e aplicações em direções diferentes em vários ambientes.
  • A funcionalidade de gateway de API no Google Cloud (Apigee) expõe os componentes da aplicação (frontend ou backend) que estão alojados no Google Cloud.
  • A funcionalidade de gateway de API noutro ambiente (híbrido) expõe os componentes de frontend (ou backend) da aplicação alojados nesse ambiente.

Opcionalmente, pode considerar usar uma VPC de trânsito. Uma VPC de trânsito pode oferecer flexibilidade para separar preocupações e realizar inspeção de segurança e conetividade híbrida numa rede VPC separada. Do ponto de vista da acessibilidade do endereço IP, uma VPC de trânsito (onde a conetividade híbrida está anexada) facilita os seguintes requisitos para manter a acessibilidade ponto a ponto:

• Os endereços IP das APIs de destino têm de ser anunciados aos outros ambientes onde os clientes/requisitantes estão alojados.
• Os endereços IP dos anfitriões que precisam de comunicar com as APIs de destino têm de ser anunciados ao ambiente onde a API de destino reside, por exemplo, os endereços IP do requerente da API (o cliente). A exceção ocorre quando a comunicação é feita através de um balanceador de carga, um proxy, um ponto final do Private Service Connect ou uma instância de NAT.

Para estender a conetividade ao ambiente remoto, esta conceção usa o peering de VPC direto com a capacidade de troca de rotas do cliente. O design permite que pedidos de API específicos originários de cargas de trabalho alojadas na VPC da aplicação sejam encaminhados através da VPC de trânsito. Google Cloud Em alternativa, pode usar um ponto final do Private Service Connect na VPC da aplicação associada a um balanceador de carga com um back-end do grupo de pontos finais da rede híbrida na VPC de trânsito. Essa configuração é descrita na secção seguinte: comunicação API bidirecional através do Private Service Connect.

Comunicação API bidirecional através do Private Service Connect

Por vezes, as empresas podem não precisar de usar um gateway de API (como o Apigee) imediatamente ou podem querer adicioná-lo mais tarde. No entanto, podem existir requisitos empresariais para ativar a comunicação e a integração entre determinadas aplicações em diferentes ambientes. Por exemplo, se a sua empresa adquiriu outra empresa, pode ter de expor determinadas aplicações a essa empresa. Podem ter de expor aplicações à sua empresa. Ambas as empresas podem ter as suas próprias cargas de trabalho alojadas em ambientes diferentes (Google Cloud, no local ou noutras nuvens) e têm de evitar a sobreposição de endereços IP. Nesses casos, pode usar o Private Service Connect para facilitar a comunicação eficaz.

Para aplicações consumidas como APIs, também pode usar o Private Service Connect para fornecer um endereço privado para as aplicações publicadas, o que permite o acesso seguro na rede privada em regiões e através da conetividade híbrida. Esta abstração facilita a integração de recursos de diversas nuvens e ambientes nas instalações através de um modelo de conetividade híbrido e de várias nuvens. Também permite a montagem de aplicações em ambientes de várias nuvens e nas instalações. Isto pode satisfazer diferentes requisitos de comunicação, como a integração de aplicações seguras onde não é usado ou não está planeado usar um gateway de API.

Ao usar o Private Service Connect com o Cloud Load Balancing, conforme mostrado no diagrama seguinte, pode alcançar dois caminhos de comunicação distintos. Cada caminho é iniciado a partir de uma direção diferente para um objetivo de conetividade separado, idealmente através de chamadas API.

• Todas as considerações de design e recomendações do Private Service Connect abordadas neste guia aplicam-se a este design.
• Se for necessária uma inspeção de camada 7 adicional, pode integrar NVAs com esta conceção (na VPC de trânsito).
• Este design pode ser usado com ou sem gateways de API.

Os dois caminhos de conetividade representados no diagrama anterior representam ligações independentes e não ilustram a comunicação bidirecional de uma única ligação ou fluxo.

Comunicação bidirecional através de pontos finais e interfaces do Private Service Connect

Conforme abordado no padrão de entrada controlada, uma das opções para ativar a comunicação cliente-serviço é usar um ponto final do Private Service Connect para expor um serviço numa VPC de produção a uma VPC de consumo. Essa conetividade pode ser estendida a um ambiente nas instalações ou até mesmo a outro ambiente de fornecedor de nuvem através de uma conetividade híbrida. No entanto, em alguns cenários, o serviço alojado também pode exigir comunicação privada.

Para aceder a um determinado serviço, como obter dados de origens de dados que podem ser alojados na VPC do consumidor ou fora dela, esta comunicação privada pode ser entre a VPC da aplicação (produtor) e um ambiente remoto, como um ambiente no local.

Neste cenário, as interfaces do Private Service Connect permitem que uma instância de VM de produtor de serviços aceda à rede de um consumidor. Isto é feito através da partilha de uma interface de rede, mantendo a separação das funções de produtor e consumidor. Com esta interface de rede na VPC do consumidor, a VM da aplicação pode aceder aos recursos do consumidor como se estivessem localmente na VPC do produtor.

Uma interface do Private Service Connect é uma interface de rede associada à VPC do consumidor (trânsito). É possível alcançar destinos externos acessíveis a partir da VPC (trânsito) do consumidor à qual a interface do Private Service Connect está anexada. Por conseguinte, esta ligação pode ser estendida a um ambiente externo através de uma conetividade híbrida, como um ambiente no local, conforme ilustrado no seguinte diagrama:

Se a VPC do consumidor for uma organização ou uma entidade externa, como uma organização de terceiros, normalmente, não tem a capacidade de proteger a comunicação com a interface do Private Service Connect na VPC do consumidor. Neste cenário, pode definir políticas de segurança no SO convidado da VM da interface do Private Service Connect. Para mais informações, consulte Configure a segurança para interfaces do Private Service Connect. Em alternativa, pode considerar uma abordagem alternativa se não estiver em conformidade com a conformidade ou as normas de segurança da sua organização.

Práticas recomendadas

• Para situações em que os pedidos de clientes da Internet têm de ser recebidos localmente por um front-end alojado num ambiente privado no local ou noutro ambiente de nuvem, considere usar o Hybrid como uma solução de gateway de API.

  • Esta abordagem também facilita a migração da solução para um ambiente totalmente alojado, mantendo a consistência da plataforma de API (Apigee). Google Cloud

• Para minimizar a latência e otimizar os custos para volumes elevados de transferências de dados de saída para os seus outros ambientes quando esses ambientes estão em configurações híbridas ou multicloud permanentes ou de longo prazo, considere o seguinte:

  • Use o Cloud Interconnect ou o Cross-Cloud Interconnect.
  • Para terminar as ligações de utilizadores no front-end segmentado no ambiente adequado, use o híbrido.

• Quando aplicável aos seus requisitos e à arquitetura, use o adaptador do Apigee para o Envoy com uma implementação híbrida com o Kubernetes.

• Antes de conceber os caminhos de conetividade e encaminhamento, primeiro tem de identificar que tráfego ou pedidos de API têm de ser direcionados para um gateway de API local ou remoto, juntamente com os ambientes de origem e destino.

• Use os VPC Service Controls para proteger os Google Cloud serviços nos seus projetos e mitigar o risco de exfiltração de dados, especificando perímetros de serviço ao nível do projeto ou da rede VPC.

  • 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 sobre as vantagens dos perímetros de serviço, consulte a Vista geral dos VPC Service Controls.

• Use as regras de firewall da nuvem virtual privada (VPC) ou as políticas de firewall para controlar o acesso ao nível da rede aos recursos do Private Service Connect através do ponto final do Private Service Connect. Por exemplo, as regras de firewall de saída na VPC da aplicação (consumidor) podem restringir o acesso das instâncias de VM ao endereço IP ou à sub-rede dos seus pontos finais.

• Quando usar uma interface do Private Service Connect, tem de proteger a comunicação com a interface configurando a segurança da interface do Private Service Connect.

• Se uma carga de trabalho numa sub-rede privada precisar de acesso à Internet, use o Cloud NAT para evitar atribuir um endereço IP externo à carga de trabalho e expô-la à Internet pública.

  • Para o tráfego Web de saída, use o Secure Web Proxy. O proxy oferece várias vantagens.

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

Padrões de transferência

Com o padrão de transferência, a arquitetura baseia-se na utilização de serviços de armazenamento fornecidos pelaGoogle Cloudpara ligar um ambiente de computação privado a projetos no Google Cloud. Este padrão aplica-se principalmente a configurações que seguem o padrão de arquitetura multinuvem híbrida de estatísticas, em que:

• Os fluxos de trabalho que estão a ser executados num ambiente de computação privado ou noutro ambiente de nuvem carregam dados para localizações de armazenamento partilhadas. Consoante os exemplos de utilização, os carregamentos podem ocorrer em massa ou em incrementos mais pequenos.
• Google Cloud- As cargas de trabalho alojadas ou outros serviços Google (por exemplo, serviços de análise de dados e inteligência artificial) consomem dados das localizações de armazenamento partilhadas e processam-nos de forma de streaming ou em lote.

Arquitetura

O diagrama seguinte mostra uma arquitetura de referência para o padrão de transferência.

O diagrama de arquitetura anterior mostra os seguintes fluxos de trabalho:

• No Google Cloud lado, implementa cargas de trabalho numa VPC de aplicação. Estas cargas de trabalho podem incluir processamento de dados, estatísticas e aplicações de front-end relacionadas com estatísticas.
• Para expor aplicações de front-end aos utilizadores de forma segura, pode usar o Cloud Load Balancing ou o API Gateway.
• Um conjunto de contentores do Cloud Storage ou filas do Pub/Sub carregam dados do ambiente de computação privado e disponibilizam-nos para processamento adicional por cargas de trabalho implementadas no Google Cloud. Através das políticas de gestão de identidade e de acesso (IAM), pode restringir o acesso a cargas de trabalho fidedignas.
• Use os VPC Service Controls para restringir o acesso aos serviços e minimizar os riscos de exfiltração de dados injustificados dos Google Cloud serviços.
• Nesta arquitetura, a comunicação com contentores do Cloud Storage ou o Pub/Sub é realizada através de redes públicas ou de uma conetividade privada através de VPN, Cloud Interconnect ou Cross-Cloud Interconnect. Normalmente, a decisão sobre como estabelecer a ligação depende de vários aspetos, como os seguintes:
  • Volume de tráfego esperado
  • Se é uma configuração temporária ou permanente
  • Requisitos de segurança e conformidade

Variação

As opções de design descritas no padrão de entrada controlada, que usa pontos finais do Private Service Connect para APIs Google, também podem ser aplicadas a este padrão. Especificamente, fornece acesso ao Cloud Storage, ao BigQuery e a outras APIs de serviços Google. Esta abordagem requer endereçamento IP privado através de uma ligação de rede híbrida e multicloud, como VPN, Cloud Interconnect e Cross-Cloud Interconnect.

Práticas recomendadas

• Restrinja o acesso a contentores do Cloud Storage e tópicos do Pub/Sub.
• Quando aplicável, use soluções de movimentação de dados integradas e baseadas na nuvem, como o Google Cloud conjunto de soluções. Para satisfazer as necessidades do seu exemplo de utilização, estas soluções foram concebidas para mover, integrar e transformar dados de forma eficiente.

• Avalie os diferentes fatores que influenciam as opções de transferência de dados, como o custo, o tempo de transferência esperado e a segurança. Para mais informações, consulte o artigo Avaliar as opções de transferência.

• Para minimizar a latência e evitar a transferência e a movimentação de dados de grande volume através da Internet pública, considere usar a Interligação de nuvem ou a Interligação entre nuvens, incluindo o acesso a pontos finais do Private Service Connect na sua nuvem virtual privada para APIs Google.

• Para proteger os serviços nos seus projetos e mitigar o risco de exfiltração de dados, use os VPC Service Controls. Google Cloud Estes controlos de serviço podem especificar perímetros de serviço ao nível do projeto ou da rede VPC.

  • 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 sobre as vantagens dos perímetros de serviço, consulte a Vista geral dos VPC Service Controls.

• Comunicar com cargas de trabalho de estatísticas de dados publicadas publicamente que estão alojadas em instâncias de VM através de um gateway de API, um equilibrador de carga ou um dispositivo de rede virtual. Use um destes métodos de comunicação para maior segurança e para evitar que estas instâncias sejam diretamente acessíveis a partir da Internet.

• Se for necessário acesso à Internet, pode usar o Cloud NAT na mesma VPC para processar o tráfego de saída das instâncias para a Internet pública.

• Reveja as práticas recomendadas gerais para topologias de rede híbridas e multicloud.

Práticas recomendadas gerais

Ao criar e integrar identidades da nuvem, a hierarquia de recursos e as redes da zona de destino, considere as recomendações de criação em Criação da zona de destino no Google Cloud e as Google Cloud práticas recomendadas de segurança abordadas no projeto de base empresarial. Valide o design selecionado com base nos seguintes documentos:

• Práticas recomendadas e arquiteturas de referência para a conceção de VPCs
• Decida uma hierarquia de recursos para a sua Google Cloud zona de destino
• Google Cloud Well-Architected Framework: segurança, privacidade e conformidade

Além disso, considere as seguintes práticas recomendadas gerais:

• Quando escolher uma opção de conetividade de rede híbrida ou multinuvem, tenha em consideração os requisitos empresariais e de aplicação, como SLAs, desempenho, segurança, custo, fiabilidade e largura de banda. Para mais informações, consulte os artigos Escolher um produto de conetividade de rede e Padrões para estabelecer ligação a outros fornecedores de serviços na nuvem com Google Cloud.

• Use VPCs partilhadas em vez de várias VPCs quando for adequado e estiver alinhado com os requisitos do design da hierarquia de recursos. Google Cloud Para mais informações, consulte o artigo Decidir se deve criar várias redes VPC.

• Siga as práticas recomendadas para planear contas e organizações.

• Quando aplicável, estabeleça uma identidade comum entre ambientes para que os sistemas possam autenticar-se em segurança em limites de ambientes.

• Para expor aplicações de forma segura a utilizadores empresariais numa configuração híbrida, e para escolher a abordagem que melhor se adapta aos seus requisitos, deve seguir as formas recomendadas de integração Google Cloud com o seu sistema de gestão de identidades.

  • Consulte também os padrões para autenticar utilizadores da força de trabalho num ambiente híbrido.

• Ao criar os seus ambientes no local e na nuvem, considere a utilização de endereços IPv6 desde o início e tenha em conta os serviços que o suportam. Para mais informações, consulte Uma introdução ao IPv6 no Google Cloud. Resume os serviços que eram suportados quando o blogue foi escrito.

• Ao conceber, implementar e gerir as regras de firewall da VPC, pode:

  • Use a filtragem baseada em contas de serviço em vez da filtragem baseada em etiquetas de rede se precisar de um controlo rigoroso sobre a forma como as regras de firewall são aplicadas às VMs.
  • Use políticas de firewall quando agrupa várias regras de firewall, para que possa atualizá-las todas em simultâneo. Também pode tornar a política hierárquica. Para ver especificações e detalhes da política de firewall hierárquica, consulte o artigo Políticas de firewall hierárquicas.
  • Use objetos de geolocalização na política de firewall quando precisar de filtrar o tráfego IPv4 externo e IPv6 externo com base em localizações ou regiões geográficas específicas.
  • Use a inteligência contra ameaças para regras de políticas de firewall se precisar de proteger a sua rede permitindo ou bloqueando o tráfego com base em dados de inteligência contra ameaças, como endereços IP maliciosos conhecidos ou com base em intervalos de endereços IP da nuvem pública. Por exemplo, pode permitir o tráfego de intervalos de endereços IP de nuvem pública específicos se os seus serviços precisarem de comunicar apenas com essa nuvem pública. Para mais informações, consulte as práticas recomendadas para regras de firewall.

• Deve sempre criar a segurança da nuvem e da rede com uma abordagem de segurança de várias camadas, considerando camadas de segurança adicionais, como as seguintes:

  • Google Cloud Armor
  • Sistema de deteção de intrusos do Cloud
  • IPS de firewall de próxima geração da nuvem
  • Informações sobre ameaças para regras de políticas de firewall

  Estas camadas adicionais podem ajudar a filtrar, inspecionar e monitorizar uma grande variedade de ameaças nas camadas de rede e de aplicação para análise e prevenção.

• Ao decidir onde a resolução de DNS deve ser realizada numa configuração híbrida, recomendamos a utilização de dois sistemas de DNS autoritativos para o seu ambiente privado e para os seus recursos no local alojados por servidores DNS existentes no seu ambiente no local.Google Cloud Para mais informações, consulte o artigo Escolha onde a resolução de DNS é realizada.

• Sempre que possível, exponha as aplicações através de APIs com um gateway de API ou um equilibrador de carga. Recomendamos que considere uma plataforma de API, como o Apigee. O Apigee funciona como uma abstração ou uma fachada para as APIs de serviços de back-end, combinadas com capacidades de segurança, limitação de taxas, quotas e estatísticas.

• Uma plataforma de API (gateway ou proxy) e o Application Load Balancer não são mutuamente exclusivos. Por vezes, a utilização conjunta de gateways de API e balanceadores de carga pode oferecer uma solução mais robusta e segura para gerir e distribuir o tráfego de API em grande escala. A utilização de gateways de API do Cloud Load Balancing permite-lhe realizar o seguinte:

  • Ofereça APIs de alto desempenho com o Apigee e a Cloud CDN para:

    • Reduza a latência
    • Alojamento de APIs a nível global

    • Aumente a disponibilidade para as temporadas de pico de tráfego

      Para mais informações, veja o vídeo Fornecer APIs de elevado desempenho com o Apigee e o Cloud CDN no YouTube.

  • Implemente a gestão avançada de tráfego.

  • Use o Cloud Armor como proteção contra DDoS, WAF e serviço de segurança de rede para proteger as suas APIs.

  • Faça a gestão do equilíbrio de carga eficiente em vários gateways em várias regiões. Para mais informações, veja o vídeo Proteger APIs e implementar a comutação por falha em várias regiões com o PSC e o Apigee.

• Para determinar que produto do Cloud Load Balancing usar, primeiro tem de determinar que tipo de tráfego os equilibradores de carga têm de processar. Para mais informações, consulte Escolha um balanceador de carga.

• Quando usar o Cloud Load Balancing, deve usar as respetivas capacidades de otimização da capacidade da aplicação, quando aplicável. Isto pode ajudar a resolver alguns dos desafios de capacidade que podem ocorrer em aplicações distribuídas globalmente.

  • Para uma análise detalhada da latência, consulte o artigo Otimize a latência da aplicação com o equilíbrio de carga.

• Embora a Cloud VPN encripte o tráfego entre ambientes, com o Cloud Interconnect, tem de usar o MACsec ou a VPN de alta disponibilidade através do Cloud Interconnect para encriptar o tráfego em trânsito na camada de conetividade. Para mais informações, consulte o artigo Como posso encriptar o meu tráfego através da Cloud Interconnect.

  • Também pode considerar a encriptação da camada de serviço através do TLS. Para mais informações, consulte o artigo Decida como cumprir os requisitos de conformidade para a encriptação em trânsito.

• Se precisar de um volume de tráfego superior numa conetividade híbrida de VPN do que um único túnel de VPN pode suportar, pode considerar usar a opção de encaminhamento de VPN de HA ativo/ativo.

  • Para configurações híbridas ou multinuvem a longo prazo com volumes elevados de transferência de dados de saída, considere o Cloud Interconnect ou o Cross-Cloud Interconnect. Essas opções de conetividade ajudam a otimizar o desempenho da conetividade e podem reduzir os custos de transferência de dados de saída para o tráfego que cumpre determinadas condições. Para mais informações, consulte os preços do Cloud Interconnect.

• Quando estabelecer ligação a Google Cloud recursos e tentar escolher entre a Interligação na nuvem, o peering direto ou o peering de operadora, recomendamos que use a Interligação na nuvem, a menos que precise de aceder às aplicações do Google Workspace. Para mais informações, pode comparar as funcionalidades do Direct Peering com o Cloud Interconnect e do Carrier Peering com o Cloud Interconnect.

• Permita espaço de endereço IP suficiente do seu espaço de endereço IP RFC 1918 existente para acomodar os seus sistemas alojados na nuvem.

• Se tiver restrições técnicas que exijam que mantenha o seu intervalo de endereços IP, pode:

  • Use os mesmos endereços IP internos para as suas cargas de trabalho no local enquanto os migra para o Google Cloud, usando sub-redes híbridas.

  • Aprovisione e use os seus próprios endereços IPv4 públicos para Google Cloud recursos que usam traga o seu próprio IP (BYOIP) para o Google.

• Se a conceção da sua solução exigir a exposição de uma aplicação baseada emGoogle Cloudà Internet pública, considere as recomendações de conceção abordadas no artigo Redes para a entrega de aplicações viradas para a Internet.

• Quando aplicável, use os pontos finais do Private Service Connect para permitir que as cargas de trabalho no Google Cloud, no local ou noutro ambiente de nuvem com conetividade híbrida acedam de forma privada às APIs Google ou aos serviços publicados, usando endereços IP internos de forma detalhada.

• Quando usar o Private Service Connect, tem de controlar o seguinte:

  • Quem pode implementar recursos do Private Service Connect.
  • Se é possível estabelecer ligações entre consumidores e produtores.
  • Que tráfego de rede tem autorização para aceder a essas ligações.

  Para mais informações, consulte o artigo Segurança do Private Service Connect.

• Para alcançar uma configuração na nuvem robusta no contexto da arquitetura híbrida e multinuvem:

  • Realizar uma avaliação abrangente dos níveis necessários de fiabilidade das diferentes aplicações em todos os ambientes. Ao fazê-lo, pode ajudar a atingir os seus objetivos de disponibilidade e resiliência.
  • Compreenda as capacidades de fiabilidade e os princípios de conceção do seu fornecedor de nuvem. Para mais informações, consulte a secção sobre a Google Cloud fiabilidade da infraestrutura.

• A visibilidade e a monitorização da rede na nuvem são essenciais para manter comunicações fiáveis. O Network Intelligence Center oferece uma única consola para gerir a visibilidade, a monitorização e a resolução de problemas da rede.

Padrões de arquitetura de rede segura híbrida e de várias nuvens: o que se segue

• Saiba mais sobre os padrões de arquitetura comuns que pode implementar usando os padrões de rede abordados neste documento.
• Saiba como abordar a nuvem híbrida e a multinuvem, e como escolher cargas de trabalho adequadas.
• Saiba mais sobre a Google Cloud rede entre nuvens uma plataforma de rede global aberta, segura e otimizada para aplicações e utilizadores em instalações locais e outras nuvens.
• Crie uma infraestrutura fiável para as suas cargas de trabalho em Google Cloud: Orientações de design para ajudar a proteger as suas aplicações contra falhas ao nível do recurso, da zona e da região.
• Para saber mais sobre a criação de arquiteturas de alta disponibilidade no Google Cloud, consulte os padrões para apps resilientes e escaláveis.
• Saiba mais sobre as possíveis opções de conetividade para ligar o cluster GKE Enterprise em execução no seu ambiente no local/periférico à Google Cloud rede juntamente com o Impacto da desativação temporária da ligação à Google Cloud.