Conceber redes para migrar cargas de trabalho empresariais: abordagens arquitetónicas

Last reviewed 2025-01-13 UTC

Este documento apresenta uma série que descreve as arquiteturas de rede e segurança para empresas que estão a migrar cargas de trabalho de centros de dados para aGoogle Cloud. Estas arquiteturas enfatizam a conetividade avançada, os princípios de segurança de confiança zero e a capacidade de gestão num ambiente híbrido.

Conforme descrito num documento complementar, Arquiteturas para proteger planos de dados na nuvem, as empresas implementam um espetro de arquiteturas que têm em conta as necessidades de conetividade e segurança na nuvem. Classificamos estas arquiteturas em três padrões arquitetónicos distintos: lift-and-shift, serviços híbridos e distribuídos de confiança zero. O presente documento considera diferentes abordagens de segurança, consoante a arquitetura que uma empresa tenha escolhido. Também descreve como implementar essas abordagens usando as bases fornecidas pela Google Cloud. Deve usar estas orientações de segurança em conjunto com outras orientações arquitetónicas que abrangem a fiabilidade, a disponibilidade, a escala, o desempenho e a governação.

Este documento foi concebido para ajudar os arquitetos de sistemas, os administradores de rede e os administradores de segurança que planeiam migrar cargas de trabalho no local para a nuvem. Pressupõe o seguinte:

  • Tem conhecimentos sobre os conceitos de segurança e rede de centros de dados.
  • Tem cargas de trabalho existentes no seu centro de dados no local e sabe o que fazem e quem são os respetivos utilizadores.
  • Tem, pelo menos, algumas cargas de trabalho que planeia migrar.
  • Geralmente, conhece os conceitos descritos no artigo Arquiteturas para proteger planos de dados na nuvem.

A série é composta pelos seguintes documentos:

Este documento resume os três padrões de arquitetura principais e apresenta as bases de recursos que pode usar para criar a sua infraestrutura. Por último, descreve como juntar os blocos de construção numa série de arquiteturas de referência que correspondem aos padrões. Pode usar estas arquiteturas de referência para orientar a sua própria arquitetura.

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

Vista geral dos padrões arquitetónicos

Normalmente, os engenheiros de rede concentraram-se na criação da infraestrutura de rede física e da infraestrutura de segurança em centros de dados no local.

A mudança para a nuvem alterou esta abordagem porque as construções de rede na nuvem são definidas por software. Na nuvem, os proprietários das aplicações têm um controlo limitado da pilha de infraestrutura subjacente. Precisam de um modelo com um perímetro seguro e que ofereça isolamento para as respetivas cargas de trabalho.

Nesta série, consideramos três padrões de arquitetura comuns. Estes padrões baseiam-se uns nos outros e podem ser vistos como um espetro em vez de uma escolha estrita.

Padrão de lift-and-shift

No padrão arquitetónico de lift-and-shift, os proprietários de aplicações empresariais migram as respetivas cargas de trabalho para a nuvem sem refatorar essas cargas de trabalho. Os engenheiros de rede e segurança usam controlos da camada 3 e da camada 4 para oferecer proteção através de uma combinação de dispositivos virtuais de rede que imitam dispositivos físicos no local e regras de firewall na rede VPC. Os proprietários de cargas de trabalho implementam os respetivos serviços em redes VPC.

Padrão de serviços híbridos

As cargas de trabalho criadas com a abordagem de migração lift-and-shift podem precisar de acesso a serviços na nuvem, como o BigQuery ou o Cloud SQL. Normalmente, o acesso a estes serviços na nuvem é feito na camada 4 e na camada 7. Neste contexto, o isolamento e a segurança não podem ser feitos estritamente na camada 3. Por conseguinte, a rede de serviços e os VPC Service Controls são usados para fornecer conetividade e segurança, com base nas identidades do serviço que está a ser acedido e do serviço que está a pedir acesso. Neste modelo, é possível expressar políticas de controlo de acesso detalhadas.

Padrão distribuído de confiança zero

