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:
- Saud Albazei | Engenheiro de clientes, modernização de aplicativos
- Anna Berenberg | Pesquisadora de engenharia
- Marco Ferrari | Arquiteto de soluções do Cloud
- Victor Moreno | Gerente de produtos, Cloud Networking
- Johannes Passing | Arquiteto de soluções na nuvem
- Mark Schlagenhauf | Redator técnico, Rede
- Daniel Strebel | Líder de soluções na EMEA, modernização de aplicativos
- Ammett Williams | Engenheiro de relações com desenvolvedores
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:
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
- Firewall de camada do aplicativo centralizado
- Topologia hub-and-spoke
- Arquitetura distribuída de microsserviços de confiança zero
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:
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.
Esse design também pode ser usado com várias VPCs compartilhadas, conforme ilustrado no diagrama a seguir.
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.
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)
- Com várias interfaces de rede
- Com o Network Connectivity Center (NCC)
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.
Para mais informações sobre esse assunto, consulte os seguintes artigos:
- Arquitetura distribuída de confiança zero
- Ambiente híbrido do GKE Enterprise
- Conectar ao Google
- Conecte um cluster do GKE Enterprise local a uma redeGoogle Cloud .
- Configurar uma malha híbrida ou de várias nuvens
- Implante o Cloud Service Mesh em ambientes e clusters.
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.
- 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:
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
- Usar um firewall de camada do aplicativo centralizado
- Arquitetura distribuída de microsserviços de confiança zero
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.
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:
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:
- Saída controlada
Entrada e saída controladas (controle bidirecional em ambas as direções)
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 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:
Dispositivo virtual de rede (NVA) com recursos de inspeção de firewall de última geração (NGFW, na sigla em inglês) colocados no caminho da rede.
Cloud Next Generation Firewall Enterprise com serviço de prevenção de invasões (IPS) para implementar a inspeção detalhada de pacotes para prevenção de ameaças.
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 Google Cloud gateway de API e front-end global
- Exportar serviços remotos usando o Private Service Connect
Usar o gateway de API Google Cloud e o front-end global
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:
- Um balanceador de carga (LB no diagrama), em que as solicitações do cliente são encerradas, processa o tráfego e o encaminha para um back-end do Private Service Connect.
- Um back-end do Private Service Connect permite que um Google Cloud balanceador de carga envie solicitações de clientes por uma conexão do Private Service Connect associada a um anexo de serviço de produtor para o serviço publicado (instância do ambiente de execução do Apigee) usando grupos de endpoints de rede do Private Service Connect (NEGs, na sigla em inglês).
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
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:
- Um anexo de serviço que faz referência a um
balanceador de carga de rede de proxy interno regional
ou a um
balanceador de carga de aplicativo interno.
- O balanceador de carga usa um grupo de endpoints de rede híbrida (NEG de conectividade híbrida) em uma VPC de produtor que atua nesse design como uma VPC de trânsito.
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.
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.
- 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 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.
- Para o tráfego de saída da Web, use o Google Cloud 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.
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.
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.
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:
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.
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:
Exponha back-ends de aplicativos a outros ambientes usando o Private Service Connect
Usar uma arquitetura hub e spoke para expor back-ends de aplicativos a outros ambientes
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.
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:
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.
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.
- Quando necessário, é possível estender perímetros de serviço para um ambiente híbrido usando uma VPN 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.
- 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:
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).
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
- Comunicação bidirecional de API com o Private Service Connect
- Comunicação bidirecional usando endpoints e interfaces do Private Service Connect
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.
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 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:
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.
- 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.
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.
- Para o 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.
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.
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.
- 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.
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:
- Práticas recomendadas e arquiteturas de referência para o design da VPC
- Escolha uma hierarquia de recursos para sua Google Cloud zona de destino
- Google Cloud Framework de arquitetura: segurança, privacidade e conformidade
Considere também as seguintes práticas gerais recomendadas:
Ao escolher uma conectividade de rede híbrida ou multicloud, considere os requisitos de negócios e aplicativos, como SLAs, desempenho, segurança, custo, confiabilidade e largura de banda. Para mais informações, consulte Como escolher um produto de conectividade de rede e Padrões para conectar outros provedores de serviços de nuvem ao Google Cloud.
Use VPCs compartilhadas em Google Cloud em vez de várias VPCs quando apropriadas e alinhadas com os requisitos de design da hierarquia de recursos. Para mais informações, consulte Como decidir se você quer criar várias redes VPC.
Siga as práticas recomendadas para o planejamento de contas e organizações.
Quando aplicável, estabeleça uma identidade comum entre os ambientes para que a autenticação dos sistemas possa ser feita com segurança nos limites do ambiente.
Para expor aplicativos com segurança a usuários corporativos em uma configuração híbrida e escolher a abordagem que melhor se adapta às suas necessidades, siga as maneiras recomendadas de integrar Google Cloud ao seu sistema de gerenciamento de identidade.
- Além disso, consulte Padrões para autenticação de usuários da força de trabalho em um ambiente híbrido.
Ao projetar ambientes no local e na nuvem, considere o endereçamento IPv6 desde o início e saiba por quais serviços ele é aceito. Para mais informações, consulte Uma introdução ao IPv6 no Google Cloud. O texto resume os serviços que eram compatíveis quando o blog foi criado.
Ao projetar, implantar e gerenciar as regras de firewall da VPC, é possível:
- Usar a filtragem baseada na conta de serviço em vez da filtragem baseada em tag de rede se for necessário um controle rigoroso sobre como as regras de firewall são aplicadas às VMs.
- Usar as políticas de firewall ao agrupar várias regras de firewall, para atualizar todas elas de uma só vez. Também é possível tornar a política hierárquica. Veja detalhes e especificações da política de firewall hierárquica em Políticas de firewall hierárquicas.
- Usar os objetos de geolocalização na política de firewall para filtrar o tráfego IPv4 e IPv6 externos com base em regiões ou localizações geográficas específicas.
- Usar Inteligência contra ameaças para regras de políticas de firewall se for necessário proteger sua rede, permitindo ou bloqueando o tráfego com base nos dados da Inteligência contra ameaças, como endereços IP maliciosos conhecidos ou com base em intervalos de endereços IP de nuvem pública. Por exemplo, é possível permitir o tráfego de intervalos específicos de endereços IP de nuvem pública se os serviços precisarem se comunicar apenas com essa nuvem pública. Para mais informações, consulte Práticas recomendadas para regras de firewall.
Você deve sempre projetar a segurança da rede e da nuvem usando uma abordagem de segurança multicamadas considerando outras camadas de segurança, como estas:
- Google Cloud Armor
- Sistema de detecção de intrusões do Cloud
- IPS do Cloud Next Generation Firewall
- Inteligência contra ameaças para regras de política de firewall
Essas camadas adicionais ajudam a filtrar, inspecionar e monitorar uma grande variedade de ameaças nas camadas do aplicativo e da rede para análise e prevenção.
Ao decidir onde a resolução de DNS deve ser executada em uma configuração híbrida, recomendamos usar dois sistemas DNS autoritativos para o ambiente Google Cloud privado e para os recursos locais hospedados por servidores DNS no local. Para mais informações, consulte Escolha onde a resolução de DNS será realizada.
Sempre que possível, exponha os aplicativos em APIs usando um gateway de API ou balanceador de carga. Recomendamos considerar uma plataforma de API, como a Apigee. A Apigee atua como uma abstração ou uma fachada para as APIs de serviço de back-end, combinadas com recursos de segurança, limitação de taxa, cotas e análises.
A plataforma de API (gateway ou proxy) e o balanceador de carga de aplicativo não são mutuamente exclusivos. Às vezes, usar gateways de API e balanceadores de carga podem oferecer uma solução mais robusta e segura para gerenciar e distribuir o tráfego de APIs em grande escala. Usar os gateways da API Cloud Load Balancing permite realizar o seguinte:
Entregar APIs de alto desempenho com a Apigee e o Cloud CDN para:
- Reduzir a latência
- Hospedar APIs globalmente
Aumentar a disponibilidade em momentos de pico de tráfego
Para mais informações, assista no YouTube: Como entregar APIs de alto desempenho com a Apigee e o Cloud CDN.
Implementar o gerenciamento de tráfego avançado.
Usar o Google Cloud Armor como uma proteção contra DDoS, WAF e segurança de rede para proteger as APIs.
Gerenciar o balanceamento de carga eficiente entre gateways em várias regiões. Para mais informações, assista Como proteger as APIs e implementar o failover multirregional com a PSC e a Apigee.
Para determinar qual produto do Cloud Load Balancing deve ser usado, primeiro você precisa determinar que tipo de tráfego seus balanceadores de carga devem gerenciar. Para mais informações, consulte Escolher um balanceador de carga.
Quando o Cloud Load Balancing é usado, é preciso usar as habilidades de otimização da capacidade de aplicativo que ele oferece, quando aplicável. Isso pode ajudar a lidar com parte dos desafios da capacidade que podem ocorrer em aplicativos distribuídos globalmente.
- Para mais detalhes sobre latência, consulte Como otimizar a latência do aplicativo com balanceamento de carga.
Enquanto o Cloud VPN criptografa o tráfego entre ambientes, no Cloud Interconnect será necessário usar o MACsec ou uma VPN de alta disponibilidade para criptografar o tráfego em trânsito da camada de conectividade. Para mais informações, consulte Como criptografar o tráfego no Cloud Interconnect.
- Também é possível considerar a criptografia da camada de serviço usando a TLS. Para mais informações, veja Decida como atender aos requisitos de compliance para a criptografia em trânsito.
Se precisar de mais volume de tráfego em uma conectividade VPN híbrida do que um só túnel VPN pode suportar, use a opção roteamento de VPN de alta disponibilidade ativo/ativo.
- Para configurações de longo prazo híbridas ou multicloud com altos volumes de transferência de dados de saída, use o Cloud Interconnect ou o Cross-Cloud Interconnect. Essas opções ajudam a otimizar o desempenho da conectividade e podem reduzir os custos de transferência de dados de saída para o tráfego que atenda a determinadas condições. Para saber mais, consulte os preços do Cloud Interconnect.
Ao se conectar aos recursos do Google Cloud e escolher entre o Cloud Interconnect, o peering direto ou o peering por operadora, recomendamos usar o Cloud Interconnect, a menos que seja necessário acessar os aplicativos do Google Workspace. Para mais informações, compare os recursos do peering direto com o Cloud Interconnect e do peering por operadora com o Cloud Interconnect.
Reserve espaço suficiente do intervalo de endereços IP RFC 1918 existente para acomodar todos os sistemas hospedados em nuvem.
Se houver restrições técnicas que exijam manter o intervalo de endereços IP, você pode:
Use os mesmos endereços IP internos para cargas de trabalho no local durante a migração para Google Cloud, usando sub-redes híbridas.
Provisione e use seus próprios endereços IPv4 públicos para Google Cloud recursos usando traga seu próprio IP (BYOIP) para o Google.
Se o design da sua solução exigir a exposição de um aplicativo baseado emGoogle Cloudà Internet pública, considere as recomendações de design discutidas em Rede para entrega de aplicativos voltados para a Internet.
Quando aplicável, use os endpoints do Private Service Connect para permitir que cargas de trabalho em Google Cloud, no local ou em outro ambiente de nuvem com conectividade híbrida acessem de forma privada as APIs do Google ou serviços publicados, usando endereços IP internos de maneira refinada.
Ao usar o Private Service Connect, é preciso controlar o seguinte:
- Quem pode implantar recursos do Private Service Connect.
- Se é possível estabelecer conexões entre consumidores e produtores.
- Qual tráfego de rede tem permissão para acessar essas conexões.
Para mais informações, consulte Segurança do Private Service Connect.
Para atingir uma configuração de nuvem robusta no contexto de arquitetura híbrida e multicloud:
- Realize uma avaliação abrangente dos níveis exigidos de confiabilidade dos aplicativos em diferentes ambientes. Isso pode ajudar a atingir os objetivos de disponibilidade e resiliência.
- Entenda os recursos de confiabilidade e os princípios de design do seu provedor de nuvem. Para mais informações, consulte Google Cloud confiabilidade da infraestrutura.
A visibilidade e o monitoramento da rede em nuvem são essenciais para manter as comunicações confiáveis. O Network Intelligence Center oferece um console único para gerenciar a visibilidade, o monitoramento e a solução de problemas da rede.
Padrões de arquitetura de rede segura híbrida e multicloud: próximas etapas
- Saiba mais sobre as regras comuns padrões de arquitetura que você pode perceber usando os padrões de rede discutidos neste do documento de política.
- Saiba como abordar o padrão híbrido e em várias nuvens 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 aplicativos e usuários no local e em outras nuvens.
- Crie uma infraestrutura confiável para suas cargas de trabalho no Google Cloud: orientações de design para ajudar a proteger seus aplicativos contra falhas no nível do recurso, da zona e da região.
- Para saber mais sobre como projetar arquiteturas altamente disponíveis em Google Cloud, confira padrões para apps resilientes e escalonáveis.
- Saiba mais sobre as possíveis opções de conectividade para conectar o cluster do GKE Enterprise em execução no seu ambiente local/de borda para a Google Cloud rede, além do Impacto da desconexão temporária do Google Cloud.