Este conteúdo foi atualizado pela última vez em abril de 2025 e representa a situação no 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 viajando pela Internet, movendo-se pela infraestrutura do Google ou armazenados em 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. Neste artigo, descrevemos como projetamos Google Cloud para criptografar 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 do cliente e as redes de data centers do Google.
A criptografia em trânsito usa várias tecnologias para ajudar a proteger os dados, incluindo segurança de camada de transporte (TLS), BoringSSL, Application Layer Transport Security (ALTS) e o protocolo de segurança PSP. Além da proteção padrão fornecida pelo Google, é possível proteger ainda mais os dados adicionando opções de criptografia, como IPsec, certificados TLS gerenciados e Cloud Service Mesh.
Este documento destina-se a CISOs e equipes de operações de segurança que usam ou consideram a Google Cloud. Neste documento, consideramos um conhecimento básico sobre 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 peer (um humano ou um 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 (em inglês) 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 enquanto os dados são transmitidos 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 protege os dados contra possíveis invasores e elimina a necessidade de que o Google, Google Cloud os clientes ou os usuários finais confiem nas camadas mais baixas da rede.
Como o tráfego é encaminhado
Nesta seção, descrevemos como as solicitações passam de um usuário final para o serviçoGoogle Cloud ou aplicativo do cliente e como o tráfego é roteado entre os 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 serviço Google Cloud .
Um aplicativo do cliente é um aplicativo hospedado em Google Cloud que você, como cliente do Google, pode criar e implantar usando os serviços do Google Cloud. Aplicativos de clientes ou soluções de parceiros hospedados em Google Cloud não são considerados Google Cloud serviços. Por exemplo, um aplicativo criado usando o Cloud Run, o Google Kubernetes Engine ou uma VM no Compute Engine é 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 cliente hospedado em Google Cloud (identificado como B no diagrama)
- De máquina virtual para máquina virtual (identificada como C no diagrama)
- De máquina virtual para o Google Front End (GFE) (identificado como D no diagrama)
- 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)
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 roteamento do usuário final mostradas no diagrama anterior.
Usuário final para um Google Cloud serviço
Google Cloud serviços como o Cloud Storage ou o Compute Engine são serviços em nuvem que oferecemos aos clientes e executados em 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 conexões HTTP(S), TCP e TLS de entrada, fornece contramedidas para prevenir ataques DDoS, e encaminha e faz o balanceamento de carga do tráfego para os próprios serviços deGoogle Cloud . Os pontos de presença do GFE existem em todo o mundo, com caminhos que são anunciados usando unicast ou Anycast.
O GFE roteia o tráfego de um usuário final pela rede do Google para um serviço deGoogle Cloud e de um usuário final para um aplicativo do cliente hospedado em Google Cloud e que usa o Cloud Load Balancing.
As solicitações que os clientes enviam a um serviço Google Cloud 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 mantida pelo Google para o protocolo TLS. BoringCrypto, o núcleo do BoringSSL, é validado para o FIPS 140-3 nível 1 (em inglês).
O GFE negocia os parâmetros criptográficos padrão do setor com o cliente, incluindo a negociação de chaves com proteção direta. Para clientes mais antigos e menos capacitados, o GFE escolhe as primitivas criptográficas legadas mais fortes oferecidas pelo cliente.
Usuário final para um aplicativo do cliente hospedado em Google Cloud
É possível rotear o tráfego do usuário final da Internet para os aplicativos de cliente hospedados em Google Cloud usando uma conexão direta ou um balanceador de carga. Quando o tráfego é roteado diretamente, ele é encaminhado para o endereço IP externo do servidor da VM que hospeda o aplicativo.
É possível usar TLS com o balanceador de carga de aplicativo externo ou com o balanceador de carga de rede de proxy externo para se conectar ao aplicativo em execução em Google Cloud. Quando você usa um balanceador de carga de 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 seja compatível com 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 usar o Cloud Service Mesh para usar mTLS para autenticação mútua (cliente e servidor) e criptografar comunicações em trânsito usando certificados que você gerencia.
Para o Firebase Hosting e domínios personalizados do Cloud Run, considere nossos certificados TLS gratuitos e automatizados. Com os domínios personalizados do Cloud Run, também é possível fornecer seus próprios certificados SSL e usar um cabeçalho HTTP Restrito de segurança de transporte (HSTS, na sigla em inglês).
Criptografia em trânsito nas redes do Google
Google Cloud criptografa dados do cliente em trânsito nas redes do Google, a menos que descrito de outra forma nesta seção.
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. Em 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áquina GPU.
O tráfego por conexões com VMs que usam endereços IP externos 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
A rede virtual deGoogle Cloudcriptografa, protege a integridade e autentica o tráfego entre VMs.
A criptografia do tráfego IP privado na mesma VPC ou em redes VPC com peering na rede virtual de 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 pela integridade e criptografadas. A chave de sessão é usada para criptografar a comunicação de VM para VM entre esses hosts e as chaves de sessão são trocadas periodicamente.
As conexões VM para VM dentro das redes VPC e das redes VPC com peering dentro da rede de produção do Google são criptografadas e protegidas pela integridade. Essas conexões incluem conexões entre as VMs de clientes e entre o cliente e as VMs gerenciadas pelo Google, como o Cloud SQL. O diagrama em Como o tráfego é roteado mostra essa interação (identificada como conexão C). Observe que, 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 externos não são criptografadas automaticamente.
A rede virtual deGoogle Cloudautentica todo o tráfego entre VMs. Essa autenticação, realizada com 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 informações de autenticação sobre o remetente e o destinatário. O plano de controle no host de envio define o token, e o host de recebimento o valida. Os tokens de segurança são pré-gerados para cada fluxo e consistem em um token (contendo as informações do remetente) e a chave secreta do host.
Conectividade com APIs e serviços do Google
O processamento de tráfego difere dependendo de onde o serviço Google Cloud está hospedado.
A maioria das APIs e dos serviços do Google é hospedada em GFEs. O tráfego entre uma VM e o GFE usa endereços IP externos para acessar os serviços de Google Cloud . No entanto, é possível configurar o acesso particular para evitar o uso de endereços IP externos. A conexão entre o GFE e 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 nas instâncias de VM gerenciadas pelo Google usando endereços IP externos, o tráfego permanecerá na rede de produção do Google, mas não será criptografado automaticamente devido ao uso de endereços IP externos. Para mais informações, consulte Google Cloud Autenticação e criptografia de rede virtual.
Quando um usuário envia uma solicitação para um serviço Google Cloud , 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 da Web (pública). 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. O GFE negocia protocolos de criptografia mais modernos quando possível.
Autenticação, integridade e criptografia de serviço a serviço
A infraestrutura do Google usa o Gboard para autenticação, integridade e criptografia de conexões entre o GFE e um Google Cloud serviço e de um Google Cloud serviço para outro Google Cloud .
O Gboard usa identidades baseadas em serviço para autenticação. Os serviços em execução no ambiente de produção do Google são credenciais emitidas que declaram as identidades baseadas em serviço. Ao fazer ou receber RPCs de outros serviços, um serviço usa as próprias credenciais para se autenticar. O Gboard 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.
Ele usa criptografia e proteção da integridade criptográfica no tráfego que carrega Google Cloud dados do GFE para um serviço e entre os serviços em execução no ambiente de produção do Google.
Ele também é usado para encapsular outros protocolos da camada 7, como HTTP, em mecanismos de RPC para o 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 de rede.
Criptografia em métodos em trânsito
As seções a seguir descrevem algumas das tecnologias usadas pelo Google para criptografar dados em trânsito.
Criptografia de rede usando PSP
O PSP é um protocolo independente de transporte que ativa a segurança por conexão e é compatível com o descarregamento de criptografia para hardware de placa de interface de rede inteligente (SmartNIC). Sempre que as SmartNICs estiverem disponíveis, o sistema do sistema vai usar o PSP para criptografar dados em trânsito na 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 aceita protocolos diferentes de TCP, como o UDP, e usa uma chave de criptografia exclusiva para cada conexão.
Application Layer Transport Security
Ele é um sistema de autenticação e criptografia mútua desenvolvido pelo Google. O sistema oferece autenticação, confidencialidade e integridade para os dados em trânsito entre os serviços em execução no ambiente de produção do Google. Ele consiste nos seguintes protocolos:
Protocolo de handshake: o cliente inicia uma combinação de curva elíptica e troca de chaves com segurança quântica. No final do handshake, os serviços envolvidos autenticam as identidades uns dos outros ao trocar e verificar certificados assinados, além de calcular uma chave de tráfego compartilhada. Entre os algoritmos aceitos para derivar a chave de tráfego compartilhada está o algoritmo pós-quântico do NIST ML-KEM (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 sistema do Kubernetes 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 criptografia AES-256, e o sistema do TLS oferece a autenticação de mensagens AES. No sistema, a criptografia é fornecida pela BoringSSL ou PSP. Essa criptografia é validada no FIPS 140-2 nível 1 ou FIPS 140-3 nível 1.
As chaves de assinatura raiz dos certificados do Speakeasy são armazenadas na CA interna do Google.
A seguir
- Consulte Segurança dos data centers para mais informações sobre a segurança dos nossos data centers.
- Para informações sobre as opções de configuração de segurança para interconexões entre Google Cloud e redes de data center do cliente, consulte Como escolher um produto de conectividade de rede (IPSec) e a Visão geral do MACsec para o Cloud Interconnect.
- Para informações sobre Google Cloud compliance e certificações de conformidade, consulte a central de recursos de conformidade, que inclui nosso relatório de auditoria SOC 3.
- Para conferir as práticas recomendadas sobre como proteger seus dados em trânsito, consulte o blueprint de fundamentos do Enterprise, o Google Cloud framework de arquitetura: segurança, privacidade e conformidade e Decidir como atender aos requisitos regulamentares para criptografia em trânsito.