Par défaut, Cloud SQL pour SQL Server chiffre le contenu client au repos. Cloud SQL pour SQL Server gère le chiffrement sans intervention de votre part. Cette option est appelée chiffrement par défaut de Google.
Si vous souhaitez contrôler vos clés de chiffrement, vous pouvez utiliser des clés de chiffrement gérées par le client (CMEK) dans Cloud KMS avec des services bénéficiant d'une intégration des CMEK, y compris Cloud SQL pour SQL Server. L'utilisation de clés Cloud KMS vous permet de contrôler leur niveau de protection, leur emplacement, leur calendrier de rotation, leurs autorisations d'utilisation et d'accès, ainsi que leurs limites cryptographiques. Cloud KMS vous permet également de suivre l'utilisation des clés, d'afficher les journaux d'audit et de contrôler le cycle de vie des clés. Au lieu de laisser Google posséder et gérer les clés de chiffrement de clés (KEK) symétriques qui protègent vos données, c'est vous qui vous chargez de cette tâche dans Cloud KMS.
Une fois que vous avez configuré vos ressources avec des clés CMEK, l'accès à vos ressources Cloud SQL pour SQL Server est semblable à celui du chiffrement par défaut de Google. Pour en savoir plus sur les options de chiffrement, consultez Clés de chiffrement gérées par le client (CMEK).
CMEK avec Cloud KMS Autokey
Pour protéger vos ressources Cloud SQL pour SQL Server, vous pouvez créer des clés CMEK manuellement ou utiliser Cloud KMS Autokey. Avec Autokey, les trousseaux de clés et les clés sont générés à la demande lors de la création de ressources dans Cloud SQL pour SQL Server. Les agents de service qui utilisent les clés pour les opérations de chiffrement et de déchiffrement sont créés s'ils n'existent pas déjà et s'ils disposent des rôles IAM (Identity and Access Management) requis. Pour en savoir plus, consultez la section Présentation de la clé automatique.
Autokey ne crée pas de clés pour les ressources BackupRun Cloud SQL pour SQL Server. Lorsque vous créez une sauvegarde d'une instance Cloud SQL pour SQL Server, celle-ci est chiffrée avec la clé gérée par le client de l'instance principale.
Cloud SQL pour SQL Server n'est compatible avec Cloud KMS Autokey que lorsque vous créez des ressources à l'aide de Terraform ou de l'API REST.
Pour savoir comment utiliser des CMEK créées manuellement pour protéger vos ressources Cloud SQL pour SQL Server, consultez la section Utiliser des clés de chiffrement gérées par le client (CMEK).
Pour utiliser les CMEK créées par Cloud KMS Autokey afin de protéger vos ressources Cloud SQL pour SQL Server, suivez les étapes fournies pour Secret Manager dans Utiliser Autokey avec des ressources Secret Manager.
Chiffrement géré par Google et chiffrement géré par le client
Les schémas ci-dessous montrent le fonctionnement du chiffrement des données au repos dans une instance Cloud SQL en cas d'utilisation du chiffrement Google par défaut et en cas d'utilisation des clés de chiffrement gérées par le client.
Sans CMEK
Avec CMEK
Lors du déchiffrement des données encapsulées avec des clés de chiffrement gérées par le client, Cloud SQL utilise la clé KEK pour déchiffrer la clé DEK, puis il utilise la clé DEK non chiffrée pour déchiffrer les données au repos.
Quand Cloud SQL interagit-il avec les clés CMEK ?
| Opération | Remarques |
| Création d'une instance | Lors de la création de l'instance, vous configurez celle-ci de sorte qu'elle utilise des clés de chiffrement gérées par le client. |
| Création d'une sauvegarde | Lors des sauvegardes d'une instance pour laquelle CMEK est activé, les clés de chiffrement gérées par le client chiffrent les données utilisateur, telles que les requêtes utilisateur et les réponses à ces requêtes. Les sauvegardes d'une instance activée avec CMEK héritent de son chiffrement avec la même clé Cloud KMS que l'instance source. |
| Restauration d'une instance | Lors des restaurations d'une instance pour laquelle CMEK est activé, Cloud SQL utilise la clé pour accéder aux données de l'instance de sauvegarde en cours de restauration. Lors d'une restauration sur une autre instance, l'instance cible peut utiliser une clé différente pour le chiffrement. |
| Création d'une instance dupliquée | Lorsque vous créez une instance répliquée avec accès en lecture d'une instance Cloud SQL dans la même région, elle hérite du CMEK de l'instance parente. Si vous créez une instance répliquée avec accès en lecture dans une autre région, vous devez sélectionner une clé CMEK dans l'autre région. Chaque région utilise son propre ensemble de clés. |
| Création de clones | Les clones d'une instance pour laquelle CMEK est activé héritent du chiffrement CMEK avec la même clé Cloud KMS que l'instance source. |
| Mise à jour d'une instance | Lors de la mise à jour d'une instance pour laquelle CMEK est activé, Cloud SQL vérifie la clé CMEK. |
Quels emplacements acceptent les instances Cloud SQL utilisant CMEK ?
CMEK est disponible dans tous les emplacements d'instances de Cloud SQL.
À propos des comptes de service
Lorsque CMEK est activé sur vos instances Cloud SQL, vous devez utiliser un compte de service pour demander un accès par clé à partir de Cloud KMS.
Pour utiliser une clé de chiffrement gérée par le client sur un projet, vous devez disposer d'un compte de service et accorder à cette clé l'accès à ce compte. Le compte de service doit être créé dans le projet Le compte de service est visible dans toutes les régions.
Si vous utilisez la console pour créer une instance, Cloud SQL crée automatiquement le compte de service lorsque vous choisissez l'option Clé gérée par le client (si un compte de service n'existe pas déjà). Lorsque Cloud SQL crée automatiquement le compte de service, vous n'avez pas besoin d'autorisations particulières sur votre compte utilisateur.
À propos des clés
Dans Cloud KMS, vous devez créer un trousseau avec une clé de chiffrement, et y associer un emplacement. Lorsque vous créez une instance Cloud SQL, vous sélectionnez cette clé pour chiffrer l'instance.
Lorsque vous créez des instances Cloud SQL qui utilisent des clés de chiffrement gérées par le client, vous devez connaître l'ID et la région de ces clés. Vous devez placer les nouvelles instances Cloud SQL dans la région où se trouve la clé de chiffrement gérée par le client associée à l'instance. Vous pouvez créer un projet unique pour les clés et les instances Cloud SQL, ou un projet distinct pour chaque élément.
Les clés de chiffrement gérées par le client utilisent le format suivant :
projects/[KMS_PROJECT_ID]/locations/[LOCATION]/keyRings/[KEY_RING]/cryptoKeys/[KEY_NAME]
Si Cloud SQL ne parvient pas à accéder à la clé (par exemple, si vous désactivez la version de clé), il suspend l'instance. Lorsque la clé redevient accessible, Cloud SQL réactive automatiquement l'instance.
Lorsque vous effectuez une rotation des clés, les instances chiffrées avec l'une de ces clés ne sont pas automatiquement chiffrées une nouvelle fois avec la nouvelle version de clé primaire. Vous pouvez rechiffrer toute instance principale ou instance répliquée CMEK existante avec la nouvelle version de clé primaire. Pour en savoir plus sur le rechiffrement d'une instance ou d'une instance répliquée Cloud SQL après une rotation des clés, consultez Rechiffrer une instance ou une instance répliquée existante sur laquelle l'option CMEK est activée.
Gestionnaires de clés externes
Vous pouvez utiliser des clés stockées dans des gestionnaires de clés externes, tels que Fortinix, Futurex ou Thales, en tant que clés de chiffrement gérées par le client. Pour apprendre à utiliser des clés externes avec Cloud KMS, consultez la page Cloud External Key Manager (Cloud EKM).
Key Access Justifications
Vous pouvez utiliser Key Access Justifications dans Cloud EKM. Key Access Justifications vous permettent d'afficher le motif de chaque requête Cloud EKM. De plus, selon la justification fournie, vous pouvez approuver ou refuser automatiquement une requête. Pour en savoir plus, consultez la présentation des justifications des accès aux clés.
Ainsi, Key Access Justifications offre un contrôle supplémentaire sur vos données en justifiant chaque tentative de déchiffrement des données.
Pour en savoir plus sur l'utilisation de vos clés avec des instances Cloud SQL, consultez la page Créer une instance Cloud SQL avec CMEK.
Comment rendre les données chiffrées par CMEK définitivement inaccessibles ?
Vous pouvez être amené à détruire définitivement des données chiffrées avec CMEK. Cette opération implique de supprimer la version correspondante de la clé de chiffrement gérée par le client. Vous ne pouvez pas détruire le trousseau ou la clé, mais vous pouvez supprimer les versions de la clé.
Comment exporter et importer des données depuis et vers une instance utilisant CMEK ?
Si vous souhaitez que vos données restent chiffrées avec une clé gérée par le client lors d'une exportation ou d'une importation, vous devez définir cette clé sur le bucket Cloud Storage avant d'exporter des données. Il n'existe pas d'exigences ni de restrictions particulières concernant l'importation de données vers une nouvelle instance lorsque ces données étaient précédemment stockées sur une instance utilisant une clé de chiffrement gérée par le client.
Restrictions
Les restrictions suivantes s'appliquent en cas d'utilisation de clés de chiffrement gérées par le client :
- Vous ne pouvez pas activer les clés de chiffrement gérées par le client sur une instance existante.
- Vous ne pouvez pas attribuer une clé différente à une instance répliquée située dans la même région que l'instance principale. Pour les instances répliquées interrégionales, vous devez créer une clé pour la région dupliquée.
- Vous ne pouvez pas attribuer une clé différente à un clone.
- Vous ne pouvez pas utiliser des clés de chiffrement gérées par le client pour chiffrer les éléments suivants :
- Serveurs externes (instances primaires externes et instances dupliquées externes)
- Métadonnées d'instance, telles que l'ID d'instance, la version de la base de données, le type de machine, les options, le planning des sauvegardes, etc.
- Vous ne pouvez pas utiliser de clés de chiffrement gérées par le client pour chiffrer les données utilisateur en transit, telles que les requêtes utilisateur et les réponses à ces requêtes.
- Une fois que vous avez créé une instance Cloud SQL, vous ne pouvez plus modifier le type de clé de chiffrement. Vous ne pouvez pas passer d'une clé de chiffrement gérée par Google à une clé Cloud Key Management Service (KMS), ni inversement.
Étape suivante
- Découvrez le chiffrement au repos dans Google Cloud Platform.
- Découvrez comment créer une instance avec CMEK activé.
- Découvrez Cloud Key Management Service (Cloud KMS).
- Apprenez-en plus sur les quotas pour les ressources Cloud KMS.
- Familiarisez-vous avec les comptes de service IAM.
- Découvrez comment ajouter la fonctionnalité Key Access Justifications à vos clés.
- Recherchez d'autres produits qui utilisent CMEK.