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 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, 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 (PCIDSS), il Sarbanes-Oxley Act ()SOX, l'Health Insurance Portability and Accountability Act (HIPAA) e altri regolamenti 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. È possibile 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 utilizzi unHSM, devi utilizzare certificati client e server per configurare una connessione affidabile tra Amazon Redshift e il tuo. 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 (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-restoreoperazione viene eseguita durante il processo di crittografia, le tabelle o le viste materializzate create con
BACKUP NOnon vengono conservate. Per ulteriori informazioni, consulta CREATETABLEo. CREATEMATERIALIZEDVIEW
Argomenti
Crittografia utilizzando 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 radice, una chiave di crittografia del cluster (), una chiave di crittografia del database (CEK) e le chiavi di crittografia dei dati. DEK
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 Seleziona una KMS chiave da utilizzare come chiave principale 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 avere (o creare) una KMS chiave gestita dal cliente separatamente 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 KMS chiavi, consulta Creating Keys nella AWS Key Management Service Developer Guide.
Se desideri utilizzare una AWS KMS chiave di un altro AWS account, devi avere l'autorizzazione a utilizzare la chiave e specificarne 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 dati viene utilizzata come CEK in Amazon Redshift. AWS KMS esporta i dati crittografati CEK in Amazon Redshift, dove vengono archiviati internamente su disco in una rete separata dal cluster insieme alla concessione alla KMS chiave e al contesto di crittografia per. CEK Solo il codice crittografato CEK viene esportato in Amazon Redshift; KMS la chiave rimane dentro. AWS KMS Amazon Redshift trasmette inoltre i dati crittografati CEK tramite un canale sicuro al cluster e li carica in memoria. Quindi, Amazon Redshift chiama AWS KMS per decrittografare CEK e carica i dati decrittografati in memoria. CEK 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
Successivamente, Amazon Redshift genera in modo casuale una chiave da utilizzare come DEK e la carica nella memoria del cluster. Il valore decrittografato CEK viene utilizzato per crittografare ilDEK, che viene quindi passato su un canale sicuro dal cluster per essere archiviato internamente da Amazon Redshift su disco in una rete separata dal cluster. AnalogamenteCEK, sia la versione crittografata che quella decrittografata di DEK vengono caricate nella memoria del cluster. La versione decrittografata di DEK viene quindi utilizzata 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 and, CEK le ricarica in memoria DEK e quindi AWS KMS chiama nuovamente per decrittografarle con CEK KMS la chiave in modo che possa essere caricata in memoria. La versione decrittografata CEK viene quindi utilizzata per decrittografarla DEK nuovamente e quella decrittografata DEK viene caricata in memoria e utilizzata per crittografare e decrittografare le chiavi dei blocchi di dati secondo necessità.
Per ulteriori informazioni sulla creazione di cluster Amazon Redshift crittografati con AWS KMS chiavi, consulta. Creazione di un cluster
Copia AWS KMS: istantanee crittografate in un'altra regione AWS
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 Copiare un'istantanea su un'altra AWS Regione.
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.
-
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.
-
-
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 Amazon Redshift o. AWS CLI API 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 istantanea interregionale per un AWS KMS: cluster crittografato.
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 generata casualmente che Amazon Redshift gestisce internamente. RSA Amazon Redshift copia quindi lo snapshot su un canale sicuro AWS nella regione di destinazione, decripta lo snapshot utilizzando la RSA chiave 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
HSMla crittografia non è supportata per nessun tipo DC2 di RA3 nodo.
HSMssono 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 se lo utilizzi HSM per gestire le chiavi di AWS KMS crittografia anziché.
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 i prezzi di Cloud HSM Classic
Quando configuri il cluster per l'utilizzo di unHSM, Amazon Redshift invia una richiesta a HSM per generare e archiviare una chiave da utilizzare come. CEK Tuttavia, a differenza AWS KMS, HSM non li esporta CEK in Amazon Redshift. Invece, Amazon Redshift genera casualmente il file DEK nel cluster e lo passa HSM al. CEK HSMrestituisce i dati crittografati DEK ad Amazon Redshift, dove vengono ulteriormente crittografati utilizzando una chiave radice interna generata casualmente e archiviati internamente su disco in una rete separata dal cluster. Amazon Redshift carica anche la versione decrittografata di quella DEK in memoria nel cluster in modo che DEK possa essere utilizzata per crittografare e decrittografare le singole chiavi per i blocchi di dati.
Se il cluster viene riavviato, Amazon Redshift decrittografa i dati archiviati internamente, con DEK doppia crittografia, utilizzando la chiave principale interna per riportare i dati archiviati internamente allo stato -encrypted. DEK CEK Il CEK file -encrypted DEK viene quindi passato HSM a essere decrittografato e restituito ad Amazon Redshift, dove può essere nuovamente caricato in memoria per essere utilizzato con le singole chiavi del blocco di dati.
Configurazione di una connessione affidabile tra Amazon Redshift e un HSM
Quando scegli di utilizzare un HSM per la gestione della tua chiave del cluster, devi configurare un collegamento di rete affidabile tra Amazon Redshift e il tuo. HSM A questo scopo, devi configurare certificati client e server. La connessione affidabile viene utilizzata per passare le chiavi di crittografia tra Amazon Redshift HSM 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. Scarichi e registri il certificato client pubblico nel tuo computer e HSM lo assegni alla partizione applicabile. HSM
Fornisci ad Amazon Redshift l'indirizzo HSM IP, il nome della HSM partizione, la password HSM della partizione e un certificato HSM del server pubblico, che viene crittografato utilizzando una chiave radice interna. Amazon Redshift completa il processo di configurazione e verifica che sia in grado di connettersi a. HSM In caso contrario, il cluster viene messo nello HSM stato INCOMPATIBLE _ e il cluster non viene creato. In questo caso, devi eliminare il cluster incompleto e riprovare.
Importante
Quando modifichi il cluster per utilizzare una HSM partizione diversa, Amazon Redshift verifica che possa connettersi alla nuova partizione, ma non verifica l'esistenza 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
Dopo la configurazione iniziale, se Amazon Redshift non riesce a connettersi aHSM, 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. Quando avvii il processo di rotazione delle chiavi, Amazon Redshift esegue la rotazione CEK per il cluster specificato e per qualsiasi istantanea automatica o manuale del cluster. Amazon Redshift ruota anche le istantanee DEK per il cluster specificato, ma non può ruotare le istantanee mentre sono archiviate internamente in Amazon Simple Storage Service (Amazon S3) Simple Storage Service (Amazon S3) e crittografate utilizzando l'esistente. DEK DEK
Durante la rotazione, il cluster viene messo in KEYS uno stato ROTATING _ fino al completamento, momento in cui il cluster 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 dei tasti, vedereChiavi di crittografia rotanti.