Numa arquitetura de confiança zero, as aplicações empresariais alargam a aplicação da segurança para além dos controlos de perímetro. Dentro do perímetro, as cargas de trabalho podem comunicar com outras cargas de trabalho apenas se a respetiva identidade do IAM tiver autorização específica, que é recusada por predefinição. Numa arquitetura distribuída de confiança zero, a confiança baseia-se na identidade e é aplicada a cada aplicação. As cargas de trabalho são criadas como microsserviços com identidades emitidas centralmente. Desta forma, os serviços podem validar os autores das chamadas e tomar decisões baseadas em políticas para cada pedido sobre se esse acesso é aceitável. Esta arquitetura é frequentemente implementada através de proxies distribuídos (uma malha de serviços) em vez de usar gateways centralizados.

As empresas podem aplicar o acesso de confiança zero a partir de utilizadores e dispositivos para aplicações empresariais configurando o Identity-Aware Proxy (IAP). O IAP oferece controlos baseados na identidade e no contexto para o tráfego de utilizadores da Internet ou da intranet.

Combinar padrões

As empresas que estão a criar ou migrar as respetivas aplicações empresariais para a nuvem usam normalmente uma combinação de todos os três padrões arquitetónicos.

Google Cloud oferece um portefólio de produtos e serviços que servem como blocos de construção para implementar o plano de dados na nuvem que alimenta os padrões arquitetónicos. Estes elementos básicos são abordados mais adiante neste documento. A combinação de controlos fornecidos no plano de dados da nuvem, juntamente com os controlos administrativos para gerir os recursos da nuvem, formam a base de um perímetro de segurança ponto a ponto. O perímetro criado por esta combinação permite-lhe reger, implementar e operar as suas cargas de trabalho na nuvem.

Hierarquia de recursos e controlos administrativos

Esta secção apresenta um resumo dos controlos administrativos que o Google Cloud Platform Google Cloud oferece como contentores de recursos. Os controlos incluem Google Cloud recursos da organização, pastas e projetos que lhe permitem agrupar e organizar hierarquicamente recursos da nuvem. Esta organização hierárquica oferece-lhe uma estrutura de propriedade e pontos de referência para aplicar políticas e controlos.

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

Usa pastas como método de agrupamento de projetos. Os projetos constituem a base para criar, ativar e usar todos os Google Cloud serviços. Os projetos permitem-lhe gerir APIs, ativar a faturação, adicionar e remover colaboradores, bem como gerir autorizações.

Através da gestão de identidade e de acesso (IAM) da Google, pode atribuir funções e definir políticas e autorizações de acesso em todos os níveis da hierarquia de recursos. As políticas IAM são herdadas pelos recursos inferiores na hierarquia. Estas políticas não podem ser alteradas pelos proprietários de recursos que estão num nível inferior da hierarquia. Em alguns casos, a gestão de identidades e acessos é fornecida a um nível mais detalhado, por exemplo, ao âmbito dos objetos num espaço de nomes ou num cluster, como no Google Kubernetes Engine.

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

Quando cria uma estratégia de migração para a nuvem, é importante desenvolver uma estratégia sobre como a sua empresa vai usar as redes de VPC. Pode considerar uma rede de VPC como uma versão virtual da sua rede física tradicional. É uma partição de rede privada completamente isolada. Por predefinição, as cargas de trabalho ou os serviços implementados numa rede VPC não podem comunicar com tarefas noutra rede VPC. Por conseguinte, as redes VPC permitem o isolamento da carga de trabalho formando um limite de segurança.

Uma vez que cada rede VPC na nuvem é uma rede totalmente virtual, cada uma tem o seu próprio espaço de endereços IP privados. Por conseguinte, pode usar o mesmo endereço IP em várias redes VPC sem conflitos. Uma implementação no local típica pode consumir uma grande parte do espaço de endereço IP privado RFC 1918. Por outro lado, se tiver cargas de trabalho no local e em redes VPC, pode reutilizar os mesmos intervalos de endereços em diferentes redes VPC, desde que essas redes não estejam ligadas nem em peering, o que permite usar o espaço de endereços IP mais lentamente.

As redes VPC são globais

As redes VPC no Google Cloud são globais, o que significa que os recursos implementados num projeto que tenha uma rede VPC podem comunicar entre si diretamente através da rede principal privada da Google.

Como mostra a figura 1, pode ter uma rede VPC no seu projeto que contenha sub-redes em diferentes regiões que abrangem várias zonas. As VMs em qualquer região podem comunicar entre si de forma privada através das rotas de VPC locais.

