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 gérée ou d'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é. Vous pouvez également migrer un cluster non chiffré vers un cluster chiffré en modifiant le cluster.

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 Copie d’instantanés sur une autre région AWS et Configuration d'une copie instantanée entre régions pour un cluster AWS KMS chiffré. 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 plus d’informations, consultez Migration vers un cluster chiffré avec HSM.

Pour modifier le chiffrement de base de données sur un cluster

1. Connectez-vous à la console Amazon Redshift AWS Management Console et ouvrez-la à l'adresse https://console.aws.amazon.com/redshiftv2/.

2. Dans le menu de navigation, choisissez Clusters, puis sélectionnez le cluster pour lequel vous souhaitez modifier les clés de chiffrement.

3. Choisissez Propriétés.

4. Dans Configurations de base de données, choisissez Modifier, puis Modification du chiffrement.

5. Choisissez l'une des options de chiffrement et Enregistrez les modifications.

Pour modifier le chiffrement du cluster à l'aide de l'interface de ligne de commande

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 <value> --encrypted --kms-key-id <value>

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 <value> --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.

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).

2. 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;

3. 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.

4. 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');

5. 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.

6. Configurez les processus de déchargement et chargement des données.

   Vous pouvez faire appel à l'utilitaire de déchargement/copie Amazon Redshift pour vous aider à effectuer la migration des données entre les deux 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.

7. 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.

8. 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 AdminViewsles 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.

2. 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.

3. (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 dans le Guide du développeur de bases de données Amazon Redshift.

4. À 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.

5. Exécutez à nouveau les requêtes de validation et vérifiez que leurs résultats correspondent à ceux du cluster source.

6. 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,

7. 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.

8. Fermez le cluster source non chiffré.