Como projetar redes para migrar cargas de trabalho empresariais: abordagens de arquitetura

Last reviewed 2023-11-13 UTC

Neste documento, apresentamos uma série que descreve arquiteturas de rede e segurança para empresas que estão migrando cargas de trabalho de data center para o Google Cloud. Essas arquiteturas enfatizam a conectividade avançada, os princípios de segurança de confiança zero e o gerenciamento em um ambiente híbrido.

Conforme descrito em um documento complementar, Architectures for Protect Cloud Data Planes, as empresas implantam um espectro de arquiteturas que consideram as necessidades de conectividade e segurança na nuvem. Classificamos essas arquiteturas em três padrões de arquitetura distintos: lift-and-shift, serviços híbridos e confiança zero distribuída. Neste documento, consideramos diferentes abordagens de segurança, dependendo da arquitetura escolhida por uma empresa. Ele também descreve como realizar essas abordagens usando os elementos básicos fornecidos pelo Google Cloud. Use estas orientações de segurança em conjunto com outras orientações de arquitetura que abrangem confiabilidade, disponibilidade, escala, desempenho e governança.

Este documento foi projetado para ajudar arquitetos de sistemas, administradores de rede e administradores de segurança que planejam migrar cargas de trabalho locais para a nuvem. Ele pressupõe o seguinte:

  • Você está familiarizado com os conceitos de rede e de segurança do data center.
  • Você tem cargas de trabalho no data center local e sabe o que elas fazem e quem são os usuários.
  • Você tem pelo menos algumas cargas de trabalho que pretende migrar.
  • Geralmente, você conhece os conceitos descritos em Architectures for Protect Cloud Data Planes.

A série inclui os documentos a seguir:

Este documento resume os três principais padrões de arquitetura e apresenta os elementos básicos de recursos que podem ser usados para criar sua infraestrutura. Por fim, ele descreve como montar os elementos básicos em uma série de arquiteturas de referência que correspondem aos padrões. É possível usar essas arquiteturas de referência para orientar sua própria arquitetura.

Neste documento, mencionamos as máquinas virtuais (VMs) como exemplos de recursos de carga de trabalho. As informações se aplicam a outros recursos que usam redes VPC, como instâncias do Cloud SQL e nós do Google Kubernetes Engine.

Visão geral de padrões de arquitetura

Normalmente, os engenheiros de rede se concentram em criar a infraestrutura de rede física e a infraestrutura de segurança em data centers locais.

A jornada para a nuvem mudou essa abordagem porque os edifícios das redes em nuvem são definidos por software. Na nuvem, os proprietários de aplicativos têm controle limitado da pilha de infraestrutura subjacente. Eles precisam de um modelo que tenha um perímetro seguro e forneça isolamento para as cargas de trabalho.

Nesta série, consideramos três padrões comuns de arquitetura. Esses padrões são baseados uns nos outros e podem ser vistos como um espectro em vez de uma escolha estrita.

Padrão lift-and-shift

No padrão de arquitetura lift-and-shift, os proprietários de aplicativos empresariais migram as cargas de trabalho para a nuvem sem refatorar as cargas de trabalho. Os engenheiros de rede e segurança usam os controles de camada 3 e 4 para fornecer proteção usando uma combinação de dispositivos virtuais de rede que imitam dispositivos físicos locais e regras de firewall na nuvem na rede VPC. Os proprietários da carga de trabalho implantam os serviços em redes VPC.

Padrão de serviços híbridos

As cargas de trabalho criadas usando a migração lift-and-shift podem precisar de acesso a serviços de nuvem, como o BigQuery ou o Cloud SQL. Normalmente, o acesso a esses serviços de nuvem é oferecido na camada 4 e na camada 7. Neste contexto, isolamento e segurança não podem ser feitos estritamente na camada 3. Portanto, a rede de serviços e o VPC Service Controls são usados para fornecer conectividade e segurança, com base nas identidades do serviço que está sendo acessado e do serviço que está solicitando acesso. Nesse modelo, é possível expressar políticas de controle de acesso avançado.

Padrão distribuído de confiança zero