Implementação da rede VPC globalGoogle Cloud com sub-redes configuradas em diferentes regiões.

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

Partilhar uma rede através da VPC partilhada

A VPC partilhada permite que um recurso de organização ligue vários projetos a uma rede VPC comum para que possam comunicar entre si em segurança através de endereços IP internos da rede partilhada. Os administradores de rede dessa rede partilhada aplicam e impõem o controlo centralizado sobre os recursos de rede.

Quando usa a VPC partilhada, designa um projeto como projeto anfitrião e associa-lhe um ou mais projetos de serviço. As redes VPC no projeto anfitrião são denominadas redes VPC partilhadas. Os recursos elegíveis dos projetos de serviço podem usar sub-redes na rede de VPC partilhada.

Normalmente, as empresas usam redes VPC partilhadas quando precisam que os administradores de rede e de segurança centralizem a gestão de recursos de rede, como sub-redes e rotas. Ao mesmo tempo, as redes VPC partilhadas permitem que as equipas de aplicações e desenvolvimento criem e eliminem instâncias de VM e implementem cargas de trabalho em sub-redes designadas através dos projetos de serviço.

Isolar ambientes através da utilização de redes VPC

A utilização de redes VPC para isolar ambientes tem várias vantagens, mas também tem de considerar algumas desvantagens. Esta secção aborda estas concessões e descreve padrões comuns para implementar o isolamento.

Motivos para isolar ambientes

Uma vez que as redes VPC representam um domínio de isolamento, muitas empresas usam-nas para manter os ambientes ou as unidades de negócio em domínios separados. Seguem-se os motivos comuns para criar isolamento ao nível da VPC:

  • Uma empresa quer estabelecer comunicações de recusa por predefinição entre uma rede VPC e outra, porque estas redes representam uma distinção organizacional significativa. Para mais informações, consulte Padrões comuns de isolamento da rede de VPC mais adiante neste documento.
  • Uma empresa tem de ter intervalos de endereços IP sobrepostos devido a ambientes nas instalações pré-existentes, devido a aquisições ou devido a implementações noutros ambientes na nuvem.
  • Uma empresa quer delegar o controlo administrativo total de uma rede a uma parte da empresa.

Desvantagens de isolar ambientes

A criação de ambientes isolados com redes VPC pode ter algumas desvantagens. Ter várias redes VPC pode aumentar os custos administrativos da gestão dos serviços que abrangem várias redes. Este documento aborda as técnicas que pode usar para gerir esta complexidade.

Padrões comuns de isolamento da rede VPC

Existem alguns padrões comuns para isolar redes VPC:

  • Isolar ambientes de desenvolvimento, teste e produção. Este padrão permite que as empresas segreguem totalmente os respetivos ambientes de desenvolvimento, teste e produção. Na prática, esta estrutura mantém várias cópias completas de aplicações, com implementação progressiva entre cada ambiente. Neste padrão, as redes VPC são usadas como limites de segurança. Os programadores têm um elevado grau de acesso às redes VPC de desenvolvimento para fazer o seu trabalho diário. Quando o desenvolvimento estiver concluído, uma equipa de produção de engenharia ou uma equipa de controlo de qualidade pode migrar as alterações para um ambiente de preparação, onde as alterações podem ser testadas de forma integrada. Quando as alterações estão prontas para serem implementadas, são enviadas para um ambiente de produção.
  • Isolar unidades de negócio. Algumas empresas querem impor um elevado grau de isolamento entre as unidades empresariais, especialmente no caso de unidades que foram adquiridas ou que exigem um elevado grau de autonomia e isolamento. Neste padrão, as empresas criam frequentemente uma rede VPC para cada unidade de negócio e delegam o controlo dessa VPC nos administradores da unidade de negócio. A empresa usa técnicas descritas mais adiante neste documento para expor serviços que abrangem a empresa ou para alojar aplicações orientadas para o utilizador que abrangem várias unidades empresariais.

Recomendação para criar ambientes isolados

Recomendamos que crie as suas redes VPC para terem o domínio mais amplo que se alinhe com os limites administrativos e de segurança da sua empresa. Pode alcançar um isolamento adicional entre cargas de trabalho executadas na mesma rede VPC através de controlos de segurança, como firewalls.

