Criptografia em trânsito no Google Cloud

Este é o terceiro artigo sobre como o Google usa criptografia para proteger dados de usuários. Também publicamos os artigos Criptografia em repouso no Google Cloud Platform e Criptografia no G Suite. Se quiser saber mais sobre o uso da criptografia no Google, leia também esses outros documentos. Neste artigo, discutimos em detalhes a criptografia em trânsito do Google Cloud, o que inclui o Google Cloud Platform e o G Suite.

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.

O conteúdo aqui apresentado foi editado em dezembro de 2017. Este artigo representa o cenário corrente do momento em que foi escrito. Conforme nosso processo de melhoria contínua da proteção de nossos clientes, as políticas e os sistemas de segurança do Google Cloud podem ser alterados no futuro.

Botão de reprodução

Criptografia de dados em trânsito no Google Cloud

Resumo para diretores de TI

  • O Google emprega várias medidas de segurança para garantir a autenticidade, a integridade e a privacidade dos dados em trânsito.
  • O Google criptografa e autentica todos os dados em trânsito em uma ou mais camadas de rede quando são transferidos para outros limites físicos não controlados pelo Google ou em nome dele. Os dados em trânsito dentro de um limite físico controlado pelo Google ou em nome dele geralmente são autenticados, mas não necessariamente criptografados.
  • 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 o 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 segurança de dados na Internet como 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 no Key Transparency e 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 seus dados, estejam eles viajando pela Internet, passando 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 documento, descrevemos nossa abordagem para criptografia em trânsito no Google Cloud.

Para ver 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 design 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 primitivos criptográficos.

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 ininteligí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 das partes 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 saber mais 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 exportados ou afetados em caso de comprometimento do sistema. Frequentemente, usa-se o padrão de criptografia avançada (AES, na sigla em inglês) 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 por meio da criptografia dos dados antes da transmissão, da autenticação dos endpoints e, por fim, da descriptografia e verificação dos dados na chegada. 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 quando eles estão sendo usados por servidores para executar cálculos. Por exemplo, criptografia homomórfica.

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 a adequada autenticação, integridade e criptografia, é possível proteger os dados transmitidos entre usuários, dispositivos ou processos em um ambiente perigoso. O restante deste documento explica a abordagem do Google quanto à criptografia de dados em trânsito e onde a aplicamos.

Infraestrutura de rede do Google

Limites físicos da rede do Google

O Google aplica proteções diferentes aos dados em trânsito quando eles são transmitidos externamente a um limite físico controlado por ou em nome do Google. 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 porcentagem de funcionários do Google tem acesso ao hardware. Os dados em trânsito dentro desses limites físicos geralmente são autenticados, mas nem sempre criptografados por padrão. Você pode escolher quais medidas de segurança adicionais devem ser aplicadas, com base em seu modelo de ameaças.

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. Dentre essas proteções está a criptografia de dados em trânsito.

Como o tráfego é encaminhado