Em uma arquitetura de confiança zero, os aplicativos empresariais estendem a aplicação da segurança além dos controles do perímetro. Dentro do perímetro, as cargas de trabalho só poderão se comunicar com outras cargas de trabalho se a identidade do IAM tiver permissão específica, o que é negado por padrão. Em uma arquitetura distribuída de confiança zero, a confiança é baseada na identidade e aplicada para cada aplicativo. As cargas de trabalho são criadas como microsserviços com identidades emitidas centralmente. Dessa forma, os serviços podem validar os autores das chamadas e tomar decisões baseadas em políticas para cada solicitação, informando se o acesso é aceitável. Essa arquitetura geralmente é implementada usando proxies distribuídos (uma malha de serviço) em vez de gateways centralizados.

As empresas podem aplicar o acesso de confiança zero de usuários e dispositivos a aplicativos corporativos configurando o Identity-Aware Proxy (IAP). O IAP fornece controles baseados em identidade e contexto para o tráfego do usuário da Internet ou da intranet.

Combinação de padrões

As empresas que estão criando ou migrando aplicativos de negócios para a nuvem geralmente usam uma combinação dos três padrões de arquitetura.

O Google Cloud oferece um portfólio de produtos e serviços que servem como elementos básicos para implementar o plano de dados em nuvem que alimenta os padrões de arquitetura. Esses elementos básicos serão discutidos mais adiante neste documento. A combinação de controles fornecidos no plano de dados na nuvem, junto com controles administrativos para gerenciar recursos da nuvem, formam a base de um perímetro de segurança completo. O perímetro criado por essa combinação permite controlar, implantar e operar as cargas de trabalho na nuvem.

Hierarquia de recursos e controles administrativos

Nesta seção, apresentamos um resumo dos controles administrativos que o Google Cloud fornece como contêineres de recursos. Os controles incluem recursos, pastas e projetos da organização do Google Cloud que permitem agrupar e organizar hierarquicamente os recursos da nuvem. Essa organização hierárquica oferece uma estrutura de propriedade e pontos de fixação para aplicar políticas e controles.

Um recurso de organização do Google é o nó raiz na hierarquia e é a base para criar implantações na nuvem. Um recurso da organização pode ter pastas e projetos como filhos. Uma pasta tem projetos ou outras pastas como filhas. Todos os outros recursos da nuvem são filhos dos projetos.

Use pastas como um método de agrupamento de projetos. Os projetos formam a base para criar, ativar e usar todos os serviços do Google Cloud. Os projetos permitem gerenciar APIs, ativar o faturamento, adicionar e remover colaboradores e gerenciar permissões.

Com o Identity and Access Management (IAM) do Google, é possível atribuir papéis e definir políticas e permissões de acesso em todos os níveis de hierarquia de recursos. As políticas do IAM são herdadas pelos recursos inferiores na hierarquia. Essas políticas não podem ser alteradas por proprietários de recursos inferiores na hierarquia. Em alguns casos, o gerenciamento de identidade e acesso é fornecido em um nível mais granular, por exemplo, no escopo de objetos em um namespace ou cluster como em Google Kubernetes Engine.

Considerações de design para redes de nuvem privada virtual do Google

Ao projetar uma estratégia de migração para a nuvem, é importante desenvolver uma estratégia para como a empresa usará as redes VPC. Pense em uma rede VPC como uma versão virtual da sua rede física tradicional. Ela é uma partição de rede privada completamente isolada. Por padrão, as cargas de trabalho ou serviços implantados em uma rede VPC não podem se comunicar com jobs em outra rede VPC. Portanto, as redes VPC permitem o isolamento da carga de trabalho formando um limite de segurança.

Como cada rede VPC na nuvem é uma rede totalmente virtual, cada uma tem o próprio espaço de endereço IP particular. Portanto, é possível usar o mesmo endereço IP em várias redes VPC sem conflito. Uma implantação típica no local pode consumir uma grande parte do espaço de endereço IP particular RFC 1918. Por outro lado, se você tiver cargas de trabalho no local e em redes VPC, será possível reutilizar os mesmos intervalos de endereços em diferentes redes VPC, desde que essas redes não estejam conectadas ou com peering, o que consome o espaço do endereço IP com menos rapidez.

As redes VPC são globais

As redes VPC no Google Cloud são globais, o que significa que os recursos implantados em um projeto que tem uma rede VPC podem se comunicar diretamente usando a espinha dorsal do Google.

Como mostra a figura 1, é possível ter uma rede VPC no projeto que contenha sub-redes em diferentes regiões que abrangem várias zonas. As VMs de qualquer região podem se comunicar de modo particular entre si usando as rotas locais da VPC.

