Padrões de arquitetura de rede seguros híbridos e de várias nuvens

Last reviewed 2025-01-23 UTC

Este é o terceiro de três documentos de um conjunto. Ele aborda temas híbridos e multicloud. Esta parte explora várias padrões comuns de arquitetura de rede segura que podem ser usados para ambientes multicloud. Ele descreve os cenários em que esses padrões de rede são mais adequados e fornece práticas recomendadas para implementá-los com Google Cloud.

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

  • Criar arquiteturas híbridas e multicloud: discute o planejamento de uma estratégia para arquitetar uma configuração híbrida e multicloud com o Google Cloud.
  • Padrões de arquitetura híbridos e de várias nuvens: discute padrões de arquitetura comuns a serem adotados como parte de um modelo híbrido e de várias nuvens.
  • Padrões de arquitetura de rede híbridos e seguros para várias nuvens: aborda padrões de arquitetura de rede híbrida e de várias nuvens perspectiva de rede (este documento).

Conectar ambientes de computação particulares ao Google Cloud com segurança e confiabilidade é essencial para qualquer arquitetura híbrida e de multicloud. O padrão de conectividade de rede híbrida e de arquitetura de rede em nuvem que você para uma configuração híbrida e de várias nuvens precisam atender aos requisitos exclusivos de das cargas de trabalho da sua empresa. Ele também precisa se adequar aos padrões de arquitetura que você que pretendemos aplicar. Embora possa ser necessário adaptar cada design, há padrões comuns que você pode usar como uma planta.

Os padrões de arquitetura de rede neste documento não devem ser consideradas alternativas ao design da zona de destino em Google Cloud. Em vez disso, você deve projetar e implantar os padrões de arquitetura selecionar como parte do design geral da zona de destino Google Cloud , que abrange as seguintes áreas:

  • Identidades
  • Gerenciamento de recursos
  • Segurança
  • Rede
  • Monitoramento

Diferentes aplicativos podem usar diferentes padrões de arquitetura de rede, que são incorporadas como parte da arquitetura de uma zona de destino. Em uma multicloud configuração, mantenha a consistência do design da zona de destino em todas do Google Cloud.

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

Colaboradores

Autor: Marwan Al Shawi | Engenheiro de clientes parceiro

Outros colaboradores:

Padrões de arquitetura

Os documentos desta série discutem os padrões de arquitetura de rede baseados nos modelos de comunicação necessários entre os aplicativos localizados no Google Cloud e em outros ambientes (no local, em outras nuvens ou nos dois).

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

Os documentos desta série também discutem as diferentes variações de design que podem ser usadas com cada padrão de arquitetura. Os seguintes padrões de rede podem ajudar você a atender aos requisitos de comunicação e segurança dos aplicativos:

Padrão espelhado

O padrão espelho é baseado na replicação do design de um ou mais ambientes existentes em um ou mais ambientes novos. Portanto, esse padrão se aplica principalmente a arquiteturas que seguem o padrão híbrido de ambiente. Nesse padrão, você executa as cargas de trabalho de desenvolvimento e teste em um ambiente enquanto executa as cargas de trabalho de preparo e produção em outro.

O padrão espelhado pressupõe que as cargas de trabalho de teste e de produção não devem se comunicar diretamente umas com as outras. No entanto, é preciso que você possa gerenciar e implantar os dois grupos de cargas de trabalho de maneira consistente.

Se você usar esse padrão, conecte os dois ambientes de computação de maneira a estar alinhado com os seguintes requisitos:

  • A integração contínua/implantação contínua (CI/CD, na sigla em inglês) pode implantar e gerenciar cargas de trabalho em todos os ambientes de computação ou em ambientes específicos.
  • O monitoramento, o gerenciamento de configuração e outros sistemas administrativos precisam funcionar em todos os ambientes de computação.
  • As cargas de trabalho não podem se comunicar diretamente entre os ambientes de computação. Se necessário, a comunicação precisa ser refinada e controlada.

Arquitetura

O diagrama de arquitetura a seguir mostra uma arquitetura de referência de alto nível desse padrão que oferece suporte a CI/CD, monitoramento, gerenciamento de configuração, outros sistemas administrativos e comunicação de carga de trabalho:

Os dados fluem entre uma CI/CD e uma VPC de administrador em Google Cloud e um ambiente de produção local. Os dados também fluem entre a CI/CD-VPC e os ambientes de desenvolvimento e teste no Google Cloud.

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

  • As cargas de trabalho são distribuídas com base nos ambientes funcionais (desenvolvimento, teste, ferramentas administrativas e CI/CD) em VPCs separadas no lado Google Cloud .
  • A VPC compartilhada é usada para cargas de trabalho de desenvolvimento e teste. Uma VPC extra é usada para as ferramentas administrativas e de CI/CD. Com VPCs compartilhadas:
    • Os aplicativos são gerenciados por diferentes equipes por ambiente e por projeto de serviço.
    • O projeto host administra e controla a comunicação de rede e os controles de segurança entre os ambientes de desenvolvimento e teste, bem como fora da VPC.
  • A VPC de CI/CD está conectada à rede que executa as cargas de trabalho de produção no seu ambiente de computação particular.
  • As regras de firewall só permitem o tráfego permitido.
    • Você também pode usar o Cloud Next Generation Firewall Enterprise com o serviço de prevenção de invasões (IPS) para implementar a inspeção detalhada de pacotes para prevenção de ameaças sem alterar o design ou o roteamento. O Cloud Next Generation Firewall Enterprise cria endpoints de firewall zonais gerenciados pelo Google que usam a tecnologia de interceptação de pacotes para inspecionar de maneira transparente as cargas de trabalho quanto às assinaturas de ameaças configuradas. Ele também protege as cargas de trabalho contra ameaças.
  • Permite a comunicação entre as VPCs com peering usando endereços IP internos.
    • O peering nesse padrão permite que a CI/CD e os sistemas administrativos implantem e gerenciem cargas de trabalho de desenvolvimento e teste.
  • Considere estas práticas recomendadas gerais.

Estabeleça essa conexão de CI/CD usando uma das opções de conectividade de rede híbrida e multicloud que atendam aos requisitos dos seus negócios e aplicativos. Para implantar e gerenciar cargas de trabalho de produção, essa conexão oferece acessibilidade de rede particular entre os diferentes ambientes de computação. Todos os ambientes precisam ter um espaço de endereços IP RFC 1918 sem sobreposição.

Se as instâncias nos ambientes de desenvolvimento e teste exigirem acesso à Internet, considere estas opções:

  • É possível implantar o Cloud NAT na mesma rede do projeto host da VPC compartilhada. O provisionamento na mesma rede de projeto host da VPC compartilhada ajuda a evitar que essas instâncias sejam acessadas diretamente pela Internet.
  • Para o tráfego de saída da Web, use o Proxy seguro da Web. O proxy oferece vários benefícios.

Para mais informações sobre as ferramentas e os recursos do Google Cloud que ajudam a criar, testar e implantar em Google Cloud e em ambientes híbridos e multicloud, consulte o blog DevOps e CI/CD no Google Cloud explicados (em inglês).

Variações

Para atender a diferentes requisitos de design, mas sem deixar de considerar todos os requisitos de comunicação, o padrão de arquitetura espelho oferece estas opções, que são descritas nas seções a seguir:

VPC compartilhada por ambiente

A opção de design de VPC compartilhada por ambiente permite a separação de aplicativos ou de nível de serviço entre ambientes, incluindo ferramentas de CI/CD e administrativas que podem ser necessárias para atender a determinados requisitos de segurança organizacionais. Esses requisitos limitam a comunicação, o domínio administrativo e o controle de acesso para diferentes serviços que também precisam ser gerenciados por equipes diferentes.

Esse design alcança a separação fornecendo isolamento de rede e projeto entre os diferentes ambientes, o que permite uma comunicação mais detalhada e o controle de acesso do Identity and Access Management (IAM).

Do ponto de vista de gerenciamento e operações, esse design oferece a flexibilidade de gerenciar os aplicativos e os workloads criados por diferentes equipes por ambiente e projeto de serviço. A rede VPC e os recursos de segurança dela podem ser provisionados e gerenciados por equipes de operações de rede com base nas seguintes estruturas:

  • Uma equipe gerencia todos os projetos de host em todos os ambientes.
  • Equipes diferentes gerenciam os projetos host nos respectivos ambientes.

