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. Si vous le souhaitez, votre connexion SSL/TLS peut effectuer une validation de l'identité du serveur en validant le certificat de serveur installé sur l'instance Cloud SQL et une 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 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.
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 :
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 de cette instance. Cloud SQL crée et gère ces autorités de certification. Pour choisir une autorité de certification par instance, sélectionnez Autorité de certification interne gérée par Google (Google Cloud console) ou spécifiez
GOOGLE_MANAGED_INTERNAL_CApour le paramètreserverCaMode(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 ou l'indicateur 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 d'autorité de certification par instance si elle est configurée pour utiliser une autorité de certification partagée ou gérée par le client.Autorité de certification partagée : avec cette option, 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 est utilisée. 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. L'utilisation d'une hiérarchie d'autorités de certification partagées est utile lorsque vous augmentez le nombre d'instances dans une région, car vous n'avez pas besoin de gérer des autorités de certification uniques pour les instances individuelles. En passant à une autorité de certification partagée (
GOOGLE_MANAGED_CAS_CA), vous pouvez utiliser un seul bundle d'autorités de certification régionales pour toutes vos instances de la région, ce qui peut simplifier votre configuration côté client. Cloud SQL héberge et gère l'autorité de certification racine et les autorités de certification de serveur subordonnées sur Google Cloud Certificate Authority Service (CA Service). Cloud SQL gère également la rotation de l'autorité 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écifiezGOOGLE_MANAGED_CAS_CApour le paramètreserverCaMode(API Cloud SQL Admin) ou l'indicateur--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 d'autorités de certification partagées si vous utilisez l'option d'autorité de certification par instance ou gérée par le client.Autorité de certification gérée par le client : avec cette option, vous créez et gérez 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. En utilisant une autorité de certification gérée par le client (
CUSTOMER_MANAGED_CAS_CA), vous pouvez gérer votre propre hiérarchie d'autorités de certification 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 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'autorités de certification etCUSTOMER_MANAGED_CAS_CApour le paramètreserverCaMode(API Cloud SQL Admin) ou l'indicateur--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 d'autorités de certification gérées par le client si vous utilisez l'option d'autorité de certification par instance ou partagée.
Après avoir créé ou mis à jour une instance, vous pouvez afficher la hiérarchie d'autorités de certification configurée pour
une instance Cloud SQL à l'aide de la commande gcloud sql instances describeou dans la Google Cloud console.
Pour en savoir plus, consultez la section Afficher les informations sur l'instance.
Le tableau suivant compare les trois options de hiérarchie d'autorités de certification.
| Fonctionnalité | Autorité de certification par instance | Autorité de certification partagée | Autorité de certification gérée par le client |
|---|---|---|---|
| Structure de l'autorité de certification | Autorité de certification distincte pour chaque instance | Autorité de certification racine et autorités de certification subordonnées partagées entre les instances de la même région | Hiérarchie d'autorités de certification 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 256 bits et algorithme SHA384 | Algorithme de signature numérique à courbe elliptique (ECDSA) avec clé de 256 bits et algorithme SHA384 |
| Période de validité de l'autorité de certification | 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 de l'autorité de certification initiée par l'utilisateur ? | Oui | Non. La rotation de l'autorité de certification 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 l'autorité de certification pour les connexions TLS | L'autorité de certification unique par instance est 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 validation de l'autorité de certification valide l'identité du serveur, car chaque instance a une autorité de certification unique. | La validation du nom d'hôte ainsi que celle de l'autorité de certification sont requises pour la validation de l'identité du serveur, car les autorités de certification de serveur sont partagées entre les instances. | Bien que l'autorité de certification ne soit pas partagée entre les instances, vous pouvez valider 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 activées avec Private Service Connect. 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 : Google Cloud |
Non compatible avec les connexions provenant des services suivants : Google Cloud
|
* 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, 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 la section Gérer la rotation de l'autorité de certification.
** Pour l'option d'autorité de certification 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 la section Paramètres des certificats CA et Créer une autorité de certification racine.
Autorité de certification par instance hébergée par Cloud SQL
La hiérarchie d'autorités de certification par instance est la configuration par défaut du mode d'autorité de certification 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 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 Google Cloud console.
Vous ne pouvez pas mettre à jour le serverCaMode d'une instance qui utilise une hiérarchie d'autorités de certification partagées ou gérées par le client pour utiliser la hiérarchie d'autorités de certification par instance.
Le schéma suivant illustre la hiérarchie d'autorités de certification par instance.
Autorités de certification partagées hébergées par CA Service
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.
Lorsque vous utilisez le mode d'autorité de certification partagée, vos clients de base de données doivent approuver à la fois l'autorité de certification racine et l'autorité de certification subordonnée qui émet les certificats de serveur pour votre instance.Pour approuver à la fois l'autorité de certification racine et l'autorité de certification subordonnée de votre instance, procédez de l'une des manières suivantes :
- Téléchargez le bundle
global.pempour approuver l'autorité de certification racine et toutes ses autorités de certification subordonnées. - Téléchargez le bundle régional
pour l'emplacement régional de votre instance afin d'approuver l'autorité de certification racine et les autorités de certification subordonnées
de cette région.
Par exemple, si votre instance se trouve dans la région
asia-east1, téléchargez le bundleasia-east1.pem. - Téléchargez le
server-ca.pemde votre instance pour approuver l'autorité de certification racine et l'autorité de certification subordonnée qui émet le certificat de serveur pour votre instance.
Vous pouvez configurer une instance pour qu'elle utilise une hiérarchie d'autorités de certification de serveur dans laquelle les autorités de certification é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 Google Cloud console.
Le schéma suivant illustre la hiérarchie d'autorités de certification partagées.
Autorités de certification 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, créez un pool d'autorités de certification dans la même région que vos instances Cloud SQL. Créez ensuite au moins une autorité de certification.
Lorsque vous créez l'instance Cloud SQL, spécifiez l'ID du pool d'autorités de certification 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 de 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 en fonction de 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 d'autorités de certification racine ou une chaîne vers 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 la section Utiliser une autorité de certification gérée par le client.
Fonctionnement de la rotation des certificats de serveur
Cloud SQL fournit des moyens d'effectuer une rotation de 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 utilisant la hiérarchie d'autorités de certification partagées ou gérées 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 d'autorités de certification par instance, partagées ou gérées 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 autorité de certification par instance ou un certificat de serveur é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 SQL Server 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 SQL Server 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) 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é.
Expiration du certificat SSL
Pour les instances Cloud SQL qui utilisent des autorités de certification 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 autorités de certification 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 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 autorité de certification 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 autorités de certification dans le pool d'autorités de certification que vous avez créé. La période d'expiration d'une autorité de certification est généralement de 10 ans, mais vous pouvez configurer une période de validité plus courte pour votre autorité de certification dans CA Service.
Pour faire tourner les autorités de certification, utilisez le processus de rotation des autorités de certification dans CA Service. Pour en savoir plus, consultez la section Gérer la rotation de l'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, les connexions de ce client aux instances Cloud SQL avec des certificats de serveur expirés échoueront. Pour éviter toute interruption des connexions client, faites tourner le certificat de serveur avant son expiration.
Que vous utilisiez le mode de serveur d'autorité de certification par instance, d'autorité de certification partagée ou d'autorité de certification 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
- Si votre instance utilise l'option d'autorité de certification partagée (
GOOGLE_MANAGED_CAS_CA) ou gérée par le client (CUSTOMER_MANAGED_CAS_CA) pour sa configurationserverCaMode, elle ne peut pas être compatible avec les connexions provenant des services suivants Google Cloud :
Étape suivante
Configurez SSL/TLS sur votre instance Cloud SQL.
Découvrez comment le chiffrement est géré dans Google Cloud.
- En savoir plus sur la façon dont SQL Server utilise des connexions chiffrées.
- Gérez SSL/TLS sur votre instance Cloud SQL.