Informações gerais sobre o TLS e o mTLS autenticados no back-end

Quando um balanceador de carga se conecta a back-ends que estão em Google Cloud, ele aceita qualquer certificado apresentado pelos back-ends. Nesses casos, o balanceador de carga não realiza nenhuma validação de certificado.

Com a autenticação de TLS ou de back-end, o balanceador de carga pode verificar a identidade dos back-ends aos quais ele se conecta. E com o mTLS de back-end, o balanceador de carga pode provar a identidade dele aos back-ends usando um certificado TLS de cliente.

O diagrama a seguir mostra a diferença entre o mTLS do front-end e do back-end, com foco no papel do balanceador de carga em cada caso. No mTLS do front-end, o balanceador de carga atua como o servidor, verificando a identidade do cliente. No mTLS de back-end, o balanceador de carga atua como o cliente, provando sua identidade para o back-end.

mTLS de front-end e back-end.
mTLSs de front-end e back-end (clique para ampliar).

O mTLS opera de forma independente no front-end e no back-end. É possível configurar o mTLS no front-end, no back-end ou em ambos.

Este documento apresenta uma visão geral do TLS autenticado de back-end e da mTLS de back-end. Para saber mais sobre o mTLS de front-end, consulte Visão geral do TLS mútuo.

O TLS autenticado e o mTLS de back-end podem ser configurados no recurso de serviço de back-end dos balanceadores de carga de aplicativo externos globais.

Recursos

A mTLS usa a infraestrutura de chave pública (PKI) para autenticar a identidade das entidades que se comunicam pela rede. A infraestrutura inclui três componentes: um cliente, um servidor e uma autoridade de certificação (AC). O TLS autenticado e o mTLS de back-end adicionam os seguintes recursos aos balanceadores de carga de aplicativo:

  • O balanceador de carga pode validar certificados apresentados por back-ends com suas próprias âncoras de confiança. É possível fazer upload de várias âncoras de confiança para permitir a migração perfeita de uma ICP anterior para uma nova sem tempo de inatividade.

  • O balanceador de carga pode validar certificados TLS de back-ends em relação a raízes de confiança públicas (ICP da Web).

  • É possível configurar certificados intermediários além dos pontos de confiança para ajudar a criar o caminho de validação de certificado do back-end. O uso de certificados intermediários significa que os servidores de back-end não precisam fornecer a cadeia de certificados completa.

  • É possível configurar um nome de host de indicação de nome do servidor (SNI) TLS para seu serviço de back-end. Durante o handshake TLS, o balanceador de carga inclui esse nome de host SNI na mensagem ClientHello que envia ao back-end. O back-end responde com o certificado TLS, e o balanceador de carga verifica se pelo menos um dos campos de nome alternativo do sujeito (SAN) do certificado corresponde ao nome do host ou a qualquer um dos campos SAN configurados para o serviço de back-end.

  • É possível configurar o serviço de back-end do balanceador de carga para usar mTLS, para que ele possa provar sua identidade aos back-ends. Essa autenticação é realizada usando 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, verifique se eles atendem a estes requisitos:

  • As ferramentas de criptografia modernas formam a base da autenticação mTLS. Os certificados precisam usar algoritmos RSA ou ECDSA para troca de chaves. Os algoritmos de hash precisam usar SHA-256 ou uma função de hash criptográfico mais forte. Algoritmos de hash como MD4, MD5 e SHA-1 não são aceitos.

  • Os certificados de servidor de folha fornecidos pelo back-end têm os seguintes requisitos:

  • Para certificados de cliente de folha (balanceador de carga) usados no mTLS de back-end, o certificado precisa ser um recurso de certificado do Gerenciador de certificados. O escopo desse certificado precisa ser client-auth, o que indica que ele é usado como um certificado de cliente no mTLS de back-end.

  • Os certificados raiz e intermediários usados com o TLS autenticado de back-end têm os seguintes requisitos:

    • A extensão Basic Constraints precisa conter CA=true.
    • A extensão Key Usage precisa ser definida como keyCertSign.
    • A extensão Extended Key Usage precisa conter o campo serverAuth.
    • O certificado não pode estar expirado.

Principais componentes do TLS autenticado de back-end e do mTLS de back-end