As decisões sobre o gerenciamento de projetos de host devem ser baseadas na estrutura da equipe, nas operações de segurança e nos requisitos de acesso de cada equipe. É possível aplicar essa variação de design à rede VPC compartilhada para cada opção de design da zona de destino do ambiente. No entanto, é preciso considerar os requisitos de comunicação do padrão espelhado para definir quais comunicações são permitidas entre os diferentes ambientes, incluindo a comunicação pela rede híbrida.

Também é possível provisionar uma rede VPC compartilhada para cada ambiente principal, conforme ilustrado no diagrama a seguir:

O peering de VPC no Google Cloud compartilha dados entre ambientes de desenvolvimento e teste e sub-redes administrativas e de CI/CD. As sub-redes compartilham dados entre Google Cloud e um ambiente local.

Firewall de camada do aplicativo centralizado

Em alguns cenários, os requisitos de segurança podem exigir a consideração da camada do aplicativo (camada 7) e uma inspeção detalhada de pacotes com mecanismos avançados de firewall que excedam os recursos do firewall de última geração do Cloud. Para atender aos requisitos e padrões de segurança da sua organização, use um dispositivo NGFW hospedado em um dispositivo virtual de rede (NVA). Vários Google Cloud parceiros de segurança oferecem opções adequadas para essa tarefa.

Conforme ilustrado no diagrama a seguir, é possível colocar o NVA no caminho de rede entre a nuvem privada virtual e o ambiente de computação particular usando várias interfaces de rede.

O peering da VPC no Google Cloud compartilha dados entre ambientes de desenvolvimento e teste e sub-redes administrativas e CI/CD. As sub-redes compartilham dados entre Google Cloud e um ambiente local por uma rede VPC de trânsito.

Esse design também pode ser usado com várias VPCs compartilhadas, conforme ilustrado no diagrama a seguir.

O peering VPC no Google Cloud compartilha dados entre ambientes de desenvolvimento e teste e CI/CD e sub-redes administrativas. As sub-redes usam um NVA para compartilhar dados entre Google Cloud e um ambiente local por uma rede VPC de trânsito.

O NVA neste design atua como a camada de segurança do perímetro. Ele também serve como base para ativar a inspeção de tráfego inline e aplicar políticas rígidas de controle de acesso.

Para uma estratégia de segurança robusta em várias camadas que inclui regras de firewall da VPC e recursos de serviço de prevenção de intrusões, inclua mais inspeção de tráfego e controle de segurança nos fluxos de tráfego leste-oeste e norte-sul.

Topologia hub e spoke

Outra variação possível do design é usar VPCs separadas (incluindo VPCs compartilhadas) para o desenvolvimento e diferentes estágios de teste. Nesta variação, conforme mostrado no diagrama abaixo, todos os ambientes de estágio se conectam à VPC de CI/CD e administrativa em uma arquitetura hub and spoke. Use essa opção se você precisar separar os domínios administrativos e as funções em cada ambiente. O modelo de comunicação hub-spoke pode ajudar com os seguintes requisitos:

  • Os aplicativos precisam acessar um conjunto comum de serviços, como monitoramento, ferramentas de gerenciamento de configuração, CI/CD ou autenticação.
  • Um conjunto comum de políticas de segurança precisa ser aplicado ao tráfego de entrada e saída de maneira centralizada pelo hub.

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

Os ambientes de desenvolvimento e de teste compartilham dados com uma CI/CD da VPC hub e uma VPC de administrador para um ambiente local.

Conforme mostrado no diagrama anterior, a comunicação inter-VPC e a conectividade híbrida passam pela VPC hub. Como parte desse padrão, é possível controlar e restringir a comunicação na VPC hub para se alinhar aos seus requisitos de conectividade.

Como parte da arquitetura de rede hub-and-spoke, estas são as principais opções de conectividade (entre as VPCs spoke e hub) no Google Cloud:

  • Peering de rede VPC
  • VPN
  • Usar o dispositivo virtual de rede (NVA)

Para mais informações sobre qual opção considerar no seu design, consulte Arquitetura de rede hub and spoke. Um fator importante para selecionar o VPN sobre o peering de VPC entre os raios e a VPC hub é 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 pelo hub.

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

Arquiteturas híbridas e multicloud podem exigir vários clusters para atingir objetivos técnicos e comerciais, incluindo a separação do ambiente de produção dos ambientes de desenvolvimento e teste. Portanto, os controles de segurança do perímetro de rede são importantes, especialmente quando são necessários para cumprir determinados requisitos de segurança.

Não basta oferecer suporte aos requisitos de segurança das arquiteturas de microsserviços distribuídos de nuvem, você também precisa considerar arquiteturas distribuídas de confiança zero. A arquitetura distribuída de microsserviços de confiança zero oferece suporte à sua arquitetura de microsserviços com aplicação de política de segurança no nível do microsserviço, autenticação e identidade da carga de trabalho. A confiança é baseada na identidade e aplicada para cada serviço.

Ao usar uma arquitetura de proxy distribuída, como uma malha de serviço, os serviços podem validar eficazmente os autores de chamadas e implementar políticas de controle de acesso refinadas para cada solicitação, permitindo um ambiente de microsserviços mais seguro e escalonável. O Cloud Service Mesh oferece flexibilidade para ter uma malha comum que pode abranger as implantaçõesGoogle Cloud e no local. A malha usa políticas de autorização para ajudar a proteger as comunicações entre serviços.

Você também pode incorporar o Adaptador da Apigee para Envoy (link em inglês), que é uma implantação leve de gateway de API da Apigee em um cluster do Kubernetes, com essa arquitetura. O adaptador da Apigee para Envoy é um proxy de serviço e borda de código aberto projetado para aplicativos com priorização da nuvem.

Os dados fluem entre os serviços no Google Cloud e um ambiente local por uma arquitetura de proxy distribuída.

Para mais informações sobre esse assunto, consulte os seguintes artigos:

Práticas recomendadas para padrão espelhado

  • Os sistemas de CI/CD necessários para implantar ou reconfigurar implantações de produção precisam ter alta disponibilidade, ou seja, todos os componentes da arquitetura precisam ser projetados para fornecer o nível esperado de disponibilidade do sistema. Para mais informações, consulte Google Cloud confiabilidade da infraestrutura.
  • Para eliminar erros de configuração em processos repetidos, como atualizações de código, a automação é essencial para padronizar builds, testes e implantações.
  • A integração de NVAs centralizados nesse design pode exigir a incorporação de vários segmentos com níveis variados de controles de acesso de segurança.
  • Ao projetar uma solução que inclua NVAs, é importante considerar a alta disponibilidade (HA) dos NVAs para evitar um ponto único de falha que possam bloquear toda a comunicação. Siga o design de alta disponibilidade e redundância as orientações de implementação fornecidas pelo fornecedor do NVA.
  • Ao não exportar rotas IP locais por peering de VPC ou VPN para a VPC de desenvolvimento e teste, é possível restringir a acessibilidade da rede dos ambientes de desenvolvimento e teste ao ambiente local. Para mais informações, consulte Troca de rotas personalizadas do peering de rede VPC.
  • Para cargas de trabalho com endereçamento IP particular que podem exigir acesso às APIs do Google, é possível expor as APIs do Google usando um endpoint do Private Service Connect em uma rede VPC. Para mais informações, consulte Ingresso controlado nesta série.
  • Consulte as práticas recomendadas gerais para padrões de arquitetura de rede híbrida e multicloud.

Padrão em malha

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

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

Arquitetura

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

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

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

    • Regras de firewall ou políticas de firewall.

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

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

Variações

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

Uma VPC por ambiente

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

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

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

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

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

Usar um firewall de camada do aplicativo centralizado

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

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

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

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

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

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

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

