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à. # Protezione dei dati tramite crittografia Amazon Aurora crittografa le risorse del database a livello di storage. Puoi anche crittografare le connessioni ai cluster DB. **Topics** + [Crittografia delle risorse Amazon Aurora](Overview.Encryption.md) + [AWS KMS key gestione](Overview.Encryption.Keys.md) + [Utilizzo SSL/TLS per crittografare una connessione a un'](UsingWithRDS.SSL.md) + [Rotazione del certificato SSL/TLS](UsingWithRDS.SSL-certificate-rotation.md) # 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 **Topics** + [Panoramica della crittografia nelle risorse di Amazon Aurora](#Overview.Encryption.Overview) + [Creazione di un cluster di database Amazon Aurora](#Overview.Encryption.Enabling) + [Determinare se la crittografia è attivata per un cluster database](#Overview.Encryption.Determining) + [Disponibilità della crittografia Amazon Aurora](#Overview.Encryption.Availability) + [Crittografia dei dati in transito](#Overview.Encryption.InTransit) + [Limiti relativi a istanze database crittografate Amazon Aurora](#Overview.Encryption.Limitations) ## 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.](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-key) 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](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-mgmt) 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](#Overview.Encryption.Availability) e [Limiti relativi a istanze database crittografate Amazon Aurora](#Overview.Encryption.Limitations). 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)](https://docs.aws.amazon.com/kms/latest/developerguide/). 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](https://aws.amazon.com/kms/features/#AWS_Service_Integration) Alcune considerazioni sull’utilizzo delle chiavi KMS: + 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-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/start-db-cluster.html)o. 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](aurora-cluster-stop-start.md#aurora-cluster-stop-limitations). 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](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#kms_keys) nella *Guida per sviluppatori di AWS Key Management Service * e [AWS KMS key gestione](Overview.Encryption.Keys.md). ## 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](Aurora.CreateInstance.md). Se usi il [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) AWS CLI comando per creare un cluster DB crittografato, imposta il `--storage-encrypted` parametro. Se utilizzate l'operazione [Create DBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) 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. ### Console **Per determinare se la crittografia a riposo è attivata per un cluster database** 1. Accedi a Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Nel pannello di navigazione, scegliere **Databases (Database)**. 1. Scegliere il nome del cluster database da controllare per visualizzarne i dettagli. 1. Selezionare la casella **Configurazione** e controllare il valore **Crittografia**. ![\[Verifica della crittografia inattiva per un cluster database\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/encryption-aurora-instance.png) ### AWS CLI Per determinare se la crittografia a riposo è attivata per un cluster DB utilizzando il AWS CLI, chiama il [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html)comando 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`. **Example** ``` 1. aws rds describe-db-clusters --db-cluster-identifier mydb --query "*[].{StorageEncrypted:StorageEncrypted}" --output text ``` ### API RDS Per determinare se la crittografia a riposo è attivata per un cluster DB utilizzando l'API Amazon RDS, chiama l'DBClustersoperazione [Descrivi](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html) 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](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping) 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. # AWS KMS key gestione Amazon Aurora si integra automaticamente con [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/) per la gestione delle chiavi. Amazon Aurora utilizza la crittografia a busta. Per ulteriori informazioni sulla crittografia envelope, consulta [Crittografia envelope](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping) nella *Guida per sviluppatori di AWS Key Management Service *. È possibile utilizzare due tipi di AWS KMS chiavi per crittografare i cluster delle DB. + Per avere il pieno controllo su una chiave KMS, devi creare una *chiave gestita dal cliente*. Per ulteriori informazioni sulle chiavi gestite dal cliente, consulta [Chiavi gestite dal cliente](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) nella *Guida per gli sviluppatori di AWS Key Management Service *. + *Chiavi gestite da AWS*sono chiavi KMS presenti nel tuo account che vengono create, gestite e utilizzate per tuo conto da un AWS servizio integrato con. AWS KMS Per impostazione predefinita, la Chiave gestita da AWS RDS (`aws/rds`) viene utilizzata per la crittografia. Non puoi gestire, ruotare o eliminare l'RDS. Chiave gestita da AWS Per ulteriori informazioni [Chiavi gestite da AWS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk)in merito Chiavi gestite da AWS, consulta la Guida per gli *AWS Key Management Service sviluppatori*. Per gestire le chiavi KMS utilizzate per i cluster di istanze crittografate Amazon Aurora, usa [AWS Key Management Service il AWS KMS(](https://docs.aws.amazon.com/kms/latest/developerguide/)) nella console, AWS CLI l'o [AWS KMS l'](https://console.aws.amazon.com/kms)API. AWS KMS Puoi visualizzare i log di controllo di ogni operazione eseguita con una chiave gestita da AWS o dal cliente utilizzando [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/). Per ulteriori informazioni sulla rotazione delle chiavi, consulta [Rotazione delle chiavi AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html). ## Autorizzazione dell'uso di una chiave gestita dal cliente Quando Aurora utilizza una chiave gestita dal cliente in operazioni che coinvolgono la crittografia, funziona per conto dell’utente che crea o modifica la risorsa Aurora. Per creare una risorsa Aurora utilizzando una chiave gestita dal cliente, un utente deve disporre delle autorizzazioni per chiamare le seguenti operazioni su tale chiave: + `kms:CreateGrant` + `kms:DescribeKey` Puoi specificare queste autorizzazioni necessarie in una policy chiave o in una policy IAM se la policy chiave lo consente. **Importante** Quando utilizzi dichiarazioni di rifiuto esplicite per tutte le risorse (\$1) nelle politiche AWS KMS chiave con servizi gestiti come Amazon RDS, devi specificare una condizione per consentire l'account proprietario della risorsa. L’operazione potrebbe non riuscire senza questa condizione, anche se la regola di rifiuto include eccezioni per l’utente IAM. **Suggerimento** Per seguire il principio del privilegio minimo, non consentire l'accesso completo a `kms:CreateGrant`. Utilizza invece la [chiave kms: ViaService condition](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-via-service) per consentire all'utente di creare concessioni sulla chiave KMS solo quando la concessione viene creata per conto dell'utente da un servizio. AWS Esistono diversi modi per rendere la policy IAM più efficace. Ad esempio, se desideri consentire l'utilizzo della chiave gestita dal cliente solo per le richieste che hanno origine in Aurora, utilizza [ kms:ViaService la chiave di condizione con `rds..amazonaws.com` il](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-via-service) valore. Puoi inoltre usare le chiavi o i valori nel [Contesto di crittografia di Amazon RDS](#Overview.Encryption.Keys.encryptioncontext) come condizione per utilizzare la chiave gestita dal cliente per la crittografia. Per ulteriori informazioni, consulta [Autorizzazione per gli utenti in altri account di utilizzare una chiave KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html) nella *Guida per gli sviluppatori di AWS Key Management Service * e [Policy delle chiavi in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies). ## Contesto di crittografia di Amazon RDS Quando Aurora utilizza la chiave KMS o quando Amazon EBS utilizza la chiave KMS per conto di Aurora, il servizio specifica un [contesto di crittografia](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#encrypt_context). Il contesto di crittografia è costituito da [dati autenticati aggiuntivi](https://docs.aws.amazon.com/crypto/latest/userguide/cryptography-concepts.html#term-aad) (AAD) AWS KMS utilizzati per garantire l'integrità dei dati. Quando viene specificato un contesto di crittografia per un'operazione di crittografia, il servizio deve specificare lo stesso contesto di crittografia per l'operazione di decrittografia. In caso contrario, la decrittografia ha esito negativo. Il contesto di crittografia viene scritto nei log [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) per aiutarti a comprendere perché è stata utilizzata una determinata chiave KMS. CloudTrail I registri potrebbero contenere molte voci che descrivono l'uso di una chiave KMS, ma il contesto di crittografia in ogni voce di registro può aiutarti a determinare il motivo di quel particolare utilizzo. Come minimo, Aurora utilizza sempre l’ID del cluster di database per il contesto di crittografia, come nel seguente esempio in formato JSON: ``` { "aws:rds:dbc-id": "cluster-CQYSMDPBRZ7BPMH7Y3RTDG5QY" } ``` Questo contesto di crittografia consente di identificare il cluster di database per cui è stata utilizzata la chiave KMS. Quando la chiave KMS viene utilizzata per un cluster di database specifico e un determinato volume Amazon EBS, sia l’ID del cluster di database sia l’ID del volume Amazon EBS vengono utilizzati per il contesto di crittografia, come nel seguente esempio in formato JSON: ``` { "aws:rds:dbc-id": "cluster-BRG7VYS3SVIFQW7234EJQOM5RQ", "aws:ebs:id": "vol-ad8c6542" } ``` # Utilizzo SSL/TLS per crittografare una connessione a un' Puoi utilizzare Secure Socket Layer (SSL) o Transport Layer Security (TLS) dall'applicazione per crittografare una connessione a un cluster di database che esegue Aurora MySQL o Aurora PostgreSQL. Le connessioni SSL/TLS forniscono un livello di sicurezza tramite la crittografia dei dati che si spostano tra il client e un cluster. Facoltativamente, la SSL/TLS connessione può eseguire la verifica dell'identità del server convalidando il certificato del server installato nel database. Per richiedere la verifica dell'identità del server, esegui questa procedura generale: 1. Scegli l'**autorità di certificazione (CA)** che firma il **certificato del server di database** per il database. Per ulteriori informazioni sulle autorità di certificazione, consulta [Autorità di certificazione](#UsingWithRDS.SSL.RegionCertificateAuthorities). 1. Scarica un bundle di certificati da utilizzare quando ti connetti al database. Per scaricare un bundle di certificati, consulta [Pacchetti di certificati di Regione AWS](#UsingWithRDS.SSL.CertificatesAllRegions). **Nota** Tutti i certificati sono disponibili solo per il download tramite connessioni SSL/TLS. 1. Connettiti al database utilizzando il processo del tuo motore DB per l'implementazione delle SSL/TLS connessioni. Ogni motore DB ha il proprio processo di implementazione SSL/TLS. To learn how to implement SSL/TLS per il tuo database, segui il link che corrisponde al tuo motore DB: + [Sicurezza con Amazon Aurora MySQL](AuroraMySQL.Security.md) + [Sicurezza con Amazon Aurora PostgreSQL](AuroraPostgreSQL.Security.md) ## Autorità di certificazione L'**autorità di certificazione (CA)** è il certificato che identifica la CA root della catena di certificati. La CA firma **il certificato del server di database**, che è il certificato del server installato su ogni istanza database. Il certificato del server di database identifica l'istanza database come server attendibile. ![\[Panoramica dell'autorità di certificazione\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/certificate-authority-overview.png) Amazon RDS fornisce quanto segue CAs per firmare il certificato del server DB per un database. **** | Autorità di certificazione (CA) | Description | Common name (CN) (Nome comune) | | --- | --- | --- | | rds-ca-rsa2048-g1 | Utilizza un'autorità di certificazione con algoritmo a chiave privata RSA 2048 e algoritmo di firma nella maggior parte dei casi. SHA256 Regioni AWS Nel AWS GovCloud (US) Regions, questa CA utilizza un'autorità di certificazione con algoritmo a chiave privata RSA 2048 e algoritmo di firma. SHA384 supporta la rotazione automatica dei certificati del server. | Amazon RDS region-identifier Root CA RSA2048 G1 | | rds-ca-rsa4096-g1 | Utilizza un'autorità di certificazione con algoritmo a chiave privata RSA 4096 e algoritmo di firma. SHA384 supporta la rotazione automatica dei certificati del server. | Amazon RDS region-identifier Root CA RSA4096 G1 | | rds-ca-ecc384-g1 | Utilizza un'autorità di certificazione con algoritmo a chiave privata ECC 384 e algoritmo di firma. SHA384 supporta la rotazione automatica dei certificati del server. | Amazon RDS region-identifier Root CA ECC384 G1 | **Nota** [Se utilizzi il AWS CLI, puoi vedere le validità delle autorità di certificazione sopra elencate utilizzando describe-certificates.](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-certificates.html) Questi certificati CA sono inclusi nel bundle di certificati regionali e globali. Quando si utilizza la CA rds-ca-rsa 2048-g1, rds-ca-rsa 4096-g1 o rds-ca-ecc 384-g1 con un database, RDS gestisce il certificato del server DB sul database. RDS esegue automaticamente la rotazione del certificato del server di database prima della scadenza. ### Impostazione della CA per il database Puoi impostare la CA per un database quando esegui le seguenti attività: + Crea un cluster Aurora DB: puoi impostare la CA per un'istanza DB in un cluster Aurora quando crei la prima istanza DB nel cluster DB utilizzando l' AWS CLI API o RDS. Attualmente, non puoi impostare la CA per istanze database in un cluster database durante la creazione del cluster database usando la console RDS. Per le istruzioni, consulta [Creazione di un cluster database Amazon Aurora](Aurora.CreateInstance.md). + Modifica di un'istanza database: puoi impostare la CA per un'istanza database in un cluster database modificandola. Per le istruzioni, consulta [Modifica di un'istanza database in un cluster database](Aurora.Modifying.md#Aurora.Modifying.Instance). **Nota** La CA predefinita è impostata su 2048-g1. rds-ca-rsa [È possibile sovrascrivere la CA predefinita per il proprio Account AWS utilizzando il comando modify-certificates.](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-certificates.html) Le opzioni disponibili CAs dipendono dal motore DB e dalla versione del motore DB. Quando si utilizza il Console di gestione AWS, è possibile scegliere la CA utilizzando l'impostazione **dell'autorità di certificazione**, come mostrato nell'immagine seguente. ![\[Opzione Certificate authority (Autorità di certificazione)\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/certificate-authority.png) La console mostra solo CAs le versioni disponibili per il motore DB e la versione del motore DB. Se si utilizza il AWS CLI, è possibile impostare la CA per un'istanza DB utilizzando il [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)comando [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)or. Se utilizzi il AWS CLI, puoi vedere quello disponibile CAs per il tuo account utilizzando il comando [describe-certificates](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-certificates.html). Questo comando mostra nell'output anche la data di scadenza per ogni CA in `ValidTill`. Puoi trovare CAs quelli disponibili per uno specifico motore DB e una versione del motore DB utilizzando il comando. [describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) L'esempio seguente mostra la CAs versione del motore DB RDS per PostgreSQL disponibile per la versione predefinita. ``` aws rds describe-db-engine-versions --default-only --engine postgres ``` L’output è simile a quello riportato di seguito. I disponibili sono elencati in. CAs `SupportedCACertificateIdentifiers` L'output mostra anche se la versione del motore di database supporta la rotazione del certificato senza riavvio in `SupportsCertificateRotationWithoutRestart`. ``` { "DBEngineVersions": [ { "Engine": "postgres", "MajorEngineVersion": "13", "EngineVersion": "13.4", "DBParameterGroupFamily": "postgres13", "DBEngineDescription": "PostgreSQL", "DBEngineVersionDescription": "PostgreSQL 13.4-R1", "ValidUpgradeTarget": [], "SupportsLogExportsToCloudwatchLogs": false, "SupportsReadReplica": true, "SupportedFeatureNames": [ "Lambda" ], "Status": "available", "SupportsParallelQuery": false, "SupportsGlobalDatabases": false, "SupportsBabelfish": false, "SupportsCertificateRotationWithoutRestart": true, "SupportedCACertificateIdentifiers": [ "rds-ca-rsa2048-g1", "rds-ca-ecc384-g1", "rds-ca-rsa4096-g1" ] } ] } ``` ### Validità dei certificati del server di database La validità del certificato del server di database dipende dal motore di database e dalla versione del motore di database. Se la versione del motore di database supporta la rotazione del certificato senza riavvio, la validità del certificato del server di database è di 1 anno. In caso contrario, la validità è di 3 anni. Per ulteriori informazioni sulla rotazione dei certificati del server di database, consulta [Rotazione automatica dei certificati del server](UsingWithRDS.SSL-certificate-rotation.md#UsingWithRDS.SSL-certificate-rotation-server-cert-rotation). ### Visualizzazione della CA per l’istanza database È possibile vedere i dettagli sulla CA per un database visualizzando la scheda **Connettività e sicurezza** nella console, come nell’immagine seguente. ![\[Dettagli dell'autorità di certificazione\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/certificate-authority-details.png) Se si utilizza il AWS CLI, è possibile visualizzare i dettagli sulla CA per un'istanza DB utilizzando il [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)comando. ## Scarica i pacchetti di certificati per Quando ci si connette al database con SSL o TLS, l’istanza database richiede un certificato di attendibilità di Amazon RDS. Seleziona il link appropriato nella tabella seguente per scaricare il bundle corrispondente alla Regione AWS in cui si ospita il database. ### Pacchetti di certificati di Regione AWS I pacchetti di certificati per tutte le regioni Regioni AWS e GovCloud (Stati Uniti) contengono i seguenti certificati CA root: + `rds-ca-rsa2048-g1` + `rds-ca-rsa4096-g1` + `rds-ca-ecc384-g1` I certificati `rds-ca-rsa4096-g1` e `rds-ca-ecc384-g1` non sono disponibili nelle seguenti Regioni: + Asia Pacifico (Mumbai) + Asia Pacifico (Melbourne) + Canada occidentale (Calgary) + Europa (Zurigo) + Europa (Spagna) + Israele (Tel Aviv) L'application trust store deve registrare solo il certificato CA principale. Non registrate i certificati CA intermedi nel vostro trust store poiché ciò potrebbe causare problemi di connessione quando RDS ruota automaticamente il certificato del server DB. **Nota** Il proxy e Aurora Serverless v1 l'uso di Amazon RDS i certificati di AWS Certificate Manager (ACM). Se si utilizza Server proxy per RDS, non è necessario scaricare certificati Amazon RDS o aggiornare applicazioni che utilizzano connessioni Server proxy per RDS. Per ulteriori informazioni, consulta [Utilizzo TLS/SSL con RDS Proxy](rds-proxy.howitworks.md#rds-proxy-security.tls). Se si utilizza Aurora Serverless v1, il download dei certificati Amazon RDS non è richiesto. Per ulteriori informazioni, consulta [Utilizzo con TLS/SSL Aurora Serverless v1](aurora-serverless.md#aurora-serverless.tls). Per scaricare un pacchetto di certificati per un Regione AWS, seleziona il link Regione AWS che ospita il database nella tabella seguente. | **AWS Region** | **Bundle di certificati (PEM)** | **Pacchetto di certificati () PKCS7** | | --- | --- | --- | | Qualsiasi pubblicità Regione AWS | [global-bundle.pem](https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem) | [global-bundle.p7b](https://truststore.pki.rds.amazonaws.com/global/global-bundle.p7b) | | Stati Uniti orientali (Virginia settentrionale) | [us-east-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/us-east-1/us-east-1-bundle.pem) | [us-east-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/us-east-1/us-east-1-bundle.p7b) | | US East (Ohio) | [us-east-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/us-east-2/us-east-2-bundle.pem) | [us-east-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/us-east-2/us-east-2-bundle.p7b) | | US West (N. California) | [us-west-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/us-west-1/us-west-1-bundle.pem) | [us-west-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/us-west-1/us-west-1-bundle.p7b) | | US West (Oregon) | [us-west-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/us-west-2/us-west-2-bundle.pem) | [us-west-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/us-west-2/us-west-2-bundle.p7b) | | Africa (Cape Town) | [af-south-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/af-south-1/af-south-1-bundle.pem) | [af-sud-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/af-south-1/af-south-1-bundle.p7b) | | Asia Pacific (Hong Kong) | [ap-east-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-east-1/ap-east-1-bundle.pem) | [ap-east-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-east-1/ap-east-1-bundle.p7b) | | Asia Pacifico (Hyderabad) | [ap-south-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-south-2/ap-south-2-bundle.pem) | [ap-south-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-south-2/ap-south-2-bundle.p7b) | | Asia Pacifico (Giacarta) | [ap-southeast-3-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-southeast-3/ap-southeast-3-bundle.pem) | [ap-southeast-3-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-southeast-3/ap-southeast-3-bundle.p7b) | | Asia Pacifico (Malesia) | [ap-southeast-5-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-southeast-5/ap-southeast-5-bundle.pem) | [ap-southeast-5-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-southeast-5/ap-southeast-5-bundle.p7b) | | Asia Pacifico (Melbourne) | [ap-southeast-4-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-southeast-4/ap-southeast-4-bundle.pem) | [ap-southeast-4-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-southeast-4/ap-southeast-4-bundle.p7b) | | Asia Pacifico (Mumbai) | [ap-south-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-south-1/ap-south-1-bundle.pem) | [ap-south-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-south-1/ap-south-1-bundle.p7b) | | Asia Pacific (Osaka) | [ap-northeast-3-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-northeast-3/ap-northeast-3-bundle.pem) | [ap-northeast-3-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-northeast-3/ap-northeast-3-bundle.p7b) | | Asia Pacifico (Thailandia) | [ap-southeast-7-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-southeast-7/ap-southeast-7-bundle.pem) | [ap-southeast-7-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-southeast-7/ap-southeast-7-bundle.p7b) | | Asia Pacifico (Tokyo) | [ap-northeast-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-northeast-1/ap-northeast-1-bundle.pem) | [ap-northeast-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-northeast-1/ap-northeast-1-bundle.p7b) | | Asia Pacific (Seoul) | [ap-northeast-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-northeast-2/ap-northeast-2-bundle.pem) | [ap-northeast-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-northeast-2/ap-northeast-2-bundle.p7b) | | Asia Pacific (Singapore) | [ap-southeast-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-southeast-1/ap-southeast-1-bundle.pem) | [ap-southeast-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-southeast-1/ap-southeast-1-bundle.p7b) | | Asia Pacific (Sydney) | [ap-southeast-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-southeast-2/ap-southeast-2-bundle.pem) | [ap-southeast-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-southeast-2/ap-southeast-2-bundle.p7b) | | Canada (Central) | [ca-central-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/ca-central-1/ca-central-1-bundle.pem) | [ca-central-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ca-central-1/ca-central-1-bundle.p7b) | | Canada occidentale (Calgary) | [ca-west-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/ca-west-1/ca-west-1-bundle.pem) | [ca-west-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ca-west-1/ca-west-1-bundle.p7b) | | Europa (Francoforte) | [eu-central-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-central-1/eu-central-1-bundle.pem) | [eu-central-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-central-1/eu-central-1-bundle.p7b) | | Europe (Ireland) | [eu-west-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-west-1/eu-west-1-bundle.pem) | [eu-west-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-west-1/eu-west-1-bundle.p7b) | | Europe (London) | [eu-west-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-west-2/eu-west-2-bundle.pem) | [eu-west-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-west-2/eu-west-2-bundle.p7b) | | Europe (Milan) | [eu-south-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-south-1/eu-south-1-bundle.pem) | [eu-sud-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-south-1/eu-south-1-bundle.p7b) | | Europe (Paris) | [eu-west-3-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-west-3/eu-west-3-bundle.pem) | [eu-west-3-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-west-3/eu-west-3-bundle.p7b) | | Europa (Spagna) | [eu-south-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-south-2/eu-south-2-bundle.pem) | [eu-south-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-south-2/eu-south-2-bundle.p7b) | | Europa (Stoccolma) | [eu-nord-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-north-1/eu-north-1-bundle.pem) | [eu-nord-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-north-1/eu-north-1-bundle.p7b) | | Europa (Zurigo) | [eu-central-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-central-2/eu-central-2-bundle.pem) | [eu-central-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-central-2/eu-central-2-bundle.p7b) | | Israele (Tel Aviv) | [il-central-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/il-central-1/il-central-1-bundle.pem) | [il-central-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/il-central-1/il-central-1-bundle.p7b) | | Messico (Centrale) | [mx-central-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/mx-central-1/mx-central-1-bundle.pem) | [mx-central-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/mx-central-1/mx-central-1-bundle.p7b) | | Middle East (Bahrain) | [me-sud-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/me-south-1/me-south-1-bundle.pem) | [me-sud-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/me-south-1/me-south-1-bundle.p7b) | | Medio Oriente (Emirati Arabi Uniti) | [me-central-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/me-central-1/me-central-1-bundle.pem) | [me-central-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/me-central-1/me-central-1-bundle.p7b) | | Sud America (San Paolo) | [sa-east-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/sa-east-1/sa-east-1-bundle.pem) | [sa-east-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/sa-east-1/sa-east-1-bundle.p7b) | | Qualsiasi AWS GovCloud (US) Region s | [global-bundle.pem](https://truststore.pki.us-gov-west-1.rds.amazonaws.com/global/global-bundle.pem) | [global-bundle.p7b](https://truststore.pki.us-gov-west-1.rds.amazonaws.com/global/global-bundle.p7b) | | AWS GovCloud (Stati Uniti orientali) | [us-gov-east-1 bundle.pem](https://truststore.pki.us-gov-west-1.rds.amazonaws.com/us-gov-east-1/us-gov-east-1-bundle.pem) | [us-gov-east-1-pacchetto.p7b](https://truststore.pki.us-gov-west-1.rds.amazonaws.com/us-gov-east-1/us-gov-east-1-bundle.p7b) | | AWS GovCloud (Stati Uniti occidentali) | [us-gov-west-1-bundle.pem](https://truststore.pki.us-gov-west-1.rds.amazonaws.com/us-gov-west-1/us-gov-west-1-bundle.pem) | [us-gov-west-1-pacchetto.p7b](https://truststore.pki.us-gov-west-1.rds.amazonaws.com/us-gov-west-1/us-gov-west-1-bundle.p7b) | ### Visualizzazione del contenuto del certificato CA Per verificare il contenuto del bundle di certificati CA, utilizza il comando seguente: ``` keytool -printcert -v -file global-bundle.pem ``` # Rotazione del certificato SSL/TLS I certificati dell’autorità di certificazione Amazon RDS rds-ca-2019 scadono ad agosto 2024. Se utilizzi o prevedi di utilizzare Secure Sockets Layer (SSL) o Transport Layer Security (TLS) con verifica del certificato per connetterti alle istanze DB RDS o ai 384-g1. rds-ca-rsa rds-ca-rsa rds-ca-ecc Se attualmente non lo utilizzi SSL/TLS con la verifica dei certificati, potresti avere ancora un certificato CA scaduto e devi aggiornarlo con un nuovo certificato CA se prevedi di utilizzarlo SSL/TLS con la verifica dei certificati per connetterti ai tuoi database RDS. Amazon RDS fornisce nuovi certificati CA come best practice di AWS sicurezza. Per informazioni sui nuovi certificati e sulle AWS regioni supportate, consulta[Utilizzo SSL/TLS per crittografare una connessione a un'](UsingWithRDS.SSL.md). Per aggiornare il certificato CA per il database, utilizza i seguenti metodi: + [Aggiornamento del certificato CA modificando l’istanza database ](#UsingWithRDS.SSL-certificate-rotation-updating) + [Aggiornamento del certificato CA mediante l'applicazione di manutenzione](#UsingWithRDS.SSL-certificate-rotation-maintenance-update) Prima di aggiornare le istanze database per utilizzare il nuovo certificato CA, assicurati di aggiornare i client o le applicazioni che si collegano ai database RDS. ## Considerazioni sulla rotazione dei certificati Considera le seguenti situazioni prima di ruotare il certificato: + Il proxy e Aurora Serverless v1 l'uso di Amazon RDS i certificati di AWS Certificate Manager (ACM). Se utilizzi RDS Proxy, quando ruoti il SSL/TLS certificato non devi aggiornare le applicazioni che utilizzano connessioni proxy RDS. Per ulteriori informazioni, consulta [Utilizzo TLS/SSL con RDS Proxy](rds-proxy.howitworks.md#rds-proxy-security.tls). + Se si utilizza Aurora Serverless v1, il download dei certificati Amazon RDS non è richiesto. Per ulteriori informazioni, consulta [Utilizzo con TLS/SSL Aurora Serverless v1](aurora-serverless.md#aurora-serverless.tls). + Se si utilizza un’applicazione Go versione 1.15 con un’istanza database creata o aggiornata al certificato rds-ca-2019 prima del 28 luglio 2020, è necessario aggiornare nuovamente il certificato. Utilizza il comando `modify-db-instance` , utilizzando il nuovo identificatore del certificato CA. Puoi trovare quelli disponibili per uno specifico motore DB e una versione del motore DB utilizzando CAs il comando. `describe-db-engine-versions` Se hai creato il database o aggiornato il relativo certificato dopo il 28 luglio 2020, non è richiesta alcuna azione. Per ulteriori informazioni, vedete [Go GitHub issue \$139568](https://github.com/golang/go/issues/39568). ## Aggiornamento del certificato CA modificando l’istanza database *L'esempio seguente aggiorna il certificato CA da *rds-ca-2019 a 2048-g1*. rds-ca-rsa* Puoi scegliere un certificato diverso. Per ulteriori informazioni, consulta[Autorità di certificazione](UsingWithRDS.SSL.md#UsingWithRDS.SSL.RegionCertificateAuthorities). Aggiorna l’archivio di trust delle applicazioni per ridurre il tempo di inattività associato all’aggiornamento del certificato CA. Per ulteriori informazioni sui riavvii associati alla rotazione del certificato CA, consulta [Rotazione automatica dei certificati del server](#UsingWithRDS.SSL-certificate-rotation-server-cert-rotation). **Per aggiornare il certificato CA modificando l’istanza database di database** 1. Scarica il nuovo SSL/TLS certificato come descritto in[Utilizzo SSL/TLS per crittografare una connessione a un'](UsingWithRDS.SSL.md). 1. Aggiornare le applicazioni per utilizzare il nuovo certificato SSL/TLS. I metodi per aggiornare le richieste di nuovi SSL/TLS certificati dipendono dalle applicazioni specifiche. Collabora con gli sviluppatori delle tue applicazioni per aggiornare i SSL/TLS certificati delle tue applicazioni. Per informazioni sul controllo delle SSL/TLS connessioni e sull'aggiornamento delle applicazioni per ogni motore di database, consultate i seguenti argomenti: + [Aggiornamento delle applicazioni per la connessione ai cluster database Aurora MySQL utilizzando nuovi certificati TLS](ssl-certificate-rotation-aurora-mysql.md) + [Aggiornamento delle applicazioni per la connessione ai cluster DB Aurora PostgreSQL utilizzando nuovi certificati SSL/TLS](ssl-certificate-rotation-aurora-postgresql.md) Per uno script di esempio che aggiorna un trust store per un sistema operativo Linux, consulta[Script di esempio per l'importazione di certificati nel tuo archivio di trust](#UsingWithRDS.SSL-certificate-rotation-sample-script). **Nota** Il bundle di certificati contiene certificati per la vecchia e la nuova CA, pertanto puoi aggiornare l'applicazione in modo sicuro e mantenere la connettività durante il periodo di transizione. Se si utilizza il AWS Database Migration Service per migrare un database verso un', si consiglia di utilizzare il pacchetto di certificati per garantire la connettività durante la migrazione. 1. **Modifica l'istanza DB per cambiare la CA da **rds-ca-2019** a 2048-g1. rds-ca-rsa** Per verificare se il database richiede un riavvio per aggiornare i certificati CA, utilizza il comando e seleziona il flag. [describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html)`SupportsCertificateRotationWithoutRestart` **Nota** Riavvia il cluster Babelfish dopo averlo modificato per aggiornare il certificato CA. **Importante** Se si verificano problemi di connettività dopo la scadenza del certificato, utilizzare l'opzione Applica immediatamente specificando **Apply immediately (Applica immediatamente)** nella console o specificando l'opzione `--apply-immediately` mediante AWS CLI. Per impostazione predefinita, questa operazione è pianificata per l'esecuzione durante la prossima finestra di manutenzione. Per impostare una sostituzione della CA per il cluster diversa dalla CA RDS predefinita, usa il comando CLI [modify-certificates](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-certificates.html). **** ------ #### [ Console ] 1. Accedi a Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Nel pannello di navigazione, scegli **Database**, quindi scegli l’istanza database che vuoi modificare. 1. Scegli **Modifica**. ![\[Modifica di un’istanza database\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/ssl-rotate-cert-modify-aurora.png) 1. Nella sezione **Connettività**, scegli **rds-ca-rsa2048-g1**. ![\[Scegliere certificato CA\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/ssl-rotate-cert-ca-rsa2048-g1.png) 1. Scegliere **Continue (Continua)** e controllare il riepilogo delle modifiche. 1. Per applicare immediatamente le modifiche, scegliere **Apply immediately (Applica immediatamente)**. 1. Nella pagina di conferma esaminare le modifiche. Se sono corrette, scegli **Modifica istanza database** per salvare le modifiche. **Importante** Quando si pianifica questa operazione, accertarsi di aver aggiornato in anticipo l'archivio di trust lato client. Oppure scegliere **Back (Indietro)** per cambiare le modifiche o **Cancel (Annulla)** per annullare le modifiche. ------ #### [ AWS CLI ] Specifica l’identificatore dell’istanza database e l’opzione `--ca-certificate-identifier`. Utilizza il parametro `--apply-immediately` per applicare immediatamente l’aggiornamento. Per impostazione predefinita, questa operazione è pianificata per l'esecuzione durante la prossima finestra di manutenzione. **Importante** Quando si pianifica questa operazione, accertarsi di aver aggiornato in anticipo l'archivio di trust lato client. **Example** L’esempio seguente modifica `mydbinstance` impostando il certificato CA su `rds-ca-rsa2048-g1`. Per Linux, macOS o Unix: ``` aws rds modify-db-instance \ --db-instance-identifier mydbinstance \ --ca-certificate-identifier rds-ca-rsa2048-g1 ``` Per Windows: ``` aws rds modify-db-instance ^ --db-instance-identifier mydbinstance ^ --ca-certificate-identifier rds-ca-rsa2048-g1 ``` Se l'istanza richiede il riavvio, puoi utilizzare il comando [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)CLI e specificare `--no-certificate-rotation-restart` l'opzione. ------ ## Aggiornamento del certificato CA mediante l'applicazione di manutenzione Completa la procedura seguente per aggiornare il certificato CA applicando la manutenzione. ------ #### [ Console ] **Per aggiornare il certificato CA applicando la manutenzione** 1. Accedi a Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Nel riquadro di navigazione, scegli **Aggiornamento certificato**. ![\[Opzione del pannello di navigazione di rotazione del certificato\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/ssl-rotate-cert-certupdate.png) Viene visualizzata la pagina **Database con aggiornamento certificati richiesto**. ![\[Aggiornamento del certificato CA per il database\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/ssl-rotate-cert-update-multiple.png) **Nota** Questa pagina mostra solo le istanze DB della versione corrente. Regione AWS Se disponi di database in più di uno Regione AWS, controlla questa pagina in ciascuno di essi Regione AWS per vedere tutte le istanze DB con vecchi certificati. SSL/TLS 1. Scegli l’istanza database da aggiornare. È possibile pianificare la rotazione dei certificati per la finestra di manutenzione successiva scegliendo **Pianifica**. Applica immediatamente la rotazione scegliendo **Applica ora**. **Importante** Se si verificano problemi di connettività dopo la scadenza del certificato, utilizza l'opzione **Applica ora**. 1. 1. Se scegli **Pianifica**, ti viene richiesto di confermare la rotazione dei certificati CA. Nella richiesta viene indicato anche la finestra pianificata per l'aggiornamento. ![\[Conferma della rotazione del certificato\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/ssl-rotate-cert-confirm-schedule.png) 1. Se scegli **Applica ora**, ti viene richiesto di confermare la rotazione dei certificati CA. ![\[Conferma della rotazione del certificato\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/ssl-rotate-cert-confirm-now.png) **Importante** Prima di pianificare la rotazione dei certificati CA sul database, aggiorna tutte le applicazioni client che utilizzano SSL/TLS e il certificato del server per la connessione. Questi aggiornamenti sono specifici per il motore DB. Dopo avere aggiornato queste applicazioni client, è possibile confermare la rotazione del certificato CA. Per continuare, scegliere la casella di controllo e quindi scegliere **Confirm (Conferma)**. 1. Ripeti i passaggi 3 e 4 per ogni istanza database da aggiornare. ------ ## Rotazione automatica dei certificati del server Se la CA root supporta la rotazione automatica dei certificati del server, RDS gestisce automaticamente la rotazione dei certificati del server di database. Per questa rotazione automatica, RDS utilizza la stessa CA root e pertanto non è necessario scaricare un nuovo bundle CA. Consulta [Autorità di certificazione](UsingWithRDS.SSL.md#UsingWithRDS.SSL.RegionCertificateAuthorities). La rotazione e la validità del certificato del server di database dipendono dal motore di database: + Se il motore di database supporta la rotazione senza riavvio, RDS esegue automaticamente la rotazione del certificato del server di database senza richiedere alcuna azione da parte dell'utente. RDS tenta di eseguire la rotazione del certificato del server di database nella finestra di manutenzione preferita in corrispondenza della semivita del certificato del server di database. Il nuovo certificato del server di database è valido per 12 mesi. + Se il tuo motore DB non supporta la rotazione senza riavvio, Amazon RDS rende visibile un'azione di manutenzione `server-certificate-rotation` in sospeso tramite Describe-pending-maintenance-actions API, al termine del periodo di dimezzamento del certificato o almeno 3 mesi prima della scadenza. Puoi applicare la rotazione utilizzando l'API. apply-pending-maintenance-action Il nuovo certificato del server di database è valido per 36 mesi. Usa il [ describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html)comando e controlla il `SupportsCertificateRotationWithoutRestart` flag per identificare se la versione del motore DB supporta la rotazione del certificato senza riavvio. Per ulteriori informazioni, consulta [Impostazione della CA per il database](UsingWithRDS.SSL.md#UsingWithRDS.SSL.RegionCertificateAuthorities.Selection). ## Script di esempio per l'importazione di certificati nel tuo archivio di trust Di seguito sono riportati script di shell di esempio che importano il bundle di certificati in un archivio di trust. Ogni script di shell di esempio utilizza keytool, che fa parte del Java Development Kit (JDK). Per informazioni sull'installazione di JDK, consulta la [Guida di installazione di JDK](https://docs.oracle.com/en/java/javase/17/install/overview-jdk-installation.html). ------ #### [ Linux ] Il seguente script è uno script di esempio shell che importa il bundle di certificati in un archivio di trust su un sistema operativo Linux. ``` mydir=tmp/certs if [ ! -e "${mydir}" ] then mkdir -p "${mydir}" fi truststore=${mydir}/rds-truststore.jks storepassword=changeit curl -sS "https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem"> ${mydir}/global-bundle.pem awk 'split_after == 1 {n++;split_after=0} /-----END CERTIFICATE-----/ {split_after=1}{print > "rds-ca-" n+1 ".pem"}' < ${mydir}/global-bundle.pem for CERT in rds-ca-*; do alias=$(openssl x509 -noout -text -in $CERT | perl -ne 'next unless /Subject:/; s/.*(CN=|CN = )//; print') echo "Importing $alias" keytool -import -file ${CERT} -alias "${alias}" -storepass ${storepassword} -keystore ${truststore} -noprompt rm $CERT done rm ${mydir}/global-bundle.pem echo "Trust store content is: " keytool -list -v -keystore "$truststore" -storepass ${storepassword} | grep Alias | cut -d " " -f3- | while read alias do expiry=`keytool -list -v -keystore "$truststore" -storepass ${storepassword} -alias "${alias}" | grep Valid | perl -ne 'if(/until: (.*?)\n/) { print "$1\n"; }'` echo " Certificate ${alias} expires in '$expiry'" done ``` ------ #### [ macOS ] Il seguente script è uno script di shell di esempio che importa il bundle di certificati in un archivio di trust su un sistema operativo Linux. ``` mydir=tmp/certs if [ ! -e "${mydir}" ] then mkdir -p "${mydir}" fi truststore=${mydir}/rds-truststore.jks storepassword=changeit curl -sS "https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem"> ${mydir}/global-bundle.pem split -p "-----BEGIN CERTIFICATE-----" ${mydir}/global-bundle.pem rds-ca- for CERT in rds-ca-*; do alias=$(openssl x509 -noout -text -in $CERT | perl -ne 'next unless /Subject:/; s/.*(CN=|CN = )//; print') echo "Importing $alias" keytool -import -file ${CERT} -alias "${alias}" -storepass ${storepassword} -keystore ${truststore} -noprompt rm $CERT done rm ${mydir}/global-bundle.pem echo "Trust store content is: " keytool -list -v -keystore "$truststore" -storepass ${storepassword} | grep Alias | cut -d " " -f3- | while read alias do expiry=`keytool -list -v -keystore "$truststore" -storepass ${storepassword} -alias "${alias}" | grep Valid | perl -ne 'if(/until: (.*?)\n/) { print "$1\n"; }'` echo " Certificate ${alias} expires in '$expiry'" done ``` ------ Per ulteriori informazioni sulle best practice sull’utilizzo di SSL con Amazon RDS, consulta [Best practices for successful SSL connections to Amazon RDS for Oracle](https://aws.amazon.com/blogs/database/best-practices-for-successful-ssl-connections-to-amazon-rds-for-oracle/).