Encriptação em trânsito para Google Cloud

Este conteúdo foi atualizado pela última vez em abril de 2025 e representa o status quo no momento em que foi escrito. As políticas e os sistemas de segurança da Google podem mudar no futuro, à medida que melhoramos continuamente a proteção dos nossos clientes.

Na Google, os nossos controlos de segurança ajudam a proteger os seus dados, quer estejam a ser transmitidos pela Internet, a ser movidos na infraestrutura da Google ou armazenados nos nossos servidores. A estratégia de segurança da Google baseia-se na autenticação, na integridade e na encriptação, tanto para os dados em repouso como para os dados em trânsito. Este artigo descreve como concebemos a encriptação de dados em trânsito a partir da Internet e dados em trânsito nas redes da Google.Google Cloud Este documento não se aplica a dados em trânsito através de interconexões entre redes de centros de dados de clientes e redes de centros de dados da Google.

A encriptação em trânsito usa várias tecnologias para ajudar a proteger os dados, incluindo Transport Layer Security (TLS), BoringSSL, Application Layer Transport Security (ALTS) e o protocolo de segurança PSP. Além da proteção predefinida fornecida pela Google, pode proteger ainda mais os dados adicionando opções de encriptação, como IPsec, certificados TLS geridos e Cloud Service Mesh.

Este documento destina-se a CISOs e equipas de operações de segurança que usam ou consideram usar Google Cloud. Este documento pressupõe uma compreensão básica da encriptação e dos primitivos criptográficos.

Autenticação, integridade e encriptação

A Google utiliza as seguintes medidas de segurança para ajudar a garantir a autenticidade, a integridade e a privacidade dos dados em trânsito:

  • A autenticação valida a identidade de um par (um humano ou um processo) numa ligação.
  • A integridade impede que os dados que envia sejam alterados durante a transmissão entre a origem e o destino.
  • A encriptação usa a criptografia para tornar os seus dados ilegíveis enquanto estão em movimento e mantê-los confidenciais.

A encriptação em trânsito ajuda a proteger os seus dados se as comunicações forem intercetadas enquanto os dados se movem entre o utilizador final e Google Cloud ou entre dois serviços. A encriptação em trânsito autentica os pontos finais e encripta os dados antes da transmissão. À chegada, o destinatário desencripta os dados e verifica se não foram modificados durante a transmissão.

A encriptação é um componente de uma estratégia de segurança mais ampla. A encriptação em trânsito defende os seus dados contra potenciais atacantes e elimina a necessidade de a Google, os clientes ou os utilizadores finais confiarem nas camadas inferiores da rede. Google Cloud

Como o tráfego é encaminhado

Esta secção descreve como os pedidos chegam de um utilizador final ao serviço ou à aplicação do cliente adequados e como o tráfego é encaminhado entre os serviços.Google Cloud

Um Google Cloud serviço é um serviço na nuvem modular que oferecemos aos nossos clientes. Estes serviços incluem computação, armazenamento de dados, análise de dados e aprendizagem automática. Por exemplo, o Cloud Storage é um Google Cloud serviço.

Uma aplicação de cliente é uma aplicação alojada na Google Cloud qual você, como cliente da Google, pode criar e implementar através de Google Cloud serviços. As aplicações de clientes ou as soluções de parceiros alojadas em Google Cloud não são consideradas Google Cloud serviços. Por exemplo, uma aplicação que cria com o Cloud Run, o Google Kubernetes Engine ou uma VM no Compute Engine é uma aplicação do cliente.

O diagrama seguinte mostra os caminhos do tráfego do utilizador final para a Google, os caminhos na rede da Google e a segurança de cada ligação. São apresentados os seguintes caminhos de tráfego:

  • Utilizador final na Internet para um Google Cloud serviço (etiquetado como A no diagrama)
  • Utilizador final na Internet para uma aplicação de cliente alojada em Google Cloud (etiquetada como B no diagrama)
  • Máquina virtual para máquina virtual (etiquetada como C no diagrama)
  • Máquina virtual para a interface de utilizador da Google (GFE) (indicada como D no diagrama)
  • GFE para APIs e serviços Google (etiquetados como E no diagrama)
  • Google Cloud serviço para Google Cloud serviço (etiquetado como F no diagrama)

Caminhos de tráfego para o Google.

Encriptação em trânsito entre o utilizador final e a Google

As secções seguintes fornecem mais detalhes sobre os pedidos de encaminhamento do utilizador final que são apresentados no diagrama anterior.

Utilizador final a um Google Cloud serviço

Google Cloud serviços como o Cloud Storage ou o Compute Engine são serviços na nuvem que oferecemos aos clientes e que são executados no nosso ambiente de produção. Os serviçosGoogle Cloud aceitam pedidos de todo o mundo através de um sistema distribuído globalmente denominado Google Front End (GFE). O GFE termina o tráfego para ligações HTTP(S), TCP e TLS recebidas; fornece contramedidas contra ataques DDoS; e encaminha e equilibra a carga do tráfego para os próprios serviçosGoogle Cloud . Os pontos de presença da GFE existem em todo o mundo com caminhos anunciados através de unicast ou anycast.

