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.
Pour obtenir un guide par étapes sur l'utilisation de CMEK avec AlloyDB, consultez la section Utiliser CMEK.
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 celles 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.