Criptografia em trânsito para Google Cloud

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

No Google, nossos controles de segurança ajudam a proteger seus dados, estejam eles na Internet, em movimento pela infraestrutura do Google ou armazenados nos nossos servidores. A autenticação, a integridade e a criptografia, tanto para dados em repouso quanto em trânsito, estão no centro da estratégia de segurança do Google. Este artigo descreve como projetamos Google Cloud a criptografia de dados em trânsito da internet e dados em trânsito nas redes do Google. Este documento não se aplica a dados em trânsito em interconexões entre redes de data center de clientes e redes de data center do Google.

A criptografia 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 padrão fornecida pelo Google, você pode proteger ainda mais os dados adicionando opções de criptografia, como IPsec, certificados TLS gerenciados e Cloud Service Mesh.

Este documento é destinado a diretores de segurança da informação e equipes de operações de segurança que já usam ou querem usar Google Cloud. Neste documento, presumimos um conhecimento básico de criptografia e primitivos criptográficos.

Autenticação, integridade e criptografia

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

  • A autenticação verifica a identidade de um par (humano ou processo) em uma conexão.
  • A integridade impede que os dados enviados sejam alterados durante o trânsito entre a origem e o destino.
  • A criptografia usa a criptografia para tornar seus dados ilegíveis durante o trânsito e mantê-los confidenciais.

A criptografia em trânsito ajuda a proteger seus dados caso a comunicação seja interceptada durante a transmissão dos dados entre o usuário final e Google Cloud ou entre dois serviços. A criptografia em trânsito autentica os endpoints e criptografa os dados antes da transmissão. Na chegada, o receptor descriptografa os dados e verifica se eles não foram modificados durante o trânsito.

A criptografia é um componente de uma estratégia de segurança mais ampla. A criptografia em trânsito defende seus dados contra possíveis invasores e elimina a necessidade de o Google, Google Cloud os clientes ou os usuários finais confiarem nas camadas inferiores da rede.

Como o tráfego é encaminhado

Nesta seção, descrevemos como as solicitações são enviadas de um usuário final e chegam ao serviço ou aplicativo do cliente adequado Google Cloud , além de explicar como o tráfego é encaminhado entre serviços.

Um Google Cloud serviço é um serviço de nuvem modular que oferecemos aos nossos clientes. Esses serviços incluem computação, armazenamento de dados, análise de dados e machine learning. Por exemplo, o Cloud Storage é um Google Cloud serviço.

Um aplicativo do cliente é um aplicativo hospedado no Google Cloud que você, como nosso cliente, pode criar e implantar usando os Google Cloud serviços. Aplicativos de clientes ou soluções de parceiros hospedados no Google Cloud não são considerados Google Cloud serviços. Por exemplo, quando você cria um aplicativo usando o Cloud Run, o Google Kubernetes Engine ou uma VM no Compute Engine, ele é considerado um aplicativo do cliente.

O diagrama a seguir mostra os caminhos de tráfego do usuário final para o Google, os caminhos na rede do Google e a segurança de cada conexão. Os seguintes caminhos de tráfego são mostrados:

  • Usuário final na Internet para um Google Cloud serviço (identificado como A no diagrama)
  • Usuário final na Internet para um aplicativo do cliente hospedado no Google Cloud (identificado como B no diagrama)
  • De máquina virtual para máquina virtual (identificado como C no diagrama)
  • Da máquina virtual para o Google Front End (GFE) (identificado como D no diagrama)
  • Do GFE para APIs e serviços do Google (identificado como E no diagrama)
  • Google Cloud De serviço para Google Cloud serviço (identificado como F no diagrama)

Caminhos de tráfego para o Google.

Criptografia em trânsito entre o usuário final e o Google

As seções a seguir fornecem mais detalhes sobre as solicitações de encaminhamento do usuário final mostradas no diagrama anterior.

Do usuário final para um serviço Google Cloud

Google Cloud Serviços como o Cloud Storage ou o Compute Engine são serviços de nuvem que oferecemos aos clientes e que são executados no nosso ambiente de produção. Google Cloud Os serviços aceitam solicitações de todo o mundo usando um sistema distribuído globalmente chamado Google Front End (GFE). O GFE encerra o tráfego de solicitações recebidas de proxies HTTP(S), TCP e TLS e fornece medidas para prevenção contra ataques de DDoS, além de encaminhar e balancear a carga de tráfego para os Google Cloud próprios serviços. Os pontos de presença do GFE existem em todo o mundo com caminhos anunciados usando unicast ou Anycast.