O GFE encaminha o tráfego de um utilizador final através da rede da Google para um Google Cloud serviço e de um utilizador final para uma aplicação do cliente alojada em Google Cloud e que usa o Cloud Load Balancing.

Os pedidos que os clientes enviam a um Google Cloud serviço através de HTTPS, HTTP/2 ou HTTP/3 são protegidos com TLS. O TLS no GFE é implementado com o BoringSSL, uma implementação de código aberto do protocolo TLS mantida pela Google. O BoringCrypto, o núcleo do BoringSSL, é validado para o nível 1 da FIPS 140-3.

O GFE negoceia parâmetros criptográficos de norma da indústria com o cliente, incluindo a negociação de chaves com segurança futura. Para clientes mais antigos e menos capazes, o GFE escolhe as primitivas criptográficas antigas mais fortes que o cliente oferece.

Utilizador final a uma aplicação do cliente alojada em Google Cloud

Pode encaminhar o tráfego do utilizador final da Internet para as suas aplicações de cliente alojadas em Google Cloud através de uma ligação direta ou de um equilibrador de carga. Quando o tráfego é encaminhado diretamente, é encaminhado para o endereço IP externo do servidor de VM que aloja a aplicação.

Pode usar o TLS com o balanceador de carga de aplicações externo ou o balanceador de carga de rede de proxy externo para se ligar à sua aplicação em execução no Google Cloud. Quando usa um equilibrador de carga da camada 7, a ligação entre o utilizador final e o equilibrador de carga é encriptada com TLS por predefinição (desde que a aplicação cliente do utilizador final suporte TLS). O GFE termina as ligações TLS dos seus utilizadores finais através de certificados TLS autogeridos ou geridos pela Google. Para mais informações sobre a personalização do seu certificado, consulte a vista geral dos certificados SSL. Para ativar a encriptação entre o balanceador de carga e a VM que aloja a aplicação do cliente, consulte o artigo Encriptação do balanceador de carga para os back-ends.

Para configurar o TLS mútuo (mTLS), consulte a vista geral do TLS mútuo. Para cargas de trabalho no GKE e no Compute Engine, considere usar o Cloud Service Mesh para poder usar o mTLS para autenticação mútua (cliente e servidor) e encriptar as comunicações em trânsito através de certificados que gere.

Para o Firebase Hosting e os domínios personalizados do Cloud Run, considere os nossos certificados TLS gratuitos e automatizados. Com os domínios personalizados do Cloud Run, também pode fornecer os seus próprios certificados SSL e usar um cabeçalho HTTP Strict Transport Security (HSTS).

Encriptação em trânsito nas redes Google

Google Cloud Encripta os dados dos clientes em trânsito nas redes da Google, salvo indicação em contrário na presente secção.

As interligações especializadas de desempenho ultra-elevado que ligam as TPUs ou as GPUs nos supercomputadores de IA da Google são separadas das redes descritas neste documento. No Google Cloud, estas interligações de desempenho ultra-elevado são ICI para TPUs e NVLink para GPUs. Para mais informações, consulte a arquitetura TPU e os tipos de máquinas de GPU.

O tráfego através de ligações a VMs que usam endereços IP externos sai das redes da Google. É responsável por configurar a sua própria encriptação para essas ligações.

Google Cloud autenticação e encriptação de rede virtual

Google CloudA rede virtual do Google Cloud encripta, protege a integridade e autentica o tráfego entre VMs.

A encriptação do tráfego IP privado na mesma VPC ou em redes VPC com intercâmbio na rede virtual do Google Cloudé realizada na camada de rede.

Cada par de anfitriões que comunicam estabelece uma chave de sessão através de um canal de controlo protegido por ALTS para comunicações autenticadas, protegidas contra adulteração e encriptadas. A chave de sessão é usada para encriptar a comunicação de VM para VM entre esses anfitriões e as chaves de sessão são alternadas periodicamente.

As ligações de VM para VM nas redes VPC e nas redes VPC com peering na rede de produção da Google estão protegidas contra a integridade e encriptadas. Estas ligações incluem ligações entre VMs de clientes e entre VMs de clientes e VMs geridas pela Google, como o Cloud SQL. O diagrama em Como o tráfego é encaminhado mostra esta interação (ligação C etiquetada). Tenha em atenção que, uma vez que a Google ativa a encriptação automática com base na utilização de endereços IP internos, as ligações entre VMs que usam endereços IP externos não são encriptadas automaticamente.

Google Cloud"s virtual network authenticates all traffic between VMs. Esta autenticação, alcançada através de tokens de segurança, impede que um anfitrião comprometido falsifique pacotes na rede.

Os tokens de segurança estão encapsulados num cabeçalho de túnel que contém informações de autenticação sobre o remetente e o destinatário. O plano de controlo no anfitrião de envio define o token e o anfitrião de receção valida o token. Os tokens de segurança são pré-gerados para cada fluxo e consistem num token (com as informações do remetente) e no segredo do anfitrião.