Na seção anterior, falamos sobre o limite físico da rede do Google e como aplicamos proteções diferentes aos dados enviados para fora desse limite. 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, descrevemos 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 Google Cloud Storage e o Gmail são serviços do Google Cloud. Um aplicativo de 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ços1 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 aplicativo de 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, fornece contramedidas para prevenir ataques de DDoS, além de encaminhar o tráfego para os serviços do Google Cloud, fazendo o balanceamento da carga. 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 de 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 de cliente hospedado no Google Cloud

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

  • Por meio de um balanceador de carga externo do proxy HTTP(S) ou TCP/SSL do Google Cloud: é possível configurar um aplicativo de cliente hospedado em VMs no Google Compute Engine para usar um serviço do Google Cloud Load Balancer (GCLB) no encerramento de conexões HTTP(S), TLS ou TCP, bem como para intermediar, encaminhar e distribuir o tráfego para as VMs delas. Esses serviços de balanceamento de carga são implementados pelos GFEs, da mesma maneira que os GFEs encerram e encaminham o tráfego para serviços do Google Cloud. Quando o GCLB encaminha o tráfego entre GFEs, as conexões são autenticadas e criptografadas assim que o tráfego sai do limite físico controlado pelo Google ou em nome dele. O mesmo ocorre quando o GCLB encaminha o tráfego entre um GFE e uma máquina física que hospeda a VM de um cliente. No caso dos balanceadores de carga HTTPS, as conexões entre usuários finais e o GFE são criptografadas e autenticadas com TLS ou QUIC, usando certificados fornecidos pelos clientes para o balanceador de carga. Já no caso dos balanceadores de carga HTTP, as conexões entre usuários finais e o GFE não são criptografadas nem autenticadas. Com os balanceadores de carga SSL, as conexões entre usuários finais e o GFE são criptografadas com TLS e também requerem o uso de certificados fornecidos pelo cliente. No caso de balanceadores de carga TCP, não há criptografia entre o usuário final e o GFE. No entanto, é possível que o aplicativo do cliente use um método de criptografia próprio nas comunicações entre o usuário final e as VMs.
  • Por meio de uma conexão direta com uma VM usando IP externo ou de balanceador de carga: se você estiver se conectando via IP externo da VM ou IP com balanceamento de carga de rede, a conexão não passará pelo GFE. Por padrão, ela não será criptografada e a segurança ficará a critério do usuário.
  • Por meio da Cloud VPN: se você estiver se conectando a partir de um host em suas instalações a uma VM do Google Cloud via VPN, a conexão sairá do host local, passará pela VPN local, pela Google VPN e chegará, por fim, à VM do Google Cloud e vice-versa. Essa conexão não passará pelo GFE. A conexão entre a VPN local e a VPN do Google é protegida por meio de IPsec. A conexão entre a VPN do Google e a VM do Google Cloud é autenticada e criptografada assim que as comunicações saem do limite físico controlado pelo Google ou em nome dele.
  • Por meio da Interconexão dedicada do Cloud: se você estiver se conectando pela Interconexão dedicada, essa conexão sairá de e chegará a seu host local diretamente, sem passar pelo GFE. Por padrão, ela não é criptografada e a segurança fica a critério do usuário. Use o protocolo criptográfico camada 7 da Transport Layer Security (TLS) para criptografar o tráfego de aplicativos pela Interconexão dedicada.

De máquina virtual para máquina virtual

No roteamento entre VMs que ocorre no nosso backbone de rede usando endereços IP privados RFC 1918, às vezes é necessário encaminhar o tráfego fora dos limites físicos controlados por ou em nome do Google. Como exemplos de roteamento entre VMs, podemos citar:

  • Envio de solicitações entre VMs do Compute Engine
  • Uma conexão entre a VM de um cliente e uma VM gerenciada pelo Google, como o Cloud SQL

As conexões entre VMs são autenticadas dentro do limite físico e criptografadas quando saem dele. Por padrão, o tráfego entre VMs que usam endereços IP públicos não é criptografado e a segurança fica a critério do usuário. A Figura 1 mostra essa interação (identificada como conexão C).

Da máquina virtual para o serviço do Google Cloud

As solicitações encaminhadas de uma VM para um serviço do Google Cloud passam por um GFE, exceto nos casos em que o serviço do Google Cloud é executado em uma VM gerenciada pelo Google, conforme discutido acima. O GFE recebe a solicitação e a encaminha da mesma maneira que as solicitações provenientes da Internet: o tráfego de uma VM para um serviço do Google Cloud é encaminhado por caminhos particulares do Google para os mesmos IPs públicos dos GFEs. Com o acesso particular do Google, as VMs sem IPs públicos podem acessar alguns serviços do Google Cloud e aplicativos de clientes hospedados no Google App Engine. Quando uma VM se conecta a um aplicativo de cliente hospedado no Google Compute Engine ou no Google Kubernetes Engine, observe que o tráfego é encaminhado da mesma forma que as solicitações provenientes da Internet por caminhos externos. Na Figura 1, é mostrada essa interação, identificada como conexão D. Para exemplificar esse tipo de encaminhamento de solicitações, citamos a conexão entre uma VM do Compute Engine e o Google Cloud Storage ou uma API de machine learning. Por padrão2, os serviços do Google Cloud são compatíveis com a proteção por TLS para essas conexões. Essa proteção é aplicada no tráfego da VM para o GFE. A conexão é autenticada no tráfego do GFE para o serviço e criptografada caso saia do limite físico.

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 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 na rede do Google

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 opcionais nas camadas 3 e 4 no Google Cloud

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

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

