Seleziona le tue preferenze relative ai cookie

Utilizziamo cookie essenziali e strumenti simili necessari per fornire il nostro sito e i nostri servizi. Utilizziamo i cookie prestazionali per raccogliere statistiche anonime in modo da poter capire come i clienti utilizzano il nostro sito e apportare miglioramenti. I cookie essenziali non possono essere disattivati, ma puoi fare clic su \"Personalizza\" o \"Rifiuta\" per rifiutare i cookie prestazionali.

Se sei d'accordo, AWS e le terze parti approvate utilizzeranno i cookie anche per fornire utili funzionalità del sito, ricordare le tue preferenze e visualizzare contenuti pertinenti, inclusa la pubblicità pertinente. Per continuare senza accettare questi cookie, fai clic su \"Continua\" o \"Rifiuta\". Per effettuare scelte più dettagliate o saperne di più, fai clic su \"Personalizza\".

Crittografia dei database di Amazon Redshift - 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à.

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, il database è crittografato per impostazione predefinita per proteggere i dati inattivi. La crittografia del database si applica al cluster e anche alle relative istantanee.

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

Sebbene sia ancora possibile trasformare il cluster crittografato predefinito in non crittografato dopo la creazione del cluster, ti 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).

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 d'uso 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 (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 o CREATE MATERIALIZED VIEW.

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 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 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. 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 AWS KMS chiavi, consulta. Creazione di un cluster

Copiare istantanee crittografate su un' AWS KMS altra 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 concessione consente ad Amazon Redshift di crittografare le istantanee nella destinazione. Regione AWS 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.

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

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 mediante 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 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, consulta Replicating 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.

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, vedereChiavi di crittografia rotanti.

PrivacyCondizioni del sitoPreferenze cookie
© 2025, Amazon Web Services, Inc. o società affiliate. Tutti i diritti riservati.