Amazon Redshift ne prendra plus en charge la création de nouvelles fonctions Python définies par l’utilisateur à compter du 1er novembre 2025. Si vous souhaitez utiliser des fonctions Python définies par l’utilisateur, créez-les avant cette date. Les fonctions Python définies par l’utilisateur existantes continueront de fonctionner normalement. Pour plus d’informations, consultez le billet de blog .

Chiffrement de base de données Amazon Redshift

Dans Amazon Redshift, votre base de données est chiffrée par défaut pour protéger vos données au repos. Le chiffrement de base de données s’applique au cluster et à 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 soit une clé détenue par AWS, soit une clé gérée par le client. Lorsque vous modifiez votre cluster pour activer le chiffrement AWS KMS, 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 plus d’informations, consultez 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 chiffrement d’un cluster contenant des données sensibles. 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 à AWS KMS mais pas à un HSM. 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 des nœuds RA3

Les mises à jour du processus de chiffrement pour les nœuds RA3 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 nœuds DC2, vous n’avez pas la possibilité d’exécuter des requêtes d’écriture, comme c’est le cas avec les nœuds RA3. Seules les requêtes de lecture peuvent être exécutées.

Notes d'utilisation pour le chiffrement avec des nœuds RA3

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

Chiffrement à l'aide d' AWS KMS

Lorsque vous choisissez AWS KMS pour la gestion des clés avec Amazon Redshift, il existe une hiérarchie à quatre niveaux des 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 des AWS KMS keys qu’Amazon Redshift ou votre compte AWS a créées ou est autorisé à utiliser dans 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é détenue par AWS générée automatiquement comme clé racine pour votre compte AWS à utiliser dans Amazon Redshift.

Si vous ne voulez pas utiliser la clé par défaut, vous devez disposer d'une clé KMS gérée par le client (ou en créer une) séparément dans 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 clé AWS KMS d'un autre compte AWS, vous devez avoir l'autorisation d'utiliser cette clé et spécifier son Amazon Resource Name (ARN) dans Amazon Redshift. Pour plus d'informations sur l'accès aux clés dans AWS KMS, veuillez consulter la rubrique Contrôler l'accès à vos clés dans le Guide du développeur AWS Key Management Service.

Une fois que vous choisissez une clé racine, Amazon Redshift demande à AWS KMS de 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. Puis, Amazon Redshift appelle AWS KMS pour déchiffrer la clé CEK et charge la clé CEK déchiffrée dans la mémoire. Pour plus d'informations sur les affectations, le contexte de chiffrement et les autres concepts liés à AWS KMS, veuillez consulter la rubrique Concepts dans le Guide du développeur AWS Key Management Service.

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 commence par les versions stockées en interne et chiffrées des clés CEK et DEK, les recharge dans la mémoire, puis appelle AWS KMS pour déchiffrer la clé CEK avec la clé KMS à nouveau afin qu'elle puisse être chargée 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 avec des clés AWS KMS, consultez Création d’un cluster.

Copie d’instantanés chiffrés par AWS KMS dans une autre Région AWS

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

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

Ce processus préalable n'est nécessaire que si vous activez la copie des instantanés à l'aide de l'AWS CLI, l'API Amazon Redshift ou des kits SDK. 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 d’une copie d’instantané entre régions pour un cluster chiffré par AWS KMS.

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

Chiffrement à l’aide de modules de sécurité matérielle

Si vous n'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.

Les HSM 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 AWS CloudHSM Classic 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. Toutefois, contrairement à AWS KMS, le HSM n'exporte pas la clé 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 clés, consultez Rotation des clés de chiffrement.