Hoje em dia, muitos sistemas usam o protocolo HTTPS para se comunicar pela Internet. O HTTPS proporciona segurança ao direcionar o protocolo por meio de uma conexão TLS, garantindo 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, na sigla em inglês) autentique o servidor. Com o par de chaves e o certificado, as solicitações do usuário na camada do aplicativo (camada 7) ficam mais protegidas porque esses dois elementos comprovam que o receptor é o proprietário do nome de domínio de destino das solicitações. Nas subseções a seguir, discutimos os componentes do usuário na criptografia do GFE, a saber: 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 de 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, fornecendo autenticação, integridade e criptografia, por meio do protocolo 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 a Transport Layer Security (TLS) ou o QUIC. O GFE negocia um determinado protocolo de criptografia com o cliente, dependendo do que o último aceita. Quando possível, o GFE negocia protocolos de criptografia mais modernos.

A criptografia por TLS escalada do GFE é aplicada não somente à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 e-mails com servidores de correio externos (para saber mais, 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 desse protocolo. Por esse motivo, ativamos por padrão muitos dos recursos de segurança do TLS. Por exemplo, usamos desde 2011 forward secrecy 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 de protocolo TLS, criada com base na OpenSSL, mantida pelo Google e compatível com essa interface. O Google criou a BoringSSL a partir da 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 para 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.34 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 SHA18
TLS 1.05     AES-256-CBC MD59
QUIC6     ChaCha20-Poly1305  
      3DES7  

Tabela 1: criptografia implementada no Google Front End para os serviços do Google Cloud na BoringSSL Cryptographic Library

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, na sigla em inglês) emissora de confiança do usuário que solicitou a conexão10. 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 alternância 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 migrarmos 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 dos dados de nome do emissor, chave pública e 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 particulares 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 servidor 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íquete11 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 uma vez por dia, pelos menos. As chaves perdem a validade em todas as propriedades a cada três dias. Para saber mais sobre a alternância 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 sessão Autenticação, integridade e criptografia de serviço a serviço. Essas RPCs são autenticadas e criptografadas.

Nas comunicações com os serviços do Google Cloud, as RPCs são protegidas com o ALTS por padrão. No caso de aplicativos de 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 infraestrutura da rede virtual do Google Cloud criptografa o tráfego assim que ele sai dos nossos limites físicos. A criptografia é realizada na camada da rede e aplicada ao tráfego de IPs privados dentro de uma mesma nuvem privada virtual (VPC, na sigla em inglês) ou em redes VPC com peering.

Presumimos que qualquer rede que entre em um limite físico não controlado por ou em nome do Google possa ser comprometida por invasores ativos que poderão rastrear, injetar ou alterar o tráfego em trânsito. Garantimos a integridade e a privacidade das comunicações por meio da criptografia quando os dados são transmitidos fora dos limites físicos que não controlamos.

Usamos o Padrão de criptografia avançada (AES, na sigla em inglês) 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 da rede (camada 3), a rede virtual do Google Cloud autentica todo o tráfego entre VMs. Essa autenticação, realizada com o uso de tokens de segurança, protege um host comprometido de pacotes de spoofing na rede.

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 controle12 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 chaves de token, as chaves secretas de 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.

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

Dentro da infraestrutura do Google, na camada do aplicativo (camada 7), usamos nosso Application Layer Transport Security (ALTS) para fazer a autenticação, manter a integridade e realizar a criptografia de chamadas RPC do Google que partem do GFE ou 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, um 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.

