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. 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.

Veja um resumo na tabela a seguir.

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 rede de proxy externo 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 aplicativo interno 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 interno regional 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 GFE se conecta a back-ends que estão no Google Cloud, o GFE aceita qualquer certificado apresentado pelos seus back-ends. Os GFEs não realizam 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 que são compatíveis com FIPS .