Práticas recomendadas para padrões em malha

  • Antes de fazer qualquer coisa, decida o design da hierarquia de recursos, e o design necessário para oferecer suporte a todos os projetos e à VPC. Isso pode ajudar você a selecionar a arquitetura de rede ideal para a estrutura dos projetos do Google Cloud .
  • Use uma arquitetura distribuída de confiança zero ao usar o Kubernetes no ambiente de computação particular e no Google Cloud.
  • Ao usar NVAs centralizados no projeto, é preciso definir vários segmentos com diferentes níveis de controles de acesso de segurança e políticas de inspeção de tráfego. Baseie esses controles e políticas nos requisitos de segurança dos aplicativos.
  • Ao projetar uma solução que inclua NVAs, é importante considerar a alta disponibilidade (HA) dos NVAs para evitar um ponto único de falha que possam bloquear toda a comunicação. Siga o design de alta disponibilidade e redundância e as orientações de implementação fornecidas pelo fornecedor de segurançaGoogle Cloud que fornece os NVAs.
  • Para oferecer maior privacidade, integridade de dados e um modelo de comunicação controlado, exponha aplicativos usando APIs com gateways de API, como Apigee e Apigee híbrida com mTLS de ponta a ponta. Também é possível usar a VPC compartilhada com a Apigee no mesmo recurso da organização.
  • Se o design da sua solução exigir a exposição de um aplicativo baseado em Google Cloud na Internet pública, considere as recomendações de design discutida em Rede para entrega de aplicativos voltados à Internet.
  • Para ajudar a proteger os serviços Google Cloud nos seus projetos e reduzir o risco de exfiltração de dados, use o VPC Service Controls para especificar perímetros de serviço no nível do projeto ou da rede VPC. Além disso, você pode estender perímetros de serviço para um ambiente híbrido usando uma VPN autorizada ou o Cloud Interconnect. Para mais informações sobre os benefícios dos perímetros de serviço, consulte Visão geral do VPC Service Controls.
  • Consulte a práticas recomendadas gerais para padrões de rede híbridos e multicloud.

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

Padrões controlados

O padrão controlado é baseado em uma arquitetura que expõe serviços aplicativos de seleção de maneira refinada, com base em APIs ou endpoints específicos expostos entre diferentes ambientes. Neste guia, categorizamos esse padrão em três opções possíveis, cada uma determinada pelo modelode comunicação específico:

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

Confira nesta série os padrões controlados e as possíveis opções de design. No entanto, uma opção de design comum aplicável a todos os padrões fechados é a Arquitetura distribuída de confiança zero para aplicativos conteinerizados com arquitetura de microsserviços. Essa opção conta com a tecnologia do Cloud Service Mesh Apigee e Adaptador da Apigee para Envoy: uma implantação leve de gateway da Apigee em um cluster do Kubernetes. O adaptador da Apigee para Envoy é um proxy de serviço e borda de código aberto conhecido desenvolvido para aplicativos com priorização da nuvem. Os controles de arquitetura permitem comunicações entre serviços protegidas e a direção da comunicação no nível do serviço. As políticas de comunicação de tráfego podem ser criadas, ajustadas e aplicadas no nível de serviço com base no padrão selecionado.

Padrões controlados permitem a implementação do Cloud Next Generation Firewall Enterprise por serviço de prevenção de invasões (IPS) para realizar uma inspeção detalhada de pacotes para prevenção de ameaças sem nenhuma modificação de design ou rota. Essa inspeção está sujeita aos aplicativos específicos acessados, o modelo de comunicação e os requisitos de segurança. Se os requisitos de segurança exigirem a camada 7 e uma inspeção detalhada de pacotes com mecanismos avançados de firewall que ultrapassam os recursos do firewall de última geração do Google Cloud, é possível usar um firewall de última geração (NGFW) centralizado hospedado em um dispositivo virtual de rede (NVA). Vários Google Cloud parceiros de segurança oferecem dispositivos de NGFW que podem atender aos seus requisitos de segurança. Integrar NVAs com esses padrões controlados pode exigir a introdução de várias zonas de segurança dentro do design de rede, cada uma com níveis de controle de acesso distintos.

Saída controlada

A arquitetura do padrão de rede de saída controlada é baseada na exposição de APIs selecionadas do ambiente local ou de outro ambiente de nuvem para cargas de trabalho implantadas em Google Cloud. Isso é feito sem expor diretamente os dados à Internet pública de um ambiente local ou de outros ambientes de nuvem. É possível facilitar essa exposição limitada por meio de um gateway de API ou proxy ou um balanceador de carga que funciona como uma fachada para cargas de trabalho atuais. É possível implantar a funcionalidade do gateway de API em um segmento de rede de perímetro isolado, como uma rede de perímetro.

O padrão de rede saída de saída controlada se aplica principalmente a (mas não se limita a) padrões de arquitetura de aplicativos em camadas e padrões de arquitetura de aplicativos particionados. Ao implantar cargas de trabalho de back-end em uma rede interna, a rede de saída gerida ajuda a manter um nível mais alto de segurança no ambiente de computação local. O padrão exige que você conecte os ambientes de computação de maneira a atender aos seguintes requisitos de comunicação:

  • As cargas de trabalho implantadas no Google Cloud podem se comunicar com o gateway de API ou o balanceador de carga (ou um endpoint do Private Service Connect) que expõe o aplicativo usando endereços IP internos.
  • Outros sistemas no ambiente de computação particular não podem ser acessados diretamente de dentro do Google Cloud.
  • Não é permitida a comunicação do ambiente de computação particular com nenhuma carga de trabalho implantada no Google Cloud .
  • O tráfego para as APIs particulares em outros ambientes só é iniciado no ambiente Google Cloud .

O foco deste guia é em ambientes híbridos e multicloud conectados por uma rede híbrida privada. Se os requisitos de segurança da sua organização permitirem, as chamadas de API para APIs de destino remotas com endereços IP públicos poderão ser acessadas diretamente pela Internet. No entanto, é necessário considerar os seguintes mecanismos de segurança:

  • API OAuth 2.0 com Transport Layer Security (TLS).
  • Limitação de taxa.
  • Políticas de proteção contra ameaças.
  • TLS mútuo configurado no back-end da camada da API.
  • Filtragem de lista de permissõ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 aspectos de segurança. Para mais informações, consulte Práticas recomendadas para proteger seus aplicativos e APIs usando a Apigee.

Arquitetura

O diagrama a seguir mostra uma arquitetura de referência que oferece suporte aos requisitos de comunicação listados na seção anterior:

Os dados fluem em uma direção de um projeto host em Google Cloud para uma carga de trabalho em um ambiente local.

Os dados fluem pelo diagrama anterior da seguinte maneira:

  • No lado do Google Cloud , é possível implantar cargas de trabalho em nuvens privadas virtuais (VPCs). As VPCs podem ser únicas ou múltiplas (compartilhadas ou não compartilhadas). A implantação precisa estar alinhada com os projetos e o design da hierarquia de recursos da sua organização.
  • As redes VPC do ambiente Google Cloud são estendidas para outros ambientes de computação. Os ambientes podem estar no local ou em outra nuvem. Para facilitar a comunicação entre ambientes usando endereços IP internos, use uma conectividade de rede híbrida e multicloud adequada.
  • Para limitar o tráfego que se origina de endereços IP específicos da VPC e é destinado a gateways remotos ou balanceadores de carga, use a filtragem de lista de permissões de endereços IP. O tráfego de retorno dessas conexões é permitido ao usar regras de firewall stateful. É possível usar qualquer combinação dos recursos a seguir para proteger e limitar as comunicações apenas aos endereços IP de origem e destino permitidos:

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

Variações

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

Usar o gateway de API Google Cloud e o front-end global

Os dados que fluem em Google Cloud da Apigee para uma VPC do projeto do cliente e depois para fora do Cloud para um ambiente local ou outra instância de nuvem.

Com essa abordagem de design, a exposição e o gerenciamento da API ficam em Google Cloud. Conforme mostrado no diagrama anterior, isso pode ser feito com a implementação do Apigee como a plataforma de API. A decisão de implantar um gateway de API ou balanceador de carga no ambiente remoto depende das suas necessidades específicas e da configuração atual. A Apigee oferece duas opções de provisionamento de conectividade:

  • Com peering de VPC
  • Sem peering de VPC

Google Cloud Os recursos globais do front-end, como o Cloud Load Balancing, o Cloud CDN (quando acessados pelo Cloud Interconnect) e a Interconexão entre nuvens aumentam a velocidade com que os usuários podem acessar aplicativos com back-ends hospedados nos seus ambientes locais e em outros ambientes de nuvem.

A otimização das velocidades de entrega de conteúdo é alcançada com a entrega desses aplicativos a partir de Google Cloud pontos de presença (PoPs). Google Cloud Os PoPs estão presentes em mais de 180 pontos de trocas de tráfego de Internet e em mais de 160 instalações de interconexão em todo o mundo.

