Autoriser via des certificats SSL/TLS

Cette page explique comment utiliser Secure Socket Layer (SSL), désormais Transport Layer Security (TLS), à partir de votre application pour chiffrer les connexions aux instances Cloud SQL.

Présentation

Cloud SQL est compatible avec la connexion à une instance à l'aide du protocole SSL/TLS. Les connexions SSL/TLS offrent une couche de sécurité en chiffrant les données en transit entre votre client et la base de données de votre instance Cloud SQL. Vous pouvez également configurer votre connexion SSL/TLS pour qu'elle effectue la validation de l'identité du serveur en validant le certificat de serveur installé sur l'instance Cloud SQL et la validation de l'identité du client en validant le certificat client installé sur le client.

Certificats du serveur

Lorsque vous créez une instance, Cloud SQL crée et installe automatiquement un certificat de serveur signé par une autorité de certification. Vous pouvez télécharger le certificat CA sur la machine hôte du client et l'utiliser pour vérifier l'identité de la CA et du serveur Cloud SQL. Vous pouvez également choisir le type de CA que Cloud SQL utilise pour signer le certificat de serveur.

Certificats clients

Vous pouvez également créer et télécharger des certificats clients avec des clés sur la machine hôte du client pour l'authentification mutuelle (validation de l'identité du serveur et du client). Vous ne pouvez pas choisir le type de CA que Cloud SQL utilise pour signer le certificat client.

Se connecter à l'aide de SSL/TLS

Lorsque vous vous connectez à une instance Cloud SQL à partir de clients, vous pouvez utiliser SSL/TLS pour les connexions directes, ainsi que pour les connexions qui utilisent le proxy d'authentification Cloud SQL ou les connecteurs de langage Cloud SQL.

  • Pour les connexions directes, Google vous recommande vivement d'appliquer le chiffrement SSL/TLS à l'aide du paramètre de mode SSL dans Cloud SQL. Vous pouvez également appliquer la validation du certificat client. Pour en savoir plus, consultez Appliquer le chiffrement SSL/TLS.

  • Pour les connexions qui utilisent le proxy d'authentification Cloud SQL ou les connecteurs de langage Cloud SQL, les connexions sont automatiquement chiffrées avec SSL/TLS, et l'identité du client et du serveur est validée sans que vous ayez à télécharger un certificat CA de serveur ni un certificat client.

Pour en savoir plus sur les options de connectivité Cloud SQL, consultez À propos des connexions Cloud SQL.

Pour en savoir plus sur la configuration SSL/TLS côté client, consultez la documentation de votre moteur de base de données.

Hiérarchies d'autorités de certification

Cette section décrit les trois types d'autorités de certification de serveur que vous pouvez choisir pour vos instances Cloud SQL. Vous avez trois possibilités :

  • CA par instance : avec cette option, une CA interne dédiée à chaque instance Cloud SQL signe le certificat de serveur pour cette instance. Cloud SQL crée et gère ces CA. Pour choisir une CA par instance, sélectionnez Autorité de certification interne gérée par Google (Cloud de Confiance console) ou spécifiez GOOGLE_MANAGED_INTERNAL_CA pour le paramètre serverCaMode (API Cloud SQL Admin) ou l'option --server-ca-mode (gcloud CLI) lorsque vous créez l'instance. Si vous ne spécifiez pas le paramètre ou l'option lorsque vous créez une instance, cette option est la valeur par défaut de l'instance. Vous ne pouvez pas mettre à jour une instance pour qu'elle utilise l'option de CA par instance si elle est configurée pour utiliser une CA partagée ou une CA gérée par le client.

  • CA partagée : avec cette option, une hiérarchie de CA composée d'une CA racine et de CA de serveur subordonnées est utilisée. Les CA de serveur subordonnées d'une région signent les certificats de serveur et sont partagées entre les instances de la région. L'utilisation d'une hiérarchie de CA partagée est utile lorsque vous augmentez le nombre d'instances dans une région, car vous n'avez pas besoin de gérer des CA uniques pour les instances individuelles. En passant à une CA partagée (GOOGLE_MANAGED_CAS_CA), vous pouvez utiliser un seul groupe de CA régional pour toutes vos instances de la région, ce qui peut simplifier votre configuration côté client. Cloud SQL héberge et gère la CA racine et les CA de serveur subordonnées sur Cloud de Confiance by S3NS Certificate Authority Service (CA Service). Cloud SQL gère également la rotation de la CA racine et des CA de serveur subordonnées, et fournit des liens accessibles au public pour télécharger les groupes de certificats CA. Pour choisir une CA partagée, sélectionnez Autorité de certification CAS gérée par Google dans la Cloud de Confiance console ou spécifiez GOOGLE_MANAGED_CAS_CA pour le paramètre serverCaMode (API Cloud SQL Admin) ou l'option --server-ca-mode (gcloud CLI) lorsque vous créez ou modifiez l'instance. Vous pouvez mettre à jour une instance existante pour qu'elle utilise une hiérarchie de CA partagée si vous utilisez l'option de CA par instance ou de CA gérée par le client.

  • CA gérée par le client : avec cette option, vous créez et gérez votre propre hiérarchie de CA. Choisissez cette option si vous souhaitez gérer vos propres CA et certificats. En utilisant une CA gérée par le client (CUSTOMER_MANAGED_CAS_CA), vous pouvez gérer votre propre hiérarchie de CA et vos propres règles de rotation avec CA Service. Cette configuration vous offre un meilleur contrôle et vous aide à respecter les exigences de conformité. Pour choisir une CA gérée par le client, vous devez créer un pool de CA et une CA dans CA Service. Dans Cloud SQL, spécifiez le pool de CA et Autorité de certification CAS gérée par le client (Cloud de Confiance console), CUSTOMER_MANAGED_CAS_CA pour le paramètre serverCaMode (API Cloud SQL Admin) ou l'option --server-ca-mode (gcloud CLI) lorsque vous créez ou modifiez l'instance. Vous pouvez mettre à jour une instance existante pour qu'elle utilise une hiérarchie de CA gérée par le client si vous utilisez l'option de CA par instance ou de CA partagée.

