Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Chiffrement de base de données Amazon Redshift

Dans Amazon Redshift, votre base de données est chiffrée par défaut afin de protéger vos données au repos. Le chiffrement de base de données s'applique au cluster ainsi qu'à ses instantanés.

Vous pouvez modifier un cluster non chiffré pour utiliser le chiffrement AWS Key Management Service (AWS KMS). Pour ce faire, vous pouvez utiliser une clé AWS détenue ou une clé gérée par le client. Lorsque vous modifiez votre cluster pour activer le AWS KMS chiffrement, Amazon Redshift migre automatiquement vos données vers un nouveau cluster chiffré. Les instantanés créés à partir du cluster chiffré sont également chiffrés. Vous pouvez également migrer un cluster chiffré vers un cluster non chiffré en modifiant le cluster et en changeant l'option Chiffrer la base de données. Pour de plus amples informations, veuillez consulter Modification du chiffrement d'un cluster.

Bien que vous puissiez toujours transformer le cluster chiffré par défaut en cluster non chiffré après l'avoir créé, nous vous recommandons de conserver le cluster contenant des données sensibles tel que crypté. En outre, vous pouvez être contraint d'utiliser le chiffrement en fonction des directives ou règlements régissant vos données. Par exemple, la norme PCI DSS (Payment Card Industry Data Security Standard), les lois américaines Sarbanes-Oxley (SOX) et HIPAA (Health Insurance Portability et Accountability Act) et d'autres règlements similaires fournissent des directives permettant de gérer des types de données spécifiques.

Amazon Redshift utilise une hiérarchie de clés de chiffrement pour chiffrer la base de données. Vous pouvez utiliser AWS Key Management Service (AWS KMS) ou un module de sécurité matérielle (HSM) pour gérer les clés de chiffrement de niveau supérieur dans cette hiérarchie. Le processus qu'utilise Amazon Redshift pour le chiffrement diffère en fonction de la façon dont vous gérez les clés. Amazon Redshift s'intègre automatiquement à un HSM AWS KMS , mais pas à celui-ci. Lorsque vous utilisez un HSM, vous devez utiliser des certificats client et de serveur pour configurer une connexion approuvée entre Amazon Redshift et votre HSM.

Améliorations du processus de chiffrement pour améliorer les performances et la disponibilité

Chiffrement avec RA3 nœuds

Les mises à jour apportées au processus de chiffrement des RA3 nœuds ont considérablement amélioré l'expérience. Les requêtes de lecture et d'écriture peuvent être exécutées au cours du processus avec un impact moindre sur les performances du chiffrement. De plus, le chiffrement se termine beaucoup plus rapidement. Les étapes du processus mises à jour incluent une opération de restauration et la migration des métadonnées du cluster vers un cluster cible. L'expérience améliorée s'applique aux types de chiffrement tels que AWS KMS, par exemple. Lorsque vous disposez de volumes de données de l'ordre du pétaoctet, l'opération a été réduite de plusieurs semaines à quelques jours.

Avant de chiffrer votre cluster, si vous prévoyez de continuer à exécuter des charges de travail de base de données, vous pouvez améliorer les performances et accélérer le processus en ajoutant des nœuds avec un redimensionnement élastique. Vous ne pouvez pas utiliser le redimensionnement élastique lorsque le chiffrement est en cours, alors faites-le avant de chiffrer. Notez que l'ajout de nœuds entraîne généralement des coûts plus élevés.

Chiffrement avec d'autres types de nœuds

Lorsque vous chiffrez un cluster avec des DC2 nœuds, vous n'êtes pas en mesure d'exécuter des requêtes d'écriture, comme c'est le cas pour les RA3 nœuds. Seules les requêtes de lecture peuvent être exécutées.

Notes d'utilisation pour le chiffrement à l'aide de RA3 nœuds

Les informations et ressources suivantes vous aident à vous préparer au chiffrement et à surveiller le processus.

Chiffrement en utilisant AWS KMS

Lorsque vous optez AWS KMS pour la gestion des clés avec Amazon Redshift, il existe une hiérarchie à quatre niveaux de clés de chiffrement. Ces clés, par ordre hiérarchique, sont la clé racine, une clé de chiffrement du cluster (CEK), une clé de chiffrement de base de données (DEK) et les clés de chiffrement des données.

Lorsque vous lancez votre cluster, Amazon Redshift renvoie une liste de ceux AWS KMS keys qu'Amazon Redshift ou AWS votre compte a créés ou dans lesquels Amazon Redshift est autorisé à utiliser. AWS KMS Vous sélectionnez une clé KMS en guise de clé racine dans la hiérarchie de chiffrement.

Par défaut, Amazon Redshift sélectionne une clé propre générée automatiquement comme AWS clé racine pour votre AWS compte à utiliser dans Amazon Redshift.

Si vous ne souhaitez pas utiliser la clé par défaut, vous devez disposer (ou créer) une clé KMS gérée par le client séparément AWS KMS avant de lancer votre cluster dans Amazon Redshift. Les clés gérées par le client vous donnent davantage de flexibilité, en vous permettant notamment de créer, d'effectuer la rotation, de désactiver et de définir le contrôle d'accès, ainsi que de contrôler les clés de chiffrement utilisées pour protéger vos données. Pour plus d'informations sur la création d'une clé KMS, veuillez consulter Création de clés dans le Guide du développeur AWS Key Management Service .