Para saber como os POPs ajudam a fornecer APIs de alto desempenho ao usar a Apigee com o Cloud CDN para realizar o seguinte, assista Como entregar APIs de alto desempenho com a Apigee e o Cloud CDN no YouTube:

  • reduzir a latência.
  • Hospedar APIs globalmente.
  • Aumente a disponibilidade em momentos de pico de tráfego.

O exemplo de design ilustrado no diagrama anterior é baseado no Private Service Connect sem peering de VPC.

A rede northbound neste design é estabelecida por:

A rede southbound é estabelecida por:

  • Um endpoint do Private Service Connect que faz referência a um anexo de serviço associado a um balanceador de carga interno (ILB no diagrama) na VPC do cliente.
  • O ILB é implantado com grupos de endpoints de rede de conectividade híbrida (NEGs de conectividade híbrida).

  • Os serviços híbridos são acessados pelo NEG de conectividade híbrida em uma conectividade de rede híbrida, como VPN ou Cloud Interconnect.

Para mais informações, consulte Configurar um balanceador de carga de rede de proxy interno regional com conectividade híbrida e Padrões de implantação do Private Service Connect.

Expor serviços remotos usando o Private Service Connect

Dados que fluem de Google Cloud para um ambiente local ou outra nuvem, depois de originarem de uma carga de trabalho em uma VPC e passarem pelo Cloud Load Balancing, um NEG de conectividade híbrida e um Cloud VPN ou interconnect.

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

  • Você não está usando uma plataforma de API ou quer evitar conectar toda a rede VPC diretamente a um ambiente externo pelos seguintes motivos:
    • Você tem restrições de segurança ou requisitos de compliance.
    • Você tem uma sobreposição de intervalo de endereços IP, como em um cenário de fusão e aquisição.
  • Para ativar comunicações unidirecionais seguras entre clientes, aplicativos e serviços em todos os ambientes, mesmo quando você tem um prazo curto.
  • Talvez seja necessário fornecer conectividade a várias VPCs de consumidor por meio de uma VPC de serviço-produtor (VPC de trânsito) para oferecer modelos de serviço multilocatário ou locatário único altamente escalonáveis e alcançar serviços publicados em outros ambientes.

O uso do Private Service Connect para aplicativos consumidos como APIs fornece um endereço IP interno para os aplicativos publicados, permitindo o acesso seguro na rede particular entre regiões e em conectividade híbrida. Essa abstração facilita a integração de recursos locais e de nuvens diversas ambientes em um modelo de conectividade híbrido e de multicloud. É possível acelerar a integração de aplicativos e expor com segurança aplicativos que residem em um ambiente local ou em outro ambiente de nuvem usando o Private Service Connect para publicar o serviço com acesso refinado. Nesse caso, use a das seguintes opções:

No diagrama anterior, as cargas de trabalho na rede VPC do seu aplicativo podem alcançar os serviços híbridos em execução no ambiente local ou em outros ambientes de nuvem pelo endpoint do Private Service Connect, conforme ilustrado no diagrama a seguir. Essa opção de design para comunicações unidirecionais oferece uma opção alternativa ao peering com uma VPC de trânsito.

Os dados fluem por e entre várias VPCs dentro de Google Cloud antes de sair por um Cloud VPN ou Cloud Interconnect e chegar a um ambiente local ou a outra nuvem.

Como parte do design no diagrama anterior, vários front-ends, back-ends ou endpoints podem se conectar ao mesmo anexo de serviço, permitindo que várias redes VPC ou vários consumidores acessem o mesmo serviço. Conforme ilustrado no diagrama abaixo, é possível tornar o aplicativo acessível a várias VPCs. Essa acessibilidade pode ajudar em cenários de serviços multilocatários em que o serviço é consumido por várias VPCs de consumidor, mesmo que os intervalos de endereços IP se sobreponham.

A sobreposição de endereços IP é um dos problemas mais comuns ao integrar aplicativos que residem em ambientes diferentes. A conexão do Private Service Connect no diagrama a seguir ajuda a evitar o problema de sobreposição de endereços IP. Isso é feito sem exigir provisionamento ou gerenciamento de outros componentes de rede, como o Cloud NAT ou um NVA, para realizar a conversão de endereços IP. Para conferir um exemplo de configuração, consulte Publicar um serviço híbrido usando o Private Service Connect.

O design tem as seguintes vantagens:

  • Evita possíveis dependências de escalonamento compartilhadas e uma capacidade de gerenciamento complexa.
  • Melhora a segurança com um controle de conectividade mais refinado.
  • Reduz a coordenação do endereço 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 estágios posteriores para integrar a Apigee como a plataforma de API usando as opções de design de rede discutidas anteriormente, incluindo a opção do Private Service Connect.

É possível tornar o endpoint do Private Service Connect acessível de outras regiões usando o acesso global do Private Service Connect.

O cliente que se conecta ao endpoint do Private Service Connect pode estar na mesma região do endpoint ou em uma região diferente. Essa abordagem pode ser usada para fornecer alta disponibilidade em serviços hospedados em várias regiões ou para acessar serviços disponíveis em uma única região de outras regiões. Quando um endpoint do Private Service Connect é acessado por recursos hospedados em outras regiões, as cobranças de saída inter-regionais se aplicam ao tráfego destinado a endpoints com acesso global.

Práticas recomendadas

  • Considere o Apigee e o Apigee Hybrid como sua solução de plataforma de API, que oferece vários benefícios. Ela oferece uma camada de proxy e uma abstração ou fachada para as APIs de serviço de back-end, combinadas com recursos de segurança, limitação de taxa, cotas e análises.
  • O design de VPCs e projetos no Google Cloud precisa ser orientado pela hierarquia de recursos e pelos requisitos do modelo de comunicação segura.
  • Quando APIs com gateways de API são usadas, você também precisa usar uma lista de permissões de endereços IP. Uma lista de permissões limita as comunicações às origens e destinos de endereços IP específicos dos consumidores e gateways de API que podem ser hospedados em ambientes diferentes.
  • Use regras de firewall da VPC ou políticas de firewall para controlar o acesso aos recursos do Private Service Connect pelo endpoint do Private Service Connect.
  • Se um aplicativo for exposto externamente por um balanceador de carga, use o Google Cloud Armor como uma camada extra de segurança para se proteger contra ameaças de segurança da camada do aplicativo e DDoS.
  • Se as instâncias exigirem acesso à Internet, use o Cloud NAT na VPC do aplicativo (consumidor) para permitir que as cargas de trabalho acessem a Internet. Ao fazer isso, você evita atribuir instâncias de VM com endereços IP públicos externos em sistemas implantados por trás de um gateway de API ou um balanceador de carga.

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

Entrada controlada

A arquitetura do padrão de entrada controlada é baseada na exposição de dados APIs de cargas de trabalho em execução no Google Cloud ao ambiente de computação particular sem expô-los à Internet pública. Esse padrão é a contraparte do padrão de saída controlada e é adequado para híbrido de borda, híbrido em camadas e multicloud particionada para cenários de direção reais.

Assim como no padrão de saída controlada, é possível facilitar essa exposição limitada. por um gateway de API ou balanceador de carga funciona como fachada para cargas de trabalho ou serviços atuais. Ao fazer isso, eles ficam acessíveis para aplicativos de computação em nuvem, ambientes no local ou em outro ambiente de nuvem, da seguinte forma:

  • as cargas de trabalho implantadas no ambiente de computação particular ou em outros ambientes de nuvem são capazes de se comunicar com o gateway de API ou carregar do balanceador de carga usando endereços IP internos. Outros sistemas implantados em Google Cloud não podem ser acessados.
  • Não é permitida a comunicação de Google Cloud com o ambiente de computação particular ou com outros ambientes de nuvem. O tráfego é apenas iniciadas do ambiente privado ou de outros ambientes de nuvem para o APIs em Google Cloud.

Arquitetura

O diagrama a seguir mostra uma arquitetura de referência que atende ao do padrão de entrada controlado.

