Esta página foi traduzida pela API Cloud Translation.

Vista geral do TLS mútuo

O TLS mútuo, ou mTLS, é um protocolo padrão da indústria para a autenticação mútua entre um cliente e um servidor. Garante que o cliente e o servidor se autenticam entre si, verificando se cada um tem um certificado válido emitido por uma autoridade de certificação (AC) fidedigna. Ao contrário do TLS padrão, em que apenas o servidor é autenticado, o mTLS requer que o cliente e o servidor apresentem certificados, confirmando as identidades de ambas as partes antes de a comunicação ser estabelecida.

O mTLS está configurado no recurso de proxy HTTPS de destino de todos os balanceadores de carga de aplicações:

Balanceador de carga de aplicações externo global
Balanceador de carga de aplicações clássico
Balanceador de carga de aplicações externo regional
Balanceador de carga de aplicações interno regional
Balanceador de carga de aplicações interno entre regiões

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 mTLS para equilibradores de carga suporta as seguintes funcionalidades:

Verificar se o cliente que apresenta o certificado possui a respetiva chave privada.
Valide os certificados de cliente num dos dois modos:
- Rejeitar certificados inválidos: aplica uma autenticação rigorosa rejeitando pedidos se não for possível validar a cadeia de certificados de cliente.
- Permitir certificados inválidos ou em falta: oferece flexibilidade ao transmitir todos os pedidos ao back-end, mesmo que um certificado de cliente esteja em falta ou seja inválido.
Validar certificados de cliente em relação a uma âncora de PKI carregada (certificado raiz), com a opção de adicionar várias âncoras separadamente para permitir uma migração perfeita de uma PKI antiga para uma nova sem tempo de inatividade.
Disponibilize certificados intermédios adicionais para ajudar a construir o caminho de validação do certificado do cliente em relação às âncoras de PKI especificadas (certificados de raiz). Estes certificados intermédios permitem que o mTLS funcione com clientes que não fornecem a cadeia de certificados completa.
Gere e transmita uma impressão digital do certificado ao back-end como um cabeçalho de pedido personalizado.
Transmita os campos selecionados extraídos do certificado para o back-end através de cabeçalhos personalizados.
Transmita o resultado da validação e quaisquer erros de validação ao back-end através de cabeçalhos personalizados.

Requisitos de certificado

Ao configurar certificados para mTLS, certifique-se de que estão em conformidade com 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.
Para certificados de cliente (folha):
- 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, timeStamping ou OCSPSigning.
- O certificado não pode ter expirado.
- O certificado de cliente não pode ser um certificado autoassinado.
Para certificados de raiz e intermédios:
- A extensão Restrições básicas tem de conter CA=true.
- A extensão Key Usage tem de ser definida como keyCertSign.
- A extensão Extended Key Usage deve conter o campo clientAuth.
- O certificado não pode ter expirado.

Arquitetura de uma implementação de mTLS

Com o mTLS, pode configurar um recurso de configuração de confiança, que contém um repositório de confiança. O repositório de confiança encapsula uma âncora de confiança (certificado de raiz) e, opcionalmente, um ou mais certificados intermédios. Quando o equilibrador de carga recebe um certificado de cliente, valida-o estabelecendo uma cadeia de fidedignidade do certificado de cliente até à âncora de fidedignidade configurada.

Segue-se uma breve vista geral dos diferentes recursos que tem de configurar para configurar o mTLS para o equilibrador de carga:

Configuração de confiança. Contém um único recurso de repositório de fidedignidade, que, por sua vez, encapsula uma âncora de fidedignidade (certificado de raiz) e, opcionalmente, um ou mais certificados intermédios. A configuração de confiança é usada para estabelecer uma cadeia de confiança entre o certificado do cliente e a âncora de confiança. Para mais informações, consulte as configurações de confiança.

Opcionalmente, se precisar de usar um certificado autoassinado, que tenha expirado ou que seja inválido de outra forma, ou se não tiver acesso aos certificados raiz e intermédios, pode adicionar esse certificado à configuração fidedigna no campo allowlistedCertificates. Não precisa de um repositório de confiança para adicionar um certificado a uma lista de autorizações.

Adicionar um certificado à lista de autorizações significa que o certificado é sempre considerado válido desde que seja analisável, seja estabelecida a prova de posse da chave privada e sejam cumpridas as restrições no campo SAN do certificado.
Repositório fidedigno. Contém a âncora de confiança e os certificados da autoridade de certificação (AC) intermédios que são usados para estabelecer uma cadeia de confiança e validar o certificado de cliente. Uma AC é usada para emitir certificados fidedignos para o cliente. A CA é identificada pela âncora de confiança do equilibrador de carga (certificado de raiz) ou pelos certificados da CA intermédia.