É possível configurar os serviços para que aceitem e enviem comunicações por ALTS somente no modo "autenticação, integridade e privacidade", mesmo quando o tráfego ocorrer dentro dos limites físicos controlados por ou em nome do Google. Um exemplo é o serviço de gerenciamento de chaves interno do Google, que armazena e gerencia as chaves de criptografia usadas para proteger os dados armazenados em repouso na infraestrutura do Google.

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, os dados do cliente para o servidor. No ALTS, a criptografia é implementada com o uso da BoringSSL e outras bibliotecas de criptografia. Geralmente o modo de criptografia adotado é AES-128-GCM e a integridade é garantida pelo GMAC da AES-GCM.

A Figura 5 mostra o handshake do ALTS em detalhes a seguir. Nas implementações mais recentes, um auxiliar de processos realiza o handshake. No entanto, esse processo ainda é realizado diretamente pelos aplicativos em alguns casos.

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áquina: 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ário: fornecem uma identidade de usuário final para um código de desenvolvimento do engenheiro do Google. Esses certificados são alternados 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 de certificado raiz é armazenada com a autoridade de certificação (CA, na sigla em inglês) 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-GCM13. 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. Por 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)14;
  • 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.

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 chegar aos serviços do Google. No entanto, é possível configurar o recurso Acesso particular do Google para usar endereços IP exclusivos do Google nas solicitações.

Assim como acontece com as solicitações de um usuário externo para o Google, por padrão, oferecemos compatibilidade com o tráfego por TLS entre uma VM e o GFE. A conexão acontece da mesma maneira que qualquer outra conexão externa. Para saber mais sobre o TLS, consulte Transport Layer Security (TLS).

Opções de criptografia em trânsito configuráveis pelo usuário

Na seção Criptografia em trânsito por padrão, descrevemos as proteções padrão que o Google aplica aos dados em trânsito. Nesta seção, descrevemos as opções de configuração que nossos usuários podem definir para essas proteções padrão.

Do data center local para o Google Cloud

TLS usando balanceadores de carga externos do GCLB

Se o seu serviço de nuvem usa um balanceador de carga externo de proxy HTTPS ou SSL do Google, o GFE encerra as conexões TLS dos usuários usando certificados SSL fornecidos e controlados por você. Para saber mais sobre como personalizar certificados, consulte a nossa documentação sobre certificados SSL.

Túnel IPsec usando a Google Cloud VPN

Como cliente do Google Cloud, você pode usar a Google Cloud VPN para conectar sua rede local com segurança à nuvem privada virtual (VPC) do Google Cloud Platform, por meio de conexão de VPN com IPsec (camada 3). O tráfego transmitido entre as duas redes é criptografado e descriptografado por gateways de VPN diferentes. Esse procedimento protege os dados no trânsito pela Internet. Além disso, você pode configurar múltiplos túneis com balanceamento de carga por meio de vários gateways de VPN. A Google Cloud VPN protege os dados das seguintes maneiras:

  • Os pacotes enviados das VMs do cliente para a Cloud VPN permanecem dentro da rede do Google. Esses pacotes serão criptografados pela rede virtual do Google Cloud se trafegarem fora dos limites físicos controlados pelo Google ou em nome dele.
  • Os pacotes enviados da Cloud VPN para a VPN local do cliente são criptografados e autenticados com um túnel IPsec.
  • Os pacotes enviados da VPN local para os hosts locais do cliente são protegidos pelo controle que o cliente aplicar à própria rede.

Para configurar uma VPN, crie um gateway da Cloud VPN e um túnel na rede da VPC do serviço hospedado. Em seguida, autorize o tráfego entre as redes. Também há a opção de configurar uma VPN entre duas VPCs.

É possível personalizar ainda mais a rede, especificando a versão do Internet Key Exchange15 (IKE) para o túnel da VPN. Você pode optar por uma das duas versões do IKE disponíveis, IKEv1 e IKEv2, sendo que cada versão é compatível com criptografias diferentes. Ao optar pelo IKEv1, o Google criptografa os pacotes usando AES-128-CBC e fornece integridade com o SHA-1 HMAC16. Já a versão IKEv2 tem uma variedade de criptografias disponíveis e compatíveis. Em todos os casos, o Google Cloud VPN negociará o protocolo comum mais seguro compatível com os dispositivos que estão se comunicando. Instruções completas sobre a configuração de uma VPN podem ser encontradas em nossa documentação Como escolher uma opção de roteamento VPN.