Dados que fluem em uma direção de um ambiente local ou de uma nuvem por meio de um Cloud VPN ou Cloud Interconnect para um ambiente Google Cloud e acabam em uma carga de trabalho.

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

  • No lado do Google Cloud , você implanta cargas de trabalho em uma VPC de aplicativo (ou várias).
  • A rede do ambiente Google Cloud se estende a outros ambientes de computação (no local ou em outra nuvem) usando conectividade de rede híbrida ou multinuvem para facilitar a comunicação entre ambientes.
  • Também é possível usar uma VPC de trânsito para fazer o seguinte:
    • Oferecer camadas de segurança de perímetro extras para permitir acesso fora da VPC do seu aplicativo.
    • Encaminhar o tráfego para os endereços IP das APIs. Você pode criar Regras de firewall da VPC para impedir que algumas origens acessem determinadas APIs por um endpoint.
    • Inspecione o tráfego da camada 7 na VPC de trânsito integrando um o dispositivo virtual de rede (NVA, na sigla em inglês).
  • Acessar as APIs por meio de um gateway de API ou balanceador de carga (proxy ou balanceador de carga de aplicativo) para fornecer uma camada de proxy e uma abstração ou fachada das suas APIs de serviço. Se você precisar distribuir o tráfego em várias instâncias de gateway de API, use um Balanceador de carga de rede de passagem interna.
  • fornecem acesso limitado e refinado a um serviço por meio de um endpoint do Private Service Connect usando um balanceador de carga pelo Private Service Connect para expor um aplicativo ou serviço.
  • Todos os ambientes devem usar um espaço de endereços IP RFC 1918 sem sobreposição.

O diagrama a seguir ilustra o design desse padrão usando Apigee como a plataforma da API.

Os dados fluem para um ambiente Google Cloud e são entregues em um projeto em uma instância da Apigee a partir de um ambiente local ou na nuvem por um Cloud VPN ou Cloud Interconnect.

No diagrama anterior, usar a Apigee como plataforma de API mostra as os seguintes recursos para permitir o padrão de entrada controlada:

  • Funcionalidade de gateway ou proxy
  • Recursos de segurança
  • Limitação de taxa
  • Análise

No design:

  • A conectividade de rede no sentido norte (para o tráfego proveniente de outros ambientes) passa por uma instância do Private Service Connect endpoint na VPC do seu aplicativo que é associados à VPC da Apigee.
  • Na VPC do aplicativo, um balanceador de carga interno é usado para expor as APIs de aplicativo por meio de um endpoint do Private Service Connect apresentados na VPC da Apigee. Para mais informações, consulte Arquitetura com o peering de VPC desativado.
  • Configurar regras de firewall e filtragem de tráfego na VPC do aplicativo. Assim, você tem acesso controlado e refinado. Isso também ajuda a parar os sistemas cheguem aos aplicativos sem passar pelo no endpoint do Private Service Connect e no gateway de API.

    Além disso, é possível restringir a divulgação do endereço IP encaminhar a sub-rede da carga de trabalho de back-end na VPC do aplicativo ao rede no local para evitar a acessibilidade direta sem passar usando o endpoint do Private Service Connect e a API gateway de gateway de borda.

Certos requisitos de segurança podem exigir inspeção de segurança de perímetro fora da VPC do aplicativo, incluindo o tráfego de conectividade híbrida. Em tal casos, é possível incorporar uma VPC de trânsito para implementar mais medidas camadas. Essas camadas, como NVAs com firewalls de próxima geração (NGFWs, na sigla em inglês) com várias interfaces de rede, ou Cloud Next Generation Firewall Enterprise serviço de prevenção de intrusões (IPS), realize uma inspeção profunda de pacotes fora da sua VPC do aplicativo, conforme ilustrado no diagrama a seguir:

Os dados fluem para um ambiente Google Cloud e são entregues a um aplicativo de um ambiente local ou na nuvem por uma Cloud VPN ou Cloud Interconnect.

Conforme ilustrado no diagrama anterior:

  • A conectividade de rede no sentido norte (para o tráfego proveniente de outros ambientes) passa por uma VPC de trânsito separada Endpoint do Private Service Connect na VPC de trânsito associada à VPC da Apigee.
  • Na VPC do aplicativo, um balanceador de carga interno (ILB no diagrama) é usada para expor o aplicativo por uma Endpoint do Private Service Connect na Apigee VPC.

É possível provisionar vários endpoints na mesma rede VPC, como mostrado no no diagrama a seguir. Para abordar diferentes casos de uso, é possível controlar os diferentes caminhos de rede possíveis com o Cloud Router e às regras de firewall da VPC. Por exemplo, se você conectar uma rede local ao Google Cloud usando várias conexões de rede híbrida, poderá enviar parte do tráfego do local para APIs ou serviços publicados específicos do Google em uma conexão e o restante em outra. Além disso, é possível usar o Acesso global ao Private Service Connect para fornecer opções de failover.

Os dados fluem para um ambiente Google Cloud e são entregues por vários endpoints do Private Service Connect para várias VPCs produtoras de um ambiente local ou na nuvem por meio do Cloud VPN ou do Cloud Interconnect.

Variações

O padrão de arquitetura de entrada controlada pode ser combinado com outras abordagens atender a diferentes requisitos de design, mas sem deixar de considerar a comunicação do padrão. O padrão oferece as seguintes opções:

Acessar as APIs do Google em outros ambientes

Para cenários que exigem acesso a serviços do Google, como Cloud Storage ou o BigQuery sem enviar tráfego pela Internet pública, O Private Service Connect oferece uma solução. Como mostrado no diagrama abaixo, ele permite a acessibilidade às APIs do Google com suporte e aos serviços (incluindo o Google Maps, o Google Ads e o Google Cloud) em ambientes locais ou em nuvem por uma conexão de rede híbrida usando o endereço IP do endpoint do Private Service Connect. Para mais informações sobre como acessar as APIs do Google pelos endpoints do Private Service Connect, consulte Sobre como acessar APIs do Google por endpoints.

Os dados fluem de um ambiente local para os serviços do Google em um ambiente Google Cloud .

No diagrama anterior, sua rede local precisa estar conectada à rede VPC de trânsito (consumidor) usando túneis do Cloud VPN ou um Anexo da VLAN do Cloud Interconnect.

As APIs do Google podem ser acessadas usando endpoints ou back-ends. Com os endpoints, você segmenta um pacote de APIs do Google. Os back-ends permitem segmentar uma API regional do Google.

Expor back-ends de aplicativos a outros ambientes usando o Private Service Connect

Em cenários específicos, como destacado pelo padrão híbrido em camadas, é possível implantar back-ends no Google Cloud e manter os front-ends em ambientes computacionais particulares. Embora menos comum, essa abordagem ao lidar com front-ends monolíticos e pesados que dependem de recursos componentes. Ou, mais comumente, ao gerenciar aplicativos distribuídos em vários ambientes, inclusive ambientes locais e outras nuvens, que exigem conectividade com back-ends hospedados no Google Cloud em uma rede híbrida.

Nessa arquitetura, é possível usar um gateway de API local ou um balanceador de carga no no local particular ou outros ambientes de nuvem para expor diretamente o front-end do aplicativo para a Internet pública. Usando o Private Service Connect em Google Cloud , você facilita a conectividade privada aos back-ends expostos por meio de um endpoint do Private Service Connect, de preferência com APIs predefinidas, conforme ilustrado no diagrama a seguir:

Os dados fluem de um ambiente local ou de outro ambiente de nuvem para um ambiente Google Cloud . Os dados fluem por uma instância da Apigee e um serviço de front-end no ambiente que não éGoogle Cloud e acabam em uma VPC de aplicativo do projeto do cliente.

O design no diagrama anterior usa uma implantação da Apigee híbrida que consiste em um plano de gerenciamento no Google Cloud e um plano de ambiente de execução hospedado no outro ambiente. Instale e gerencie o ambiente de execução em um gateway de API distribuído em uma das plataformas do Kubernetes com suporte no ambiente local ou em outros ambientes de nuvem. Com base em seus requisitos para cargas de trabalho distribuídas em Google Cloud e outros ambientes, é possível usar a Apigee em Google Cloud com a Apigee híbrida. Para mais informações, consulte Gateways de API distribuídos.

Usar uma arquitetura de hub e spoke para expor back-ends de aplicativos a outros ambientes

A exposição de APIs de back-ends de aplicativos hospedados em Google Cloud em diferentes redes VPC pode ser necessária em determinados cenários. Conforme ilustrado em no diagrama a seguir, uma VPC hub serve como ponto central de interconexão para as várias VPCs (spokes), permitindo uma comunicação segura por e conectividade. Opcionalmente, recursos de gateway de API local em outros ambientes, como Apigee híbrida, podem ser usados para encerrar solicitações de clientes localmente onde o front-end do aplicativo está hospedado.

