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 un niveau de sécurité en chiffrant les données en transit entre votre client et la base de données de votre instance Cloud SQL. Si vous le souhaitez, votre connexion SSL/TLS peut effectuer la validation de l'identité du serveur en validant le certificat 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 (CA). Vous pouvez télécharger le certificat CA sur la machine hôte du client et l'utiliser pour vérifier l'identité de l'autorité de certification et du serveur Cloud SQL. Vous pouvez également choisir le type d'autorité de certification que Cloud SQL utilise pour signer le certificat de serveur.

Certificats clients

Vous pouvez également créer et télécharger des certificats client 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 d'autorité de certification que Cloud SQL utilise pour signer le certificat client.

Se connecter à l'aide de SSL/TLS

Lorsque vous vous connectez à une instance Cloud SQL depuis des 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 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 des certificats clients. 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 besoin de télécharger un certificat d'autorité de certification du 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 (CA)

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

• Autorité de certification par instance : avec cette option, une autorité de certification 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 (consoleGoogle Cloud ) ou spécifiez GOOGLE_MANAGED_INTERNAL_CA pour le paramètre serverCaMode (API Cloud SQL Admin) ou l'indicateur --server-ca-mode (gcloud CLI) lorsque vous créez l'instance. Si vous ne spécifiez pas le paramètre ni l'indicateur lorsque vous créez une instance, cette option est la valeur par défaut de l'instance.

• Autorité de certification partagée : cette option utilise une hiérarchie d'autorités de certification composée d'une autorité de certification racine et d'autorités de certification de serveur subordonnées. Les autorités de certification de serveur subordonnées d'une région signent les certificats de serveur et sont partagées entre les instances de la région. Cloud SQL héberge et gère l'autorité de certification racine et les autorités de certification de serveur subordonnées sur le service d'autorité de certification (CA Service). Google CloudCloud SQL gère également la rotation des autorités de certification racine et des autorités de certification de serveur subordonnées, et fournit des liens accessibles au public pour télécharger les bundles de certificats CA. Pour choisir une autorité de certification partagée, spécifiez GOOGLE_MANAGED_CAS_CA pour le paramètre serverCaMode (API Cloud SQL Admin) ou l'indicateur --server-ca-mode (gcloud CLI) lorsque vous créez l'instance.

• Autorité de certification gérée par le client : cette option vous permet de créer et de gérer votre propre hiérarchie d'autorités de certification. Choisissez cette option si vous souhaitez gérer vos propres autorités de certification et certificats. Pour choisir une autorité de certification gérée par le client, vous devez créer un pool d'autorités de certification et une autorité de certification dans CA Service. Dans Cloud SQL, spécifiez le pool d'AC et CUSTOMER_MANAGED_CAS_CA pour le paramètre serverCaMode (API Cloud SQL Admin) ou l'indicateur --server-ca-mode (gcloud CLI) lorsque vous créez l'instance.

Une fois l'instance créée, vous pouvez afficher la hiérarchie d'autorité de certification configurée pour une instance Cloud SQL à l'aide de la commande gcloud sql instances describe ou dans la console Google Cloud . Pour en savoir plus, consultez Afficher les informations sur les instances.

Le tableau suivant compare les trois options de hiérarchie d'AC.

Fonctionnalité	CA par instance	AC partagée	AC gérée par le client
Structure de l'autorité de certification	Autorité de certification distincte pour chaque instance	CA racine et CA subordonnées partagées entre les instances d'une même région	Hiérarchie d'AC que vous créez et gérez
Attributs cryptographiques	Clé RSA de 2 048 bits avec l'algorithme SHA256	Algorithme ECDSA (Elliptic Curve Digital Signature Algorithm) avec clé de 384 bits et algorithme SHA384	Algorithme ECDSA (Elliptic Curve Digital Signature Algorithm) avec clé de 384 bits et algorithme SHA384
Période de validité de l'AC	10 ans	25 ans pour l'autorité de certification racine et 10 ans pour les autorités de certification subordonnées	Configurable *
Période de validité du certificat de serveur	10 ans	1 an	1 an**
Rotation des CA initiée par l'utilisateur	Oui	Non. La rotation des autorités de certification est gérée par Cloud SQL.	Oui
Rotation du certificat de serveur initiée par l'utilisateur	Oui	Oui	Oui
Ancre de confiance de l'autorité de certification pour les connexions TLS	L'autorité de certification unique par instance constitue l'ancre de confiance de l'instance correspondante.	L'autorité de certification racine et les autorités de certification subordonnées sont les ancres de confiance pour toutes les instances d'une région donnée.	Les autorités de certification que vous créez et gérez sont les ancres de confiance.
Validation de l'identité du serveur	La vérification de l'AC permet de vérifier l'identité du serveur, car chaque instance possède une AC unique.	La vérification du nom d'hôte et de l'autorité de certification est requise pour la vérification de l'identité du serveur, car les autorités de certification du serveur sont partagées entre les instances.	Bien que l'autorité de certification ne soit pas partagée entre les instances, vous pouvez vérifier le nom d'hôte en même temps que l'autorité de certification.
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 vérifier l'identité du serveur. Si vous vous connectez à une instance Cloud SQL en utilisant le 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 valider l'identité du serveur. Si vous vous connectez à une instance Cloud SQL en utilisant le 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 valider l'identité du serveur.
Compatibilité avec les versions du proxy d'authentification Cloud SQL	Compatible avec toutes les versions du proxy d'authentification Cloud SQL, y compris la version 1 et les versions ultérieures.	Nécessite le proxy d'authentification Cloud SQL version 2.13.0 ou ultérieure.	Nécessite le proxy d'authentification Cloud SQL version 2.14.3 ou ultérieure.
Limites de la connexion au service	Aucun	Les connexions depuis les services Google Cloudsuivants ne sont pas prises en charge : Environnement standard App Engine Environnement flexible App Engine Services Cloud Run s'exécutant dans un environnement d'exécution de première génération	Les connexions depuis les services Google Cloudsuivants ne sont pas prises en charge : Environnement standard App Engine Environnement flexible App Engine Services Cloud Run s'exécutant dans un environnement d'exécution de première génération

