Présentation du TLS authentifié et du mTLS backend

Lorsqu'un équilibreur de charge se connecte à des backends situés dans Google Cloud, il accepte tous les certificats présentés par vos backends. Dans ce cas, l'équilibreur de charge n'effectue aucune validation de certificat.

Avec le TLS authentifié par le backend ou l'authentification du backend, l'équilibreur de charge peut vérifier l'identité des backends auxquels il se connecte. Avec l'authentification mTLS du backend, l'équilibreur de charge peut également prouver son identité aux backends à l'aide d'un certificat TLS client.

Le diagramme suivant montre la différence entre le protocole mTLS côté client et côté serveur, en mettant l'accent sur le rôle de l'équilibreur de charge dans chaque cas. Dans mTLS côté client, l'équilibreur de charge agit en tant que serveur, vérifiant l'identité du client. Dans le mTLS backend, l'équilibreur de charge agit en tant que client, prouvant son identité au backend.

mTLS du front-end et du backend
mTLS de front-end et de backend (cliquez pour agrandir).

Le mTLS fonctionne indépendamment sur le frontend et le backend. Vous pouvez configurer le mTLS sur l'interface, le backend ou les deux.

Ce document présente le TLS authentifié côté backend ainsi que le mTLS côté backend. Pour en savoir plus sur le mTLS de l'interface, consultez la présentation du protocole TLS mutuel.

Le TLS authentifié de backend et le mTLS de backend peuvent être configurés sur la ressource de service de backend des équilibreurs de charge d'application externes globaux.

Fonctionnalités

mTLS utilise une infrastructure à clé publique (PKI) pour authentifier l'identité des entités qui communiquent sur le réseau. L'infrastructure comprend trois composants: un client, un serveur et une autorité de certification (AC). Le TLS authentifié côté backend et le mTLS côté backend ajoutent les fonctionnalités suivantes aux équilibreurs de charge d'application:

  • L'équilibreur de charge peut valider les certificats présentés par les backends par rapport à vos propres points d'ancrage de confiance. Vous pouvez importer plusieurs ancres de confiance pour faciliter la migration d'une ancienne PKI vers une nouvelle sans temps d'arrêt.

  • L'équilibreur de charge peut valider les certificats TLS des backends par rapport aux racines de confiance publiques (PKI Web).

  • Vous pouvez configurer des certificats intermédiaires en plus de vos ancrages de confiance pour créer le chemin de validation du certificat du backend. L'utilisation de certificats intermédiaires signifie que vos serveurs backend n'ont pas besoin de fournir la chaîne de certificats complète.

  • Vous pouvez configurer un nom d'hôte TLS pour l'indication du nom du serveur (SNI) de votre service backend. Lors du handshake TLS, l'équilibreur de charge inclut ce nom d'hôte SNI dans le message ClientHello qu'il envoie au backend. Le backend répond ensuite avec son certificat TLS, et l'équilibreur de charge vérifie qu'au moins un des champs SAN (Subject Alternative Name) de ce certificat correspond au nom d'hôte ou à l'un des champs SAN configurés pour le service backend.

  • Vous pouvez configurer le service de backend de votre équilibreur de charge pour qu'il utilise mTLS afin que l'équilibreur de charge puisse prouver son identité aux backends. Cette authentification est effectuée à l'aide d'un certificat client (équilibreur de charge) que l'équilibreur de charge présente au backend.

Exigences relatives aux certificats

