Cette page décrit les clés de chiffrement gérées par le client (CMEK) pour AlloyDB pour PostgreSQL.
Pour en savoir plus sur CMEK en général, y compris quand et pourquoi activer cette fonctionnalité, consultez la documentation Cloud KMS.
Par défaut, AlloyDB pour PostgreSQL chiffre le contenu client au repos. AlloyDB 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 AlloyDB. 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 d'afficher les journaux d'audit et de contrôler les cycles 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 CMEK, l'accès à vos ressources AlloyDB 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).
Pour savoir comment utiliser des clés CMEK créées manuellement afin de protéger vos ressources AlloyDB, consultez la section Utiliser des clés CMEK.
CMEK avec Cloud KMS Autokey
Pour protéger vos ressources AlloyDB, 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 AlloyDB. 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.
AlloyDB n'est compatible avec Cloud KMS Autokey que lors de la création de ressources à l'aide de Terraform ou de l'API REST.
Une alternative autogérée au chiffrement géré par Google
Par défaut, toutes les données au repos dans Google Cloud, y compris les données d'AlloyDB, sont protégées à l'aide du chiffrement par défaut géré par Google. Google Cloudtraite et gère ce chiffrement par défaut sans aucune action supplémentaire de votre part.
Si vous avez des exigences réglementaires ou de conformité spécifiques concernant les clés qui protègent vos données, vous pouvez utiliser CMEK à la place. Avec CMEK, votre cluster AlloyDB est protégé à l'aide d'une clé que vous contrôlez et gérez dans Cloud Key Management Service (KMS). Votre clé CMEK peut être une clé symétrique ou une clé Cloud HSM.
Fonctionnalités
- Contrôle de l'accès aux données:les administrateurs peuvent alterner la clé utilisée pour protéger les données au repos dans AlloyDB, en gérer l'accès, et la désactiver ou la détruire.
- Possibilité de réaliser des audits:si vous activez la journalisation d'audit pour l'API Cloud KMS dans votre projet, toutes les actions sur la clé, y compris celles effectuées par AlloyDB, sont enregistrées et visibles dans Cloud Logging.
- Performances:l'utilisation de CMEK n'a aucun impact sur les performances d'AlloyDB.
Tarifs
AlloyDB facture un cluster compatible CMEK comme n'importe quel autre cluster. Il n'y a aucuns frais AlloyDB supplémentaires. Pour en savoir plus, consultez la page Tarifs AlloyDB pour PostgreSQL.
Cloud KMS vous facture le coût de la clé ainsi que les opérations de chiffrement et de déchiffrement lorsque AlloyDB utilise la clé. Pour en savoir plus, consultez la page Tarifs de Cloud Key Management Service.
Éléments protégés par CMEK
AlloyDB utilise votre clé Cloud KMS pour protéger les données au repos de la manière suivante:
- Si vous activez CMEK sur un cluster, AlloyDB utilise votre clé pour chiffrer toutes les données de votre cluster en stockage.
- Si vous spécifiez une configuration CMEK lorsque vous créez une sauvegarde à la demande, AlloyDB utilise votre clé pour chiffrer cette sauvegarde.
- Si vous activez CMEK avec la configuration de sauvegarde continue ou automatique de votre cluster, AlloyDB utilise votre clé pour chiffrer vos sauvegardes en cours.
Que vous utilisiez une Google-owned and Google-managed encryption keys ou une CMEK, AlloyDB dispose de trois couches de chiffrement:
AlloyDB divise les données au repos en fragments pour les stocker et chiffre chaque fragment avec une clé de chiffrement individuelle. La clé utilisée pour chiffrer les données contenues dans un fragment est appelée "clé de chiffrement des données" (DEK, Data Encryption Key).
En raison de la nécessité d'une faible latence et d'une disponibilité élevée, ainsi que du grand nombre de clés chez Google, AlloyDB stocke chaque DEK à proximité des données qu'elle chiffre.
AlloyDB chiffre chaque DEK à l'aide d'une clé de chiffrement de clé (KEK) détenue par le cluster.
Enfin, AlloyDB chiffre le KEK avec la clé de chiffrement basée sur Cloud Key Management Service de votre cluster, qui est une clé Google-owned and Google-managed encryption keyou une clé CMEK.
Vous pouvez également afficher les versions de clé utilisées pour protéger un cluster.
Activer CMEK
Pour autoriser un cluster AlloyDB à utiliser CMEK, vous devez spécifier la clé Cloud KMS au moment de la création du cluster.
AlloyDB peut accéder à la clé en votre nom après avoir attribué le rôle Chiffreur/Déchiffreur de CryptoKeys Cloud KMS (roles/cloudkms.cryptoKeyEncrypterDecrypter) à un agent de service AlloyDB.
Pour obtenir des instructions détaillées, consultez la page Utiliser CMEK.
Gérer les clés
Utilisez Cloud KMS pour toutes les opérations de gestion des clés. AlloyDB ne peut ni détecter, ni exploiter les modifications d'une clé avant que celles-ci ne soient propagées par Cloud KMS. La propagation de certaines opérations, telles que la désactivation ou la destruction d'une clé, peut prendre jusqu'à trois heures. Les modifications apportées aux autorisations se propagent généralement beaucoup plus rapidement.
Une fois le cluster créé, AlloyDB appelle Cloud KMS toutes les cinq minutes environ pour s'assurer que la clé est toujours valide.
Si AlloyDB détecte que votre clé Cloud KMS a été désactivée ou détruite, une opération visant à rendre les données de votre cluster inaccessibles commence immédiatement. Si les appels d'AlloyDB à Cloud KMS détectent qu'une clé précédemment désactivée a été réactivée, elle restaure automatiquement l'accès.
Utiliser et gérer des clés externes
Au lieu d'utiliser des clés stockées sur Cloud KMS, vous pouvez utiliser des clés stockées auprès d'un partenaire de gestion de clés externes compatible. Pour ce faire, utilisez Cloud External Key Manager (Cloud EKM) pour créer et gérer des clés externes, qui sont des pointeurs vers des clés situées en dehors de Google Cloud. Pour en savoir plus, consultez la section Cloud External Key Manager.
Une fois que vous avez créé une clé externe avec Cloud EKM, vous pouvez l'appliquer à un nouveau cluster AlloyDB en fournissant l'ID de cette clé lors de la création du cluster. Cette procédure est identique à celle d'application d'une clé Cloud KMS à un nouveau cluster.
Vous pouvez utiliser Key Access Justifications dans Cloud EKM. Key Access Justifications vous permet d'afficher le motif de chaque demande Cloud EKM. De plus, selon la justification fournie, vous pouvez approuver ou refuser automatiquement une requête. Pour en savoir plus, consultez la section Présentation.
Google ne contrôle pas la disponibilité des clés dans un système partenaire de gestion de clés externes.
Indisponibilité de la clé
Si vous désactivez la clé Cloud KMS utilisée pour chiffrer un cluster AlloyDB, les instances AlloyDB appartenant à ce cluster subiront un temps d'arrêt dans un délai de 30 minutes. Réactiver la clé rétablit les instances.
Dans de rares cas, par exemple pendant les périodes d'indisponibilité de Cloud KMS, AlloyDB peut ne pas être en mesure de récupérer l'état de votre clé à partir de Cloud KMS. Dans ce scénario, AlloyDB continue de prendre en charge les opérations de cluster complètes dans la mesure du possible pendant une période pouvant aller jusqu'à 30 minutes afin de minimiser l'impact de toute interruption temporaire sur votre charge de travail.
Au bout de 30 minutes, si AlloyDB ne parvient toujours pas à se connecter à Cloud KMS, il commence à mettre le cluster hors connexion par mesure de protection. Les données de votre cluster AlloyDB restent inaccessibles jusqu'à ce que votre cluster puisse se reconnecter à Cloud KMS et que Cloud KMS réponde que la clé est bien active.
Sauvegardes et restaurations
AlloyDB protège également les sauvegardes à l'aide de CMEK ou du chiffrement géré par Google par défaut. Si une sauvegarde est compatible avec les CMEK, elle est chiffrée à l'aide de la version principale de la clé KMS au moment de la création de la sauvegarde. Une fois une sauvegarde créée, la clé et la version de clé associées ne peuvent plus être modifiées, même si une rotation de clé KMS est appliquée. Pour en savoir plus, consultez la page Sauvegarder un cluster.
Lorsque vous restaurez un cluster à partir d'une sauvegarde, il utilise par défaut le chiffrement géré par Google, mais vous pouvez spécifier une clé CMEK à utiliser à la place. Pour restaurer une sauvegarde avec CMEK activé, la clé et la version de clé utilisées pour chiffrer la sauvegarde doivent être disponibles.
Journalisation
Vous pouvez auditer les requêtes envoyées par AlloyDB en votre nom à Cloud KMS dans Cloud Logging, si vous avez activé la journalisation d'audit pour l'API Cloud KMS dans votre projet. Ces entrées de journal Cloud KMS sont visibles dans Cloud Logging. Pour en savoir plus, consultez Afficher les journaux d'audit d'une clé Cloud KMS.