Criptografia do balanceador de carga nos back-ends

Criptografia automática entre GFEs e back-ends

Para os seguintes tipos de balanceador de carga, o Google criptografa automaticamente o tráfego entre o Google Front Ends (GFEs) e seus back-ends que residem nas redes VPC do Google Cloud:

  • Balanceamento de carga de HTTP(S)
  • Balanceamento de carga de proxy TCP
  • Balanceamento de carga de proxy SSL

Opções do protocolo de back-end seguro

Ao criar um serviço de back-end, você seleciona um protocolo de serviço de back-end. Os seguintes protocolos de serviço de back-end fornecem conectividade segura para back-ends:

  • Para balanceamento de carga HTTP(S): HTTPS e HTTP/2
  • Para balanceamento de carga HTTP(S) interno: HTTPS e HTTP/2
  • Para balanceamento de carga do proxy SSL: SSL
  • Para o Traffic Director: HTTPS e HTTP/2

Quando o balanceamento de carga HTTP(S) ou o balanceamento de carga do proxy SSL se conecta a um back-end usando um protocolo seguro, o GFE é o cliente HTTPS ou SSL. Quando o balanceamento de carga HTTP(S) interno se conecta a um back-end usando um protocolo seguro, o proxy Envoy é o cliente HTTPS.

Quando um proxy do lado do cliente configurado usando o Traffic Director se conecta a um back-end usando um protocolo de serviço de back-end seguro, o proxy do cliente é o cliente SSL ou HTTPS.

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.