Algumas ou todas as informações nesta página podem não se aplicar à Trusted Cloud by S3NS. Consulte o artigo Diferenças em relação ao Google Cloud para mais detalhes.

Esta página foi traduzida pela API Cloud Translation.

Encriptação do balanceador de carga para os back-ends

Encriptação em todas as Trusted Cloud regiões

Todo o tráfego de VM para VM numa rede de VPC e em redes de VPC com peering é encriptado.

Encriptação entre balanceadores de carga de proxy e back-ends

Para alguns equilibradores de carga de proxy (consulte a tabela 1), a Google encripta automaticamente o tráfego para os back-ends que residem em redes Trusted Cloud VPC Trusted Cloud . A isto chama-se encriptação automática ao nível da rede. A encriptação automática ao nível da rede só é aplicável a comunicações com os seguintes tipos de backends:

Grupos de instâncias
NEGs zonais (GCE_VM_IP_PORT pontos finais)

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

Os equilibradores de carga regionais usam o proxy Envoy de código aberto como cliente para os back-ends. Os balanceadores de carga suportam os conjuntos de cifras indicados na RFC 8446, secção 9.1 para o TLS 1.3. Para o TLS 1.2 e anterior, o equilibrador de carga suporta os conjuntos de cifras associados ao perfil da política SSL COMPATÍVEL.

A tabela seguinte apresenta um resumo dos balanceadores de carga de proxy que encriptam o tráfego para os back-ends.

**Tabela 1.** Comunicações entre balanceadores de carga e back-ends
Balanceador de carga de proxy	Proxy (do cliente para o back-end)	Opções de protocolo do serviço de back-end
Balanceador de carga de aplicações externo regional	Proxy Envoy	HTTP, HTTPS e HTTP/2 Escolha HTTPS ou HTTP/2 se precisar de encriptação auditável em trânsito para os back-ends.
Balanceador de carga de aplicações interno regional	Proxy Envoy	HTTP, HTTPS e HTTP/2 Escolha HTTPS ou HTTP/2 se precisar de encriptação 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

Exemplos de utilização do protocolo de back-end seguro

Recomendamos um protocolo seguro para estabelecer ligação a instâncias de back-end nos seguintes casos:

Quando precisa de uma ligação encriptada e auditável do balanceador de carga (ou da malha de serviços na nuvem) às instâncias de back-end.
Quando o balanceador de carga se liga a uma instância de back-end que está fora deTrusted Cloud (com um NEG de internet). A comunicação com um back-end NEG da Internet pode transitar pela Internet pública. Quando o equilibrador de carga se liga a um NEG da Internet, o certificado assinado pela AC pública tem de cumprir os requisitos de validação.

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

Quando usar um protocolo de serviço de back-end seguro, tenha em atenção o seguinte:

As instâncias ou os pontos finais de back-end do equilibrador de carga têm de ser servidos com o mesmo protocolo que o serviço de back-end. Por exemplo, se o protocolo do serviço de back-end for HTTPS, os back-ends têm de ser servidores HTTPS.
Se o protocolo de serviço de back-end for HTTP/2, os seus back-ends têm de usar TLS. Para ver instruções de configuração, consulte a documentação do software em execução nas instâncias ou nos pontos finais do back-end.
Tem de instalar chaves privadas e certificados nas suas instâncias ou pontos finais de back-end para que funcionem como servidores HTTPS ou SSL. Estes certificados não têm de corresponder aos certificados SSL de front-end do equilibrador de carga. Para ver instruções de instalação, consulte a documentação do software em execução nas instâncias ou nos pontos finais do back-end.
Com exceção dos balanceadores de carga HTTPS com backends de NEG da Internet, os balanceadores de carga não usam a extensão Server Name Indication (SNI) para ligações ao backend.
Quando um balanceador de carga se liga a back-ends que estão dentro Trusted Cloud, o balanceador de carga aceita qualquer certificado que os seus back-ends apresentem. Neste caso, o balanceador de carga realiza apenas a validação mínima de certificados.

Por exemplo, os certificados são tratados como válidos mesmo nas seguintes circunstâncias:
- O certificado é autoassinado.
- O certificado é assinado por uma autoridade de certificação (CA) desconhecida.
- O certificado expirou ou ainda não é válido.
- Os atributos CN e subjectAlternativeName não correspondem a um cabeçalho Host nem a um registo PTR de DNS.
Para certificados RSA, a partir de 28 de abril de 2025, o equilibrador de carga só vai aceitar certificados RSA que tenham a extensão de utilização da chave X509v3 presente e incluam os parâmetros de assinatura digital e cifragem de chaves. Para mais informações, consulte a nota de lançamento associada de 24 de janeiro de 2025.

Protocolos de front-end seguros

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

Os balanceadores de carga de aplicações externos e os balanceadores de carga de rede de proxy externos usam a biblioteca BoringCrypto da Google. Para ver detalhes da FIPS 140-2, consulte o certificado n.º 3678 do programa de validação de módulos criptográficos do NIST.

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