Para mais informações sobre como criar e desenvolver uma estratégia de isolamento para a sua organização, consulte as práticas recomendadas e as arquiteturas de referência para o design de VPC e a rede no Google Cloud projeto de base empresarial.

Bases para redes na nuvem

Esta secção aborda os elementos essenciais importantes para a conetividade de rede, a segurança de rede, a rede de serviços e a segurança de serviços. A Figura 2 mostra como estes blocos de criação se relacionam entre si. Pode usar um ou mais dos produtos indicados numa determinada linha.

Bases no domínio da conetividade e segurança da rede na nuvem.

Figura 2. Bases no domínio da conetividade de rede na nuvem e da segurança.

As secções seguintes abordam cada um dos elementos básicos e os Google Cloud serviços que pode usar para cada um dos blocos.

Conetividade de rede

O bloqueio da conetividade de rede está na base da hierarquia. É responsável por ligar Google Cloud recursos a centros de dados nas instalações ou a outras nuvens. Consoante as suas necessidades, pode precisar apenas de um destes produtos ou pode usá-los todos para lidar com diferentes exemplos de utilização.

Cloud VPN

A VPN na nuvem permite-lhe ligar os seus escritórios remotos ou outros fornecedores de nuvem às redes VPC da Google através de ligações VPN IPsec. O tráfego que viaja entre as duas redes é encriptado por um gateway de VPN e, em seguida, desencriptado pelo outro gateway de VPN, o que ajuda a proteger os dados à medida que atravessam a Internet.

O Cloud VPN permite-lhe ligar o seu ambiente nas instalações e Google Cloud com um custo inferior, mas uma largura de banda mais baixa, do que o Cloud Interconnect (descrito na secção seguinte). Pode aprovisionar uma VPN de HA para cumprir um requisito de SLA de até 99,99% de disponibilidade se tiver a arquitetura em conformidade. Por exemplo, a Cloud VPN é uma boa escolha para exemplos de utilização não essenciais ou para estender a conetividade a outros fornecedores de nuvem.

Cloud Interconnect

O Cloud Interconnect oferece conetividade dedicada de nível empresarial ao Google Cloud que tem débito mais elevado e desempenho de rede mais fiável em comparação com a utilização de VPN ou entrada da Internet. O Dedicated Interconnect oferece conetividade física direta à rede da Google a partir dos seus routers. O Partner Interconnect oferece conectividade dedicada através de uma extensa rede de parceiros, que podem oferecer um alcance mais amplo ou outras opções de largura de banda do que o Dedicated Interconnect. O Cross-Cloud Interconnect oferece conetividade direta dedicada das suas redes VPC a outros fornecedores de nuvem. O Dedicated Interconnect requer que se ligue a uma instalação de colocation onde a Google está presente, mas o Partner Interconnect não. O Cloud Interconnect garante que o tráfego entre a sua rede local ou outra rede de nuvem e a sua rede de VPC não atravessa a Internet pública.

Pode aprovisionar estas ligações do Cloud Interconnect para cumprir um requisito de SLA de até 99,99% de disponibilidade se aprovisionar a arquitetura adequada. Pode considerar usar o Cloud Interconnect para suportar cargas de trabalho que requerem baixa latência, largura de banda elevada e desempenho previsível, ao mesmo tempo que garante que todo o seu tráfego permanece privado.

Network Connectivity Center para híbrido

O Network Connectivity Center oferece conetividade entre sites entre as suas redes nas instalações e outras redes na nuvem. Isto é feito através da rede principal da Google para oferecer uma conectividade fiável entre os seus sites.

Além disso, pode expandir a sua rede de sobreposição SD-WAN existente para Google Cloud configurar uma VM ou um dispositivo de router de fornecedor externo como um anexo de spoke lógico.

Pode aceder aos recursos nas redes VPC através do dispositivo de encaminhamento, da VPN ou da rede Cloud Interconnect como anexos spoke. Pode usar o Network Connectivity Center para consolidar a conetividade entre os seus sites no local, as suas presenças noutras nuvens e Google Cloud e gerir tudo através de uma única vista.

Network Connectivity Center para redes de VPC

O Network Connectivity Center também lhe permite criar uma topologia de malha ou estrela entre várias redes VPC através de raios da VPC. Pode ligar o hub a localizações no local ou a outras nuvens através de raios híbridos do Network Connectivity Center.