Pode carregar os seguintes tipos de certificados de raiz e intermédios para o repositório de confiança:
- Certificados emitidos por ACs de terceiros à sua escolha.
- Certificados emitidos por ACs privadas sob o seu controlo, conforme descrito no artigo Configure o TLS mútuo com uma AC privada.
- Certificados fornecidos pelo utilizador, conforme descrito em Configure o TLS mútuo com certificados fornecidos pelo utilizador.
Autenticação do cliente (também conhecida como ServerTLSPolicy). Especifica o modo de validação do cliente e o recurso de configuração de confiança a usar ao validar certificados de cliente. Quando o cliente apresenta um certificado inválido ou nenhum certificado ao equilibrador de carga, o modo de validação do cliente especifica como a ligação do cliente é processada. Pode especificar todos os parâmetros relacionados com a autenticação mTLS nas políticas TLS do servidor. O recurso ClientAuthentication(ServerTLSPolicy) está anexado ao recurso de proxy HTTPS de destino.

Os diagramas seguintes mostram os diferentes componentes mTLS anexados ao recurso de proxy HTTPS de destino dos balanceadores de carga de aplicações globais e regionais.

Global

O diagrama seguinte mostra os componentes de uma implementação do balanceador de carga de aplicações externo. Esta arquitetura também se aplica ao Application Load Balancer interno entre regiões, que é um Application Load Balancer interno que usa componentes globais.

regional

O diagrama seguinte mostra os componentes de uma implementação de um balanceador de carga de aplicações interno regional. Esta arquitetura também se aplica ao balanceador de carga de aplicações externo regional, que é um balanceador de carga de aplicações externo que usa componentes regionais.

Modo de validação do cliente

Quando o cliente apresenta um certificado inválido ou nenhum certificado ao balanceador de carga, o atributo clientValidationMode no recurso de autenticação de cliente (ServerTLSPolicy) especifica como o balanceador de carga processa a ligação do cliente.

Os valores do modo de validação do cliente são os seguintes:

ALLOW_INVALID_OR_MISSING_CLIENT_CERT. Permite a ligação do cliente, mesmo que a validação do certificado de cliente tenha falhado ou não tenha sido apresentado nenhum certificado de cliente. Neste modo, o equilibrador de carga permite a ligação do cliente e passa todos os pedidos para o back-end, independentemente de ser possível ou não estabelecer uma cadeia de confiança.

O comprovativo de posse da chave privada é sempre verificado quando o certificado do cliente é apresentado. Se o cliente não conseguir comprovar a posse da chave privada, a negociação TLS é terminada, mesmo que o modo de validação do cliente permita um certificado de cliente inválido ou em falta.
REJECT_INVALID. Rejeita a ligação se um cliente não fornecer um certificado ou se a validação do certificado falhar. Neste modo, o balanceador de carga termina a ligação do cliente se não conseguir estabelecer uma cadeia de fidedignidade a partir do certificado do cliente até à âncora de fidedignidade.

Configure o mTLS no balanceador de carga

Segue-se uma vista geral de nível elevado dos principais passos que tem de seguir para configurar o mTLS no seu balanceador de carga:

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.
Associe a configuração de confiança ao recurso de autenticação do cliente (ServerTLSPolicy), que define o modo de validação do cliente de ALLOW_INVALID_OR_MISSING_CLIENT_CERT ou REJECT_INVALID.
Anexe o recurso de autenticação de cliente (ServerTLSPolicy) ao recurso de proxy HTTPS de destino do balanceador de carga.
Opcional: pode usar cabeçalhos mTLS personalizados para transmitir informações sobre a ligação mTLS a um serviço de back-end ou a um mapa de URLs.

Para saber mais sobre esta configuração em detalhe, consulte os seguintes guias:

Passos de validação do certificado de cliente

Ao validar o certificado de cliente, o equilibrador de carga faz o seguinte:

Verifique se o cliente tem a chave privada.

