Criptografia em trânsito

Este é o terceiro whitepaper sobre como o Google usa criptografia para proteger dados de usuários. Neste artigo, você verá mais detalhes sobre a criptografia em trânsito para o Google Cloud e o Google Workspace.

Nós nos dedicamos a manter os dados do cliente protegidos em todos os produtos do Google e tentamos ser o mais transparentes possível sobre a segurança das informações.

Este conteúdo foi atualizado pela última vez em setembro de 2022 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 a proteção dos clientes é aprimorada.

Resumo para CIOs

• O Google emprega várias medidas de segurança para garantir a autenticidade, a integridade e a privacidade dos dados em trânsito.
• Para os casos de uso discutidos neste whitepaper, o Google criptografa e autentica dados em trânsito em uma ou mais camadas de rede quando eles são transferidos para outros limites físicos não controlados pelo Google ou em nome dele. Todo o tráfego de VM para VM em uma rede VPC e em redes VPC com peering é criptografado.
• Dependendo da conexão que está sendo feita, o Google aplica proteções padrão aos dados em trânsito. Por exemplo, protegemos as comunicações entre o usuário e o Google Front End (GFE) usando TLS.
• Os clientes do Google Cloud que tenham outros requisitos para a criptografia de dados pela WAN podem optar por implementar outras proteções para dados à medida que eles mudam de um usuário para um aplicativo ou entre máquinas virtuais. Essas proteções incluem túneis IPSec, S/MIME para Gmail, certificados SSL gerenciados e Istio.
• O Google trabalha ativamente com o setor para que a criptografia em trânsito seja acessível a todos. Temos vários projetos de código aberto que incentivam o uso de criptografia em trânsito e a segurança de dados na Internet como um todo, incluindo transparência dos certificados, APIs do Chrome e SMTP seguro.
• O Google quer continuar sendo o líder do setor em criptografia em trânsito. Para isso, dedicamos recursos ao desenvolvimento e aprimoramento da tecnologia de criptografia. Nessa área, nosso trabalho conta com inovações em Key Transparency e na criptografia pós-quântica.

Introdução

A segurança é frequentemente um fator decisivo na escolha de um provedor de nuvem pública. No Google, a segurança é nossa maior prioridade. Trabalhamos incansavelmente para proteger suas informações, estejam elas na Internet, em movimento pela infraestrutura do Google ou armazenadas 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. Neste documento, descrevemos nossa abordagem para criptografia em trânsito no Google Cloud.

Para mais informações sobre dados em repouso, consulte Criptografia em repouso no Google Cloud Platform. Você também pode ter uma visão geral de toda a segurança do Google no artigo Visão geral do esquema de segurança da infraestrutura do Google.

Público-alvo: diretores de segurança da informação e equipes de operações de segurança que já utilizam ou querem utilizar o Google Cloud.

Pré-requisitos: além desta introdução, supomos que o leitor tenha algum conhecimento sobre criptografia e primitivas criptográficas.

Autenticação, integridade e criptografia

O Google emprega várias medidas de segurança para garantir a autenticidade, a integridade e a privacidade dos dados em trânsito.

• Autenticação: verificamos a fonte, seja ela um humano ou um processo, e o destino dos dados.
• Integridade: verificamos se os dados enviados chegam inalterados ao destino.
• Criptografia: tornamos os dados ilegíveis durante o trânsito, para mantê-los particulares. A criptografia é o processo em que dados legíveis (texto simples) ficam ilegíveis (texto criptografado) para serem acessados somente por pessoas autorizadas pelo respectivo proprietário. Os algoritmos utilizados no processo de criptografia são públicos, mas a chave necessária para descriptografar o texto criptografado é particular. Geralmente, a criptografia em trânsito faz uso da troca de chaves assimétricas, como de Diffie-Hellman, baseada em curva elíptica, para estabelecer uma chave simétrica compartilhada que será usada na criptografia dos dados. Para mais informações sobre criptografia, consulte Introdução à criptografia moderna.

A criptografia pode ser usada para proteger dados em três estados:

• Criptografia em repouso: protege os dados por meio da criptografia durante o armazenamento, para que não sejam exfiltrados ou afetados em caso de comprometimento do sistema. Frequentemente, usa-se o padrão de criptografia avançada (AES) para criptografar dados em repouso.
• Criptografia em trânsito: protege os dados caso a comunicação seja interceptada durante a transmissão dos dados entre um site e um provedor de nuvem ou entre dois serviços. Essa proteção é feita pela criptografia dos dados antes da transmissão. Autenticação dos endpoints e, na chegada, descriptografando e verificando se os dados não foram modificados. Por exemplo, muitas vezes, usamos o protocolo Transport Layer Security (TLS) para criptografar dados em trânsito e garantir a segurança de transporte e as Secure/Multipurpose Internet Mail Extensions (S/MIME) para proteger mensagens de e-mail.
• Criptografia em uso: protege os dados na memória contra comprometimento ou exfiltração de dados criptografando os dados durante o processamento. Para saber mais, consulte Computação confidencial.

A criptografia é um componente de uma estratégia de segurança mais ampla. A criptografia em trânsito tem o propósito de proteger os dados contra ataques após o estabelecimento e a autenticação de uma conexão, ao:

• acabar com a necessidade de confiar nas camadas mais inferiores da rede que normalmente são fornecidas por terceiros;
• reduzir a superfície de ataques em potencial;
• impedir que invasores acessem os dados em caso de interceptação das comunicações.

Ao promover autenticação, integridade e criptografia adequadas, é possível proteger os dados transmitidos entre usuários, dispositivos ou processos em um ambiente perigoso. No restante deste documento, detalhamos a abordagem do Google quanto à criptografia de dados em trânsito e onde ela é aplicada.

Infraestrutura de rede do Google

Limites físicos

Um limite físico é a barreira de um espaço físico controlado por ou em nome do Google, em que podemos garantir a aplicação das nossas rigorosas medidas de segurança. O acesso físico a esses locais é restrito e rigorosamente monitorado. Apenas uma pequena parte dos funcionários do Google tem acesso ao hardware. Os dados em trânsito dentro desses limites físicos geralmente são autenticados, mas não são criptografados por padrão.

Devido à escala global da Internet, não podemos aplicar os mesmos controles de segurança física aos links de fibra em nossa WAN ou em qualquer lugar fora dos limites físicos controlados por ou em nome do Google. Por esse motivo, automaticamente impomos proteções adicionais fora do limite físico confiável. Essas proteções incluem criptografia de dados em trânsito para todo o tráfego fora dos nossos limites físicos.

Como o tráfego é encaminhado

Para que você entenda completamente como a criptografia em trânsito funciona no Google, precisamos também explicar como o tráfego é encaminhado pela Internet. Nesta seção, descreveremos como as solicitações são enviadas de um usuário final e chegam ao serviço adequado do Google Cloud ou ao aplicativo do cliente, além de explicar como o tráfego é encaminhado entre serviços.

Um serviço do Google Cloud é 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 do Google Cloud. Um aplicativo do cliente é um aplicativo hospedado no Google Cloud que você, como nosso cliente, pode criar e implantar usando os serviços do Google Cloud. Aplicativos de clientes ou soluções de parceiros hospedados no Google Cloud não são classificados como serviços do Google Cloud¹. Por exemplo, quando você cria um aplicativo com o Google App Engine, o Google Kubernetes Engine ou uma VM no Google Compute Engine, ele é considerado um aplicativo do cliente.

Os cinco tipos de solicitações de encaminhamento abordados abaixo são mostrados na Figura 1. Ela mostra as interações entre os vários componentes de rede e as medidas de segurança aplicadas em cada conexão.

Do usuário final (Internet) para um serviço do Google Cloud

Os serviços do Google Cloud 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 próprios serviços do Google Cloud. O GFE tem pontos de presença em todo o mundo, com rotas anunciadas via unicast ou Anycast.

Os GFEs intermedeiam o tráfego direcionado aos serviços do Google Cloud. Eles encaminham as solicitações dos usuários pelo nosso backbone de rede para um serviço do Google Cloud. Essa conexão é autenticada e criptografada desde o GFE até o front-end do serviço do Google Cloud ou do aplicativo do cliente, assim que as comunicações saem do limite físico controlado por ou em nome do Google. A Figura 1 mostra essa interação (identificada como conexão A).

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