Intercâmbio de redes da VPC

O intercâmbio da rede da VPC permite-lhe ligar redes VPC da Google para que as cargas de trabalho em diferentes redes VPC possam comunicar internamente, independentemente de pertencerem ao mesmo projeto ou ao mesmo recurso de organização. O tráfego permanece na rede da Google e não atravessa a Internet pública.

O intercâmbio da rede da VPC requer que as redes a serem interligadas não tenham endereços IP sobrepostos.

Segurança de redes

O bloco de segurança de rede está na parte superior do bloco de conetividade de rede. É responsável por permitir ou negar o acesso a recursos com base nas características dos pacotes IP.

Cloud NGFW

A firewall de próxima geração da nuvem (Cloud NGFW) é um serviço de firewall distribuído que lhe permite aplicar políticas de firewall ao nível da organização, da pasta e da rede. As regras de firewall ativadas são sempre aplicadas, protegendo as suas instâncias independentemente da respetiva configuração, do sistema operativo ou mesmo se as VMs foram totalmente iniciadas. As regras são aplicadas por instância, o que significa que as regras protegem as ligações entre VMs numa determinada rede, bem como as ligações fora da rede. A aplicação de regras pode ser regida por etiquetas regidas pelo IAM, que lhe permitem controlar que VMs são abrangidas por regras específicas. O NGFW da nuvem também oferece a opção de fazer a inspeção de pacotes da camada 7.

Espelhamento de pacotes

O espelhamento de pacotes clona o tráfego de instâncias específicas na sua rede VPC e encaminha-o para coletores para exame. A replicação de pacotes captura todo o tráfego e dados de pacotes, incluindo cargas úteis e cabeçalhos. Pode configurar o espelhamento para o tráfego de entrada e de saída, apenas para o tráfego de entrada ou apenas para o tráfego de saída. A duplicação ocorre nas instâncias de VM e não na rede.

Dispositivo virtual de rede

Os dispositivos virtuais de rede permitem-lhe aplicar controlos de segurança e conformidade à rede virtual que são consistentes com os controlos no ambiente no local. Pode fazê-lo implementando imagens de VMs disponíveis no Google Cloud Marketplace em VMs com várias interfaces de rede, cada uma anexada a uma rede VPC diferente, para realizar várias funções virtuais de rede.

Seguem-se exemplos de utilização típicos para dispositivos virtuais:

  • Firewall de nova geração (NGFW). As NVAs NGFW oferecem proteção em situações não abrangidas pelo NGFW da nuvem ou para fornecer consistência de gestão com instalações NGFW no local.
  • Sistema de deteção de intrusões/sistema de prevenção de intrusões (IDS/IPS). Um IDS baseado na rede oferece visibilidade do tráfego potencialmente malicioso. Para evitar intrusões, os dispositivos IPS podem bloquear o tráfego malicioso que tenta alcançar o respetivo destino. Google Cloud oferece o sistema de deteção de intrusões do Cloud (Cloud IDS) como um serviço gerido.
  • Gateway da Web seguro (SWG). Um SWG bloqueia ameaças da Internet, permitindo que as empresas apliquem políticas corporativas no tráfego que se desloca para e a partir da Internet. Isto é feito através da filtragem de URLs, da deteção de código malicioso e do controlo de acesso. Google Cloud oferece o proxy Web seguro como um serviço gerido.
  • Gateway de tradução de endereços de rede (NAT). Um gateway NAT traduz endereços IP e portas. Por exemplo, esta tradução ajuda a evitar a sobreposição de endereços IP. Google Cloud ofereceo Cloud NAT como um serviço gerido.
  • Firewall de app Web (WAF). Uma WAF foi concebida para bloquear tráfego HTTP(S) malicioso que se destina a uma aplicação Web.O Google Cloud oferece funcionalidade WAF através das políticas de segurança do Google Cloud Armor. A funcionalidade exata difere entre os fornecedores de FAF, por isso é importante determinar o que precisa.

Cloud IDS

O Cloud IDS é um serviço de deteção de intrusões que oferece deteção de ameaças para intrusões, software malicioso, spyware e ataques de comando e controlo na sua rede. O Cloud IDS funciona através da criação de uma rede com peering gerida pela Google que contém VMs que recebem tráfego espelhado. Em seguida, o tráfego espelhado é inspecionado pelas tecnologias de proteção contra ameaças da Palo Alto Networks para fornecer uma deteção de ameaças avançada.

