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 delle risorse Amazon Aurora
Amazon Aurora protegge i dati sia a riposo che in transito, indipendentemente dal fatto che si spostino tra client locali e Amazon Aurora o tra Amazon Aurora e altre risorse. AWS Amazon Aurora crittografa tutti i dati utente nei cluster Amazon Aurora DB, inclusi log, backup automatici e snapshot.
Dopo la crittografia dei dati, Aurora gestisce l'autenticazione dell'accesso e la decrittografia dei dati in modo trasparente con un impatto minimo sulle prestazioni. Non è quindi necessario modificare le applicazioni client di database per utilizzare la crittografia.
Nota
Per i cluster di DB crittografati e non crittografati, i dati in transito tra le repliche di origine e quelle di lettura vengono crittografati, anche durante la replica tra regioni. AWS
Argomenti
Panoramica della crittografia nelle risorse di Amazon Aurora
I cluster database Amazon Aurora crittografati offrono un livello aggiuntivo di sicurezza dei dati proteggendoli dagli accessi non autorizzati nello storage sottostante. Tutti i nuovi cluster di database creati il 18 febbraio 2026 o dopo il 2026 in Amazon Aurora sono crittografati a riposo utilizzando la crittografia AES-256 standard di settore. Questa crittografia avviene automaticamente in background, proteggendo i dati senza richiedere alcuna azione da parte tua. Inoltre, aiuta a ridurre l'onere operativo e la complessità associati alla protezione dei dati sensibili. Con la crittografia a riposo, è possibile proteggere le applicazioni sensibili alla conformità e critiche per la sicurezza da minacce accidentali e dannose, soddisfacendo al contempo i requisiti normativi.
Amazon Aurora utilizza una AWS Key Management Service chiave per crittografare queste risorse. AWS KMS combina hardware e software sicuri e ad alta disponibilità per fornire un sistema di gestione delle chiavi scalabile per il cloud. Quando si crea un nuovo cluster di database, Amazon Aurora utilizza la crittografia lato server (SSE) con una AWS chiave di proprietà per impostazione predefinita. Tuttavia, puoi scegliere tra tre tipi di crittografia in base alle tue esigenze di sicurezza e conformità:
-
AWS chiave proprietaria (SSE-RDS): una chiave di crittografia completamente AWS controllata che non è possibile visualizzare o gestire, utilizzata automaticamente da Aurora per la crittografia predefinita.
-
AWS chiave gestita (AMK): questa chiave viene creata e gestita da AWS ed è visibile nell'account ma non personalizzabile. Non è previsto alcun canone mensile, ma verranno applicati i costi dell' AWS KMS API.
-
Chiave gestita dal cliente (CMK): la chiave è memorizzata nel tuo account e viene creata, posseduta e gestita da te. Hai il pieno controllo della chiave KMS (a AWS KMS pagamento).
AWS le chiavi gestite sono un'opzione di crittografia legacy che rimane disponibile per la compatibilità con le versioni precedenti. Amazon Aurora utilizza chiavi di AWS proprietà per impostazione predefinita per crittografare i dati, fornendo una solida protezione di sicurezza senza costi aggiuntivi o sovraccarichi di gestione. Nella maggior parte dei casi d'uso, consigliamo di utilizzare la chiave di AWS proprietà predefinita per semplicità ed efficienza in termini di costi, oppure una chiave gestita dal cliente (CMK) se hai bisogno del pieno controllo delle tue chiavi di crittografia. Per ulteriori informazioni sui tipi di chiave, consulta le sezioni Customer Managed Keys e AWS Managed Keys.
Nota
Importante: per le istanze o i cluster di database di origine creati prima del 18 febbraio 2026 (3 marzo 2026 in cui non hai optato per la crittografia, le istantanee, i cloni e le repliche di Amazon Aurora (istanza di lettura) create da tali fonti rimarranno non crittografate. Tuttavia, le operazioni di ripristino e la replica logica all'esterno del cluster Amazon Aurora produrranno istanze crittografate.
Per un cluster database Amazon Aurora crittografato, vengono crittografati tutti i log, i backup e le snapshot. Per ulteriori informazioni sulla disponibilità e sui limiti della crittografia, consulta Disponibilità della crittografia Amazon Aurora e Limiti relativi a istanze database crittografate Amazon Aurora.
Quando crei un cluster DB crittografato, puoi scegliere una chiave gestita dal cliente o consentire Chiave gestita da AWS ad Amazon Aurora di crittografare il tuo cluster DB. Se non specifichi l'identificatore di chiave per una chiave gestita dal cliente, Amazon Aurora lo utilizza per il Chiave gestita da AWS tuo nuovo cluster DB. Amazon Aurora crea una pagina per Amazon Aurora Chiave gestita da AWS per il tuo account. AWS Il tuo AWS account ha un nome diverso Chiave gestita da AWS per Amazon Aurora per ogni AWS regione.
Per gestire le chiavi gestite dal cliente utilizzate per crittografare e decrittografare le risorse di Amazon Aurora, utilizza AWS Key Management Service (AWS KMS).
Utilizzando AWS KMS, puoi creare chiavi gestite dal cliente e definire le politiche per controllare l'uso di queste chiavi gestite dal cliente. AWS KMS supporta CloudTrail, in modo da poter controllare l'utilizzo delle chiavi KMS per verificare che le chiavi gestite dal cliente vengano utilizzate in modo appropriato. Puoi utilizzare le chiavi gestite dai clienti con Amazon Aurora e AWS servizi supportati come Amazon S3, Amazon EBS e Amazon Redshift. Per un elenco dei servizi integrati con AWS KMS, consulta Service Integration.AWS
-
Una volta creata un'istanza DB crittografata, non è possibile modificare la chiave KMS utilizzata da tale istanza. Assicurati di determinare i requisiti della chiave KMS prima di creare l'istanza DB crittografata. Se devi modificare la chiave di crittografia per il tuo cluster DB, segui questi passaggi:
-
Crea un'istantanea manuale del cluster.
-
Ripristina l'istantanea e abilita la crittografia con la chiave KMS desiderata durante l'operazione di ripristino.
-
-
Se si ripristina un'istantanea non crittografata e si sceglie nessuna crittografia, il cluster di database creato verrà crittografato utilizzando la crittografia predefinita a riposo (AWS chiave di proprietà).
-
Non è possibile condividere un'istantanea che è stata crittografata utilizzando l' AWS account che ha condiviso Chiave gestita da AWS l'istantanea.
-
Ogni istanza DB nel cluster DB condivide lo stesso storage crittografato con la stessa chiave KMS.
Importante
Amazon Aurora può perdere l’accesso alla chiave KMS per un cluster di database quando disabiliti la chiave KMS. In questi casi, il cluster di database crittografato entra nello stato inaccessible-encryption-credentials-recoverable. Il cluster di database rimane in questo stato per sette giorni, durante i quali l’istanza viene arrestata. Le chiamate API effettuate al cluster di database durante questo periodo potrebbero non avere esito positivo. Per ripristinare il cluster di database, abilita la chiave KMS e riavvia il cluster. È possibile abilitare la chiave KMS dall'API Console di gestione AWS AWS CLI, o RDS. Riavviare il cluster DB utilizzando il AWS CLI comando start-db-clustero. Console di gestione AWS
Lo stato inaccessible-encryption-credentials-recoverable si applica solo ai cluster di database che possono essere arrestati. Questo stato ripristinabile non è applicabile alle istanze che non possono essere arrestate, come i cluster con repliche di lettura tra Regioni. Per ulteriori informazioni, consulta Limitazioni per l'arresto e l'avvio di cluster di database Aurora.
Se il cluster di database non viene ripristinato entro sette giorni, passa allo stato terminale inaccessible-encryption-credentials. In questo stato, il cluster di database non è più utilizzabile e potrà essere ripristinato solo da un backup. Si consiglia vivamente di attivare sempre i backup per evitare la perdita di dati nei database.
Durante la creazione di un cluster di database, Aurora verifica se il principale chiamante ha accesso alla chiave KMS e genera una concessione dalla chiave KMS che utilizza per l’intera durata del cluster di database. La revoca dell’accesso del principale chiamante alla chiave KMS non influisce su un database in esecuzione. Quando si utilizzano le chiavi KMS in scenari che coinvolgono più account, ad esempio per copiare uno snapshot in un altro account, la chiave KMS deve essere condivisa con l’altro account. Se si crea un cluster di database dallo snapshot senza specificare una chiave KMS diversa, il nuovo cluster utilizza la chiave KMS dell’account di origine. La revoca dell’accesso alla chiave dopo la creazione del cluster di database non influisce sul cluster. Tuttavia, la disabilitazione della chiave influisce su tutti i cluster di database crittografati con tale chiave. Per evitare che ciò accada, specifica una chiave diversa durante l’operazione di copia dello snapshot.
Per ulteriori informazioni sulle chiavi KMS, consulta AWS KMS keys nella Guida per sviluppatori di AWS Key Management Service e AWS KMS key gestione.
Creazione di un cluster di database Amazon Aurora
Tutti i nuovi cluster DB creati a partire dal 18 febbraio 2026 sono crittografati per impostazione predefinita con una chiave proprietaria. AWS
Per crittografare un nuovo cluster DB, utilizzando Chiave gestita da AWS una chiave gestita dal cliente, scegli l'opzione sulla console. Per ulteriori informazioni sulla creazione di un cluster database, consulta Creazione di un cluster database Amazon Aurora.
Se usi il create-db-cluster AWS CLI comando per creare un cluster DB crittografato, imposta il --storage-encrypted parametro. Se utilizzate l'operazione Create DBCluster API, impostate il StorageEncrypted parametro su true.
Una volta creato un cluster di database crittografato, non potrai più modificare la chiave KMS utilizzata da quel cluster di database. Assicurati quindi di determinare i requisiti della chiave KMS prima di creare il cluster di database crittografato.
Se utilizzi il AWS CLI create-db-cluster comando per creare un cluster DB crittografato con una chiave gestita dal cliente, imposta il --kms-key-id parametro su qualsiasi identificatore di chiave per la chiave KMS. Se utilizzi la funzionalità CreateDBInstance dell'API Amazon RDS, imposta il parametro KmsKeyId su un qualsiasi identificatore chiave per la chiave KMS. Per utilizzare una chiave gestita dal cliente in un altro AWS account, specificare l'ARN della chiave o l'alias ARN.
Determinare se la crittografia è attivata per un cluster database
Puoi utilizzare l'API Console di gestione AWS AWS CLI, o RDS per determinare se la crittografia a riposo è attivata per un cluster DB.
Per determinare se la crittografia a riposo è attivata per un cluster database
Accedi a Console di gestione AWS e apri la console Amazon RDS all'indirizzo https://console.aws.amazon.com/rds/
. -
Nel pannello di navigazione, scegliere Databases (Database).
-
Scegliere il nome del cluster database da controllare per visualizzarne i dettagli.
-
Selezionare la casella Configurazione e controllare il valore Crittografia.
Per determinare se la crittografia a riposo è attivata per un cluster DB utilizzando il AWS CLI, chiama il describe-db-clusterscomando con la seguente opzione:
-
--db-cluster-identifier: il nome del cluster di database.
Nell'esempio seguente viene utilizzata una query per restituire TRUE o FALSE per quanto riguarda la crittografia inattiva per il cluster database mydb.
Esempio
aws rds describe-db-clusters --db-cluster-identifiermydb--query "*[].{StorageEncrypted:StorageEncrypted}" --output text
Per determinare se la crittografia a riposo è attivata per un cluster DB utilizzando l'API Amazon RDS, chiama l'DBClustersoperazione Descrivi con il seguente parametro:
-
DBClusterIdentifier: il nome del cluster di database.
Disponibilità della crittografia Amazon Aurora
La crittografia Amazon Aurora è attualmente disponibile per tutti i motori di database e i tipi di storage.
Nota
La crittografia Amazon Aurora non è disponibile per la classe di istanza database db.t2.micro.
Crittografia dei dati in transito
- Crittografia a livello fisico
-
Tutti i dati che fluiscono attraverso la Regioni AWS rete AWS globale vengono automaticamente crittografati a livello fisico prima di lasciare le AWS strutture protette. Tutto il traffico AZs intercorrente è crittografato. Ulteriori livelli di crittografia, inclusi quelli elencati in questa sezione, possono fornire ulteriore protezione.
- Crittografia fornita dal peering Amazon VPC e dal peering transregionale Transit Gateway
-
Tutto il traffico tra regioni che utilizza il peering Amazon VPC e Transit Gateway viene automaticamente crittografato in massa quando esce da una regione. Un ulteriore livello di crittografia viene fornito automaticamente a livello fisico per tutto il traffico prima che lasci le strutture protette. AWS
- Crittografia tra istanze
-
AWS fornisce una connettività sicura e privata tra istanze DB di tutti i tipi. Inoltre, alcuni tipi di istanza utilizzano le funzionalità di offload dell'hardware Nitro System sottostante per crittografare automaticamente il traffico in transito tra le istanze. Questa crittografia utilizza algoritmi AEAD (Authenticated Encryption with Associated Data), con crittografia a 256 bit. Non vi è alcun impatto sulle prestazioni della rete. Per supportare questa crittografia aggiuntiva del traffico in transito tra istanze, è necessario soddisfare i seguenti requisiti:
-
Le istanze utilizzano i seguenti tipi di istanza:
-
Uso generico: M6i, M6id, M6in, M6idn, M7g
-
Ottimizzate per la memoria: R6i, R6id, R6in, R6idn, R7g, X2idn, X2iedn, X2iezn
-
-
Le istanze si trovano nella stessa Regione AWS.
-
Le istanze si trovano nello stesso VPC o VPCs peered e il traffico non passa attraverso un dispositivo o un servizio di rete virtuale, come un sistema di bilanciamento del carico o un gateway di transito.
-
Limiti relativi a istanze database crittografate Amazon Aurora
Esistono le seguenti limitazioni per le istanze database crittografate Amazon Aurora:
-
Non puoi disattivare la crittografia di un cluster database crittografato.
-
Se disponi di un cluster non crittografato esistente, anche tutte le istantanee create da quel cluster non saranno crittografate. Per creare un'istantanea crittografata da un cluster non crittografato, è necessario copiare l'istantanea e specificare una chiave gestita dal cliente durante l'operazione di copia. Non è possibile creare un'istantanea crittografata da un'istantanea non crittografata senza specificare una chiave gestita dal cliente.
-
Una snapshot di un cluster database crittografato deve essere crittografata utilizzando la stessa chiave KMS del cluster database.
-
Non è possibile convertire un cluster database non crittografato in uno crittografato. Tuttavia, puoi ripristinare uno snapshot di un cluster database non crittografato in un cluster database Aurora crittografato. Per eseguire questa operazione, specifica una chiave KMS quando ripristini dalla snapshot non crittografata.
-
Se disponi di un cluster non crittografato esistente, anche qualsiasi replica di Amazon Aurora (istanza di lettura) creata da quel cluster non sarà crittografata. Per creare un cluster crittografato da un cluster non crittografato, devi ripristinare il cluster di database. Il cluster ripristinato verrà crittografato per impostazione predefinita dopo l'operazione di ripristino.
-
Per copiare un'istantanea crittografata da una AWS regione all'altra, è necessario specificare la chiave KMS nella regione di destinazione AWS . Questo perché le chiavi KMS sono specifiche della AWS regione in cui vengono create.
La snapshot di origine resta crittografata nel processo di copia. Amazon Aurora utilizza la crittografia envelope per proteggere i dati durante il processo di copia. Per ulteriori informazioni sulla crittografia envelope, consulta Crittografia envelope nella Guida per sviluppatori di AWS Key Management Service .
-
Non è possibile decrittografare un cluster database crittografato. Tuttavia, puoi esportare i dati da un cluster database crittografato e importarli in un cluster database non crittografato.