Com o TLS autenticado de back-end, o balanceador de carga pode verificar a identidade dos back-ends aos quais ele se conecta. É possível configurar o TLS autenticado de back-end em um balanceador de carga HTTP(S) que usa HTTPS ou HTTP/2 como protocolo de serviço de back-end. Se você não configurar o TLS autenticado do back-end, o balanceador de carga aceita qualquer certificado do back-end. Usando o mTLS de back-end, você também pode configurar o balanceador de carga para apresentar o próprio certificado do cliente ao back-end, que pode ser usado para autenticar o balanceador de carga.

Para configurar o TLS autenticado de back-end, faça 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 configuraçã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, é necessário criar um certificado do cliente e anexá-lo ao recurso de configuração de autenticação de back-end. Não é possível anexar o certificado do cliente depois que o recurso de configuração de autenticação de back-end é criado.

O diagrama a seguir mostra os diferentes componentes, anexados ao serviço de back-end de um balanceador de carga de aplicativo, que ativam o TLS autenticado de back-end e o mTLS de back-end.

Componentes de mTLS e TLS autenticados de back-end.
Componentes de TLS e mTLS autenticados de back-end (clique para ampliar).

As informações a seguir fornecem uma visão geral desses componentes diferentes usados para configurar o TLS autenticado de back-end e o mTLS de back-end.

Configuração de confiança

Para autenticar os certificados do servidor que o back-end apresenta ao balanceador de carga, ele precisa ser configurado com certificados X.509 que estabeleçam uma cadeia de confiança para o emissor do certificado do back-end. Você configura a configuração de confiança usando um recurso TrustConfig, que expressa toda a configuração de confiança e contém um único repositório de confiança.

Um repositório de confiança encapsula uma âncora de confiança (certificado raiz) e, opcionalmente, um ou mais certificados intermediários. Uma âncora de confiança é um certificado que representa uma raiz de confiança. Um certificado de servidor válido precisa mostrar uma cadeia de confiança de volta para alguma âncora de confiança na loja de confiança.

Um certificado intermediário é um certificado que faz parte de uma cadeia de confiança que leva de volta a uma âncora de confiança no repositório de confiança. Ele é usado, junto com qualquer AC intermediária adicional incluída no certificado de folha, para criar a cadeia de confiança durante o processo de validação. A criação de um certificado intermediário é opcional.

Se você precisar usar um certificado autoassinado, expirado, que não seja vinculado a uma raiz de confiança especificada ou que tenha falhado na validação, adicione esse certificado a uma lista de permissões na configuração de confiança. A criação de um certificado autoassinado que pode ser adicionado a uma lista de permissões também é opcional.

O armazenamento de confiança não contém chaves privadas porque apenas os certificados são necessários para verificar uma cadeia de confiança.

Recurso de configuração de autenticação de back-end

O recurso de configuração de autenticação de back-end (BackendAuthenticationConfig), anexado ao serviço de back-end do balanceador de carga, permite o seguinte:

  • TLS autenticado de back-end (usando a configuração de confiança e as raízes de confiança públicas)
  • mTLS de back-end (usando o certificado do cliente)

Para ativar o TLS autenticado e o mTLS de back-end, o recurso de configuração de autenticação de back-end 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 confiança públicas (wellKnownRoots): indica se o balanceador de carga confia em certificados do servidor de back-end emitidos por ACs públicas, além de certificados confiáveis pela configuração de confiança. Para saber mais, consulte Como usar raízes de confiança públicas.

  • Certificado do cliente (clientCertificate): o certificado do cliente que o balanceador de carga usa para expressar a identidade ao back-end, se a conexão com o back-end usar mTLS. Para TLS autenticado de back-end (autenticação de back-end), esse campo pode estar vazio. Nesse caso, o balanceador de carga só autentica o back-end, mas não a si mesmo, para o 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 de back-end (authenticationConfig)
  • Nome do host SNI (sni)
  • SANs aceitos (subjectAltNames)

Os campos SNI (sni) e SAN (subjectAltNames) no atributo tlsSettings controlam como o balanceador de carga valida o certificado do back-end com base nos valores do SAN do certificado. Esses campos influenciam o processo de validação, independentemente de o TLS autenticado de back-end estar configurado.

Quando o campo SNI está definido (tlsSettings.sni), o balanceador de carga faz o seguinte:

  • Envia o nome do host SNI para o servidor de back-end durante o handshake de TLS.
  • Verifica se o certificado TLS do back-end inclui um SAN que corresponde ao nome do host SNI.

