Quando um equilibrador de carga se liga a back-ends que estão dentro do Google Cloud, o equilibrador de carga aceita qualquer certificado que os seus back-ends apresentem. Nestes casos, o balanceador de carga não realiza nenhuma validação de certificado.
Com o TLS autenticado no back-end ou a autenticação no back-end, o balanceador de carga pode validar a identidade dos back-ends aos quais se liga. Além disso, com o mTLS de back-end, o balanceador de carga pode provar a sua identidade aos back-ends através de um certificado TLS de cliente.
O diagrama seguinte mostra a diferença entre o mTLS de front-end e de back-end, com foco no papel do equilibrador de carga em cada caso. No mTLS de front-end, o balanceador de carga atua como o servidor, validando a identidade do cliente. No mTLS de back-end, o balanceador de carga atua como o cliente, comprovando a respetiva identidade ao back-end.
O mTLS funciona de forma independente no front-end e no back-end. Pode configurar o mTLS no front-end, no back-end ou em ambos.
Este documento oferece uma vista geral do TLS autenticado no back-end, juntamente com o mTLS no back-end. Para saber mais acerca do mTLS de front-end, consulte a vista geral do TLS mútuo.
O TLS autenticado no back-end e o mTLS no back-end podem ser configurados no recurso de serviço do back-end dos balanceadores de carga de aplicações externos globais.
Funcionalidades
O mTLS usa a infraestrutura de chave pública (PKI) para autenticar a identidade das entidades que comunicam através da rede. A infraestrutura inclui três componentes: um cliente, um servidor e uma autoridade de certificação (AC). O TLS autenticado no back-end e o mTLS no back-end adicionam as seguintes capacidades aos balanceadores de carga de aplicações:
O balanceador de carga pode validar os certificados apresentados pelos back-ends com base nas suas próprias âncoras fidedignas. Pode carregar várias âncoras de fidedignidade para ativar uma migração perfeita de uma infraestrutura de chaves públicas (PKI) anterior para uma nova sem tempo de inatividade.
O balanceador de carga pode validar os certificados TLS dos back-ends em relação às raízes de confiança públicas (PKI Web).
Pode configurar certificados intermédios, além das âncoras de confiança, para ajudar a construir o caminho de validação de certificados de back-end. A utilização de certificados intermédios significa que os seus servidores de back-end não têm de fornecer a cadeia de certificados completa.
Pode configurar um nome de anfitrião de Indicação do nome do servidor (SNI) TLS para o seu serviço de back-end. Durante a negociação de TLS, o balanceador de carga inclui este nome do anfitrião SNI na mensagem
ClientHelloque envia para o back-end. Em seguida, o back-end responde com o respetivo certificado TLS e o equilibrador de carga verifica se, pelo menos, um dos campos de nome alternativo de entidade (SAN) deste certificado corresponde ao nome de anfitrião ou a qualquer um dos campos SAN configurados para o serviço de back-end.Pode configurar o serviço de back-end do seu equilibrador de carga para usar o mTLS, de modo que o equilibrador de carga possa comprovar a sua identidade aos back-ends. Esta autenticação é realizada através de um certificado de cliente (balanceador de carga) que o balanceador de carga apresenta ao back-end.
Requisitos de certificado
Ao configurar certificados para TLS autenticado de back-end e mTLS de back-end, certifique-se de que cumprem estes requisitos:
As ferramentas de criptografia modernas formam a base da autenticação mTLS. Os certificados têm de usar algoritmos RSA ou ECDSA para a troca de chaves. Os algoritmos de hash têm de usar SHA-256 ou uma função de hash criptográfica mais forte. Os algoritmos de hash, como MD4, MD5 e SHA-1, não são suportados.
Os certificados de servidor de folha fornecidos pelo back-end têm os seguintes requisitos:
- A extensão Basic Constraints
não pode conter
CA=true. - A extensão Utilização alargada da chave
tem de conter
serverAuth. - A extensão Utilização alargada da chave
não deve conter os campos
codeSigning,timeStampingouOCSPSigning. - O certificado não pode ter expirado.
- A extensão Basic Constraints
não pode conter
Para os certificados de cliente final (equilibrador de carga) usados no mTLS de back-end, o certificado tem de ser um recurso do gestor de certificados. O âmbito deste certificado tem de ser
client-auth, o que indica que este certificado é usado como um certificado de cliente no mTLS de back-end.- A extensão Basic Constraints
não pode conter
CA=true. - A extensão Utilização alargada da chave
tem de conter
clientAuth. - A extensão Utilização alargada da chave
não deve conter os campos
codeSigning,timeStampingouOCSPSigning. - O certificado não pode ter expirado.
- A extensão Basic Constraints
não pode conter
Os certificados de raiz e intermediários usados com TLS autenticado no back-end têm os seguintes requisitos:
- A extensão Basic Constraints
tem de conter
CA=true. - A extensão Key Usage
tem de estar definida como
keyCertSign. - A extensão Extended Key Usage tem de conter o campo
serverAuth. - O certificado não pode ter expirado.
- A extensão Basic Constraints
tem de conter
Componentes-chave do TLS autenticado no back-end e do mTLS no back-end
Com o TLS autenticado no back-end, o balanceador de carga pode validar a identidade dos back-ends aos quais se liga. Pode configurar o TLS autenticado de back-end num balanceador de carga de HTTP(S) que usa HTTPS ou HTTP/2 como protocolo do serviço de back-end. Se não configurar o TLS autenticado no back-end, o balanceador de carga aceita qualquer certificado do back-end. Com o mTLS de back-end, também pode configurar o balanceador de carga para apresentar o seu próprio certificado de cliente ao back-end, que o back-end pode usar para autenticar o balanceador de carga.
Para configurar o TLS autenticado no back-end, tem de fazer o seguinte:
- Crie um recurso de configuração de confiança.
- Crie um recurso de configuração de autenticação de back-end.
- Atualize o atributo de definição de TLS no serviço de back-end, apontando-o para o recurso de configuração de autenticação de back-end.
Para configurar o mTLS de back-end, tem de criar um certificado de cliente e anexá-lo ao recurso Backend Authentication Config. Não pode anexar o certificado de cliente depois de o recurso Backend Authentication Config ter sido criado.
O diagrama seguinte mostra os diferentes componentes anexados ao serviço de back-end de um Application Load Balancer que ativam o TLS autenticado de back-end e o mTLS de back-end.
As informações que se seguem oferecem uma vista geral destes diferentes componentes usados para configurar o TLS autenticado de back-end e o mTLS de back-end.
Configuração de confiança
Para autenticar os certificados de servidor que o seu back-end apresenta ao
equilibrador de carga, o equilibrador de carga tem de ser configurado com certificados
X.509 que estabelecem uma cadeia de confiança para o emissor do certificado
do back-end. Configura a configuração de confiança através de um TrustConfig
recurso, que expressa
toda a configuração de confiança e contém uma única loja de confiança.
Um repositório de confiança encapsula uma âncora de confiança (certificado de raiz) e, opcionalmente, um ou mais certificados intermédios. Uma âncora de confiança é um certificado que representa uma raiz de fidedignidade. Um certificado de servidor válido tem de apresentar uma cadeia de fidedignidade que remeta para uma âncora de fidedignidade no repositório fidedigno.
Um certificado intermédio é um certificado que faz parte de uma cadeia de confiança que remete para uma âncora de confiança no repositório fidedigno. É usado, juntamente com quaisquer ACs intermédias adicionais incluídas no certificado de folha, para criar a cadeia de confiança durante o processo de validação. A criação de um certificado intermédio é opcional.
Se precisar de usar um certificado autoassinado, expirado, que não esteja encadeado a uma raiz de confiança especificada ou que tenha falhado na validação, pode adicionar esse certificado a uma lista de autorizações na configuração de confiança. A criação de um certificado autossinado que pode ser adicionado a uma lista de autorizações também é opcional.
O repositório de confiança não contém chaves privadas porque apenas os certificados são necessários para validar uma cadeia de confiança.
Recurso de configuração de autenticação do back-end
O recurso Backend Authentication Config (BackendAuthenticationConfig), anexado ao serviço de back-end do balanceador de carga, permite o seguinte:
- TLS autenticado no back-end (através da configuração de confiança e das raízes de confiança públicas)
- mTLS de back-end (com o certificado de cliente)
Para ativar o TLS autenticado no back-end e o mTLS no back-end, o recurso Backend Authentication Config aponta para os seguintes recursos:
Configuração de confiança (
trustConfig): a configuração de confiança anexada usada para validar o certificado do servidor fornecido pelo back-end.Raízes de fidedignidade públicas (
wellKnownRoots): indica se o balanceador de carga confia em certificados de servidor de back-end que são emitidos por ACs públicas, além dos certificados considerados fidedignos pela configuração de fidedignidade. Para saber mais, consulte o artigo Usar raízes públicas de confiança.Certificado de cliente (
clientCertificate): o certificado de cliente que o balanceador de carga usa para expressar a respetiva identidade ao back-end, se a ligação ao back-end usar mTLS. Para TLS autenticado no back-end (autenticação do back-end), este campo pode estar vazio, caso em que o balanceador de carga só autentica o back-end, mas não a si próprio, no back-end.
Serviço de back-end
No serviço de back-end, o atributo tlsSettings aponta para os seguintes recursos para validar o certificado de back-end.
- Configuração de autenticação do back-end (
authenticationConfig) - Nome do anfitrião SNI (
sni) - SANs aceites (
subjectAltNames)
Os campos SNI (sni) e SAN (subjectAltNames) no atributo tlsSettings controlam a forma como o balanceador de carga valida o certificado do back-end com base nos valores SAN do certificado. Estes campos
influenciam o processo de validação, independentemente de o TLS autenticado no back-end
estar configurado.
Quando o campo SNI está definido (tlsSettings.sni), o balanceador de carga faz o seguinte:
- Envia o nome de anfitrião SNI para o servidor de back-end durante o handshake do TLS.
- Valida se o certificado TLS do back-end inclui um SAN que corresponde ao nome do anfitrião SNI.
Por predefinição, o equilibrador de carga verifica se o certificado TLS do back-end inclui um SAN que corresponde ao nome de anfitrião SNI. No entanto, se os SANs estiverem configurados no serviço de back-end (tlsSettings.subjectAltNames), o balanceador de carga faz o seguinte:
- Ignora o nome de anfitrião SNI para a validação SAN.
- Valida se o certificado TLS do back-end inclui um SAN que
corresponde a um dos SANs aceites (
subjectAltNames) configurados no serviço de back-end.
Certificado do cliente
Além do TLS autenticado no back-end (autenticação no back-end), pode configurar o serviço de back-end de um equilibrador de carga para usar o mTLS, de modo que o equilibrador de carga possa provar a sua identidade ao back-end. Esta autenticação usa um certificado de cliente (balanceador de carga) que o balanceador de carga apresenta ao back-end.
Para configurar o mTLS de back-end, tem de fazer o seguinte:
- Crie um recurso de certificado de cliente que contenha o certificado de cliente (balanceador de carga) e a respetiva chave privada.
- Anexe o certificado de cliente ao recurso Backend Authentication Config.
O mTLS de back-end também é compatível com as identidades de carga de trabalho geridas do Compute Engine quando configura certificados geridos através do Gestor de certificados. Os certificados geridos por PKI pública não são suportados e todos os certificados de cliente têm de ter um âmbito client-auth e estar em conformidade com os requisitos
de certificado.
Se o back-end pedir um certificado de cliente, tem de ser configurado para aceitar o certificado de cliente. Se o back-end recusar a ligação do balanceador de carga, o balanceador de carga devolve um código de estado HTTP 502 para os pedidos que está a encaminhar por proxy e regista um estado genérico no Cloud Logging.
Configure o TLS autenticado de back-end e o mTLS de back-end no balanceador de carga
Pode configurar o TLS autenticado no back-end e o mTLS no back-end no equilibrador de carga usando uma PKI privada ou raízes de confiança públicas.
Use PKI privada
Segue-se uma vista geral de nível elevado dos principais passos que tem de seguir para configurar o TLS autenticado no back-end e o mTLS no back-end no seu equilibrador de carga através de certificados emitidos pela sua PKI privada. A infraestrutura de chaves públicas privada tem a vantagem de estar totalmente sob o seu controlo e isolada dos sistemas de infraestrutura de chaves públicas da Internet pública.
Crie um recurso de configuração de confiança que inclua a âncora de confiança (certificado de raiz) e os certificados intermédios que servem como raízes de confiança.
Para configurar o mTLS de back-end, crie um certificado de cliente que contenha o certificado de cliente (equilibrador de carga) e a respetiva chave privada.
Crie um recurso Backend Authentication Config que faça referência à trust config. Se quiser configurar o mTLS de back-end, o recurso Backend Authentication Config faz referência à configuração de confiança e ao certificado do cliente.
Anexe o recurso Backend Authentication Config ao serviço de back-end do balanceador de carga.
Para saber mais sobre esta configuração em detalhe, consulte os seguintes guias:
Use raízes de fidedignidade públicas
Além de usar certificados emitidos pela sua PKI privada para ativar o TLS autenticado no back-end, também pode usar raízes públicas de confiança para validar o certificado do back-end.
Para usar raízes de confiança públicas, não precisa de criar uma configuração de confiança e anexá-la ao recurso de configuração de autenticação de back-end. Em alternativa, tem de definir PUBLIC_ROOTS como um valor no campo wellKnownRoots do recurso de configuração de autenticação de back-end. No entanto, também pode criar uma trust
config que inclua explicitamente as raízes dos seus certificados emitidos publicamente,
além dos certificados fidedignos pela trust config.
A definição PUBLIC_ROOTS usa um conjunto de ACs de raiz,
semelhante ao conjunto de ACs de raiz fidedignas pelos navegadores, que é gerido pela Google
e pode mudar ao longo do tempo. Isto apresenta um risco de os seus certificados de back-end ficarem inválidos quando estas raízes mudarem. Se precisar de validar certificados emitidos publicamente, considere escolher uma AC fidedigna e bem estabelecida, e uma que use a assinatura cruzada intermédia para emitir os seus certificados de back-end, de modo a mitigar o risco de um certificado de raiz expirar ou ser revogado.
Passos de validação do certificado do servidor
Quando valida o certificado do servidor durante o TLS autenticado de back-end ou a autenticação de back-end, o balanceador de carga faz o seguinte:
Verifique se o servidor possui a chave privada do certificado.
O servidor prova a posse da chave privada associada ao certificado que apresenta ao equilibrador de carga assinando um conjunto de informações com a respetiva chave privada e enviando-o para o equilibrador de carga como parte da mensagem
CertificateVerify. Em seguida, o equilibrador de carga valida esta assinatura através da chave pública do certificado do servidor. Se a validação da assinatura falhar, indica que o servidor de back-end não tem a chave privada correspondente ao certificado. Nesses casos, o balanceador de carga termina o handshake do TLS sem registar erros.Valide a cadeia de confiança.
Se a configuração de fidedignidade incluir, pelo menos, uma âncora de fidedignidade ou tiver o atributo
wellKnownRootsdefinido comoPUBLIC_ROOTS, o balanceador de carga tenta validar uma cadeia de fidedignidade entre o certificado do servidor e a âncora de fidedignidade configurada. As verificações de validação incluem o seguinte:- O certificado do servidor do back-end, os certificados intermédios (se forem fornecidos) e o certificado de raiz configurado estão em conformidade com os requisitos de certificado.
- Para todos os certificados na cadeia de confiança, o campo de assunto no certificado principal corresponde ao campo de emissor no certificado secundário. Esta validação ajuda a garantir que a identidade (assunto) do certificado principal é a mesma que a identidade indicada como emissor no certificado secundário.
- Para todos os certificados na cadeia de confiança, o identificador da chave de requerente (SKID) do certificado principal corresponde ao identificador da chave da autoridade (AKID) no certificado subordinado. Esta correspondência confirma que: O certificado secundário foi emitido pela autoridade de raiz correta e Que é fidedigno porque a chave pública da raiz está a ser referenciada no AKID para validar a validade do certificado.
Estabeleça uma ligação com o back-end.
Se a validação do certificado for bem-sucedida, o equilibrador de carga prossegue com a ligação ao back-end.
No entanto, se a validação do certificado falhar, o balanceador de carga termina a ligação ao back-end, envia um código de estado HTTP
502ao cliente e regista o motivo da terminação no Cloud Logging. Em caso de erro de validação do certificado, os pedidos recebidos subsequentes acionam o balanceador de carga para reiniciar a ligação de back-end.A ligação de back-end também pode falhar se o servidor de back-end recusar a ligação. Com o mTLS de back-end, isto pode acontecer porque considera o certificado de cliente inválido. Quando a ligação ao back-end falha, o balanceador de carga responde a pedidos enviados por proxy com um código de estado HTTP
502e regista um motivo de erro genérico no Cloud Logging.
Processamento de erros e registo
Os equilibradores de carga de aplicações oferecem capacidades de registo detalhadas que lhe permitem monitorizar a validação de certificados de servidor, identificar potenciais problemas e resolver problemas de ligação. Esta secção descreve os diferentes tipos de erros que podem ocorrer durante a validação mTLS e como são registados.
Se a validação do certificado do servidor falhar, a ligação é terminada e os erros são registados no Cloud Logging. Estes erros estão descritos na tabela seguinte.
| Estado do certificado do servidor | Erro registado |
|---|---|
| A cadeia de certificados do servidor é demasiado longa (mais de 10 certificados intermédios incluídos no certificado do servidor). |
server_cert_chain_exceeded_limit
|
Um servidor ou um certificado intermédio tem um tamanho da chave RSA inválido. Não é feita nenhuma validação. As chaves RSA podem variar entre 2048 e 4096 bits. |
server_cert_invalid_rsa_key_size
|
Um servidor ou um certificado intermédio está a usar uma curva elíptica não suportada. Não é feita nenhuma validação. As curvas válidas são P-256 e P-384. |
server_cert_unsupported_elliptic_curve_key
|
Um servidor ou um certificado intermédio está a usar um algoritmo não RSA ou não ECDSA. Não é feita nenhuma validação. |
server_cert_unsupported_key_algorithm
|
A PKI a usar para validação tem mais de dez certificados intermédios que partilham o mesmo assunto e informações da chave pública do assunto. Não é feita nenhuma validação. |
server_cert_pki_too_large
|
Um certificado intermédio fornecido para validação tinha mais de 10 restrições de nomes. |
|
O certificado do servidor tem um campo de extensão |
|
| O limite de tempo foi excedido ao tentar validar a cadeia de certificados. |
server_cert_validation_timed_out
|
O limite de profundidade ou iteração foi atingido ao tentar validar a cadeia de certificados. A profundidade máxima de uma cadeia de certificados é de dez, incluindo os certificados de raiz e de servidor. O número máximo de iterações é 100 (certificados examinados para validar a cadeia de certificados do servidor). |
server_cert_validation_search_limit_exceeded
|
Configurou o mTLS sem configurar um recurso |
server_cert_validation_not_performed
|
O servidor não forneceu o certificado pedido durante a negociação. |
server_cert_not_provided
|
A validação do certificado do servidor falhou com o recurso |
ssl_certificate_verification_failed
|
O serviço não consegue realizar a validação da cadeia de certificados. |
server_cert_validation_unavailable
|
| Erro interno ao validar a cadeia de certificados. |
server_cert_validation_internal_error
|
Não foi encontrado nenhum |
server_cert_trust_config_not_found
|
| A carga útil do certificado do servidor (incluindo todos os certificados intermédios) é demasiado grande (mais de 16 KB). |
server_cert_exceeded_size_limit
|
Limitações
O TLS autenticado no back-end e o mTLS no back-end só podem ser configurados para equilibradores de carga de aplicações externos globais. Os balanceadores de carga de aplicações clássicos não suportam TLS autenticado no back-end nem mTLS no back-end.
O TLS autenticado no back-end e o mTLS no back-end não são suportados para os seguintes tipos de back-end:
Back-ends de NEG da Internet global
Back-ends do App Engine
Para ativar o mTLS de back-end, também tem de configurar o TLS autenticado de back-end.
Se quiser ativar o mTLS de back-end, tem de criar o certificado de cliente antes de configurar o recurso Backend Authentication Config.
As verificações de funcionamento usadas pelos back-ends não implementam a autenticação TLS nem as capacidades de mTLS. Tem de configurar os back-ends com pontos finais de verificação de funcionamento que possam responder a pedidos HTTP ou HTTPS.
O balanceador de carga não passa o nome do anfitrião SNI do cliente da ligação TLS de front-end quando se liga a um back-end. No entanto, os backends podem aceder ao nome do anfitrião SNI do cliente através de um cabeçalho de pedido personalizado.
Para o mTLS de back-end, as chaves do certificado de cliente estão restritas ao seguinte:
- As chaves RSA podem variar entre 2048 e 4096 bits.
- As chaves ECDSA podem usar as curvas P-256 ou P-384.
O TLS autenticado no back-end não suporta verificações de revogação de certificados.
Quotas e limites
Uma única loja de confiança pode conter até 200 âncoras de confiança e certificados intermédios combinados, com um limite separado de 100 para certificados intermédios. Não podem ser partilhadas mais de três informações de chave pública da entidade e entidade iguais por certificados intermédios.
A profundidade máxima de uma cadeia de certificados é de 10 certificados, incluindo os certificados raiz e folha. O número máximo de certificados intermédios que podem ser avaliados ao tentar criar a cadeia de confiança é 100.
O TLS autenticado no back-end limita a cadeia de certificados recebida do back-end a um máximo de 16 KB e 10 certificados.
Os certificados de raiz usados para validação não podem conter mais de 10 restrições de nomes.
O número máximo de nomes alternativos do requerente permitidos no campo
tlsSettings.subjectAltNames[]é 5.