Autoriser via des certificats SSL/TLS

MySQL | PostgreSQL | SQL Server

Cette page explique comment Cloud SQL utilise des certificats SSL (Secure Socket Layer) et TLS (Transport Layer Security) pour se connecter en toute sécurité aux instances Cloud SQL.

Présentation

Cloud SQL est compatible avec la connexion à une instance à l'aide du protocole SSL/TLS (Transport Layer Security). Les données en transit se trouvant au sein d'une limite physique contrôlée par ou pour le compte de Google sont généralement authentifiées, mais elles peuvent ne pas être chiffrées par défaut. Si vous vous connectez à une instance à l'aide de son adresse IP publique, vous devez appliquer des certificats SSL/TLS afin que les données soient sécurisées pendant leur transmission. SSL/TLS est le protocole standard de chiffrement des données envoyées sur Internet. Si vos données ne sont pas chiffrées, n'importe qui peut examiner vos paquets et lire des informations confidentielles.

La méthode de chiffrement la plus sûre est la "cryptographie asymétrique", qui repose sur deux clés de chiffrement, l'une publique et l'autre privée. Pour simplifier, vous utilisez la clé publique pour chiffrer les données et la clé privée pour les déchiffrer. Le serveur et les machines clientes possèdent le même ensemble de clés de client.

Dans Cloud SQL, la clé publique est nommée client-cert.pem et la clé privée client-key.pem. Le serveur génère également son propre certificat, nommé server-ca.pem.

Votre application a besoin de ces trois éléments pour pouvoir se connecter. Stockez ces clés de manière sécurisée. En effet, toute personne qui y aurait accès serait en mesure de se connecter au serveur ou d'intercepter vos données. Vous ne pourrez pas récupérer la clé privée ultérieurement à partir du serveur. Par conséquent, si vous la perdez, vous devrez créer de nouveaux certificats clients pour remplacer ceux utilisés précédemment. De même, lorsque le serveur génère un nouveau fichier server-ca.pem, vous devez le télécharger et le stocker sur la machine hôte du client PostgreSQL afin de remplacer le fichier existant.

Certificats SSL/TLS

Un certificat CA (autorité de certification) du serveur est obligatoire dans le cadre de connexions SSL. Cloud SQL crée automatiquement un certificat de serveur lors de la création d'une instance. Tant que celui-ci est valide, vous n'avez pas besoin de gérer activement le certificat du serveur. Toutefois, le certificat a une date d'expiration de 10 ans. Après cette date, il n'est plus valide et les clients ne sont plus en mesure d'établir une connexion sécurisée à votre instance à l'aide de ce certificat. Vous pouvez également en créer un manuellement.

Vous créez des certificats clients vous-même. Le nombre de certificats clients par instance Cloud SQL est limité à 10.

Fonctionnement de la rotation des certificats de serveur

Cloud SQL fournit une fonctionnalité de rotation des certificats de serveur. Cela permet de facilement mettre en place un nouveau certificat avant l'expiration de l'ancien.

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.

Avant l'expiration du certificat 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 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.

Appliquer le chiffrement SSL/TLS

Configurer une instance Cloud SQL pour qu'elle accepte les connexions SSL/TLS ne suffit pas à garantir que toutes les connexions non chiffrées et non sécurisées seront refusées. Si vous n'exigez pas SSL/TLS pour toutes les connexions, les connexions non chiffrées sont toujours autorisées. Par conséquent, si vous accédez à votre instance à l'aide d'une adresse IP publique, il est fortement recommandé d'appliquer le protocole SSL à toutes les connexions.

Utiliser des réseaux autorisés

Si votre instance Cloud SQL utilise une adresse IP publique, vous devez ajouter les adresses IP de vos clients PostgreSQL comme réseaux autorisés lors de la configuration de SSL/TLS.

Dans ce cas, les clients PostgreSQL ne sont autorisés à se connecter que si leurs adresses IP sont ajoutées à cette liste. Les adresses IP peuvent être limitées à un seul point de terminaison ou consister en une plage au format CIDR. Par exemple, 10.50.51.3 ou 10.50.51.0/26.

Expiration du certificat SSL

Les certificats SSL associés aux instances Cloud SQL ont une période d'expiration de 10 ans. À la date d'expiration, procédez à la rotation des certificats SSL. Vous pouvez également réinitialiser la configuration SSL de votre instance Cloud SQL à tout moment.