Amazon Redshift non supporterà più la creazione di nuovi Python UDFs a partire dalla Patch 198. Python esistente UDFs continuerà a funzionare fino al 30 giugno 2026. Per ulteriori informazioni, consulta il [post del blog](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/).
Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Crittografia dei dati a riposo
La crittografia lato server esegue la crittografia dei dati a riposo, vale a dire che Amazon Redshift consente di crittografare i dati durante la scrittura nei data center e ne esegue la decrittografia quando avviene l'accesso. Se la richiesta è autenticata e sono disponibili le autorizzazioni per l'accesso, non c'è differenza nelle modalità di accesso ai dati, crittografati o meno.
Amazon Redshift protegge i dati a riposo mediante la crittografia. In alternativa, è possibile proteggere tutti i dati archiviati sui dischi all'interno di un cluster e tutti i backup in Amazon S3 con Advanced Encryption Standard AES-256.
[Per gestire le chiavi utilizzate per crittografare e decrittografare le risorse Amazon Redshift, usi (). AWS Key Management ServiceAWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/) AWS KMScombina hardware e software sicuri e ad alta disponibilità per fornire un sistema di gestione delle chiavi scalabile per il cloud. UtilizzandoAWS KMS, è possibile creare chiavi di crittografia e definire le politiche che controllano il modo in cui tali chiavi possono essere utilizzate. AWS KMSsupportaAWS CloudTrail, in modo da poter controllare l'utilizzo delle chiavi per verificare che vengano utilizzate in modo appropriato. Puoi utilizzare AWS KMS le tue chiavi in combinazione con Amazon Redshift e i servizi supportatiAWS. Per un elenco dei servizi che supportanoAWS KMS, consulta [How AWS Services Use AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/services.html) nella *AWS Key Management ServiceDeveloper Guide*.
Se scegli di gestire la password di amministratore del cluster fornito o dello spazio dei nomi serverless utilizzando, Amazon Gestione dei segreti AWS Redshift accetta anche una chiave AWS KMS aggiuntiva da utilizzare per crittografare le tue credenziali. Gestione dei segreti AWS Questa chiave aggiuntiva può essere una chiave generata automaticamente da o una chiave personalizzata fornita da Gestione dei segreti AWS te.
Amazon Redshift query editor v2 memorizza in modo sicuro le informazioni inserite nell'editor di query come segue:
+ ARN (Amazon Resource Name) della chiave KMS usato per crittografare i dati query editor v2.
+ Informazioni sulla connessione al database.
+ Nomi e contenuti di file e cartelle.
Amazon Redshift query editor v2 crittografa le informazioni utilizzando la crittografia a livello di blocco con la chiave KMS o la chiave KMS dell'account di servizio. La crittografia dei dati Amazon Redshift è controllata dalle proprietà del cluster Amazon Redshift.
**Topics**
+ [Crittografia dei database di Amazon Redshift](working-with-db-encryption.md)
# Crittografia dei database di Amazon Redshift
In Amazon Redshift, il database è crittografato per impostazione predefinita per proteggere i dati a riposo. La crittografia del database si applica al cluster e anche ai relativi snapshot.
È possibile modificare un cluster non crittografato per utilizzare la crittografia AWS Key Management Service (AWS KMS). A tale scopo, è possibile utilizzare una chiave di AWS proprietà o una chiave gestita dal cliente. Quando modifichi il cluster per abilitare la AWS KMS crittografia, Amazon Redshift migra automaticamente i dati in un nuovo cluster crittografato. Anche le snapshot create dal cluster crittografato sono crittografate. Puoi anche eseguire la migrazione di un cluster crittografato in un cluster non crittografato modificando il cluster e l'opzione **Encrypt database (Crittografa database)**. Per ulteriori informazioni, consulta [Modifica della crittografia del cluster](changing-cluster-encryption.md).
Sebbene possa continuare a trasformare il cluster crittografato predefinito in un cluster non crittografato dopo la creazione, consigliamo di mantenere crittografato il cluster che contiene dati sensibili. Inoltre, potresti dover usare la crittografia in base a linee guida o normative che regolano i tuoi dati. Ad esempio, il Payment Card Industry Data Security Standard (PCI DSS), il Sarbanes-Oxley Act (SOX), l'Health Insurance Portability and Accountability Act (HIPAA) e altre normative simili forniscono linee guida per la gestione di tipi specifici di dati.
Amazon Redshift usa una gerarchia di chiavi di crittografia per crittografare il database. Puoi utilizzare AWS Key Management Service (AWS KMS) o un modulo di sicurezza hardware (HSM) per gestire le chiavi di crittografia di primo livello in questa gerarchia. Il processo utilizzato da Amazon Redshift per la crittografia è diverso a seconda del modo in cui vengono gestite le chiavi. Amazon Redshift si integra automaticamente con un HSM AWS KMS , ma non con. Quando si utilizza un modulo di sicurezza hardware (HSM), è necessario usare certificati client e server per configurare una connessione attendibile tra Amazon Redshift e il modulo di sicurezza hardware (HSM).
**Importante**
Amazon Redshift può perdere l’accesso alla chiave KMS per un cluster con provisioning o un namespace serverless quando disabiliti la chiave KMS gestita dal cliente. In questi casi Amazon Redshift prende un backup del data warehouse Amazon Redshift e ne attiva lo stato `inaccessible-kms-key` per 14 giorni. Se ripristini la chiave KMS entro tale periodo, Amazon Redshift ripristina l’accesso e il warehouse funziona normalmente. Se il periodo di 14 giorni termina senza che la chiave KMS venga ripristinata, Amazon Redshift elimina il data warehouse. Mentre un warehouse è nello stato `inaccessible-kms-key`, ha le seguenti caratteristiche:
Non puoi eseguire alcuna query sul data warehouse.
Se il data warehouse è il warehouse producer di un’unità di condivisione dati, non puoi eseguire query di condivisione dei dati su di esso dai data warehouse consumer.
Non puoi creare copie di snapshot tra più Regioni.
Per informazioni sul ripristino di una chiave KMS disabilitata, consulta [Abilitare e disabilitare le chiavi](https://docs.aws.amazon.com/kms/latest/developerguide/enabling-keys.html) nella *Guida per gli sviluppatori di AWS Key Management Service *. Se la chiave KMS del warehouse è stata eliminata, puoi utilizzare il backup per creare un nuovo data warehouse prima che venga eliminato il warehouse con lo stato `inaccessible-kms-key`.
## Miglioramenti del processo di crittografia per migliori prestazioni e disponibilità
### Crittografia con nodi RA3
Gli aggiornamenti al processo di crittografia per RA3 i nodi hanno migliorato notevolmente l'esperienza. Durante il processo possono essere eseguite sia le query di lettura che quelle di scrittura con un minore impatto sulle prestazioni dovuto alla crittografia. Inoltre, la crittografia termina molto più rapidamente. Le fasi del processo aggiornate includono un'operazione di ripristino e la migrazione dei metadati del cluster su un cluster di destinazione. L'esperienza migliorata si applica ai tipi di crittografia come AWS KMS, ad esempio. Quando si dispone di volumi di dati nell'ordine di petabyte, l'operazione è stata ridotta da settimane a giorni.
Prima di crittografare il cluster, se prevedi di continuare a eseguire i carichi di lavoro del database, puoi migliorare le prestazioni e accelerare il processo aggiungendo nodi con ridimensionamento elastico. Non puoi usare il ridimensionamento elastico quando la crittografia è in corso, quindi effettua questa operazione prima della crittografia. Tieni presente che l'aggiunta di nodi comporta in genere un costo più elevato.
### Crittografia con altri tipi di nodo
Quando si crittografa un cluster con DC2 nodi, non è possibile eseguire query di scrittura, come con RA3 i nodi. Puoi eseguire solo query di lettura.
### Note di utilizzo per la crittografia con nodi RA3
I seguenti approfondimenti e risorse aiutano a prepararsi alla crittografia e a monitorare il processo.
+ **Esecuzione delle query dopo l'avvio della crittografia**: dopo l'avvio della crittografia, le operazioni di lettura e scrittura sono disponibili entro circa quindici minuti. Il tempo necessario per completare l'intero processo di crittografia dipende dalla quantità di dati nel cluster e dai livelli del carico di lavoro.
+ **Quanto tempo richiede la crittografia?** - Il tempo necessario per crittografare i dati dipende da diversi fattori: tra cui il numero di carichi di lavoro in esecuzione, le risorse di calcolo utilizzate, il numero e il tipo di nodi. Consigliamo di eseguire inizialmente la crittografia in un ambiente di test. Come regola generale, se lavori con volumi di dati in petabyte, possono essere necessari 1-3 giorni per il completamento della crittografia.
+ **Come faccio a sapere se la crittografia è terminata?** Dopo avere abilitato la crittografia, il completamento del primo snapshot conferma che la crittografia è terminata.
+ **Rollback della crittografia**: se devi eseguire il rollback dell'operazione di crittografia, il modo migliore per farlo è ripristinare il backup più recente eseguito prima dell'avvio della crittografia. Dovrai riapplicare tutti i nuovi aggiornamenti (updates/deletes/inserts) dopo l'ultimo backup.
+ **Esecuzione del ripristino di una tabella**: tieni presente che non puoi ripristinare una tabella da un cluster non crittografato a un cluster crittografato.
+ **Crittografia di un cluster a nodo singolo**: la crittografia di un cluster a nodo singolo presenta limiti di prestazioni. Richiede più tempo della crittografia per un cluster multinodo.
+ **Creazione di un backup dopo la crittografia**: quando si crittografano i dati nel cluster, non viene creato un backup finché il cluster non è completamente crittografato. Il tempo necessario per questa operazione è variabile. Il tempo necessario per il backup può variare da ore a giorni, a seconda delle dimensioni del cluster. Una volta completata la crittografia, può verificarsi un ritardo prima di poter creare un backup.
Tieni presente che, poiché un' backup-and-restoreoperazione viene eseguita durante il processo di crittografia, le tabelle o le viste materializzate create con `BACKUP NO` non vengono conservate. Per ulteriori informazioni, consulta [CREATE TABLE](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_TABLE_NEW.html) o [CREATE MATERIALIZED VIEW](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-create-sql-command.html).
**Topics**
+ [Miglioramenti del processo di crittografia per migliori prestazioni e disponibilità](#resize-classic-encryption)
+ [Utilizzo della crittografia AWS KMS](#working-with-aws-kms)
+ [Crittografia tramite moduli di sicurezza hardware](#working-with-HSM)
+ [Rotazione delle chiavi di crittografia](#working-with-key-rotation)
+ [Modifica della crittografia del cluster](changing-cluster-encryption.md)
+ [Migrazione a un cluster crittografato con HSM](migrating-to-an-encrypted-cluster.md)
+ [Rotazione delle chiavi di crittografia](manage-key-rotation-console.md)
## Utilizzo della crittografia AWS KMS
Quando scegli AWS KMS la gestione delle chiavi con Amazon Redshift, esiste una gerarchia di chiavi di crittografia a quattro livelli. Queste chiavi, in ordine gerarchico, sono la chiave root, una chiave di crittografia del cluster, una chiave di crittografia del database e le chiavi di crittografia dei dati.
Quando avvii il cluster, Amazon Redshift restituisce un elenco dei file AWS KMS keys che Amazon Redshift o il AWS tuo account hanno creato o in cui sono autorizzati a utilizzare. AWS KMS Devi selezionare una chiave KMS del cliente da usare come chiave root nella gerarchia di crittografia.
Per impostazione predefinita, Amazon Redshift seleziona una chiave di AWS proprietà generata automaticamente come chiave principale per l' AWS account da utilizzare in Amazon Redshift.
Se non desideri utilizzare la chiave predefinita, devi disporre (o creare) separatamente una chiave KMS gestita dal cliente AWS KMS prima di avviare il cluster in Amazon Redshift. Le chiavi gestite dal cliente ti offrono maggiore flessibilità, inclusa la possibilità di creare, ruotare, disabilitare, definire il controllo degli accessi per e controllare le chiavi di crittografia per proteggere i dati. Per ulteriori informazioni sulla creazione di chiavi KMS, consultare [Creazione di chiavi](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) nella *Guida per gli sviluppatori di AWS Key Management Service *.
Se desideri utilizzare una AWS KMS chiave di un altro AWS account, devi disporre dell'autorizzazione a utilizzare la chiave e specificarne il nome Amazon Resource Name (ARN) in Amazon Redshift. Per ulteriori informazioni sull'accesso alle chiavi in AWS KMS, consulta [Controlling Access to Your Keys](https://docs.aws.amazon.com/kms/latest/developerguide/control-access.html) nella *AWS Key Management Service Developer* Guide.
Dopo aver scelto una chiave radice, Amazon Redshift richiede di AWS KMS generare una chiave dati e di crittografarla utilizzando la chiave radice selezionata. Questa chiave di dati viene utilizzata come chiave CEK in Amazon Redshift. AWS KMS esporta la chiave CEK crittografata in Amazon Redshift, in cui viene archiviata internamente su disco in una rete separata dal cluster insieme all'autorizzazione per la chiave KMS e il contesto di crittografia per la chiave CEK. Solo la chiave CEK crittografata viene esportata in Amazon Redshift; la KMS rimane in AWS KMS. Amazon Redshift passa la chiave CEK crittografata anche al cluster attraverso un canale sicuro e la carica in memoria. Quindi, Amazon Redshift chiama AWS KMS per decrittografare il CEK e carica il CEK decrittografato in memoria. [https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html)
Amazon Redshift genera quindi casualmente una chiave da usare come chiave di crittografia del database e la carica in memoria nel cluster. La chiave CEK decrittata viene usata per crittografare la chiave DEK, che viene quindi passata attraverso un canale sicuro dal cluster per essere archiviata internamente da Amazon Redshift su disco in una rete separata dal cluster. Come per la chiave di crittografia del cluster, la versione crittografata e quella decrittografata della chiave di crittografia del database vengono caricate in memoria nel cluster. La versione decrittografata della chiave di crittografia del database viene quindi usata per crittografare le singole chiavi di crittografia generate casualmente per ogni blocco di dati nel database.
Al riavvio del cluster, Amazon Redshift inizia con le versioni crittografate e archiviate internamente di CEK e DEK, le ricarica in memoria e quindi AWS KMS chiama nuovamente per decrittografare il CEK con la chiave KMS in modo che possa essere caricato in memoria. La chiave di crittografia del cluster decrittografata viene quindi usata per decrittografare di nuovo la chiave di crittografia del database e questa chiave decrittografata viene caricata in memoria e quindi usata per crittografare e decrittografare le chiavi dei blocchi di dati in base alle esigenze.
Per ulteriori informazioni sulla creazione di cluster Amazon Redshift crittografati con chiavi AWS KMS , consulta [Creazione di un cluster](create-cluster.md).
### Copiare istantanee crittografate su un'altra AWS KMS Regione AWS
AWS KMS le chiavi sono specifiche di un. Regione AWS Se desideri abilitare la copia degli snapshot di Amazon Redshift da un cluster di origine crittografato a un Regione AWS altro, ma desideri utilizzare la AWS KMS tua chiave per gli snapshot nella destinazione, devi configurare una concessione per Amazon Redshift per utilizzare una chiave radice nel tuo account nella destinazione. Regione AWS Questa autorizzazione permette ad Amazon Redshift di crittografare gli snapshot nella Regione AWS di destinazione. Se desideri che le istantanee nella destinazione siano crittografate con una chiave Regione AWS di proprietà, non è necessario configurare alcuna concessione nella destinazione. Regione AWS Per ulteriori informazioni sulla copia di snapshot tra regioni, consultare [Copiare un'istantanea in un'altra regione AWS](cross-region-snapshot-copy.md).
**Nota**
Se abiliti la copia di istantanee da un cluster crittografato e la utilizzi AWS KMS come chiave principale, non puoi rinominare il cluster perché il nome del cluster fa parte del contesto di crittografia. Se è necessario rinominare il cluster, è possibile disabilitare la copia delle istantanee nella AWS regione di origine, rinominare il cluster e quindi configurare e abilitare nuovamente la copia delle istantanee.
Il processo di configurazione dell'autorizzazione per la copia degli snapshot viene descritto di seguito.
1. Nella AWS regione di destinazione, crea una concessione per la copia delle istantanee effettuando le seguenti operazioni:
+ Se non hai già una AWS KMS chiave da usare, creane una. Per ulteriori informazioni sulla creazione di AWS KMS chiavi, consulta [Creating Keys](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) nella *AWS Key Management Service Developer Guide*.
+ Specificare un nome per l'autorizzazione di copia degli snapshot. Questo nome deve essere univoco in quella AWS regione per il tuo AWS account.
+ Specificate l'ID della AWS KMS chiave per cui state creando la sovvenzione. Se non si specifica un ID chiave, l'autorizzazione viene applicata alla chiave predefinita.
1. Nella AWS regione di origine, abilitate la copia delle istantanee e specificate il nome della concessione per la copia delle istantanee che avete creato nella regione di destinazione. AWS
Questo processo precedente è necessario solo se abiliti la copia di istantanee utilizzando l'API AWS CLI Amazon Redshift o. SDKs Se si utilizza la console, Amazon Redshift fornisce il flusso di lavoro appropriato per configurare l'autorizzazione quando si abilita la copia di snapshot tra regioni. Per ulteriori informazioni sulla configurazione della copia di snapshot tra regioni per cluster crittografati con AWS KMS utilizzando la console, consultare [Configurazione di una copia delle istantanee tra regioni per un cluster crittografato AWS KMS](xregioncopy-kms-encrypted-snapshot.md).
Prima che lo snapshot venga copiato AWS nella regione di destinazione, Amazon Redshift decripta lo snapshot utilizzando la chiave radice nella regione di AWS origine e lo cripta nuovamente temporaneamente utilizzando una chiave RSA generata casualmente che Amazon Redshift gestisce internamente. Amazon Redshift copia quindi lo snapshot su un canale sicuro AWS nella regione di destinazione, decripta lo snapshot utilizzando la chiave RSA gestita internamente e quindi cripta nuovamente lo snapshot utilizzando la chiave radice nella regione di destinazione. AWS
## Crittografia tramite moduli di sicurezza hardware
Se non lo utilizzi AWS KMS per la gestione delle chiavi, puoi utilizzare un modulo di sicurezza hardware (HSM) per la gestione delle chiavi con Amazon Redshift.
**Importante**
La crittografia HSM non è supportata per DC2 nessun tipo di nodo. RA3
HSMs sono dispositivi che forniscono il controllo diretto della generazione e della gestione delle chiavi. Forniscono una sicurezza maggiore separando la gestione delle chiavi dai livelli applicazione e database. Amazon Redshift supporta AWS CloudHSM Classic per la gestione delle chiavi. Il processo di crittografia è diverso quando utilizzi HSM per gestire le chiavi di crittografia anziché. AWS KMS
**Importante**
Amazon Redshift supporta solo AWS CloudHSM la versione Classic. Non supportiamo il servizio più recente. AWS CloudHSM
AWS CloudHSM Classic è chiuso ai nuovi clienti. Per ulteriori informazioni, consulta la pagina dei prezzi di [CloudHSM](https://aws.amazon.com/cloudhsm/pricing-classic/) Classic. AWS CloudHSM La versione classica non è disponibile in tutte le AWS regioni. Per ulteriori informazioni sulle AWS regioni disponibili, consulta la [tabella delle AWS regioni](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/).
Quando si configura il cluster per l'uso di un modulo di sicurezza hardware (HSM), Amazon Redshift invia una richiesta al modulo di sicurezza hardware per generare e archiviare una chiave da usare come chiave di crittografia del cluster. Tuttavia AWS KMS, a differenza di HSM, non esporta il CEK in Amazon Redshift. Amazon Redshift genera invece casualmente la chiave DEK nel cluster e la passa al modulo di sicurezza hardware (HSM) perché venga crittografata dalla chiave di crittografia del cluster. Il modulo di sicurezza hardware (HSM) restituisce la chiave DEK crittografata ad Amazon Redshift, in cui viene ulteriormente crittografata con una chiave root interna generata casualmente e archiviata internamente su disco in una rete separata dal cluster. Amazon Redshift inoltre carica la versione decrittata della chiave DEK nella memoria nel cluster in modo che la chiave possa essere utilizzata per crittografare e decrittare le singole chiavi per i blocchi di dati.
Se il cluster viene riavviato, Amazon Redshift decritta la chiave DEK doppiamente crittografata e archiviata internamente usando la chiave root interna per riportare la chiave DEK archiviata internamente allo stato di crittografia tramite la chiave CEK. La chiave DEK crittografata con la chiave CEK viene passata al modulo di sicurezza hardware (HSM) perché venga decrittata e quindi passata di nuovo ad Amazon Redshift, in cui può essere caricata di nuovo in memoria per l'uso con le singole chiavi dei blocchi di dati.
### Configurazione di una connessione attendibile tra Amazon Redshift e un modulo di sicurezza hardware (HSM)
Se si decide di usare un modulo di sicurezza hardware (HSM) per la gestione della chiave del cluster, è necessario configurare un collegamento di rete attendibile tra Amazon Redshift e il modulo di sicurezza hardware. A questo scopo, devi configurare certificati client e server. La connessione attendibile viene usata per passare le chiavi di crittografia tra il modulo di sicurezza hardware e Amazon Redshift durante le operazioni di crittografia e decrittografia.
Amazon Redshift crea un certificato client pubblico da una coppia di chiavi privata e pubblica generata casualmente. Queste chiavi vengono crittografate e archiviate internamente. Devi scaricare e registrare il certificato client pubblico nel modulo di sicurezza hardware e quindi assegnarlo alla partizione del modulo di sicurezza hardware appropriata.
Fornire ad Amazon Redshift l'indirizzo IP dell'HSM, il nome e la password della partizione HSM e un certificato server HSM pubblico, che viene crittografato con una chiave root interna. Amazon Redshift completa il processo di configurazione e verifica se riesce a connettersi a HSM. In caso contrario, il cluster passa allo stato INCOMPATIBLE\$1HSM (HSM\$1INCOMPATIBILE) e non viene creato. In questo caso, devi eliminare il cluster incompleto e riprovare.
**Importante**
Quando si modifica il cluster per l'uso di una partizione del modulo di sicurezza hardware diversa, Amazon Redshift verifica di riuscire a connettersi alla nuova partizione, ma non verifica la presenza di una chiave di crittografia valida. Prima di usare la nuova partizione, devi replicarvi le chiavi. Se il cluster viene riavviato e Amazon Redshift non riesce a trovare una chiave valida, il riavvio non riesce. Per ulteriori informazioni, consulta [Replicating](https://docs.aws.amazon.com/cloudhsm/latest/userguide/cli-clone-hapg.html) Keys Across. HSMs
Se dopo la configurazione iniziale Amazon Redshift non riesce a connettersi al modulo di sicurezza hardware (HSM), viene registrato un evento. Per ulteriori informazioni su questi eventi, consultare [Notifiche di eventi di Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-event-notifications.html).
## Rotazione delle chiavi di crittografia
In Amazon Redshift è possibile eseguire la rotazione delle chiavi di crittografia per i cluster crittografati. All'inizio del processo di rotazione delle chiavi, Amazon Redshift esegue la rotazione della chiave CEK per il cluster specificato e per qualsiasi snapshot automatico o manuale del cluster. Amazon Redshift esegue la rotazione anche della chiave DEK per il cluster specificato, ma non può ruotare la chiave DEK per gli snapshot mentre questi sono archiviati internamente in Amazon Simple Storage Service (Amazon S3) e crittografati con la chiave DEK esistente.
Durante la rotazione, il cluster passa allo stato ROTATING\$1KEYS fino al completamento, quindi torna allo stato AVAILABLE. Amazon Redshift gestisce la decrittografia e la nuova crittografia durante il processo di rotazione delle chiavi.
**Nota**
Non puoi eseguire la rotazione delle chiavi per snapshot senza un cluster di origine. Prima di eliminare un cluster, valuta se gli snapshot associati usano la rotazione delle chiavi.
Poiché il cluster è momentaneamente non disponibile durante il processo di rotazione delle chiavi, devi ruotare le chiavi solo in base alla frequenza determinata dalle esigenze relative ai dati o quando sospetti che le chiavi siano state compromesse. Come best practice, devi esaminare il tipo di dati archiviati e determinare la frequenza della rotazione delle chiavi che crittografano i dati. La frequenza per la rotazione delle chiavi varia a seconda delle policy aziendali in materia di sicurezza dei dati e di qualsiasi standard del settore relativo ai dati sensibili e alla conformità alle normative. Assicurati che il tuo piano garantisca un giusto equilibrio tra esigenze di sicurezza e considerazioni sulla disponibilità per il cluster.
Per ulteriori informazioni sulla rotazione delle chiavi, consulta [Rotazione delle chiavi di crittografia](manage-key-rotation-console.md).
# Modifica della crittografia del cluster
È possibile modificare un cluster non crittografato per utilizzare la crittografia AWS Key Management Service (AWS KMS) utilizzando una chiave di AWS proprietà o una chiave gestita dal cliente. Quando si modifica il cluster per abilitare la crittografia AWS KMS , Amazon Redshift migra automaticamente i dati a un nuovo cluster crittografato. È inoltre possibile migrare un cluster crittografato in un cluster non crittografato modificando il cluster con AWS CLI, ma non con. Console di gestione AWS
Durante l'operazione di migrazione, il cluster rimane disponibile in sola lettura e lo stato visualizzato sarà **resizing (ridimensionamento)**.
Se il cluster è configurato per abilitare la copia di istantanee tra AWS regioni, è necessario disabilitarlo prima di modificare la crittografia. Per ulteriori informazioni, consultare [Copiare un'istantanea in un'altra regione AWS](cross-region-snapshot-copy.md) e [Configurazione di una copia delle istantanee tra regioni per un cluster crittografato AWS KMS](xregioncopy-kms-encrypted-snapshot.md). Non puoi abilitare la crittografia con il modulo di sicurezza hardware (HSM) modificando il cluster. Devi invece creare un nuovo cluster crittografato con HSM ed eseguire la migrazione dei dati al nuovo cluster. Per ulteriori informazioni, consulta [Migrazione a un cluster crittografato con HSM](migrating-to-an-encrypted-cluster.md).
------
#### [ Amazon Redshift console ]
1. Accedi a Console di gestione AWS e apri la console Amazon Redshift all'indirizzo. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)
1. Dal menu di navigazione, scegliere **Clusters** (Cluster), quindi scegliere il cluster di cui si desidera modificare la crittografia.
1. Scegli **Properties (Proprietà)**.
1. Nella sezione **Configurazioni di database**, scegliere **Modifica**, quindi **Modifica crittografia**.
1. Scegliere una delle opzioni di crittografia e selezionare **Salva modifiche**.
------
#### [ AWS CLI ]
Per modificare il cluster non crittografato da utilizzare AWS KMS, `modify-cluster` esegui il comando CLI e `–-encrypted` specifica, come illustrato di seguito. Per impostazione predefinita viene utilizzata la chiave KMS predefinita. Per specificare una chiave gestita dal cliente, includi l'opzione `--kms-key-id`.
```
aws redshift modify-cluster --cluster-identifier --encrypted --kms-key-id
```
Per rimuovere la crittografia dal cluster, esegui questo comando della CLI.
```
aws redshift modify-cluster --cluster-identifier --no-encrypted
```
------
# Migrazione a un cluster crittografato con HSM
Per eseguire la migrazione di un cluster non crittografato a un cluster crittografato con un modulo di sicurezza hardware (HSM), crea un nuovo cluster crittografato e sposta i dati nel nuovo cluster. Non puoi eseguire la migrazione a un cluster crittografato con HSM modificando il cluster.
Per eseguire la migrazione da un cluster non crittografato a un cluster crittografato con HSM, devi prima scaricare i dati dal cluster di origine esistente. Ricarica quindi i dati in un nuovo cluster di destinazione con l'impostazione di crittografia scelta. Per ulteriori informazioni sull'avvio di un cluster crittografato, consultare [Crittografia dei database di Amazon Redshift](working-with-db-encryption.md).
Durante il processo di migrazione, il cluster di origine è disponibile per query di sola lettura fino all'ultima fase. L'ultima fase consiste nel rinominare i cluster di destinazione e di origine, scambiando gli endpoint in modo che il traffico venga instradato al nuovo cluster di destinazione. Il cluster di destinazione non è disponibile fino al riavvio successivo alla ridenominazione. Durante il trasferimento dei dati, sospendi qualsiasi caricamento dei dati e altre operazioni di scrittura nel cluster di origine.
**Preparativi per la migrazione**
1. Identificare tutti i sistemi dipendenti che interagiscono con Amazon Redshift, ad esempio gli strumenti di business intelligence (BI) e i sistemi di estrazione, trasformazione e caricamento (ETL).
1. Identificare le query di convalida per testare la migrazione.
Ad esempio, è possibile usare la query seguente per trovare il numero di tabelle definite dall'utente.
```
select count(*)
from pg_table_def
where schemaname != 'pg_catalog';
```
La query seguente restituisce un elenco di tutte le tabelle definite dall'utente e il numero di righe in ogni tabella.
```
select "table", tbl_rows
from svv_table_info;
```
1. Scegliere un buon momento per la migrazione. Per trovare un momento in cui l'utilizzo del cluster è minimo, monitorare i parametri del cluster, come utilizzo della CPU e numero di connessioni al database. Per ulteriori informazioni, consultare [Visualizzazione di dati di prestazioni dei cluster](performance-metrics-perf.md).
1. Rimuovere le tabelle inutilizzate.
Per creare un elenco di tabelle che indichi anche il numero di volte in cui sono state eseguite query su ogni tabella, eseguire la query seguente.
```
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. Avviare un nuovo cluster crittografato.
Usare lo stesso numero di porta del cluster di destinazione come cluster di origine. Per ulteriori informazioni sull'avvio di un cluster crittografato, consultare [Crittografia dei database di Amazon Redshift](working-with-db-encryption.md).
1. Configurare il processo di scaricamento e caricamento.
Puoi utilizzare l'[Amazon Redshift Unload/Copy Utility](https://github.com/awslabs/amazon-redshift-utils/tree/master/src/UnloadCopyUtility) per aiutarti a migrare i dati tra i cluster. L'utilità esporta dati dal cluster di origine a una posizione in Amazon S3. I dati vengono crittografati con. AWS KMS L'utilità importa quindi automaticamente i dati nella destinazione. Facoltativamente, è possibile usare l'utilità per eseguire la pulizia di Amazon S3 al termine della migrazione.
1. Eseguire un test per verificare il processo e determinare il periodo di tempo per cui sospendere le operazioni di scrittura.
Durante le operazioni di scaricamento e caricamento dei dati, mantenere la coerenza dei dati sospendendo il caricamento dei dati e altre operazioni di scrittura. Usando una delle tabelle di dimensioni maggiori, eseguire il processo di scaricamento e caricamento per stimare i tempi.
1. Creare oggetti di database, come schemi, viste e tabelle. Per aiutarti a generare le istruzioni DDL (Data Definition Language) necessarie, puoi utilizzare gli script presenti [AdminViews](https://github.com/awslabs/amazon-redshift-utils/tree/master/src/AdminViews)nel AWS GitHub repository.
**Per eseguire la migrazione del cluster**
1. Arrestare tutti i processi ETL nel cluster di origine.
Per verificare che non vi siano operazioni di scrittura in corso, usare la Console di gestione di Amazon Redshift per monitorare gli IOPS di scrittura. Per ulteriori informazioni, consultare [Visualizzazione di dati di prestazioni dei cluster](performance-metrics-perf.md).
1. Eseguire le query di convalida identificate in precedenza per raccogliere informazioni sul cluster di origine non crittografato prima della migrazione.
1. Facoltativo: creare una coda di gestione dei carichi di lavoro per usare il numero massimo di risorse disponibili sia nel cluster di origine sia nel cluster di destinazione. Ad esempio, creare una coda denominata `data_migrate` e configurarla con memoria al 95% e simultaneità 4. Per ulteriori informazioni, consultare [Routing di query su code basate su gruppi di utenti e gruppi di query](https://docs.aws.amazon.com/redshift/latest/dg/tutorial-wlm-routing-queries-to-queues.html) nella *Guida per gli sviluppatori di database di Amazon Redshift*.
1. Usando la `data_migrate` coda, esegui il. UnloadCopyUtility
Monitorare i processi UNLOAD e COPY tramite la console Amazon Redshift.
1. Eseguire di nuovo le query di convalida e verificare che i risultati corrispondano a quelli del cluster di origine.
1. Rinominare i cluster di origine e di destinazione per scambiare gli endpoint. Per evitare interruzioni, eseguire questa operazione al di fuori dell'orario di ufficio.
1. Verificare di potersi connettere al cluster di destinazione usando tutti i client SQL, tra cui gli strumenti ETL e di creazione di report.
1. Arrestare il cluster di origine non crittografato.
# Rotazione delle chiavi di crittografia
Per ruotare le chiavi di crittografia utilizzando la console Amazon Redshift, procedere nel modo illustrato di seguito.
**Per ruotare le chiavi crittografiche per un cluster**
1. Accedi a Console di gestione AWS e apri la console Amazon Redshift all'indirizzo. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)
1. Dal menu di navigazione, scegliere **Clusters** (Cluster), quindi scegliere il cluster di cui aggiornare le chiavi di crittografia.
1. Alla voce **Actions (Operazioni)**, scegli **Rotate encryption (Ruota cifratura)** per visualizzare la pagina **Rotate encryption keys (Rotazione delle chiavi crittografiche)**.
1. Nella pagina **Rotate encryption keys (Rotazione delle chiavi crittografiche)**, scegli **Rotate encryption keys (Ruota chiavi crittografiche)**.