Por padrão, o balanceador de carga verifica se o certificado TLS do back-end inclui um SAN que corresponde ao nome de host SNI. No entanto, se os SANs forem configurados no serviço de back-end (tlsSettings.subjectAltNames), o balanceador de carga fará o seguinte:

  • Ignora o nome do host SNI para a verificação de SAN.
  • Verifica se o certificado TLS do back-end inclui um SAN que corresponde a um dos SANs aceitos (subjectAltNames) configurados no serviço de back-end.

Certificado do cliente

Além do TLS autenticado de back-end (autenticação de back-end), é possível configurar o serviço de back-end de um balanceador de carga para usar mTLS, para que o balanceador de carga possa provar sua identidade para o back-end. Essa autenticação usa um certificado de cliente (balanceador de carga) que o balanceador de carga apresenta ao back-end.

Para configurar o mTLS do back-end, faça o seguinte:

  • Crie um recurso de certificado do cliente que contenha o certificado do cliente (balanceador de carga) e a chave privada dele.
  • Anexe o certificado do cliente ao recurso de configuração de autenticação de back-end.

O mTLS de back-end também é compatível com as identidades de carga de trabalho gerenciadas pelo Compute Engine quando você configura certificados gerenciados pelo Gerenciador de certificados. Não há suporte para certificados gerenciados por PKI público, e todos os certificados do cliente precisam ter um escopo client-auth e obedecer aos requisitos de certificado.

Se o back-end solicitar um certificado do cliente, ele precisará ser configurado para aceitar o certificado do cliente. Se o back-end recusar a conexão do balanceador de carga, ele retornará um código de status HTTP 502 para solicitações que estão fazendo proxy e registrará um status genérico no Cloud Logging.

Configurar o TLS e o mTLS autenticados do back-end no balanceador de carga

É possível configurar o TLS autenticado e o mTLS no back-end no balanceador de carga usando uma PKI privada ou raízes de confiança públicas.

Usar ICP privada

Confira a seguir uma visão geral de alto nível das principais etapas que você precisa seguir para configurar o TLS autenticado e o mTLS no back-end no balanceador de carga usando certificados emitidos pela PKI particular. A PKI privada tem a vantagem de estar totalmente sob seu controle e isolada dos sistemas de PKI da Internet pública.

  1. Crie um recurso de configuração de confiança que inclua a âncora de confiança (certificado raiz) e certificados intermediários que servem como raízes de confiança.

  2. Para configurar o mTLS de back-end, crie um certificado de cliente contendo o certificado do cliente (balanceador de carga) e a chave privada dele.

  3. Crie um recurso de configuração de autenticação de back-end que faça referência à configuração de confiança. Se você quiser configurar o mTLS do back-end, o recurso de configuração de autenticação do back-end vai referenciar a configuração de confiança e o certificado do cliente.

  4. Anexe o recurso de configuração de autenticação de back-end ao serviço de back-end do balanceador de carga.

Para saber mais sobre essa configuração, consulte os seguintes guias:

Usar raízes de confiança públicas

Além de usar certificados emitidos pela sua ICP particular para ativar o TLS autenticado de back-end, você também pode usar raízes de confiança públicas para validar o certificado de back-end.

Para usar as raízes de confiança públicas, não é necessário criar uma configuração de confiança e anexá-la ao recurso de configuração de autenticação de back-end. Em vez disso, defina PUBLIC_ROOTS como um valor no campo wellKnownRoots do recurso de configuração de autenticação do back-end. No entanto, você também pode criar uma configuração de confiança que inclua explicitamente as raízes dos certificados emitidos publicamente, além dos certificados confiáveis pela configuração de confiança.

A configuração PUBLIC_ROOTS usa um conjunto de ACs raiz, semelhante ao conjunto de ACs raiz confiáveis pelos navegadores, que é gerenciado pelo Google e pode mudar com o tempo. Isso apresenta o risco de que seus certificados de back-end se tornem inválidos quando essas raízes mudarem. Se você precisar validar certificados emitidos publicamente, escolha uma AC confiável e bem estabelecida que use assinatura cruzada intermediária para emitir seus certificados de back-end e reduzir o risco de um certificado raiz expirar ou ser revogado.

Etapas de validação do certificado do servidor