Si vous souhaitez utiliser une AWS KMS clé d'un autre AWS compte, vous devez être autorisé à utiliser la clé et spécifier son Amazon Resource Name (ARN) dans Amazon Redshift. Pour plus d'informations sur l'accès aux clés AWS KMS, consultez la section Contrôle de l'accès à vos clés dans le guide du AWS Key Management Service développeur.

Une fois que vous avez choisi une clé racine, Amazon Redshift vous demande de AWS KMS générer une clé de données et de la chiffrer à l'aide de la clé racine sélectionnée. Cette clé de données est utilisée comme clé CEK dans Amazon Redshift. AWS KMS exporte la clé CEK chiffrée vers Amazon Redshift, où elle est stockée en interne sur un disque sur un réseau distinct du cluster avec l'affectation de la clé KMS et le contexte de chiffrement de la clé CEK. Seule la clé CEK chiffrée est exportée vers Amazon Redshift ; la clé KMS reste dans AWS KMS. Amazon Redshift transmet également au cluster la clé CEK chiffrée sur un canal sécurisé et la charge dans la mémoire. Amazon Redshift appelle ensuite AWS KMS pour déchiffrer le CEK et charge le CEK déchiffré en mémoire. Pour plus d'informations sur les subventions, le contexte de chiffrement et d'autres concepts AWS KMS connexes, consultez la section Concepts du guide du AWS Key Management Service développeur.

Ensuite, Amazon Redshift génère une clé de manière aléatoire à utiliser en tant que clé DEK et la charge en mémoire dans le cluster. La clé CEK déchiffrée est utilisée pour chiffrer la clé DEK, qui est ensuite transmise via un canal sécurisé depuis le cluster pour être stockée en interne par Amazon Redshift sur le disque dans un autre réseau que celui du cluster. A l'instar de la clé CEK, les versions chiffrées et déchiffrées de la clé DEK sont chargées en mémoire dans le cluster. La version déchiffrée de la clé DEK est ensuite utilisée pour chiffrer les clés de chiffrement individuelles qui sont générées de façon aléatoire pour chaque bloc de données de la base de données.

Lorsque le cluster redémarre, Amazon Redshift démarre avec les versions cryptées stockées en interne du CEK et du DEK, les recharge en mémoire, puis AWS KMS appelle pour déchiffrer à nouveau le CEK avec la clé KMS afin qu'il puisse être chargé en mémoire. La clé CEK déchiffrée est ensuite utilisée pour déchiffrer la clé DEK à nouveau, et la clé DEK déchiffré est chargée dans la mémoire et utilisée pour chiffrer et déchiffrer les clés de bloc de données en fonction des besoins.

Pour plus d'informations sur la création de clusters Amazon Redshift chiffrés à l'aide de AWS KMS clés, consultez. Création d’un cluster

Copier des instantanés AWS KMS chiffrés vers un autre Région AWS

AWS KMS les clés sont spécifiques à un Région AWS. Si vous souhaitez activer la copie d'instantanés Amazon Redshift d'un cluster source chiffré vers un autre Région AWS, mais que vous souhaitez utiliser votre propre AWS KMS clé pour les instantanés de destination, vous devez configurer une autorisation permettant à Amazon Redshift d'utiliser une clé racine dans votre compte de destination. Région AWS Cette subvention permet à Amazon Redshift de chiffrer les instantanés dans la destination. Région AWS Si vous souhaitez que les instantanés de destination soient chiffrés à l'aide d'une clé Région AWS détenue, vous n'avez pas besoin de configurer d'autorisations dans la destination. Région AWS Pour de plus amples informations sur la copie d'instantanés entre régions, veuillez consulter Copier un instantané dans une autre AWS région.

Le processus permettant de configurer l'autorisation de copier des instantanés est le suivant.

Ce processus précédent n'est nécessaire que si vous activez la copie des instantanés à l' AWS CLI aide de l'API Amazon Redshift ou. SDKs Si vous utilisez la console, Amazon Redshift fournit le flux de travail approprié pour configurer l'autorisation lorsque vous activez la copie d'instantanés entre régions. Pour de plus amples informations sur la configuration de copie d'instantanés entre régions pour les clusters chiffrés par AWS KMSà l'aide de la console, veuillez consulter Configuration de la copie instantanée entre régions pour un cluster AWS KMS chiffré.

Avant que l'instantané ne soit copié dans la AWS région de destination, Amazon Redshift le déchiffre à l'aide de la clé racine dans la AWS région source et le chiffre à nouveau temporairement à l'aide d'une clé RSA générée aléatoirement qu'Amazon Redshift gère en interne. Amazon Redshift copie ensuite l'instantané via un canal sécurisé vers la AWS région de destination, le déchiffre à l'aide de la clé RSA gérée en interne, puis le chiffre à nouveau à l'aide de la clé racine dans la région de destination. AWS

Chiffrement à l'aide de modules de sécurité matériels