O GFE encaminha o tráfego de um usuário final pela rede do Google para um Google Cloud serviço e de um usuário final para um aplicativo do cliente que é hospedado no Google Cloud e usa Cloud Load Balancing.

As solicitações que os clientes enviam para um Google Cloud serviço por HTTPS, HTTP/2, ou HTTP/3 são protegidas com TLS. O TLS no GFE é implementado com BoringSSL, uma implementação de código aberto do protocolo TLS mantida pelo Google. O BoringCrypto, o núcleo do BoringSSL, é validado para o nível 1 do FIPS 140-3.

O GFE negocia parâmetros criptográficos padrão do setor com o cliente, incluindo a negociação de chaves com segurança direta. Para clientes mais antigos e menos capazes, o GFE escolhe os primitivos criptográficos legados mais fortes que o cliente oferece.

Do usuário final para um aplicativo do cliente hospedado no Google Cloud

Você pode encaminhar o tráfego do usuário final da Internet para os aplicativos do cliente hospedados no Google Cloud usando uma conexão direta ou por um balanceador de carga. Quando o tráfego é encaminhado diretamente, ele é encaminhado para o endereço IP externo do servidor de VM que hospeda o aplicativo.

Use o TLS com o balanceador de carga de aplicativo externo ou o balanceador de carga de rede de proxy externo para se conectar ao aplicativo em execução no Google Cloud. Quando você usa um balanceador de carga da camada 7, a conexão entre o usuário final e o balanceador de carga é criptografada usando TLS por padrão (desde que o aplicativo cliente do usuário final ofereça suporte a TLS). O GFE encerra as conexões TLS dos usuários finais usando certificados TLS autogerenciados ou gerenciados pelo Google. Para mais informações sobre como personalizar seu certificado, consulte Visão geral dos certificados SSL. Para ativar a criptografia entre o balanceador de carga e a VM que hospeda o aplicativo do cliente, consulte Criptografia do balanceador de carga para os back-ends.

Para configurar o TLS mútuo (mTLS), consulte Visão geral do TLS mútuo. Para cargas de trabalho no GKE e no Compute Engine, considere o Cloud Service Mesh para poder usar o mTLS na autenticação mútua (cliente e servidor) e criptografar as comunicações em trânsito usando certificados gerenciados por você.

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

Criptografia em trânsito nas redes do Google

Google Cloud criptografa os dados do cliente em trânsito nas redes do Google, a menos que descrito de outra forma nesta seção.

As interconexões especializadas de desempenho ultra-alto que conectam TPUs ou GPUs nos supercomputadores de IA do Google são separadas das redes descritas neste documento. Não Google Cloud, essas interconexões de desempenho ultra-alto são ICI para TPUs e NVLink para GPUs. Para mais informações, consulte Arquitetura de TPU e Tipos de máquinas de GPU.

O tráfego em conexões com VMs usando endereços IP externo sai das redes do Google. Você é responsável por configurar sua própria criptografia para essas conexões.

Google Cloud Autenticação e criptografia de rede virtual

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

A criptografia de tráfego de IP particular na mesma VPC ou em redes VPC com peering na rede virtual do Google Cloud'é realizada na camada da rede.

Cada par de hosts que estão se comunicando estabelece uma chave de sessão usando um canal de controle protegido por ALTS para comunicações autenticadas, protegidas por integridade e criptografadas. A chave de sessão é usada para criptografar a comunicação de VM para VM entre os hosts. Essas chaves são alternadas periodicamente.

As conexões entre VMs nas redes VPC e redes VPC com peering dentro da rede de produção do Google são protegidas por integridade e criptografadas. Essas conexões incluem conexões entre VMs de clientes e entre VMs gerenciadas pelo cliente e pelo Google, como o Cloud SQL. O diagrama em Como o tráfego é encaminhado mostra essa interação (identificada como conexão C). Como o Google ativa a criptografia automática com base no uso de endereços IP internos, as conexões entre VMs que usam endereços IP externo não são criptografadas automaticamente.

Google CloudA rede virtual doautentica todo o tráfego entre VMs. Essa autenticação, realizada com o uso de tokens de segurança, impede que um host comprometido faça spoofing de pacotes na rede.