Há várias maneiras de encaminhar o tráfego da Internet para um aplicativo do cliente hospedado no Google Cloud. A forma como isso acontece depende da configuração do cliente, conforme explicado abaixo. A Figura 1 mostra essa interação (identificada como conexão B).

Se você estiver usando um balanceador de carga de aplicativo externo ou um balanceador de carga de rede de proxy externo (com um proxy SSL), consulte Criptografia do balanceador de carga para os back-ends.

De máquina virtual para máquina virtual

As conexões entre VMs nas redes VPC e redes VPC com peering dentro da rede de produção do Google são autenticadas e criptografadas. Isso inclui conexões entre VMs de clientes e entre VMs gerenciadas pelo cliente e pelo Google, como o Cloud SQL. A Figura 1 mostra essa interação (identificada como conexão C). Observe que as conexões de VM para VM que usam endereços IP externos não são criptografadas.

Conectividade com APIs e serviços do Google

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

• A maioria das APIs e dos serviços do Google são hospedados no Google Front Ends (GFEs). No entanto, alguns serviços são hospedados em instâncias gerenciadas pelo Google. Por exemplo, o acesso a serviços privados e os mestres do GKE para clusters particulares são hospedados em instâncias gerenciadas pelo Google.

  Com o Acesso privado do Google, as VMs que não têm endereços IP externos podem acessar APIs e serviços do Google compatíveis, incluindo aplicativos cliente hospedados no App Engine. Para mais informações sobre o acesso a APIs e serviços do Google, consulte Opções de acesso privado para serviços.

• Se uma instância de VM do Compute Engine se conectar ao endereço IP externo de outra, o tráfego permanecerá na rede de produção do Google, mas não será criptografado devido ao uso do endereço IP externo. Os sistemas que estão fora da rede de produção do Google que se conectam a um endereço IP externo de uma instância de VM do Compute Engine têm tráfego roteado pela Internet.

  Na Figura 1, é exibido um caminho externo (identificado como conexão D). Os casos típicos desse tipo de roteamento são estes:

  • De uma VM do Compute Engine ao Google Cloud Storage.
  • De uma VM do Compute Engine a uma API Machine Learning.

Da VM para o GFE, os serviços do Google Cloud são compatíveis com a proteção por TLS para essas conexões.². A conexão é autenticada no tráfego do GFE para o serviço e criptografada caso saia do limite físico. Além dessas proteções padrão, é possível aplicar a criptografia de envelope. Para mais informações, consulte Criptografar seus dados.

De um serviço do Google Cloud para outro

O encaminhamento entre serviços de produção ocorre no nosso backbone de rede. Às vezes, é necessário encaminhar o tráfego para fora dos limites físicos controlados por ou em nome do Google. A Figura 1 mostra essa interação (identificada como conexão E). Como exemplo desse tipo de tráfego podemos mencionar um evento do Google Cloud Storage que aciona o Google Cloud Functions. As conexões entre serviços de produção são autenticadas dentro do limite físico e criptografadas quando saem dele.

Figura 1: proteção por padrão e opções sobrepostas em uma rede VPC

Criptografia em trânsito por padrão

O Google usa vários métodos de criptografia de dados em trânsito, tanto por padrão como configuráveis pelo usuário. O tipo de criptografia depende da camada OSI, do tipo de serviço e do componente físico da infraestrutura. As figuras 2 e 3 abaixo ilustram as proteções opcionais e padrão que o Google Cloud aplica às camadas 3, 4 e 7.

Figura 2: proteções padrão e opções nas camadas 3 e 4 no Google Cloud

Figura 3: proteções padrão e opcionais na camada 7 do Google Cloud³

O restante desta seção descreve as proteções padrão que o Google usa para proteger dados em trânsito.

Criptografia do tráfego entre o usuário e o Google Front End