Uma alternativa ao túnel IPsec é o Google Cloud Dedicated Interconnect. A Interconexão dedicada fornece conexões físicas diretas e comunicação RFC 1918 entre redes locais e a rede do Google. Os dados que trafegam por essa conexão NÃO são criptografados por padrão. Portanto, é necessário protegê-los na camada do aplicativo, usando o TLS, por exemplo. A Google Cloud VPN e a Interconexão do Google Cloud usam o mesmo ponto de ligação para que você possa utilizar a criptografia de VPN com IPsec com a Interconexão dedicada. No entanto, para que isso seja possível, também é necessário usar uma solução de terceiros. No momento, não oferecemos compatibilidade com MACsec (proteção da camada 2).

Do usuário para o Google Front End

Certificados SSL gerenciados: certificados gratuitos e automatizados

Ao criar um aplicativo no Google Cloud, você pode configurar seu certificado SSL aproveitando que o GFE é compatível com o TLS. Por exemplo, é possível encerrar a sessão TLS em seu aplicativo. Isso é diferente do tipo de encerramento da sessão TLS descrito em TLS usando balanceadores de carga externos do GCLB.

O Google também fornece certificados SSL gratuitos e automatizados nos domínios personalizados do Firebase Hosting e do Google App Engine. Esses certificados estão disponíveis somente para as propriedades hospedadas no Google. Com os domínios personalizados do Google App Engine, você passa a ser capaz de fornecer seus próprios certificados SSL e usar um cabeçalho HTTPS Strict Transport Protocol (HSTS).

Uma vez definido o encaminhamento entre seu domínio e a infraestrutura do Google, solicitamos e recebemos um certificado para esse domínio, a fim de permitir as comunicações seguras. Gerenciamos as chaves privadas do servidor TLS, que são RSA de 2048 bits ou ECC secp256r1, e renovamos certificados em nome dos nossos clientes.

TLS obrigatório no Gmail

Conforme discutido na seção Transport Layer Security (TLS), o Gmail usa esse protocolo por padrão. O Gmail registra e exibe se o último salto de um e-mail foi realizado em uma sessão TLS17. Quando há trocas de e-mails entre usuários do Gmail, esses e-mails são protegidos pelo TLS ou, em alguns casos, enviados diretamente no aplicativo. Nesses casos, as RPCs usadas pelo aplicativo do Gmail são protegidas pelo ALTS, conforme descrevemos na seção Autenticação, integridade e criptografia de serviço a serviço. No caso das mensagens recebidas de outros provedores de e-mail, o Gmail não aplica o TLS. Os administradores do Gmail podem configurá-lo para tornar obrigatório que seja estabelecida uma conexão TLS segura para todos os e-mails recebidos e enviados.

Gmail S/MIME

O Secure/Multipurpose Internet Mail Extensions (S/MIME) é um padrão de segurança para e-mails que fornece autenticação, integridade e criptografia. A implementação do padrão S/MIME determina que os certificados associados aos usuários que enviam e-mails sejam hospedados em uma CA pública.

Como administrador, é possível configurar o Gmail para ativar o S/MIME para e-mails enviados, configurar políticas de conformidade para conteúdo e anexos e criar regras de encaminhamento para e-mails recebidos e enviados. Após finalizar a configuração, faça o upload dos certificados públicos dos usuários para o Gmail usando a API do Gmail. No caso de usuários que não utilizam o Gmail, é necessário trocar uma mensagem inicial assinada por S/MIME para definir o S/MIME como padrão.

Criptografia do tráfego entre serviços e entre VMs

O Istio é uma malha de serviço de código aberto desenvolvida pelo Google, IBM, Lyft e outros para simplificar a detecção e a conectividade de serviços. Com a autenticação do Istio, é fornecida criptografia automática de dados em trânsito entre serviços, bem como o gerenciamento de chaves e certificados associados. O Istio é usado no Google Kubernetes Engine e no Google Compute Engine.

