Notes d'utilisation du chiffrement de DynamoDB au repos - Amazon DynamoDB

Notes d'utilisation du chiffrement de DynamoDB au repos

Lorsque vous utilisez un chiffrement au repos dans Amazon DynamoDB, tenez compte des considérations suivantes.

Toutes les données des tables sont chiffrées

Le chiffrement au repos côté serveur est activé sur toutes les données de tables DynamoDB et ne peut pas être désactivé. Vous ne pouvez pas chiffrer uniquement un sous-ensemble d'éléments dans une table. DynamoDB a chiffré toutes les tables existantes qui étaient précédemment non chiffrées à l'aide de la clé Clé détenue par AWS.

La fonction de chiffrement au repos chiffre uniquement les données lorsque qu'elles sont statiques (au repos) sur un support de stockage permanent. Si la sécurité des données est un élément important pour les données en transit ou en cours d'utilisation, vous devrez peut-être prendre des mesures supplémentaires :

  • Données en transit : toutes vos données dans DynamoDB sont chiffrées en transit (à l'exception des données dans DAX). Par défaut, les communications avec DynamoDB utilisent le protocole HTTPS qui protège le trafic réseau à l'aide du chiffrement Secure Sockets Layer (SSL)/Transport Layer Security (TLS).

  • Données en cours d'utilisation : protégez vos données avant de les envoyer à DynamoDB à l'aide d'un chiffrement côté client. Pour plus d'informations, consultez Chiffrement côté client et côté serveur dans le Guide du développeur de client de chiffrement Amazon DynamoDB.

Vous pouvez utiliser des flux avec des tables chiffrées. Les flux de DynamoDB sont toujours chiffrés avec une clé de chiffrement au niveau de la table. Pour plus d'informations, consultez Modifier la récupération de données pour DynamoDB Streams.

Les sauvegardes de DynamoDB sont chiffrées, et le chiffrement est également activé dans les tables restaurées à partir de ces sauvegardes. Vous pouvez utiliser la clé Clé détenue par AWS, la clé Clé gérée par AWS ou la clé gérée par le client pour chiffrer vos données de sauvegarde. Pour plus d'informations, consultez Utilisation de la sauvegarde et de la restauration à la demande pour DynamoDB.

Les index secondaires locaux et les index secondaires globaux sont chiffrés à l'aide de la même clé que la table de base.

Types de chiffrement

Note

La clé CMK (clé gérée par le client) n'est pas prise en charge dans Global Table Version 2017. Si vous souhaitez utiliser une CMK dans une DynamoDB Global Table, vous devez mettre à niveau la table vers Global Table Version 2019, puis l'activer.

Sur l'AWS Management Console, le type de chiffrement est KMS lorsque vous utilisez la clé Clé gérée par AWS ou la clé gérée par le client pour chiffrer vos données. Le type de chiffrement est DEFAULT lorsque vous utilisez la clé Clé détenue par AWS. Dans l'API Amazon DynamoDB, le type de chiffrement est KMS lorsque vous utilisez la clé Clé gérée par AWS ou la clé gérée par le client. Si le type de chiffrement n'est pas spécifié, vos données sont chiffrées avec la clé Clé détenue par AWS. Vous pouvez basculer à tout moment entre la clé Clé détenue par AWS, la clé Clé gérée par AWS et la clé gérée par le client. Vous pouvez utiliser la console, l'AWS Command Line Interface (AWS CLI), ou l'API Amazon DynamoDB pour changer les clés de chiffrement.

Notez que les limites suivantes s'appliquent lors de l'utilisation des clés gérées par le client :

  • Vous ne pouvez pas utiliser une clé gérée par le client avec des clusters DynamoDB Accelerator (DAX). Pour plus d'informations, consultez Chiffrement au repos DAX.

  • Vous pouvez utiliser une clé gérée par le client pour chiffrer les tables qui utilisent des transactions. Cependant, pour assurer la durabilité de la propagation des transactions, une copie de la demande de transaction est temporairement stockée par le service et chiffrée à l'aide d'une clé Clé détenue par AWS. Les données validées dans vos tables et index secondaires sont toujours chiffrées au repos à l'aide de votre clé gérée par le client.

  • Vous pouvez utiliser une clé gérée par le client pour chiffrer les tables qui utilisent Contributor Insights. Toutefois, les données transmises à Amazon CloudWatch sont chiffrées avec une clé Clé détenue par AWS.

  • Lorsque vous passez à une nouvelle clé gérée par le client, veillez à conserver la clé d'origine activée jusqu'à la fin du processus.AWSaura toujours besoin de la clé d'origine pour déchiffrer les données avant de les chiffrer avec la nouvelle clé. Le processus sera terminé lorsque le statut SSEDescription de la table est ACTIVÉ et que le KMSMasterKeyarn de la nouvelle clé gérée par le client est affiché. À ce stade, la clé d'origine peut être désactivée ou planifiée en vue de sa suppression.

  • Une fois la nouvelle clé gérée par le client affichée, la table et toutes les nouvelles sauvegardes à la demande sont chiffrées avec la nouvelle clé.

  • Toutes les sauvegardes à la demande existantes restent chiffrées avec la clé gérée par le client utilisée lors de la création de ces sauvegardes. Vous aurez besoin de la même clé pour restaurer ces sauvegardes. Vous pouvez identifier la clé pour la période pendant laquelle chaque sauvegarde a été créée à l'aide de l'API DescribeBackup, pour afficher la valeur SSEDescription de cette sauvegarde.

  • Si vous désactivez votre clé gérée par le client ou planifiez sa suppression, toutes les données dans DynamoDB Streams restent sujettes à une durée de vie de 24 heures. Toutes les données d'activité non récupérées sont éligibles à la suppression lorsqu'elles ont plus de 24 heures.

  • Si vous désactivez votre clé gérée par le client ou planifiez sa suppression, les suppressions liées au Time-to-live (TTL) continuent pendant 30 minutes. Ces suppressions TTL continuent d'être effectuées dans DynamoDB Streams et sont sujettes à un intervalle de suppression/conservation standard.