Implementação de rede VPC global do Google Cloud com sub-redes configuradas em regiões diferentes.

Figura 1. Implementação da rede VPC global do Google Cloud com sub-redes configuradas em diferentes regiões.

Como compartilhar uma rede usando a VPC compartilhada

A VPC compartilhada permite que um recurso da organização conecte vários projetos a uma rede VPC comum para que eles possam se comunicar uns com os outros de maneira segura usando endereços IP internos da rede compartilhada. Os administradores dessa rede compartilhada aplicam o controle centralizado dos recursos da rede.

Quando você usa a VPC compartilhada, precisa designar um projeto como host e anexar um ou mais projetos de serviço. As redes VPC no host são chamadas de redes VPC compartilhadas. Recursos qualificados de projetos de serviço podem usar sub-redes na rede VPC compartilhada.

As empresas geralmente usam redes VPC compartilhadas quando precisam de administradores de rede e segurança para centralizar o gerenciamento de recursos de rede, como sub-redes e rotas. Ao mesmo tempo, as redes VPC compartilhadas permitem que as equipes de aplicativos e desenvolvimento criem e excluam instâncias de VM e implantem cargas de trabalho em sub-redes designadas usando os projetos de serviço.

Isolar ambientes usando redes VPC

O uso de redes VPC para isolar ambientes tem várias vantagens, mas você também precisa considerar algumas desvantagens. Esta seção aborda essas compensações e descreve padrões comuns para implementar o isolamento.

Motivos para isolar ambientes

Como as redes VPC representam um domínio de isolamento, muitas empresas as utilizam para manter ambientes ou unidades de negócios em domínios separados. Veja a seguir os motivos comuns para criar isolamento no nível da VPC:

  • Uma empresa quer estabelecer comunicações de negação padrão entre uma rede VPC e outra, porque essas redes representam uma distinção organizacional significativa. Para mais informações, consulte Padrões de isolamento de rede VPC comuns mais adiante neste documento.
  • Uma empresa precisa ter intervalos de endereços IP sobrepostos devido a ambientes no local preexistentes, de aquisições ou de implantações em outros ambientes de nuvem.
  • Uma empresa quer delegar o controle administrativo total de uma rede a uma parte dela.

Desvantagens de ambientes isolados

Criar ambientes isolados com redes VPC pode ter algumas desvantagens. Ter várias redes VPC pode aumentar a sobrecarga administrativa de gerenciar os serviços que abrangem várias redes. Este documento aborda técnicas que podem ser usadas para gerenciar essa complexidade.

Padrões comuns de isolamento de rede VPC

Há alguns padrões comuns para isolar redes VPC:

  • Isole os ambientes de desenvolvimento, preparo e produção. Esse padrão permite que as empresas separem totalmente os ambientes de desenvolvimento, preparo e produção. Na prática, essa estrutura mantém várias cópias completas de aplicativos, com lançamento gradual entre cada ambiente. Nesse padrão, as redes VPC são usadas como limites de segurança. Os desenvolvedores têm um alto nível de acesso às redes VPC de desenvolvimento para fazer o trabalho diário. Quando o desenvolvimento é concluído, uma equipe de produção de engenharia ou uma equipe de controle de qualidade pode migrar as alterações para um ambiente de preparo, em que as alterações podem ser testadas de maneira integrada. Quando as alterações estiverem prontas para serem implantadas, elas serão enviadas para um ambiente de produção.
  • Isole as unidades de negócios. Algumas empresas querem aplicar um alto grau de isolamento entre unidades de negócios, especialmente no caso de unidades adquiridas ou que exigem alto grau de autonomia e isolamento. Nesse padrão, as empresas costumam criar uma rede VPC para cada unidade de negócios e delegar o controle dessa VPC aos administradores da unidade de negócios. A empresa usa técnicas descritas posteriormente neste documento para expor serviços que abrangem a empresa ou para hospedar aplicativos voltados ao usuário que abrangem várias unidades de negócios.

Recomendação para criar ambientes isolados

Recomendamos que você projete suas redes VPC para que tenham o domínio mais amplo alinhado aos limites administrativos e de segurança da sua empresa. É possível conseguir isolamento adicional entre cargas de trabalho executadas na mesma rede VPC usando controles de segurança, como firewalls.