Se você quiser implementar a autenticação mútua e a criptografia de cargas de trabalho, use o Istio Auth. Especificamente em cargas de trabalho do Kubernetes, o Istio Auth permite gerar e distribuir certificados por uma CA em nível de cluster, que serão usados na aplicação do mutual Transport Layer Security (mTLS) pod a pod.

Como o Google ajuda a criptografar dados em trânsito na Internet

Nas seções Criptografia em trânsito por padrão e Opções de criptografia em trânsito configuráveis pelo usuário, você verá explicações sobre proteções padrão e personalizáveis aplicadas pelo Google Cloud aos dados em trânsito do cliente. Além do que já foi discutido, o Google tem vários projetos de código aberto e outros esforços que incentivam o uso da criptografia em trânsito e segurança dos dados na Internet em geral.

Transparência dos certificados

Conforme discutido em Criptografia do tráfego entre o usuário e o Google Front End, para oferecer HTTPS, um site precisa primeiro solicitar um certificado de uma CA da Web (pública) confiável. A CA é responsável por verificar se o solicitante foi autorizado pelo titular do domínio, bem como por garantir que todas as informações contidas no certificado são precisas. Em seguida, esse certificado é apresentado ao navegador para a autenticação do site que o usuário está tentando acessar. Para garantir que o HTTPS seja devidamente autenticado, é importante assegurar que as CAs emitam apenas certificados autorizados pelo titular do domínio.

A Transparência dos certificados (CT, na sigla em inglês) é um esforço iniciado pelo Google em março de 2013 para oferecer aos operadores de sites e titulares de domínios uma maneira de detectar se uma CA emitiu certificados não autorizados ou incorretos. Isso é feito por meio de um mecanismo em que os titulares de domínios, as CAs e o público registram os certificados confiáveis de que tomam conhecimento ou emitem, no caso das CAs. Esses registros são apenas de acréscimo, à prova de adulterações e podem ser verificados publicamente. Os certificados contidos nesses registros podem ser examinados por qualquer pessoa que queira confirmar se as informações estão corretas, precisas e autorizadas.

A primeira versão da Transparência dos certificados foi especificada em uma RFC experimental do IETF, a RFC 6962. Durante o desenvolvimento da Transparência dos certificados, o Google abriu o código de várias ferramentas, inclusive de um servidor de registros de código aberto que pode registrar certificados, bem como ferramentas para a criação de registros da Transparência dos certificados. Além disso, o Google Chrome requer que alguns certificados sejam divulgados publicamente, como os certificados de Validação Estendida (EV, na sigla em inglês) ou aqueles de CAs que já emitiram certificados incorretamente. A partir de 2018, o Chrome exigirá que todos os novos certificados confiáveis públicos sejam divulgados.

Como operador de sites, você pode usar a Transparência dos certificados para detectar se algum certificado não autorizado foi emitido para seu site. Há diversas ferramentas gratuitas que facilitam essa tarefa, como o Relatório de transparência dos certificados do Google, o site Certificate Search ou as ferramentas do Facebook. Mesmo que você não use a Transparência dos certificados, diversos navegadores atualmente examinam essa ferramenta regularmente. Eles fazem isso para confirmar se as CAs em que os usuários confiam para acessar seu site aderem aos requisitos e práticas recomendadas do setor, reduzindo o risco de emissão de certificados fraudulentos.

Aumento do uso de HTTPS

Como descrevemos na seção Criptografia do tráfego entre o usuário e o Google Front End, estamos trabalhamos arduamente para garantir que nossos sites e serviços forneçam, como norma, um HTTPS moderno. Nosso objetivo é chegar a 100% de criptografia em nossos produtos e serviços. Para isso, publicamos um HTTPS Transparency Report anual que rastreia nosso progresso em direção ao nosso objetivo para todas as propriedades, incluindo o Google Cloud. Continuamos trabalhando para superar as barreiras técnicas que dificultam a compatibilidade de criptografia em alguns de nossos produtos, como as soluções para navegadores ou outros clientes que sejam incompatíveis com HTTPS Strict Transport Protocol (HSTS)18. Usamos o HSTS em alguns de nossos sites, incluindo a página inicial google.com, para que os usuários se conectem a um servidor somente por HTTPS.

