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