Criptografia do balanceador de carga nos back-ends

Criptografia em todas as regiões do Google Cloud

Todo o tráfego de VM para VM em uma rede VPC e em redes VPC com peering é criptografado. Isso inclui o tráfego entre VMs em limites físicos (ou seja, o tráfego intracluster).

Criptografia entre balanceadores de carga baseados em proxy e back-ends

Para alguns balanceadores de carga de proxy (consulte a tabela 1), o Google criptografa automaticamente o tráfego para os back-ends que residem nas redes VPC do Google Cloud. Isso é chamado de criptografia automática no nível da rede. A criptografia automática no nível da rede só é aplicável a comunicações com estes tipos de back-ends:

  • Grupos de instâncias
  • NEGs zonais (endpoints GCE_VM_IP_PORT)

Além disso, o Google Cloud oferece opções de protocolo seguras para criptografar a comunicação com o serviço de back-end.

Alguns balanceadores de carga do Google Cloud usam o Google Front Ends (GFEs) como o cliente para os back-ends, enquanto outros usam o proxy Envoy de código aberto. Em todos os casos, o balanceador de carga oferece suporte aos conjuntos de criptografia listados na RFC 8446, seção 9.1 para o TLS 1.3. Para o TLS 1.2 e anteriores, o balanceador de carga oferece suporte aos conjuntos de criptografia associados ao perfil de política SSL COMPATÍVEL.

A tabela a seguir mostra um resumo dos balanceadores de carga de proxy que criptografam o tráfego para os back-ends.

Tabela 1. Comunicações entre balanceadores de carga e back-ends
Balanceador de carga de proxy Proxy (cliente para o back-end) Criptografia automática no nível da rede Opções de protocolo do serviço de back-end
Balanceador de carga de aplicativo externo global GFE (com software Envoy para recursos avançados de roteamento) HTTP, HTTPS e HTTP/2
Escolha HTTPS ou HTTP/2 se precisar de criptografia auditável em trânsito para os back-ends.
Balanceador de carga de aplicativo clássico GFE HTTP, HTTPS e HTTP/2
Escolha HTTPS ou HTTP/2 se precisar de criptografia auditável em trânsito para os back-ends.
Balanceador de carga de aplicativo externo regional Proxy Envoy HTTP, HTTPS e HTTP/2
Escolha HTTPS ou HTTP/2 se precisar de criptografia auditável em trânsito para os back-ends.
Balanceador de carga de aplicativo interno regional Proxy Envoy HTTP, HTTPS e HTTP/2
Escolha HTTPS ou HTTP/2 se precisar de criptografia auditável em trânsito para os back-ends.
Balanceador de carga de aplicativo interno entre regiões Proxy Envoy HTTP, HTTPS e HTTP/2
Escolha HTTPS ou HTTP/2 se precisar de criptografia auditável em trânsito para os back-ends.
Balanceador de carga de rede de proxy externo global GFE (com software Envoy para recursos avançados de roteamento) SSL ou TCP
Escolha SSL para o protocolo de serviço de back-end se você precisar de criptografia auditável em trânsito para os back-ends.
Balanceador de carga de rede de proxy clássico GFE SSL ou TCP
Escolha SSL para o protocolo de serviço de back-end se você precisar de criptografia auditável em trânsito para os back-ends.
Balanceador de carga de rede de proxy externo regional Proxy Envoy TCP
Balanceador de carga de rede de proxy interno regional Proxy Envoy TCP
Balanceador de carga de rede de proxy interno entre regiões Proxy Envoy TCP
Cloud Service Mesh Proxy do lado do cliente HTTPS e HTTP/2

Casos de uso do protocolo de back-end seguro

Um protocolo seguro para se conectar a instâncias de back-end é recomendado nos seguintes casos:

  • Quando você precisa de uma conexão auditável e criptografada do balanceador de carga (ou Cloud Service Mesh) às instâncias de back-end.

  • Quando o balanceador de carga se conecta a uma instância de back-end fora do Google Cloud (com um NEG da Internet). A comunicação com um back-end do NEG da Internet pode transitar pela Internet pública. Quando o balanceador de carga se conecta a um NEG da Internet, o certificado público assinado pela CA precisa atender aos requisitos de validação.

Considerações sobre o protocolo de back-end seguro

Ao usar um protocolo de serviço de back-end seguro, lembre-se do seguinte:

  • As instâncias de back-end ou os endpoints do balanceador de carga precisam veicular usando o mesmo protocolo do serviço de back-end. Por exemplo, se o protocolo de serviço de back-end for HTTPS, os back-ends precisarão ser servidores HTTPS.

  • Se o protocolo do serviço de back-end for HTTP/2, seus back-ends precisarão usar o TLS. Para instruções de configuração, consulte a documentação do software em execução nos endpoints ou instâncias de back-end.

  • É preciso instalar certificados e chaves privadas nos endpoints ou instâncias de back-end para que funcionem como servidores HTTPS ou SSL. Esses certificados não precisam corresponder aos certificados SSL de front-end do balanceador de carga. Para instruções de instalação, consulte a documentação do software em execução nos endpoints ou instâncias de back-end.

  • Com exceção dos balanceadores de carga HTTPS com back-ends de NEG da Internet, os GFEs não usam a extensão de indicação de nome do servidor (SNI, na sigla em inglês) para conexões com o back-end.

  • quando um balanceador de carga se conecta a back-ends que estão no Google Cloud, ele aceita qualquer certificado presente nos back-ends; Nesse caso, o balanceador de carga não realiza nenhuma validação de certificado. Por exemplo, o certificado é tratado como válido mesmo nas seguintes circunstâncias:

    • O certificado é autoassinado
    • O certificado é assinado por uma autoridade de certificação (CA, na sigla em inglês) desconhecida
    • O certificado expirou ou ainda não é válido
    • Os atributos CN e subjectAlternativeName não correspondem a um cabeçalho Host ou registro PTR DNS.

Protocolos de front-end seguros

Quando você usa um HTTPS de destino ou um proxy SSL de destino como parte da configuração, o Google Cloud usa um protocolo de front-end seguro.

Os balanceadores de carga de aplicativos externos e de rede de proxy externo usam a biblioteca BoringCrypto do Google. Para ver detalhes sobre FIPS 140-2, consulte o Certificado do programa de validação do módulo de criptografia NIST 3678.

Os balanceadores de carga de aplicativo internos usam a biblioteca BoringSSL do Google. Para ver detalhes sobre o FIPS 140-2, consulte a documentação do Envoy. O Google cria proxies do Envoy para balanceadores de carga de aplicativo internos no modo compatível com FIPS.

O Cloud Service Mesh oferece suporte a proxies Envoy criados no modo compatível com o FIPS.