O Cloud IDS oferece visibilidade total do tráfego na sub-rede, o que lhe permite monitorizar a comunicação entre VMs e detetar o movimento lateral.

NAT na nuvem

O Cloud NAT oferece apoio técnico de tradução de endereços de rede totalmente gerido e definido por software para aplicações. Permite a tradução de endereços de rede de origem (NAT de origem ou SNAT) para tráfego virado para a Internet a partir de VMs que não têm endereços IP externos.

Firewall Insights

As estatísticas da firewall ajudam a compreender e otimizar as regras da firewall. Fornece dados sobre a forma como as regras da firewall estão a ser usadas, expõe configurações incorretas e identifica regras que podem ser tornadas mais rigorosas. Também usa a aprendizagem automática para prever a utilização futura das suas regras de firewall, para que possa tomar decisões informadas sobre se deve remover ou restringir regras que parecem excessivamente permissivas.

Registo de rede

Pode usar vários Google Cloud produtos para registar e analisar o tráfego de rede.

O registo de regras de firewall permite-lhe auditar, validar e analisar os efeitos das suas regras de firewall. Por exemplo, pode determinar se uma regra de firewall concebida para negar tráfego está a funcionar como pretendido. O registo das regras de firewall também é útil se precisar de determinar quantas ligações são afetadas por uma determinada regra de firewall.

Ativa o registo das regras de firewall individualmente para cada regra de firewall cujas ligações tem de registar. O registo de regras de firewall é uma opção para qualquer regra de firewall, independentemente da ação (permitir ou recusar) ou da direção (entrada ou saída) da regra.

Os registos de fluxo da VPC registam uma amostra de fluxos de rede enviados e recebidos por instâncias de VMs, incluindo instâncias usadas como nós do Google Kubernetes Engine (GKE). Estes registos podem ser usados para monitorização de rede, análise forense, análise de segurança em tempo real e otimização de despesas.

Redes de serviços

Os blocos de rede de serviços são responsáveis por fornecer serviços de pesquisa que indicam aos serviços onde um pedido deve ser encaminhado (DNS, diretório de serviços) e por encaminhar os pedidos para o local correto (Private Service Connect, Cloud Load Balancing).

Cloud DNS

As cargas de trabalho são acedidas através de nomes de domínios. O Cloud DNS oferece uma tradução fiável e de baixa latência de nomes de domínios para endereços IP que se encontram em qualquer parte do mundo. O Cloud DNS oferece zonas públicas e zonas de DNS geridas privadas. Uma zona pública é visível para a Internet pública, enquanto uma zona privada é visível apenas a partir de uma ou mais redes de VPC que especificar.

Cloud Load Balancing

Dentro dos Google Cloudbalanceadores de carga, estes são um componente crucial. Encaminham o tráfego para vários serviços para oferecer velocidade e eficiência, e para ajudar a melhorar a segurança globalmente para o tráfego interno e externo.

Os nossos balanceadores de carga também permitem que o tráfego seja encaminhado e dimensionado em várias nuvens ou ambientes híbridos. Isto faz do Cloud Load Balancing a "porta da frente" através da qual qualquer aplicação pode ser dimensionada, independentemente da sua localização ou do número de locais onde está alojada. A Google oferece vários tipos de balanceamento de carga: global e regional, externo e interno, e camada 4 e camada 7.

Diretório de serviços

O diretório de serviços permite-lhe gerir o seu inventário de serviços, oferecendo um único local seguro para publicar, descobrir e associar serviços, todas as operações suportadas pelo controlo de acesso baseado na identidade. Permite-lhe registar serviços com nome e os respetivos pontos finais. O registo pode ser manual ou através de integrações com o Private Service Connect, o GKE e o Cloud Load Balancing. A deteção de serviços é possível através de APIs HTTP e gRPC explícitas, bem como através do Cloud DNS.

Cloud Service Mesh

O Cloud Service Mesh foi concebido para executar aplicações distribuídas complexas através da ativação de um conjunto abrangente de políticas de gestão de tráfego e segurança em arquiteturas de service mesh.