Ao validar 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:

  1. Verifique se o servidor tem a chave privada do certificado.

    O servidor prova a posse da chave privada associada ao certificado que ele apresenta ao balanceador de carga assinando uma parte das informações usando a chave privada e enviando-a ao balanceador de carga como parte da mensagem CertificateVerify. O balanceador de carga verifica essa assinatura usando a chave pública do certificado do servidor. Se a verificação de assinatura falhar, isso indica que o servidor de back-end não possui a chave privada correspondente ao certificado. Nesses casos, o balanceador de carga encerra o handshake de TLS sem registrar erros.

  2. Verifique a cadeia de confiança.

    Se a configuração de confiança incluir pelo menos uma âncora de confiança ou tiver o atributo wellKnownRoots definido como PUBLIC_ROOTS, o balanceador de carga tentará verificar uma cadeia de confiança entre o certificado do servidor e a âncora de confiança configurada. As verificações de verificação incluem:

    • O certificado do servidor do back-end, os certificados intermediários (se fornecidos) e o certificado 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 pai corresponde ao campo de emissor no certificado filho. Essa verificação ajuda a garantir que a identidade (assunto) do certificado pai seja a mesma que a identidade listada como emissor no certificado filho.
    • Para todos os certificados na cadeia de confiança, o identificador de chave de assunto (SKID, na sigla em inglês) do certificado pai corresponde ao identificador de chave de autoridade (AKID, na sigla em inglês) no certificado filho. Essa correspondência confirma que o certificado filho foi emitido pela autoridade raiz correta e que ele pode ser confiável porque a chave pública da raiz está sendo referenciada no AKID para verificar a validade do certificado.

  3. Estabeleça uma conexão com o back-end.

    Se a validação do certificado for bem-sucedida, o balanceador de carga vai prosseguir com a conexão ao back-end.

    No entanto, se a validação do certificado falhar, o balanceador de carga encerrará a conexão com o back-end, enviará um código de status 502 HTTP para o cliente e registrará o motivo do encerramento no Cloud Logging. Em caso de erro de validação de certificado, as solicitações de entrada subsequentes acionam o balanceador de carga para reiniciar a conexão do back-end.

    A conexão de back-end também pode falhar se o servidor de back-end recusar a conexão. Com o mTLS de back-end, isso pode acontecer porque o certificado do cliente é considerado inválido. Quando a conexão com o back-end falha, o balanceador de carga responde a solicitações de proxy com um código de status HTTP 502 e registra um motivo de erro genérico no Cloud Logging.

Limitações

  • O TLS autenticado de back-end e o mTLS de back-end só podem ser configurados para balanceadores de carga de aplicativo externos globais. Os balanceadores de carga de aplicativo clássicos não oferecem suporte a TLS autenticado e mTLS de back-end.

  • O TLS autenticado e o mTLS de back-end não são compatíveis com os seguintes tipos de back-end:

    • Back-ends de NEG globais da Internet

    • Backends do App Engine

  • Para ativar o mTLS de back-end, você também precisa configurar o TLS autenticado de back-end.

  • Se você quiser ativar o mTLS de back-end, crie o certificado do cliente antes de configurar o recurso de configuração de autenticação de back-end.

  • As verificações de integridade usadas pelos back-ends não implementam a autenticação TLS ou os recursos mTLS. É necessário configurar os back-ends com endpoints de verificação de integridade que possam responder a solicitações HTTP ou HTTPS.

  • O balanceador de carga não transmite o nome de host SNI do cliente da conexão TLS do front-end ao se conectar a um back-end. No entanto, os back-ends podem acessar o nome de host do SNI do cliente usando um cabeçalho de solicitação personalizado.

  • Para mTLS de back-end, as chaves de certificado do cliente são restritas a isto:

    • As chaves RSA podem variar de 2.048 a 4.096 bits.
    • As chaves ECDSA podem usar as curvas P-256 ou P-384.

  • O TLS autenticado de back-end não oferece suporte a verificações de revogação de certificados.

Cotas e limites

  • Um único armazenamento de confiança pode conter até 200 âncoras de confiança e certificados intermediários combinados, com um limite separado de 100 para certificados intermediários. Não é possível compartilhar as mesmas informações de Assunto e de Chave pública do assunto em mais de três certificados intermediários.

  • A profundidade máxima de uma cadeia de certificados é de 10 certificados, incluindo os certificados raiz e de folha. O número máximo de certificados intermediários que podem ser avaliados ao tentar criar a cadeia de confiança é 100.

  • O TLS autenticado do back-end limita a cadeia de certificados recebida do back-end a no máximo 16 KB e 10 certificados.

  • Os certificados raiz usados para validação não podem conter mais de 10 restrições de nome.

  • O número máximo de nomes alternativos de assunto permitidos no campo tlsSettings.subjectAltNames[] é 5.

A seguir