Para mais informações sobre como projetar e criar uma estratégia de isolamento para sua organização, consulte Práticas recomendadas e arquiteturas de referência para o design da VPC e Rede no blueprint de bases empresariais do Google Cloud.

Elementos básicos para redes de nuvem

Nesta seção, falamos sobre os elementos básicos importantes da conectividade de rede, segurança de rede, rede de serviços e segurança do serviço. A Figura 2 mostra como esses elementos básicos se relacionam entre si. É possível usar um ou mais produtos listados em uma determinada linha.

Elementos básicos na conectividade e na segurança da rede da nuvem.

Figura 2. Elementos básicos na conectividade e na segurança da rede da nuvem.

As seções a seguir discutem cada um dos elementos básicos e quais serviços do Google Cloud você pode usar para cada um dos blocos.

Conectividade de rede

O bloco de conectividade de rede está na base da hierarquia. Ele é responsável por conectar os recursos do Google Cloud a data centers locais ou outras nuvens. Dependendo das suas necessidades, talvez você precise de apenas um desses produtos ou use todos eles para processar diferentes casos de uso.

Cloud VPN

O Cloud VPN permite conectar seus escritórios de ramificação remota ou outros provedores de nuvem às redes da VPC do Google por uma conexão VPN IPsec. O tráfego transmitido entre as duas redes é criptografado por um gateway de VPN e descriptografado por outro gateway desse tipo para ajudar a proteger os dados enquanto eles atravessam a Internet.

O Cloud VPN permite ativar a conectividade entre o ambiente local e o Google Cloud sem a sobrecarga de provisionamento das conexões cruzadas físicas necessárias para o Cloud Interconnect, descritas na próxima seção. É possível provisionar uma VPN de alta disponibilidade para atender a um requisito de SLA de até 99,99% de disponibilidade se você tiver a arquitetura em conformidade. Use o Cloud VPN se as cargas de trabalho não exigirem baixa latência ou alta largura de banda. Por exemplo, o Cloud VPN é uma boa opção para casos de uso não essenciais ou para estender a conectividade com outros provedores de nuvem.

Cloud Interconnect

O Cloud Interconnect oferece conectividade dedicada de nível empresarial ao Google Cloud que tem mais capacidade de processamento e um desempenho de rede mais confiável do que a utilização de uma VPN ou de uma entrada de Internet. A Interconexão dedicada fornece conectividade física direta à rede do Google a partir dos seus roteadores. A Interconexão por parceiro oferece conectividade dedicada por meio de uma rede extensa de parceiros, que podem oferecer um alcance mais amplo ou outras opções de largura de banda diferentes das oferecidas pela Interconexão dedicada. O Cross-Cloud Interconnect fornece conectividade direta dedicada das suas redes VPC a outros provedores de nuvem. A Interconexão dedicada exige que você se conecte a uma instalação de colocation em que o Google esteja presente, mas a Interconexão por parceiro não. O Cross-Cloud Interconnect permite selecionar locais que atendam aos seus requisitos para estabelecer as conexões. O Cloud Interconnect garante que o tráfego entre sua rede local ou outra rede na nuvem e sua rede VPC não passe pela Internet pública.

É possível provisionar essas conexões do Cloud Interconnect para atender a um requisito do SLA de 99,99% de disponibilidade se você provisionar a arquitetura apropriada. Considere usar o Cloud Interconnect para oferecer suporte a cargas de trabalho que exigem baixa latência, alta largura de banda e desempenho previsível, garantindo, ao mesmo tempo, que todo o tráfego permaneça particular.

Network Connectivity Center para sistemas híbridos

O Network Connectivity Center oferece conectividade site a site entre suas redes locais e outras redes na nuvem. Ele faz isso usando a rede de backbone do Google para fornecer conectividade confiável entre seus sites.

Além disso, é possível ampliar sua rede de sobreposição SD-WAN atual para o Google Cloud configurando uma VM ou um dispositivo roteador como um anexo de spoke lógico de fornecedor terceirizado.

É possível acessar recursos dentro das redes VPC usando o roteador, a VPN ou a rede do Cloud Interconnect como spoke anexos. É possível usar o Network Connectivity Center para consolidar a conectividade entre seus locais locais, suas presenças em outras nuvens e o Google Cloud e gerenciar tudo com uma única visualização.