Os dados fluem entre um ambiente Google Cloud e um ambiente local ou outro ambiente de nuvem e expõem APIs de back-ends de aplicativos hospedados em Google Cloud em diferentes redes VPC.

Conforme ilustrado no diagrama anterior:

  • Para fornecer capacidades de inspeção de NGFW adicionais na camada 7, o NVA com Os recursos de NGFW têm a opção de ser integrados ao design. Você pode exigem que essas habilidades obedeçam a requisitos de segurança e os padrões de políticas de segurança da sua organização.
  • O modelo pressupõe que as VPCs spoke não exigem VPC direta para VPC da comunicação entre serviços.

    • Se a comunicação spoke-to-spoke for necessária, use a função NVA para facilitar essa comunicação.
    • Se você tiver back-ends diferentes em VPCs diferentes, será possível usar Private Service Connect para expor esses back-ends à VPC da Apigee.
    • Se o peering de VPC for usado nos sentidos norte e sul entre as VPCs spoke e a VPC hub, precisa considerar limitação de transitividade da rede VPC sobre peering de VPC. Para superar essa limitação, você pode usar qualquer uma das seguintes opções:
      • Para interconectar as VPCs, use um NVA (em inglês).
      • Quando aplicável, use o Private Service Connect modelo do PyTorch.
      • Para estabelecer a conectividade entre a VPC da Apigee e os back-ends que estão localizados em outros projetosGoogle Cloud na mesma organização sem outros componentes de rede, use a VPC compartilhada.
  • Se os NVAs forem necessários para a inspeção de tráfego, incluindo o tráfego da sua em outros ambientes, ou seja, a conectividade híbrida com ambientes devem ser encerrados na VPC de trânsito híbrido.

  • Se o design não incluir o NVA, encerre o ambiente e conectividade na VPC do hub.

  • Se certas funcionalidades de balanceamento de carga ou recursos de segurança estiverem necessários, como adicionar a proteção contra DDoS do Google Cloud Armor, ou WAF, um balanceador de carga de aplicativo externo no perímetro pode ser implantado por um antes de rotear solicitações de clientes externos para os back-ends.

Práticas recomendadas

  • Para situações em que as solicitações de clientes da Internet precisam ser recebidos localmente por um front-end hospedado em uma rede local de nuvem híbrida, use a Apigee híbrida como API de gateway de borda. Essa abordagem também facilita a migração da solução para um ambiente totalmente hospedado no Google Cloud, mantendo a consistência da plataforma de API (Apigee).
  • Use o adaptador da Apigee para Envoy com um Implantação da Apigee híbrida com o Kubernetes arquitetura, quando aplicável aos seus requisitos e à arquitetura.
  • O design de VPCs e projetos no Google Cloud deve seguir a hierarquia de recursos e os requisitos do modelo de comunicação seguro, descritas neste guia.
  • A incorporação de uma VPC de trânsito nesse design oferece a flexibilidade de provisionar mais medidas de segurança de perímetro e conectividade híbrida fora da VPC de carga de trabalho.
  • Usar o Private Service Connect para acessar as APIs e e serviços em ambientes locais ou em outros ambientes de nuvem usando o endereço IP interno o endpoint em uma rede de conectividade híbrida. Para mais informações, consulte Acessar o endpoint de hosts locais.
  • Para ajudar a proteger os serviços Google Cloud nos seus projetos e mitigar o risco de exfiltração de dados, use o VPC Service Controls para especificar perímetros de serviço no nível do projeto ou da rede VPC.
  • Usar Regras de firewall da VPC ou políticas de firewall para controlar o acesso no nível da rede aos recursos do Private Service Connect usando o endpoint do Private Service Connect. Por exemplo: regras de firewall de saída na VPC do aplicativo (consumidor) pode restringir o acesso das instâncias de VM o endereço IP ou a sub-rede dos endpoints. Para mais informações sobre regras de firewall da VPC em geral, consulte Regras de firewall da VPC.
  • Ao projetar uma solução que inclua NVAs, é importante considerar a alta disponibilidade (HA) dos NVAs para evitar um ponto único de falha que possam bloquear toda a comunicação. Siga o design de alta disponibilidade e redundância as orientações de implementação fornecidas pelo fornecedor do NVA.
  • Para reforçar a segurança do perímetro e proteger seu gateway de API implantados no respectivo ambiente, é possível implementar o balanceamento de balanceamento de carga e de aplicativos da Web nos outros sistemas (ambiente híbrido ou outra nuvem). Implemente essas opções no do perímetro de serviço diretamente conectada à Internet.
  • Se as instâncias exigirem acesso à Internet, use Cloud NAT na VPC do aplicativo para que as cargas de trabalho acessem a Internet. Ao fazer isso evita a atribuição de instâncias de VM com endereços IP públicos externos implantados por trás de um gateway de API ou balanceador de carga.
  • Para tráfego de saída da Web, use Proxy seguro da Web. O proxy oferece vários benefícios.
  • Consulte a práticas recomendadas gerais para padrões de rede híbridos e multicloud.

Saída e entrada controladas

Os padrões de saída controlada e entrada controlada usam uma combinação de saída controlada e entrada controlada para cenários que exigem o uso bidirecional de APIs selecionadas entre as cargas de trabalho. As cargas de trabalho podem ser executadas em Google Cloud, em ambientes locais privados ou em outros ambientes de nuvem. Nesse padrão, é possível gateways de API, endpoints 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 esse padrão e o padrão em malha aplica-se a cenários que exigem apenas o uso de API bidirecional ou comunicação com origens e destinos específicos de endereços IP, por exemplo, um aplicativo publicado por um endpoint do Private Service Connect. Como a comunicação é restrita às APIs expostas ou a endereços IP específicos, as redes em ambientes não precisam se alinhar ao seu design. Cenários comuns aplicáveis incluem, sem limitação:

  • Fusões e aquisições.
  • Integrações de aplicativos com parceiros.
  • Integrações entre aplicativos e serviços de uma organização com diferentes unidades organizacionais que gerenciam os próprios aplicativos e hospedam em ambientes diferentes.

A comunicação funciona da seguinte maneira:

  • As cargas de trabalho implantadas no Google Cloud podem se comunicar com o gateway de API (ou endereços IP de destino específicos) usando endereços IP internos. Outros sistemas implantados no ambiente de computação particular não pode ser contatados.
  • Por outro lado, as cargas de trabalho implantadas em outros ambientes de computação podem se comunicar com o gateway de API do Google Cloud(ou um endereço IP de endpoint publicado) usando endereços IP internos. Outros sistemas implantados em Google Cloud não podem ser acessados.

Arquitetura

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

Entradas e saídas de dados entre Google Cloud e uma rede local ou outra rede em nuvem.

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

  • No lado do Google Cloud , você implanta cargas de trabalho em uma VPC (ou VPC compartilhada) sem expô-las diretamente à Internet.
  • A rede do ambiente Google Cloud é estendida para outros ambientes de computação. Esse ambiente pode estar no local ou em outra nuvem. Para estender o ambiente, use um padrão de comunicação de conectividade híbrida e de várias nuvens adequado para facilitar a comunicação entre os ambientes para que eles possam usar endereços IP internos.
  • Outra opção é ativar o acesso a endereços IP de destino específicos. Você pode usar uma VPC de trânsito para adicionar uma camada de segurança de perímetro fora do VPC do aplicativo.
    • Você pode usar o Cloud Next Generation Firewall ou dispositivos virtuais de rede (NVAs, na sigla em inglês) com firewalls de última geração (NGFWs) na VPC de trânsito para inspecionar o tráfego e permitir ou proibir o acesso a determinadas APIs por meio de origens específicas antes de chegar à VPC do seu aplicativo.
  • É preciso acessar as APIs por um gateway de API ou balanceador de carga para fornecer uma camada de proxy e uma abstração ou fachada para as suas APIs de serviço.
  • Para aplicativos consumidos como APIs, você também pode usar o Private Service Connect para fornecer um endereço IP interno do aplicativo publicado.
  • Todos os ambientes usam o espaço de endereço IP RFC 1918 sem sobreposição.

