O SSL/TLS é o protocolo criptográfico mais usado na Internet. Tecnicamente, o TLS é o sucessor do SSL, embora os termos sejam, por vezes, usados alternadamente, como neste documento.
O Transport Layer Security (TLS) é usado para encriptar informações enquanto são enviadas através de uma rede, o que garante a privacidade entre um cliente e um servidor ou um equilibrador de carga. Um balanceador de carga de aplicações ou um balanceador de carga de rede proxy que usa SSL requer, pelo menos, uma chave privada e um certificado SSL.
Métodos de configuração de certificados
Google Cloud oferece três métodos de configuração de certificados para balanceadores de carga de aplicações que usam proxies HTTPS de destino e balanceadores de carga de rede de proxy que usam proxies SSL de destino.
O proxy de destino faz referência a certificados SSL do Compute Engine: com este método, o proxy de destino do balanceador de carga pode fazer referência a até 15 recursos de certificados SSL do Compute Engine. Cada recurso de certificado SSL do Compute Engine contém a chave privada, o certificado correspondente e, opcionalmente, os certificados da AC.
O proxy de destino faz referência a um mapa de certificados do Gestor de certificados: com este método, o proxy de destino do equilibrador de carga faz referência a um único mapa de certificados. Por predefinição, o mapa de certificados suporta milhares de entradas e pode ser dimensionado para milhões de entradas. Cada entrada contém dados de chave privada e certificado.
Referenciar diretamente os certificados do Gestor de certificados no proxy de destino: com este método, o proxy de destino do equilibrador de carga pode referenciar até 100 certificados do Gestor de certificados.
Apoio técnico do balanceador de carga
A tabela seguinte mostra os métodos de configuração de certificados suportados por cada equilibrador de carga.
| Balanceador de carga | Método de configuração do certificado: referências... do proxy de destino | |||
|---|---|---|---|---|
| Certificados SSL do Compute Engine | Um mapa de certificados do Gestor de certificados | Certificados do Gestor de certificados diretamente | ||
| Balanceadores de carga de aplicações (proxies HTTPS de destino) | ||||
| Balanceador de carga de aplicações externo global | Suporta
certificados
globais Geridos por si Geridos pela Google |
Gerido por si Gerido pela Google |
||
| Balanceador de carga de aplicações clássico | Suporta
certificados
globais Geridos por si Geridos pela Google |
Gerido por si Gerido pela Google |
||
| Balanceador de carga de aplicações externo regional | Suporta
certificados
regionais Geridos por si Geridos pela Google |
Gerido por si Gerido pela Google |
||
| Balanceador de carga de aplicações interno regional | Suporta
certificados
regionais Geridos por si Geridos pela Google |
Gerido por si Gerido pela Google |
||
| Balanceador de carga de aplicações interno entre regiões |
Gerido por si Gerido pela Google |
|||
| Balanceadores de carga de rede de proxy (proxies SSL de destino) | ||||
| Balanceador de carga de rede de proxy externo global | Suporta
certificados
globais Geridos por si Geridos pela Google |
Gerido por si Gerido pela Google |
||
| Balanceador de carga de rede de proxy clássico | Suporta
certificados
globais Geridos por si Geridos pela Google |
Gerido por si Gerido pela Google |
||
Regras do método de configuração
Google Cloud aplica as seguintes regras do método de configuração de certificados:
Para equilibradores de carga que suportam certificados SSL do Compute Engine e mapas de certificados do Certificate Manager: o proxy de destino do equilibrador de carga pode referenciar simultaneamente um mapa de certificados e um ou mais certificados SSL do Compute Engine. No entanto, nesse caso, todos os certificados SSL do Compute Engine são ignorados, e apenas os certificados do mapa de certificados são usados pelo equilibrador de carga.
Para equilibradores de carga que suportam certificados SSL do Compute Engine e certificados do Gestor de certificados associados diretamente: o proxy de destino do equilibrador de carga só pode ser configurado para referenciar até 15 certificados SSL do Compute Engine ou até 100 certificados do Gestor de certificados, não uma combinação de ambos.
Tipos de certificados
Google Cloud Suporta certificados autogeridos e geridos pela Google.
Certificados SSL autogeridos
Os certificados SSL autogeridos são certificados que obtém, aprovisiona e renova por si. Os certificados autogeridos podem ser qualquer um destes tipos de certificados de chave pública:
- Validação de domínio (DV)
- Validação da organização (OV)
- Certificados de validação alargada (EV)
Pode criar certificados SSL autogeridos através de:
Recursos de certificados SSL do Compute Engine: para mais informações, consulte o artigo Use certificados SSL autogeridos.
Gestor de certificados: para mais informações, consulte a vista geral da implementação na documentação do Gestor de certificados.
Certificados SSL geridos pela Google
Os certificados SSL geridos pela Google são certificados que a Google Google Cloud obtém, gere e renova automaticamente. Os certificados geridos pela Google são sempre certificados de validação de domínio (DV). Não demonstram a identidade de uma organização ou de um indivíduo associado ao certificado.
Os certificados geridos pela Google que usam carateres universais só são suportados pelo Certificate Manager quando usam a autorização DNS.
Pode criar certificados SSL geridos pela Google através de:
- Recursos de certificados SSL do Compute Engine: apenas os recursos
sslCertificatesdo Compute Engine globais suportam certificados SSL geridos pela Google; os recursosregionSslCertificatesnão os suportam. Os certificados SSL do Compute Engine globais suportam apenas certificados geridos pela Google confiados publicamente. Para mais informações, consulte o artigo Use certificados SSL geridos pela Google. - Gestor de certificados: os certificados do gestor de certificados (globais e regionais) suportam certificados geridos pela Google fidedignos publicamente e certificados geridos pela Google fidedignos de forma privada. Para mais informações, consulte a secção Certificados na documentação do gestor de certificados.
Tipos de chaves suportados
Os equilibradores de carga suportam certificados que usam chaves privadas de diferentes tipos de chaves. A tabela seguinte mostra o suporte de tipo de chave consoante os certificados sejam globais ou regionais e sejam autogeridos ou geridos pela Google.|
Tipo de certificado SSL arrow_forward Tipo de chave arrow_downward |
Certificados SSL do Compute Engine | Certificados SSL do Gestor de certificados | ||||
|---|---|---|---|---|---|---|
| Global | Regional | Global e regional | ||||
| Autogerido | Gerido pela Google e fidedigno publicamente | Autogerido | Autogerido | Gerido pela Google e fidedigno publicamente | Gerido pela Google e fidedigno de forma privada | |
| RSA-2048 | ||||||
| RSA-3072 | ||||||
| RSA-4096 | ||||||
| ECDSA P-256 | ||||||
| ECDSA P-384 | ||||||
Use certificados com chaves ECDSA
Esta secção examina o motivo pelo qual recomendamos o ECDSA em vez do RSA como prática recomendada para chaves de assinatura de certificados.
Que tipo de chave usar
O ECDSA P-256 é a escolha recomendada do tipo de chave para a maioria dos certificados TLS, oferecendo uma forte segurança criptográfica juntamente com um excelente desempenho para operações de assinatura e uma utilização eficiente da largura de banda da rede.
Seguem-se alguns dos possíveis motivos para usar outros tipos de chaves de certificados:
- Se precisar de suportar clientes antigos que não suportam certificados ECDSA, pode fornecer certificados RSA-2048, além de certificados ECDSA P-256.
- Se tiver requisitos de conformidade específicos que exijam a utilização de tamanhos de chaves maiores ou tipos de chaves específicos, pode usar chaves ECDSA P-384, RSA-2048, RSA-3072 e RSA-4096.
Por que motivo deve escolher ECDSA em vez de RSA
A principal vantagem do ECDSA reside na sua capacidade de fornecer um nível de segurança criptográfica equivalente com chaves significativamente mais pequenas em comparação com o RSA. Esta eficiência traduz-se em benefícios tangíveis de desempenho e recursos. Uma chave mais pequena não implica uma segurança mais fraca. A ECDSA baseia-se no problema do logaritmo discreto da curva elíptica, que oferece uma segurança mais forte por unidade de chave e, em alguns casos, uma melhor eficiência computacional em comparação com a RSA.
Por exemplo:
- Uma chave ECDSA de 256 bits oferece um nível de segurança semelhante ao de uma chave RSA-3072.
- Uma chave ECDSA de 384 bits oferece um nível de segurança superior ao de qualquer tamanho de chave RSA amplamente suportado.
Principais vantagens do ECDSA:
Desempenho: as operações de assinatura ECDSA são significativamente menos intensivas em termos de computação do que as operações RSA, oferecendo um nível de segurança equivalente. Isto reduz a carga da CPU e a latência, o que é fundamental para sistemas de elevado débito ou sensíveis à latência.
Eficiência: as chaves e as assinaturas mais pequenas requerem menos largura de banda e armazenamento, o que é especialmente benéfico para ambientes com restrições de recursos, como dispositivos móveis e de IdC.
Vários certificados SSL
Um Application Load Balancer ou um Network Load Balancer de proxy pode alojar dois ou mais certificados SSL em simultâneo quando o respetivo proxy de destino é configurado através de um método de configuração de certificados suportado. Como prática recomendada, use o Gestor de certificados quando forem necessários vários certificados SSL.
Para balanceadores de carga que suportam certificados SSL do Compute Engine: o proxy de destino do balanceador de carga pode referenciar até 15 certificados SSL do Compute Engine. O primeiro recurso de certificado SSL do Compute Engine referenciado é o certificado predefinido (principal) para o proxy de destino.
Para equilibradores de carga que suportam um mapa de certificados do Certificate Manager: o proxy de destino do equilibrador de carga faz referência a um único mapa de certificados. O mapeamento de certificados suporta milhares de entradas de mapeamento de certificados. Pode configurar que entrada de certificado é o certificado predefinido (principal) para o mapa de certificados.
Para equilibradores de carga que suportam a referência direta a certificados do Gestor de certificados: o proxy de destino do equilibrador de carga pode referenciar até 100 certificados do Gestor de certificados. O primeiro recurso de certificado SSL do Certificate Manager referenciado é o certificado predefinido (principal) para o proxy de destino.
Para mais informações, consulte:
Proxies de destino e certificados SSL na documentação de equilíbrio de carga.
Quotas e limites de recursos na documentação do Certificate Manager.
Processo de seleção de certificados
O seguinte processo de seleção de certificados aplica-se a equilibradores de carga cujos proxies de destino referenciam vários certificados SSL do Compute Engine ou vários certificados do Gestor de certificados.
O processo de seleção de certificados é diferente se o proxy de destino de um equilibrador de carga fizer referência a um mapa de certificados do Gestor de certificados. Para ver detalhes sobre o processo de seleção de certificados de um mapeamento de certificados, consulte a lógica de seleção de certificados na documentação do Certificate Manager.
Depois de um cliente se ligar ao balanceador de carga, o cliente e o balanceador de carga negociam uma sessão TLS. Durante a negociação da sessão TLS, o cliente envia ao balanceador de carga uma lista de cifras TLS suportadas (no ClientHello). O balanceador de carga seleciona um certificado cujo algoritmo de chave pública é compatível com o cliente. O cliente também pode enviar um nome de anfitrião de indicação do nome do servidor (SNI) para o balanceador de carga como parte desta negociação. Por vezes, os dados do nome de anfitrião SNI são usados para ajudar o equilibrador de carga a escolher o certificado que deve enviar para o cliente.
Se o proxy de destino do equilibrador de carga referenciar apenas um certificado, esse certificado é usado e o valor do nome de anfitrião SNI enviado pelo cliente não é relevante.
Se o proxy de destino do balanceador de carga fizer referência a dois ou mais certificados, o balanceador de carga usa o seguinte processo para selecionar um único certificado:
Se o cliente não tiver enviado nenhum nome de anfitrião SNI no respetivo
ClientHello, o balanceador de carga usa o primeiro certificado na respetiva lista de certificados.Se o cliente enviar um nome de anfitrião SNI que não corresponda a nenhum nome comum (CN) do certificado e que não corresponda a nenhum nome alternativo de entidade (SAN) do certificado, o balanceador de carga usa o primeiro certificado na respetiva lista de certificados.
Em todas as outras situações: o balanceador de carga seleciona um certificado através do seguinte processo de correspondência:
A correspondência é feita pelo sufixo mais longo em relação aos atributos do certificado de nome comum (CN) e nome alternativo de entidade (SAN), com uma preferência por certificados ECDSA em vez de certificados RSA.
Para ilustrar o método de correspondência, considere um proxy de destino que faz referência aos dois certificados seguintes:
Certificado A
- CN:
cats.pets.example.com - SANs:
cats.pets.example.com,*.pets.example.com,*.example.com
- CN:
Certificado B
- CN:
dogs.pets.example.com - SANs:
dogs.pets.example.com,*.pets.example.com,*.example.com
- CN:
Considere agora os seguintes cenários:
- Se o nome de anfitrião SNI enviado pelo cliente for
cats.pets.example.com, o equilibrador de carga usa o certificado A. - Se o nome de anfitrião SNI enviado pelo cliente for
ferrets.pets.example.com, não existe uma correspondência exata, pelo que o equilibrador de carga seleciona o certificado A ou o certificado B porque ambos incluem*.pets.example.comna respetiva lista de SANs. Nesta situação, não pode controlar que certificado é selecionado.
- Se o nome de anfitrião SNI enviado pelo cliente for
Depois de selecionar um certificado, o balanceador de carga envia o certificado ao cliente apenas se o certificado selecionado usar um algoritmo de chave pública compatível com uma cifra enviada pelo cliente no
ClientHello. A negociação de TLS falha se o cliente não suportar um conjunto de cifras que inclua o algoritmo de chave pública (ECDSA ou RSA) do certificado que o equilibrador de carga selecionou.
Preços
Incorre em custos de rede quando usa equilibradores de carga Google Cloud . Para mais informações, consulte a secção Preços de todas as redes. Para ver os preços do Certificate Manager, consulte a secção Preços na documentação do Certificate Manager. Não existem custos adicionais pela utilização de recursos de certificados SSL do Compute Engine.