O cliente prova a posse da chave privada associada à chave pública no certificado gerando uma assinatura durante o processo de handshake. O equilibrador de carga valida esta assinatura através da chave pública do cliente. Se a validação da assinatura falhar, significa que o cliente não é o proprietário do certificado. Neste caso, a negociação TLS é terminada, mesmo que a sua configuração permita um certificado de cliente inválido ou em falta. Não são registados erros para os balanceadores de carga de aplicações externos globais, mas é registado um erro de TLS no campo proxyStatus para balanceadores de carga de aplicações externos regionais e balanceadores de carga de aplicações internos.
Valide a cadeia de confiança.

O balanceador de carga valida a cadeia de fidedignidade entre o certificado do cliente e a configuração de fidedignidade configurada. As verificações de validação incluem o seguinte:
- Os certificados de cliente, intermediários e de raiz estão em conformidade com os requisitos de certificado.
- O campo de assunto no certificado principal corresponde ao campo de emissor no certificado secundário. Esta validação garante que a identidade (assunto) do certificado principal é a mesma que a identidade indicada como emissor no certificado secundário.
- O identificador da chave de requerente (SKID) do certificado principal corresponde ao identificador da chave da autoridade (AKID) no certificado secundário. 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.
- O nome alternativo do requerente (SAN) de um certificado subordinado não viola o campo NameConstraints no certificado principal.
Nota: os certificados de cliente autoassinados não formam uma cadeia de confiança válida e são sempre rejeitados.
Encaminhar o pedido para o back-end.

Se a validação do certificado de cliente for bem-sucedida, o pedido é encaminhado para o back-end através de cabeçalhos mTLS personalizados.

No entanto, se a validação falhar, a ação tomada depende do valor do modo de validação do cliente:
- ALLOW_INVALID_OR_MISSING_CLIENT_CERT: O pedido é encaminhado com cabeçalhos mTLS personalizados que indicam o motivo da falha de validação. Para balanceadores de carga de aplicações internos entre regiões, balanceadores de carga de aplicações externos regionais e balanceadores de carga de aplicações internos regionais, além dos cabeçalhos mTLS personalizados, pode configurar campos opcionais do mTLS para verificar o motivo da falha.
- REJECT_INVALID: a ligação é terminada e os erros são registados no Cloud Logging.

Cabeçalhos mTLS personalizados transmitidos ao back-end

A tabela seguinte mostra as variáveis de cabeçalho mTLS personalizadas que estão disponíveis para serem transmitidas ao back-end, tanto quando o certificado do cliente passa na validação como quando falha. Se o certificado de cliente falhar na validação, os pedidos são transmitidos ao back-end apenas quando o modo de validação do cliente está definido como ALLOW_INVALID_OR_MISSING_CLIENT_CERT.

Estas variáveis também podem ser definidas no mapa de URLs.