Network Connectivity Center para redes VPC

O Network Connectivity Center também permite criar uma malha entre muitas redes VPC. É possível conectar essa malha ao local ou a outras nuvens usando o Cloud VPN ou o Cloud Interconnect.

Peering de rede VPC

Peering de rede VPC permite conectar redes VPC do Google para que cargas de trabalho em diferentes redes VPC possam se comunicar internamente, independentemente de pertencerem ao mesmo projeto ou ao mesmo recurso da organização. O tráfego fica restrito à rede do Google e não passa pela Internet pública.

O peering de rede VPC exige que as redes com peering não tenham endereços IP sobrepostos.

Segurança de rede

O bloco de segurança de rede fica sobre o bloco de conectividade de rede. Ele é responsável por permitir ou negar acesso a recursos com base nas características dos pacotes IP.

Regras de firewall de VPC

As regras de firewall da VPC se aplicam a uma determinada rede. Com as regras de firewall da VPC, você permite ou recusa conexões de ou para suas instância de VM com base na configuração especificada. As regras de firewall da VPC ativadas são sempre aplicadas, protegendo as instâncias, independentemente da configuração, do sistema operacional ou se as VMs foram totalmente inicializadas.

Toda rede VPC funciona como um firewall distribuído. Embora as regras de firewall são definidas no nível da rede, as conexões são permitidas ou negadas por instância. Pense nas regras de firewall da VPC como existentes não apenas entre suas instâncias e outras redes, mas também entre instâncias individuais dentro da mesma rede.

Políticas de firewall hierárquicas

As políticas hierárquicas de firewall permitem criar e aplicar uma política de firewall consistente em toda a organização. Elas contêm regras que podem negar ou permitir conexões explicitamente. É possível atribuir políticas hierárquicas de firewall ao recurso da organização como um todo ou a pastas individuais.

Espelhamento de pacotes

O espelhamento de pacotes clona o tráfego de instâncias específicas na rede VPC e o encaminha aos coletores para análise. O espelhamento de pacotes captura todo o tráfego e dados de pacote, incluindo payloads e cabeçalhos. É possível configurar o espelhamento para tráfego de entrada e saída, apenas para tráfego de entrada ou apenas para o tráfego de saída. O espelhamento acontece nas instâncias de VM, e não na rede.

Dispositivo virtual de rede

Os dispositivos virtuais de rede permitem que você aplique controles de segurança e conformidade à rede virtual consistente com os controles no ambiente local. Para fazer isso, implante imagens de VM disponíveis no Google Cloud Marketplace em VMs que têm várias interfaces de rede, cada uma anexada a uma rede VPC diferente, para executar várias funções virtuais de rede.

Os casos de uso típicos de dispositivos virtuais são os seguintes:

Cloud IDS

O Cloud IDS é um serviço que detecta ameaças de intrusões, malware, spyware e ataques de comando e controle na rede. O Cloud IDS funciona criando uma rede com peering gerenciada pelo Google contendo VMs que receberão tráfego espelhado. Depois, o tráfego espelhado é inspecionado pelas tecnologias de proteção contra ameaças da Palo Alto Networks para oferecer uma detecção avançada de ameaças.

O Cloud IDS oferece visibilidade total do tráfego intra-sub-rede, permitindo o monitoramento da comunicação entre VMs e a detecção de movimento lateral.

Cloud NAT

O Cloud NAT fornece suporte de conversão de endereço de rede totalmente gerenciado e definido por software para aplicativos. Ele ativa a conversão de endereços de rede de origem (NAT ou SNAT de origem) para o tráfego voltado para a Internet de VMs que não têm endereços IP externos.

Firewall Insights

O Firewall Insights ajuda você a entender e otimizar suas regras de firewall. Ele fornece dados sobre como as regras de firewall estão sendo usadas, expõem configurações incorretas e identifica regras que podem ser mais rígidas. Ele também usa o machine learning para prever o uso futuro das regras de firewall. Assim, é possível tomar decisões informadas sobre remover ou restringir regras que parecem ser muito permissivas.

Registro de rede

É possível usar vários produtos do Google Cloud para registrar e analisar o tráfego de rede.