Os tokens de segurança são encapsulados em um cabeçalho de túnel que contém as informações de autenticação de quem envia e de quem recebe os dados. O token é configurado pelo plano de controle do host de envio e validado pelo host de recebimento. Os tokens de segurança são gerados com antecedência para cada fluxo. Eles consistem em um token (contendo as informações de quem envia os dados) e a chave secreta do host.

Conectividade com APIs e serviços do Google

O gerenciamento de tráfego varia de acordo com o local do Google Cloud serviço hospedado.

A maioria das APIs e dos serviços do Google são hospedados no GFE. O tráfego entre uma VM e o GFE usa endereços IP externo para acessar Google Cloud serviços, mas é possível configurar o acesso particular para evitar o uso de endereços IP externo. A conexão do GFE com o serviço é autenticada e criptografada.

Alguns serviços, como o Cloud SQL, são hospedados em instâncias de VM gerenciadas pelo Google. Se as VMs do cliente acessarem os serviços hospedados em instâncias de VM gerenciadas pelo Google usando endereços IP externo, o tráfego permanecerá na rede de produção do Google, mas não será criptografado automaticamente devido ao uso dos endereços IP externo. Para mais informações, consulte Google Cloud autenticação e criptografia de rede virtual.

Quando um usuário envia uma solicitação para um Google Cloud serviço, nós protegemos os dados em trânsito (fornecendo autenticação, integridade e criptografia) usando HTTPS com um certificado de uma autoridade de certificação (pública) da Web. Todos os dados que o usuário envia para o GFE são criptografados em trânsito com TLS ou QUIC. O GFE negocia um determinado protocolo de criptografia com o cliente, dependendo do que ele aceita. Quando possível, o GFE negocia protocolos de criptografia mais modernos.

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

A infraestrutura do Google usa o ALTS para autenticação, integridade e criptografia de conexões do GFE para um Google Cloud serviço e de um Google Cloud serviço para outro Google Cloud serviço.

O ALTS usa identidades baseadas em serviço para autenticação. Os serviços em execução no ambiente de produção do Google recebem credenciais que afirmam suas identidades baseadas em serviço. Ao fazer ou receber RPCs de outros serviços, o serviço usa as próprias credenciais para se autenticar. O ALTS verifica se essas credenciais são emitidas pela AC interna do Google. A AC interna do Google não tem relação e é independente do Certificate Authority Service.

O ALTS usa criptografia 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 em execução no ambiente de produção do Google.

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

Métodos de criptografia em trânsito

As seções a seguir descrevem algumas das tecnologias que o Google usa para criptografar dados em trânsito.

Criptografia de rede usando PSP

O PSP é um protocolo independente de transporte que permite a segurança por conexão e oferece suporte ao descarregamento de criptografia em um hardware de placa de interface de rede inteligente (SmartNIC, na sigla em inglês). Sempre que as SmartNICs estão disponíveis, o ALTS usa o PSP para criptografar dados em trânsito em toda a nossa rede.

O PSP foi projetado para atender aos requisitos de tráfego em grande escala de data center. A infraestrutura do Google usa o PSP para criptografar o tráfego dentro e entre nossos data centers. O PSP também oferece suporte a protocolos não TCP, como UDP, e usa uma chave de criptografia exclusiva para cada conexão.

Application Layer Transport Security

O ALTS é um sistema de autenticação e criptografia mútua desenvolvido pelo Google. O ALTS oferece autenticação, confidencialidade e integridade para dados em trânsito entre serviços em execução no ambiente de produção do Google. O ALTS consiste nos seguintes protocolos:

  • Protocolo de handshake:o cliente inicia uma troca de chaves combinada de curva elíptica e resistente a ataques quânticos. No final do handshake, os serviços envolvidos autenticam as identidades uns dos outros trocando e verificando certificados assinados e calculam uma chave de tráfego compartilhada. Entre os algoritmos com suporte para derivar a chave de tráfego compartilhada está o algoritmo pós-quântico ML-KEM do NIST (FIPS 203). Para mais informações, consulte Criptografia pós-quântica .

  • Protocolo de registro:os dados de serviço a serviço são criptografados em trânsito usando a chave de tráfego compartilhada. Por padrão, o ALTS usa a criptografia AES-128-GCM para todo o tráfego. Os dados em trânsito no sistema de armazenamento de nível mais baixo do Google usam a criptografia AES-256, e o ALTS fornece autenticação de mensagens AES. A criptografia no ALTS é fornecida pelo BoringSSL ou PSP. Essa criptografia é validada no nível 1 do FIPS 140-2 ou no nível 1 do FIPS 140-3.

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

A seguir