O Cloud Service Mesh suporta implementações regionais e globais baseadas no Kubernetes, tanto Google Cloud na nuvem como no local, que beneficiam de um produto Istio gerido. Também suporta Google Cloud a utilização de proxies em VMs ou gRPC sem proxy.

Private Service Connect

O Private Service Connect cria abstrações de serviços tornando as cargas de trabalho acessíveis em redes VPC através de um único ponto final. Isto permite que duas redes comuniquem num modelo cliente-servidor que expõe apenas o serviço ao consumidor, em vez de toda a rede ou a carga de trabalho em si. Um modelo de rede orientado para serviços permite que os administradores de rede raciocinem sobre os serviços que expõem entre redes em vez de sub-redes ou VPCs, o que permite o consumo dos serviços num modelo de produtor-consumidor, quer se trate de serviços originais ou de terceiros (SaaS).

Com o Private Service Connect, uma VPC do consumidor pode usar um endereço IP privado para estabelecer ligação a uma API Google ou a um serviço noutra VPC.

Pode estender o Private Service Connect à sua rede no local para aceder a pontos finais que se ligam às APIs Google ou a serviços geridos noutra 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 requer que o produtor crie uma ou mais sub-redes específicas do Private Service Connect. Estas sub-redes também são denominadas sub-redes NAT. O Private Service Connect executa o NAT de origem com um endereço IP selecionado a partir de uma das sub-redes do Private Service Connect para encaminhar os pedidos para um produtor de serviços. Esta abordagem permite-lhe usar endereços IP sobrepostos entre consumidores e produtores.

Na camada 7, pode criar um back-end do Private Service Connect usando um balanceador de carga de aplicações interno. O balanceador de carga de aplicações interno permite-lhe escolher os serviços que estão disponíveis através de um mapa de URLs. Para mais informações, consulte o artigo Acerca dos back-ends do Private Service Connect.

Acesso a serviços privados

O acesso privado aos serviços é uma ligação privada entre a sua rede VPC e uma rede que pertence à Google ou a terceiros. A Google ou os terceiros que oferecem serviços são conhecidos como produtores de serviços. O acesso a serviços privados usa o VPC Network Peering para estabelecer a conetividade e requer que as redes VPC do produtor e do consumidor estejam em peering entre si. Isto é diferente do Private Service Connect, que lhe permite projetar um único endereço IP privado na sua sub-rede.

A ligação privada permite que as instâncias de VM na sua rede VPC e os serviços aos quais acede comuniquem exclusivamente através de endereços IP internos. As instâncias de VM não precisam de acesso à Internet nem de endereços IP externos para alcançar serviços disponíveis através do acesso a serviços privados. O acesso privado a serviços também pode ser estendido à rede no local através da utilização do Cloud VPN ou do Cloud Interconnect para fornecer uma forma de os anfitriões no local alcançarem a rede do produtor de serviços. Para ver uma lista dos serviços geridos pela Google que são suportados através do acesso a serviços privados, consulte os Serviços suportados na documentação da nuvem privada virtual.

Acesso a VPC sem servidor

O acesso a VPC sem servidor permite-lhe estabelecer ligação diretamente à sua rede VPC a partir de serviços alojados em ambientes sem servidor, como o Cloud Run, o App Engine ou as funções do Cloud Run. A configuração do acesso a VPC sem servidor permite que o seu ambiente sem servidor envie pedidos para a sua rede VPC através de DNS interno e endereços IP internos. As respostas a estes pedidos também usam a sua rede virtual.

O acesso a VPC sem servidor envia tráfego interno da sua rede VPC para o seu ambiente sem servidor apenas quando esse tráfego é uma resposta a um pedido que foi enviado do seu ambiente sem servidor através do conector de acesso a VPC sem servidor.

O Acesso a VPC sem servidor tem as seguintes vantagens:

  • Os pedidos enviados para a sua rede de VPC nunca são expostos à Internet.
  • A comunicação através do Acesso a VPC sem servidor pode ter uma latência inferior em comparação com a comunicação através da Internet.

Saída direta da VPC

A saída direta da VPC permite que o seu serviço do Cloud Run envie tráfego para uma rede VPC sem configurar um conetor do Acesso a VPC sem servidor.

Segurança do serviço