O recurso de geração de registros de regras de firewall permite auditar, verificar e analisar os efeitos das suas regras de firewall. Por exemplo, é possível determinar se uma regra de firewall criada para negar tráfego está funcionando conforme o esperado. O registro de regras de firewall também é útil quando você precisa determinar quantas conexões são afetadas por uma determinada regra de firewall.

Ative a geração de registros de regras de firewall individualmente para cada regra de firewall que tem as conexões que você precisa registrar. A geração de registros de regras de firewall é uma opção para qualquer regra de firewall, seja qual for a ação (permitir ou negar) ou a direção (entrada ou saída) dela.

Os registros de fluxo de VPC registram uma amostra de fluxos de rede que são enviados e recebidos por instâncias de VM, incluindo instâncias usadas como nós do Google Kubernetes Engine (GKE). Esses registros são usados para monitoramento de rede, perícia forense, análise de segurança em tempo real e otimização de despesas.

Rede de serviços

Os blocos de rede de serviços são responsáveis por fornecer serviços de pesquisa que informam os serviços para onde a solicitação deve ser feita (DNS, Diretório de serviços) e sobre o recebimento de solicitações para o local correto (Private Service Connect, Cloud Load Balancing).

Cloud DNS

As cargas de trabalho são acessadas usando nomes de domínio. O Cloud DNS oferece tradução confiável e de baixa latência de nomes de domínios para endereços IP localizados em qualquer lugar do mundo. No Cloud DNS, são fornecidas zonas públicas e zonas DNS gerenciadas particulares. Uma zona pública é visível para todos na Internet pública, já uma zona particular é visível apenas para os usuários em uma ou mais redes VPC especificadas por você.

Cloud Load Balancing

No Google Cloud, balanceadores de carga são um componente crucial. Eles encaminham o tráfego para vários serviços para garantir velocidade e eficiência, e para ajudar a garantir a segurança globalmente para tráfego interno e externo.

Nossos balanceadores de carga também permitem o roteamento e o escalonamento do tráfego em várias nuvens ou ambientes híbridos. Isso faz do Cloud Load Balancing a "porta da frente" por meio da qual qualquer aplicativo pode ser escalonado, independentemente de onde estiver ou em quantos lugars ele está hospedado. O Google oferece vários tipos de balanceamento de carga: global e regional, externo e interno e as camadas 4 e 7.

Diretório de serviços

O Diretório de serviços permite gerenciar seu inventário de serviços, oferecendo um único local seguro para publicar, descobrir e conectar serviços, todas as operações apoiadas pelo controle de acesso baseado em identidade. Ele permite registrar serviços nomeados e os respectivos endpoints. O registro pode ser manual ou usando integrações com o Private Service Connect, o GKE e o Cloud Load Balancing. A descoberta de serviços é possível usando APIs HTTP e gRPC explícitas, bem como o uso do Cloud DNS.

Malhas de serviço: Anthos Service Mesh e Traffic Director

O Anthos Service Mesh e o Traffic Director são projetados para facilitar a execução de aplicativos complexos e distribuídos ativando um conjunto avançado de políticas de segurança e gerenciamento de tráfego em arquiteturas de malha de serviço. As principais diferenças entre esses produtos estão nos ambientes compatíveis, nas APIs do Istio para eles e nos recursos de balanceamento de carga global.

O Anthos Service Mesh é ideal para implantações regionais e globais baseadas em Kubernetes, tanto no Google Cloud quanto no local, que se beneficiam de um produto gerenciado do Istio.

O Traffic Director é ideal para casos de uso de rede que apresentam serviços implantados globalmente de saúde e carga em todo o Google Cloud. O Traffic Director gerencia cargas de trabalho usando proxies do Envoy que atuam como sidecars ou gateways ou usando cargas de trabalho de gRPC sem proxy.

Veja na tabela a seguir um resumo dos recursos do Diretório de tráfego e do Anthos Service Mesh.

Anthos Service Mesh Traffic Director
Tipo de implantação Kubernetes VM, Kubernetes
Ambientes Google Cloud, no local, várias nuvens Google Cloud, no local, várias nuvens
Escopo da implantação Regional e federado regional Global
Superfície da API Istio Roteamento de serviços (modelo do Kubernetes Gateway)
Conectividade de rede Arquivo secundário do Envoy Arquivo secundário do Envoy, gRPC sem proxy
Distribuição de carga global com base na integridade do back-end Sim (com base no Kubernetes) Yes
Distribuição de carga global com base na carga de back-end No Yes
Identidade gerenciada para a carga de trabalho mTLS (confiança zero) Yes Sim (somente no GKE)

