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.

Puoi modificare un cluster non crittografato per utilizzare la crittografia AWS Key Management Service (AWS KMS). A tale scopo puoi utilizzare una chiave di proprietà di AWS 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. 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.

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 AWS KMS ma non con un HSM. 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 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 i nodi RA3 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 a tipi di crittografia come, ad esempio, AWS KMS. 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 crittografi un cluster con i nodi DC2, non puoi eseguire query di scrittura, come con i nodi RA3. 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 (aggiornamenti/eliminazioni/inserimenti) 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.

  Inoltre, poiché l'operazione di backup/ripristino si verifica durante il processo di crittografia, qualsiasi tabella o vista materializzata creata con BACKUP NO non viene mantenuta. Per ulteriori informazioni, consulta CREATE TABLE o CREATE MATERIALIZED VIEW.

Argomenti

• Crittografia tramite AWS KMS

• Crittografia tramite moduli di sicurezza hardware

• Rotazione delle chiavi di crittografia

• Modifica della crittografia del cluster

• Migrazione a un cluster crittografato con HSM

• Rotazione delle chiavi di crittografia

Crittografia tramite AWS KMS

Quando si sceglie AWS KMS per la gestione delle chiavi con Amazon Redshift, viene applicata 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 di AWS KMS keys che Amazon Redshift o l’account AWS ha creato o è autorizzato a utilizzare in 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 proprietà di AWS generata automaticamente come chiave root che l’account AWS può utilizzare in Amazon Redshift.

Se non si desidera utilizzare la chiave predefinita, è necessario disporre (o creare) una chiave KMS gestita dal cliente separata in 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 nella Guida per gli sviluppatori di AWS Key Management Service.

Se desideri utilizzare una chiave AWS KMS da un altro account AWS, è necessario disporre dell'autorizzazione necessaria per l'uso della chiave e specificarne l'Amazon Resource Name (ARN) in Amazon Redshift. Per ulteriori informazioni sull'accesso alle chiavi in AWS KMS, consultare Controllo dell'accesso alle chiavi nellaGuida per gli sviluppatori di AWS Key Management Service.

Dopo aver scelto una chiave root, Amazon Redshift richiede che AWS KMS generi una chiave di dati e che questa venga crittografata con la chiave master 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. Amazon Redshift chiama quindi AWS KMS per decrittare la chiave CEK e carica questa chiave decrittata in memoria. Per ulteriori informazioni su autorizzazioni, contesto di crittografia e altri concetti correlati a AWS KMS, consultare Concetti nella Guida per gli sviluppatori di AWS Key Management Service.

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.

Quando il cluster viene riavviato, Amazon Redshift inizia dalle versioni crittografate e archiviate internamente delle chiavi CEK e DEK, le carica nuovamente in memoria e quindi chiama AWS KMS per decrittare di nuovo la chiave CEK con la chiave KMS perché possa essere caricata 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.

Copia di snapshot crittografati con AWS KMS in un’altra Regione AWS

Le chiavi AWS KMS sono specifiche di una Regione AWS. Se desideri abilitare la copia di snapshot di Amazon Redshift da un cluster di origine crittografato in un’altra Regione AWS, ma preferisci utilizzare la tua chiave AWS KMS per gli snapshot nella destinazione, devi configurare un’autorizzazione per Amazon Redshift per l’uso di una chiave root nell’account nella Regione AWS di destinazione. Questa autorizzazione permette ad Amazon Redshift di crittografare gli snapshot nella Regione AWS di destinazione. Se desideri che gli snapshot nella destinazione siano crittografate con una chiave di proprietà di Regione AWS, non devi configurare alcuna concessione nella Regione AWS di destinazione. Per ulteriori informazioni sulla copia di snapshot tra regioni, consultare Copia di uno snapshot in un’altra Regione AWS.

Nota

Se abiliti la copia degli snapshot da un cluster crittografato e usi AWS KMS per la chiave root, 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 degli snapshot nella regione AWS di origine, rinominare il cluster e quindi configurare e riabilitare la copia degli snapshot.

Il processo di configurazione dell'autorizzazione per la copia degli snapshot viene descritto di seguito.

1. Nella regione AWS di destinazione, creare un'autorizzazione di copia degli snapshot in questo modo:

   • Se non è già disponibile una chiave AWS KMS da usare, è necessario crearne una. Per ulteriori informazioni sulla creazione di chiavi AWS KMS, consultare Creazione di chiavi nella Guida per gli sviluppatori di AWS Key Management Service.

   • Specificare un nome per l'autorizzazione di copia degli snapshot. Questo nome deve essere univoco nella regione AWS per l'account AWS.

   • Specificare l'ID chiave AWS KMS per cui si sta creando l'autorizzazione. Se non si specifica un ID chiave, l'autorizzazione viene applicata alla chiave predefinita.

2. Nella regione AWS di origine, abilitare la copia degli snapshot e specificare il nome dell'autorizzazione di copia degli snapshot creata nella regione AWS di destinazione.

Il processo precedente è necessario solo se si abilita la copia degli snapshot utilizzando la AWS CLI, l'API Amazon Redshift o gli SDK. 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 della copia di snapshot tra Regioni per un cluster crittografato da AWS KMS.

Prima che lo snapshot venga copiato nella regione AWSdi destinazione, Amazon Redshift decritta lo snapshot utilizzando la chiave root nella regione AWS di origine e la crittografa temporaneamente utilizzando una chiave RSA generata in modo casuale che Amazon Redshift gestisce internamente. Amazon Redshift copia quindi lo snapshot su un canale sicuro nella regione AWS di destinazione, decritta lo snapshot utilizzando la chiave RSA gestita internamente e quindi esegue nuovamente la crittografia utilizzando la chiave root nella regione AWS di destinazione.

Crittografia tramite moduli di sicurezza hardware

Se non si utilizza AWS KMS per la gestione delle chiavi, è possibile utilizzare un modulo di sicurezza hardware (HSM) per la gestione delle chiavi con Amazon Redshift.

Importante

La crittografia tramite un modulo di sicurezza hardware non è supportata per tipi di nodo DC2 ed RA3.

I moduli di sicurezza hardware sono dispositivi che forniscono il controllo diretto sulla generazione e sulla 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 usi un modulo di sicurezza hardware per gestire le chiavi di crittografia invece di AWS KMS.

Importante

Amazon Redshift supporta solo AWS CloudHSM Classic. Il servizio AWS CloudHSM più recente non è supportato.

AWS CloudHSM Classic è chiuso ai nuovi clienti. Per ulteriori informazioni, consultare Prezzi di CloudHSM Classic.AWS CloudHSM Classic non è disponibile in tutte le regioni AWS. Per ulteriori informazioni sulle regioni AWS disponibili, consultare Tabella delle regioni AWS.

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, diversamente da AWS KMS, il modulo di sicurezza hardware (HSM) non esporta la chiave 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_HSM (HSM_INCOMPATIBILE) 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, consultare la pagina relativa alla replica di chiavi tra moduli di sicurezza hardware.

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.

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