A segurança do serviço bloqueia o acesso aos recursos com base na identidade do solicitador ou numa compreensão de nível superior dos padrões de pacotes, em vez de apenas nas caraterísticas de um pacote individual.

Cloud Armor para DDoS/WAF

O Cloud Armor é uma firewall de aplicação Web (WAF) e um serviço de mitigação de negação de serviço distribuída (DDoS) que ajuda a defender as suas aplicações e serviços Web de vários tipos de ameaças. Estas ameaças incluem ataques DDoS, ataques baseados na Web, como scripting entre sites (XSS) e injeção SQL (SQLi), bem como ataques baseados em fraude e automatização.

O Cloud Armor inspeciona as solicitações recebidas na extremidade global da Google. Tem um conjunto incorporado de regras de firewall de aplicações Web para procurar ataques Web comuns e um sistema de deteção de ataques avançado baseado em ML que cria um modelo de bom tráfego e, em seguida, deteta mau tráfego. Por último, o Cloud Armor integra-se com o Google reCAPTCHA para ajudar a detetar e parar fraudes sofisticadas e ataques baseados em automatização através da utilização da telemetria de pontos finais e da telemetria da nuvem.

Identity-Aware Proxy (IAP)

O Identity-Aware Proxy (IAP) oferece controlos de acesso sensíveis ao contexto a aplicações baseadas na nuvem e VMs que estão em execução Google Cloud ou que estão ligadas Google Cloud através de qualquer uma das tecnologias de rede híbrida. A IAP valida a identidade do utilizador e determina se o pedido do utilizador tem origem em fontes fidedignas, com base em vários atributos contextuais. O IAP também suporta o tunelamento TCP para acesso SSH/RDP de utilizadores empresariais.

VPC Service Controls

Os VPC Service Controls ajudam a mitigar o risco de exfiltração de dados de Google Cloud serviços como o Cloud Storage e o BigQuery. A utilização dos VPC Service Controls ajuda a garantir que a utilização dos seus serviços ocorre apenas a partir de ambientes aprovados. Google Cloud

Pode usar os VPC Service Controls para criar perímetros que protegem os recursos e os dados dos serviços que especificar, limitando o acesso a construções de identidade nativas da nuvem específicas, como contas de serviço e redes VPC. Depois de criar um perímetro, o acesso aos serviços Google especificados é recusado, a menos que o pedido seja feito a partir do interior do perímetro.

Envio de conteúdo

Os blocos de envio de conteúdo controlam a otimização do envio de aplicações e conteúdo.

Cloud CDN

O Cloud CDN oferece aceleração de conteúdo estático através da rede de limite global da Google para fornecer conteúdo a partir de um ponto mais próximo do utilizador. Isto ajuda a reduzir a latência dos seus Websites e aplicações.

Media CDN

A RFC de multimédia é a solução de fornecimento de multimédia da Google e foi criada para cargas de trabalho de saída de elevado débito.

Observabilidade

Os blocos de observabilidade dão-lhe visibilidade da sua rede e oferecem estatísticas que podem ser usadas para resolver problemas, documentar e investigar.

Network Intelligence Center

O Network Intelligence Center compreende vários produtos que abordam vários aspetos da observabilidade da rede. Cada produto tem um foco diferente e fornece estatísticas detalhadas para informar os administradores, os arquitetos e os profissionais sobre o estado e os problemas da rede.

Arquiteturas de referência

Os documentos seguintes apresentam arquiteturas de referência para diferentes tipos de cargas de trabalho: na nuvem, viradas para a Internet e híbridas. Estas arquiteturas de carga de trabalho são criadas com base num plano de dados na nuvem que é realizado através dos blocos de construção e dos padrões de arquitetura descritos nas secções anteriores deste documento.

Pode usar as arquiteturas de referência para criar formas de migrar ou criar cargas de trabalho na nuvem. As suas cargas de trabalho são, então, suportadas pelo plano de dados da nuvem e usam as arquiteturas. Embora estes documentos não forneçam um conjunto exaustivo de arquiteturas de referência, abrangem os cenários mais comuns.

Tal como acontece com os padrões de arquitetura de segurança descritos no artigo Arquiteturas para proteger planos de dados na nuvem, os serviços do mundo real podem usar uma combinação destes designs. Estes documentos abordam cada tipo de carga de trabalho e as considerações para cada arquitetura de segurança.

O que se segue?