O Google elaborou ainda mais a criação de um ambiente completo de arquitetura distribuída de confiança zero usando a arquitetura do BeyondProd. Além do perímetro da rede e da autenticação e autorização do serviço, o BeyondProd detalha como os ambientes de computação confiáveis, a procedência do código e os lançamentos de implantação desempenham um papel para alcançar uma arquitetura segura de serviços distribuídos de confiança zero. Considere essas preocupações que vão além da rede quando você está adotando uma abordagem de confiança zero.

Private Service Connect

O Private Service Connect cria abstrações de serviço tornando as cargas de trabalho acessíveis em todas as redes VPC por um único endpoint. Isso permite que duas redes se comuniquem em um modelo cliente-servidor que exponha apenas o serviço ao consumidor em vez de toda a rede ou a própria carga de trabalho. Um modelo de rede orientado a serviços permite que os administradores de redes meçam os serviços que eles expõem entre redes, em vez de sub-redes ou VPCs. Isso permite o consumo dos serviços em um modelo de produtor e consumidor, seja ele por serviços (SaaS) próprios ou terceirizados.

Com o Private Service Connect, uma VPC do consumidor pode usar um endereço IP particular para se conectar a uma API do Google ou um serviço em outra VPC.

É possível estender o Private Service Connect para sua rede local para acessar endpoints que se conectam a APIs do Google ou a serviços gerenciados em outra rede VPC. O Private Service Connect permite o consumo de serviços na camada 4 ou na camada 7.

Na camada 4, o Private Service Connect exige que o produtor crie uma ou mais sub-redes específicas para o Private Service Connect. Essas sub-redes também são chamadas de sub-redes NAT. O Private Service Connect executa o NAT de origem usando um endereço IP selecionado em uma das sub-redes do Private Service Connect para encaminhar as solicitações para um produtor de serviço. Essa abordagem permite que você use endereços IP sobrepostos entre consumidores e produtores.

Na camada 7, é possível criar um back-end do Private Service Connect usando um balanceador de carga de aplicativo interno. O balanceador de carga de aplicativo interno permite escolher quais serviços estão disponíveis usando um mapa de URL. Para mais informações, consulte Sobre back-ends do Private Service Connect.

Acesso a serviços particulares

O acesso a serviços particulares é uma conexão particular entre sua rede VPC e uma rede pertencente ao Google ou a um terceiro. O Google ou os terceiros que oferecem serviços são conhecidos como produtores de serviços. O acesso a serviços particulares usa o peering de rede VPC para estabelecer a conectividade e requer que as redes VPC do produtor e do cliente façam peering entre si. É diferente do Private Service Connect, que permite projetar um único endereço IP particular na sub-rede.

A conexão particular permite que as instâncias de VM na sua rede VPC e os serviços que você acessa se comuniquem exclusivamente usando endereços IP internos. As instâncias de VM não precisam de acesso à Internet ou de endereços IP externos para alcançar serviços disponíveis por meio do acesso a serviços privados. O acesso a serviços particulares também pode ser estendido para a rede local usando o Cloud VPN ou o Cloud Interconnect para fornecer uma maneira para os hosts locais de alcançar a rede do produtor de serviço. Para acessar uma lista de serviços gerenciados pelo Google que são compatíveis com o acesso a serviços privados, consulte Serviços compatíveis na documentação da nuvem privada virtual.

Acesso VPC sem servidor

O acesso VPC sem servidor permite que você se conecte diretamente à rede VPC a partir de serviços hospedados em ambientes sem servidor, como Cloud Run, App Engine ou Cloud Functions. Ao configurar o acesso VPC sem servidor, você permite que o ambiente sem servidor envie solicitações à sua rede VPC usando DNS interno e endereços IP internos. As respostas a essas solicitações também usam a rede virtual.

O acesso VPC sem servidor envia o tráfego interno da rede VPC para o ambiente sem servidor somente quando esse tráfego é uma resposta a uma solicitação enviada do ambiente sem servidor pelo conector de acesso VPC sem servidor.

O acesso VPC sem servidor tem os seguintes benefícios:

  • As solicitações enviadas à rede VPC nunca são expostas à Internet.
  • A comunicação pelo acesso VPC sem servidor pode ter menos latência em comparação com a comunicação pela Internet.

