Amazon Redshift ne prendra plus en charge la création de nouveaux Python à UDFs partir du patch 198. UDFs Le Python existant continuera de fonctionner jusqu'au 30 juin 2026. Pour plus d’informations, consultez le [ billet de blog ](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). 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 des données La protection des données consiste à protéger les données en transit (lorsqu’elles se déplacent vers et depuis Amazon Redshift) et au repos (lorsqu’elles sont stockées sur des disques dans les centres de données Amazon Redshift). Vous pouvez protéger les données en transit en utilisant SSL ou un chiffrement côté client. Vous disposez des options suivantes pour protéger les données au repos dans Amazon Redshift. + **Utilisation du chiffrement côté serveur** – Vous demandez à Amazon Redshift de chiffrer vos données avant de les enregistrer sur les disques dans ses centres de données et de les déchiffrer lorsque vous téléchargez les objets. + **Utilisation du chiffrement côté client** – Vous pouvez chiffrer les données côté client et charger ces dernières sur Amazon Redshift. Dans ce cas, vous gérez le processus de chiffrement, les clés de chiffrement et les outils associés. # Chiffrement au repos Le cryptage côté serveur concerne le chiffrement des données au repos, c’est-à-dire qu’Amazon Redshift chiffre en option vos données lorsqu’il les écrit dans ses centres de données et les déchiffre pour vous lorsque vous y accédez. Tant que vous authentifiez votre demande et que vous avez des autorisations d’accès, il n’y a aucune différence dans la manière dont vous accédez aux données chiffrées ou déchiffrées. Amazon Redshift protège les données au repos grâce au chiffrement. En option, vous pouvez protéger toutes les données stockées sur les disques d’un cluster et toutes les sauvegardes dans Amazon S3 avec Advanced Encryption Standard AES-256. [Pour gérer les clés utilisées pour chiffrer et déchiffrer vos ressources Amazon Redshift, vous utilisez (). AWS Key Management ServiceAWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/) AWS KMScombine du matériel et des logiciels sécurisés et hautement disponibles pour fournir un système de gestion des clés adapté au cloud. À l'aide deAWS KMS, vous pouvez créer des clés de chiffrement et définir les politiques qui contrôlent la manière dont ces clés peuvent être utilisées. AWS KMSprend en chargeAWS CloudTrail, afin que vous puissiez auditer l'utilisation des clés pour vérifier que les clés sont utilisées de manière appropriée. Vous pouvez utiliser vos AWS KMS clés en combinaison avec Amazon Redshift et les services pris en chargeAWS. Pour obtenir la liste des services compatiblesAWS KMS, consultez la section [Comment les AWS services sont utilisés AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/services.html) dans le *guide du AWS Key Management Service développeur*. Si vous choisissez de gérer le mot de passe administrateur de votre cluster provisionné ou de votre espace de noms sans serveur en utilisant, Amazon AWS Secrets Manager Redshift accepte également une clé AWS KMS supplémentaire qui AWS Secrets Manager permet de chiffrer vos informations d'identification. Cette clé supplémentaire peut être une clé générée automatiquement ou une clé personnalisée que vous fournissez. AWS Secrets Manager L’éditeur de requête Amazon Redshift v2 stocke en toute sécurité les informations saisies dans l’éditeur de requête comme suit : + L’Amazon Resource Name (ARN) de la clé KMS à utiliser pour chiffrer les données de l’éditeur de requête v2. + Informations de connexion à la base de données. + Les noms et le contenu des fichiers et des dossiers. L’éditeur de requête Amazon Redshift v2 chiffre les informations à l’aide d’un chiffrement de niveau bloc avec votre clé KMS ou la clé KMS du compte de service. Le chiffrement de vos données Amazon Redshift est contrôlé par les propriétés de votre cluster Amazon Redshift. **Topics** + [Chiffrement de base de données Amazon Redshift](working-with-db-encryption.md) # 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 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 plus d’informations, consultez [Modification du chiffrement d’un cluster](changing-cluster-encryption.md). 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 à 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. **Important** Amazon Redshift peut perdre l’accès à la clé KMS pour un cluster alloué ou un espace de noms sans serveur lorsque vous désactivez la clé KMS gérée par le client. Dans ces cas, Amazon Redshift effectue une sauvegarde de l’entrepôt de données Amazon Redshift et la met dans l’état `inaccessible-kms-key` pendant 14 jours. Si vous restaurez la clé KMS pendant cette période, Amazon Redshift rétablira l’accès et l’entrepôt fonctionnera normalement. Si la période de 14 jours prend fin sans que la clé KMS soit restaurée, Amazon Redshift supprimera l’entrepôt de données. Lorsqu’un entrepôt est en état `inaccessible-kms-key`, il présente les caractéristiques suivantes : Vous ne pouvez exécuter aucune requête sur l’entrepôt de données. Si l’entrepôt de données est l’entrepôt producteur d’une unité de partage des données, vous ne pouvez pas exécuter de requêtes de partage de données à partir d’entrepôts de consommateurs. Vous ne pouvez pas créer d’instantanés entre régions. Pour plus d’informations sur la restauration d’une clé KMS désactivée, consultez la section [Activer et désactiver les clés](https://docs.aws.amazon.com/kms/latest/developerguide/enabling-keys.html) dans le *Guide du développeur AWS Key Management Service *. Si la clé KMS de l’entrepôt a été supprimée, vous pouvez utiliser la sauvegarde pour créer un nouvel entrepôt de données avant que l’entrepôt en état `inaccessible-kms-key` ne soit supprimé. ## 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. + **Exécution de requêtes après le démarrage du chiffrement** : une fois le chiffrement démarré, les lectures et les écritures sont disponibles en quinze minutes environ. La durée du processus de chiffrement complet dépend de la quantité de données sur le cluster et des niveaux de charge de travail. + **Combien de temps dure le chiffrement ?** – Le temps nécessaire pour chiffrer vos données dépend de plusieurs facteurs, notamment du nombre de charges de travail en cours d'exécution, des ressources de calcul utilisées, du nombre de nœuds et du type de nœuds. Nous vous recommandons d'effectuer d'abord le chiffrement dans un environnement de test. En règle générale, si vous travaillez avec des volumes de données en pétaoctets, le chiffrement peut prendre entre 1 et 3 jours. + **Comment savoir si le chiffrement est terminé ?** — Une fois le chiffrement activé, la fin du premier instantané confirme que le chiffrement est terminé. + **Annulation du chiffrement** : si vous devez annuler l'opération de chiffrement, la meilleure méthode consiste à effectuer une restauration à partir de la sauvegarde la plus récente effectuée avant le lancement du chiffrement. Vous devrez réappliquer toute nouvelle mise à jour (updates/deletes/inserts) après la dernière sauvegarde. + **Exécution d'une restauration de table** : notez que vous ne pouvez pas restaurer une table d'un cluster non chiffré vers un cluster chiffré. + **Chiffrement d'un cluster à nœud unique** : le chiffrement d'un cluster à nœud unique présente des limites de performances. Cela prend plus de temps que le chiffrement pour un cluster multi-nœuds. + **Création d'une sauvegarde après chiffrement** : lorsque vous chiffrez les données de votre cluster, aucune sauvegarde n'est créée tant que le cluster n'est pas entièrement chiffré. Le temps que cela prend peut varier. La durée de la sauvegarde peut aller de quelques heures à plusieurs jours, selon la taille du cluster. Une fois le chiffrement terminé, il peut s'écouler un certain temps avant que vous puissiez créer une sauvegarde. Notez qu'étant donné qu'une backup-and-restore opération a lieu pendant le processus de chiffrement, les tables ou les vues matérialisées créées avec `BACKUP NO` ne sont pas conservées. Pour plus d'informations, consultez [CREATE TABLE](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_TABLE_NEW.html) ou [CREATE MATERIALIZED VIEW](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-create-sql-command.html). **Topics** + [Améliorations du processus de chiffrement pour améliorer les performances et la disponibilité](#resize-classic-encryption) + [Chiffrement en utilisant AWS KMS](#working-with-aws-kms) + [Chiffrement à l’aide de modules de sécurité matérielle](#working-with-HSM) + [Rotation des clés de chiffrement](#working-with-key-rotation) + [Modification du chiffrement d’un cluster](changing-cluster-encryption.md) + [Migration vers un cluster chiffré avec HSM](migrating-to-an-encrypted-cluster.md) + [Rotation des clés de chiffrement](manage-key-rotation-console.md) ## 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](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) 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](https://docs.aws.amazon.com/kms/latest/developerguide/control-access.html) 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](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html) 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 avec des clés AWS KMS , consultez [Création d’un cluster](create-cluster.md). ### 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 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é 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](cross-region-snapshot-copy.md). **Note** Si vous activez la copie d'instantanés à partir d'un cluster chiffré et que vous l'utilisez AWS KMS comme clé racine, vous ne pouvez pas renommer votre cluster car le nom du cluster fait partie du contexte de chiffrement. Si vous devez renommer votre cluster, vous pouvez désactiver la copie des instantanés dans la AWS région source, renommer le cluster, puis configurer et réactiver la copie des instantanés. Le processus permettant de configurer l'autorisation de copier des instantanés est le suivant. 1. Dans la AWS région de destination, créez une autorisation de copie instantanée en procédant comme suit : + Si vous n'avez pas encore de AWS KMS clé à utiliser, créez-en une. Pour plus d'informations sur la création de AWS KMS clés, consultez la section [Création de clés](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) dans le *guide du AWS Key Management Service développeur*. + Spécifiez un nom pour l'autorisation de copie d'instantanés. Ce nom doit être unique dans cette AWS région pour votre AWS compte. + Spécifiez l'ID AWS KMS clé pour lequel vous créez la subvention. Si vous ne spécifiez pas d'ID de clé, l'autorisation s'applique à votre clé par défaut. 1. Dans la AWS région source, activez la copie des instantanés et spécifiez le nom de la licence de copie d'instantanés que vous avez créée dans la AWS région de destination. 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é](xregioncopy-kms-encrypted-snapshot.md). 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érielle 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. **Important** Le chiffrement HSM n'est pas pris en charge pour les types DC2 de RA3 nœuds et. 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. **Important** Amazon Redshift prend uniquement AWS CloudHSM en charge la version classique. Nous ne prenons pas en charge le nouveau AWS CloudHSM service. AWS CloudHSM Classic est fermé aux nouveaux clients. Pour plus d'informations, consultez la section [Tarification de CloudHSM Classic](https://aws.amazon.com/cloudhsm/pricing-classic/). AWS CloudHSM La version classique n'est pas disponible dans toutes les AWS régions. Pour plus d'informations sur AWS les régions disponibles, consultez le [tableau des AWS régions](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/). 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\$1HSM et le cluster n'est pas créé. Dans ce cas, vous devez supprimer le cluster incomplet, puis réessayer. **Important** Lorsque vous modifiez votre cluster pour utiliser une partition HSM différente, Amazon Redshift vérifie qu'il peut se connecter à la nouvelle partition, mais il ne vérifie pas qu'une clé de chiffrement valide existe. Avant d'utiliser la nouvelle partition, vous devez répliquer vos clés sur la nouvelle partition. Si le cluster est redémarré et qu'Amazon Redshift ne trouve pas de clé valide, le redémarrage échoue. Pour plus d'informations, consultez la section [Réplication des clés entre elles. HSMs](https://docs.aws.amazon.com/cloudhsm/latest/userguide/cli-clone-hapg.html) 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](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-event-notifications.html). ## 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\$1KEYS 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. **Note** Vous ne pouvez pas effectuer une rotation des clés pour des instantanés sans cluster source. Avant de supprimer un cluster, demandez-vous si ses instantanés reposent sur la 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](manage-key-rotation-console.md). # Modification du chiffrement d’un cluster Vous pouvez modifier un cluster non chiffré pour utiliser le chiffrement AWS Key Management Service (AWS KMS) à l'aide d'une clé AWS détenue ou d'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é. Vous pouvez également migrer un cluster chiffré vers un cluster non chiffré en modifiant le cluster avec le AWS CLI, mais pas avec le AWS Management Console. Pendant l'opération de migration, votre cluster est disponible en mode lecture seule et son statut est **redimensionnement en cours**. Si votre cluster est configuré pour activer la copie instantanée AWS entre régions, vous devez la désactiver avant de modifier le chiffrement. Pour plus d’informations, consultez [Copier un instantané dans une autre AWS région](cross-region-snapshot-copy.md) et [Configuration de la copie instantanée entre régions pour un cluster AWS KMS chiffré](xregioncopy-kms-encrypted-snapshot.md). Vous ne pouvez pas activer le chiffrement HSM (module de sécurité matérielle) en modifiant le cluster. À la place, créez un nouveau cluster chiffré avec HSM et migrez vos données vers le nouveau cluster. Pour de plus amples informations, veuillez consulter [Migration vers un cluster chiffré avec HSM](migrating-to-an-encrypted-cluster.md). ------ #### [ Amazon Redshift console ] 1. Connectez-vous à la console Amazon Redshift AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/) 1. Dans le menu de navigation, choisissez **Clusters**, puis sélectionnez le cluster pour lequel vous souhaitez modifier les clés de chiffrement. 1. Choisissez **Propriétés**. 1. Dans **Configurations de base de données**, choisissez **Modifier**, puis **Modification du chiffrement**. 1. Choisissez l'une des options de chiffrement et **Enregistrez les modifications**. ------ #### [ AWS CLI ] Pour modifier le cluster non chiffré à utiliser AWS KMS, exécutez la commande `modify-cluster` CLI et spécifiez`–-encrypted`, comme indiqué ci-dessous. Par défaut, votre clé KMS par défaut est utilisée. Pour spécifier une clé gérée par le client, incluez l'option `--kms-key-id`. ``` aws redshift modify-cluster --cluster-identifier --encrypted --kms-key-id ``` Pour supprimer le chiffrement de votre cluster, exécutez la commande suivante de l'interface de ligne de commande. ``` aws redshift modify-cluster --cluster-identifier --no-encrypted ``` ------ # Migration vers un cluster chiffré avec HSM Pour migrer un cluster non chiffré vers un cluster chiffré en utilisant un module de sécurité matérielle (HSM), vous créez un nouveau cluster chiffré et déplacez vos données vers le nouveau cluster. Vous ne pouvez pas migrer vers un cluster chiffré par HSM en modifiant le cluster. Pour migrer d'un cluster non chiffré vers un cluster chiffré avec HSM, vous devez d'abord décharger vos données du cluster source existant. Vous devez ensuite les recharger dans un nouveau cluster cible avec le paramètre de chiffrement choisi. Pour plus d’informations sur le lancement d’un cluster chiffré, consultez [Chiffrement de base de données Amazon Redshift](working-with-db-encryption.md). Jusqu'à la dernière étape du processus de migration, votre cluster source reste disponible pour les requêtes en lecture seule. La dernière étape consiste à renommer les clusters source et cible afin de permuter les points de terminaison de manière à ce que la totalité du trafic soit redirigée vers le nouveau cluster cible. Le cluster cible est indisponible tant que vous ne l'avez pas redémarré après l'avoir renommé. Suspendez tous les chargements de données et autres opérations en écriture sur le cluster source pendant le transfert des données. **Pour préparer la migration** 1. Identifiez tous les systèmes dépendants qui interagissent avec Amazon Redshift, par exemple les outils de Business Intelligence (BI) et les systèmes Extract-transform-load (ETL). 1. Identifiez les requêtes de validation permettant de tester la migration. Par exemple, vous pouvez utiliser la requête suivante pour trouver le nombre de tables définies par l'utilisateur. ``` select count(*) from pg_table_def where schemaname != 'pg_catalog'; ``` La requête suivante renvoie la liste de toutes les tables définies par l'utilisateur et le nombre de lignes de chacune d'entre elles. ``` select "table", tbl_rows from svv_table_info; ``` 1. Choisissez le moment opportun pour réaliser la migration. Pour savoir quand l'utilisation du cluster est à son plus bas, surveillez les mesures relatives au cluster, notamment l'utilisation de la CPU et le nombre de connexions à la base de données. Pour plus d’informations, consultez [Affichage des données de performances de cluster](performance-metrics-perf.md). 1. Ignorez les tables inutilisées. Pour obtenir la liste des tables et la fréquence d'interrogation de chacune, exécutez la requête suivante. ``` select database, schema, table_id, "table", round(size::float/(1024*1024)::float,2) as size, sortkey1, nvl(s.num_qs,0) num_qs from svv_table_info t left join (select tbl, perm_table_name, count(distinct query) num_qs from stl_scan s where s.userid > 1 and s.perm_table_name not in ('Internal worktable','S3') group by tbl, perm_table_name) s on s.tbl = t.table_id where t."schema" not in ('pg_internal'); ``` 1. Lancez un nouveau cluster chiffré. Indiquez le même numéro de port pour le cluster cible que celui qu'utilisait le cluster source. Pour plus d’informations sur le lancement d’un cluster chiffré, consultez [Chiffrement de base de données Amazon Redshift](working-with-db-encryption.md). 1. Configurez les processus de déchargement et chargement des données. Vous pouvez utiliser l'[ Unload/Copy utilitaire Amazon Redshift](https://github.com/awslabs/amazon-redshift-utils/tree/master/src/UnloadCopyUtility) pour vous aider à migrer des données entre des clusters. L'utilitaire exporte les données depuis le cluster source vers un emplacement sur Amazon S3. Les données sont cryptées avec AWS KMS. L'utilitaire importe ensuite automatiquement les données sur le cluster cible. En option, vous pouvez utiliser l'utilitaire pour nettoyer Amazon S3 une fois la migration terminée. 1. Effectuez un test afin de vérifier que le processus fonctionne et d'estimer la durée pendant laquelle les opérations en écriture doivent être suspendues. Lors des opérations de déchargement et chargement des données, vous devez préserver la cohérence des données en suspendant tous les chargements habituels et autres opérations en écriture. Utilisez l'une de vos plus grandes tables pour exécuter le test de déchargement/chargement et estimer les délais requis. 1. Créez des objets de base de données, tels que des schémas, vues ou tables. Pour vous aider à générer les instructions DDL (Data Definition Language) nécessaires, vous pouvez utiliser [AdminViews](https://github.com/awslabs/amazon-redshift-utils/tree/master/src/AdminViews)les scripts du AWS GitHub référentiel. **Pour migrer votre cluster** 1. Arrêtez tous les processus ETL sur le cluster source. Pour vérifier qu'il n'y a aucune opération d'écriture en cours, utilisez la console de gestion Amazon Redshift afin de surveiller les IOPS d'écriture. Pour plus d’informations, consultez [Affichage des données de performances de cluster](performance-metrics-perf.md). 1. Exécutez les requêtes de validation que vous avez identifiées précédemment afin de collecter des informations sur le cluster source chiffré avant de procéder à la migration. 1. (Facultatif) Créez une file d'attente de gestion de la charge de travail (WLM) pour exploiter le maximum de ressources disponibles à la fois dans le cluster source et le cible. Par exemple, créez une file d'attente nommée `data_migrate` et configurez-la avec 95 % de mémoire et un niveau de simultanéité de 4. Pour de plus amples informations, veuillez consulter la rubrique [Acheminement des requêtes vers les files d'attente](https://docs.aws.amazon.com/redshift/latest/dg/tutorial-wlm-routing-queries-to-queues.html) dans le *Guide du développeur de bases de données Amazon Redshift*. 1. À l'aide de la `data_migrate` file d'attente, exécutez le UnloadCopyUtility. Surveillez la progression des opérations UNLOAD et COPY à l'aide de la console Amazon Redshift. 1. Exécutez à nouveau les requêtes de validation et vérifiez que leurs résultats correspondent à ceux du cluster source. 1. Renommez vos clusters source et cible pour permuter les points de terminaison. Pour éviter une interruption de l'activité, effectuez cette opération en dehors des heures de travail, 1. Vérifiez que vous pouvez vous connecter au cluster cible à partir de tous vos clients SQL, notamment via les outils ETL et de génération de rapports. 1. Fermez le cluster source non chiffré. # Rotation des clés de chiffrement Vous pouvez utiliser la procédure suivante pour effectuer une rotation des clés de chiffrement avec Amazon Redshift. **Pour effectuer une rotation des clés de chiffrement pour un cluster.** 1. Connectez-vous à la console Amazon Redshift AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/) 1. Dans le menu de navigation, choisissez **Clusters**, puis le cluster pour lequel vous souhaitez mettre à jour les clés de chiffrement. 1. Pour **Actions**, choisissez **Rotate encryption (Effectuer une rotation du chiffrement)** pour afficher la page **Rotate encryption keys (Effectuer une rotation des clés de chiffrement)**. 1. Sur la page **Rotate encryption keys (Effectuer une rotation des clés de chiffrement)**, choisissez **Rotate encryption keys (Effectuer une rotation des clés de chiffrement)**. # Chiffrement en transit Vous pouvez configurer votre environnement pour protéger la confidentialité et l’intégrité des données en transit. Les détails suivants s’appliquent au chiffrement de données en transit entre un cluster Amazon Redshift et des clients SQL sur JDBC/ODBC : + Vous pouvez vous connecter aux clusters Amazon Redshift depuis les outils clients SQL via des connexions Java Database Connectivity (JDBC) et Open Database Connectivity (ODBC). + Amazon Redshift prend en charge les connexions SSL (Secure Sockets Layer) pour chiffrer les données et les certificats de serveur pour valider le certificat du serveur auquel le client se connecte. Le client se connecte au nœud principal d’un cluster Amazon Redshift. Pour de plus amples informations, veuillez consulter [Configuration des options de sécurité des connexions](connecting-ssl-support.md). + Pour prendre en charge les connexions SSL, Amazon Redshift crée et installe AWS Certificate Manager (ACM) des certificats émis sur chaque cluster. Pour de plus amples informations, veuillez consulter [Transition vers les certificats ACM pour les connexions SSL](connecting-transitioning-to-acm-certs.md). + Pour protéger vos données en transit dans le AWS cloud, Amazon Redshift utilise le protocole SSL à accélération matérielle pour communiquer avec Amazon S3 ou Amazon DynamoDB pour les opérations de copie, de déchargement, de sauvegarde et de restauration. Les détails suivants s’appliquent au chiffrement de données en transit entre un cluster Amazon Redshift et Amazon S3 ou DynamoDB : + Amazon Redshift utilise l’accélération matérielle SSL afin de communiquer avec Amazon S3 ou DynamoDB pour les opérations de copie (COPY), de déchargement (UNLOAD), de sauvegarde et de restauration. + Redshift Spectrum prend en charge le chiffrement côté serveur (SSE) Amazon S3 à l'aide de la clé par défaut de votre compte gérée par le AWS Key Management Service (KMS). + Vous pouvez chiffrer les charges Amazon Redshift avec Amazon S3 et. AWS KMS Pour plus d'informations, consultez [Chiffrer vos charges Amazon Redshift avec Amazon S3](https://aws.amazon.com/blogs/big-data/encrypt-your-amazon-redshift-loads-with-amazon-s3-and-aws-kms/) et. AWS KMS Les informations suivantes s'appliquent au chiffrement et à la signature des données en transit entre les AWS CLI clients du SDK ou de l'API et les points de terminaison Amazon Redshift : + Amazon Redshift fournit des points de terminaison HTTPS pour le chiffrement des données en transit. + Pour protéger l’intégrité des requêtes d’API adressées à Amazon Redshift, les appels d’API doivent être signés par l’appelant. Les appels sont signés par un certificat X.509 ou par la clé d'accès AWS secrète du client conformément au processus de signature Signature version 4 (Sigv4). Pour plus d’informations, consultez [Processus de signature Signature Version 4](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) dans le *Références générales AWS*. + Utilisez le AWS CLI ou l'un des AWS SDKs pour envoyer des demandes àAWS. Ces outils signent automatiquement les demandes avec la clé d’accès que vous spécifiez lors de leur configuration. Les détails suivants s’appliquent au chiffrement de données en transit entre les clusters Amazon Redshift et Amazon Redshift Query Editor V2 : + Les données sont transmises entre l’éditeur de requête v2 et les clusters Amazon Redshift sur un canal chiffré TLS. # Contrôles de chiffrement VPC avec Amazon Redshift Amazon Redshift prend en charge les [contrôles de chiffrement VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-encryption-controls.html), une fonctionnalité de sécurité qui vous aide à appliquer le chiffrement en transit pour tout le trafic à l'intérieur et à travers VPCs une région. Ce document explique comment utiliser les contrôles de chiffrement VPC avec les clusters Amazon Redshift et les groupes de travail sans serveur. Les contrôles de chiffrement VPC fournissent un contrôle centralisé pour surveiller et appliquer le chiffrement en transit au sein de votre entreprise. VPCs Lorsqu'il est activé en mode Enforce, il garantit que tout le trafic réseau est crypté soit au niveau de la couche matérielle (avec AWS Nitro System) soit au niveau de la couche application (avec TLS/SSL). Amazon Redshift s'intègre aux contrôles de chiffrement VPC pour vous aider à répondre aux exigences de conformité dans des secteurs tels que la santé (HIPAA), le gouvernement (FedRAMP) et les finances (PCI DSS). ## Comment fonctionnent les contrôles de chiffrement VPC avec Amazon Redshift Les contrôles de chiffrement VPC fonctionnent selon deux modes : + Mode surveillance : fournit une visibilité sur l'état de chiffrement des flux de trafic et aide à identifier les ressources qui autorisent le trafic non chiffré. + Mode d'application : empêche la création ou l'utilisation de ressources qui autorisent le trafic non chiffré au sein du VPC. Tout le trafic doit être chiffré au niveau de la couche matérielle (instances basées sur Nitro) ou de la couche application (TLS/SSL). ## Exigences relatives à l'utilisation des contrôles de chiffrement VPC **Exigences relatives au type d'instance** Amazon Redshift nécessite des instances basées sur Nitro pour prendre en charge les contrôles de chiffrement VPC. Tous les types d'instances Redshift modernes prennent en charge les fonctionnalités de chiffrement nécessaires. **Exigences SSL/TLS** Lorsque les contrôles de chiffrement VPC sont activés en mode d'application, le paramètre require\$1ssl doit être défini sur true et ne peut pas être désactivé. Cela garantit que toutes les connexions client utilisent des connexions TLS cryptées. ## Migration vers les contrôles de chiffrement VPC **Pour les clusters et groupes de travail existants** Vous ne pouvez pas activer les contrôles de chiffrement VPC en mode renforcé sur un VPC qui contient des clusters Redshift ou des groupes de travail sans serveur existants. Consultez les étapes suivantes pour utiliser les contrôles de chiffrement si vous possédez déjà un cluster ou un groupe de travail : 1. Créez un instantané de votre cluster ou espace de noms existant 1. Créez un nouveau VPC avec les contrôles de chiffrement VPC activés en mode d'application 1. Effectuez une restauration depuis le snapshot vers le nouveau VPC à l'aide de l'une des opérations suivantes : + Pour les clusters provisionnés : utilisez l'opération `restore-from-cluster-snapshot` + Pour le mode sans serveur : utilisez l'`restore-from-snapshot`opération sur votre groupe de travail **Lorsque vous créez de nouveaux clusters ou groupes de travail dans un VPC avec les contrôles de chiffrement activés, le paramètre require\$1ssl doit être défini sur true.** Amazon Redshift nécessite des instances basées sur Nitro pour prendre en charge les contrôles de chiffrement VPC. Tous les types d'instances Redshift modernes prennent en charge les fonctionnalités de chiffrement nécessaires. **Exigences SSL/TLS** Lorsque les contrôles de chiffrement VPC sont activés en mode d'application, le paramètre require\$1ssl doit être défini sur true et ne peut pas être désactivé. Cela garantit que toutes les connexions client utilisent des connexions TLS cryptées. ## Considérations et restrictions Lorsque vous utilisez les contrôles de chiffrement VPC dans Amazon Redshift, tenez compte des points suivants : **Restrictions relatives à l'état du VPC** + La création de clusters et de groupes de travail est bloquée lorsque les contrôles de chiffrement VPC sont activés `enforce-in-progress` + Vous devez attendre que le VPC passe en `enforce` mode mode avant de créer de nouvelles ressources **Configuration du protocole SSL** + Paramètre require\$1ssl : doit toujours être destiné aux clusters et aux groupes de travail créés dans `true` le cadre d'une procédure de chiffrement appliquée VPCs + Une fois qu'un cluster ou un groupe de travail est créé dans un VPC à chiffrement renforcé`require_ssl`, il ne peut pas être désactivé pendant toute sa durée de vie **Disponibilité dans les Régions** Cette fonctionnalité n'est pas disponible en mode d'application avec Amazon Redshift Serverless dans les régions suivantes : + Amérique du Sud (São Paulo) + Europe (Zurich) # Gestion des clés Vous pouvez configurer votre environnement pour protéger des données avec des clés. + Amazon Redshift s'intègre automatiquement à AWS Key Management Service (AWS KMS) pour la gestion des clés. AWS KMSutilise le chiffrement des enveloppes. Pour plus d’informations, consultez [Chiffrement d’enveloppe](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping). + Lorsque les clés de chiffrement sont gérées dansAWS KMS, Amazon Redshift utilise une architecture à quatre niveaux basée sur des clés pour le chiffrement. Cette architecture se compose de clés de chiffrement des données AES-256 générées de manière aléatoire, d’une clé de base de données, d’une clé de cluster et d’une clé root. Pour plus d'informations, consultez [Comment Amazon Redshift](https://docs.aws.amazon.com/kms/latest/developerguide/services-redshift.html) l'utilise. AWS KMS + Vous pouvez créer votre propre clé gérée par le client dans AWS KMS. Pour plus d’informations, consultez [Création de clés](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html). + Vous pouvez également importer votre propre matériel clé pour le neufAWS KMS keys. Pour plus d'informations, voir [Importation de matériel clé dans AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/importing-keys.html). + Amazon Redshift prend en charge la gestion des clés de chiffrement dans les modules de sécurité matériels externes ()HSMs. Il peut s’agir d’un module HSM sur site ou d’ AWS CloudHSM. 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. Amazon Redshift prend uniquement en charge la AWS CloudHSM version classique pour la gestion des clés. Pour de plus amples informations, veuillez consulter [Chiffrement à l’aide de modules de sécurité matérielle](working-with-db-encryption.md#working-with-HSM). Pour plus d'informationsAWS CloudHSM, voir [Qu'est-ce que c'est AWS CloudHSM ?](https://docs.aws.amazon.com/cloudhsm/latest/userguide/introduction.html) + Vous pouvez effectuer une rotation des clés de chiffrement pour les clusters chiffrés. Pour plus d’informations, consultez [Rotation des clés de chiffrement](working-with-db-encryption.md#working-with-key-rotation).