Conetividade às APIs e aos serviços Google

O processamento do tráfego difere consoante o local onde o serviço Google Cloud está alojado.

A maioria das APIs e dos serviços Google estão alojados em GFEs. O tráfego da VM para o GFE usa endereços IP externos para alcançar os Google Cloud serviços, mas pode configurar o acesso privado para evitar a utilização de endereços IP externos. A ligação do GFE ao serviço é autenticada e encriptada.

Alguns serviços, como o Cloud SQL, são alojados em instâncias de VMs geridas pela Google. Se as VMs do cliente acederem aos serviços alojados em instâncias de VMs geridas pela Google através de endereços IP externos, o tráfego permanece na rede de produção da Google, mas não é encriptado automaticamente devido à utilização dos endereços IP externos. Para mais informações, consulte a secção sobre Google Cloud autenticação e encriptação de redes virtuais.

Quando um utilizador envia um pedido a um Google Cloud serviço, protegemos os dados em trânsito (fornecendo autenticação, integridade e encriptação) através de HTTPS com um certificado de uma autoridade de certificação Web (pública). Todos os dados que o utilizador envia para o GFE são encriptados quando estão em trânsito com TLS ou QUIC. O GFE negoceia um protocolo de encriptação específico com o cliente, consoante o que o cliente pode suportar. O GFE negoceia protocolos de encriptação mais modernos sempre que possível.

Autenticação, integridade e encriptação de serviço a serviço

A infraestrutura da Google usa o ALTS para a autenticação, a integridade e a encriptação das ligações do GFE a um Google Cloud serviço e de um Google Cloud serviço a outro Google Cloud serviço.

O ALTS usa identidades baseadas em serviços para autenticação. Os serviços executados no ambiente de produção da Google emitem credenciais que afirmam as respetivas identidades baseadas em serviços. Ao fazer ou receber RPCs de outros serviços, um serviço usa as respetivas credenciais para fazer a autenticação. O ALTS verifica se estas credenciais são emitidas pela AC interna da Google. A AC interna da Google não está relacionada nem é independente do serviço de autoridade de certificação.

O ALTS usa encriptação e proteção de integridade criptográfica para o tráfego que transporta Google Cloud dados do GFE para um serviço e entre serviços que estão a ser executados no ambiente de produção da Google.

O ALTS também é usado para encapsular outros protocolos da camada 7, como o HTTP, em mecanismos RPC para tráfego entre GFEs e serviços do Google Cloud. Esta proteção ajuda a isolar a camada de aplicação e remove qualquer dependência da segurança do caminho de rede.

Métodos de encriptação em trânsito

As secções seguintes descrevem algumas das tecnologias que a Google utiliza para encriptar dados em trânsito.

Encriptação de rede através do PSP

O PSP é um protocolo independente do transporte que permite a segurança por ligação e suporta a transferência da encriptação para hardware de placa de interface de rede inteligente (SmartNIC). Sempre que as SmartNICs estão disponíveis, o ALTS usa o PSP para encriptar os dados em trânsito na nossa rede.

O PSP foi concebido para cumprir os requisitos do tráfego de centros de dados em grande escala. A infraestrutura da Google usa o PSP para encriptar o tráfego dentro e entre os nossos centros de dados. O PSP também suporta protocolos não TCP, como o UDP, e usa uma chave de encriptação única para cada ligação.

Application Layer Transport Security

O ALTS é um sistema de autenticação e encriptação mútua desenvolvido pela Google. O ALTS fornece autenticação, confidencialidade e integridade para os dados em trânsito entre os serviços executados no ambiente de produção da Google. O ALTS consiste nos seguintes protocolos:

  • Protocolo de handshake: o cliente inicia uma curva elíptica combinada e uma troca de chaves segura para o quantum. No final da troca de informações, os serviços envolvidos autenticam as identidades uns dos outros através da troca e validação de certificados assinados e calculam uma chave de tráfego partilhada. Entre os algoritmos suportados para derivar a chave de tráfego partilhada, encontra-se o algoritmo pós-quântico da NIST ML-KEM (FIPS 203). Para mais informações, consulte o artigo Criptografia pós-quântica.

  • Protocolo de registo: os dados de serviço a serviço são encriptados em trânsito através da chave de tráfego partilhada. Por predefinição, o ALTS usa a encriptação AES-128-GCM para todo o tráfego. Os dados em trânsito no sistema de armazenamento de nível mais baixo da Google usam a encriptação AES-256, e o ALTS fornece autenticação de mensagens AES. A encriptação no ALTS é fornecida pelo BoringSSL ou PSP. Esta encriptação é validada ao nível 1 da norma FIPS 140-2 ou ao nível 1 da norma FIPS 140-3.

As chaves de assinatura de raiz para certificados ALTS são armazenadas na AC interna da Google.

O que se segue?