Estado do certificado de cliente	Modo de validação do cliente	Cabeçalhos personalizados
A cadeia de certificados de cliente é demasiado longa (mais de 10 certificados intermédios incluídos no certificado de cliente).	`ALLOW_INVALID_OR_MISSING_CLIENT_CERT`	`client_cert_present: true` `client_cert_chain_verified: false` `client_cert_error: client_cert_chain_exceeded_limit` `client_cert_sha256_fingerprint: <cert hash>`
Um cliente 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.	`ALLOW_INVALID_OR_MISSING_CLIENT_CERT`	`client_cert_present: true` `client_cert_chain_verified: false` `client_cert_error: client_cert_invalid_rsa_key_size` `client_cert_sha256_fingerprint: <cert hash>`
Um cliente ou um certificado intermédio está a usar uma curva elíptica não suportada. Não é feita nenhuma validação. As curvas elípticas válidas são P-256 e P-384.	`ALLOW_INVALID_OR_MISSING_CLIENT_CERT`	`client_cert_present: true` `client_cert_chain_verified: false` `client_cert_error: client_cert_unsupported_elliptic_curve_key` `client_cert_sha256_fingerprint: <cert hash>`
Um cliente ou um certificado intermédio está a usar um algoritmo que não é RSA nem ECDSA. Não é feita nenhuma validação.	`ALLOW_INVALID_OR_MISSING_CLIENT_CERT`	`client_cert_present: true` `client_cert_chain_verified: false` `client_cert_error: client_cert_unsupported_key_algorithm` `client_cert_sha256_fingerprint: <cert hash>`
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.	`ALLOW_INVALID_OR_MISSING_CLIENT_CERT`	`client_cert_present: true` `client_cert_chain_verified: false` `client_cert_error: client_cert_pki_too_large` `client_cert_sha256_fingerprint: <cert hash>`
Um certificado intermédio fornecido para validação tinha mais de 10 restrições de nomes.	`ALLOW_INVALID_OR_MISSING_CLIENT_CERT`	`client_cert_present: true` `client_cert_chain_verified: false` `client_cert_error: client_cert_chain_max_name_constraints_exceeded` `client_cert_sha256_fingerprint: <cert hash>`
O certificado de cliente não tem a extensão `Extended Key Usage (EKU)` que inclui `clientAuth`.	`ALLOW_INVALID_OR_MISSING_CLIENT_CERT`	`client_cert_present: true` `client_cert_chain_verified: false` `client_cert_error: client_cert_chain_invalid_eku` `client_cert_sha256_fingerprint: <cert hash>`
O limite de tempo foi excedido ao tentar validar a cadeia de certificados.	`ALLOW_INVALID_OR_MISSING_CLIENT_CERT`	`client_cert_present: true` `client_cert_chain_verified: false` `client_cert_error: client_cert_validation_timed_out` `client_cert_sha256_fingerprint: <cert hash>`
O limite de profundidade ou iteração é 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 cliente. O número máximo de iterações é 100 (certificados examinados para validar a cadeia de certificados de cliente).	`ALLOW_INVALID_OR_MISSING_CLIENT_CERT`	`client_cert_present: true` `client_cert_chain_verified: false` `client_cert_error: client_cert_validation_search_limit_exceeded` `client_cert_sha256_fingerprint: <cert hash>`
Configurou o mTLS sem configurar um recurso `TrustConfig`. Não é possível realizar a validação, mas o hash do certificado é encaminhado para o back-end.	`ALLOW_INVALID_OR_MISSING_CLIENT_CERT`	`client_cert_present: true` `client_cert_chain_verified: false` `client_cert_error: client_cert_validation_not_performed` `client_cert_sha256_fingerprint: <cert hash>`
Nenhum certificado de cliente.	`ALLOW_INVALID_OR_MISSING_CLIENT_CERT`	`client_cert_present: false` `client_cert_chain_verified: false` `client_cert_error: client_cert_not_provided` `client_cert_sha256_fingerprint: <empty>`
O certificado de cliente falha a validação em relação ao recurso `TrustConfig`.	`ALLOW_INVALID_OR_MISSING_CLIENT_CERT`	`client_cert_present: true` `client_cert_chain_verified: false` `client_cert_error: client_cert_validation_failed` `client_cert_sha256_fingerprint: <cert hash>`
O certificado de cliente passa na validação do validador de certificados.	Não aplicável	`client_cert_present: true` `client_cert_chain_verified: true` `client_cert_error: <empty>` `client_cert_sha256_fingerprint: <cert hash>` `client_cert_serial_number: <serial_number>` `client_cert_valid_not_before: <date>` `client_cert_valid_not_after: <date>` `client_cert_uri_sans: <list>` `client_cert_dnsname_sans: <list>` `client_cert_issuer_dn: <issuer>` `client_cert_subject_dn: <subject>` `client_cert_leaf: <certificate>` `client_cert_chain: <list>`

Analise os valores das variáveis de cabeçalho personalizadas transmitidos ao back-end

Alguns valores de variáveis de cabeçalho mTLS personalizadas são representações de strings codificadas em Base64 de dados de certificados de regras de codificação distintas (DER) binários. Pode descodificar strings codificadas em Base64 usando as bibliotecas de software ou as ferramentas da sua escolha. Seguem-se alguns exemplos:

Os sistemas macOS e Linux podem usar a ferramenta de linha de comandos base64, que é um utilitário essencial incluído em ambos os sistemas operativos. Para descodificar strings codificadas como Base64 com a utilidade base64, transmita a string codificada como entrada padrão para o comando base64 e use a flag -d para descodificar a string da seguinte forma:
```
echo BASE_64_ENCODED_STRING | base64 -d
```

O Python inclui o módulo base64, que pode ser usado para descodificar strings codificadas em Base64 da seguinte forma:

import base64
encoded_string=BASE_64_ENCODED_STRING
decoded_string=base64.b64decode(encoded_string).decode()
print(decoded_string) # Note that a newline character (\n) is added to the end of the string.

Processamento de erros e registo

Os balanceadores de carga de aplicações oferecem capacidades de registo detalhadas que lhe permitem monitorizar a validação de certificados de cliente, 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.

Erros registados no modo `REJECT_INVALID`