Atualmente, muitos sistemas usam HTTPS para se comunicarem pela Internet. O HTTPS oferece segurança usando uma conexão TLS, o que garante a autenticidade, a integridade e a privacidade de solicitações e respostas. Para aceitar solicitações HTTPS, o receptor requer um par de chaves pública/privada e um certificado X.509 para que uma autoridade de certificação (CA) autentique o servidor. Com o par de chaves e o certificado, as solicitações do usuário na camada 7 (do aplicativo) ficam mais protegidas porque esses dois elementos comprovam que o receptor é o proprietário do nome do domínio de destino das solicitações. Nas subseções a seguir, discutimos os componentes do usuário na criptografia do GFE: TLS, BoringSSL e a autoridade de certificação do Google. Lembre-se de que nem todos os caminhos de cliente fazem encaminhamento via GFE. Ele é usado, sobretudo, no tráfego de um usuário para um serviço do Google Cloud ou para um aplicativo do cliente hospedado no Google Cloud que usa o Google Cloud Load Balancing.

Transport Layer Security (TLS)

Quando um usuário envia uma solicitação para um serviço do Google Cloud, nós protegemos os dados em trânsito por meio de autenticação, integridade e criptografia, usando HTTPS com um certificado proveniente 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 Transport Layer Security (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.

A criptografia por TLS escalada do GFE não é apenas aplicada às interações do usuário final com o Google, mas também facilita as interações da API com o Google por TLS, incluindo com o Google Cloud. Além disso, nossa criptografia por TLS é usada no Gmail para a troca de mensagens com servidores de e-mails externos. Para mais detalhes, consulte TLS obrigatório no Gmail.

O Google é um líder do setor, tanto na adoção do TLS quanto no fortalecimento da implementação deste protocolo. Por esse motivo, ativamos por padrão muitos dos recursos de segurança do TLS. Por exemplo, usamos forward secrecy desde 2011 na nossa implementação do TLS. Com o forward secrecy, garantimos que a chave que protege uma conexão não seja mantida permanentemente. Dessa forma, um invasor que interceptar e ler uma mensagem não conseguirá ler as mensagens anteriores.

BoringSSL

BoringSSL é uma ferramenta de implementação de código aberto do protocolo TLS, criada com base na OpenSSL, mantida pelo Google e compatível com essa interface. O Google criou a BoringSSL com base na OpenSSL para simplificar o uso interno e auxiliar essa biblioteca com os projetos do Chromium e do Android Open Source Project. BoringCrypto, o núcleo da BoringSSL, foi validado quanto à conformidade com o FIPS 140-2 nível 1.

O TLS no GFE é implementado com o BoringSSL. A Tabela 1 mostra os protocolos de criptografia que o GFE aceita para se comunicar com os clientes.

Protocolos	Autenticação	Troca de chaves	Criptografia	Funções de hash
TLS 1.3	RSA 2048	Curve25519	AES-128-GCM	SHA384
TLS 1.2	ECDSA P-256	P-256 (NIST secp256r1)	AES-256-GCM	SHA256
TLS 1.1			AES-128-CBC	SHA17
TLS 1.04			AES-256-CBC	MD58
QUIC5			ChaCha20-Poly1305
			3DES6

Tabela 1: criptografia implementada no Google Front End para os serviços do Google Cloud na biblioteca criptográfica da BoringSSL

Autoridade de certificação do Google

Como parte do TLS, um servidor precisa provar a identidade dele ao usuário quando recebe uma solicitação de conexão. Essa verificação é realizada no protocolo TLS quando o servidor apresenta um certificado contendo a identidade declarada. O certificado contém tanto o nome de host DNS quanto a chave pública do servidor. Depois de apresentado, o certificado é assinado por uma autoridade de certificação (CA) emissora de confiança do usuário que solicitou a conexão⁹. Como resultado, os usuários que solicitam conexões com o servidor precisam somente confiar na CA raiz. Caso o servidor deva ser acessado universalmente, a CA raiz precisa ser conhecida pelos dispositivos de clientes no mundo todo. Atualmente, a maioria dos navegadores e outras implementações de clientes TLS têm o próprio conjunto de CAs raiz configuradas como confiáveis no "repositório raiz".

Há muito tempo que o Google opera a própria CA emissora, que usávamos para assinar certificados para os domínios do Google. No entanto, não operávamos nossa própria CA raiz. Hoje em dia, nossos certificados de CA são assinados por várias CAs raiz que são distribuídas de maneira universal, incluindo a Symantec ("GeoTrust") e raízes operadas anteriormente pela GlobalSign ("GS Root R2" e "GS Root R4").

Em junho de 2017, anunciamos uma transição para o uso de CAs raiz de propriedade do Google. Futuramente, planejamos operar uma CA raiz distribuída universalmente que emitirá certificados para os domínios do Google e nossos clientes.

Migração de chave raiz e rotação de chaves

As chaves da CA raiz não são alteradas com frequência porque a migração para uma CA raiz nova exige que todos os navegadores e dispositivos incorporem a confiança desse certificado, o que leva muito tempo. Como resultado, mesmo com o Google agora operando as próprias CAs raiz, continuaremos confiando em várias CAs raiz de terceiros por um período de transição para atender aos dispositivos legados, enquanto estivermos migrando para as nossas próprias CAs.

Criar uma CA raiz nova requer uma cerimônia de chave. No Google, a cerimônia exige que, no mínimo, três dos seis indivíduos autorizados se reúnam presencialmente para usar as chaves de hardware armazenadas em um cofre. Esses indivíduos devem se encontrar em uma sala apropriada, protegida contra interferências eletromagnéticas, com um módulo de segurança de hardware (HSM, na sigla em inglês) fisicamente isolado, para gerar um conjunto de chaves e certificados. Essa sala está em um local seguro nos data centers do Google. Controles adicionais, como medidas de segurança física, câmeras e outros observadores humanos, garantem que o processo seja realizado conforme planejado. Se a cerimônia for bem-sucedida, o certificado gerado será idêntico a uma amostra de certificado, com exceção do nome do emissor, da chave pública e da assinatura. O certificado da CA raiz gerado é, então, enviado aos navegadores e dispositivos para a incorporação nos programas raiz deles. Esse processo foi concebido para assegurar que seja de conhecimento geral que as chaves privadas associadas têm privacidade e segurança garantidas e, dessa forma, possam ser consideradas como confiáveis por um período de dez anos ou mais.

Conforme descrito anteriormente, as CAs usam as próprias chaves privadas para assinar certificados que, por sua vez, verificam as identidades no início do processo de handshake de TLS na sessão do usuário. Os certificados de servidores são assinados com CAs intermediárias, sendo a criação semelhante à criação de uma CA raiz. Os certificados da CA intermediária são distribuídos como parte da sessão TLS, facilitando a migração para uma nova CA intermediária. Esse método de distribuição também permite que o operador da CA mantenha o material da chave da CA raiz em um estado off-line.

A segurança da sessão TLS depende de a chave do servidor estar bem protegida. Para reduzir ainda mais o risco de comprometimento da chave, a vida útil do certificado de TLS do Google é limitada a, aproximadamente, três meses. Além disso, os certificados são alternados a cada duas semanas, mais ou menos.

Um cliente conectado a um servidor usa uma chave de tíquete privada¹⁰ para retornar à sessão anterior com um handshake de TLS reduzido. Por isso, esses tíquetes são muito valiosos para os invasores. O Google alterna as chaves dos tíquetes pelo menos uma vez por dia. As chaves perdem a validade em todas as propriedades a cada três dias. Para mais informações sobre a rotação de tíquetes de chaves de sessão, consulte o artigo Measuring the Security Harm of TLS Crypto Shortcuts.

Do Google Front End para front-ends de aplicativos

Em alguns casos, conforme discutido na sessão Como o tráfego é encaminhado, o usuário se conecta a um GFE dentro de um limite físico diferente do serviço desejado e dos front-ends de aplicativos associados. Quando isso ocorre, a solicitação do usuário e todos os outros protocolos da camada 7, como HTTP, são protegidos por TLS ou encapsulados em uma RPC que, por sua vez, é protegida pelo Application Layer Transport Security (ALTS), mencionado na seção Autenticação, integridade e criptografia de serviço a serviço. Essas RPCs são autenticadas e criptografadas.

Para serviços do Google Cloud, as RPCs são protegidas pelo ALTS. No caso de aplicativos do cliente hospedados no Google Cloud, se o tráfego for encaminhado via Google Front End (por exemplo, caso o Google Cloud Load Balancer seja usado), o tráfego para a VM será protegido pela criptografia de rede virtual do Google Cloud, descrita na próxima seção.

Criptografia e autenticação da rede virtual do Google Cloud

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.

Usamos o padrão de criptografia avançada (AES) no modo de contador/Galois (GCM, na sigla em inglês) com uma chave de 128 bits (AES-128-GCM) para implementar a criptografia na camada da rede. Cada par de hosts que estão se comunicando estabelece uma chave de sessão por meio de um canal de controle protegido por ALTS para comunicações autenticadas e criptografadas. A chave de sessão é usada para criptografar todas as comunicações de VM para VM entre os hosts. Essas chaves são alternadas periodicamente.

Na camada 3 (da rede), a rede virtual do Google Cloud autentica todo o tráfego entre VMs. Esse processo, realizado com o uso de tokens de segurança, protege um host comprometido contra pacotes de spoofing.

Durante a autenticação, 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 remetente e validado pelo host de recebimento. Os tokens de segurança são gerados com antecedência para cada fluxo. Eles consistem em uma chave de token (contendo as informações de quem envia os dados) e a chave secreta do host. Há uma chave secreta para cada par de fonte/receptor dos limites físicos controlados por ou em nome do Google.

A Figura 4 mostra como as chaves de token, os secrets do host e os tokens de segurança são criados.

Figura 4: tokens de segurança

A chave secreta do limite físico é um número pseudoaleatório de 128 bits que dá origem às chaves secretas do host ao assumir um HMAC-SHA1. Ela é negociada por um handshake entre os planos de controle da rede de um par de limites físicos e renegociada a cada poucas horas. Os tokens de segurança usados para a autenticação de cada conexão individual entre VMs, derivados dessas e de outras entradas, são HMACs negociados para um determinado par de remetente e receptor.

Criptografia do tráfego entre a máquina virtual e o Google Front End

No tráfego entre uma VM e o GFE, são usados IPs externos para acessar serviços do Google. No entanto, é possível configurar o Acesso particular para usar endereços IP exclusivos do Google nas solicitações.

Por padrão, aceitamos tráfego TLS de uma VM para o GFE. A conexão acontece da mesma maneira que qualquer outra conexão externa. Para mais informações sobre o TLS, consulte Transport Layer Security (TLS).

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

Dentro da infraestrutura do Google, na camada 7 (do aplicativo), usamos nosso Application Layer Transport Security (ALTS) para fazer a autenticação, manter a integridade e realizar a criptografia de chamadas da RPC do Google que partem do GFE ou de um serviço com destino a outro serviço.

O ALTS usa contas de serviço para fazer a autenticação. Cada serviço na infraestrutura do Google é executado como uma identidade de conta de serviço com credenciais criptográficas associadas. Ao fazer ou receber RPCs de outros serviços, o serviço usa as próprias credenciais para se autenticar. O ALTS verifica essas credenciais usando uma autoridade de certificação interna.

Dentro de um limite físico controlado por ou em nome do Google, o ALTS faz a autenticação e mantém a integridade de RPCs no modo "autenticação e integridade". No caso do tráfego transmitido por WAN fora dos limites físicos controlados por ou em nome do Google, o ALTS aplica automaticamente a criptografia ao tráfego de RPCs na infraestrutura, no modo "autenticação, integridade e privacidade". Atualmente, todo o tráfego direcionado a serviços do Google, incluindo os serviços do Google Cloud, é beneficiado com essas mesmas proteções.

O ALTS também é usado para encapsular outros protocolos da camada 7, como HTTP, em mecanismos de RPC da infraestrutura para o tráfego em trânsito do Google Front End para o front-end de aplicativos. Essa proteção isola a camada do aplicativo e remove qualquer dependência na segurança do caminho da rede.

Os serviços de infraestrutura de segurança aceitam e enviam comunicações do Spinnaker apenas no modo "autenticação, integridade e privacidade", mesmo dentro dos limites físicos controlados pelo Google ou em nome dele. Um exemplo é o Keystore, que armazena e gerencia as chaves de criptografia usadas para proteger os dados armazenados em repouso na infraestrutura do Google.

Criptografia de rede usando PSP

O PSP (protocolo de segurança do PSP) é independente do transporte, 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, usamos 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. Usamos o PSP para criptografar o tráfego entre nossos data centers. O PSP é compatível com protocolos não TCP, como UDP, e usa uma chave de criptografia para cada conexão da camada 4.

Para mais informações sobre como usamos o PSP, consulte Como anunciar o descarregamento de hardware criptográfico do PSP em escala agora é de código aberto.

Protocolo do ALTS

O ALTS tem um protocolo de handshake seguro semelhante ao TLS mútuo. Dois serviços que querem se comunicar usando o ALTS empregam esse protocolo de handshake para autenticar e negociar os parâmetros de comunicação antes de enviar qualquer informação confidencial. O protocolo é um processo em duas etapas:

• Etapa 1: handshake. O cliente usa o Curve25519 para iniciar um handshake Diffie Hellman de curva elíptica (ECDH, na sigla em inglês) com o servidor. Tanto o cliente quanto o servidor têm parâmetros públicos ECDH certificados como parte do certificado de cada um que será usado durante a troca de chaves Diffie Hellman. O handshake resulta em uma chave de tráfego comum, disponível no cliente e no servidor. As identidades das partes expressas nos certificados são exibidas para que a camada do aplicativo as utilize nas decisões de autorização.
• Etapa 2: criptografia do registro. A chave de tráfego comum, gerada na primeira etapa, é usada para transmitir, com segurança, o tráfego do cliente para o servidor. No ALTS, a criptografia é implementada com o uso de BoringSSL e outras bibliotecas de criptografia. Geralmente o modo de criptografia adotado é AES-128-GCM, e a integridade é garantida pelo GMAC da AES-GCM.

O diagrama a seguir mostra o handshake do ALTS de forma detalhada. Nas implementações mais recentes, um auxiliar de processos realiza o handshake. No entanto, ainda há alguns casos em que esse processo é realizado diretamente pelos aplicativos.

Figura 5: handshake do ALTS

Conforme descrito no início da seção Autenticação, integridade e criptografia de serviço a serviço, o ALTS usa contas de serviço para fazer a autenticação, sendo que cada serviço na infraestrutura do Google é executado como uma identidade de serviço com credenciais criptográficas associadas. Durante o handshake do ALTS, o auxiliar de processos acessa as chaves privadas e os certificados correspondentes usados por cada par de cliente/servidor nas comunicações deles. A chave privada e o certificado correspondente (buffer de protocolo assinado) são provisionados para a identidade da conta de serviço em questão.

Certificados do ALTS Há vários tipos de certificados do ALTS:

• Certificados de máquinas: fornecem uma identidade aos serviços principais em uma máquina específica. Esses certificados são alternados a cada 6 horas aproximadamente.
• Certificados de usuários: fornecem uma identidade de usuário final para um código de desenvolvimento do engenheiro do Google. Esses certificados são revezados a cada 20 horas aproximadamente.
• Certificados de jobs Borg: fornecem uma identidade aos jobs em execução na infraestrutura do Google. Esses certificados são alternados a cada 48 horas aproximadamente.

A chave de assinatura do certificado raiz é armazenada com a autoridade de certificação (CA) interna do Google, que é independente e não tem relação com nossa CA externa.

Criptografia no ALTS

É possível implementar a criptografia no ALTS por meio de vários algoritmos, dependendo das máquinas usadas. Por exemplo, a maioria dos serviços usa AES-128-GCM¹². Para saber mais sobre a criptografia no ALTS, consulte a Tabela 2.

Máquinas	Criptografia usada nas mensagens
Mais comum	AES-128-GCM
Sandy Bridge ou mais antigas	AES-128-VCM	Usa um VMAC, em vez de um GMAC, e é um pouco mais eficiente em máquinas antigas.

Tabela 2: criptografia no ALTS

A maioria dos serviços do Google usa o ALTS ou encapsulamento de RPCs com uso do ALTS. Nos casos em que o ALTS não é utilizado, outras proteções são empregadas. Exemplo:

• alguns serviços de gerenciamento de máquinas e bootstrap de nível inferior usam SSH;
• Alguns serviços de geração de registros da infraestrutura de nível inferior usam TLS ou Datagram TLS (DTLS)¹³
• Alguns serviços que utilizam transportes diferentes de TCP usam outros protocolos criptográficos ou proteções no nível da rede, quando o tráfego ocorre nos limites físicos controlados pelo Google ou em nome dele.

As comunicações entre VMs e os serviços do Google Cloud Platform usam TLS para se comunicar com o Google Front End, em vez do ALTS. Descrevemos esse tipo de comunicação em Criptografia do tráfego entre a máquina virtual e o Google Front End.

Como configurar outra criptografia nas opções de transporte público

É possível configurar proteções para seus dados quando eles estiverem em trânsito entre o Google Cloud e seus data centers ou em trânsito entre os aplicativos hospedados no Google Cloud e dispositivos de usuários.

Se você estiver conectando seu data center ao Google Cloud, considere o seguinte:

• 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 serviço de nuvem. O GFE encerra as conexões TLS dos usuários usando certificados SSL provisionados e controlados por você. Para mais informações sobre como personalizar seu certificado, consulte Visão geral dos certificados SSL.
• Crie um túnel IPSec usando o Cloud VPN ou o Cloud Interconnect para conectar sua rede local com segurança à rede de nuvem privada virtual. Para mais informações, consulte Como escolher um produto de conectividade de rede.
• Use o MACsec para o Cloud Interconnect para proteger o tráfego entre o roteador local e os roteadores de borda do Google. Para mais informações, consulte Informações gerais do MACsec para o Cloud Interconnect.

Se você estiver conectando os dispositivos de usuários a aplicativos em execução no Google Cloud, considere o seguinte:

• Para usar o suporte do TLS do GFE, configure o certificado SSL que você usa. Por exemplo, é possível encerrar a sessão TLS em seu aplicativo.
• Considere nossos certificados SSL gratuitos e automatizados, disponíveis para os domínios personalizados do Firebase Hosting e App Engine. Com os domínios personalizados do App Engine, é possível também fornecer os próprios certificados SSL e usar um cabeçalho HTTP Strict Transport Security (HSTS).
• Para cargas de trabalho no GKE e no Compute Engine, considere a malha de serviço do GKE Enterprise para poder usar mTLS na autenticação, o que garante que todas as comunicações TCP sejam criptografadas em trânsito.

Se você estiver usando o Google Workspace, configure o Gmail para ativar o S/MIME para e-mails enviados, configure políticas para conformidade de anexo e conteúdo e crie regras de roteamento para e-mails de entrada e saída.

Pesquisa e inovação na criptografia em trânsito

Ao longo dos anos, estamos envolvidos em vários projetos de código aberto e outros esforços que incentivam o uso de criptografia em trânsito na Internet.

Esses esforços incluem o seguinte:

• Lançamos a Transparência dos certificados (CT) em um esforço para fornecer aos operadores de sites e detentores de domínio uma maneira de detectar se uma AC emitiu certificados não autorizados ou incorretos.
• Nosso Relatório de Transparência HTTPS monitora nosso progresso em direção ao nosso objetivo de 100% de criptografia em trânsito em todas as nossas propriedades, incluindo o Google Cloud.
• O desenvolvimento do algoritmo de curva elíptica e pós-quântico combinado (CECPQ2), que ajuda a proteger as conexões TLS contra ataques de computadores quânticos.

Para mais informações sobre nossas contribuições recentes, consulte Colaboração com a comunidade de pesquisa de segurança.

A seguir

• Para informações gerais sobre segurança do Google Cloud, incluindo práticas recomendadas de segurança, consulte a seção "Segurança" do site do Google Cloud.
• Para informações sobre conformidade e os respectivos certificados do Google Cloud, consulte a seção Compliance no site do Google Cloud, que inclui o relatório de auditoria pública de SOC3 do Google.
• Para ver práticas recomendadas sobre como proteger seus dados em trânsito, consulte o Blueprint de bases empresariais e o Framework da arquitetura do Google Cloud: segurança, privacidade e conformidade e Decida como atender aos requisitos regulamentares para criptografia em trânsito.

Notas de rodapé