Segurança do serviço

Os bloqueios de segurança do serviço controlam o acesso a recursos com base na identidade do solicitante ou com base no entendimento de nível superior dos padrões do pacote, em vez de apenas nas características de um pacote individual.

Google Cloud Armor para DDoS/WAF

O Google Cloud Armor é um firewall de aplicativos da Web (WAF) e serviço de mitigação de ataque distribuído de negação de serviço (DDoS) que ajuda você a defender seus aplicativos e serviços da Web contra vários tipos de ameaças. Essas ameaças incluem ataques DDoS, baseados na Web, como scripting em vários locais (XSS) e injeção de SQL (SQLi), além de ataques baseados em automação e fraudes.

O Google Cloud Armor inspeciona solicitações recebidas na borda global do Google. Ele tem um conjunto integrado de regras de firewall de aplicativos da Web que verificam ataques da Web comuns e um avançado sistema de detecção de ataques baseado em ML que cria um modelo de tráfego bom e detecta tráfego ruim. Por fim, o Google Cloud Armor se integra ao Google reCAPTCHA para ajudar a detectar e interromper fraudes sofisticadas e ataques baseados em automação usando a telemetria de endpoint e de nuvem.

Identity Aware Proxy (IAP)

O Identity-Aware Proxy (IAP) fornece controles de acesso baseado no contexto para aplicativos baseados em nuvem e VMs que estão em execução no Google Cloud ou que estão conectados ao Google Cloud usando qualquer uma das tecnologias de rede híbrida. O IAP verifica a identidade do usuário e determina se a solicitação do usuário é originária de fontes confiáveis, com base em vários atributos contextuais. O IAP também é compatível com o encapsulamento TCP para acesso SSH/RDP de usuários corporativos.

VPC Service Controls

O VPC Service Controls ajuda a reduzir o risco de exfiltração de dados dos serviços do Google Cloud, como o Cloud Storage e o BigQuery. O uso do VPC Service Controls ajuda a garantir que o uso dos serviços do Google Cloud aconteça apenas de ambientes aprovados.

É possível usar o VPC Service Controls para criar perímetros que protegem os recursos e dados dos serviços especificados, limitando o acesso a construções específicas de identidade nativas da nuvem, como contas de serviço e redes VPC. Depois que um perímetro é criado, o acesso aos serviços especificados do Google é negado, a menos que a solicitação venha de dentro dele.

Entrega de conteúdo

Os blocos de entrega de conteúdo controlam a otimização da entrega de aplicativos e conteúdo.

Cloud CDN

O Cloud CDN fornece aceleração de conteúdo estático usando a rede de borda global do Google para enviar conteúdo de um ponto mais próximo do usuário. Isso ajuda a reduzir a latência dos seus sites e aplicativos.

Media CDN

O Media CDN é a solução de entrega de mídia do Google criada para cargas de trabalho de saída de alta capacidade.

Observabilidade

Os blocos de observabilidade oferecem visibilidade da sua rede e oferecem insights que podem ser usados para resolver problemas, documentar e investigar.

Network Intelligence Center

O Network Intelligence Center abrange vários produtos que abordam vários aspectos da observabilidade da rede. Cada produto tem um foco diferente e fornece insights avançados para informar administradores, arquitetos e profissionais sobre a integridade da rede e os problemas.

Arquiteturas de referência

Os documentos a seguir apresentam arquiteturas de referência para diferentes tipos de cargas de trabalho: intranuvem, voltadas para a Internet e híbridas. Essas arquiteturas de carga de trabalho são baseadas em um plano de dados em nuvem realizado com os elementos básicos e os padrões de arquitetura que foram descritos nas seções anteriores deste documento.

É possível usar as arquiteturas de referência para projetar maneiras de migrar ou criar cargas de trabalho na nuvem. As cargas de trabalho são mantidas pelo plano de dados na nuvem e usam as arquiteturas. Esses documentos não fornecem um conjunto completo de arquiteturas de referência, mas cobrem os cenários mais comuns.

Assim como os padrões de arquitetura de segurança descritos em Architectures for Protect Cloud Data Planes, serviços reais podem usar uma combinação desses designs. Nesses documentos, discutimos cada tipo de carga de trabalho e as considerações para cada arquitetura de segurança.

A seguir