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, vous pouvez activer le chiffrement des bases de données pour vos clusters afin de protéger les données au repos. Lorsque vous activez le chiffrement pour un cluster, les blocs de données et les métadonnées système sont chiffrés pour le cluster et ses instantanés.
Vous pouvez activer le chiffrement lorsque vous lancez votre cluster, ou 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é gérée par le client ou une clé AWS 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 le chiffrement soit un paramètre facultatif dans Amazon Redshift, nous vous recommandons de l'activer pour les clusters qui contiennent 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 de sécurité des données du secteur des cartes de paiement (PCIDSS), la loi Sarbanes-Oxley ()SOX, la loi Health Insurance Portability and Accountability (HIPAA) et d'autres réglementations similaires fournissent des directives pour le traitement de types spécifiques de données.
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ériel (HSM) pour gérer les clés de chiffrement de haut niveau 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 à un. HSM Lorsque vous utilisez unHSM, vous devez utiliser des certificats client et serveur pour configurer une connexion sécurisé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.
-
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 appliquer à nouveau toutes les nouvelles mises à jour (mises à jour/suppressions/insertions) 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 NOne sont pas conservées. Pour plus d'informations, consultez CREATETABLEou CREATEMATERIALIZEDVIEW.
Rubriques
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, classées par ordre hiérarchique, sont la clé racine, une clé de chiffrement de cluster (CEK), une clé de chiffrement de base de données (DEK) et des clés de chiffrement de données.
Lorsque vous lancez votre cluster, Amazon Redshift renvoie une liste de ceux AWS KMS keys que votre AWS compte a créés ou dans lesquels vous êtes autorisé à utiliser. AWS KMS Vous sélectionnez une KMS clé à utiliser comme clé racine dans la hiérarchie de chiffrement.
Par défaut, Amazon Redshift sélectionne votre clé par défaut en tant que clé racine. Votre clé par défaut est une clé AWS gérée créée pour que votre AWS compte puisse l'utiliser dans Amazon Redshift. AWS KMS crée cette clé la première fois que vous lancez un cluster chiffré dans une AWS région et que vous choisissez la clé par défaut.
Si vous ne souhaitez pas utiliser la clé par défaut, vous devez disposer (ou créer) une KMS clé 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 de KMS clés, consultez la section Création de clés dans le guide du AWS Key Management Service développeur.
Si vous souhaitez utiliser une AWS KMS clé d'un autre AWS compte, vous devez être autorisé à utiliser la clé et spécifier son nom de ressource Amazon (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 CEK dans Amazon Redshift. AWS KMS exporte le chiffrement CEK vers Amazon Redshift, où il est stocké en interne sur disque dans un réseau distinct du cluster, avec l'attribution de la KMS clé et le contexte de chiffrement pour le. CEK Seul le code chiffré CEK est exporté vers Amazon Redshift ; la KMS clé y est conservée. AWS KMS Amazon Redshift transmet également les données chiffrées CEK via un canal sécurisé au cluster et les charge en mémoire. Ensuite, Amazon Redshift appelle AWS KMS pour les déchiffrer CEK et charge le fichier déchiffré en mémoire. CEK 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 de manière aléatoire une clé à utiliser comme clé DEK et la charge en mémoire dans le cluster. Le déchiffré CEK est utilisé pour chiffrer leDEK, qui est ensuite transmis via un canal sécurisé depuis le cluster pour être stocké en interne par Amazon Redshift sur disque dans un réseau distinct du cluster. Comme leCEK, les versions chiffrées et déchiffrées du DEK sont chargées en mémoire dans le cluster. La version déchiffrée du DEK est ensuite utilisée pour chiffrer les clés de chiffrement individuelles qui sont générées de manière 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 DEK et, les recharge en mémoire, puis AWS KMS appelle à nouveau pour les déchiffrer avec CEK KMS la clé afin qu'elles puissent être chargées en mémoire. Le déchiffré CEK est ensuite utilisé pour le déchiffrer à DEK nouveau, puis le déchiffré DEK est chargé en mémoire et utilisé pour chiffrer et déchiffrer les clés des blocs de données selon les 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 AWS KMS des instantanés chiffrés vers une autre région AWS
AWS KMS les clés sont spécifiques à une AWS région. Si vous activez la copie des instantanés Amazon Redshift vers une autre AWS région et que le cluster source et ses instantanés sont chiffrés à l'aide d'une clé racine provenant de AWS KMS, vous devez configurer une autorisation pour qu'Amazon Redshift utilise une clé racine dans la région de destination. AWS Cette subvention permet à Amazon Redshift de chiffrer les instantanés dans la région de destination. AWS Pour de plus amples informations sur la copie d'instantanés entre régions, veuillez consulter Copier un instantané vers un autre AWS Région.
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.
-
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 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.
-
-
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 d'Amazon API 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 d'une copie instantanée entre régions pour un AWS KMS—cluster 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é générée aléatoirement qu'Amazon Redshift gère en interne. RSA 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 RSA clé 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ériel (HSM) pour la gestion des clés avec Amazon Redshift.
Important
HSMle chiffrement n'est pas pris en charge pour DC2 les types de RA3 nœuds et.
HSMssont 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 l'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 Cloud HSM Classic
Lorsque vous configurez votre cluster pour utiliser unHSM, Amazon Redshift envoie une demande au HSM pour générer et stocker une clé à utiliser en tant que. CEK Cependant, contrairement à cela AWS KMS, HSM il ne les exporte pas CEK vers Amazon Redshift. Au lieu de cela, Amazon Redshift génère aléatoirement le DEK dans le cluster et le transmet au pour qu'il soit chiffré par leHSM. CEK Les HSM données chiffrées sont renvoyées DEK à Amazon Redshift, où elles sont ensuite chiffrées à l'aide d'une clé racine interne générée de manière aléatoire et stockées en interne sur disque dans un réseau distinct de celui du cluster. Amazon Redshift charge également la version déchiffrée de la clé DEK en mémoire dans le cluster afin de DEK pouvoir l'utiliser 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 contenu stocké en interne et chiffré deux fois à l'aide de la clé racine interne pour rétablir DEK l'état crypté du cluster stocké en interne. DEK CEK Le CEK code -encrypted DEK est ensuite transmis au HSM pour être déchiffré et renvoyé à Amazon Redshift, où il peut être à nouveau chargé en mémoire pour être utilisé avec les clés de bloc de données individuelles.
Configuration d'une connexion sécurisée entre Amazon Redshift et un HSM
Lorsque vous choisissez d'utiliser un HSM pour la gestion de votre clé de cluster, vous devez configurer un lien réseau fiable entre Amazon Redshift et votre. HSM Cela nécessite une configuration de certificats de client et de serveur. La connexion sécurisée est utilisée pour transmettre les clés de chiffrement entre Amazon Redshift HSM et Amazon Redshift lors des 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 client public dans votre partitionHSM, puis vous l'attribuez à la HSM partition applicable.
Vous fournissez à Amazon Redshift l'adresse HSM IP, le nom de la HSM partition, le mot de passe de la HSM partition et un certificat de HSM serveur public, 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 Si ce n'est pas le cas, le cluster passe à HSM l'état INCOMPATIBLE _ 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 autre HSM partition, Amazon Redshift vérifie qu'il peut se connecter à la nouvelle partition, mais il ne vérifie pas l'existence d'une clé de chiffrement valide. 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
Après la configuration initiale, si Amazon Redshift ne parvient pas à se connecter à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 lancez le processus de rotation des clés, Amazon Redshift effectue une rotation CEK pour le cluster spécifié et pour tous les instantanés automatisés ou manuels du cluster. Amazon Redshift effectue également une rotation DEK pour le cluster spécifié, mais ne peut pas effectuer de rotation DEK pour les instantanés lorsqu'ils sont stockés en interne dans Amazon Simple Storage Service (Amazon S3) et chiffrés à l'aide de l'existant. DEK
Pendant que la rotation est en cours, le cluster est mis dans un KEYS état ROTATING _ jusqu'à ce qu'il soit terminé, moment auquel le cluster revient à l'AVAILABLEétat. 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 touches, consultezRotation des clés de chiffrement.