Se a validação do certificado de cliente falhar e o modo de validação do cliente estiver definido como REJECT_INVALID, a ligação é terminada e os erros são registados no Cloud Logging. Estes erros estão descritos na tabela seguinte.

Estado do certificado de cliente	Erro registado
A cadeia de certificados de cliente é demasiado longa (mais de 10 certificados intermédios incluídos no certificado de cliente).	`client_cert_chain_exceeded_limit`
Um cliente 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.	`client_cert_invalid_rsa_key_size`
Um cliente 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.	`client_cert_unsupported_elliptic_curve_key`
Um cliente ou um certificado intermédio está a usar um algoritmo que não seja RSA ou ECDSA. Não é feita nenhuma validação.	`client_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.	`client_cert_pki_too_large`
Um certificado intermédio fornecido para validação tinha mais de 10 restrições de nomes.	`client_cert_chain_max_name_constraints_exceeded`
O certificado de cliente não tem uma extensão `Extended Key Usage (EKU)` que inclua `clientAuth`.	`client_cert_chain_invalid_eku`
O limite de tempo foi excedido ao tentar validar a cadeia de certificados.	`client_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 cliente. O número máximo de iterações é 100 (certificados examinados para validar a cadeia de certificados de cliente).	`client_cert_validation_search_limit_exceeded`
Configurou o mTLS sem configurar um recurso `TrustConfig`.	`client_cert_validation_not_performed`
O cliente não forneceu o certificado pedido durante a negociação.	`client_cert_not_provided`
O certificado de cliente falha a validação com o recurso `TrustConfig`.	`client_cert_validation_failed`

Erros registados para ligações fechadas

Quando o modo de validação do cliente está definido como ALLOW_INVALID_OR_MISSING_CLIENT_CERT ou REJECT_INVALID, determinados erros resultam em ligações fechadas e são registados no Cloud Logging. Estes erros estão descritos na tabela seguinte.

Estado do certificado de cliente	Pedido	Erro registado
O certificado de cliente não corresponde à assinatura durante a negociação.	Termine o handshake SSL	Nenhum
O serviço não consegue realizar a validação da cadeia de certificados.	Termine a associação	`client_cert_validation_unavailable`
Erro interno ao validar a cadeia de certificados.	Termine a associação	`client_cert_validation_internal_error`
Não foi encontrado nenhum `TrustConfig` correspondente.	Termine a associação	`client_cert_trust_config_not_found`
A carga útil do certificado de cliente (incluindo quaisquer certificados intermédios) é demasiado grande (mais de 16 KB).	Termine a associação	`client_cert_exceeded_size_limit`

Se o registo estiver ativado no serviço de back-end, pode ver os erros registados para ligações fechadas durante a validação do certificado do cliente mTLS.

Limitações

O equilibrador de carga não realiza verificações de revogação em certificados de cliente.
Os equilibradores de carga de aplicações permitem-lhe carregar uma configuração de confiança com uma única loja de confiança, que contém, no máximo: 200 do número combinado de âncoras de confiança e certificados intermédios (o número de certificados intermédios está limitado a 100) e 500 certificados que são adicionados a uma lista de autorizações. Todos os certificados intermédios não podem ter mais de três certificados que partilhem as mesmas informações de assunto e chave pública do assunto. Para mais informações, consulte Quotas e limites.
A profundidade máxima de uma cadeia de certificados é de dez, incluindo os certificados raiz e de cliente. O número máximo de vezes que os certificados intermédios podem ser avaliados ao tentar criar a cadeia de confiança é 100. Para mais informações, consulte o artigo Quotas e limites.
As chaves dos certificados carregados e transmitidos a partir do cliente estão restritas ao seguinte:
- As chaves RSA podem variar entre 2048 e 4096 bits. Para mais informações, consulte o artigo Quotas e limites.
- As chaves ECDSA podem usar as curvas P-256 ou P-384.
A cadeia de certificados aceite recebida do cliente está limitada a um máximo de 16 KB e 10 certificados. Para mais informações, consulte o artigo Quotas e limites.
Os certificados de raiz usados para validação não podem conter mais de 10 restrições de nomes. Para mais informações, consulte o artigo Quotas e limites.
A camada 1 dos front-ends da Google (GFEs) aplica um limite de tempo não configurável de 10 segundos para o cliente apresentar o respetivo certificado durante o handshake TLS. Em condições de carga máxima, este limite de tempo pode ser mais curto. Os clientes têm de concluir a apresentação do certificado dentro deste período para estabelecer com êxito uma ligação mTLS.