Crittografia dei database di Amazon Redshift - Amazon Redshift
Miglioramenti del processo di crittografia per migliori prestazioni e disponibilitàCrittografia dei database per Amazon Redshift tramite AWS KMSCrittografia per Amazon Redshift tramite moduli di sicurezza hardware (HSM)Rotazione delle chiavi di crittografia in Amazon Redshift

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 database di Amazon Redshift

In Amazon Redshift è possibile abilitare la crittografia del database per i cluster per proteggere ulteriormente i dati a riposo. Quando abiliti la crittografia per un cluster, i blocchi di dati e i metadati di sistema vengono crittografati per il cluster e i relativi snapshot.

È possibile abilitare la crittografia all'avvio del cluster oppure modificare un cluster non crittografato per utilizzare la crittografia AWS Key Management Service (AWS KMS). A tale scopo, è possibile utilizzare una chiave AWS gestita 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, consultare Modifica della crittografia del cluster.

Anche se la crittografia è un'impostazione facoltativa in Amazon Redshift, consigliamo di abilitarla per i cluster che contengono 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).

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 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 nodi DC2, non è possibile 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 aver abilitato la crittografia, il completamento della prima istantanea conferma che la crittografia è stata completata.

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

    Si noti che, poiché un' backup-and-restore operazione 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 o CREATE MATERIALIZED VIEW.

Argomenti

Crittografia dei database per Amazon Redshift tramite 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 di quelli AWS KMS keys che il tuo AWS account ha creato o in cui è autorizzato 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 la chiave predefinita come chiave root. La tua chiave predefinita è una chiave AWS gestita creata per il tuo AWS account da utilizzare in Amazon Redshift. AWS KMS crea questa chiave la prima volta che avvii un cluster crittografato in una AWS regione e scegli la chiave predefinita.

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 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 nella AWS Key Management Service Developer Guide.

Dopo aver scelto una chiave radice, Amazon Redshift richiede che AWS KMS generino una chiave dati e la crittografino 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. Per ulteriori informazioni sulle sovvenzioni, sul contesto di crittografia e su altri concetti AWS KMS correlati, consulta Concepts nella Developer Guide.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.

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 , consultare Creazione di un cluster e Gestione dei cluster utilizzando Amazon AWS CLI Redshift API.

Copia di istantanee crittografate in un'altra regione AWS KMSAWS

AWS KMS le chiavi sono specifiche di una regione. AWS Se abiliti la copia degli snapshot di Amazon Redshift in AWS un'altra regione e il cluster di origine e i relativi snapshot sono crittografati utilizzando una chiave radice AWS KMS da, devi configurare una concessione per Amazon Redshift per utilizzare una chiave radice nella regione di destinazione. AWS Questa concessione consente ad Amazon Redshift di crittografare le istantanee nella regione di destinazione. AWS Per ulteriori informazioni sulla copia di snapshot tra regioni, consultare Copia di snapshot in un'altra regione AWS.

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

  2. 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' AWS CLI 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 Configura una copia delle istantanee tra regioni per un cluster crittografato AWS KMS.

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

Per ulteriori informazioni sulla configurazione delle concessioni di copie istantanee per cluster crittografati, consulta. AWS KMSConfigurazione di Amazon Redshift per l'utilizzo delle chiavi di crittografia AWS KMS con l'API di Amazon Redshift e AWS CLI

Crittografia per Amazon Redshift tramite moduli di sicurezza hardware (HSM)

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 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 la versione Classic. Il servizio AWS CloudHSM più recente non è supportato.

AWS CloudHSM Classic è chiuso ai nuovi clienti. Per ulteriori informazioni, consulta la pagina dei prezzi di CloudHSM 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.

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

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, consultare Rotazione delle chiavi di crittografia utilizzando la console di Amazon Redshift e Rotazione delle chiavi di crittografia con l'API di Amazon Redshift e la AWS CLI.