Uma aplicação comum desse padrão envolve a implantação de back-ends de aplicativos (ou um subconjunto de back-ends de aplicativos) em Google Cloud , enquanto hospeda outros componentes de back-end e front-end em ambientes locais ou em outras nuvens (padrão híbrido em camadas ou padrão multicloud particionado). À medida que os aplicativos evoluem e migram para a nuvem, as dependências e preferências de serviços em nuvem específicos geralmente surgem.

Às vezes, essas dependências e preferências levam à distribuição de aplicativos e back-ends em diferentes provedores de nuvem. Além disso, alguns aplicativos podem ser criados com uma combinação de recursos e serviços distribuídos em ambientes no local e em várias nuvens.

Para aplicativos distribuídos, os recursos da conectividade externa híbrida e de multicloud do Cloud Load Balancing podem ser usados para encerrar solicitações de usuários e encaminhá-las para front-ends ou back-ends em outros ambientes. Esse roteamento ocorre em uma conexão de rede híbrida, conforme ilustrado no diagrama a seguir. Essa integração permite a a distribuição de componentes de aplicativos em diferentes ambientes. As solicitações do front-end para os serviços de back-end hospedados no Google Cloud se comunicam com segurança na conexão de rede híbrida estabelecida, facilitada por um balanceador de carga interno (ILB no diagrama).

Entradas e saídas de dados entre o front-end de um aplicativo em um ambiente local ou outro ambiente de nuvem e o back-end de um aplicativo em um ambiente Google Cloud . Os dados fluem por um balanceador de carga interno (ILB) em Google Cloud.

Usar o design Google Cloud no diagrama anterior ajuda no seguinte:

  • Facilita a comunicação bidirecional entre Google Cloud, ambientes no local e outros ambientes de nuvem usando APIs predefinidas em ambos os lados que se alinham com o modelo de comunicação desse padrão.
  • Para fornecer front-ends globais para aplicativos voltados à Internet com componentes de aplicativo distribuídos (front-ends ou back-ends) e para atingir as metas a seguir, use os recursos de balanceamento e segurança avançados do Google Cloud distribuídos em pontos de presença (PoPs, na sigla em inglês):
  • Reduzir as despesas de capital e simplificar as operações usando serviços gerenciados sem servidor.
  • Otimizar conexões com back-ends de aplicativos globalmente para aumentar a velocidade e latência.
    • Google Cloud O Cross-Cloud Network do Google Cloud permite a comunicação em várias nuvens entre componentes de aplicativos em conexões privadas ideais.
  • Armazenar em cache conteúdo estático de alta demanda e melhorar o desempenho dos aplicativos que usam o Cloud Load Balancing global fornecendo acesso ao Cloud CDN.
  • Proteger os front-ends globais dos aplicativos voltados à Internet usando os recursos do Google Cloud Armor que oferecem serviços de firewall de aplicativos da Web (WAF) e mitigação de DDoS distribuídos globalmente.
  • Outra opção é incorporar o Private Service Connect ao seu design. Isso permite acesso particular e refinado às APIs de serviço do Google Cloud ou aos seus serviços publicados de outros ambientes sem passar pela Internet pública.

Variações

Os padrões de arquitetura de saída controlada e entrada controlada podem ser combinados com outras abordagens para atender a diferentes requisitos de design, sem deixar de considerar os requisitos de comunicação desse padrão. Os padrões oferecem os seguintes opções:

Gateways de API distribuídos

Em cenários como o baseado no padrão de várias nuvens particionadas, aplicativos (ou componentes de aplicativos) podem ser criados em diferentes do Google Cloud, incluindo um ambiente particular no local. O requisito comum é encaminhar as solicitações de clientes para o front-end do aplicativo diretamente para o ambiente em que o aplicativo ou o componente de front-end está hospedado. Esta desse tipo de comunicação requer um balanceador de carga local ou um gateway de API. Esses aplicativos e os respectivos componentes também podem exigir uma plataforma de API específica recursos de integração.

O diagrama a seguir ilustra como a Apigee e Apigee híbrida foram projetados para atender a esses requisitos com um gateway de API localizado em cada ambiente de execução. O gerenciamento da plataforma de API é centralizado em Google Cloud. Esse design ajuda a aplicar medidas de controle de acesso estritas em que apenas endereços IP pré-aprovados (APIs de destino e de destino ou endereços IP de endpoint do Private Service Connect) podem se comunicar entre Google Cloud e os outros ambientes.

Entradas e saídas de dados entre um ambiente local ou outro ambiente de nuvem e um ambiente Google Cloud . As solicitações do cliente para o front-end do aplicativo vão diretamente para o ambiente onde o aplicativo (ou o componente de front-end) está hospedado.

A lista a seguir descreve as duas instâncias caminhos de comunicação no diagrama anterior que usam Apigee Gateway de API:

  • As solicitações do cliente chegam ao front-end do aplicativo diretamente na o ambiente que hospeda o aplicativo ou o componente do front-end.
  • Os gateways e proxies de API em cada ambiente lidam com clientes e solicitações de API do aplicativo em direções diferentes em vários do Google Cloud.
    • A funcionalidade de gateway de API em Google Cloud (Apigee) expõe o aplicativo (front-end ou back-end) e componentes hospedados em Google Cloud.
    • A funcionalidade de gateway de API em outro ambiente (Híbrido) expõe o front-end do aplicativo (ou back-end) que estão hospedados nesse ambiente.

Outra opção é usar uma VPC de trânsito. Uma VPC de trânsito pode fornecer flexibilidade para separar preocupações e realizar inspeção de segurança e implantações em uma rede VPC separada. A partir de um endereço IP acessível uma VPC de trânsito, com conectividade híbrida facilita os seguintes requisitos para manter a acessibilidade de ponta a ponta:

  • Os endereços IP das APIs de destino precisam ser anunciados para a outra ambientes onde os clientes/solicitantes estão hospedados.
  • Os endereços IP dos hosts que precisam se comunicar com o destino. As APIs precisam ser anunciadas para o ambiente onde a API de destino reside, por exemplo, os endereços IP do solicitante da API (o cliente). O é quando a comunicação ocorre por um balanceador de carga, um proxy endpoint do Private Service Connect ou instância NAT.

Para ampliar a conectividade ao ambiente remoto, este projeto usa VPC direta peering com troca de rota do cliente capacidade de processamento. O design permite que solicitações de API específicas que se originam de cargas de trabalho hospedadas na VPC do aplicativo Google Cloud sejam roteadas pela VPC de trânsito. Como alternativa, é possível usar um endpoint do Private Service Connect em a VPC do aplicativo associada a uma carga com um back-end de grupo de endpoints de rede híbrido na VPC de trânsito. Aquele está descrito na próxima seção: Comunicação de API bidirecional usando Private Service Connect.

Comunicação bidirecional de API com o Private Service Connect

Às vezes, as empresas podem não precisar usar um gateway de API (como Apigee) imediatamente, ou pode querer adicioná-la mais tarde. No entanto, pode haver requisitos de negócios para permitem a comunicação e a integração entre certos aplicativos em diferentes do Google Cloud. Por exemplo, se sua empresa adquiriu outra empresa, você pode precisaria expor certos aplicativos a essa empresa. Eles podem precisar expor aplicativos para sua empresa. Ambas as empresas podem ter cargas de trabalho próprias hospedadas em ambientes diferentes (Google Cloud, no local ou em outras nuvens) e evitar sobreposições de endereços IP. Nesses casos, você pode usar Private Service Connect para facilitar a comunicação eficaz.

Para aplicativos consumidos como APIs, você também pode usar o Private Service Connect para fornecer um endereço particular para os aplicativos publicados, o que permite o acesso seguro no ambiente de rede entre regiões e em conectividade híbrida. Essa abstração facilita a integração de recursos locais e de nuvens diversas ambientes em um modelo de conectividade híbrido e de multicloud. Ele também permite a montagem de aplicativos em ambientes locais e multicloud. Isso pode satisfazer diferentes requisitos de comunicação, como a integração aplicativos em que um gateway de API não é usado ou não está planejado para ser usado.

Usando o Private Service Connect com o Cloud Load Balancing, conforme mostrado a seguir: é possível estabelecer dois caminhos de comunicação distintos. Cada caminho iniciado de uma direção diferente para uma finalidade de conectividade separada; idealmente por chamadas de API.

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