Si vous ne l'utilisez pas AWS KMS pour la gestion des clés, vous pouvez utiliser un module de sécurité matérielle (HSM) pour la gestion des clés avec Amazon Redshift.

HSMs sont des dispositifs qui permettent de contrôler directement la génération et la gestion des clés. Ils offrent une plus grande sécurité en séparant la gestion des clés des couches application et base de données. Amazon Redshift prend en charge la AWS CloudHSM version classique pour la gestion des clés. Le processus de chiffrement est différent lorsque vous utilisez HSM pour gérer vos clés de chiffrement au lieu de AWS KMS.

Lorsque vous configurez votre cluster pour utiliser un HSM, Amazon Redshift envoie une requête au HSM pour générer et stocker une clé à utiliser comme CEK. Cependant, contrairement à cela AWS KMS, le HSM n'exporte pas le CEK vers Amazon Redshift. Au lieu de cela, Amazon Redshift génère de manière aléatoire la clé DEK dans le cluster et la transmet au HSM pour qu'elle soit chiffrée par la clé CEK. Le HSM renvoie la clé DEK chiffrée à Amazon Redshift, où elle est encore chiffrée à l'aide d'une clé racine interne générée de manière aléatoire et stockée en interne sur un disque sur un autre réseau que celui du cluster. Amazon Redshift charge également la version déchiffrée du DEK en mémoire dans le cluster afin que le DEK puisse être utilisé pour chiffrer et déchiffrer les clés individuelles des blocs de données.

Si le cluster est redémarré, Amazon Redshift déchiffre le DEK doublement chiffré stocké en interne à l'aide de la clé racine interne pour ramener le DEK stocké en interne à l'état chiffré CEK. Le DEK chiffré par CEK est ensuite transmis au HSM pour être déchiffré et renvoyé à Amazon Redshift, où il peut être rechargé en mémoire pour être utilisé avec les clés de bloc de données individuelles.

Configuration d'une connexion approuvée entre Amazon Redshift et un HSM

Lorsque vous optez pour utiliser un HSM pour la gestion de votre clé de cluster, vous devez configurer un lien réseau de confiance entre Amazon Redshift et votre HSM. Cela nécessite une configuration de certificats de client et de serveur. La connexion approuvée est utilisée pour transmettre les clés de chiffrement entre le HSM et Amazon Redshift pendant les opérations de chiffrement et de déchiffrement.

Amazon Redshift crée un certificat client public à partir d'une paire de clés privée et publique générée de manière aléatoire. Celles-ci sont chiffrées et stockées en interne. Vous téléchargez et enregistrez le certificat de client public dans votre HSM et l'affectez à la partition HSM applicable.

Vous fournissez à Amazon Redshift l'adresse IP du HSM, le nom de la partition HSM, le mot de passe de la partition HSM et un certificat public du serveur HSM, qui est chiffré à l'aide d'une clé racine interne. Amazon Redshift termine le processus de configuration et vérifie qu'il peut se connecter au HSM. S'il ne peut pas, le cluster est passé à l'État INCOMPATIBLE_HSM et le cluster n'est pas créé. Dans ce cas, vous devez supprimer le cluster incomplet, puis réessayer.

Après la configuration initiale, si Amazon Redshift ne parvient pas à se connecter au HSM, un événement est enregistré. Pour plus d'informations sur ces événements, veuillez consulter Notifications d'événements Amazon Redshift.

Rotation des clés de chiffrement

Dans Amazon Redshift, vous pouvez effectuer une rotation des clés de chiffrement pour les clusters chiffrés. Lorsque vous démarrez le processus de rotation des clés, Amazon Redshift effectue une rotation de la clé CEK pour le cluster spécifié et pour les instantanés automatiques ou manuels du cluster. Amazon Redshift effectue également une rotation de la clé DEK pour le cluster spécifié, mais ne peut pas effectuer une rotation de la clé DEK pour les instantanés pendant qu'ils sont stockés en interne dans Amazon Simple Storage Service (Amazon S3) et chiffrés à l'aide de la clé DEK existante.

Pendant que la rotation est en cours, le cluster est mis dans l'état ROTATING_KEYS jusqu'à ce qu'il soit terminé, auquel cas le cluster retourne à l'état AVAILABLE. Amazon Redshift gère le déchiffrement et le rechiffrement pendant le processus de rotation des clés.

Etant donné que le cluster est temporairement indisponible pendant le processus de rotation des clés, vous devez effectuer la rotation des clés uniquement dès que les données le nécessitent ou lorsque vous pensez que les clés ont été volées. La bonne pratique consiste à examiner le type de données que vous stockez et à prévoir à quelle fréquence effectuer la rotation des clés de chiffrement des données. La fréquence à laquelle effectuer la rotation des clés varie en fonction de vos stratégies d'entreprise concernant la sécurité des données et des normes du secteur relatives aux données sensibles et à la conformité réglementaire. Assurez-vous que votre plan tient compte des besoins en matière de sécurité autant que des considérations concernant la disponibilité de votre cluster.

Pour plus d'informations sur la rotation des touches, consultezRotation des clés de chiffrement.