* Pour l'option d'autorité de certification 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 l'autorité de certification peut nécessiter des rotations plus fréquentes de l'autorité de certification. 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 des certificats d'autorité de certification.

** Pour l'option d'autorité de certification gérée par le client, la durée 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 d'autorité de certification, la période de validité de votre certificat de serveur sera plus courte. Pour savoir comment configurer la période de validité de votre certificat CA lors de sa création, consultez Paramètres du certificat CA et Créer une autorité de certification racine.

CA par instance hébergée par Cloud SQL

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

Cloud SQL crée une nouvelle autorité de certification 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 console Google Cloud .

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

AC partagées hébergées par le service CA

La hiérarchie d'AC partagée est la configuration par défaut du mode AC du serveur lorsque vous créez une instance à l'aide de la console Google Cloud .

Ce mode d'autorité de certification de serveur se compose d'une autorité de certification racine et d'autorités de certification de serveur subordonnées dans chaque région. Les autorités de certification 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 autorités de certification de serveur régionales partagées et fournit des liens accessibles au public pour télécharger les bundles de certificats CA.

Vous pouvez configurer une instance pour qu'elle utilise une hiérarchie d'AC de serveur où les AC é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 l'instance. Vous pouvez également sélectionner Autorité de certification CAS gérée par Google dans la console Google Cloud .

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

AC gérées par le client

Ce mode d'autorité de certification de serveur vous permet de configurer votre propre hiérarchie d'autorités de certification dans CA Service.

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

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

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

Fonctionnement de la rotation des certificats de serveur

Cloud SQL fournit des méthodes pour 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.

Pour les instances qui utilisent les hiérarchies d'AC par instance, d'AC partagée ou d'AC 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 du certificat de serveur à utiliser dépend du type de certificat de serveur que vous utilisez : certificat émis par une autorité de certification par instance ou certificat émis par l'autorité de certification partagée ou 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 PostgreSQL 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 PostgreSQL mis à jour, envoyez à l'instance Cloud SQL une commande de rotation (pour l'autorité de certification par instance) ou une commande de rotation (pour l'autorité de certification partagée ou gérée par le client) afin de passer au nouveau certificat de 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 la rotation du certificat 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. Le certificat de l'autorité de certification (CA) racine a une période d'expiration de 25 ans, et le certificat de l'autorité de certification 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 la rotation des certificats de CA en faisant tourner les CA dans le 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 effectuer la rotation des autorités de certification, utilisez le processus de rotation des autorités de certification dans CA Service. Pour en savoir plus, consultez Gérer la rotation des certificats d'autorité de certification.

Si un client est configuré pour valider l'autorité de certification ou le nom d'hôte dans le certificat de serveur, ses connexions 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 serveur de l'autorité de certification par instance, de l'autorité de certification partagée ou de l'autorité de certification gérée par le client, vous pouvez réinitialiser la configuration SSL de votre instance Cloud SQL à tout moment.

Étapes suivantes

• Configurez SSL/TLS sur votre instance Cloud SQL.

• Découvrez comment le chiffrement est géré dans Google Cloud.

• Connectez-vous à votre instance Cloud SQL à l'aide de SSL/TLS.

• Gérez SSL/TLS sur votre instance Cloud SQL.

• Découvrez en détail comment PostgreSQL utilise SSL/TLS.