Sabemos que o restante da Internet também está trabalhando para migrar para o HTTPS e, por isso, tentamos facilitar essa mudança das seguintes maneiras:

Em 2016, começamos a publicar métricas sobre o “uso do HTTPS na Internet” para os 100 sites mais acessados da Internet que não pertencem ao Google. Com essas métricas, buscamos aumentar a conscientização e ajudar a tornar a Internet um lugar mais seguro para todos os usuários. Em outubro de 2017, o Chrome renovou formalmente o apoio financeiro à Let's Encrypt como patrocinador Platinum.

Aumento no uso de SMTP seguro: indicadores do Gmail

A maioria dos e-mails é trocada com o uso de Simple Mail Transfer Protocol (SMTP) que, por padrão, envia e-mails sem realizar criptografia. Para criptografar um e-mail, o provedor precisa implementar controles de segurança, como o TLS.

Como discutimos na seção Criptografia do tráfego entre o usuário e o Google Front End, o Gmail usa o TLS por padrão. Além disso, em TLS obrigatório no Gmail, descrevemos como os administradores do Gmail podem impor o uso da proteção TLS para e-mails recebidos e enviados. Assim como os esforços do Google para aumentar a transparência do HTTPS, o Gmail fornece dados sobre o uso do TLS para o recebimento de e-mails. Esses dados estão apresentados no nosso Safer Email Transparency Report.

O Google, em parceria com a IETF e outros agentes importantes do setor, está liderando o desenvolvimento do SMTP STS, que é como o HSTS para o HTTPS, e torna obrigatório o uso de SMTP exclusivamente em canais criptografados.

APIs do Chrome

Em fevereiro de 2015, o Chrome anunciou que novos recursos avançados estariam disponíveis apenas para proteger as origens19. Esses recursos incluem o gerenciamento de informações privadas e o acesso a sensores no dispositivo do usuário. Começando pela geolocalização no Chrome 50, iniciamos o processo de suspensão de uso desses recursos para origens não seguras.

Inovação contínua na criptografia em trânsito

Experiência do usuário dos recursos de segurança do Chrome

O Google Chrome é líder do setor em aproveitar a própria IU para exibir informações de segurança. Dessa forma, os usuários podem saber rapidamente se estão se conectando aos sites de maneira segura. Com essas informações, os usuários podem tomar decisões embasadas sobre quando e como compartilhar dados. O Chrome conduz uma pesquisa extensa sobre os usuários, cujos resultados são compartilhados em documentos revistos por outros pesquisadores.

Para ajudar a proteger ainda mais os usuários, o Chrome anunciou que, até o final de 2017, marcará todas as conexões HTTP como não seguras. A partir do Chrome 56, por padrão, os usuários verão um aviso caso uma página HTTP inclua um formulário com os campos de senha ou cartão de crédito. No Chrome 62, um aviso será exibido quando o usuário inserir dados em uma página HTTP, bem como em todas as páginas HTTP visitadas no modo de navegação anônima. Futuramente, o Chrome mostrará um aviso para todas as páginas disponibilizadas por HTTP.

Para ver como determinadas configurações são exibidas para os usuários no Chrome, use a ferramenta BadSSL.

Transparência de chaves

Um grande obstáculo para a adoção generalizada da criptografia de mensagens é a dificuldade em trocar de chaves públicas: como é possível encontrar de maneira confiável uma chave pública para um usuário novo com quem estamos nos comunicando? Para ajudar a resolver esse problema, em janeiro de 2017, o Google anunciou a Transparência de chaves. Trata-se de uma estrutura aberta que oferece um meio genérico, seguro e auditável para distribuir chaves públicas. Ela remove a necessidade de os usuários realizarem a verificação de chaves manualmente. A Transparência de chaves é destinada principalmente à distribuição de chaves públicas de usuários nas comunicações, por exemplo, criptografia de e-mail E2E e OpenPGP. O projeto do Key Transparency é uma nova abordagem para recuperação e distribuição de chaves com base nos insights recebidos pela Transparência dos certificados e pelo CONIKS.