Os ambientes no local ou em outras nuvens e um ambiente Google Cloud comunicam dados por diferentes caminhos e balanceadores de carga, endpoints VPC e sub-redes.

Os dois caminhos de conectividade descritos no diagrama anterior representam conexões independentes e não ilustram a comunicação bidirecional de um único uma conexão ou fluxo.

Comunicação bidirecional usando endpoints e interfaces do Private Service Connect

Conforme discutido nas padrão de entrada controlado, uma das opções para ativar a comunicação entre serviços e cliente é usar um Endpoint do Private Service Connect para expor um serviço em um produtor VPC para uma VPC do consumidor. Aquele a conectividade pode ser estendida a um ambiente no local ou até mesmo de nuvem do provedor em uma conectividade híbrida. No entanto, em alguns cenários, e o serviço hospedado podem exigir comunicação particular.

Para acessar um determinado serviço, como recuperar dados de fontes que podem ser hospedadas dentro ou fora da VPC do consumidor, essa comunicação privada pode ser entre a VPC do aplicativo (produtor) e um ambiente remoto, como local.

Nesse cenário, Interfaces do Private Service Connect permitem que uma instância de VM do produtor de serviços acesse a rede de um consumidor. Ele faz isso compartilhando uma interface de rede, mantendo a separação das funções de produtor e consumidor. Com essa interface de rede VPC do consumidor, a VM do aplicativo pode acessar os recursos do consumidor como se eles que residem localmente na VPC do produtor.

Uma interface do Private Service Connect é uma interface de rede anexadas à VPC do consumidor (transit). É possível alcançar pessoas que podem ser acessados pela VPC do consumidor (transporte), em que o A interface do Private Service Connect está anexada. Portanto, essa conexão pode ser estendida para um ambiente externo por meio de uma conectividade híbrida, como um ambiente local, conforme ilustrado nas diagrama a seguir:

Entradas e saídas de dados entre um aplicativo em Google Cloud e uma carga de trabalho em uma rede local ou outra rede em nuvem.

Se a VPC do consumidor for uma organização ou entidade externa, como um organização, normalmente você não terá a capacidade de proteger a comunicação à interface do Private Service Connect na VPC do consumidor. Em neste cenário, é possível definir políticas de segurança no SO convidado da VM da interface do Private Service Connect. Para mais informações, ver Configure a segurança das interfaces do Private Service Connect. Ou você pode considerar uma abordagem alternativa se ela não estiver em conformidade com compliance ou padrões de segurança da sua organização.

Práticas recomendadas

  • Para situações em que as solicitações de clientes da Internet precisam ser recebidos localmente por um front-end hospedado em uma rede local de nuvem híbrida, considere usar o modelo híbrido de gateway de borda.

    • Essa abordagem também facilita a migração da solução para um ambiente totalmente hospedado no Google Cloud, mantendo a consistência da plataforma de API (Apigee).
  • Para minimizar a latência e otimizar os custos de grandes volumes de dados de saída para seus outros ambientes quando eles estiverem em as configurações híbridas ou de várias nuvens permanentes ou de longo prazo:

    • Usar o Cloud Interconnect ou o Cross-Cloud Interconnect.
    • Para encerrar conexões de usuário no front-end de destino na ambiente apropriado, use Híbrido:
  • Quando aplicável aos seus requisitos e à arquitetura, use Adaptador da Apigee para Envoy com um Implantação híbrida com o Kubernetes.

  • Antes de projetar a conectividade e os caminhos de roteamento, você precisa identificar qual tráfego ou solicitações de API precisam ser direcionados a um local ou gateway de API remoto, além dos ambientes de origem e destino.

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

  • Usar Regras de firewall da nuvem privada virtual (VPC) ou políticas de firewall para controlar o acesso aos recursos no Private Service Connect no nível da rede usando o endpoint do Private Service Connect. Por exemplo: regras de firewall de saída na VPC do aplicativo (consumidor) pode restringir o acesso das instâncias de VM o endereço IP ou a sub-rede dos endpoints.

  • Ao usar uma interface do Private Service Connect, é preciso para proteger a comunicação do Terraform. Para isso, configure a segurança do Interface do Private Service Connect.

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

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

Padrões de entrega

Com o padrão de handover, a arquitetura é baseada no uso de serviços de armazenamento fornecidos peloGoogle Cloudpara conectar um ambiente de computação privado a projetos no Google Cloud. Esse padrão se aplica principalmente às configurações que seguem o padrão de arquitetura multicloud híbrida de análise, em que:

  • As cargas de trabalho em execução em um ambiente de computação privado ou em outra nuvem fazem o upload de dados para locais de armazenamento compartilhado. Dependendo dos casos de uso, os uploads podem ocorrer em massa ou em incrementos menores.
  • Cargas de trabalho hospedadas peloGoogle Cloudou outros serviços do Google (por exemplo, análises de dados e serviços de inteligência artificial) consomem dados dos locais de armazenamento compartilhado e os processam em streaming ou em lote.

Arquitetura

O diagrama a seguir mostra uma arquitetura de referência para o padrão de handover.

Os dados fluem de um ambiente local para uma carga de trabalho hospedada em VPC e um serviço de análise de dados hospedado em um ambiente Google Cloud .

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

  • No lado do Google Cloud , você implanta cargas de trabalho em uma VPC de aplicativo. Essas cargas de trabalho podem incluir processamento de dados, análises e aplicativos front-end relacionados à análise.
  • Para expor aplicativos front-end com segurança aos usuários, você pode usar o Cloud Load Balancing ou o gateway de API.
  • Um conjunto de buckets do Cloud Storage ou filas do Pub/Sub faz o upload dos dados do ambiente de computação particular e os disponibiliza para processamento por cargas de trabalho implantadas no Google Cloud. Usando as políticas do Identity and Access Management (IAM), é possível restringir o acesso a cargas de trabalho confiáveis.
  • Use o VPC Service Controls para restringir o acesso a serviços e minimizar riscos de exfiltração de dados injustificados de Google Cloud serviços.
  • Nesta arquitetura, a comunicação com buckets do Cloud Storage ou do Pub/Sub é realizada em redes públicas ou pela conectividade privada usando VPN, Cloud Interconnect ou Cross-Cloud Interconnect. Normalmente, a decisão sobre como se conectar depende de vários aspectos, como:
    • Volume de tráfego esperado
    • 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 controlado, que usa endpoints do Private Service Connect para APIs do Google, também podem ser aplicadas a esse padrão. Especificamente, ele dá acesso ao Cloud Storage, BigQuery, e outras APIs de serviços do Google. Essa abordagem requer um endereçamento IP privado em uma conexão de rede híbrida e multicloud, como VPN, Cloud Interconnect e Cross-Cloud Interconnect.

Práticas recomendadas

  • Bloqueie o acesso a buckets do Cloud Storage e tópicos do Pub/Sub.
  • Quando aplicável, use soluções de movimentação de dados integradas e com priorização da nuvem como o Google Cloud pacote de soluções. Para atender às suas necessidades de caso de uso, essas soluções foram projetadas para mover, integrar e transformar os dados com eficiência.
  • Avalie os diferentes fatores que influenciam as opções de transferência de dados como custo, tempo esperado de transferência e segurança. Para mais informações, consulte Avaliando as opções de transferência.

  • Para minimizar a latência e evitar a transferência e a movimentação de alto volume de dados na Internet pública, use o Cloud Interconnect ou Cross-Cloud Interconnect, incluindo o acesso aos endpoints do Private Service Connect na nuvem privada virtual para APIs do Google.

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

  • Comunique-se com cargas de trabalho de análise de dados veiculadas publicamente que são hospedadas em instâncias de VM usando um gateway de API, um balanceador de carga ou um dispositivo de rede virtual. Use um desses métodos de comunicação para aumentar a segurança e evitar tornar essas instâncias diretamente acessíveis na Internet.

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

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

Práticas recomendadas gerais

Ao projetar e integrar identidades na nuvem, hierarquia de recursos e redes de zonas de destino, considere as recomendações de design no Design da zona de destino no Google Cloud e as práticas recomendadas de Google Cloud segurança abordadas no Blueprint de bases empresariais. Valide o design selecionado com base nos seguintes documentos:

Considere também as seguintes práticas gerais recomendadas:

Padrões de arquitetura de rede segura híbrida e multicloud: próximas etapas