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 tipos de balanceador de carga, 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.

Além disso, o Google Cloud oferece protocolos seguros de serviço de back-end para criptografia.

Alguns tipos de balanceador de carga do Google Cloud usam Google Front Ends (GFEs) como cliente para os back-ends. Outros usam o proxy Envoy.

Veja um resumo na tabela a seguir.

Tipo de produto com base em proxy Cliente para o back-end Criptografia automática no nível da rede Opções de protocolo seguro do serviço de back-end
Balanceador de carga HTTP(S) externo global GFE (com software Envoy para recursos avançados de roteamento) HTTPS e HTTP/2
Balanceador de carga HTTP(S) externo global (clássico) GFE HTTPS e HTTP/2
Balanceador de carga HTTP(S) externo regional Proxy Envoy HTTPS e HTTP/2
balanceador de carga do proxy TCP. GFE N/A. Se você quiser usar um protocolo seguro, use o balanceador de carga de proxy SSL.
balanceador de carga do proxy SSL; GFE SSL
Balanceador de carga HTTP(S) interno Proxy Envoy HTTPS e HTTP/2
Traffic Director 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 criptografada e auditável do balanceador de carga (ou do Traffic Director) para as 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.

  • Quando um GFE inicia uma sessão TLS para back-ends, o GFE não usa a extensão de indicação de nome do servidor (SNI).

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

O balanceamento de carga HTTP(S) e o balanceamento de carga do proxy SSL usam a biblioteca BoringCrypto do Google. Para ver detalhes sobre o FIPS 140-2, consulte o Certificado do programa de validação do módulo de criptografia NIST #3678.

O balanceamento de carga HTTP(S) interno usa a biblioteca BoringSSL do Google. Para ver detalhes sobre o FIPS 140-2, consulte a documentação do Envoy (em inglês). O Google cria proxies Envoy para balanceamento de carga HTTP(S) interno no modo compatível com FIPS.

O Traffic Director é compatível com proxies Envoy criados no modo compatível com o FIPS.