O Key Transparency é um desenvolvimento de código aberto, implementado por meio de uma árvore Merkle de grande escala. Com a verificação da Transparência de chaves, é possível ver as chaves associadas a contas e há quanto tempo uma conta está ativa e estável. A meta desse trabalho do Google a longo prazo é permitir que qualquer um execute um servidor da Transparência de chaves, bem como facilitar a integração com inúmeros aplicativos.

Criptografia pós-quântica

O Google quer continuar sendo o líder do setor em criptografia em trânsito. Para tanto, começamos a trabalhar na área de criptografia pós-quântica. Esse tipo de criptografia permite substituir as primitivas criptográficas existentes, que são vulneráveis a ataques quânticos eficientes, por candidatos pós-quânticos, que são considerados mais resistentes. Em julho de 2016, anunciamos um teste sobre a viabilidade da implantação de tal criptografia usando o algoritmo criptográfico pós-quântico New Hope na versão do desenvolvedor do Chrome. Além desse trabalho, os pesquisadores do Google publicaram documentos sobre outros protocolos pós-quânticos práticos para troca de chaves.

Apêndice

Leia mais sobre a Segurança do Google Cloud, incluindo nossa Visão geral de design da segurança de infraestrutura e sobre a conformidade do Google Cloud, incluindo o relatório de auditoria SOC 3 público.

Notas de rodapé

1Entre as soluções de parceiros, encontram-se as oferecidas no Cloud Launcher e os produtos criados em colaboração com parceiros, como o Cloud Dataprep.
2Por exemplo, ainda é possível desativar essa criptografia para o acesso HTTP a intervalos do Google Cloud Storage.
3As comunicações entre VMs e serviços não protegidas na camada 7 permanecem protegidas nas camadas 3 e 4.
4O TLS 1.3 ainda não está finalizado. A versão preliminar foi implementada somente em determinados domínios do Google, como o Gmail, para a realização de testes.
5O TLS 1.0 é compatível com o Google em navegadores que ainda usam essa versão do protocolo. Observe que todos os sites Google que processam informações de cartão de crédito deixarão de ser compatíveis com o TLS 1.0 até julho de 2018, quando o Setor de Cartões de Pagamento (PCI, na sigla em inglês) passará a exigir a suspensão de uso desse recurso.
6Para mais detalhes sobre o QUIC, acesse [https://www.chromium.org/quic](https://www.chromium.org/quic).
7, 8, 9Para que haja compatibilidade com versões anteriores de alguns sistemas operacionais legados, aceitamos 3DES, SHA1 e MD5.
10Nos casos de certificados em cadeia, a CA é temporariamente confiável.
11Ela pode ser um tíquete de sessão ([RFC 5077](https://tools.ietf.org/html/rfc5077)) ou um código de sessão ([RFC 5246](https://tools.ietf.org/html/rfc5246)).
12O plano de controle faz parte da rede que transporta o tráfego de sinalização e é responsável pelo encaminhamento.
13Anteriormente eram usados outros protocolos, hoje obsoletos.Menos de 1% dos jobs usam esses protocolos mais antigos.
14O Datagram TLS (DTLS) oferece segurança aos aplicativos baseados em datagramas, o que evita espionagens e adulterações durante a comunicação.
15Internet Key Exchange (IKE) é o protocolo usado para configurar uma associação de segurança no conjunto de protocolos IPsec.
16HMAC-SHA-1 não é quebrado por uma [colisão SHA-1] (https://shattered.io/), como a colisão SHAttered que os pesquisadores do Google descobriram.
17No G Suite Enterprise, isso não é mostrado na interface do usuário. Os administradores de domínio podem examinar os dados dos próprios domínios usando [Email Log Search] (https://support.google.com/a/answer/2604578).
18O HTTPS Strict Transport Protocol é um mecanismo que permite que sites declarem-se acessíveis apenas por meio de conexões seguras e/ou para usuários que direcionam os próprios agentes para interagirem com determinados sites apenas em conexões seguras.
19Origens seguras são conexões que correspondem a determinados esquemas, hosts ou [padrões de] portas (https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features).
Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…