Lorsque vous configurez des certificats pour le TLS authentifié côté backend et le mTLS côté backend, assurez-vous qu'ils respectent les exigences suivantes:

  • Les outils de cryptographie modernes constituent la base de l'authentification mTLS. Les certificats doivent utiliser des algorithmes RSA ou ECDSA pour l'échange de clés. Les algorithmes de hachage doivent utiliser SHA-256 ou une fonction de hachage cryptographique plus sécurisée. Les algorithmes de hachage tels que MD4, MD5 et SHA-1 ne sont pas acceptés.

  • Les certificats de serveur de feuilles fournis par le backend présentent les exigences suivantes:

  • Pour les certificats de client racine (équilibreur de charge) utilisés dans le mTLS backend, le certificat doit être une ressource de certificat du Gestionnaire de certificats. Le champ d'application de ce certificat doit être client-auth, ce qui indique qu'il est utilisé comme certificat client dans le backend mTLS.

  • Les certificats racine et intermédiaires utilisés avec le protocole TLS authentifié côté backend doivent respecter les exigences suivantes:

Composants clés du TLS authentifié côté backend et du mTLS côté backend

Avec le TLS authentifié côté backend, l'équilibreur de charge peut vérifier l'identité des backends auxquels il se connecte. Vous pouvez configurer le TLS authentifié de backend sur un équilibreur de charge HTTP(S) qui utilise HTTPS ou HTTP/2 comme protocole de service de backend. Si vous ne configurez pas le TLS authentifié du backend, l'équilibreur de charge accepte tous les certificats du backend. À l'aide de l'authentification mTLS du backend, vous pouvez également configurer l'équilibreur de charge pour qu'il présente son propre certificat client au backend, qui peut l'utiliser pour authentifier l'équilibreur de charge.

Pour configurer le TLS authentifié côté backend, procédez comme suit:

  • Créez une ressource de configuration de confiance.
  • Créez une ressource Backend Authentication Config.
  • Mettez à jour l'attribut de paramètre TLS sur le service de backend, en le pointant vers la ressource de configuration de l'authentification du backend.

Pour configurer le mTLS du backend, vous devez créer un certificat client et l'associer à la ressource de configuration de l'authentification du backend. Vous ne pouvez pas joindre le certificat client une fois la ressource de configuration d'authentification de backend créée.

Le schéma suivant montre les différents composants, associés au service backend d'un équilibreur de charge d'application, qui permettent d'activer le TLS authentifié et le mTLS backend.

Composants TLS et mTLS authentifiés côté backend
Composants TLS et mTLS authentifiés côté backend (cliquez pour agrandir).

Les informations suivantes présentent ces différents composants utilisés pour configurer le TLS authentifié côté backend et le mTLS côté backend.

Configuration de confiance

Pour authentifier les certificats de serveur que votre backend présente à l'équilibreur de charge, l'équilibreur de charge doit être configuré avec des certificats X.509 qui établissent une chaîne de confiance avec l'émetteur du certificat du backend. Vous configurez la configuration d'approbation à l'aide d'une ressource TrustConfig, qui exprime l'ensemble de la configuration d'approbation et contient un seul magasin de confiance.

Un magasin de confiance encapsule une ancre de confiance (certificat racine) et, éventuellement, un ou plusieurs certificats intermédiaires. Une ancre de confiance est un certificat représentant une racine de confiance. Un certificat de serveur valide doit présenter une chaîne de confiance remontant à un ancrage de confiance dans le magasin de confiance.

Un certificat intermédiaire fait partie d'une chaîne de confiance qui mène à une ancre de confiance dans le magasin de confiance. Il est utilisé, avec d'autres autorités de certification intermédiaires incluses avec le certificat de fin de chaîne, pour créer la chaîne de confiance lors du processus de validation. La création d'un certificat intermédiaire est facultative.

Si vous devez utiliser un certificat autosigné, expiré, qui ne s'enchaîne pas à une racine de confiance spécifiée ou dont la validation a échoué, vous pouvez ajouter un tel certificat à une liste d'autorisation dans la configuration de confiance. La création d'un certificat autosigné pouvant être ajouté à une liste d'autorisation est également facultative.

Le magasin de confiance ne contient aucune clé privée, car seuls les certificats sont nécessaires pour valider une chaîne de confiance.

Ressource de configuration d'authentification de backend