Après avoir créé ou mis à jour une instance, vous pouvez afficher la hiérarchie de CA configurée pour une instance Cloud SQL à l'aide de la gcloud sql instances describe commande ou dans la Cloud de Confiance console. Pour en savoir plus, consultez Afficher les informations sur l'instance.

Le tableau suivant compare les trois options de hiérarchie de CA.

Fonctionnalité CA par instance CA partagée CA gérée par le client
Structure de la CA CA distincte pour chaque instance CA racine et CA subordonnées partagées entre les instances de la même région Hiérarchie de CA que vous créez et gérez
Attributs cryptographiques Clé RSA de 2 048 bits avec algorithme SHA256 Algorithme de signature numérique à courbe elliptique (ECDSA) avec clé de 384 bits et algorithme SHA384 Algorithme de signature numérique à courbe elliptique (ECDSA) avec clé de 384 bits et algorithme SHA384
Période de validité de la CA 10 ans 25 ans pour la CA racine et 10 ans pour les CA subordonnées Configurable *
Période de validité du certificat de serveur 10 ans 1 an 1 an**
Rotation de la CA initiée par l'utilisateur ? Oui Non. La rotation de la CA est gérée par Cloud SQL. Oui
Rotation du certificat de serveur initiée par l'utilisateur ? Oui Oui Oui
Rotation automatique du certificat de serveur ? Non Oui Oui
Ancre de confiance de la CA pour les connexions TLS La CA unique par instance est l'ancre de confiance de l'instance correspondante. La CA racine et les CA subordonnées sont les ancres de confiance pour toutes les instances d'une région donnée. Les CA que vous créez et gérez sont les ancres de confiance.
Validation de l'identité du serveur La validation de la CA permet de valider l'identité du serveur, car chaque instance possède une CA unique. La validation du nom d'hôte et de la CA est requise pour la validation de l'identité du serveur, car les CA de serveur sont partagées entre les instances. Bien que la CA ne soit pas partagée entre les instances, vous pouvez valider le nom d'hôte en même temps que la CA.
Champ "Autre nom de l'objet (SAN)" dans les certificats de serveur Le champ SAN ne contient le nom d'hôte (nom DNS de l'instance) que pour les instances sur lesquelles Private Service Connect est activé. Le nom d'hôte peut être utilisé pour la validation de l'identité du serveur. Si vous vous connectez à une instance Cloud SQL à l'aide du nom DNS comme nom d'hôte, vous devez configurer la résolution DNS. Le champ SAN contient le nom d'hôte (nom DNS de l'instance) pour tous les types d'instances. Le nom d'hôte peut être utilisé pour la validation de l'identité du serveur. Si vous vous connectez à une instance Cloud SQL à l'aide du nom DNS comme nom d'hôte, vous devez configurer la résolution DNS. Le champ SAN contient le nom d'hôte (nom DNS de l'instance) pour tous les types d'instances. Le nom d'hôte peut être utilisé pour la validation de l'identité du serveur.
Compatibilité avec la version du proxy d'authentification Cloud SQL Compatible avec toutes les versions du proxy d'authentification Cloud SQL, version 1 et ultérieures. Nécessite la version 2.13.0 ou ultérieure du proxy d'authentification Cloud SQL. Nécessite la version 2.14.3 ou ultérieure du proxy d'authentification Cloud SQL.
Limites de connexion au service Aucune Non compatible avec les connexions provenant des services suivants : Cloud de Confiance by S3NS Non compatible avec les connexions provenant des services suivants : Cloud de Confiance by S3NS
  • Environnement standard App Engine
  • Environnement flexible App Engine
  • Services Cloud Run qui s'exécutent dans un environnement d'exécution de première génération

* Pour l'option de CA gérée par le client, la période de validité par défaut d'un certificat CA dans CA Service est de 10 ans. Vous pouvez configurer une période de validité différente pour vos certificats CA. Une période de validité plus courte pour la CA peut nécessiter des rotations de CA plus fréquentes, et une période de validité inférieure à un an peut affecter la période de validité de vos certificats de serveur. Pour en savoir plus, consultez Gérer la rotation de la CA.

** Pour l'option de CA gérée par le client, la période de validité par défaut d'un certificat de serveur est d'un an. Toutefois, si vous configurez une période de validité inférieure à un an pour votre certificat CA, votre certificat de serveur aura une période de validité plus courte. Pour en savoir plus sur la configuration de la période de validité de votre certificat CA lors de sa création, consultez Paramètres des certificats CA et Créer une CA racine.

CA par instance hébergée par Cloud SQL

La hiérarchie de CA par instance est la configuration par défaut du mode de CA de serveur lorsque vous créez une instance à l'aide de gcloud CLI, de l'API Cloud SQL Admin ou de Terraform.

Cloud SQL crée une CA de serveur autosignée pour chaque instance lorsque vous la créez. Pour utiliser ce paramètre, configurez serverCaMode sur GOOGLE_MANAGED_INTERNAL_CA lorsque vous créez l'instance. Vous pouvez laisser le paramètre de configuration serverCaMode non spécifié à l'aide de l'API Cloud SQL Admin ou de gcloud CLI, ou sélectionner l'option Autorité de certification interne Google dans la Cloud de Confiance console.

Vous ne pouvez pas mettre à jour le serverCaMode d'une instance qui utilise une hiérarchie de CA partagée ou de CA gérée par le client pour utiliser la hiérarchie de CA par instance.

Le schéma suivant illustre la hiérarchie de CA par instance.

Schéma de la hiérarchie des CA internes par instance.

CA partagées hébergées par CA Service

Ce mode de CA de serveur se compose d'une CA racine et de CA de serveur subordonnées dans chaque région. Les CA de serveur subordonnées émettent des certificats de serveur et sont partagées entre les instances de la région. Cloud SQL gère la rotation des CA de serveur régionales partagées et fournit des liens accessibles au public pour télécharger les groupes de certificats CA.

Vous pouvez configurer une instance pour qu'elle utilise une hiérarchie de CA de serveur dans laquelle les CA émettrices sont partagées entre les instances de la même région. Pour utiliser ce paramètre, configurez serverCaMode sur GOOGLE_MANAGED_CAS_CA lorsque vous créez ou modifiez l'instance. Vous pouvez également sélectionner Autorité de certification CAS gérée par Google dans la Cloud de Confiance console.

Le schéma suivant illustre la hiérarchie de l'autorité de certification partagée.

Schéma d'une hiérarchie d'AC partagée

CA gérées par le client

Ce mode de CA de serveur vous permet de configurer votre propre hiérarchie de CA dans CA Service.

Pour utiliser l'option de CA gérée par le client dans Cloud SQL, vous devez créer un pool de CA dans la même région que vos instances Cloud SQL. Ensuite, créez au moins une CA. Lorsque vous créez l'instance Cloud SQL, spécifiez l'ID du pool de CA dans le champ serverCaPool et configurez le champ serverCaMode avec la valeur CUSTOMER_MANAGED_CAS_CA. CA Service fournit une CA à partir du pool de CA et l'utilise pour émettre le certificat de serveur de l'instance.

Lorsque vous créez des CA dans CA Service, vous pouvez créer une CA racine ou une CA subordonnée en fonction de votre cas d'utilisation. Par exemple, vous pouvez créer une CA subordonnée si vous prévoyez de configurer une hiérarchie de CA racine ou une chaîne vers une CA externe.

Ne sélectionnez l'option de CA gérée par le client que si vous souhaitez gérer vos propres CA et certificats. Pour en savoir plus, consultez Utiliser une CA gérée par le client.

Fonctionnement de la rotation des certificats de serveur

Cloud SQL fournit des moyens de faire tourner votre certificat de serveur, afin que le nouveau certificat puisse être mis en place de manière transparente avant l'expiration de l'ancien.

Les instances qui utilisent la hiérarchie de CA partagée ou de CA gérée par le client peuvent activer la rotation automatique des certificats de serveur pour qu'elle s'exécute lors des mises à jour de maintenance jusqu'à 180 jours avant l'expiration.

Pour les instances qui utilisent les hiérarchies de CA par instance, de CA partagée ou de CA gérée par le client, environ trois mois avant l'expiration du certificat de serveur d'une instance Cloud SQL, les propriétaires de projet reçoivent un e-mail de Cloud SQL leur indiquant que le processus de rotation des certificats a été démarré pour l'instance concernée. L'e-mail indique le nom de l'instance et informe les propriétaires de projet qu'un nouveau certificat de serveur y a été ajouté par Cloud SQL. Le certificat de serveur existant continue à fonctionner normalement. De fait, l'instance dispose lors de cette période de deux certificats de serveur.

La commande de rotation des certificats de serveur à utiliser dépend du fait que vous utilisiez un certificat de serveur émis par une CA par instance ou un certificat de serveur émis par la CA partagée ou la CA gérée par le client.

Avant l'expiration du certificat de serveur actuel, téléchargez le nouveau fichier server-ca.pem contenant les détails du certificat actuel ainsi que ceux du certificat nouvellement créé. Mettez à jour vos clients MySQL pour qu'ils utilisent le nouveau fichier. Pour cela, copiez le fichier téléchargé vers vos machines hôtes clientes afin de remplacer le fichier existant.

Une fois tous vos clients MySQL mis à jour, envoyez à l'instance Cloud SQL une commande de rotation (pour la CA par instance) ou une commande de rotation (pour la CA partagée ou la CA gérée par le client) déclenchant la rotation vers le nouveau certificat du serveur. Une fois cette opération effectuée, l'ancien certificat du serveur n'est plus reconnu et seul le nouveau certificat du serveur peut être utilisé.

Les certificats clients ne sont pas affectés par la rotation des certificats du serveur.

Expiration du certificat SSL

Pour les instances Cloud SQL qui utilisent des CA par instance (serverCaMode est défini sur GOOGLE_MANAGED_INTERNAL_CA), les certificats SSL ont une période d'expiration de 10 ans. Avant l'expiration de ces certificats, effectuez une rotation des certificats CA du serveur.

Pour les instances qui utilisent des CA partagées (serverCaMode est défini sur GOOGLE_MANAGED_CAS_CA), la période d'expiration des certificats de serveur est d'un an. Avant l'expiration, effectuez une rotation des certificats de serveur ou activez la rotation automatique des certificats de serveur. Le certificat de l'autorité de certification racine a une période d'expiration de 25 ans, et le certificat de la CA partagée subordonnée a une période d'expiration de 10 ans. Cloud SQL gère leur rotation.

Si vous utilisez une CA gérée par le client (serverCaMode est défini sur CUSTOMER_MANAGED_CAS_CA), vous pouvez effectuer une rotation des certificats CA en faisant tourner les CA du pool de CA que vous avez créé. La période d'expiration d'une CA est généralement de 10 ans, mais vous pouvez configurer une période de validité plus courte pour votre CA dans CA Service.

Pour faire tourner les CA, utilisez le processus de rotation des CA dans CA Service. Pour en savoir plus, consultez Gérer la rotation de la CA.

Si un client est configuré pour valider la CA ou le nom d'hôte dans le certificat de serveur, les connexions de ce client aux instances Cloud SQL dont les certificats de serveur ont expiré échoueront. Pour éviter toute interruption des connexions client, faites tourner le certificat de serveur avant son expiration.

Que vous utilisiez le mode de serveur de CA par instance, de CA partagée ou de CA gérée par le client , vous pouvez réinitialiser la configuration SSL de votre instance Cloud SQL à tout moment.

Limites

Cette section couvre les limites liées à la configuration des certificats SSL/TLS et à Cloud SQL.

Limites de connexion au service

Étape suivante