La ressource de configuration d'authentification de backend (BackendAuthenticationConfig), associée au service de backend de l'équilibreur de charge, permet les opérations suivantes:

  • TLS authentifié côté backend (à l'aide de la configuration de confiance et des racines de confiance publiques)
  • mTLS backend (à l'aide du certificat client)

Pour activer le TLS authentifié et le mTLS du backend, la ressource Backend Authentication Config pointe vers les ressources suivantes:

  • Configuration de confiance (trustConfig) : configuration de confiance associée utilisée pour valider le certificat de serveur fourni par le backend.

  • Racines de confiance publiques (wellKnownRoots) : indique si l'équilibreur de charge approuve les certificats de serveur backend émis par des autorités de certification publiques, en plus des certificats approuvés par la configuration de confiance. Pour en savoir plus, consultez Utiliser des racines de confiance publiques.

  • Certificat client (clientCertificate) : certificat client utilisé par l'équilibreur de charge pour exprimer son identité auprès du backend, si la connexion au backend utilise mTLS. Pour le TLS authentifié côté backend (authentification côté backend), ce champ peut être vide, auquel cas l'équilibreur de charge n'authentifie que le backend, mais pas lui-même, auprès du backend.

Service de backend

Dans le service backend, l'attribut tlsSettings pointe vers les ressources suivantes afin de valider le certificat backend.

  • Configuration d'authentification de backend (authenticationConfig)
  • Nom d'hôte SNI (sni)
  • SAN acceptés (subjectAltNames)

Les champs SNI (sni) et SAN (subjectAltNames) de l'attribut tlsSettings contrôlent la manière dont l'équilibreur de charge valide le certificat du backend en fonction des valeurs SAN du certificat. Ces champs influencent le processus de validation, que le TLS authentifié du backend soit configuré ou non.

Lorsque le champ SNI est défini (tlsSettings.sni), l'équilibreur de charge effectue les opérations suivantes:

  • Envoie le nom d'hôte SNI au serveur backend lors du handshake TLS.
  • Vérifie que le certificat TLS du backend inclut un SAN correspondant au nom d'hôte SNI.

Par défaut, l'équilibreur de charge vérifie que le certificat TLS du backend inclut un SAN correspondant au nom d'hôte SNI. Toutefois, si des SAN sont configurés sur le service de backend (tlsSettings.subjectAltNames), l'équilibreur de charge procède comme suit:

  • Ignore le nom d'hôte SNI pour la validation du SAN.
  • Vérifie que le certificat TLS du backend inclut un SAN correspondant à l'un des SAN acceptés (subjectAltNames) configurés sur le service de backend.

Certificat client

En plus du TLS authentifié par le backend (authentification du backend), vous pouvez configurer le service de backend d'un équilibreur de charge pour qu'il utilise mTLS, afin que l'équilibreur de charge puisse prouver son identité au backend. Cette authentification utilise un certificat client (équilibreur de charge) que l'équilibreur de charge présente au backend.

Pour configurer le mTLS backend, procédez comme suit:

  • Créez une ressource de certificat client contenant le certificat du client (équilibreur de charge) et sa clé privée.
  • Associez le certificat client à la ressource de configuration d'authentification du backend.

Le mTLS backend est également compatible avec les identités de charge de travail gérées Compute Engine lorsque vous configurez des certificats gérés via le Gestionnaire de certificats. Les certificats gérés par une PKI publique ne sont pas acceptés. Tous les certificats client doivent avoir une portée client-auth et être conformes aux exigences relatives aux certificats.

Si le backend demande un certificat client, il doit être configuré pour l'accepter. Si le backend refuse la connexion de l'équilibreur de charge, l'équilibreur de charge renvoie un code d'état HTTP 502 pour les requêtes qu'il proxy et consigne un état générique dans Cloud Logging.

Configurer TLS authentifié et mTLS authentifié côté backend sur l'équilibreur de charge

Vous pouvez configurer le protocole TLS authentifié et le protocole mTLS authentifié sur l'équilibreur de charge à l'aide d'une PKI privée ou de racines de confiance publiques.

Utiliser une PKI privée

Vous trouverez ci-dessous une présentation générale des principales étapes à suivre pour configurer le TLS authentifié côté backend et le mTLS côté backend sur votre équilibreur de charge à l'aide de certificats émis par votre PKI privée. La PKI privée présente l'avantage d'être entièrement sous votre contrôle et d'être isolée des systèmes PKI de l'Internet public.

  1. Créez une ressource de configuration de confiance comprenant l'ancre de confiance (certificat racine) et les certificats intermédiaires qui servent de racines de confiance.

  2. Pour configurer l'authentification mTLS du backend, créez un certificat client contenant le certificat client (équilibreur de charge) et sa clé privée.

  3. Créez une ressource de configuration d'authentification de backend qui fait référence à la configuration de confiance. Si vous souhaitez configurer mTLS côté backend, la ressource "Backend Authentication Config" (Configuration d'authentification du backend) fait référence à la fois à la configuration de confiance et au certificat client.

  4. Associez la ressource de configuration de l'authentification de backend au service de backend de l'équilibreur de charge.

Pour en savoir plus sur cette configuration, consultez les guides suivants:

Utiliser des racines de confiance publiques

En plus d'utiliser des certificats émis par votre PKI privée pour activer le TLS authentifié du backend, vous pouvez également utiliser des racines de confiance publiques pour valider le certificat du backend.

Pour utiliser des racines de confiance publiques, vous n'avez pas besoin de créer une configuration de confiance et de l'associer à la ressource de configuration d'authentification du backend. Vous devez plutôt définir PUBLIC_ROOTS comme valeur dans le champ wellKnownRoots de la ressource de configuration de l'authentification backend. Toutefois, vous pouvez également créer une configuration de confiance qui inclut explicitement les racines de vos certificats émis publiquement, en plus des certificats approuvés par la configuration de confiance.

Le paramètre PUBLIC_ROOTS utilise un ensemble d'autorités de certification racine, semblable à l'ensemble d'autorités de certification racine approuvées par les navigateurs, qui est géré par Google et peut changer au fil du temps. Cela présente le risque que vos certificats backend deviennent non valides lorsque ces racines changent. Si vous devez valider des certificats émis publiquement, envisagez de choisir une autorité de certification bien établie et fiable, qui utilise la signature croisée intermédiaire pour émettre vos certificats backend afin de réduire le risque d'expiration ou de révocation d'un certificat racine.

Étapes de validation du certificat de serveur

Lors de la validation du certificat de serveur lors du TLS authentifié par le backend ou de l'authentification du backend, l'équilibreur de charge procède comme suit:

  1. Vérifiez que le serveur possède la clé privée du certificat.

    Le serveur prouve qu'il possède la clé privée associée au certificat qu'il présente à l'équilibreur de charge en signant un élément d'information à l'aide de sa clé privée et en l'envoyant à l'équilibreur de charge dans le message CertificateVerify. L'équilibreur de charge valide ensuite cette signature à l'aide de la clé publique du certificat du serveur. Si la validation de la signature échoue, cela signifie que le serveur backend ne possède pas la clé privée correspondant au certificat. Dans ce cas, l'équilibreur de charge interrompt le handshake TLS sans enregistrer d'erreurs.

  2. Vérifiez la chaîne de confiance.

    Si la configuration de confiance inclut au moins une ancre de confiance ou si l'attribut wellKnownRoots est défini sur PUBLIC_ROOTS, l'équilibreur de charge tente de valider une chaîne de confiance entre le certificat du serveur et l'ancre de confiance configurée. Les vérifications de validation incluent les éléments suivants:

    • Le certificat de serveur du backend, les certificats intermédiaires (le cas échéant) et le certificat racine configuré sont conformes aux exigences relatives aux certificats.
    • Pour tous les certificats de la chaîne de confiance, le champ d'objet du certificat parent correspond au champ d'émetteur du certificat enfant. Cette vérification permet de s'assurer que l'identité (objet) du certificat parent est identique à celle indiquée comme émetteur dans le certificat enfant.
    • Pour tous les certificats de la chaîne de confiance, l'identifiant de la clé de l'objet (SKID) du certificat parent correspond à l'identifiant de la clé d'autorité (AKID) du certificat enfant. Cette correspondance confirme que le certificat enfant a été émis par l'autorité racine appropriée et qu'il peut être approuvé, car la clé publique de la racine est référencée dans l'AKID pour valider la validité du certificat.

  3. Établissez une connexion avec le backend.

    Si la validation du certificat réussit, l'équilibreur de charge établit la connexion au backend.

    Toutefois, si la validation du certificat échoue, l'équilibreur de charge interrompt la connexion au backend, envoie un code d'état HTTP 502 au client et consigne la raison de l'interruption dans Cloud Logging. En cas d'erreur de validation de certificat, les requêtes entrantes suivantes déclenchent la réinitialisation de la connexion backend par l'équilibreur de charge.

    La connexion backend peut également échouer si le serveur backend refuse la connexion. Avec l'authentification mTLS côté backend, cela peut se produire si le certificat client est invalide. Lorsque la connexion au backend échoue, l'équilibreur de charge répond aux requêtes proxy avec un code d'état HTTP 502 et consigne une raison d'erreur générique dans Cloud Logging.

Limites

  • Le protocole TLS authentifié côté backend et le protocole mTLS côté backend ne peuvent être configurés que pour les équilibreurs de charge d'application externes globaux. Les équilibreurs de charge d'application classiques ne sont pas compatibles avec le TLS authentifié du backend ni le mTLS du backend.

  • Le TLS authentifié côté backend et le mTLS côté backend ne sont pas compatibles avec les types de backend suivants:

    • Backends NEG Internet globaux

    • Backends App Engine

  • Pour activer le mTLS du backend, vous devez également configurer le TLS authentifié du backend.

  • Si vous souhaitez activer mTLS côté backend, vous devez créer le certificat client avant de configurer la ressource de configuration d'authentification backend.

  • Les vérifications de l'état utilisées par les backends n'implémentent pas l'authentification TLS ni les fonctionnalités mTLS. Vous devez configurer les backends avec des points de terminaison de vérification de l'état pouvant répondre aux requêtes HTTP ou HTTPS.

  • L'équilibreur de charge ne transmet pas le nom d'hôte SNI du client à partir de la connexion TLS du frontend lors de la connexion à un backend. Toutefois, les backends peuvent accéder au nom d'hôte SNI du client à l'aide d'un en-tête de requête personnalisé.

  • Pour le mTLS backend, les clés de certificat client sont limitées aux éléments suivants:

    • Les clés RSA peuvent aller de 2 048 à 4 096 bits.
    • Les clés ECDSA peuvent utiliser les courbes P-256 ou P-384.

  • Le TLS authentifié côté backend n'est pas compatible avec les vérifications de révocation de certificat.

Quotas et limites

  • Un seul magasin de confiance peut contenir jusqu'à 200 ancres de confiance et certificats intermédiaires combinés, avec une limite distincte de 100 pour les certificats intermédiaires. Pas plus de trois certificats intermédiaires ne peuvent partager les mêmes informations "Objet" et "Clé publique de l'objet".

  • La profondeur maximale d'une chaîne de certificats est de 10 certificats, y compris les certificats racine et feuille. Le nombre maximal de certificats intermédiaires pouvant être évalués lors de la tentative de création de la chaîne de confiance est de 100.

  • Le TLS authentifié côté backend limite la chaîne de certificats reçue du backend à 16 Ko et à 10 certificats maximum.

  • Les certificats racines utilisés pour la validation ne peuvent pas contenir plus de 10 contraintes de nom.

  • Le nombre maximal d'autres noms d'objet autorisé dans le champ tlsSettings.subjectAltNames[] est de cinq.

Étape suivante