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à.
# Sicurezza in
La sicurezza del cloud AWS è la massima priorità. In qualità di AWS cliente, puoi beneficiare di un data center e di un'architettura di rete progettati per soddisfare i requisiti delle organizzazioni più sensibili alla sicurezza.
La sicurezza è una responsabilità condivisa tra AWS te e te. Il [modello di responsabilità condivisa](https://aws.amazon.com/compliance/shared-responsibility-model/) descrive questo come sicurezza *del* cloud e sicurezza *nel* cloud:
+ **Sicurezza del cloud**: AWS è responsabile della protezione dell'infrastruttura che gestisce AWS i servizi nel AWS cloud. AWS ti fornisce anche servizi che puoi utilizzare in modo sicuro. I revisori di terze parti testano e verificano regolarmente l'efficacia della sicurezza come parte dei [programmi di conformitàAWS](https://aws.amazon.com/compliance/programs/). Per ulteriori informazioni sui programmi di conformità che si applicano ad Amazon Aurora (Aurora), consulta [Servizi AWS coperti dal programma di compliance](https://aws.amazon.com/compliance/services-in-scope/).
+ **Sicurezza nel cloud**: la tua responsabilità è determinata dal AWS servizio che utilizzi. L'utente è anche responsabile per altri fattori, tra cui la riservatezza dei dati, i requisiti dell'azienda, nonché le leggi e le normative applicabili.
La presente documentazione aiuta a comprendere come applicare il modello di responsabilità condivisa quando si utilizza Amazon Aurora. I seguenti argomenti illustrano come configurare Amazon Aurora per soddisfare gli obiettivi di sicurezza e conformità. Scopri anche come utilizzare altri AWS servizi che ti aiutano a monitorare e proteggere le tue risorse Amazon Aurora.
È possibile gestire l’accesso alle risorse Amazon Aurora e ai database in un cluster di database. Il metodo utilizzato per gestire l’accesso dipende dal tipo di attività che l’utente deve eseguire con Amazon Aurora:
+ Esegui il cluster di database in un cloud privato virtuale (VPC) basato sul servizio Amazon VPC per il massimo controllo possibile dell’accesso alla rete. Per ulteriori informazioni sulla creazione di un cluster di database in un VPC, consulta [VPC Amazon e Amazon Aurora](USER_VPC.md) .
+ Utilizza le policy AWS Identity and Access Management (IAM) per assegnare autorizzazioni che determinano chi è autorizzato a gestire le risorse Amazon . Ad esempio, è possibile utilizzare IAM per determinare chi è autorizzato a creare, descrivere, modificare ed eliminare cluster di database, applicare tag alle risorse oppure modificare i gruppi di sicurezza.
Per esempi di policy IAM, consulta [Esempi di policy di Amazon Aurora basate su identità](security_iam_id-based-policy-examples.md).
+ Utilizzare i gruppi di sicurezza per controllare quali indirizzi IP o istanze Amazon EC2 possono collegarsi ai database su un cluster di database. Quando si crea per la prima volta un cluster di database, il firewall impedisce qualsiasi accesso al database tranne che attraverso le regole specificate da un gruppo di sicurezza associato.
+ Utilizzare le connessioni Secure Socket Layer (SSL) o Transport Layer Security (TLS) con cluster di database che eseguono Aurora MySQL o Aurora PostgreSQL. Per ulteriori informazioni sull'utilizzo SSL/TLS con un cluster DB, vedere[Utilizzo SSL/TLS per crittografare una connessione a un'](UsingWithRDS.SSL.md).
+ Utilizzare la crittografia Amazon Aurora per proteggere i cluster di database e gli snapshot a riposo. La crittografia Amazon Aurora utilizza l’algoritmo di crittografia AES-256 standard del settore per crittografare i dati sul server che ospita il cluster di database. Per ulteriori informazioni, consulta [Crittografia delle risorse Amazon Aurora](Overview.Encryption.md).
+ Utilizzare le funzionalità di sicurezza del motore di database per controllare chi può accedere ai database su un cluster di database. Queste funzionalità funzionano come se il database si trovasse sulla rete locale.
Per informazioni sulla sicurezza con Aurora MySQL, consulta [Sicurezza con Amazon Aurora MySQL](AuroraMySQL.Security.md). Per informazioni sulla sicurezza con Aurora PostgreSQL, consulta [Sicurezza con Amazon Aurora PostgreSQL](AuroraPostgreSQL.Security.md).
Aurora fa parte del servizio di database gestito Amazon Relational Database Service (Amazon RDS). Amazon RDS è un servizio Web che semplifica la configurazione, l'uso e il dimensionamento dei database relazionali nel cloud. Se è la prima volta che utilizzi Amazon RDS, consulta la [https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html).
Aurora include un sottosistema di storage ad alte prestazioni. I relativi motori di database compatibili con MySQL e PostgreSQL sono personalizzati per beneficiare dello storage distribuito e rapido. Aurora inoltre automatizza ed esegue la standardizzazione del clustering e della replica di database, ovvero due aspetti in genere tra i più impegnativi nell'ambito della configurazione e dell'amministrazione dei database.
Sia per Amazon RDS che per Aurora, puoi accedere all'API RDS a livello di codice e puoi utilizzarla per accedere all'API RDS in modo AWS CLI interattivo. Alcune operazioni API RDS e comandi AWS CLI si applicano sia a Amazon RDS che ad Aurora, mentre altri si applicano a uno o all'altro. Per informazioni sulle operazioni API RDS, consulta [Documentazione di riferimento dell'API Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/Welcome.html). Per ulteriori informazioni su AWS CLI, consulta il [AWS Command Line Interface riferimento per Amazon RDS.](https://docs.aws.amazon.com/cli/latest/reference/rds/index.html)
**Nota**
Devi configurare la sicurezza solo per i tuoi casi d'uso. Non devi configurare l'accesso di sicurezza per i processi gestiti da Amazon Aurora. Sono inclusi la creazione di backup, il failover automatico e altri processi.
Per ulteriori informazioni sulla gestione dell’accesso alle risorse Amazon Aurora e ai database su un cluster di database, consulta i seguenti argomenti.
**Topics**
+ [Autenticazione del database con](database-authentication.md)
+ [Gestione delle password con Amazon Aurora e Gestione dei segreti AWS](rds-secrets-manager.md)
+ [Protezione dei dati in Amazon RDS](DataDurability.md)
+ [Gestione accessi e identità per Amazon Aurora](UsingWithRDS.IAM.md)
+ [Registrazione e monitoraggio in](Overview.LoggingAndMonitoring.md)
+ [Convalida della conformità per Amazon Aurora](RDS-compliance.md)
+ [Resilienza in Amazon Aurora](disaster-recovery-resiliency.md)
+ [Sicurezza dell'infrastruttura in Amazon Aurora](infrastructure-security.md)
+ [API Amazon RDS ed endpoint VPC dell'interfaccia (AWS PrivateLink)](vpc-interface-endpoints.md)
+ [Best practice di sicurezza per](CHAP_BestPractices.Security.md)
+ [Controllo dell'accesso con i gruppi di sicurezza](Overview.RDSSecurityGroups.md)
+ [Privilegi dell'account utente master](UsingWithRDS.MasterAccounts.md)
+ [Utilizzo di ruoli collegati ai servizi per Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md)
+ [VPC Amazon e Amazon Aurora](USER_VPC.md)
# Autenticazione del database con
Amazon Aurora supporta diversi modi per autenticare gli utenti del database.
L'autenticazione con password è disponibile per impostazione predefinita per tutti i cluster database. Per Aurora MySQL e Aurora PostgreSQL, puoi aggiungere sia l'autenticazione del database IAM che l'autenticazione Kerberos per lo stesso cluster di database.
L'autenticazione con password, Kerberos e del database IAM utilizzano diversi metodi di autenticazione nel database. Pertanto, un utente specifico può accedere a un database utilizzando un solo metodo di autenticazione.
Per PostgreSQL, utilizza solo una delle seguenti impostazioni di ruolo per un utente di un database specifico:
+ Per utilizzare l'autenticazione del database IAM, assegna all'utente il ruolo `rds_iam`.
+ Per utilizzare l'autenticazione Kerberos, assegna all'utente il ruolo `rds_ad`.
+ Per utilizzare l'autenticazione con password, non assegnare i ruoli `rds_iam` o `rds_ad`.
Non assegnare entrambi i ruoli `rds_iam` e `rds_ad` a un utente di un database PostgreSQL direttamente o indirettamente mediante l'accesso di concessione nidificato. Se all'utente master, viene aggiunto il ruolo `rds_iam`, l'autenticazione IAM ha la precedenza sull'autenticazione con password, quindi l'utente master dovrà accedere come utente IAM.
**Importante**
Si consiglia di non utilizzare l'utente master direttamente nelle applicazioni. Rispetta piuttosto la best practice di utilizzare un utente del database creato con i privilegi minimi richiesti per l'applicazione.
**Topics**
+ [Autenticazione password](#password-authentication)
+ [Autenticazione del database IAM](#iam-database-authentication)
+ [Autenticazione Kerberos](#kerberos-authentication)
## Autenticazione password
Con *autenticazione con password* il database esegue tutta l'amministrazione degli account utente. È possibile creare utenti con istruzioni SQL come `CREATE USER`, con la clausola appropriata richiesta dal motore DB per specificare le password. Ad esempio, in MySQL l'istruzione `CREATE USER` *name* `IDENTIFIED BY` *password* è, mentre in PostgreSQL l'istruzione è. `CREATE USER` *name* `WITH PASSWORD` *password*
Con l'autenticazione con password, il database controlla e autentica gli account utente. Se un motore DB dispone di potenti funzionalità di gestione delle password, può migliorare la sicurezza. L'autenticazione del database potrebbe essere più semplice da amministrare utilizzando l'autenticazione con password quando si dispone di comunità di utenti di piccole dimensioni. Poiché in questo caso vengono generate password con testo non crittografato, l'integrazione con può migliorare la sicurezza. Gestione dei segreti AWS
Per informazioni sull’utilizzo di Secrets Manager con Amazon Aurora, consulta [Creazione di un segreto di base](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_create-basic-secret.html) e [Rotazione dei segreti per database Amazon RDS supportati](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets-rds.html) nella *Guida per l’utente di Gestione dei segreti AWS *. Per informazioni sul recupero a livello di programmazione dei segreti nelle applicazioni personalizzate, consulta [Recupero del valore segreto](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_retrieve-secret.html) nella *Guida per l'utente di Gestione dei segreti AWS *.
## Autenticazione del database IAM
Puoi eseguire l’autenticazione nel cluster di database tramite l’autenticazione del database AWS Identity and Access Management (IAM). Con questo metodo di autenticazione, non devi utilizzare una password quando esegui la connessione al cluster di database. Utilizzi invece un token di autenticazione.
Per ulteriori informazioni sull’autenticazione del database IAM, incluse le informazioni sulla disponibilità per specifici motori di database, consulta [Autenticazione del database IAM ](UsingWithRDS.IAMDBAuth.md).
## Autenticazione Kerberos
Amazon Aurora supporta l’autenticazione esterna degli utenti dei database con Kerberos e Microsoft Active Directory. Kerberos è un protocollo di autenticazione di rete che utilizza ticket e crittografia a chiave simmetrica eliminando la necessità di scambiare password sulla rete. È stato integrato in Microsoft Active Directory ed è progettato per autenticare gli utenti su risorse di rete, ad esempio i database.
Il supporto Amazon Aurora per Kerberos e Active Directory offre i vantaggi del Single Sign-On e dell’autenticazione centralizzata degli utenti dei database. Puoi mantenere le tue credenziali utente in Active Directory. Active Directory fornisce una posizione centralizzata per archiviare e gestire le credenziali per più cluster di database.
Per utilizzare le credenziali dell'Active Directory autogestito, è necessario impostare una relazione di trust con Directory Service Microsoft Active Directory a cui è unito il cluster DB dell' DB.
Aurora PostgreSQL e Aurora MySQL supportano relazioni di trust tra foreste unidirezionali e bidirezionali con autenticazione a livello di foresta o autenticazione selettiva.
In alcuni scenari, è possibile configurare l’autenticazione Kerberos tramite una relazione di trust esterna. Ciò richiede che Active Directory autogestito disponga di impostazioni aggiuntive. Questo include, ad esempio, [Kerberos Forest Search Order](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/kfso-not-work-in-external-trust-event-is-17).
Aurora supporta l'autenticazione Kerberos per i cluster di database Aurora MySQL e Aurora PostgreSQL. Per ulteriori informazioni, consulta [Utilizzo dell'autenticazione Kerberos per Aurora MySQL](aurora-mysql-kerberos.md) e [Utilizzo di Autenticazione Kerberos con Aurora PostgreSQL](postgresql-kerberos.md).
# Gestione delle password con Amazon Aurora e Gestione dei segreti AWS
Amazon Aurora si integra con Secrets Manager per gestire le password degli utenti master per .
**Topics**
+ [Disponibilità di regioni e versioni](#rds-secrets-manager-availability)
+ [Limitazioni per l'integrazione di Secrets Manager con Amazon Aurora](#rds-secrets-manager-limitations)
+ [Panoramica della gestione delle password degli utenti principali con Gestione dei segreti AWS](#rds-secrets-manager-overview)
+ [Vantaggi della gestione delle password degli utenti master con Secrets Manager](#rds-secrets-manager-benefits)
+ [Autorizzazioni necessarie per l'integrazione di Secrets Manager](#rds-secrets-manager-permissions)
+ [Applicazione della gestione della password dell'utente principale in Gestione dei segreti AWS](#rds-secrets-manager-auth)
+ [Gestione della password dell'utente principale per un cluster DB con Secrets Manager](#rds-secrets-manager-db-cluster)
+ [Ruotare la password segreta dell'utente principale per un cluster DB](#rds-secrets-manager-rotate-db-cluster)
+ [Visualizzazione dei dettagli su un segreto per un cluster DB](#rds-secrets-manager-view-db-cluster)
## Disponibilità di regioni e versioni
Il supporto varia a seconda delle versioni specifiche di ciascun motore di database e a seconda delle Regioni AWS. Per ulteriori informazioni sulla disponibilità di versioni e regioni con l'integrazione di Secrets Manager con Amazon Aurora, consulta [Regioni e motori di database Aurora supportati per l’integrazione di Secrets Manager](Concepts.Aurora_Fea_Regions_DB-eng.Feature.SecretsManager.md).
## Limitazioni per l'integrazione di Secrets Manager con Amazon Aurora
La gestione delle password degli utenti master con Secrets Manager non è supportata per le seguenti funzionalità:
+ Implementazioni Amazon RDS Blue/Green
+ Cluster database che fanno parte di un database globale Aurora
+ Cluster di database Aurora Serverless v1
+ Repliche di lettura tra regioni diverse
+ Replica esterna di log binari
## Panoramica della gestione delle password degli utenti principali con Gestione dei segreti AWS
Con Gestione dei segreti AWS, puoi sostituire le credenziali codificate nel codice, incluse le password del database, con una chiamata API a Secrets Manager per recuperare il segreto a livello di codice. Per ulteriori informazioni su Secrets Manager, consultare la [Guida per l'utente di Gestione dei segreti AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/).
Quando memorizzi i segreti del database in Secrets Manager, ti vengono Account AWS addebitati dei costi. Per informazioni sui prezzi, consulta [Gestione dei segreti AWS Pricing](https://aws.amazon.com/secrets-manager/pricing).
Puoi specificare che Aurora gestisca la password dell'utente master in Secrets Manager per un database Amazon Aurora quando esegui una delle seguenti operazioni:
+ Creazione di un cluster di database
+ Modificare un cluster di database
+ Ripristino di un cluster di database da Amazon S3 (solo Aurora MySQL)
Quando specifichi che Aurora gestisce la password dell'utente master in Secrets Manager, Aurora genera la password e la memorizza in Secrets Manager. Puoi interagire direttamente con il segreto per recuperare le credenziali dell'utente master. Puoi anche specificare una chiave gestita dal cliente per crittografare il segreto o utilizzare la chiave KMS fornita da Secrets Manager.
Aurora gestisce le impostazioni del segreto e lo ruota ogni sette giorni per impostazione predefinita. È possibile modificare alcune impostazioni, ad esempio il programma di rotazione. Se si elimina un cluster database che gestisce un segreto in Secrets Manager, vengono eliminati anche il segreto e i metadati associati.
Per connetterti a con le credenziali in un segreto, puoi recuperare il segreto da Secrets Manager. Per ulteriori informazioni, consulta [Recupera segreti da Gestione dei segreti AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html) e [Connettiti a un database SQL con credenziali in un Gestione dei segreti AWS segreto nella Guida](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets_jdbc.html) per l'*Gestione dei segreti AWS utente*.
## Vantaggi della gestione delle password degli utenti master con Secrets Manager
La gestione delle password degli utenti master Aurora con Secrets Manager offre i seguenti vantaggi:
+ Aurora genera automaticamente le credenziali del database.
+ Aurora archivia e gestisce automaticamente le credenziali del database in. Gestione dei segreti AWS
+ Aurora ruota regolarmente le credenziali del database, senza richiedere modifiche all'applicazione.
+ Secrets Manager protegge le credenziali del database dall'accesso umano e dalla visualizzazione in testo normale.
+ Secrets Manager consente il recupero delle credenziali del database nei segreti per le connessioni al database.
+ Secrets Manager consente un controllo dettagliato dell'accesso alle credenziali del database nei segreti utilizzando IAM.
+ Facoltativamente, puoi separare la crittografia del database dalla crittografia delle credenziali con chiavi KMS diverse.
+ Puoi eliminare la gestione manuale e la rotazione delle credenziali del database.
+ Puoi monitorare facilmente le credenziali del database con AWS CloudTrail Amazon CloudWatch.
Per ulteriori informazioni sui vantaggi di Secrets Manager, consulta la [Guida per l'utente di Gestione dei segreti AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/).
## Autorizzazioni necessarie per l'integrazione di Secrets Manager
Gli utenti devono disporre delle autorizzazioni necessarie per eseguire le operazioni relative all'integrazione di Secrets Manager. Puoi creare le policy IAM che concedono l'autorizzazione per eseguire operazioni API specifiche sulle risorse indicate necessarie. Puoi quindi collegare tali policy ai ruoli o ai set di autorizzazioni IAM che richiedono le autorizzazioni. Per ulteriori informazioni, consulta [Gestione accessi e identità per Amazon Aurora](UsingWithRDS.IAM.md).
Per le operazioni di creazione, modifica o ripristino, l'utente che specifica che Aurora gestisce la password dell'utente master in Secrets Manager deve disporre delle autorizzazioni per eseguire le seguenti operazioni:
+ `kms:DescribeKey`
+ `secretsmanager:CreateSecret`
+ `secretsmanager:TagResource`
L’autorizzazione `kms:DescribeKey` è necessaria per accedere alla chiave gestita dal cliente per `MasterUserSecretKmsKeyId` e per descrivere `aws/secretsmanager`.
Per le operazioni di creazione, modifica o ripristino, l'utente che specifica la chiave gestita dal cliente per crittografare il segreto in Secrets Manager deve disporre delle autorizzazioni per eseguire le seguenti operazioni:
+ `kms:Decrypt`
+ `kms:GenerateDataKey`
+ `kms:CreateGrant`
Per le operazioni di modifica, l'utente che ruota la password dell'utente master in Secrets Manager deve disporre delle autorizzazioni per eseguire la seguente operazione:
+ `secretsmanager:RotateSecret`
## Applicazione della gestione della password dell'utente principale in Gestione dei segreti AWS
È possibile utilizzare le chiavi di condizione IAM per implementare la gestione da parte di Aurora della password dell'utente master in Gestione dei segreti AWS. La seguente policy non consente agli utenti di creare o ripristinare istanze database a meno che la password dell’utente master non sia gestita da Aurora in Secrets Manager.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": ["rds:CreateDBInstance", "rds:CreateDBCluster", "rds:RestoreDBInstanceFromS3", "rds:RestoreDBClusterFromS3"],
"Resource": "*",
"Condition": {
"Bool": {
"rds:ManageMasterUserPassword": false
}
}
}
]
}
```
------
**Nota**
Questa politica impone la gestione delle password al momento della creazione. Gestione dei segreti AWS Tuttavia, puoi comunque disabilitare l'integrazione di Secrets Manager e impostare manualmente una password master modificando il cluster.
Per evitare questa procedura, includi `rds:ModifyDBInstance`, `rds:ModifyDBCluster` nel blocco operazione della policy. Tieni presente che in tal modo impedisci all'utente di applicare ulteriori modifiche ai cluster esistenti in cui non è abilitata l'integrazione di Secrets Manager.
Per ulteriori informazioni sull'utilizzo delle chiavi di condizione nelle policy IAM, consulta [Chiavi di condizione delle policy per Aurora](security_iam_service-with-iam.md#UsingWithRDS.IAM.Conditions) e [Policy di esempio: Utilizzo di chiavi di condizione](UsingWithRDS.IAM.Conditions.Examples.md).
## Gestione della password dell'utente principale per un cluster DB con Secrets Manager
È possibile configurare la gestione Aurora della password dell'utente master in Secrets Manager eseguendo le seguenti operazioni:
+ [Creazione di un cluster database Amazon Aurora](Aurora.CreateInstance.md)
+ [Modifica di un cluster database Amazon Aurora](Aurora.Modifying.md)
+ [La migrazione di dati da un database MySQL esterno a un cluster database Amazon Aurora MySQL](AuroraMySQL.Migrating.ExtMySQL.md)
È possibile utilizzare la console RDS AWS CLI, o l'API RDS per eseguire queste azioni.
### Console
Segui le istruzioni per creare o modificare un cluster database con la console RDS:
+ [Creazione di un cluster di database](Aurora.CreateInstance.md#Aurora.CreateInstance.Creating)
+ [Modifica di un'istanza database in un cluster database](Aurora.Modifying.md#Aurora.Modifying.Instance)
Nella console RDS puoi modificare qualsiasi istanza database per specificare le impostazioni di gestione della password dell'utente master per l'intero cluster database.
+ [Ripristino di un cluster di database Amazon Aurora MySQL da un bucket Amazon S3](AuroraMySQL.Migrating.ExtMySQL.S3.md#AuroraMySQL.Migrating.ExtMySQL.S3.Restore)
Quando usi la console RDS per eseguire una di queste operazioni, è possibile specificare che la password dell'utente master sia gestita da Aurora in Secrets Manager. A tale scopo, durante la creazione o il ripristino di un cluster di database, seleziona **Gestisci le credenziali master in Gestione dei segreti AWS** in **Impostazioni credenziali**. Quando modifichi un cluster database, seleziona **Manage master credentials in Gestione dei segreti AWS** (Gestione credenziali master in Gestione dei segreti AWS) in **Settings** (Impostazioni).
L'immagine seguente è un esempio di impostazione **Manage master credentials in Gestione dei segreti AWS** (Gestione credenziali master in Gestione dei segreti AWS) durante la creazione o il ripristino di un cluster database.
![\[Gestisci le credenziali principali in Gestione dei segreti AWS\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/secrets-manager-credential-settings.png)
Quando selezioni questa opzione, Aurora genera la password dell'utente master e la gestisce per tutto il suo ciclo di vita in Secrets Manager.
![\[Gestisci le credenziali principali in modalità selezionata Gestione dei segreti AWS\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/secrets-manager-integration-create.png)
Puoi scegliere di crittografare il segreto con una chiave KMS fornita da Secrets Manager o con una chiave gestita dal cliente creata da te. Dopo che Aurora gestisce le credenziali del database per un cluster database, non puoi modificare la chiave KMS utilizzata per crittografare il segreto.
Puoi scegliere altre impostazioni per soddisfare le tue esigenze.
Per ulteriori informazioni sulle impostazioni disponibili per la creazione di un cluster database, consulta [Impostazioni per cluster di database Aurora](Aurora.CreateInstance.md#Aurora.CreateInstance.Settings). Per ulteriori informazioni sulle impostazioni disponibili per la modifica di un cluster database, consulta [Impostazioni per Amazon Aurora](Aurora.Modifying.md#Aurora.Modifying.Settings).
### AWS CLI
Per specificare che Aurora gestisce la password dell'utente master in Secrets Manager, imposta l'opzione `--manage-master-user-password` in uno dei seguenti comandi:
+ [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html)
+ [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)
+ [restore-db-cluster-from-s3](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-from-s3.html)
Quando si specifica l'opzione `--manage-master-user-password` in questi comandi, Aurora genera la password dell'utente master e la gestisce per tutto il suo ciclo di vita in Secrets Manager.
Per crittografare il segreto, è possibile specificare una chiave gestita dal cliente o utilizzare la chiave KMS predefinita fornita da Secrets Manager. Per specificare la chiave gestita dal cliente usa l'opzione `--master-user-secret-kms-key-id`. L'identificatore della chiave AWS KMS è l'ARN della chiave, l'ID chiave, l'alias ARN o il nome alias per la chiave KMS. Per utilizzare una chiave KMS in un'altra chiave Account AWS, specifica la chiave ARN o l'alias ARN. Dopo che Aurora gestisce le credenziali del database per un cluster database, non puoi modificare la chiave KMS utilizzata per crittografare il segreto.
Puoi scegliere altre impostazioni per soddisfare le tue esigenze.
Per ulteriori informazioni sulle impostazioni disponibili per la creazione di un cluster database, consulta [Impostazioni per cluster di database Aurora](Aurora.CreateInstance.md#Aurora.CreateInstance.Settings). Per ulteriori informazioni sulle impostazioni disponibili per la modifica di un cluster database, consulta [Impostazioni per Amazon Aurora](Aurora.Modifying.md#Aurora.Modifying.Settings).
Questo esempio crea un cluster database e specifica che Aurora gestisce la password in Secrets Manager. Il segreto viene crittografato utilizzando la chiave KMS fornita da Secrets Manager.
**Example**
Per Linux, macOS o Unix:
```
1. aws rds create-db-cluster \
2. --db-cluster-identifier sample-cluster \
3. --engine aurora-mysql \
4. --engine-version 8.0 \
5. --master-username admin \
6. --manage-master-user-password
```
Per Windows:
```
1. aws rds create-db-cluster ^
2. --db-cluster-identifier sample-cluster ^
3. --engine aurora-mysql ^
4. --engine-version 8.0 ^
5. --master-username admin ^
6. --manage-master-user-password
```
### API RDS
Per specificare che Aurora gestisce la password dell'utente master in Secrets Manager, imposta il parametro `ManageMasterUserPassword` su `true` in una delle seguenti operazioni:
+ [CreaDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html)
+ [ModificaDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)
+ [Ripristina da S3 DBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromS3.html)
Quando imposti il parametro `ManageMasterUserPassword` su `true` in una di queste operazioni, Aurora genera la password dell'utente master e la gestisce per tutto il suo ciclo di vita in Secrets Manager.
Per crittografare il segreto, è possibile specificare una chiave gestita dal cliente o utilizzare la chiave KMS predefinita fornita da Secrets Manager. Per specificare la chiave gestita dal cliente usa il parametro `MasterUserSecretKmsKeyId`. L'identificatore della chiave AWS KMS è l'ARN della chiave, l'ID chiave, l'alias ARN o il nome alias per la chiave KMS. Per usate una chiave KMS in un Account AWS diverso, specifica l'ARN della chiave o dell'alias. Dopo che Aurora gestisce le credenziali del database per un cluster database, non puoi modificare la chiave KMS utilizzata per crittografare il segreto.
## Ruotare la password segreta dell'utente principale per un cluster DB
Quando Aurora ruota il segreto della password di un utente master, Secrets Manager genera una nuova versione del segreto esistente. La nuova versione del segreto contiene la nuova password dell'utente master. Amazon Aurora modifica la password dell'utente master per il cluster database in modo che corrisponda alla password per la nuova versione del segreto.
Puoi ruotare un segreto immediatamente invece di aspettare la rotazione programmata. Per ruotare il segreto della password dell'utente master in Secrets Manager, modifica il cluster database . Per informazioni sulla modifica di un cluster database, consulta [Modifica di un cluster database Amazon Aurora](Aurora.Modifying.md).
È possibile ruotare immediatamente la password segreta di un utente principale con la console RDS AWS CLI, la o l'API RDS. La nuova password è sempre lunga 28 caratteri e contiene almeno un carattere maiuscolo e minuscolo, un numero e un carattere di punteggiatura.
### Console
Per ruotare il segreto della password dell'utente master utilizzando la console RDS, modifica il cluster database e seleziona **Rotate secret immediately** (Ruota il segreto immediatamente) in **Settings** (Impostazioni).
![\[Rotazione immediata del segreto della password dell'utente master\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/secrets-manager-integration-rotate-aurora.png)
Per modificare un cluster database con la console RDS segui le istruzioni presenti in [Modifica del cluster di database tramite la console, la CLI e l'API](Aurora.Modifying.md#Aurora.Modifying.Cluster). È necessario scegliere **Apply immediately** (Applica immediatamente) nella pagina di conferma.
### AWS CLI
Per ruotare la password segreta di un utente principale utilizzando il AWS CLI, usa il [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)comando e specifica l'opzione. `--rotate-master-user-password` È necessario specificare l'opzione `--apply-immediately` quando si ruota la password master.
Questo esempio ruota il segreto della password dell'utente master.
**Example**
Per Linux, macOS o Unix:
```
1. aws rds modify-db-cluster \
2. --db-cluster-identifier mydbcluster \
3. --rotate-master-user-password \
4. --apply-immediately
```
Per Windows:
```
1. aws rds modify-db-cluster ^
2. --db-cluster-identifier mydbcluster ^
3. --rotate-master-user-password ^
4. --apply-immediately
```
### API RDS
È possibile ruotare la password segreta di un utente principale utilizzando l'DBClusteroperazione [Modifica](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) e impostando il `RotateMasterUserPassword` parametro su. `true` È necessario impostare il parametro `ApplyImmediately` su `true` quando si ruota la password master.
## Visualizzazione dei dettagli su un segreto per un cluster DB
Puoi recuperare i tuoi segreti usando la console ([https://console.aws.amazon.com/secretsmanager/](https://console.aws.amazon.com/secretsmanager/)) o il comando AWS CLI ([get-secret-value](https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/get-secret-value.html)Secrets Manager).
Puoi trovare l'Amazon Resource Name (ARN) di un segreto gestito da Aurora in Secrets Manager con la console RDS AWS CLI, l'o l'API RDS.
### Console
**Per visualizzare i dettagli su un segreto gestito da Aurora in Secrets Manager**
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, seleziona **Database**.
1. Scegli il nome del cluster database per visualizzarne i dettagli.
1. Scegli la scheda **Configurazione**.
In **Master Credentials ARN** (ARN credenziali master), puoi visualizzare l'ARN del segreto.
![\[Visualizza i dettagli di un segreto gestito da Aurora in Secrets Manager\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/secrets-manager-integration-view-cluster.png)
Puoi selezionare il collegamento **Manage in Secrets Manager** (Gestisci in Secrets Manager) per visualizzare e gestire il segreto nella console di Secrets Manager.
### AWS CLI
È possibile utilizzare il AWS CLI [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html)comando RDS per trovare le seguenti informazioni su un segreto gestito da in Secrets Manager:
+ `SecretArn`: l'ARN del segreto
+ `SecretStatus`: lo stato del segreto
I valori possibili per lo stato sono:
+ `creating`: il segreto è in fase di creazione.
+ `active`: il segreto è disponibile per l'uso normale e la rotazione.
+ `rotating`: il segreto è in fase di rotazione.
+ `impaired`: il segreto può essere utilizzato per accedere alle credenziali del database, ma non può essere ruotato. Un segreto può avere questo stato se, ad esempio, le autorizzazioni vengono modificate in modo che RDS non può più accedere al segreto o alla chiave KMS del segreto.
Quando un segreto ha questo stato, puoi correggere la condizione che lo ha causato. Se correggi la condizione che ha causato lo stato, lo stato rimane `impaired` fino alla rotazione successiva. In alternativa, è possibile modificare il cluster database per disattivare la gestione automatica delle credenziali del database e quindi modificare nuovamente il cluster database per attivare la gestione automatica delle credenziali del database. Per modificare il cluster DB, utilizzare l'`--manage-master-user-password`opzione nel comando. [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)
+ `KmsKeyId`: l'ARN della chiave KMS utilizzata per crittografare il segreto
Specifica l'opzione `--db-cluster-identifier` per mostrare l'output per un cluster database specifico. Questo esempio mostra l'output di un segreto utilizzato da un cluster database.
**Example**
```
1. aws rds describe-db-clusters --db-cluster-identifier mydbcluster
```
L'esempio seguente mostra l'output di un segreto:
```
"MasterUserSecret": {
"SecretArn": "arn:aws:secretsmanager:eu-west-1:123456789012:secret:rds!cluster-033d7456-2c96-450d-9d48-f5de3025e51c-xmJRDx",
"SecretStatus": "active",
"KmsKeyId": "arn:aws:kms:eu-west-1:123456789012:key/0987dcba-09fe-87dc-65ba-ab0987654321"
}
```
Quando si dispone dell'ARN segreto, è possibile visualizzare i dettagli sul segreto utilizzando il comando [get-secret-value](https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/get-secret-value.html)Secrets Manager CLI.
Questo esempio mostra i dettagli del segreto nell'output di esempio precedente.
**Example**
Per Linux, macOS o Unix:
```
aws secretsmanager get-secret-value \
--secret-id 'arn:aws:secretsmanager:eu-west-1:123456789012:secret:rds!cluster-033d7456-2c96-450d-9d48-f5de3025e51c-xmJRDx'
```
Per Windows:
```
aws secretsmanager get-secret-value ^
--secret-id 'arn:aws:secretsmanager:eu-west-1:123456789012:secret:rds!cluster-033d7456-2c96-450d-9d48-f5de3025e51c-xmJRDx'
```
### API RDS
È possibile visualizzare l'ARN, lo stato e la chiave KMS per un segreto gestito da RDS in Secrets Manager utilizzando l'operazione DBClusters Descrivi RDS e `DBClusterIdentifier` impostando [il](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html) parametro su un identificatore di cluster DB. I dettagli del segreto sono inclusi nell'output.
Quando si dispone dell'ARN segreto, è possibile visualizzare i dettagli sul segreto utilizzando l'operazione [GetSecretValue](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html)Secrets Manager.
# Protezione dei dati in Amazon RDS
Il [modello di responsabilità condivisa](https://aws.amazon.com/compliance/shared-responsibility-model/) di AWS si applica alla protezione dei dati in Amazon Relational Database Service. Come descritto in questo modello, AWS è responsabile della protezione dell'infrastruttura globale che esegue tutto l'Cloud AWS. L'utente è responsabile del controllo dei contenuti ospitati su questa infrastruttura. L'utente è inoltre responsabile della configurazione della protezione e delle attività di gestione per i Servizi AWS utilizzati. Per ulteriori informazioni sulla privacy dei dati, vedi le [Domande frequenti sulla privacy dei dati](https://aws.amazon.com/compliance/data-privacy-faq/). Per informazioni sulla protezione dei dati in Europa, consulta il post del blog relativo al [Modello di responsabilità condivisa AWSe GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) nel *Blog sulla sicurezza AWS*.
Per garantire la protezione dei dati, ti suggeriamo di proteggere le credenziali Account AWSe di configurare i singoli utenti con AWS IAM Identity Centero AWS Identity and Access Management(IAM). In tal modo, a ogni utente verranno assegnate solo le autorizzazioni necessarie per svolgere i suoi compiti. Ti suggeriamo, inoltre, di proteggere i dati nei seguenti modi:
+ Utilizza l'autenticazione a più fattori (MFA) con ogni account.
+ Utilizza SSL/TLS per comunicare con le risorse AWS. È richiesto TLS 1.2 ed è consigliato TLS 1.3.
+ Configura l'API e la registrazione delle attività degli utenti con AWS CloudTrail. Per informazioni sull'utilizzo dei percorsi CloudTrail per acquisire le attività AWS, consulta [Utilizzo dei percorsi CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) nella *Guida per l'utente di AWS CloudTrail*.
+ Utilizza le soluzioni di crittografia AWS, insieme a tutti i controlli di sicurezza di default all'interno dei Servizi AWS.
+ Utilizza i servizi di sicurezza gestiti avanzati, come Amazon Macie, che aiutano a individuare e proteggere i dati sensibili archiviati in Amazon S3.
+ Se necessiti di moduli crittografici convalidati FIPS 140-3 quando accedi ad AWS attraverso un'interfaccia a riga di comando o un'API, utilizza un endpoint FIPS. Per ulteriori informazioni sugli endpoint FIPS disponibili, consulta il [Federal Information Processing Standard (FIPS) 140-3](https://aws.amazon.com/compliance/fips/).
Ti consigliamo di non inserire mai informazioni riservate o sensibili, ad esempio gli indirizzi e-mail dei clienti, nei tag o nei campi di testo in formato libero, ad esempio nel campo **Nome**. Questo suggerimento è relativo all'utilizzo di Amazon RDS o altri Servizi AWS tramite la console, l'API, AWS CLI o gli SDK AWS. I dati inseriti nei tag o nei campi di testo in formato libero utilizzati per i nomi possono essere utilizzati per i la fatturazione o i log di diagnostica. Quando fornisci un URL a un server esterno, ti suggeriamo vivamente di non includere informazioni sulle credenziali nell'URL per convalidare la tua richiesta al server.
**Topics**
+ [Protezione dei dati tramite crittografia](Encryption.md)
+ [Riservatezza del traffico Internet](inter-network-traffic-privacy.md)
# 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/).
# Riservatezza del traffico Internet
Le connessioni sono protette sia tra Amazon Aurora e le applicazioni locali sia tra Aurora e altre risorse all'interno della stessa regione. AWS
## Traffico tra servizio e applicazioni e client locali
Sono disponibili due opzioni di connettività tra la rete privata e: AWS
+ Una connessione AWS Site-to-Site VPN. Per maggiori informazioni, consulta [Che cos’è AWS Site-to-Site VPN?](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html)
+ Una Direct Connect connessione. Per ulteriori informazioni, vedi [Cos'è Direct Connect?](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html)
È possibile ottenere l’accesso ad Amazon Aurora tramite la rete utilizzando le operazioni API pubblicate da AWS. I client devono supportare quanto segue:
+ Transport Layer Security (TLS). È richiesto TLS 1.2 ed è consigliato TLS 1.3.
+ Suite di cifratura con Perfect Forward Secrecy (PFS), ad esempio Ephemeral Diffie-Hellman (DHE) o Elliptic Curve Ephemeral Diffie-Hellman (ECDHE). La maggior parte dei sistemi moderni, come Java 7 e versioni successive, supporta tali modalità.
Inoltre, le richieste devono essere firmate utilizzando un ID chiave di accesso e una chiave di accesso segreta associata a un principale IAM. In alternativa, è possibile utilizzare [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) (AWS STS) per generare le credenziali di sicurezza temporanee per sottoscrivere le richieste.
# Gestione accessi e identità per Amazon Aurora
AWS Identity and Access Management (IAM) è un programma Servizio AWS che aiuta un amministratore a controllare in modo sicuro l'accesso alle AWS risorse. Gli amministratori IAM controllano chi può essere *autenticato* (accesso effettuato) e *autorizzato* (dispone di autorizzazioni) per utilizzare le risorse Amazon RDS. IAM è un software Servizio AWS che puoi utilizzare senza costi aggiuntivi.
**Topics**
+ [Destinatari](#security_iam_audience)
+ [Autenticazione con identità](#security_iam_authentication)
+ [Gestione dell’accesso tramite policy](#security_iam_access-manage)
+ [Funzionamento di Amazon Aurora con IAM](security_iam_service-with-iam.md)
+ [Esempi di policy di Amazon Aurora basate su identità](security_iam_id-based-policy-examples.md)
+ [AWS politiche gestite per Amazon RDS](rds-security-iam-awsmanpol.md)
+ [Aggiornamenti di Amazon RDS sulle policy gestite da AWS](rds-manpol-updates.md)
+ [Prevenzione del problema "confused deputy" tra servizi](cross-service-confused-deputy-prevention.md)
+ [Autenticazione del database IAM](UsingWithRDS.IAMDBAuth.md)
+ [Risoluzione dei problemi di identità e accesso in Amazon Aurora](security_iam_troubleshoot.md)
## Destinatari
Il modo in cui utilizzi AWS Identity and Access Management (IAM) varia a seconda del lavoro svolto in Aurora.
**Utente del servizio** –Se utilizzi il servizio Aurora per eseguire il tuo lavoro, l’amministratore fornisce le credenziali e le autorizzazioni necessarie. All’aumentare del numero di funzionalità Aurora utilizzate per il lavoro, potrebbero essere necessarie ulteriori autorizzazioni. La comprensione della gestione dell’accesso consente di richiedere le autorizzazioni corrette all’amministratore. Se non riesci ad accedere a una funzionalità di Aurora, consulta [Risoluzione dei problemi di identità e accesso in Amazon Aurora](security_iam_troubleshoot.md).
**Amministratore del servizio** – Se sei il responsabile delle risorse Aurorapresso la tua azienda, probabilmente disponi dell’accesso completo a Aurora. Il tuo compito è determinare le caratteristiche e le risorse Aurora a cui i dipendenti devono accedere. Devi inviare le richieste all’amministratore per cambiare le autorizzazioni degli utenti del servizio. Esamina le informazioni contenute in questa pagina per comprendere le nozioni di base di IAM. Per ulteriori informazioni su come la tua azienda può utilizzare IAM con Aurora, consulta [Funzionamento di Amazon Aurora con IAM](security_iam_service-with-iam.md).
**Amministratore** – Se sei un amministratore, potresti essere interessato a ottenere informazioni su come puoi scrivere policy per gestire l’accesso a Aurora. Per visualizzare policy basate su identità Aurora di esempio che puoi utilizzare in IAM, consulta [Esempi di policy di Amazon Aurora basate su identità](security_iam_id-based-policy-examples.md).
## Autenticazione con identità
L'autenticazione è il modo in cui accedi AWS utilizzando le tue credenziali di identità. Devi autenticarti come utente IAM o assumendo un ruolo IAM. Utente root dell'account AWS
Puoi accedere come identità federata utilizzando credenziali provenienti da una fonte di identità come AWS IAM Identity Center (IAM Identity Center), autenticazione Single Sign-On o credenziali. Google/Facebook Per maggiori informazioni sull’accesso, consultare la sezione [Come accedere a Account AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) nella *Guida per l’utente di Accedi ad AWS *.
Per l'accesso programmatico, AWS fornisce un SDK e una CLI per firmare crittograficamente le richieste. Per ulteriori informazioni, consulta [AWS Signature Version 4 per le richieste API](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) nella *Guida per l’utente IAM*.
### AWS account (utente root)
Quando si crea un Account AWS, si inizia con un'identità di accesso denominata *utente Account AWS root* che ha accesso completo a tutte Servizi AWS le risorse. Si consiglia vivamente di non utilizzare l’utente root per le attività quotidiane. Per le attività che richiedono le credenziali come utente root, consulta [Attività che richiedono le credenziali dell’utente root](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) nella *Guida per l’utente IAM*.
### Identità federata
Come procedura ottimale, richiedi agli utenti umani di utilizzare la federazione con un provider di identità per accedere Servizi AWS utilizzando credenziali temporanee.
Un'*identità federata* è un utente della directory aziendale, del provider di identità Web o Directory Service che accede Servizi AWS utilizzando le credenziali di una fonte di identità. Le identità federate assumono ruoli che forniscono credenziali temporanee.
Per la gestione centralizzata degli accessi, consigliamo di utilizzare AWS IAM Identity Center. Per ulteriori informazioni, consulta [Cos’è IAM Identity Center?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) nella *Guida per l’utente di AWS IAM Identity Center *.
### Utenti e gruppi IAM
Un *[utente IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* è un’identità che dispone di autorizzazioni specifiche per una singola persona o applicazione. Ti consigliamo di utilizzare credenziali temporanee invece di utenti IAM con credenziali a lungo termine. *Per ulteriori informazioni, consulta [Richiedere agli utenti umani di utilizzare la federazione con un provider di identità per accedere AWS utilizzando credenziali temporanee](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) nella Guida per l'utente IAM.*
Un [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) specifica una raccolta di utenti IAM e semplifica la gestione delle autorizzazioni per gestire gruppi di utenti di grandi dimensioni. Per ulteriori informazioni, consulta [Casi d’uso per utenti IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) nella *Guida per l’utente IAM*.
Puoi eseguire l’autenticazione nel cluster di database tramite l’autenticazione del database IAM.
L’autenticazione del database IAM funziona con Aurora. Per ulteriori informazioni sull’autenticazione al cluster di database tramite IAM, consulta [Autenticazione del database IAM ](UsingWithRDS.IAMDBAuth.md).
### Ruoli IAM
Un *[ruolo IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* è un'identità interna all'utente Account AWS che dispone di autorizzazioni specifiche. È simile a un utente, ma non è associato a una persona specifica. Puoi assumere temporaneamente un ruolo IAM in Console di gestione AWS [cambiando ruolo](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html). Puoi assumere un ruolo chiamando un'operazione AWS CLI o AWS API o utilizzando un URL personalizzato. Per ulteriori informazioni sui metodi per l’utilizzo dei ruoli, consulta [Utilizzo di ruoli IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html) nella *Guida per l’utente IAM*.
I ruoli IAM con credenziali temporanee sono utili nelle seguenti situazioni:
+ **Autorizzazioni utente temporanee**: un utente può assumere un ruolo IAM per ottenere temporaneamente autorizzazioni diverse per un’attività specifica.
+ **Accesso utente federato** - Per assegnare le autorizzazioni a una identità federata, è possibile creare un ruolo e definire le autorizzazioni per il ruolo. Quando un’identità federata viene autenticata, l’identità viene associata al ruolo e ottiene le autorizzazioni da esso definite. Per ulteriori informazioni sulla federazione dei ruoli, consulta [Creare un ruolo per un provider di identità di terza parte (federazione)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp.html) nella *Guida per l’utente IAM*. Se si utilizza IAM Identity Center, configurare un set di autorizzazioni. IAM Identity Center mette in correlazione il set di autorizzazioni con un ruolo in IAM per controllare a cosa possono accedere le identità dopo l’autenticazione. Per informazioni sui set di autorizzazioni, consulta [Set di autorizzazioni](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) nella *Guida per l’utente AWS IAM Identity Center *.
+ **Accesso multi-account**: è possibile utilizzare un ruolo IAM per permettere a un utente (un principale affidabile) con un account diverso di accedere alle risorse nell’account. I ruoli sono lo strumento principale per concedere l’accesso multi-account. Tuttavia, con alcuni Servizi AWS, è possibile allegare una policy direttamente a una risorsa (anziché utilizzare un ruolo come proxy). Per informazioni sulle differenze tra ruoli e policy basate su risorse per l’accesso multi-account, consulta [Differenza tra i ruoli IAM e le policy basate su risorse](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html) nella *Guida per l’utente IAM*.
+ **Accesso a più servizi**: alcuni Servizi AWS utilizzano le funzionalità di altri Servizi AWS. Ad esempio, quando effettui una chiamata in un servizio, è normale che quel servizio esegua applicazioni in Amazon EC2 o archivi oggetti in Amazon S3. Un servizio può eseguire questa operazione utilizzando le autorizzazioni dell’entità chiamante, utilizzando un ruolo di servizio o utilizzando un ruolo collegato al servizio.
+ **Sessioni di accesso inoltrato**: le sessioni di accesso inoltrato (FAS) utilizzano le autorizzazioni del principale chiamante e Servizio AWS, in combinazione con la richiesta, Servizio AWS per effettuare richieste ai servizi downstream. Per i dettagli delle policy relative alle richieste FAS, consultare [Forward access sessions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
+ **Ruolo di servizio** - Un ruolo di servizio è un [ruolo IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) che un servizio assume per eseguire operazioni per conto dell’utente. Un amministratore IAM può creare, modificare ed eliminare un ruolo di servizio dall’interno di IAM. Per ulteriori informazioni, consulta la sezione [Create a role to delegate permissions to an Servizio AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) nella *Guida per l’utente IAM*.
+ **Ruolo collegato al servizio: un ruolo collegato** al servizio è un tipo di ruolo di servizio collegato a un. Servizio AWS Il servizio può assumere il ruolo per eseguire un’azione per tuo conto. I ruoli collegati al servizio vengono visualizzati nel tuo account Account AWS e sono di proprietà del servizio. Un amministratore IAM può visualizzare le autorizzazioni per i ruoli collegati al servizio, ma non modificarle.
+ **Applicazioni in esecuzione su Amazon EC2**: puoi utilizzare un ruolo IAM per gestire le credenziali temporanee per le applicazioni in esecuzione su un' EC2 istanza e che AWS CLI effettuano richieste AWS API. Questa soluzione è preferibile alla memorizzazione delle chiavi di accesso all'interno dell' EC2 istanza. Per assegnare un AWS ruolo a un' EC2 istanza e renderlo disponibile per tutte le sue applicazioni, create un profilo di istanza collegato all'istanza. Un profilo di istanza contiene il ruolo e consente ai programmi in esecuzione sull' EC2 istanza di ottenere credenziali temporanee. Per ulteriori informazioni, consulta [Utilizzare un ruolo IAM per concedere le autorizzazioni alle applicazioni in esecuzione su EC2 istanze Amazon](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) nella *IAM User Guide*.
Per informazioni sull’utilizzo di ruoli IAM, consulta [Quando creare un ruolo IAM invece di un utente](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose_role) nella *Guida per l’utente di IAM*.
## Gestione dell’accesso tramite policy
Puoi controllare l'accesso AWS creando policy e collegandole a identità o risorse IAM. AWS Una policy è un oggetto AWS che, se associato a un'identità o a una risorsa, ne definisce le autorizzazioni. AWS valuta queste politiche quando un'entità (utente root, utente o ruolo IAM) effettua una richiesta. Le autorizzazioni nelle policy determinano l’approvazione o il rifiuto della richiesta. La maggior parte delle politiche viene archiviata AWS come documenti JSON. Per ulteriori informazioni sulla struttura e sui contenuti dei documenti delle policy JSON, consulta [Panoramica delle policy JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) nella *Guida per l’utente IAM*.
Un amministratore può utilizzare le policy per specificare chi ha accesso alle AWS risorse e quali azioni può eseguire su tali risorse. Ogni entità IAM (set di autorizzazioni o ruolo) inizialmente non dispone di autorizzazioni. Ovvero, di default, gli utenti non possono eseguire alcuna operazione, neppure modificare la propria password. Per autorizzare un utente a eseguire operazioni, un amministratore deve allegare una policy di autorizzazioni a tale utente. In alternativa, l’amministratore può aggiungere l’utente a un gruppo che dispone delle autorizzazioni desiderate. Quando un amministratore fornisce le autorizzazioni a un gruppo, le autorizzazioni vengono concesse a tutti gli utenti in tale gruppo.
Le policy IAM definiscono le autorizzazioni relative a un’operazione, indipendentemente dal metodo utilizzato per eseguirla. Ad esempio, supponiamo di disporre di una policy che consente l’operazione `iam:GetRole`. Un utente con tale policy può ottenere informazioni sul ruolo dall' Console di gestione AWS AWS CLI, dall'o dall' AWS API.
### Policy basate sull’identità
Le policy basate su identità sono documenti di policy di autorizzazione JSON che è possibile collegare a un’identità, ad esempio un set di autorizzazioni o un ruolo. Tali policy definiscono le operazioni autorizzate per l’identità, nonché le risorse e le condizioni in cui possono essere eseguite. Per informazioni su come creare una policy basata su identità, consulta [Creazione di policy IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) nella *Guida per l’utente IAM*.
Le policy basate su identità possono essere ulteriormente classificate come *policy inline* o *policy gestite*. Le policy inline sono incorporate direttamente in un singolo set di autorizzazioni o ruolo. Le politiche gestite sono politiche autonome che puoi allegare a più set di autorizzazioni e ruoli nel tuo AWS account. Le politiche gestite includono politiche AWS gestite e politiche gestite dai clienti. Per informazioni su come scegliere tra una policy gestita o una policy inline, consulta [Scelta fra policy gestite e policy inline](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#choosing-managed-or-inline) nella *Guida per l’utente IAM*.
Per informazioni sulle policy AWS gestite specifiche di Aurora, consulta. [AWS politiche gestite per Amazon RDS](rds-security-iam-awsmanpol.md)
### Altri tipi di policy
AWS supporta tipi di policy aggiuntivi e meno comuni. Questi tipi di policy possono impostare il numero massimo di autorizzazioni concesse dai più tipi di policy comuni.
+ **Limiti delle autorizzazioni**: un limite delle autorizzazioni è una funzione avanzata nella quale si imposta il numero massimo di autorizzazioni che una policy basata su identità può concedere a un’entità IAM (set di autorizzazioni o ruolo). È possibile impostare un limite delle autorizzazioni per un’entità. Le autorizzazioni risultanti sono l’intersezione delle policy basate su identità dell’entità e i suoi limiti delle autorizzazioni. Le policy basate su risorse che specificano il set di autorizzazioni o il ruolo nel campo `Principal` sono condizionate dal limite delle autorizzazioni. Un rifiuto esplicito in una qualsiasi di queste policy sostituisce l’autorizzazione. Per ulteriori informazioni sui limiti delle autorizzazioni, consulta [Limiti delle autorizzazioni per le entità IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) nella *Guida per l’utente di IAM*.
+ **Politiche di controllo del servizio (SCPs)**: SCPs sono politiche JSON che specificano le autorizzazioni massime per un'organizzazione o un'unità organizzativa (OU) in. AWS Organizations AWS Organizations è un servizio per il raggruppamento e la gestione centralizzata di più AWS account di proprietà dell'azienda. Se abiliti tutte le funzionalità di un'organizzazione, puoi applicare le politiche di controllo del servizio (SCPs) a uno o tutti i tuoi account. L'SCP limita le autorizzazioni per le entità presenti negli account dei membri, inclusa ciascuna di esse. Utente root dell'account AWS Per ulteriori informazioni su Organizations and SCPs, consulta [How SCPs work](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_about-scps.html) nella *AWS Organizations User Guide*.
+ **Policy di sessione** - Le policy di sessione sono policy avanzate che vengono trasmesse come parametro quando si crea in modo programmatico una sessione temporanea per un ruolo o un utente federato. Le autorizzazioni della sessione risultante sono l’intersezione delle policy basate sull’identità del set di autorizzazioni o del ruolo e le policy di sessione. Le autorizzazioni possono anche provenire da una policy basata su risorse. Un rifiuto esplicito in una qualsiasi di queste policy sostituisce l’autorizzazione. Per ulteriori informazioni, consulta [Policy di sessione](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) nella *Guida per l’utente IAM*.
### Più tipi di policy
Quando a una richiesta si applicano più tipi di policy, le autorizzazioni risultanti sono più complicate da comprendere. Per scoprire come si AWS determina se consentire o meno una richiesta quando sono coinvolti più tipi di policy, consulta [Logica di valutazione delle policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) nella *IAM User Guide*.
# Funzionamento di Amazon Aurora con IAM
Prima di utilizzare IAM per gestire l'accesso ad Amazon Aurora, è necessario comprendere quali funzionalità IAM sono disponibili per l'uso con Amazon Aurora.
Nella seguente tabella sono elencate le funzionalità di IAM che è possibile utilizzare con Amazon Aurora:
| Funzionalità IAM | Supporto di Amazon Aurora |
| --- | --- |
| [Policy basate sull’identità](#security_iam_service-with-iam-id-based-policies) | Sì |
| [Policy basate su risorse](#security_iam_service-with-iam-resource-based-policies) | No |
| [Operazioni di policy](#security_iam_service-with-iam-id-based-policies-actions) | Sì |
| [Risorse relative alle policy](#security_iam_service-with-iam-id-based-policies-resources) | Sì |
| [Chiavi di condizione della policy (specifica del servizio)](#UsingWithRDS.IAM.Conditions) | Sì |
| [ACLs](#security_iam_service-with-iam-acls) | No |
| [Controllo degli accessi basato su attributi (ABAC) (tag nelle policy)](#security_iam_service-with-iam-tags) | Sì |
| [Credenziali temporanee](#security_iam_service-with-iam-roles-tempcreds) | Sì |
| [Inoltro delle sessioni di accesso](#security_iam_service-with-iam-principal-permissions) | Sì |
| [Ruoli di servizio](#security_iam_service-with-iam-roles-service) | Sì |
| [Ruoli collegati al servizio](#security_iam_service-with-iam-roles-service-linked) | Sì |
*Per avere una visione di alto livello di come Aurora e AWS altri servizi funzionano con IAM, [AWS consulta i servizi che funzionano con](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) IAM nella IAM User Guide.*
**Topics**
+ [Policy basate su identità Aurora](#security_iam_service-with-iam-id-based-policies)
+ [Policy basate su risorse all'interno di Aurora](#security_iam_service-with-iam-resource-based-policies)
+ [Operazioni delle policy per Aurora](#security_iam_service-with-iam-id-based-policies-actions)
+ [Risorse delle policy per Aurora](#security_iam_service-with-iam-id-based-policies-resources)
+ [Chiavi di condizione delle policy per Aurora](#UsingWithRDS.IAM.Conditions)
+ [Elenchi di controllo degli accessi (ACLs) in](#security_iam_service-with-iam-acls)
+ [Controllo degli accessi basato su attributi (ABAC) nelle policy con tag Aurora](#security_iam_service-with-iam-tags)
+ [Utilizzo di credenziali temporanee con Aurora](#security_iam_service-with-iam-roles-tempcreds)
+ [Inoltro delle sessioni di accesso per Aurora](#security_iam_service-with-iam-principal-permissions)
+ [Ruoli di servizio per Aurora](#security_iam_service-with-iam-roles-service)
+ [Ruoli collegati ai servizi per Aurora](#security_iam_service-with-iam-roles-service-linked)
## Policy basate su identità Aurora
**Supporta le policy basate su identità:** sì.
Le policy basate sull'identità sono documenti di policy di autorizzazione JSON che è possibile allegare a un'identità (utente, gruppo di utenti o ruolo IAM). Tali policy definiscono le operazioni che utenti e ruoli possono eseguire, su quali risorse e in quali condizioni. Per informazioni su come creare una policy basata su identità, consulta [Definizione di autorizzazioni personalizzate IAM con policy gestite dal cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) nella *Guida per l’utente di IAM*.
Con le policy basate sull’identità di IAM, è possibile specificare quali operazioni e risorse sono consentite o respinte, nonché le condizioni in base alle quali le operazioni sono consentite o respinte. Per informazioni su tutti gli elementi utilizzabili in una policy JSON, consulta [Guida di riferimento agli elementi delle policy JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) nella *Guida per l’utente IAM*.
### Esempi di policy basate su identità per Aurora
Per visualizzare esempi di policy basate su identità Aurora, consulta [Esempi di policy di Amazon Aurora basate su identità](security_iam_id-based-policy-examples.md).
## Policy basate su risorse all'interno di Aurora
**Supporta le policy basate su risorse:** no.
Le policy basate su risorse sono documenti di policy JSON che è possibile collegare a una risorsa. Esempi di policy basate sulle risorse sono le *policy di attendibilità dei ruoli* IAM e le *policy di bucket* Amazon S3. Nei servizi che supportano policy basate sulle risorse, gli amministratori dei servizi possono utilizzarli per controllare l’accesso a una risorsa specifica. Quando è collegata a una risorsa, una policy definisce le operazioni che un principale può eseguire su tale risorsa e a quali condizioni. In una policy basata sulle risorse è obbligatorio [specificare un’entità principale](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html). I principali possono includere account, utenti, ruoli, utenti federati o. Servizi AWS
Per consentire l’accesso multi-account, è possibile specificare un intero account o entità IAM in un altro account come entità principale in una policy basata sulle risorse. Per ulteriori informazioni, consulta [Accesso a risorse multi-account in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) nella *Guida per l’utente IAM*.
## Operazioni delle policy per Aurora
**Supporta le operazioni di policy:** si
Gli amministratori possono utilizzare le policy AWS JSON per specificare chi ha accesso a cosa. In altre parole, quale **entità principale** può eseguire **operazioni** su quali **risorse** e in quali **condizioni**.
L'elemento `Action` di una policy JSON descrive le operazioni che è possibile utilizzare per consentire o negare l'accesso in una policy. Includere le operazioni in una policy per concedere le autorizzazioni a eseguire l’operazione associata.
Le operazioni delle policy in Aurora utilizzano il seguente prefisso prima dell'operazione: `rds:`. Ad esempio, per concedere a qualcuno l'autorizzazione per descrivere istanze database con l'operazione API Amazon RDS `DescribeDBInstances`, includi l'operazione `rds:DescribeDBInstances` nella policy. Le istruzioni della policy devono includere un elemento `Action` o `NotAction`. Aurora definisce un proprio set di operazioni che descrivono le attività che puoi eseguire con quel servizio.
Per specificare più operazioni in una singola istruzione, separarle con una virgola come mostrato di seguito.
```
"Action": [
"rds:action1",
"rds:action2"
```
Puoi specificare più operazioni tramite caratteri jolly (\$1). Ad esempio, per specificare tutte le operazioni che iniziano con la parola `Describe`, includi la seguente operazione.
```
"Action": "rds:Describe*"
```
Per visualizzare un elenco di operazioni di Aurora, consulta [Operazioni definite da Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-actions-as-permissions) nella *Service Authorization Reference*.
## Risorse delle policy per Aurora
**Supporta le risorse di policy:** sì.
Gli amministratori possono utilizzare le policy AWS JSON per specificare chi ha accesso a cosa. In altre parole, quale **entità principale** può eseguire **operazioni** su quali **risorse** e in quali **condizioni**.
L’elemento JSON `Resource` della policy specifica l’oggetto o gli oggetti ai quali si applica l’operazione. Come best practice, specifica una risorsa utilizzando il suo [nome della risorsa Amazon (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). Per le azioni che non supportano le autorizzazioni a livello di risorsa, si utilizza un carattere jolly (\$1) per indicare che l’istruzione si applica a tutte le risorse.
```
"Resource": "*"
```
La risorsa di un'istanza database ha il seguente nome della risorsa Amazon (ARN).
```
arn:${Partition}:rds:${Region}:${Account}:{ResourceType}/${Resource}
```
Per ulteriori informazioni sul formato di ARNs, consulta [Amazon Resource Names (ARNs) e AWS service namespaces](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html).
Ad esempio, per specificare l'istanza database `dbtest` nell'istruzione, utilizza l'ARN riportato di seguito.
```
"Resource": "arn:aws:rds:us-west-2:123456789012:db:dbtest"
```
Per specificare tutte le istanze database che appartengono a un account specifico, utilizza il carattere jolly (\$1).
```
"Resource": "arn:aws:rds:us-east-1:123456789012:db:*"
```
Alcune operazioni API RDS, ad esempio quelle per la creazione di risorse, non possono essere eseguite su una risorsa specifica. In questi casi, utilizza il carattere jolly (\$1).
```
"Resource": "*"
```
Molte operazioni API di Amazon RDS coinvolgono più risorse. Ad esempio, `CreateDBInstance` crea un'istanza database. Puoi specificare che un utente deve utilizzare un gruppo specifico di sicurezza e un gruppo di parametri quando crea un’istanza database. Per specificare più risorse in una singola istruzione, separale con virgole. ARNs
```
"Resource": [
"resource1",
"resource2"
```
*Per visualizzare un elenco dei tipi di risorse di Aurora e ARNs relativi, [consulta Resources Defined by Amazon](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-resources-for-iam-policies) RDS nel Service Authorization Reference.* Per informazioni sulle operazioni con cui è possibile specificare l'ARN di ogni risorsa, consulta [Operazioni definite da Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-actions-as-permissions).
## Chiavi di condizione delle policy per Aurora
**Supporta le chiavi di condizione delle policy specifiche del servizio:** sì.
Gli amministratori possono utilizzare le policy AWS JSON per specificare chi ha accesso a cosa. In altre parole, quale **entità principale** può eseguire **operazioni** su quali **risorse** e in quali **condizioni**.
L’elemento `Condition` specifica quando le istruzioni vengono eseguite in base a criteri definiti. È possibile compilare espressioni condizionali che utilizzano [operatori di condizione](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), ad esempio uguale a o minore di, per soddisfare la condizione nella policy con i valori nella richiesta. Per visualizzare tutte le chiavi di condizione AWS globali, consulta le chiavi di [contesto delle condizioni AWS globali nella Guida](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) per l'*utente IAM*.
Aurora definisce il proprio set di chiavi di condizione e, inoltre, supporta l'uso di alcune chiavi di condizione globali. Per vedere tutte le chiavi di condizione AWS globali, consulta le [chiavi di contesto delle condizioni AWS globali](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) nella *Guida per l'utente IAM*.
Tutte le operazioni API RDS supportano la chiave di condizione `aws:RequestedRegion`.
Per visualizzare un elenco di chiavi di condizione Aurora, consulta [Chiavi di condizione per Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-policy-keys) nella *Service Authorization Reference*. Per informazioni su operazioni e risorse con cui è possibile utilizzare una chiave di condizione, consulta [Operazioni definite da Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-actions-as-permissions).
## Elenchi di controllo degli accessi (ACLs) in
**Supporta gli elenchi di controllo degli accessi (ACLs)**: No
Le liste di controllo degli accessi (ACLs) controllano quali principali (membri dell'account, utenti o ruoli) dispongono delle autorizzazioni per accedere a una risorsa. ACLs sono simili alle politiche basate sulle risorse, sebbene non utilizzino il formato del documento di policy JSON.
## Controllo degli accessi basato su attributi (ABAC) nelle policy con tag Aurora
**Supporta tag di controllo degli accessi basato su attributi (ABAC) nelle policy:** sì.
Il controllo degli accessi basato su attributi (ABAC) è una strategia di autorizzazione che definisce le autorizzazioni in base ad attributi chiamati tag. È possibile allegare tag a entità e AWS risorse IAM, quindi progettare politiche ABAC per consentire operazioni quando il tag del principale corrisponde al tag sulla risorsa.
Per controllare l’accesso basato su tag, fornire informazioni sui tag nell’[elemento condizione](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) di una policy utilizzando le chiavi di condizione `aws:ResourceTag/key-name`, `aws:RequestTag/key-name` o `aws:TagKeys`.
Se un servizio supporta tutte e tre le chiavi di condizione per ogni tipo di risorsa, il valore per il servizio è **Sì**. Se un servizio supporta tutte e tre le chiavi di condizione solo per alcuni tipi di risorsa, allora il valore sarà **Parziale**.
Per maggiori informazioni su ABAC, consulta [Definizione delle autorizzazioni con autorizzazione ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) nella *Guida per l’utente di IAM*. Per visualizzare un tutorial con i passaggi per l’impostazione di ABAC, consulta [Utilizzo del controllo degli accessi basato su attributi (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) nella *Guida per l’utente di IAM*.
Per ulteriori informazioni sul tagging delle risorse di Aurora, consulta [Specifica delle condizioni: Utilizzo di tag personalizzati](UsingWithRDS.IAM.SpecifyingCustomTags.md). Per visualizzare una policy basata sulle identità di esempio per limitare l'accesso a una risorsa basata su tag su tale risorsa, consulta [Concedere l'autorizzazione per le operazioni su una risorsa con un tag specifico con due valori diversi](security_iam_id-based-policy-examples-create-and-modify-examples.md#security_iam_id-based-policy-examples-grant-permissions-tags).
## Utilizzo di credenziali temporanee con Aurora
**Supporta le credenziali temporanee:** sì.
Le credenziali temporanee forniscono l'accesso a breve termine alle AWS risorse e vengono create automaticamente quando si utilizza la federazione o si cambia ruolo. AWS consiglia di generare dinamicamente credenziali temporanee anziché utilizzare chiavi di accesso a lungo termine. Per ulteriori informazioni, consulta [Credenziali di sicurezza temporanee in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) e [Servizi AWS compatibili con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) nella *Guida per l’utente IAM*.
## Inoltro delle sessioni di accesso per Aurora
**Supporta l’inoltro delle sessioni di accesso:** sì.
Le sessioni di accesso inoltrato (FAS) utilizzano le autorizzazioni del principale che chiama e, in combinazione con la richiesta Servizio AWS, Servizio AWS per effettuare richieste ai servizi downstream. Per i dettagli delle policy relative alle richieste FAS, consulta [Forward access sessions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
## Ruoli di servizio per Aurora
**Supporta i ruoli di servizio:** sì.
Un ruolo di servizio è un [ruolo IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) che un servizio assume per eseguire operazioni per tuo conto. Un amministratore IAM può creare, modificare ed eliminare un ruolo di servizio dall’interno di IAM. Per ulteriori informazioni, consulta [Create a role to delegate permissions to an Servizio AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) nella *Guida per l’utente IAM*.
**avvertimento**
La modifica delle autorizzazioni per un ruolo di servizio potrebbe compromettere la funzionalità di Aurora. Modificare i ruoli di servizio solo quando Aurora fornisce le indicazioni per farlo.
## Ruoli collegati ai servizi per Aurora
**Supporta i ruoli collegati ai servizi:** sì.
Un ruolo collegato al servizio è un tipo di ruolo di servizio collegato a un. Servizio AWS Il servizio può assumere il ruolo per eseguire un’operazione per tuo conto. I ruoli collegati al servizio vengono visualizzati nel tuo account Account AWS e sono di proprietà del servizio. Un amministratore IAM può visualizzare le autorizzazioni per i ruoli collegati al servizio, ma non modificarle.
Per ulteriori informazioni sull'utilizzo di ruoli collegati ai servizi Aurora, consulta [Utilizzo di ruoli collegati ai servizi per Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md).
# Esempi di policy di Amazon Aurora basate su identità
Per impostazione predefinita, i set di autorizzazioni e i ruoli non dispongono dell'autorizzazione per creare o modificare risorse Aurora. Inoltre, non possono eseguire attività utilizzando l' AWS API Console di gestione AWS AWS CLI, o. Un amministratore deve creare policy IAM che concedono a set di autorizzazioni e ruoli l'autorizzazione per eseguire operazioni API specifiche sulle risorse specifiche di cui hanno bisogno. L'amministratore deve quindi collegare queste policy ai set di autorizzazioni o ai ruoli che richiedono tali autorizzazioni.
Per informazioni su come creare una policy basata su identità IAM utilizzando questi documenti di policy JSON di esempio, consultare [Creazione di policy nella scheda JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) nella *Guida per l'utente di IAM*.
**Topics**
+ [Best practice delle policy](#security_iam_service-with-iam-policy-best-practices)
+ [Utilizzo della console di Aurora](#security_iam_id-based-policy-examples-console)
+ [Autorizzazioni necessarie per l'uso della console](#UsingWithRDS.IAM.RequiredPermissions.Console)
+ [Consentire agli utenti di visualizzare le loro autorizzazioni](#security_iam_id-based-policy-examples-view-own-permissions)
+ [Policy di autorizzazione per creare, modificare ed eliminare risorse in Aurora](security_iam_id-based-policy-examples-create-and-modify-examples.md)
+ [Policy di esempio: Utilizzo di chiavi di condizione](UsingWithRDS.IAM.Conditions.Examples.md)
+ [Specifica delle condizioni: Utilizzo di tag personalizzati](UsingWithRDS.IAM.SpecifyingCustomTags.md)
+ [Concessione dell’autorizzazione all’applicazione di tag Aurora per le risorse durante la creazione](security_iam_id-based-policy-examples-grant-permissions-tags-on-create.md)
## Best practice delle policy
Le policy basate su identità determinano se qualcuno può creare, accedere o eliminare risorse Amazon RDS nell'account. Queste azioni possono comportare costi aggiuntivi per l’ Account AWS. Quando si creano o modificano policy basate sull’identità, seguire queste linee guida e raccomandazioni:
+ **Inizia con le policy AWS gestite e passa alle autorizzazioni con privilegi minimi: per iniziare a concedere autorizzazioni** a utenti e carichi di lavoro, utilizza le *politiche AWS gestite* che concedono le autorizzazioni per molti casi d'uso comuni. Sono disponibili nel tuo. Account AWS Ti consigliamo di ridurre ulteriormente le autorizzazioni definendo politiche gestite dai AWS clienti specifiche per i tuoi casi d'uso. Per maggiori informazioni, consulta [Policy gestite da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) o [Policy gestite da AWS per le funzioni dei processi](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) nella *Guida per l’utente di IAM*.
+ **Applicazione delle autorizzazioni con privilegio minimo** - Quando si impostano le autorizzazioni con le policy IAM, concedere solo le autorizzazioni richieste per eseguire un’attività. È possibile farlo definendo le azioni che possono essere intraprese su risorse specifiche in condizioni specifiche, note anche come *autorizzazioni con privilegio minimo*. Per maggiori informazioni sull’utilizzo di IAM per applicare le autorizzazioni, consulta [Policy e autorizzazioni in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) nella *Guida per l’utente di IAM*.
+ **Condizioni d’uso nelle policy IAM per limitare ulteriormente l’accesso** - Per limitare l’accesso ad azioni e risorse è possibile aggiungere una condizione alle policy. Ad esempio, è possibile scrivere una condizione di policy per specificare che tutte le richieste devono essere inviate utilizzando SSL. Puoi anche utilizzare le condizioni per concedere l'accesso alle azioni del servizio se vengono utilizzate tramite uno specifico Servizio AWS, ad esempio CloudFormation. Per maggiori informazioni, consultare la sezione [Elementi delle policy JSON di IAM: condizione](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) nella *Guida per l’utente di IAM*.
+ **Utilizzo dello strumento di analisi degli accessi IAM per convalidare le policy IAM e garantire autorizzazioni sicure e funzionali** - Lo strumento di analisi degli accessi IAM convalida le policy nuove ed esistenti in modo che aderiscano al linguaggio (JSON) della policy IAM e alle best practice di IAM. Lo strumento di analisi degli accessi IAM offre oltre 100 controlli delle policy e consigli utili per creare policy sicure e funzionali. Per maggiori informazioni, consultare [Convalida delle policy per il Sistema di analisi degli accessi IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) nella *Guida per l’utente di IAM*.
+ **Richiedi l'autenticazione a più fattori (MFA**): se hai uno scenario che richiede utenti IAM o un utente root nel Account AWS tuo, attiva l'MFA per una maggiore sicurezza. Per richiedere la MFA quando vengono chiamate le operazioni API, aggiungere le condizioni MFA alle policy. Per maggiori informazioni, consultare [Protezione dell’accesso API con MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) nella *Guida per l’utente di IAM*.
Per maggiori informazioni sulle best practice in IAM, consulta [Best practice di sicurezza in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) nella *Guida per l’utente di IAM*.
## Utilizzo della console di Aurora
Per accedere alla console Amazon Aurora, è necessario disporre di un set di autorizzazioni minimo. Queste autorizzazioni devono consentirti di elencare e visualizzare i dettagli sulle risorse Amazon Aurora presenti nel tuo. Account AWS Se crei una policy basata sull’identità più restrittiva rispetto alle autorizzazioni minime richieste, la console non funzionerà nel modo previsto per le entità (utenti o ruoli) associate a tale policy.
Non è necessario consentire autorizzazioni minime per la console per gli utenti che effettuano chiamate solo verso o l' AWS CLI API. AWS Al contrario, è possibile accedere solo alle operazioni che soddisfano l'operazione API che stai cercando di eseguire.
Per garantire che tali entità possano ancora utilizzare la console Aurora, allega anche la AWS seguente policy gestita alle entità.
```
AmazonRDSReadOnlyAccess
```
Per maggiori informazioni, consulta [Aggiunta di autorizzazioni a un utente](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) nella *Guida per l’utente di IAM*.
## Autorizzazioni necessarie per l'uso della console
Affinché un utente possa utilizzare la console, è necessario che disponga di un set minimo di autorizzazioni. Queste autorizzazioni consentono all'utente di descrivere le risorse Aurora per il AWS proprio account e di fornire altre informazioni correlate, tra cui informazioni sulla sicurezza e sulla rete di Amazon EC2.
Se decidi di creare una policy IAM più restrittiva delle autorizzazioni minime richieste, la console non funzionerà come previsto per gli utenti con tale policy IAM. Per garantire che gli utenti possano continuare a usare la console, collega anche la policy gestita `AmazonRDSReadOnlyAccess` all'utente, come descritto in [Gestione dell’accesso tramite policy](UsingWithRDS.IAM.md#security_iam_access-manage).
Non sono necessarie le autorizzazioni minime della console per gli utenti che effettuano chiamate solo a AWS CLI o all'API di Amazon RDS.
La seguente politica garantisce l'accesso completo a tutte le risorse Amazon Aurora per l'account root: AWS
```
AmazonRDSFullAccess
```
## Consentire agli utenti di visualizzare le loro autorizzazioni
Questo esempio mostra in che modo è possibile creare una policy che consente agli utenti IAM di visualizzare le policy inline e gestite che sono collegate alla relativa identità utente. Questa policy include le autorizzazioni per completare questa azione sulla console o utilizzando programmaticamente l'API o. AWS CLI AWS
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
# Policy di autorizzazione per creare, modificare ed eliminare risorse in Aurora
Le seguenti sezioni presentano esempi di policy di autorizzazione che concedono e limitano l’accesso alle risorse:
## Consenti a un utente di creare istanze DB in un account AWS
Di seguito è riportato un esempio di politica che consente all'account con l'ID di `123456789012` creare istanze DB per il tuo AWS account. La policy richiede che il nome della nuova istanza database inizi con `test`. La nuova istanza database deve anche utilizzare il motore del database MySQL e la classe di istanza database `db.t2.micro`. Inoltre, la nuova istanza database deve utilizzare un gruppo di opzioni e un gruppo di parametri database che inizia con `default`, e deve utilizzare il gruppo di sottoreti `default`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowCreateDBInstanceOnly",
"Effect": "Allow",
"Action": [
"rds:CreateDBInstance"
],
"Resource": [
"arn:aws:rds:*:123456789012:db:test*",
"arn:aws:rds:*:123456789012:og:default*",
"arn:aws:rds:*:123456789012:pg:default*",
"arn:aws:rds:*:123456789012:subgrp:default"
],
"Condition": {
"StringEquals": {
"rds:DatabaseEngine": "mysql",
"rds:DatabaseClass": "db.t2.micro"
}
}
}
]
}
```
------
La policy include una singola istruzione che specifica le autorizzazioni seguenti per l'utente :
+ La policy consente all'account di creare un'istanza DB utilizzando l'operazione [Create DBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) API (ciò vale anche per il [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) AWS CLI comando e il Console di gestione AWS).
+ L'elemento `Resource` specifica che l'utente può eseguire azioni in o con altre risorse. Specifica le risorse usando Amazon Resource Name (ARN). Questo ARN include il nome del servizio a cui appartiene la risorsa (`rds`), la AWS regione (`*`indica qualsiasi regione in questo esempio), il numero di AWS account (`123456789012`è il numero di account in questo esempio) e il tipo di risorsa. Per ulteriori informazioni sulla creazione ARNs, vedere[Nome della risorsa Amazon (ARN) in Amazon RDS](USER_Tagging.ARN.md).
L'elemento `Resource` nell'esempio specifica i seguenti vincoli della policy sulle risorse per l'utente:
+ L'identificatore istanze DB per la nuova istanza database deve iniziare con `test` (per esempio, `testCustomerData1`, `test-region2-data`).
+ Il gruppo di opzioni per la nuova istanza database deve iniziare con `default`.
+ Il gruppo di parametri database per la nuova istanza database deve iniziare con `default`.
+ Il gruppo di sottoreti per la nuova istanza database deve essere il gruppo di sottoreti `default`.
+ L'elemento `Condition` specifica che il motore database deve essere MySQL e la classe di istanza database deve essere `db.t2.micro`. L'elemento `Condition` specifica le condizioni quando deve essere applicata una policy. È possibile aggiungere permessi o restrizioni aggiuntivi usando l'elemento `Condition`. Per ulteriori informazioni su come specificare le condizioni;, consulta [Chiavi di condizione delle policy per Aurora](security_iam_service-with-iam.md#UsingWithRDS.IAM.Conditions). Questo esempio specifica le condizioni `rds:DatabaseEngine` e `rds:DatabaseClass`. Per informazioni sui valori delle condizioni validi per`rds:DatabaseEngine`, consultate l'elenco sotto il `Engine` parametro in [Create DBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html). Per informazioni sui valori di condizione validi per `rds:DatabaseClass`, consulta [Motori di database supportati per classi di istanza database](Concepts.DBInstanceClass.SupportAurora.md).
La policy non specifica l'elemento `Principal` poiché in una policy basata su identità l'entità che ottiene l'autorizzazione non viene specificata. Quando si collega una policy a un utente, quest'ultimo è l'entità implicita. Quando si collega una policy di autorizzazione a un ruolo IAM;, l'entità identificata nella policy di attendibilità del ruolo ottiene le autorizzazioni.
Per visualizzare un elenco di operazioni di Aurora, consulta [Operazioni definite da Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-actions-as-permissions) nella *Service Authorization Reference*.
## Consentire a un utente di eseguire qualsiasi operazione Describe in qualsiasi risorsa RDS
La seguente policy di autorizzazione concede a un utente le autorizzazioni per eseguire tutte le operazioni che iniziano con `Describe`. Queste operazioni riportano informazioni su una risorsa RDS, ad esempio un'istanza database. Il carattere jolly (\$1) nell'elemento `Resource` indica che le operazioni sono permesse per tutte le risorse Amazon Aurora di proprietà dell'account.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowRDSDescribe",
"Effect": "Allow",
"Action": "rds:Describe*",
"Resource": "*"
}
]
}
```
------
## Consentire a un utente di creare un'istanza database che utilizza il gruppo parametri del database e il gruppo di sottorete specificati
La seguente policy di autorizzazioni concede le autorizzazioni per consentire a un utente di creare un'istanza database che deve usare il gruppo di parametri database `mydbpg` e il gruppo di sottorete DB `mydbsubnetgroup`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "rds:CreateDBInstance",
"Resource": [
"arn:aws:rds:*:*:pg:mydbpg",
"arn:aws:rds:*:*:subgrp:mydbsubnetgroup"
]
}
]
}
```
------
## Concedere l'autorizzazione per le operazioni su una risorsa con un tag specifico con due valori diversi
Puoi utilizzare le condizioni nella policy basata sulle identità per controllare l'accesso alle risorse di Aurora in base ai tag. La seguente policy concede l'autorizzazione per eseguire l'operazione API `CreateDBSnapshot` sulle istanze database con il tag `stage` impostato su `development` o `test`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AllowAnySnapshotName",
"Effect":"Allow",
"Action":[
"rds:CreateDBSnapshot"
],
"Resource":"arn:aws:rds:*:123456789012:snapshot:*"
},
{
"Sid":"AllowDevTestToCreateSnapshot",
"Effect":"Allow",
"Action":[
"rds:CreateDBSnapshot"
],
"Resource":"arn:aws:rds:*:123456789012:db:*",
"Condition":{
"StringEquals":{
"rds:db-tag/stage":[
"development",
"test"
]
}
}
}
]
}
```
------
La seguente policy concede l'autorizzazione per eseguire l'operazione API `ModifyDBInstance` sulle istanze database con il tag `stage` impostato su `development` o `test`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AllowChangingParameterOptionSecurityGroups",
"Effect":"Allow",
"Action":[
"rds:ModifyDBInstance"
],
"Resource": [
"arn:aws:rds:*:123456789012:pg:*",
"arn:aws:rds:*:123456789012:secgrp:*",
"arn:aws:rds:*:123456789012:og:*"
]
},
{
"Sid":"AllowDevTestToModifyInstance",
"Effect":"Allow",
"Action":[
"rds:ModifyDBInstance"
],
"Resource":"arn:aws:rds:*:123456789012:db:*",
"Condition":{
"StringEquals":{
"rds:db-tag/stage":[
"development",
"test"
]
}
}
}
]
}
```
------
## Impedire a un utente di eliminare un'istanza database
La seguente policy di autorizzazione assegna le autorizzazioni per impedire a un utente di eliminare un'istanza database specifica. Ad esempio, potresti voler negare la possibilità di eliminare le istanze database di produzione a qualsiasi utente che non sia un amministratore.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyDelete1",
"Effect": "Deny",
"Action": "rds:DeleteDBInstance",
"Resource": "arn:aws:rds:us-west-2:123456789012:db:my-mysql-instance"
}
]
}
```
------
## Negare tutti gli accessi a una risorsa
È anche possibile negare esplicitamente l'accesso a una risorsa. I criteri di negazione hanno la precedenza sui criteri di autorizzazione. La policy seguente nega esplicitamente a un utente la possibilità di gestire una risorsa:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "rds:*",
"Resource": "arn:aws:rds:us-east-1:123456789012:db:mydb"
}
]
}
```
------
# Policy di esempio: Utilizzo di chiavi di condizione
Di seguito sono illustrati esempi di come è possibile utilizzare le chiavi di condizione nelle policy di autorizzazioni IAM di Amazon Aurora.
## Esempio 1: Concessione dell'autorizzazione per creare un'istanza database che utilizza un motore del database specifico e non è Multi-AZ
La policy seguente utilizza una chiave di condizione RDS e permette a un utente di creare solo istanze database che utilizzano il motore del database MySQL e non utilizzano Multi-AZ. L'elemento `Condition` indica il requisito secondo cui il motore del database deve essere MySQL.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowMySQLCreate",
"Effect": "Allow",
"Action": "rds:CreateDBInstance",
"Resource": "*",
"Condition": {
"StringEquals": {
"rds:DatabaseEngine": "mysql"
},
"Bool": {
"rds:MultiAz": false
}
}
}
]
}
```
------
## Esempio 2: Rifiuto esplicito dell'autorizzazione per creare istanze database per determinate classi di istanze database e per creare istanze database che utilizzano Provisioned IOPS
La policy seguente rifiuta in modo esplicito l'autorizzazione per creare istanze database che utilizzano le classi di istanze database `r3.8xlarge` e `m4.10xlarge`, che sono le istanze database di dimensioni maggiori e più costose. Questa policy impedisce anche gli utenti di creare istanze database che utilizzano Provisioned IOPS, che comporta costi aggiuntivi.
Il rifiuto esplicito di un'autorizzazione prevale su qualsiasi altra autorizzazione concessa. In questo modo si evita che le identità ottengano accidentalmente un'autorizzazione che non desideravi concedere.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyLargeCreate",
"Effect": "Deny",
"Action": "rds:CreateDBInstance",
"Resource": "*",
"Condition": {
"StringEquals": {
"rds:DatabaseClass": [
"db.r3.8xlarge",
"db.m4.10xlarge"
]
}
}
},
{
"Sid": "DenyPIOPSCreate",
"Effect": "Deny",
"Action": "rds:CreateDBInstance",
"Resource": "*",
"Condition": {
"NumericNotEquals": {
"rds:Piops": "0"
}
}
}
]
}
```
------
## Esempio 3: limita il set di chiavi di tag e valori che possono essere utilizzati per aggiungere tag a una risorsa
La policy seguente utilizza una chiave di condizione RDS che consente l'aggiunta di un tag con la chiave `stage` per essere aggiunta alla risorsa con i valori `test`, `qa` e `production`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowTagEdits",
"Effect": "Allow",
"Action": [
"rds:AddTagsToResource",
"rds:RemoveTagsFromResource"
],
"Resource": "arn:aws:rds:us-east-1:123456789012:db:db-123456",
"Condition": {
"StringEquals": {
"rds:req-tag/stage": [
"test",
"qa",
"production"
]
}
}
}
]
}
```
------
# Specifica delle condizioni: Utilizzo di tag personalizzati
Amazon Aurora permette di specificare condizioni in una policy IAM utilizzando tag personalizzati.
Ad esempio, supponi di aggiungere alle istanze database un tag denominato `environment` con valori quali `beta`, `staging`, `production` e così via. In questo modo, puoi creare una policy che limita alcuni utenti alle istanze database in base al valore del tag `environment`.
**Nota**
Per gli identificatori di tag personalizzati viene fatta distinzione tra maiuscole e minuscole.
Nella tabella seguente sono elencati gli identificatori di tag RDS che è possibile utilizzare in un elemento `Condition`.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAM.SpecifyingCustomTags.html)
La sintassi per una condizione di un tag personalizzato è la seguente:
`"Condition":{"StringEquals":{"rds:rds-tag-identifier/tag-name": ["value"]} }`
Ad esempio, l'elemento `Condition` seguente si applica alle istanze database con un tag denominato `environment` e un valore di tag corrispondente a `production`.
` "Condition":{"StringEquals":{"rds:db-tag/environment": ["production"]} } `
Per informazioni sulla creazione di tag, consulta [Etichettatura delle risorse Amazon Aurora e Amazon RDS](USER_Tagging.md).
**Importante**
Se gestisci l'accesso alle risorse RDS tramite tagging, è consigliabile proteggere l'accesso ai tag per le risorse RDS. È possibile gestire l'accesso ai tag creando policy per le operazioni `AddTagsToResource` e `RemoveTagsFromResource`. Ad esempio, la policy seguente nega agli utenti la possibilità di aggiungere o rimuovere tag per tutte le risorse. Puoi quindi creare policy per permettere a utenti specifici di aggiungere o rimuovere tag.
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"DenyTagUpdates",
"Effect":"Deny",
"Action":[
"rds:AddTagsToResource",
"rds:RemoveTagsFromResource"
],
"Resource":"*"
}
]
}
```
Per visualizzare un elenco di operazioni di Aurora, consulta [Operazioni definite da Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-actions-as-permissions) nella *Service Authorization Reference*.
## Policy di esempio: Utilizzo di tag personalizzati
Di seguito sono illustrati esempi di come è possibile utilizzare i tag personalizzati nelle policy di autorizzazioni IAM di Amazon Aurora. Per ulteriori informazioni sull'aggiunta di tag a una risorsa Amazon Aurora, consulta [Nome della risorsa Amazon (ARN) in Amazon RDS](USER_Tagging.ARN.md).
**Nota**
Tutti gli esempi utilizzano la regione us-west-2 e contengono account fittizi. IDs
### Esempio 1: Concessione dell'autorizzazione per le operazioni su una risorsa con un tag specifico con due valori diversi
La seguente policy concede l'autorizzazione per eseguire l'operazione API `CreateDBSnapshot` sulle istanze database con il tag `stage` impostato su `development` o `test`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AllowAnySnapshotName",
"Effect":"Allow",
"Action":[
"rds:CreateDBSnapshot"
],
"Resource":"arn:aws:rds:*:123456789012:snapshot:*"
},
{
"Sid":"AllowDevTestToCreateSnapshot",
"Effect":"Allow",
"Action":[
"rds:CreateDBSnapshot"
],
"Resource":"arn:aws:rds:*:123456789012:db:*",
"Condition":{
"StringEquals":{
"rds:db-tag/stage":[
"development",
"test"
]
}
}
}
]
}
```
------
La seguente policy concede l'autorizzazione per eseguire l'operazione API `ModifyDBInstance` sulle istanze database con il tag `stage` impostato su `development` o `test`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AllowChangingParameterOptionSecurityGroups",
"Effect":"Allow",
"Action":[
"rds:ModifyDBInstance"
],
"Resource": [
"arn:aws:rds:*:123456789012:pg:*",
"arn:aws:rds:*:123456789012:secgrp:*",
"arn:aws:rds:*:123456789012:og:*"
]
},
{
"Sid":"AllowDevTestToModifyInstance",
"Effect":"Allow",
"Action":[
"rds:ModifyDBInstance"
],
"Resource":"arn:aws:rds:*:123456789012:db:*",
"Condition":{
"StringEquals":{
"rds:db-tag/stage":[
"development",
"test"
]
}
}
}
]
}
```
------
### Esempio 2: Rifiuto esplicito dell'autorizzazione per creare un'istanza database che utilizza gruppi di parametri database specificati
La policy seguente rifiuta in modo esplicito l'autorizzazione per creare un'istanza database che utilizza gruppi di parametri database con valori di tag specifici. Puoi applicare questa policy se desideri che uno specifico gruppo di parametri database creato dal cliente venga sempre utilizzato nella creazione di istanze database. Le policy che utilizzano `Deny` servono per lo più a limitare l'accesso concesso da una policy più ampia.
Il rifiuto esplicito di un'autorizzazione prevale su qualsiasi altra autorizzazione concessa. In questo modo si evita che le identità ottengano accidentalmente un'autorizzazione che non desideravi concedere.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"DenyProductionCreate",
"Effect":"Deny",
"Action":"rds:CreateDBInstance",
"Resource":"arn:aws:rds:*:123456789012:pg:*",
"Condition":{
"StringEquals":{
"rds:pg-tag/usage":"prod"
}
}
}
]
}
```
------
### Esempio 3: Concessione dell'autorizzazione per le operazioni in un'istanza database con un nome di istanza che ha come prefisso un nome utente
La policy seguente concede l'autorizzazione per chiamare qualsiasi API (ad eccezione di `AddTagsToResource` o `RemoveTagsFromResource`) in un'istanza database con un nome di istanza che ha come prefisso il nome dell'utente e che dispone di un tag denominato `stage` equivalente a `devo` o che non dispone di un tag `stage`.
La riga `Resource` nella policy identifica una risorsa in base al relativo Amazon Resource Name (ARN). Per ulteriori informazioni sull'utilizzo ARNs con le risorse Amazon Aurora, consulta. [Nome della risorsa Amazon (ARN) in Amazon RDS](USER_Tagging.ARN.md)
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AllowFullDevAccessNoTags",
"Effect":"Allow",
"NotAction":[
"rds:AddTagsToResource",
"rds:RemoveTagsFromResource"
],
"Resource":"arn:aws:rds:*:123456789012:db:${aws:username}*",
"Condition":{
"StringEqualsIfExists":{
"rds:db-tag/stage":"devo"
}
}
}
]
}
```
------
# Concessione dell’autorizzazione all’applicazione di tag Aurora per le risorse durante la creazione
Alcune operazioni dell’API RDS consentono di specificare tag al momento della creazione delle risorse. È possibile utilizzare i tag delle risorse per implementare il controllo basato sugli attributi (ABAC). Per ulteriori informazioni, consulta A [cosa serve ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)? AWS e [Controllo dell'accesso alle AWS risorse tramite tag](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html).
Per essere abilitati a taggare le risorse in fase di creazione, gli utenti devono disporre delle autorizzazioni per utilizzare l’azione che crea la risorsa, ad esempio `rds:CreateDBCluster`. Se i tag vengono specificati nell’azione di creazione, RDS implementa autorizzazioni aggiuntive per l’azione `rds:AddTagsToResource` al fine di verificare se gli utenti dispongono delle autorizzazioni per creare tag. Pertanto, gli utenti devono disporre anche di autorizzazioni esplicite a utilizzare l’azione `rds:AddTagsToResource`.
Nella definizione della policy IAM per l’azione `rds:AddTagsToResource`, è possibile utilizzare la chiave di condizione `aws:RequestTag` per richiedere tag in una richiesta di applicare tag a una risorsa.
Ad esempio, la seguente policy consente agli utenti di creare istanze database e applicare tag durante la creazione di un’istanza database, ma solo con chiavi di tag specifiche (`environment` o `project`):
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds:CreateDBInstance"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"rds:AddTagsToResource"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/environment": ["production", "development"],
"aws:RequestTag/project": ["dataanalytics", "webapp"]
},
"ForAllValues:StringEquals": {
"aws:TagKeys": ["environment", "project"]
}
}
}
]
}
```
------
Questa policy respinge qualsiasi richiesta di creazione di istanza database che includa tag diversi dai tag `environment` o `project` oppure che non specifichi nessuno di questi tag. Inoltre, gli utenti devono specificare i valori per i tag che corrispondono ai valori consentiti nella policy.
La seguente policy consente gli utenti di creare cluster di database e applicare tag durante la creazione ad eccezione del tag `environment=prod`:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds:CreateDBCluster"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"rds:AddTagsToResource"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestTag/environment": "prod"
}
}
}
]
}
```
------
## Azioni API RDS supportate per l’applicazione di tag in fase di creazione
Le seguenti azioni dell’API RDS supportano l’applicazione di tag durante la creazione di una risorsa. Per queste azioni, puoi specificare i tag al momento della creazione della risorsa:
+ `CreateBlueGreenDeployment`
+ `CreateCustomDBEngineVersion`
+ `CreateDBCluster`
+ `CreateDBClusterEndpoint`
+ `CreateDBClusterParameterGroup`
+ `CreateDBClusterSnapshot`
+ `CreateDBInstance`
+ `CreateDBInstanceReadReplica`
+ `CreateDBParameterGroup`
+ `CreateDBProxy`
+ `CreateDBProxyEndpoint`
+ `CreateDBSecurityGroup`
+ `CreateDBShardGroup`
+ `CreateDBSnapshot`
+ `CreateDBSubnetGroup`
+ `CreateEventSubscription`
+ `CreateGlobalCluster`
+ `CreateIntegration`
+ `CreateOptionGroup`
+ `CreateTenantDatabase`
+ `CopyDBClusterParameterGroup`
+ `CopyDBClusterSnapshot`
+ `CopyDBParameterGroup`
+ `CopyDBSnapshot`
+ `CopyOptionGroup`
+ `RestoreDBClusterFromS3`
+ `RestoreDBClusterFromSnapshot`
+ `RestoreDBClusterToPointInTime`
+ `RestoreDBInstanceFromDBSnapshot`
+ `RestoreDBInstanceFromS3`
+ `RestoreDBInstanceToPointInTime`
+ `PurchaseReservedDBInstancesOffering`
Se si utilizza l'API AWS CLI or per creare una risorsa con tag, il `Tags` parametro viene utilizzato per applicare i tag alle risorse durante la creazione.
Per queste azioni dell’API, se l’applicazione di tag non riesce, la risorsa non viene creata, la richiesta ha esito negativo e viene restituito un errore. Questo garantisce che le risorse vengano create con i tag o che non vengano create affatto, impedendo così la creazione di risorse senza i tag previsti.
# AWS politiche gestite per Amazon RDS
Per aggiungere autorizzazioni ai set di autorizzazioni e ai ruoli, è più facile utilizzare politiche AWS gestite piuttosto che scrivere politiche da soli. La [creazione di policy gestite dai clienti IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) che forniscono al team solo le autorizzazioni di cui ha bisogno richiede tempo e competenza. Per iniziare rapidamente, puoi utilizzare le nostre politiche AWS gestite. Queste policy coprono i casi d’uso comuni e sono disponibili nell’account Account AWS. Per ulteriori informazioni sulle policy AWS gestite, consulta le [policy AWS gestite](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) nella *IAM User Guide*.
Servizi AWS mantenere e aggiornare le politiche AWS gestite. Non è possibile modificare le autorizzazioni nelle politiche AWS gestite. I servizi aggiungono occasionalmente autorizzazioni aggiuntive a una policy AWS gestita per supportare nuove funzionalità. Questo tipo di aggiornamento interessa tutte le identità (set di autorizzazioni e ruoli) a cui è collegata la policy. È più probabile che i servizi aggiornino una politica AWS gestita quando viene lanciata una nuova funzionalità o quando diventano disponibili nuove operazioni. I servizi non rimuovono le autorizzazioni da una policy AWS gestita, quindi gli aggiornamenti delle policy non compromettono le autorizzazioni esistenti.
Inoltre, AWS supporta politiche gestite per le funzioni lavorative che si estendono su più servizi. Ad esempio, la policy `ReadOnlyAccess` AWS gestita fornisce l'accesso in sola lettura a tutte le Servizi AWS risorse. Quando un servizio lancia una nuova funzionalità, AWS aggiunge autorizzazioni di sola lettura per nuove operazioni e risorse. Per l’elenco e la descrizione delle policy di funzione dei processi, consultare la sezione [Policy gestite da AWS per funzioni di processi](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) nella *Guida per l’utente di IAM*.
**Topics**
+ [AWS politica gestita: Amazon RDSRead OnlyAccess](#rds-security-iam-awsmanpol-AmazonRDSReadOnlyAccess)
+ [AWS politica gestita: Amazon RDSFull Access](#rds-security-iam-awsmanpol-AmazonRDSFullAccess)
+ [AWS politica gestita: Amazon RDSData FullAccess](#rds-security-iam-awsmanpol-AmazonRDSDataFullAccess)
+ [AWS politica gestita: Amazon RDSEnhanced MonitoringRole](#rds-security-iam-awsmanpol-AmazonRDSEnhancedMonitoringRole)
+ [AWS politica gestita: Amazon RDSPerformance InsightsReadOnly](#rds-security-iam-awsmanpol-AmazonRDSPerformanceInsightsReadOnly)
+ [AWS politica gestita: Amazon RDSPerformance InsightsFullAccess](#rds-security-iam-awsmanpol-AmazonRDSPerformanceInsightsFullAccess)
+ [AWS politica gestita: Amazon RDSDirectory ServiceAccess](#rds-security-iam-awsmanpol-AmazonRDSDirectoryServiceAccess)
+ [AWS politica gestita: Amazon RDSService RolePolicy](#rds-security-iam-awsmanpol-AmazonRDSServiceRolePolicy)
+ [AWS politica gestita: Amazon RDSPreview ServiceRolePolicy](#rds-security-iam-awsmanpol-AmazonRDSPreviewServiceRolePolicy)
+ [AWS politica gestita: Amazon RDSBeta ServiceRolePolicy](#rds-security-iam-awsmanpol-AmazonRDSBetaServiceRolePolicy)
## AWS politica gestita: Amazon RDSRead OnlyAccess
Questa policy consente l'accesso in sola lettura ad Amazon RDS tramite. Console di gestione AWS
**Dettagli delle autorizzazioni**
Questa policy include le seguenti autorizzazioni:
+ `rds`: consente ai principali di descrivere le risorse Amazon RDS e di elencare i tag per le risorse Amazon RDS.
+ `cloudwatch`— Consente ai mandanti di ottenere statistiche sui CloudWatch parametri di Amazon.
+ `ec2`: consente ai principali di descrivere le zone di disponibilità e le risorse di rete.
+ `logs`— Consente ai responsabili di descrivere CloudWatch Logs, i flussi di log dei gruppi di log e di ottenere gli eventi di log di Logs. CloudWatch
+ `devops-guru`— Consente ai responsabili di descrivere le risorse che hanno una copertura Amazon DevOps Guru, specificata dai nomi degli CloudFormation stack o dai tag delle risorse.
Per ulteriori informazioni su questa politica, incluso il documento sulla politica JSON, consulta [Amazon RDSRead OnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSReadOnlyAccess.html) nella *AWS Managed Policy Reference Guide*.
## AWS politica gestita: Amazon RDSFull Access
Questa policy fornisce l'accesso completo ad Amazon RDS tramite. Console di gestione AWS
**Dettagli delle autorizzazioni**
Questa policy include le seguenti autorizzazioni:
+ `rds`: consente ai principali l'accesso completo ad Amazon RDS.
+ `application-autoscaling`: consente ai principali di descrivere e gestire gli obiettivi e le policy di dimensionamento di Application Auto Scaling.
+ `cloudwatch`— Consente ai responsabili di ottenere statistiche CloudWatch metriche e gestire gli allarmi. CloudWatch
+ `ec2`: consente ai principali di descrivere le zone di disponibilità e le risorse di rete.
+ `logs`— Consente ai responsabili di descrivere CloudWatch Logs, log, flussi di log dei gruppi di log e ottenere gli eventi di log di Logs. CloudWatch
+ `outposts`— Consente ai principali di ottenere i tipi di istanza. AWS Outposts
+ `pi`: consente ai principali di ottenere i parametri di Performance Insights.
+ `sns`: consente ai principali di accedere a iscrizioni e argomenti Amazon Simple Notification Service (Amazon SNS) e di pubblicare messaggi Amazon SNS.
+ `devops-guru`— Consente ai responsabili di descrivere le risorse che hanno una copertura Amazon DevOps Guru, specificata dai nomi degli CloudFormation stack o dai tag delle risorse.
Per ulteriori informazioni su questa politica, incluso il documento sulla politica JSON, consulta [Amazon RDSFull Access](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSFullAccess.html) nella *AWS Managed Policy Reference Guide*.
## AWS politica gestita: Amazon RDSData FullAccess
Questa politica consente l'accesso completo all'utilizzo della Data API e dell'editor di query sui Aurora Serverless cluster in uno specifico Account AWS. Questa politica consente di Account AWS ottenere il valore di un segreto da Gestione dei segreti AWS.
È possibile allegare la policy `AmazonRDSDataFullAccess` alle identità IAM.
**Dettagli delle autorizzazioni**
Questa policy include le seguenti autorizzazioni:
+ `dbqms`: consente ai principali di accedere, creare, eliminare, descrivere e aggiornare le query. Il Database Query Metadata Service (`dbqms`) è un servizio solo interno. Fornisce le tue query recenti e salvate per l'editor di query su Console di gestione AWS for multiple Servizi AWS, incluso Amazon RDS.
+ `rds-data`: consente ai principali di eseguire istruzioni SQL su database Aurora Serverless.
+ `secretsmanager`— Consente ai mandanti di ottenere il valore di un segreto da. Gestione dei segreti AWS
Per ulteriori informazioni su questa politica, incluso il documento sulla politica JSON, consulta [Amazon RDSData FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSDataFullAccess.html) nella *AWS Managed Policy Reference Guide*.
## AWS politica gestita: Amazon RDSEnhanced MonitoringRole
Questa policy fornisce l'accesso ad Amazon CloudWatch Logs for Amazon RDS Enhanced Monitoring.
**Dettagli delle autorizzazioni**
Questa policy include le seguenti autorizzazioni:
+ `logs`— Consente ai responsabili di creare CloudWatch Logs, gruppi di log e politiche di conservazione e di creare e descrivere i flussi di log CloudWatch Logs dei gruppi di log. Consente inoltre ai responsabili di inserire e ottenere gli eventi di log dei Logs. CloudWatch
Per ulteriori informazioni su questa politica, incluso il documento sulla politica JSON, consulta [Amazon RDSEnhanced MonitoringRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSEnhancedMonitoringRole.html) nella *AWS Managed Policy Reference Guide*.
## AWS politica gestita: Amazon RDSPerformance InsightsReadOnly
Questa policy fornisce accesso in sola lettura alle istanze Amazon RDS Performance Insights per istanze database Amazon RDS e cluster di database Amazon Aurora.
Questa policy ora include `Sid` (ID istruzione) come identificativo per l'istruzione della policy.
**Dettagli delle autorizzazioni**
Questa policy include le seguenti autorizzazioni:
+ `rds`: consente ai principali di descrivere le istanze database Amazon RDS e i cluster di database Amazon Aurora.
+ `pi`: consente ai principali di effettuare chiamate all'API Amazon RDS Performance Insights e accedere ai parametri di Performance Insights.
Per ulteriori informazioni su questa politica, incluso il documento sulla politica JSON, consulta [Amazon RDSPerformance InsightsReadOnly](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSPerformanceInsightsReadOnly.html) nella *AWS Managed Policy Reference Guide*.
## AWS politica gestita: Amazon RDSPerformance InsightsFullAccess
Questa policy fornisce l'accesso completo ad Approfondimenti sulle prestazioni di Amazon RDS per istanze database Amazon RDS e cluster database Amazon Aurora.
Questa policy ora include `Sid` (ID istruzione) come identificativo per l'istruzione della policy.
**Dettagli delle autorizzazioni**
Questa policy include le seguenti autorizzazioni:
+ `rds`: consente ai principali di descrivere le istanze database Amazon RDS e i cluster di database Amazon Aurora.
+ `pi`: consente ai principali di effettuare chiamate all'API Approfondimenti sulle prestazioni di Amazon RDS e di creare, visualizzare ed eliminare report di analisi delle prestazioni.
+ `cloudwatch`— Consente ai responsabili di elencare tutte le CloudWatch metriche di Amazon e ottenere dati e statistiche sui parametri.
Per ulteriori informazioni su questa politica, incluso il documento sulla politica JSON, consulta [Amazon RDSPerformance InsightsFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSPerformanceInsightsFullAccess.html) nella *AWS Managed Policy Reference Guide*.
## AWS politica gestita: Amazon RDSDirectory ServiceAccess
Questa policy permette ad Amazon RDS di effettuare chiamate alla Directory Service.
**Dettagli delle autorizzazioni**
Questa policy include la seguente autorizzazione:
+ `ds`— Consente ai responsabili di descrivere le Directory Service directory e di controllare l'autorizzazione alle Directory Service directory.
Per ulteriori informazioni su questa politica, incluso il documento sulla politica JSON, consulta [Amazon RDSDirectory ServiceAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSDirectoryServiceAccess.html) nella *AWS Managed Policy Reference Guide*.
## AWS politica gestita: Amazon RDSService RolePolicy
Non è possibile allegare la policy `AmazonRDSServiceRolePolicy` alle entità IAM. Questa policy è allegata a un ruolo collegato ai servizi che consente ad Amazon RDS di eseguire operazioni per conto dell'utente. Per ulteriori informazioni, consulta [Autorizzazioni del ruolo collegato ai servizi per Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions).
## AWS politica gestita: Amazon RDSPreview ServiceRolePolicy
Non bisogna collegare `AmazonRDSPreviewServiceRolePolicy` alle entità IAM. Questa policy è associata a un ruolo collegato al servizio che consente ad Amazon RDS di chiamare i AWS servizi per conto delle tue risorse DB RDS. Per ulteriori informazioni, consulta [Ruolo collegato ai servizi per Amazon RDS Preview](UsingWithRDS.IAM.ServiceLinkedRoles.md#slr-permissions-rdspreview).
**Dettagli delle autorizzazioni**
Questa policy include le seguenti autorizzazioni:
+ `ec2`: consente ai principali di descrivere le zone di disponibilità e le risorse di rete.
+ `secretsmanager`— Consente ai responsabili di ottenere il valore di un segreto da. Gestione dei segreti AWS
+ `cloudwatch`, `logs` ‐ Consente ad Amazon RDS di caricare i parametri e i log delle istanze DB tramite agente. CloudWatch CloudWatch
Per ulteriori informazioni su questa politica, incluso il documento sulla politica JSON, consulta [Amazon RDSPreview ServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSPreviewServiceRolePolicy.html) nella *AWS Managed Policy Reference Guide*.
## AWS politica gestita: Amazon RDSBeta ServiceRolePolicy
Non bisogna collegare `AmazonRDSBetaServiceRolePolicy` alle entità IAM. Questa policy è associata a un ruolo collegato al servizio che consente ad Amazon RDS di chiamare i AWS servizi per conto delle tue risorse DB RDS. Per ulteriori informazioni, consulta [Autorizzazioni del ruolo collegato ai servizi per Amazon RDS Beta](UsingWithRDS.IAM.ServiceLinkedRoles.md#slr-permissions-rdsbeta).
**Dettagli delle autorizzazioni**
Questa policy include le seguenti autorizzazioni:
+ `ec2`‐ Consente ad Amazon RDS di eseguire operazioni di backup sull'istanza DB che fornisce funzionalità di point-in-time ripristino.
+ `secretsmanager`: consente ad Amazon RDS di gestire i segreti specifici delle istanze database creati da Amazon RDS.
+ `cloudwatch`, `logs` ‐ Consente ad Amazon RDS di caricare i parametri e i log delle istanze DB tramite agente. CloudWatch CloudWatch
Per ulteriori informazioni su questa politica, incluso il documento sulla politica JSON, consulta [Amazon RDSBeta ServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSBetaServiceRolePolicy.html) nella *AWS Managed Policy Reference Guide*.
# Aggiornamenti di Amazon RDS sulle policy gestite da AWS
Visualizza i dettagli sugli aggiornamenti alle policy gestite da AWS per Amazon RDS da quando questo servizio ha iniziato a tenere traccia delle modifiche. Per gli avvisi automatici sulle modifiche apportate a questa pagina, sottoscrivere il feed RSS nella pagina di [Cronologia dei documenti](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/WhatsNew.html) di Amazon RDS.
| Modifica | Descrizione | Data |
| --- | --- | --- |
| [AWS politica gestita: Amazon RDSPreview ServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSPreviewServiceRolePolicy): aggiornamento a policy esistente | Amazon RDS ha rimosso l’autorizzazione `sns:Publish` dalla policy `AmazonRDSPreviewServiceRolePolicy` del ruolo collegato al servizio `AWSServiceRoleForRDSPreview`. Per ulteriori informazioni, consulta [AWS politica gestita: Amazon RDSPreview ServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSPreviewServiceRolePolicy). | 7 agosto 2024 |
| [AWS politica gestita: Amazon RDSBeta ServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSBetaServiceRolePolicy): aggiornamento a policy esistente | Amazon RDS ha rimosso l’autorizzazione `sns:Publish` dalla policy `AmazonRDSBetaServiceRolePolicy` del ruolo collegato al servizio `AWSServiceRoleForRDSBeta`. Per ulteriori informazioni, consulta [AWS politica gestita: Amazon RDSBeta ServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSBetaServiceRolePolicy). | 7 agosto 2024 |
| [AWS politica gestita: Amazon RDSService RolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSServiceRolePolicy): aggiornamento a policy esistente | Amazon RDS ha rimosso l’autorizzazione `sns:Publish` dalla policy `AmazonRDSServiceRolePolicy` del ruolo collegato al servizio ` AWSServiceRoleForRDS`. Per ulteriori informazioni, consulta [AWS politica gestita: Amazon RDSService RolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSServiceRolePolicy). | 2 luglio 2024 |
| [AWS politiche gestite per Amazon RDS](rds-security-iam-awsmanpol.md): aggiornamento a policy esistente | Amazon RDS ha aggiunto una nuova autorizzazione alla policy `AmazonRDSCustomServiceRolePolicy` del ruolo collegato al servizio `AWSServiceRoleForRDSCustom` per consentire a RDS Custom per SQL Server di modificare il tipo di istanza host del database sottostante. RDS ha inoltre aggiunto l’autorizzazione `ec2:DescribeInstanceTypes` per ottenere informazioni sul tipo di istanza per l’host del database. Per ulteriori informazioni, consulta [AWS politiche gestite per Amazon RDS](rds-security-iam-awsmanpol.md). | 8 aprile 2024 |
| [AWS politiche gestite per Amazon RDS](rds-security-iam-awsmanpol.md): nuova policy | Amazon RDS ha aggiunto una nuova policy gestita denominata AmazonRDSCustomInstanceProfileRolePolicy per consentire a RDS Custom di eseguire azioni di automazione e attività di gestione del database tramite un profilo dell’istanza EC2. Per ulteriori informazioni, consulta [AWS politiche gestite per Amazon RDS](rds-security-iam-awsmanpol.md). | 27 febbraio 2024 |
| [Autorizzazioni del ruolo collegato ai servizi per Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions): aggiornamento a una policy esistente | Amazon RDS ha aggiunto nuovi ID istruzione alla policy `AmazonRDSServiceRolePolicy` del ruolo collegato al servizio `AWSServiceRoleForRDS`. Per ulteriori informazioni, consulta [Autorizzazioni del ruolo collegato ai servizi per Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions). | 19 gennaio 2024 |
| [AWS politiche gestite per Amazon RDS](rds-security-iam-awsmanpol.md): aggiornamento a policy esistenti | Le policy gestite `AmazonRDSPerformanceInsightsReadOnly` e `AmazonRDSPerformanceInsightsFullAccess` ora includono `Sid` (ID istruzione) come identificativo nell'istruzione della policy. Per ulteriori informazioni, consulta [AWS politica gestita: Amazon RDSPerformance InsightsReadOnly](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSPerformanceInsightsReadOnly) e [AWS politica gestita: Amazon RDSPerformance InsightsFullAccess](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSPerformanceInsightsFullAccess). | 23 ottobre 2023 |
| [AWS politiche gestite per Amazon RDS](rds-security-iam-awsmanpol.md): aggiornamento a policy esistente | Amazon RDS ha aggiunto nuove autorizzazioni alla policy gestita `AmazonRDSFullAccess`. Le autorizzazioni consentono di generare, visualizzare ed eliminare il report di analisi delle prestazioni per un periodo di tempo. Per ulteriori informazioni sulla configurazione delle policy di accesso per Performance Insights, consulta [Configurazione delle policy di accesso per Performance Insights](USER_PerfInsights.access-control.md) | 17 agosto 2023 |
| [AWS politiche gestite per Amazon RDS](rds-security-iam-awsmanpol.md): nuova policy e aggiornamento a una policy esistente | Amazon RDS ha aggiunto nuove autorizzazioni alla policy gestita `AmazonRDSPerformanceInsightsReadOnly`e una nuova policy gestita denominata `AmazonRDSPerformanceInsightsFullAccess`. Queste autorizzazioni consentono di analizzare Performance Insights per un periodo di tempo, visualizzare i risultati dell'analisi insieme ai suggerimenti ed eliminare i report. Per ulteriori informazioni sulla configurazione delle policy di accesso per Performance Insights, consulta [Configurazione delle policy di accesso per Performance Insights](USER_PerfInsights.access-control.md) | 16 agosto 2023 |
| [AWS politiche gestite per Amazon RDS](rds-security-iam-awsmanpol.md): aggiornamento a una policy esistente | Amazon RDS ha aggiunto un nuovo spazio dei nomi Amazon CloudWatch `ListMetrics` a `AmazonRDSFullAccess` e `AmazonRDSReadOnlyAccess`. Questo spazio dei nomi è necessario affinché Amazon RDS elenchi specifici parametri di utilizzo delle risorse. Per ulteriori informazioni, consulta [Panoramica sulla gestione delle autorizzazioni di accesso alle risorse CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/iam-access-control-overview-cw.html) nella *Guida per l'utente di Amazon CloudWatch*. | 4 aprile 2023 |
| [Autorizzazioni del ruolo collegato ai servizi per Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions): aggiornamento a una policy esistente | Amazon RDS ha aggiunto nuove autorizzazioni alla `AmazonRDSServiceRolePolicy` del ruolo collegato al servizio `AWSServiceRoleForRDS` per l'integrazione con Gestione dei segreti AWS. RDS richiede l'integrazione con Secrets Manager per la gestione delle password degli utenti master in Secrets Manager. Il segreto utilizza una convenzione di denominazione riservata e limita gli aggiornamenti del cliente. Per ulteriori informazioni, consulta [Gestione delle password con Amazon Aurora e Gestione dei segreti AWS](rds-secrets-manager.md). | 22 dicembre 2022 |
| [AWS politiche gestite per Amazon RDS](rds-security-iam-awsmanpol.md): aggiornamento a policy esistenti | Amazon RDS ha aggiunto una nuova autorizzazione alle policy gestite `AmazonRDSFullAccess` e `AmazonRDSReadOnlyAccess` per consentire di attivare Amazon DevOps Guru nella console RDS. Questa autorizzazione è necessaria per verificare se DevOps Guru è attivato. Per ulteriori informazioni, consulta [Configurazione delle politiche di accesso IAM per Guru for RDS DevOps](devops-guru-for-rds.md#devops-guru-for-rds.configuring.access). | 19 dicembre 2022 |
| [Autorizzazioni del ruolo collegato ai servizi per Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions): aggiornamento a una policy esistente | Amazon RDS ha aggiunto un nuovo spazio dei nomi Amazon CloudWatch ad `AmazonRDSPreviewServiceRolePolicy` per `PutMetricData`. Questo spazio dei nomi è necessario affinché Amazon RDS pubblichi i parametri di utilizzo delle risorse. Per ulteriori informazioni, consultare [Utilizzo delle chiavi di condizione per limitare l’accesso agli spazi dei nomi di CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/iam-cw-condition-keys-namespace.html) nella *Guida per l’utente di Amazon CloudWatch*. | 7 luglio 2022 |
| [Autorizzazioni del ruolo collegato ai servizi per Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions): aggiornamento a una policy esistente | Amazon RDS ha aggiunto un nuovo spazio dei nomi Amazon CloudWatch ad `AmazonRDSBetaServiceRolePolicy` per `PutMetricData`. Questo spazio dei nomi è necessario affinché Amazon RDS pubblichi i parametri di utilizzo delle risorse. Per ulteriori informazioni, consultare [Utilizzo delle chiavi di condizione per limitare l’accesso agli spazi dei nomi di CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/iam-cw-condition-keys-namespace.html) nella *Guida per l’utente di Amazon CloudWatch*. | 7 luglio 2022 |
| [Autorizzazioni del ruolo collegato ai servizi per Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions): aggiornamento a una policy esistente | Amazon RDS ha aggiunto un nuovo spazio dei nomi Amazon CloudWatch ad `AWSServiceRoleForRDS` per `PutMetricData`. Questo spazio dei nomi è necessario affinché Amazon RDS pubblichi i parametri di utilizzo delle risorse. Per ulteriori informazioni, consultare [Utilizzo delle chiavi di condizione per limitare l’accesso agli spazi dei nomi di CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/iam-cw-condition-keys-namespace.html) nella *Guida per l’utente di Amazon CloudWatch*. | 22 aprile 2022 |
| [AWS politiche gestite per Amazon RDS](rds-security-iam-awsmanpol.md): nuova policy | Amazon RDS ha aggiunto una nuova policy gestita denominata `AmazonRDSPerformanceInsightsReadOnly` per consentire ad Amazon RDS di chiamare i servizi AWS per conto delle istanze database. Per ulteriori informazioni sulla configurazione delle policy di accesso per Performance Insights, consulta [Configurazione delle policy di accesso per Performance Insights](USER_PerfInsights.access-control.md) | 10 marzo 2022 |
| [Autorizzazioni del ruolo collegato ai servizi per Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions): aggiornamento a una policy esistente | Amazon RDS ha aggiunto nuovi namespace Amazon CloudWatch a `AWSServiceRoleForRDS` per `PutMetricData`. Questi spazi dei nomi servono ad Amazon DocumentDB (con compatibilità MongoDB) e Amazon Neptune per pubblicare i parametri di CloudWatch. Per ulteriori informazioni, consultare [Utilizzo delle chiavi di condizione per limitare l’accesso agli spazi dei nomi di CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/iam-cw-condition-keys-namespace.html) nella *Guida per l’utente di Amazon CloudWatch*. | 4 marzo 2022 |
| Amazon RDS ha iniziato a monitorare le modifiche | Amazon RDS ha iniziato a tenere traccia delle modifiche per le sue policy gestite da AWS. | 26 ottobre 2021 |
# Prevenzione del problema "confused deputy" tra servizi
Il *problema confused deputy* è un problema di sicurezza in cui un’entità che non dispone dell’autorizzazione per eseguire un’azione può costringere un’entità maggiormente privilegiata a eseguire l’azione. InoltreAWS, l'impersonificazione tra diversi servizi può portare alla confusione del vicesceriffo.
La rappresentazione tra servizi può verificarsi quando un servizio (il *servizio chiamante*) effettua una chiamata a un altro servizio (il *servizio chiamato*). Il servizio chiamante può essere manipolato per utilizzare le proprie autorizzazioni e agire sulle risorse di un altro cliente, a cui normalmente non avrebbe accesso. Per evitare che ciò accada, AWS fornisce strumenti che possono aiutarvi a proteggere i vostri dati per tutti i servizi, con responsabili del servizio a cui è stato concesso l'accesso alle risorse del vostro account. Per ulteriori informazioni, consultare [Problema del "confused deputy"](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) nella *Guida per l'utente di IAM*.
Per limitare le autorizzazioni alle risorse che Amazon RDS fornisce a un altro servizio per una risorsa specifica, si consiglia di utilizzare le chiavi di contesto delle condizioni globali [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) e [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) nelle policy delle risorse.
In alcuni casi, il valore `aws:SourceArn` non contiene l'ID dell'account, ad esempio quando utilizzi Amazon Resource Name (ARN) per un bucket Simple Storage Service (Amazon S3). In questi casi, assicurati di utilizzare entrambe le chiavi di contesto delle condizioni globali per limitare le autorizzazioni. In alcuni casi, si utilizzano le chiavi di contesto delle condizioni globali e il valore `aws:SourceArn` contiene l'ID dell'account. In questi casi, assicurati che il valore `aws:SourceAccount` e l'account in `aws:SourceArn` utilizzano lo stesso ID dell'account quando vengono utilizzati nella stessa dichiarazione di policy. Utilizza `aws:SourceArn` se desideri consentire l'associazione di una sola risorsa all'accesso tra servizi. Se desideri consentire l'associazione di qualsiasi risorsa nell'AWSaccount specificato all'utilizzo tra servizi, utilizza. `aws:SourceAccount`
Assicurati che il valore di `aws:SourceArn` sia un ARN per un tipo di risorsa Amazon RDS. Per ulteriori informazioni, consulta [Nome della risorsa Amazon (ARN) in Amazon RDS](USER_Tagging.ARN.md).
Il modo più efficace per proteggersi dal problema "confused deputy" è quello di usare la chiave di contesto della condizione globale `aws:SourceArn` con l'ARN completo della risorsa. In alcuni casi, potresti non conoscere l'ARN completo della risorsa o potresti specificare più risorse. In questi casi, utilizza la chiave di contesto delle condizioni globali `aws:SourceArn` con caratteri jolly (`*`) per le parti sconosciute dell'ARN. Un esempio è `arn:aws:rds:*:123456789012:*`.
L'esempio seguente mostra il modo in cui puoi utilizzare le chiavi di contesto `aws:SourceArn` e `aws:SourceAccount` delle condizioni globali in Amazon RDS per prevenire il problema “confused deputy”.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Sid": "ConfusedDeputyPreventionExamplePolicy",
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:rds:us-east-1:123456789012:db:mydbinstance"
},
"StringEquals": {
"aws:SourceAccount": "123456789012"
}
}
}
}
```
------
Per altri esempi di policy che utilizzano le chiavi di contesto delle condizioni globali `aws:SourceArn` e `aws:SourceAccount`, consulta le sezioni seguenti:
+ [Concessione di autorizzazioni per pubblicare le notifiche in un argomento Amazon SNS](USER_Events.GrantingPermissions.md)
+ [Configurazione dell'accesso a un bucket Simple Storage Service (Amazon S3)](USER_PostgreSQL.S3Import.AccessPermission.md) (importazione PostgreSQL)
+ [Configurazione dell'accesso a un bucket Amazon S3](postgresql-s3-export-access-bucket.md) (esportazione PostgreSQL)
# Autenticazione del database IAM
Puoi autenticarti nel tuo cluster di DB utilizzando l'autenticazione del database AWS Identity and Access Management (IAM). L'autenticazione del database IAM funziona con Aurora MySQL e Aurora PostgreSQL. Con questo metodo di autenticazione, non devi utilizzare una password quando esegui la connessione al cluster database. Utilizzi invece un token di autenticazione.
Un *token di autenticazione* è una stringa univoca di caratteri generata da Amazon Aurora su richiesta. I token di autenticazione vengono generati utilizzando la versione 4 di AWS Signature. Ciascun token ha un ciclo di vita di 15 minuti. Non devi archiviare le credenziali dell'utente nel database, perché l'autenticazione è gestita esternamente utilizzando IAM. Puoi anche utilizzare ancora l'autenticazione standard del database. Il token viene utilizzato solo per l'autenticazione e non influisce sulla sessione dopo che è stato stabilito.
L'autenticazione del database IAM fornisce i seguenti vantaggi:
+ Il traffico di rete da e verso il database viene crittografato utilizzando Secure Socket Layer (SSL) o Transport Layer Security (TLS). Per ulteriori informazioni sull'utilizzo SSL/TLS con Aurora, consulta. [Utilizzo SSL/TLS per crittografare una connessione a un'](UsingWithRDS.SSL.md)
+ Puoi usare IAM per gestire in modo centralizzato l'accesso alle risorse del database invece di gestire l'accesso singolarmente in ogni cluster database.
+ Per le applicazioni in esecuzione su Amazon EC2, puoi utilizzare le credenziali specifiche dell'istanza EC2 per accedere al database invece di una password, per maggiore sicurezza.
In generale, prendi in considerazione l'utilizzo dell'autenticazione del database IAM quando le applicazioni creano meno di 200 connessioni al secondo e non desideri gestire nomi utente e password direttamente nel codice dell'applicazione.
Il driver JDBC Amazon Web Services (AWS) supporta l’autenticazione del database IAM. Per ulteriori informazioni, consulta [AWS IAM Authentication Plugin](https://github.com/aws/aws-advanced-jdbc-wrapper/blob/main/docs/using-the-jdbc-driver/using-plugins/UsingTheIamAuthenticationPlugin.md) nel [repository di driver GitHub JDBC di Amazon Web Services (AWS)](https://github.com/aws/aws-advanced-jdbc-wrapper).
Il driver Python Amazon Web Services (AWS) supporta l’autenticazione del database IAM. Per ulteriori informazioni, consulta [AWS IAM Authentication Plugin](https://github.com/aws/aws-advanced-python-wrapper/blob/main/docs/using-the-python-driver/using-plugins/UsingTheIamAuthenticationPlugin.md) nel repository [Python Driver GitHub di Amazon Web Services (AWS)](https://github.com/aws/aws-advanced-python-wrapper).
Per apprendere il processo di impostazione di IAM per l’autenticazione del database, consulta i seguenti argomenti:
+ [Abilitazione e disabilitazione dell’autenticazione database IAM](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [Creazione e utilizzo di una policy IAM per l'accesso al database IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [Creazione di un account database tramite l’autenticazione IAM](UsingWithRDS.IAMDBAuth.DBAccounts.md)
+ [Connessione al cluster di database tramite l'autenticazione IAM](UsingWithRDS.IAMDBAuth.Connecting.md)
## Disponibilità di regioni e versioni
La disponibilità e il supporto della funzionalità varia a seconda delle versioni specifiche di ciascun motore di database Aurora e in tutte le Regioni AWS. Per ulteriori informazioni sulla disponibilità di versioni e Regioni per l'autenticazione del database Aurora e IAM, consulta [Regioni e motori di database Aurora supportati per l’autenticazione del database IAM](Concepts.Aurora_Fea_Regions_DB-eng.Feature.IAMdbauth.md).
Per Aurora MySQL, tutte le classi di istanza database supportate supportano l'autenticazione del database IAM, ad eccezione di db.t2.small e db.t3.small. Per informazioni sulle classi di istanza database supportate, consulta [Motori di database supportati per classi di istanza database](Concepts.DBInstanceClass.SupportAurora.md).
## Supporto per CLI e SDK
L'autenticazione del database IAM è disponibile per [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/rds/generate-db-auth-token.html)e per i seguenti linguaggi: AWS SDKs
+ [AWS SDK per .NET](https://docs.aws.amazon.com/sdkfornet/v3/apidocs/items/RDS/TRDSAuthTokenGenerator.html)
+ [AWS SDK per C\$1\$1](https://docs.aws.amazon.com/sdk-for-cpp/latest/api/class_aws_1_1_r_d_s_1_1_r_d_s_client.html#ae134ffffed5d7672f6156d324e7bd392)
+ [AWS SDK per Go](https://docs.aws.amazon.com/sdk-for-go/api/service/rds/#pkg-overview)
+ [AWS SDK per Java](https://docs.aws.amazon.com/sdk-for-java/latest/reference/software/amazon/awssdk/services/rds/RdsUtilities.html)
+ [AWS SDK per JavaScript](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/modules/_aws_sdk_rds_signer.html)
+ [AWS SDK per PHP](https://docs.aws.amazon.com/aws-sdk-php/v3/api/class-Aws.Rds.AuthTokenGenerator.html)
+ [AWS SDK per Python (Boto3)](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/rds.html#RDS.Client.generate_db_auth_token)
+ [AWS SDK per Ruby](https://docs.aws.amazon.com/sdk-for-ruby/v3/api/Aws/RDS/AuthTokenGenerator.html)
## Limitazioni per l'autenticazione database IAM
Quando utilizzi l'autenticazione database IAM, tieni presenti le seguenti limitazioni:
+ Attualmente, l'autenticazione database IAM non supporta nessuna delle chiavi di contesto delle condizioni globali.
Per ulteriori informazioni sulle chiavi di contesto delle condizioni globali, consulta [Chiavi di contesto delle condizioni globali AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) nella *Guida per l'utente di IAM*.
+ Per PostgreSQL, se il ruolo IAM (`rds_iam`) viene aggiunto a un utente (incluso l'utente principale RDS), l'autenticazione IAM ha la precedenza sull'autenticazione tramite password, quindi l'utente deve accedere come un utente IAM.
+ Non è possibile utilizzare un record DNS Route 53 personalizzato anziché l'endpoint del cluster di databaseper generare il token di autenticazione.
+ CloudWatch e CloudTrail non registrate l'autenticazione IAM. Questi servizi non tengono traccia delle chiamate API `generate-db-auth-token` che autorizzano il ruolo IAM a consentire la connessione al database.
+ L’autenticazione del database IAM richiede risorse di calcolo sul cluster di database. Per una connettività affidabile è necessario disporre di una memoria aggiuntiva compresa tra 300 e 1000 MiB nel database. Per individuare la memoria necessaria per il carico di lavoro, si confronta la colonna RES per i processi RDS nell’elenco dei processi di monitoraggio avanzato prima e dopo aver abilitato l’autenticazione del database IAM. Per informazioni, consulta [Visualizzazione delle metriche nella console RDS](USER_Monitoring.OS.Viewing.md).
Se si utilizza un’istanza di classe espandibile, evitare di esaurire la memoria riducendo della stessa quantità la memoria utilizzata da altri parametri, come buffer e cache.
+ Per Aurora MySQL, non è possibile utilizzare l'autenticazione basata su password per un utente del database configurato con l'autenticazione IAM.
+ L’autenticazione del database IAM non è supportata per RDS su Outposts per tutti i motori.
## Consigli per l'autenticazione del database IAM
Quando si utilizza l'autenticazione del database IAM, è consigliabile procedere come segue:
+ Utilizzare l'autenticazione del database IAM quando l'applicazione richiede meno di 200 nuove connessioni di autenticazione del database IAM al secondo.
I motori di database che funzionano con Amazon Aurora non prevedono limitazioni per i tentativi di autenticazione al secondo. Tuttavia, quando utilizzi un'autenticazione database IAM, l'applicazione deve generare un token di autenticazione. L'applicazione usa quindi il token per connettersi al cluster database. Se eccedi il limite massimo di nuove connessioni al secondo, la gestione extra dell'autenticazione database IAM può causare throttling della connessione.
Valuta la possibilità di utilizzare il pool di connessioni nelle applicazioni per mitigare la creazione continua di connessioni. Questo può ridurre il sovraccarico derivante dall'autenticazione DB IAM e consentire alle applicazioni di riutilizzare le connessioni esistenti. In alternativa, per questi casi d'uso considera l'utilizzo di Server proxy per RDS. Per Server proxy per RDS sono previsti costi aggiuntivi. Consulta i [prezzi per Server proxy per RDS](https://aws.amazon.com/rds/proxy/pricing/).
+ La dimensione di un token di autenticazione del database IAM dipende da molti fattori, tra cui il numero di tag IAM, le policy di servizio IAM, la lunghezza del nome della risorsa Amazon (ARN) e altre proprietà IAM e del database. La dimensione minima del token è generalmente di circa 1 KB, ma può essere maggiore. Poiché questo token viene utilizzato come password nella stringa di connessione al database mediante l'autenticazione IAM, è necessario assicurarsi che il driver del database (ad esempio ODBC) and/or non limiti o altrimenti tronchi questo token a causa delle sue dimensioni. Un token troncato causa l'esito negativo della convalida dell'autenticazione effettuata dal database e da IAM.
+ Se si utilizzano credenziali temporanee durante la creazione di un token di autenticazione del database IAM, le credenziali temporanee devono essere ancora valide quando si utilizza il token di autenticazione del database IAM per effettuare una richiesta di connessione.
## Chiavi di contesto relative alle condizioni globali non supportate AWS
L'autenticazione del database IAM non supporta il seguente sottoinsieme di chiavi di contesto delle condizioni AWS globali.
+ `aws:Referer`
+ `aws:SourceIp`
+ `aws:SourceVpc`
+ `aws:SourceVpce`
+ `aws:UserAgent`
+ `aws:VpcSourceIp`
Per ulteriori informazioni, consultare [Chiavi di contesto delle condizioni globali AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) nella *Guida per l'utente IAM*.
# Abilitazione e disabilitazione dell’autenticazione database IAM
Per impostazione predefinita, l’autenticazione database IAM è disabilitata nei cluster database. Puoi abilitare o disabilitare l'autenticazione del database IAM utilizzando Console di gestione AWS AWS CLI, o l'API.
Puoi abilitare l’autenticazione database IAM quando esegui una delle seguenti operazioni:
+ Per creare un nuovo cluster di database con l’autenticazione database IAM abilitata, consulta [Creazione di un cluster database Amazon Aurora](Aurora.CreateInstance.md).
+ Per modificare un cluster di database per abilitare l’autenticazione database IAM, consulta [Modifica di un cluster database Amazon Aurora](Aurora.Modifying.md).
+ Per ripristinare un cluster di database da uno snapshot con l’autenticazione del database IAM abilitata, consulta [Ripristino da uno snapshot cluster database](aurora-restore-snapshot.md).
+ Per ripristinare un cluster database a un momento specifico con l’autenticazione del database IAM abilitata, consulta [Ripristino di un cluster di database a un determinato momento](aurora-pitr.md).
## Console
Ogni flusso di lavoro di creazione o modifica include una sezione **Database authentication (Autenticazione database)** in cui puoi abilitare o disabilitare l’autenticazione database IAM. In questa sezione scegli **Password and IAM database authentication (Autenticazione password e database IAM)** per abilitare l’autenticazione database IAM.
**Per abilitare o disabilitare l’autenticazione database IAM per un cluster di database esistente**
1. Aprire 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 cluster database che si vuole modificare.
**Nota**
Puoi abilitare l’autenticazione IAM solo se tutte le istanze database nel cluster di database sono compatibili con IAM. Controllare i requisiti di compatibilità in [Disponibilità di regioni e versioni](UsingWithRDS.IAMDBAuth.md#UsingWithRDS.IAMDBAuth.Availability).
1. Scegliere **Modify (Modifica)**.
1. Nella sezione **Autenticazione del database**, scegli Autenticazione del **database IAM per abilitare l'**autenticazione del database IAM. Scegli **Autenticazione password** o **Autenticazione di password e Kerberos** per disabilitare l’autenticazione IAM.
1. Puoi anche scegliere di abilitare la pubblicazione dei log di autenticazione IAM DB su Logs. CloudWatch In **Esportazioni di log**, scegli l'opzione **iam-db-auth-error log**. La pubblicazione dei log in CloudWatch Logs consuma spazio di archiviazione e comporta l'addebito di costi per tale archiviazione. Assicurati di eliminare tutti i CloudWatch log che non ti servono più.
1. Scegli **Continue (Continua)**.
1. Per applicare immediatamente le modifiche, scegli **Immediately (Immediatamente)** nella sezione **Scheduling of modifications (Pianificazione delle modifiche)**.
1. Scegliere **Modify cluster (Modifica cluster)**.
## AWS CLI
Per creare un nuovo cluster DB con autenticazione IAM utilizzando il AWS CLI, usa il [https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html)comando. Specifica l’opzione `--enable-iam-database-authentication`.
Per aggiornare un cluster di database esistente in modo da abilitare o disabilitare l’autenticazione IAM, utilizzare il comando AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html). Specifica l’opzione `--enable-iam-database-authentication` o `--no-enable-iam-database-authentication`, come appropriato.
**Nota**
Puoi abilitare l’autenticazione IAM solo se tutte le istanze database nel cluster di database sono compatibili con IAM. Controllare i requisiti di compatibilità in [Disponibilità di regioni e versioni](UsingWithRDS.IAMDBAuth.md#UsingWithRDS.IAMDBAuth.Availability).
Per impostazione predefinita, Aurora esegue la modifica durante la finestra di manutenzione successiva. Se desideri sostituire ciò e abilitare l’autenticazione database IAM il prima possibile, utilizza il parametro `--apply-immediately`.
Se stai ripristinando un cluster di DB, usa uno dei seguenti AWS CLI comandi:
+ `[restore-db-cluster-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-to-point-in-time.html)`
+ `[restore-db-cluster-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html)`
L’impostazione di autenticazione del database IAM corrisponde a quella della snapshot origine. Per modificare questa impostazione, imposta l’opzione `--enable-iam-database-authentication` or `--no-enable-iam-database-authentication`, come appropriato.
## API RDS
Per creare una nuova istanza database con autenticazione IAM tramite l’API, utilizzare l’operazione API [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html). Imposta il parametro `EnableIAMDatabaseAuthentication` su `true`.
Per aggiornare un cluster di database esistente in modo da abilitare l’autenticazione IAM, utilizzare l’operazione API [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html). Imposta il parametro `EnableIAMDatabaseAuthentication` su `true` per abilitare l’autenticazione IAM o su `false` per disabilitarla.
**Nota**
Puoi abilitare l’autenticazione IAM solo se tutte le istanze database nel cluster di database sono compatibili con IAM. Controllare i requisiti di compatibilità in [Disponibilità di regioni e versioni](UsingWithRDS.IAMDBAuth.md#UsingWithRDS.IAMDBAuth.Availability).
Se ripristini un cluster database, usa una delle operazioni API seguenti:
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromSnapshot.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromSnapshot.html)
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterToPointInTime.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterToPointInTime.html)
L’impostazione di autenticazione del database IAM corrisponde a quella della snapshot origine. Per modificare questa impostazione, imposta il parametro `EnableIAMDatabaseAuthentication` su `true` per abilitare l’autenticazione IAM o su `false` per disabilitarla.
# Creazione e utilizzo di una policy IAM per l'accesso al database IAM
Per permettere a un utente o un ruolo di connettersi al cluster database, devi creare una policy IAM. Dopo questa operazione, collega la policy a un set di autorizzazioni o un ruolo.
**Nota**
Per ulteriori informazioni sulle policy IAM, consulta [Gestione accessi e identità per Amazon Aurora](UsingWithRDS.IAM.md).
La policy nell'esempio seguente permette a un utente di connettersi a un cluster database tramite l'autenticazione database IAM.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds-db:connect"
],
"Resource": [
"arn:aws:rds-db:us-east-2:111122223333:dbuser:cluster-ABCDEFGHIJKL01234/db_user"
]
}
]
}
```
------
**Importante**
Un utente con le autorizzazioni di amministratore può accedere ai cluster database senza una policy IAM esplicita. Se vuoi limitare l'accesso come amministratore a cluster di , puoi creare un ruolo IAM con le autorizzazioni appropriate, con privilegi minori e assegnarlo all'amministratore.
**Nota**
Non confondere il prefisso `rds-db:` con altri prefissi di operazione API RDS che iniziano con `rds:`. Utilizzi il prefisso `rds-db:` e l'operazione `rds-db:connect` solo per l'autenticazione database IAM. Non sono validi in altri contesti.
La policy di esempio include una singola istruzione con i seguenti elementi:
+ `Effect` – Specifica `Allow` per concedere l'accesso al cluster database. Se non si concede esplicitamente l'accesso, questo viene rifiutato per impostazione predefinita.
+ `Action` – Specifica `rds-db:connect` per consentire le connessioni al cluster database.
+ `Resource` – Specifica un Amazon Resource Name (ARN) che descrive un account database in un cluster database. Di seguito è riportato il formato ARN.
```
arn:aws:rds-db:region:account-id:dbuser:DbClusterResourceId/db-user-name
```
In questo formato, sostituisci quanto segue:
+ `region`è la AWS regione per il cluster di DB. Nella politica di esempio, la AWS regione è`us-east-2`.
+ `account-id`è il numero di AWS account per il cluster di DB. Nella policy di esempio, il numero di account è `1234567890`. L'utente deve essere nello stesso account dell'account del cluster di database.
Per eseguire l'accesso multi-account, crea un ruolo IAM con la policy mostrata in precedenza nell'account per il cluster di database e consenti all'altro account di assumere il ruolo.
+ `DbClusterResourceId` è l'identificatore del cluster database. Questo identificatore è unico per una AWS regione e non cambia mai. Nella policy di esempio, l'identificatore è `cluster-ABCDEFGHIJKL01234`.
Per trovare un ID di risorsa del Console di gestione AWS cluster di DB in Amazon Aurora, scegli il cluster di istanze per visualizzarne i dettagli. Quindi seleziona la scheda **Configuration (Configurazione)**. **Resource ID (ID risorsa)** è visualizzato nella sezione **Configuration (Configurazione)**.
In alternativa, puoi utilizzare il AWS CLI comando per elencare gli identificatori e le risorse IDs per tutto il cluster di DB nella AWS regione corrente, come illustrato di seguito.
```
aws rds describe-db-clusters --query "DBClusters[*].[DBClusterIdentifier,DbClusterResourceId]"
```
**Nota**
Se si sta effettuando la connessione a un database tramite proxy RDS, specificare l'ID risorsa proxy, ad esempio `prx-ABCDEFGHIJKL01234`. Per informazioni sull'utilizzo dell'autenticazione del database IAM con proxy RDS, vedere [Connessione a un database tramite l'autenticazione IAM](rds-proxy-connecting.md#rds-proxy-connecting-iam).
+ `db-user-name` è il nome dell'account database da associare all'autenticazione IAM. Nella policy di esempio, l'account database è `db_user`.
È possibile crearne altri ARNs per supportare vari modelli di accesso. La policy seguente permette l'accesso a due diversi account database in un cluster database.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds-db:connect"
],
"Resource": [
"arn:aws:rds-db:us-east-2:123456789012:dbuser:cluster-ABCDEFGHIJKL01234/jane_doe",
"arn:aws:rds-db:us-east-2:123456789012:dbuser:cluster-ABCDEFGHIJKL01234/mary_roe"
]
}
]
}
```
------
La seguente politica utilizza il carattere «\$1» per abbinare tutte le DB, i cluster e gli account di database per un account e una regione particolari AWS . AWS
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds-db:connect"
],
"Resource": [
"arn:aws:rds-db:us-east-2:111122223333:dbuser:*/*"
]
}
]
}
```
------
La seguente politica corrisponde a tutti i cluster di DB per un account e una regione particolari AWS . AWS Tuttavia, la policy concede l'accesso solo a cluster database che hanno un account database `jane_doe`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds-db:connect"
],
"Resource": [
"arn:aws:rds-db:us-east-2:123456789012:dbuser:*/jane_doe"
]
}
]
}
```
------
L'utente o il ruolo ha accesso solo a quei database ai quali l'utente ha accesso. Supponiamo, ad esempio, che il cluster database abbia un database denominato *dev* e un altro database denominato *test*. Se l'utente del database `jane_doe` ha accesso solo a *dev*, anche qualsiasi utente o ruolo che accede al cluster database con l'utente `jane_doe` ha accesso solo a *dev*. Questa restrizione dell'accesso è anche valida per altri oggetti database, come tabelle, visualizzazioni e così via.
Un amministratore deve creare policy IAM che concedono alle entità l'autorizzazione per eseguire operazioni API specifiche sulle risorse specificate di cui hanno bisogno. L'amministratore deve quindi collegare queste policy ai set di autorizzazioni o ai ruoli che richiedono tali autorizzazioni. Per esempi di policy, consulta [Esempi di policy di Amazon Aurora basate su identità](security_iam_id-based-policy-examples.md).
## Collegamento di una policy IAM a un set di autorizzazioni o un ruolo
Dopo aver creato una policy IAM per consentire l'autenticazione del database, devi collegare la policy a un set di autorizzazioni o un ruolo. Per un tutorial su questo argomento, consulta [ Creare e collegare la tua prima policy gestita dal cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_managed-policies.html) nella *Guida per l'utente IAM*.
Durante il tutorial, puoi utilizzare uno degli esempi di policy indicati in questa sezione come punto di partenza e personalizzarli in base alle tue esigenze. Al termine del tutorial, avrai un set di autorizzazioni con una policy collegata che può utilizzare l'operazione `rds-db:connect`.
**Nota**
Puoi mappare più set di autorizzazioni o ruoli allo stesso account utente del database. Ad esempio, supponiamo che la policy IAM abbia specificato la seguente risorsa ARN.
```
arn:aws:rds-db:us-east-2:123456789012:dbuser:cluster-12ABC34DEFG5HIJ6KLMNOP78QR/jane_doe
```
Se colleghi la policy agli utenti *Jane*, *Bob* e *Diego*, ciascuno di quegli utenti potrà connettersi al cluster di database specificato utilizzando l'account di database `jane_doe`.
# Creazione di un account database tramite l’autenticazione IAM
Con l’autenticazione database IAM, non devi assegnare password di database agli account utente che crei. Se rimuovi un utente mappato a un account database, devi anche rimuovere l’account database con l’istruzione `DROP USER`.
**Nota**
Il nome utente utilizzato per l’autenticazione IAM deve avere lo stesso formato maiuscolo/minuscolo del nome utente nel database.
**Topics**
+ [Utilizzo dell’autenticazione IAM con Aurora MySQL](#UsingWithRDS.IAMDBAuth.DBAccounts.MySQL)
+ [Utilizzo dell'autenticazione IAM con Aurora PostgreSQL](#UsingWithRDS.IAMDBAuth.DBAccounts.PostgreSQL)
## Utilizzo dell’autenticazione IAM con Aurora MySQL
Con per autenticare gli utenti. Connettiti al cluster database come utente master o altro utente che può creare utenti e concedere privilegi. Dopo la connessione, immetti l’istruzione `CREATE USER`, come mostrato nell’esempio seguente.
```
CREATE USER 'jane_doe' IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS';
```
La clausola `IDENTIFIED WITH` permette a Aurora MySQL di utilizzare `AWSAuthenticationPlugin` per autenticare l’account database (`jane_doe`). La clausola `AS 'RDS'` fa riferimento al metodo di autenticazione. Assicurarsi che il nome utente del database specificato sia lo stesso di una risorsa nella policy IAM per l’accesso al database IAM. Per ulteriori informazioni, consulta [Creazione e utilizzo di una policy IAM per l'accesso al database IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md).
**Nota**
`ERROR 1524 (HY000): Plugin 'AWSAuthenticationPlugin' is not loaded`
Per correggere questo errore, assicurati di usare una configurazione supportata e di aver abilitato l’autenticazione database IAM nel cluster database. Per ulteriori informazioni, consulta [Disponibilità di regioni e versioni](UsingWithRDS.IAMDBAuth.md#UsingWithRDS.IAMDBAuth.Availability) e [Abilitazione e disabilitazione dell’autenticazione database IAM](UsingWithRDS.IAMDBAuth.Enabling.md).
Dopo aver creato un account utilizzando `AWSAuthenticationPlugin`, lo gestisci nello stesso modo di altri account database. Ad esempio, puoi modificare i privilegi di account con le istruzioni `GRANT` e `REVOKE` o modificare vari attributi di account con l’istruzione `ALTER USER`.
Il traffico di rete del database viene SSL/TLS crittografato utilizzando IAM. Per consentire le connessioni SSL, modifica l’account utente con il comando seguente.
```
ALTER USER 'jane_doe'@'%' REQUIRE SSL;
```
## Utilizzo dell'autenticazione IAM con Aurora PostgreSQL
Per utilizzare l’autenticazione IAM con Aurora PostgreSQL, connettiti al cluster database come utente master o altro utente che può creare utenti e concedere privilegi. Dopo la connessione, crea gli utenti di database e autorizza il ruolo `rds_iam`, come mostrato nell’esempio seguente.
```
CREATE USER db_userx;
GRANT rds_iam TO db_userx;
```
Assicurarsi che il nome utente del database specificato sia lo stesso di una risorsa nella policy IAM per l’accesso al database IAM. Per ulteriori informazioni, consulta [Creazione e utilizzo di una policy IAM per l'accesso al database IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md). È necessario fornire il ruolo `rds_iam` per utilizzare l’autenticazione IAM. È possibile utilizzare anche appartenenze nidificate o concessioni indirette del ruolo.
Tieni presente che un utente del database PostgreSQL può utilizzare l’autenticazione IAM o Kerberos ma non entrambe, quindi questo utente non può avere anche il ruolo `rds_ad`. Questo vale anche per le appartenenze nidificate. Per ulteriori informazioni, consulta [Fase 7: creazione di utenti PostgreSQL per i principali Kerberos](postgresql-kerberos-setting-up.md#postgresql-kerberos-setting-up.create-logins).
# Connessione al cluster di database tramite l'autenticazione IAM
Con l'autenticazione database IAM devi usare un token di autenticazione per la connessione al cluster di database. Un *token di autenticazione* è una stringa unica di caratteri che utilizzi invece di una password. Trascorsi 15 minuti dalla sua creazione, un token di autenticazione scade. Se cerchi di eseguire la connessione utilizzando un token scaduto la richiesta di connessione viene negata.
Ogni token di autenticazione deve essere accompagnato da una firma valida, utilizzando AWS Signature Version 4. Per ulteriori informazioni, consulta [Processo di firma Signature Version 4](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) in *Riferimenti generali di AWS*. La AWS CLI e un SDK AWS, come AWS SDK per Java o AWS SDK per Python (Boto3), possono firmare automaticamente ogni token che viene creato.
Poi usare un token di autenticazione quando ti connetti ad Amazon Aurora da un altro servizio AWS, ad esempio AWS Lambda. Utilizzando un token, eviti di inserire una password nel codice. In alternativa, puoi utilizzare l'SDK AWS per creare e firmare in modo programmatico un token di autenticazione.
Quando hai un token di autenticazione IAM firmato, puoi connetterti a un cluster di database Aurora. Di seguito vengono fornite informazioni su come eseguire questa operazione tramite uno strumento a riga di comando o un SDK AWS, come AWS SDK per Java o AWS SDK per Python (Boto3).
Per ulteriori informazioni, consulta il seguente post sul blog:
+ [Uso dell'autenticazione IAM per la connessione con SQL Workbench/J a Aurora MySQL o Amazon RDS for MySQL](https://aws.amazon.com/blogs/database/use-iam-authentication-to-connect-with-sql-workbenchj-to-amazon-aurora-mysql-or-amazon-rds-for-mysql/).
+ [Utilizzo dell'autenticazione IAM per connettersi con pgAdmin Amazon Aurora PostgreSQL o Amazon RDS for PostgreSQL](https://aws.amazon.com/blogs/database/using-iam-authentication-to-connect-with-pgadmin-amazon-aurora-postgresql-or-amazon-rds-for-postgresql/)
**Prerequisiti**
Di seguito sono riportati i prerequisiti per la connessione alcluster di DB utilizzando l'autenticazione IAM:
+ [Abilitazione e disabilitazione dell’autenticazione database IAM](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [Creazione e utilizzo di una policy IAM per l'accesso al database IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [Creazione di un account database tramite l’autenticazione IAM](UsingWithRDS.IAMDBAuth.DBAccounts.md)
**Topics**
+ [Connessione al cluster dell’ database utilizzando l’autenticazione IAM con i driver AWS](IAMDBAuth.Connecting.Drivers.md)
+ [Connessione al cluster di DB utilizzando l'autenticazione IAM dalla riga di comando: AWS CLI e il client mysql](UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.md)
+ [Connessione al cluster di DB utilizzando l'autenticazione IAM dalla riga di comando: AWS CLI e il client psql](UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.PostgreSQL.md)
+ [Connessione al cluster di DB utilizzando l'autenticazione IAM e AWS SDK per .NET](UsingWithRDS.IAMDBAuth.Connecting.NET.md)
+ [Connessione al cluster di DB utilizzando l'autenticazione IAM e AWS SDK per Go](UsingWithRDS.IAMDBAuth.Connecting.Go.md)
+ [Connessione al cluster di DB utilizzando l'autenticazione IAM e il AWS SDK per Java](UsingWithRDS.IAMDBAuth.Connecting.Java.md)
+ [Connessione al cluster di DB utilizzando l'autenticazione IAM e il AWS SDK per Python (Boto3)](UsingWithRDS.IAMDBAuth.Connecting.Python.md)
# Connessione al cluster dell’ database utilizzando l’autenticazione IAM con i driver AWS
La suite di driver AWS è stata progettata per consentire tempi di switchover e failover più rapidi e per eseguire l’autenticazione con Gestione dei segreti AWS, AWS Identity and Access Management (IAM) e l’identità federata. I driver AWS si basano sul monitoraggio dello stato dell’ del cluster di database e conoscono la topologia dell’ del cluster per determinare la nuova istanza di scrittura. Questo approccio riduce i tempi di switchover e failover a meno di dieci secondi, rispetto alle decine di secondi necessari per i driver open source.
Per ulteriori informazioni sui driver AWS, consulta il driver del linguaggio corrispondente per il cluster di database [Aurora MySQL](Aurora.Connecting.md#Aurora.Connecting.JDBCDriverMySQL) o [Aurora PostgreSQL](Aurora.Connecting.md#Aurora.Connecting.AuroraPostgreSQL.Utilities).
# Connessione al cluster di DB utilizzando l'autenticazione IAM dalla riga di comando: AWS CLI e il client mysql
Puoi connetterti dalla riga di comando a un cluster Aurora con AWS CLI lo strumento da riga di comando `mysql` and come descritto di seguito.
**Prerequisiti**
Di seguito sono riportati i prerequisiti per la connessione alcluster di DB utilizzando l’autenticazione IAM:
+ [Abilitazione e disabilitazione dell’autenticazione database IAM](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [Creazione e utilizzo di una policy IAM per l'accesso al database IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [Creazione di un account database tramite l’autenticazione IAM](UsingWithRDS.IAMDBAuth.DBAccounts.md)
**Nota**
Per informazioni sulla connessione al database tramite SQL Workbench/J con autenticazione IAM, consulta il post del blog [Use IAM authentication to connect with SQL Workbench/J to Aurora MySQL o Amazon RDS for MySQL](https://aws.amazon.com/blogs/database/use-iam-authentication-to-connect-with-sql-workbenchj-to-amazon-aurora-mysql-or-amazon-rds-for-mysql/).
**Topics**
+ [Generazione di un token di autenticazione IAM](#UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.AuthToken)
+ [Connessione a un cluster database](#UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.Connect)
## Generazione di un token di autenticazione IAM
L'esempio seguente mostra come ottenere un token di autenticazione firmato utilizzando AWS CLI.
```
aws rds generate-db-auth-token \
--hostname rdsmysql.123456789012.us-west-2.rds.amazonaws.com \
--port 3306 \
--region us-west-2 \
--username jane_doe
```
Nell'esempio, i parametri sono come segue:
+ `--hostname` – Nome host del cluster database cui vuoi accedere.
+ `--port` – Numero di porta usato per la connessione al dell'istanza database
+ `--region`
+ `--username` – L'account database cui vuoi accedere.
I primi caratteri del token hanno il seguente aspetto.
```
rdsmysql.123456789012.us-west-2.rds.amazonaws.com:3306/?Action=connect&DBUser=jane_doe&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Expires=900...
```
**Nota**
Non è possibile utilizzare un record DNS Route 53 personalizzato anziché l'endpoint del cluster di databaseper generare il token di autenticazione.
## Connessione a un cluster database
Il formato generale per la connessione è visualizzato di seguito.
```
mysql --host=hostName --port=portNumber --ssl-ca=full_path_to_ssl_certificate --enable-cleartext-plugin --user=userName --password=authToken
```
I parametri sono i seguenti:
+ `--host` – Nome host del cluster database cui vuoi accedere.
+ `--port` – Numero di porta usato per la connessione al dell'istanza database
+ `--ssl-ca` – Il percorso completo del file del certificato SSL che contiene la chiave pubblica
Per ulteriori informazioni, consulta [Connessioni TLS a cluster di database Aurora MySQL](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL).
Per scaricare un certificato SSL consulta [Utilizzo SSL/TLS per crittografare una connessione a un'](UsingWithRDS.SSL.md)
+ `--enable-cleartext-plugin` – Valore che specifica che per la connessione deve essere usato `AWSAuthenticationPlugin`.
Se si utilizza un client MariaDB, l'opzione `--enable-cleartext-plugin` non è richiesta.
+ `--user` – L'account database cui vuoi accedere.
+ `--password` – Token di autenticazione IAM firmato.
Il token di autenticazione consiste in diverse centinaia di caratteri. Può essere macchinoso nella riga di comando. Una soluzione è di salvare il token in una variabile di ambiente e utilizzare quella variabile durante la connessione. L'esempio seguente mostra un modo per eseguire questa soluzione. Nell'esempio, */sample\$1dir/* è il percorso completo del file del certificato SSL che contiene la chiave pubblica.
```
RDSHOST="mysqlcluster.cluster-123456789012.us-east-1.rds.amazonaws.com"
TOKEN="$(aws rds generate-db-auth-token --hostname $RDSHOST --port 3306 --region us-west-2 --username jane_doe )"
mysql --host=$RDSHOST --port=3306 --ssl-ca=/sample_dir/global-bundle.pem --enable-cleartext-plugin --user=jane_doe --password=$TOKEN
```
Quando si esegue la connessione utilizzando `AWSAuthenticationPlugin`, la connessione viene protetta utilizzando SSL. Per verificare ciò, digita quanto segue al prompt del comando `mysql>`.
```
show status like 'Ssl%';
```
Le righe seguenti nell'output mostrano più dettagli.
```
+---------------+-------------+
| Variable_name | Value |
+---------------+-------------+
| ... | ...
| Ssl_cipher | AES256-SHA |
| ... | ...
| Ssl_version | TLSv1.1 |
| ... | ...
+-----------------------------+
```
Se desideri connetterti a un cluster di database tramite un proxy, consulta [Connessione a un database tramite l'autenticazione IAM](rds-proxy-connecting.md#rds-proxy-connecting-iam).
# Connessione al cluster di DB utilizzando l'autenticazione IAM dalla riga di comando: AWS CLI e il client psql
Puoi eseguire la connessione dalla riga di comando a un cluster database Aurora PostgreSQL con AWS CLI e lo strumento a riga di comando psql come descritto di seguito.
**Prerequisiti**
Di seguito sono riportati i prerequisiti per la connessione alcluster di DB utilizzando l’autenticazione IAM:
+ [Abilitazione e disabilitazione dell’autenticazione database IAM](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [Creazione e utilizzo di una policy IAM per l'accesso al database IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [Creazione di un account database tramite l’autenticazione IAM](UsingWithRDS.IAMDBAuth.DBAccounts.md)
**Nota**
Per informazioni sulla connessione al database tramite pgAdmin con autenticazione IAM, consulta il post sul blog [Utilizzo dell'autenticazione IAM per connettersi con PGadmin Amazon Aurora PostgreSQL o Amazon RDS for PostgreSQL](https://aws.amazon.com/blogs/database/using-iam-authentication-to-connect-with-pgadmin-amazon-aurora-postgresql-or-amazon-rds-for-postgresql/).
**Topics**
+ [Generazione di un token di autenticazione IAM](#UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.AuthToken.PostgreSQL)
+ [Connessione a un cluster Aurora PostgreSQL](#UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.Connect.PostgreSQL)
## Generazione di un token di autenticazione IAM
Il token di autenticazione è costituito da diverse centinaia di caratteri, quindi può essere complesso nella riga di comando. Una soluzione è di salvare il token in una variabile di ambiente e utilizzare quella variabile durante la connessione. L'esempio seguente mostra come utilizzare il AWS CLI per ottenere un token di autenticazione firmato utilizzando il `generate-db-auth-token` comando e archiviarlo in una variabile di `PGPASSWORD` ambiente.
```
export RDSHOST="mypostgres-cluster.cluster-123456789012.us-west-2.rds.amazonaws.com"
export PGPASSWORD="$(aws rds generate-db-auth-token --hostname $RDSHOST --port 5432 --region us-west-2 --username jane_doe )"
```
Nell'esempio, i parametri per il comando `generate-db-auth-token` sono i seguenti:
+ `--hostname` – Nome host del cluster (endpoint del cluster) di database cui desideri accedere.
+ `--port` – Numero di porta usato per la connessione al dell'istanza database
+ `--region`— La AWS regione in cui è in esecuzione il cluster di DB
+ `--username` – L'account database cui vuoi accedere.
I primi caratteri del token generato hanno il seguente aspetto.
```
mypostgres-cluster.cluster-123456789012.us-west-2.rds.amazonaws.com:5432/?Action=connect&DBUser=jane_doe&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Expires=900...
```
**Nota**
Non è possibile utilizzare un record DNS Route 53 personalizzato anziché l'endpoint del cluster di databaseper generare il token di autenticazione.
## Connessione a un cluster Aurora PostgreSQL
Di seguito è mostrato il formato generale per l'utilizzo di psql per la connessione.
```
psql "host=hostName port=portNumber sslmode=verify-full sslrootcert=full_path_to_ssl_certificate dbname=DBName user=userName password=authToken"
```
I parametri sono i seguenti:
+ `host` – Nome host del cluster (endpoint del cluster) di database cui desideri accedere.
+ `port` – Numero di porta usato per la connessione al dell'istanza database
+ `sslmode` – Modalità SSL da utilizzare.
Quando si utilizza `sslmode=verify-full`, la connessione SSL verifica l'endpoint del cluster database rispetto a quello nel certificato SSL.
+ `sslrootcert` – Il percorso completo del file del certificato SSL che contiene la chiave pubblica
Per ulteriori informazioni, consulta [Sicurezza dei dati Aurora PostgreSQL con SSL/TLS](AuroraPostgreSQL.Security.md#AuroraPostgreSQL.Security.SSL).
Per scaricare un certificato SSL consulta [Utilizzo SSL/TLS per crittografare una connessione a un'](UsingWithRDS.SSL.md)
+ `dbname` – Database a cui accedere.
+ `user` – L'account database cui vuoi accedere.
+ `password` – Token di autenticazione IAM firmato.
**Nota**
Non è possibile utilizzare un record DNS Route 53 personalizzato anziché l'endpoint del cluster di databaseper generare il token di autenticazione.
L'esempio seguente mostra l'utilizzo di psql per la connessione. Nell'esempio, psql utilizza la variabile d'ambiente `RDSHOST` per l'host e la variabile d'ambiente `PGPASSWORD` per il token generato. Inoltre, */sample\$1dir/* è il percorso completo del file del certificato SSL che contiene la chiave pubblica.
```
export RDSHOST="mypostgres-cluster.cluster-123456789012.us-west-2.rds.amazonaws.com"
export PGPASSWORD="$(aws rds generate-db-auth-token --hostname $RDSHOST --port 5432 --region us-west-2 --username jane_doe )"
psql "host=$RDSHOST port=5432 sslmode=verify-full sslrootcert=/sample_dir/global-bundle.pem dbname=DBName user=jane_doe password=$PGPASSWORD"
```
Se desideri connetterti a un cluster di database tramite un proxy, consulta [Connessione a un database tramite l'autenticazione IAM](rds-proxy-connecting.md#rds-proxy-connecting-iam).
# Connessione al cluster di DB utilizzando l'autenticazione IAM e AWS SDK per .NET
È possibile connettersi a un cluster come descritto di seguito. AWS SDK per .NET
**Prerequisiti**
Di seguito sono riportati i prerequisiti per la connessione alcluster di DB utilizzando l’autenticazione IAM:
+ [Abilitazione e disabilitazione dell’autenticazione database IAM](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [Creazione e utilizzo di una policy IAM per l'accesso al database IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [Creazione di un account database tramite l’autenticazione IAM](UsingWithRDS.IAMDBAuth.DBAccounts.md)
**Esempi**
Il seguente esempio di codice mostra come generare un token di autenticazione e utilizzarlo per eseguire la connessione a un cluster del database.
Per eseguire questo esempio di codice, è necessario il file, trovato sul sito. [AWS SDK per .NET](https://aws.amazon.com/sdk-for-net/) AWS I pacchetti `AWSSDK.CORE` e `AWSSDK.RDS` sono obbligatori. Per connetterti a un cluster di DB, usa il connettore di database.NET per il motore DB, ad esempio MySqlConnector per MariaDB o MySQL, o Npgsql per PostgreSQL.
Questo codice si connette a un cluster di database Aurora MySQL. Modifica i valori delle variabili seguenti in base alle esigenze.
+ `server`: l'endpoint del cluster database cui vuoi accedere
+ `user` – L'account database cui vuoi accedere.
+ `database` – Database a cui accedere.
+ `port` – Numero di porta usato per la connessione al dell'istanza database
+ `SslMode` – Modalità SSL da utilizzare.
Quando si utilizza `SslMode=Required`, la connessione SSL verifica l'endpoint del cluster database rispetto a quello nel certificato SSL.
+ `SslCa` - Percorso completo del certificato SSL per Amazon Aurora
Per scaricare un certificato, consultare [Utilizzo SSL/TLS per crittografare una connessione a un'](UsingWithRDS.SSL.md).
**Nota**
Non è possibile utilizzare un record DNS Route 53 personalizzato anziché l'endpoint del cluster di databaseper generare il token di autenticazione.
```
using System;
using System.Data;
using MySql.Data;
using MySql.Data.MySqlClient;
using Amazon;
namespace ubuntu
{
class Program
{
static void Main(string[] args)
{
var pwd = Amazon.RDS.Util.RDSAuthTokenGenerator.GenerateAuthToken(RegionEndpoint.USEast1, "mysqlcluster.cluster-123456789012.us-east-1.rds.amazonaws.com", 3306, "jane_doe");
// for debug only Console.Write("{0}\n", pwd); //this verifies the token is generated
MySqlConnection conn = new MySqlConnection($"server=mysqlcluster.cluster-123456789012.us-east-1.rds.amazonaws.com;user=jane_doe;database=mydB;port=3306;password={pwd};SslMode=Required;SslCa=full_path_to_ssl_certificate");
conn.Open();
// Define a query
MySqlCommand sampleCommand = new MySqlCommand("SHOW DATABASES;", conn);
// Execute a query
MySqlDataReader mysqlDataRdr = sampleCommand.ExecuteReader();
// Read all rows and output the first column in each row
while (mysqlDataRdr.Read())
Console.WriteLine(mysqlDataRdr[0]);
mysqlDataRdr.Close();
// Close connection
conn.Close();
}
}
}
```
Questo codice si connette a un cluster di database Aurora PostgreSQL.
Modifica i valori delle variabili seguenti in base alle esigenze.
+ `Server`: l'endpoint del cluster database cui vuoi accedere
+ `User ID` – L'account database cui vuoi accedere.
+ `Database` – Database a cui accedere.
+ `Port` – Numero di porta usato per la connessione al dell'istanza database
+ `SSL Mode` – Modalità SSL da utilizzare.
Quando si utilizza `SSL Mode=Required`, la connessione SSL verifica l'endpoint del cluster database rispetto a quello nel certificato SSL.
+ `Root Certificate` - Percorso completo del certificato SSL per Amazon Aurora
Per scaricare un certificato, consultare [Utilizzo SSL/TLS per crittografare una connessione a un'](UsingWithRDS.SSL.md).
**Nota**
Non è possibile utilizzare un record DNS Route 53 personalizzato anziché l'endpoint del cluster di databaseper generare il token di autenticazione.
```
using System;
using Npgsql;
using Amazon.RDS.Util;
namespace ConsoleApp1
{
class Program
{
static void Main(string[] args)
{
var pwd = RDSAuthTokenGenerator.GenerateAuthToken("postgresmycluster.cluster-123456789012.us-east-1.rds.amazonaws.com", 5432, "jane_doe");
// for debug only Console.Write("{0}\n", pwd); //this verifies the token is generated
NpgsqlConnection conn = new NpgsqlConnection($"Server=postgresmycluster.cluster-123456789012.us-east-1.rds.amazonaws.com;User Id=jane_doe;Password={pwd};Database=mydb;SSL Mode=Require;Root Certificate=full_path_to_ssl_certificate");
conn.Open();
// Define a query
NpgsqlCommand cmd = new NpgsqlCommand("select count(*) FROM pg_user", conn);
// Execute a query
NpgsqlDataReader dr = cmd.ExecuteReader();
// Read all rows and output the first column in each row
while (dr.Read())
Console.Write("{0}\n", dr[0]);
// Close connection
conn.Close();
}
}
}
```
Se desideri connetterti a un cluster di database tramite un proxy, consulta [Connessione a un database tramite l'autenticazione IAM](rds-proxy-connecting.md#rds-proxy-connecting-iam).
# Connessione al cluster di DB utilizzando l'autenticazione IAM e AWS SDK per Go
È possibile connettersi a un cluster come descritto di seguito. AWS SDK per Go
**Prerequisiti**
Di seguito sono riportati i prerequisiti per la connessione alcluster di DB utilizzando l’autenticazione IAM:
+ [Abilitazione e disabilitazione dell’autenticazione database IAM](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [Creazione e utilizzo di una policy IAM per l'accesso al database IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [Creazione di un account database tramite l’autenticazione IAM](UsingWithRDS.IAMDBAuth.DBAccounts.md)
**Esempi**
Per eseguire questi esempi di codice, è necessario il file, trovato sul sito. [AWS SDK per Go](https://aws.amazon.com/sdk-for-go/) AWS
Modifica i valori delle variabili seguenti in base alle esigenze.
+ `dbName` – Database a cui accedere.
+ `dbUser` – L'account database cui vuoi accedere.
+ `dbHost`: l'endpoint del cluster database cui vuoi accedere
**Nota**
Non è possibile utilizzare un record DNS Route 53 personalizzato anziché l'endpoint del cluster di databaseper generare il token di autenticazione.
+ `dbPort` – Numero di porta usato per la connessione al dell'istanza database
+ `region`— La AWS regione in cui è in esecuzione il cluster di DB
Inoltre, assicurarsi che le librerie importate nel codice di esempio esistano nel sistema.
**Importante**
Negli esempi riportati in questa sezione viene utilizzato il codice seguente per fornire credenziali che accedono a un database da un ambiente locale:
`creds := credentials.NewEnvCredentials()`
Se accedi a un database da un AWS servizio, come Amazon EC2 o Amazon ECS, puoi sostituire il codice con il seguente codice:
`sess := session.Must(session.NewSession())`
`creds := sess.Config.Credentials`
Se si apporta questa modifica, assicurarsi di aggiungere la seguente importazione:
`"github.com/aws/aws-sdk-go/aws/session"`
**Topics**
+ [Connessione tramite autenticazione IAM e V2 AWS SDK per Go](#UsingWithRDS.IAMDBAuth.Connecting.GoV2)
+ [Connessione tramite autenticazione IAM e AWS SDK per Go V1.](#UsingWithRDS.IAMDBAuth.Connecting.GoV1)
## Connessione tramite autenticazione IAM e V2 AWS SDK per Go
È possibile connettersi a un cluster di DB utilizzando l'autenticazione IAM e la AWS SDK per Go V2.
Il seguente esempio di codice mostra come generare un token di autenticazione e utilizzarlo per eseguire la connessione a un cluster del database.
Questo codice si connette a un cluster di database Aurora MySQL.
```
package main
import (
"context"
"database/sql"
"fmt"
"github.com/aws/aws-sdk-go-v2/config"
"github.com/aws/aws-sdk-go-v2/feature/rds/auth"
_ "github.com/go-sql-driver/mysql"
)
func main() {
var dbName string = "DatabaseName"
var dbUser string = "DatabaseUser"
var dbHost string = "mysqlcluster.cluster-123456789012.us-east-1.rds.amazonaws.com"
var dbPort int = 3306
var dbEndpoint string = fmt.Sprintf("%s:%d", dbHost, dbPort)
var region string = "us-east-1"
cfg, err := config.LoadDefaultConfig(context.TODO())
if err != nil {
panic("configuration error: " + err.Error())
}
authenticationToken, err := auth.BuildAuthToken(
context.TODO(), dbEndpoint, region, dbUser, cfg.Credentials)
if err != nil {
panic("failed to create authentication token: " + err.Error())
}
dsn := fmt.Sprintf("%s:%s@tcp(%s)/%s?tls=true&allowCleartextPasswords=true",
dbUser, authenticationToken, dbEndpoint, dbName,
)
db, err := sql.Open("mysql", dsn)
if err != nil {
panic(err)
}
err = db.Ping()
if err != nil {
panic(err)
}
}
```
Questo codice si connette a un cluster di database Aurora PostgreSQL.
```
package main
import (
"context"
"database/sql"
"fmt"
"github.com/aws/aws-sdk-go-v2/config"
"github.com/aws/aws-sdk-go-v2/feature/rds/auth"
_ "github.com/lib/pq"
)
func main() {
var dbName string = "DatabaseName"
var dbUser string = "DatabaseUser"
var dbHost string = "postgresmycluster.cluster-123456789012.us-east-1.rds.amazonaws.com"
var dbPort int = 5432
var dbEndpoint string = fmt.Sprintf("%s:%d", dbHost, dbPort)
var region string = "us-east-1"
cfg, err := config.LoadDefaultConfig(context.TODO())
if err != nil {
panic("configuration error: " + err.Error())
}
authenticationToken, err := auth.BuildAuthToken(
context.TODO(), dbEndpoint, region, dbUser, cfg.Credentials)
if err != nil {
panic("failed to create authentication token: " + err.Error())
}
dsn := fmt.Sprintf("host=%s port=%d user=%s password=%s dbname=%s",
dbHost, dbPort, dbUser, authenticationToken, dbName,
)
db, err := sql.Open("postgres", dsn)
if err != nil {
panic(err)
}
err = db.Ping()
if err != nil {
panic(err)
}
}
```
Se desideri connetterti a un cluster di database tramite un proxy, consulta [Connessione a un database tramite l'autenticazione IAM](rds-proxy-connecting.md#rds-proxy-connecting-iam).
## Connessione tramite autenticazione IAM e AWS SDK per Go V1.
È possibile connettersi a un cluster di DB utilizzando l'autenticazione IAM e la AWS SDK per Go V1
Il seguente esempio di codice mostra come generare un token di autenticazione e utilizzarlo per eseguire la connessione a un cluster del database.
Questo codice si connette a un cluster di database Aurora MySQL.
```
package main
import (
"database/sql"
"fmt"
"log"
"github.com/aws/aws-sdk-go/aws/credentials"
"github.com/aws/aws-sdk-go/service/rds/rdsutils"
_ "github.com/go-sql-driver/mysql"
)
func main() {
dbName := "app"
dbUser := "jane_doe"
dbHost := "mysqlcluster.cluster-123456789012.us-east-1.rds.amazonaws.com"
dbPort := 3306
dbEndpoint := fmt.Sprintf("%s:%d", dbHost, dbPort)
region := "us-east-1"
creds := credentials.NewEnvCredentials()
authToken, err := rdsutils.BuildAuthToken(dbEndpoint, region, dbUser, creds)
if err != nil {
panic(err)
}
dsn := fmt.Sprintf("%s:%s@tcp(%s)/%s?tls=true&allowCleartextPasswords=true",
dbUser, authToken, dbEndpoint, dbName,
)
db, err := sql.Open("mysql", dsn)
if err != nil {
panic(err)
}
err = db.Ping()
if err != nil {
panic(err)
}
}
```
Questo codice si connette a un cluster di database Aurora PostgreSQL.
```
package main
import (
"database/sql"
"fmt"
"github.com/aws/aws-sdk-go/aws/credentials"
"github.com/aws/aws-sdk-go/service/rds/rdsutils"
_ "github.com/lib/pq"
)
func main() {
dbName := "app"
dbUser := "jane_doe"
dbHost := "postgresmycluster.cluster-123456789012.us-east-1.rds.amazonaws.com"
dbPort := 5432
dbEndpoint := fmt.Sprintf("%s:%d", dbHost, dbPort)
region := "us-east-1"
creds := credentials.NewEnvCredentials()
authToken, err := rdsutils.BuildAuthToken(dbEndpoint, region, dbUser, creds)
if err != nil {
panic(err)
}
dsn := fmt.Sprintf("host=%s port=%d user=%s password=%s dbname=%s",
dbHost, dbPort, dbUser, authToken, dbName,
)
db, err := sql.Open("postgres", dsn)
if err != nil {
panic(err)
}
err = db.Ping()
if err != nil {
panic(err)
}
}
```
Se desideri connetterti a un cluster di database tramite un proxy, consulta [Connessione a un database tramite l'autenticazione IAM](rds-proxy-connecting.md#rds-proxy-connecting-iam).
# Connessione al cluster di DB utilizzando l'autenticazione IAM e il AWS SDK per Java
È possibile connettersi a un cluster come descritto di seguito. AWS SDK per Java
**Prerequisiti**
Di seguito sono riportati i prerequisiti per la connessione alcluster di DB utilizzando l’autenticazione IAM:
+ [Abilitazione e disabilitazione dell’autenticazione database IAM](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [Creazione e utilizzo di una policy IAM per l'accesso al database IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [Creazione di un account database tramite l’autenticazione IAM](UsingWithRDS.IAMDBAuth.DBAccounts.md)
+ [Configurare l' AWS SDK per Java](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/setup-install.html)
Per esempi su come utilizzare l’SDK per Java 2.x, consulta [Esempi per Amazon RDS con SDK per Java 2.x](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/java_rds_code_examples.html). [Puoi anche usare AWS Advanced JDBC Wrapper, consulta AWS la documentazione di Advanced JDBC Wrapper.](https://github.com/aws/aws-advanced-jdbc-wrapper/blob/main/docs/Documentation.md)
**Topics**
+ [Generazione di un token di autenticazione IAM](#UsingWithRDS.IAMDBAuth.Connecting.Java.AuthToken)
+ [Creazione manuale di un token di autenticazione IAM](#UsingWithRDS.IAMDBAuth.Connecting.Java.AuthToken2)
+ [Connessione a un cluster database](#UsingWithRDS.IAMDBAuth.Connecting.Java.AuthToken.Connect)
## Generazione di un token di autenticazione IAM
Se state scrivendo programmi utilizzando il AWS SDK per Java, potete ottenere un token di autenticazione firmato utilizzando la classe. `RdsIamAuthTokenGenerator` L'utilizzo di questa classe richiede l'immissione di AWS credenziali. A tale scopo, create un'istanza della `DefaultAWSCredentialsProviderChain` classe. `DefaultAWSCredentialsProviderChain`utilizza la prima chiave di AWS accesso e la chiave segreta che trova nella [catena di provider di credenziali predefinita](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/credentials.html#credentials-default). Per ulteriori informazioni sulle chiavi di accesso AWS , consulta [Gestione delle chiavi di accesso per gli utenti IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html).
**Nota**
Non è possibile utilizzare un record DNS Route 53 personalizzato anziché l'endpoint del cluster di databaseper generare il token di autenticazione.
Dopo aver creato un’istanza di `RdsIamAuthTokenGenerator`, puoi chiamare il metodo `getAuthToken` per ottenere un token firmato. Specifica la regione AWS , il nome host, il numero di porta e il nome utente. Il seguente esempio di codice dimostra come eseguire questa operazione.
```
package com.amazonaws.codesamples;
import com.amazonaws.auth.DefaultAWSCredentialsProviderChain;
import com.amazonaws.services.rds.auth.GetIamAuthTokenRequest;
import com.amazonaws.services.rds.auth.RdsIamAuthTokenGenerator;
public class GenerateRDSAuthToken {
public static void main(String[] args) {
String region = "us-west-2";
String hostname = "rdsmysql.123456789012.us-west-2.rds.amazonaws.com";
String port = "3306";
String username = "jane_doe";
System.out.println(generateAuthToken(region, hostname, port, username));
}
static String generateAuthToken(String region, String hostName, String port, String username) {
RdsIamAuthTokenGenerator generator = RdsIamAuthTokenGenerator.builder()
.credentials(new DefaultAWSCredentialsProviderChain())
.region(region)
.build();
String authToken = generator.getAuthToken(
GetIamAuthTokenRequest.builder()
.hostname(hostName)
.port(Integer.parseInt(port))
.userName(username)
.build());
return authToken;
}
}
```
## Creazione manuale di un token di autenticazione IAM
In Java, il modo più semplice di generare un token di autenticazione è di utilizzare `RdsIamAuthTokenGenerator`. Questa classe crea un token di autenticazione per te, quindi lo firma utilizzando la versione 4 AWS della firma. Per ulteriori informazioni, consulta la pagina relativa al [processo di firma Signature Version 4](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) nella *Riferimenti generali di AWS*.
Tuttavia, puoi anche creare e firmare un token di autenticazione manualmente, come visualizzato nel seguente esempio di codice.
```
package com.amazonaws.codesamples;
import com.amazonaws.SdkClientException;
import com.amazonaws.auth.DefaultAWSCredentialsProviderChain;
import com.amazonaws.auth.SigningAlgorithm;
import com.amazonaws.util.BinaryUtils;
import org.apache.commons.lang3.StringUtils;
import javax.crypto.Mac;
import javax.crypto.spec.SecretKeySpec;
import java.nio.charset.Charset;
import java.security.MessageDigest;
import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.SortedMap;
import java.util.TreeMap;
import static com.amazonaws.auth.internal.SignerConstants.AWS4_TERMINATOR;
import static com.amazonaws.util.StringUtils.UTF8;
public class CreateRDSAuthTokenManually {
public static String httpMethod = "GET";
public static String action = "connect";
public static String canonicalURIParameter = "/";
public static SortedMap canonicalQueryParameters = new TreeMap();
public static String payload = StringUtils.EMPTY;
public static String signedHeader = "host";
public static String algorithm = "AWS4-HMAC-SHA256";
public static String serviceName = "rds-db";
public static String requestWithoutSignature;
public static void main(String[] args) throws Exception {
String region = "us-west-2";
String instanceName = "rdsmysql.123456789012.us-west-2.rds.amazonaws.com";
String port = "3306";
String username = "jane_doe";
Date now = new Date();
String date = new SimpleDateFormat("yyyyMMdd").format(now);
String dateTimeStamp = new SimpleDateFormat("yyyyMMdd'T'HHmmss'Z'").format(now);
DefaultAWSCredentialsProviderChain creds = new DefaultAWSCredentialsProviderChain();
String awsAccessKey = creds.getCredentials().getAWSAccessKeyId();
String awsSecretKey = creds.getCredentials().getAWSSecretKey();
String expiryMinutes = "900";
System.out.println("Step 1: Create a canonical request:");
String canonicalString = createCanonicalString(username, awsAccessKey, date, dateTimeStamp, region, expiryMinutes, instanceName, port);
System.out.println(canonicalString);
System.out.println();
System.out.println("Step 2: Create a string to sign:");
String stringToSign = createStringToSign(dateTimeStamp, canonicalString, awsAccessKey, date, region);
System.out.println(stringToSign);
System.out.println();
System.out.println("Step 3: Calculate the signature:");
String signature = BinaryUtils.toHex(calculateSignature(stringToSign, newSigningKey(awsSecretKey, date, region, serviceName)));
System.out.println(signature);
System.out.println();
System.out.println("Step 4: Add the signing info to the request");
System.out.println(appendSignature(signature));
System.out.println();
}
//Step 1: Create a canonical request date should be in format YYYYMMDD and dateTime should be in format YYYYMMDDTHHMMSSZ
public static String createCanonicalString(String user, String accessKey, String date, String dateTime, String region, String expiryPeriod, String hostName, String port) throws Exception {
canonicalQueryParameters.put("Action", action);
canonicalQueryParameters.put("DBUser", user);
canonicalQueryParameters.put("X-Amz-Algorithm", "AWS4-HMAC-SHA256");
canonicalQueryParameters.put("X-Amz-Credential", accessKey + "%2F" + date + "%2F" + region + "%2F" + serviceName + "%2Faws4_request");
canonicalQueryParameters.put("X-Amz-Date", dateTime);
canonicalQueryParameters.put("X-Amz-Expires", expiryPeriod);
canonicalQueryParameters.put("X-Amz-SignedHeaders", signedHeader);
String canonicalQueryString = "";
while(!canonicalQueryParameters.isEmpty()) {
String currentQueryParameter = canonicalQueryParameters.firstKey();
String currentQueryParameterValue = canonicalQueryParameters.remove(currentQueryParameter);
canonicalQueryString = canonicalQueryString + currentQueryParameter + "=" + currentQueryParameterValue;
if (!currentQueryParameter.equals("X-Amz-SignedHeaders")) {
canonicalQueryString += "&";
}
}
String canonicalHeaders = "host:" + hostName + ":" + port + '\n';
requestWithoutSignature = hostName + ":" + port + "/?" + canonicalQueryString;
String hashedPayload = BinaryUtils.toHex(hash(payload));
return httpMethod + '\n' + canonicalURIParameter + '\n' + canonicalQueryString + '\n' + canonicalHeaders + '\n' + signedHeader + '\n' + hashedPayload;
}
//Step 2: Create a string to sign using sig v4
public static String createStringToSign(String dateTime, String canonicalRequest, String accessKey, String date, String region) throws Exception {
String credentialScope = date + "/" + region + "/" + serviceName + "/aws4_request";
return algorithm + '\n' + dateTime + '\n' + credentialScope + '\n' + BinaryUtils.toHex(hash(canonicalRequest));
}
//Step 3: Calculate signature
/**
* Step 3 of the &AWS; Signature version 4 calculation. It involves deriving
* the signing key and computing the signature. Refer to
* http://docs.aws.amazon
* .com/general/latest/gr/sigv4-calculate-signature.html
*/
public static byte[] calculateSignature(String stringToSign,
byte[] signingKey) {
return sign(stringToSign.getBytes(Charset.forName("UTF-8")), signingKey,
SigningAlgorithm.HmacSHA256);
}
public static byte[] sign(byte[] data, byte[] key,
SigningAlgorithm algorithm) throws SdkClientException {
try {
Mac mac = algorithm.getMac();
mac.init(new SecretKeySpec(key, algorithm.toString()));
return mac.doFinal(data);
} catch (Exception e) {
throw new SdkClientException(
"Unable to calculate a request signature: "
+ e.getMessage(), e);
}
}
public static byte[] newSigningKey(String secretKey,
String dateStamp, String regionName, String serviceName) {
byte[] kSecret = ("AWS4" + secretKey).getBytes(Charset.forName("UTF-8"));
byte[] kDate = sign(dateStamp, kSecret, SigningAlgorithm.HmacSHA256);
byte[] kRegion = sign(regionName, kDate, SigningAlgorithm.HmacSHA256);
byte[] kService = sign(serviceName, kRegion,
SigningAlgorithm.HmacSHA256);
return sign(AWS4_TERMINATOR, kService, SigningAlgorithm.HmacSHA256);
}
public static byte[] sign(String stringData, byte[] key,
SigningAlgorithm algorithm) throws SdkClientException {
try {
byte[] data = stringData.getBytes(UTF8);
return sign(data, key, algorithm);
} catch (Exception e) {
throw new SdkClientException(
"Unable to calculate a request signature: "
+ e.getMessage(), e);
}
}
//Step 4: append the signature
public static String appendSignature(String signature) {
return requestWithoutSignature + "&X-Amz-Signature=" + signature;
}
public static byte[] hash(String s) throws Exception {
try {
MessageDigest md = MessageDigest.getInstance("SHA-256");
md.update(s.getBytes(UTF8));
return md.digest();
} catch (Exception e) {
throw new SdkClientException(
"Unable to compute hash while signing request: "
+ e.getMessage(), e);
}
}
}
```
## Connessione a un cluster database
Il seguente esempio di codice mostra come generare un token di autenticazione e utilizzarlo per eseguire la connessione a un cluster eseguendo Aurora MySQL.
Per eseguire questo esempio di codice, è necessario il [AWS SDK per Java](https://aws.amazon.com/sdk-for-java/)file, trovato sul AWS sito. Inoltre, hai bisogno di quanto segue:
+ MySQL Connector/J. Questo esempio di codice è stato testato con `mysql-connector-java-5.1.33-bin.jar`.
+ Un certificato intermedio per Amazon Aurora specifico per una regione. AWS Per ulteriori informazioni, consulta [Utilizzo SSL/TLS per crittografare una connessione a un'](UsingWithRDS.SSL.md). Durante il runtime, il loader della classe cerca un certificato nella stessa directory di questo esempio di codice Java, per permettere al loader della classe di trovarlo.
+ Modifica i valori delle variabili seguenti in base alle esigenze.
+ `RDS_INSTANCE_HOSTNAME`: il nome host del cluster database cui vuoi accedere.
+ `RDS_INSTANCE_PORT`: il numero di porta usato per la connessione al cluster database PostgreSQL.
+ `REGION_NAME`— La AWS regione in cui è in esecuzione il cluster di DB.
+ `DB_USER`: l’account database cui vuoi accedere.
+ `SSL_CERTIFICATE`— Un certificato SSL per Amazon Aurora specifico per una regione. AWS
Per scaricare un certificato per la regione AWS , consulta [Utilizzo SSL/TLS per crittografare una connessione a un'](UsingWithRDS.SSL.md). Inserisci il certificato SSL nella stessa directory di questo file di programma Java, per permettere al loader di classe di trovare il certificato durante il runtime.
[Questo esempio di codice ottiene AWS le credenziali dalla catena di provider di credenziali predefinita.](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/credentials.html#credentials-default)
**Nota**
Specifica una password per `DEFAULT_KEY_STORE_PASSWORD` diversa da quella mostrata qui come best practice di sicurezza.
```
package com.amazonaws.samples;
import com.amazonaws.services.rds.auth.RdsIamAuthTokenGenerator;
import com.amazonaws.services.rds.auth.GetIamAuthTokenRequest;
import com.amazonaws.auth.BasicAWSCredentials;
import com.amazonaws.auth.DefaultAWSCredentialsProviderChain;
import com.amazonaws.auth.AWSStaticCredentialsProvider;
import java.io.File;
import java.io.FileOutputStream;
import java.io.InputStream;
import java.security.KeyStore;
import java.security.cert.CertificateFactory;
import java.security.cert.X509Certificate;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.Statement;
import java.util.Properties;
import java.net.URL;
public class IAMDatabaseAuthenticationTester {
//&AWS; Credentials of the IAM user with policy enabling IAM Database Authenticated access to the db by the db user.
private static final DefaultAWSCredentialsProviderChain creds = new DefaultAWSCredentialsProviderChain();
private static final String AWS_ACCESS_KEY = creds.getCredentials().getAWSAccessKeyId();
private static final String AWS_SECRET_KEY = creds.getCredentials().getAWSSecretKey();
//Configuration parameters for the generation of the IAM Database Authentication token
private static final String RDS_INSTANCE_HOSTNAME = "rdsmysql.123456789012.us-west-2.rds.amazonaws.com";
private static final int RDS_INSTANCE_PORT = 3306;
private static final String REGION_NAME = "us-west-2";
private static final String DB_USER = "jane_doe";
private static final String JDBC_URL = "jdbc:mysql://" + RDS_INSTANCE_HOSTNAME + ":" + RDS_INSTANCE_PORT;
private static final String SSL_CERTIFICATE = "rds-ca-2019-us-west-2.pem";
private static final String KEY_STORE_TYPE = "JKS";
private static final String KEY_STORE_PROVIDER = "SUN";
private static final String KEY_STORE_FILE_PREFIX = "sys-connect-via-ssl-test-cacerts";
private static final String KEY_STORE_FILE_SUFFIX = ".jks";
private static final String DEFAULT_KEY_STORE_PASSWORD = "changeit";
public static void main(String[] args) throws Exception {
//get the connection
Connection connection = getDBConnectionUsingIam();
//verify the connection is successful
Statement stmt= connection.createStatement();
ResultSet rs=stmt.executeQuery("SELECT 'Success!' FROM DUAL;");
while (rs.next()) {
String id = rs.getString(1);
System.out.println(id); //Should print "Success!"
}
//close the connection
stmt.close();
connection.close();
clearSslProperties();
}
/**
* This method returns a connection to the db instance authenticated using IAM Database Authentication
* @return
* @throws Exception
*/
private static Connection getDBConnectionUsingIam() throws Exception {
setSslProperties();
return DriverManager.getConnection(JDBC_URL, setMySqlConnectionProperties());
}
/**
* This method sets the mysql connection properties which includes the IAM Database Authentication token
* as the password. It also specifies that SSL verification is required.
* @return
*/
private static Properties setMySqlConnectionProperties() {
Properties mysqlConnectionProperties = new Properties();
mysqlConnectionProperties.setProperty("verifyServerCertificate","true");
mysqlConnectionProperties.setProperty("useSSL", "true");
mysqlConnectionProperties.setProperty("user",DB_USER);
mysqlConnectionProperties.setProperty("password",generateAuthToken());
return mysqlConnectionProperties;
}
/**
* This method generates the IAM Auth Token.
* An example IAM Auth Token would look like follows:
* btusi123---cmz7kenwo2ye---rds---cn-north-1.amazonaws.com.rproxy.goskope.com.cn:3306/?Action=connect&DBUser=iamtestuser&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20171003T010726Z&X-Amz-SignedHeaders=host&X-Amz-Expires=899&X-Amz-Credential=AKIAPFXHGVDI5RNFO4AQ%2F20171003%2Fcn-north-1%2Frds-db%2Faws4_request&X-Amz-Signature=f9f45ef96c1f770cdad11a53e33ffa4c3730bc03fdee820cfdf1322eed15483b
* @return
*/
private static String generateAuthToken() {
BasicAWSCredentials awsCredentials = new BasicAWSCredentials(AWS_ACCESS_KEY, AWS_SECRET_KEY);
RdsIamAuthTokenGenerator generator = RdsIamAuthTokenGenerator.builder()
.credentials(new AWSStaticCredentialsProvider(awsCredentials)).region(REGION_NAME).build();
return generator.getAuthToken(GetIamAuthTokenRequest.builder()
.hostname(RDS_INSTANCE_HOSTNAME).port(RDS_INSTANCE_PORT).userName(DB_USER).build());
}
/**
* This method sets the SSL properties which specify the key store file, its type and password:
* @throws Exception
*/
private static void setSslProperties() throws Exception {
System.setProperty("javax.net.ssl.trustStore", createKeyStoreFile());
System.setProperty("javax.net.ssl.trustStoreType", KEY_STORE_TYPE);
System.setProperty("javax.net.ssl.trustStorePassword", DEFAULT_KEY_STORE_PASSWORD);
}
/**
* This method returns the path of the Key Store File needed for the SSL verification during the IAM Database Authentication to
* the db instance.
* @return
* @throws Exception
*/
private static String createKeyStoreFile() throws Exception {
return createKeyStoreFile(createCertificate()).getPath();
}
/**
* This method generates the SSL certificate
* @return
* @throws Exception
*/
private static X509Certificate createCertificate() throws Exception {
CertificateFactory certFactory = CertificateFactory.getInstance("X.509");
URL url = new File(SSL_CERTIFICATE).toURI().toURL();
if (url == null) {
throw new Exception();
}
try (InputStream certInputStream = url.openStream()) {
return (X509Certificate) certFactory.generateCertificate(certInputStream);
}
}
/**
* This method creates the Key Store File
* @param rootX509Certificate - the SSL certificate to be stored in the KeyStore
* @return
* @throws Exception
*/
private static File createKeyStoreFile(X509Certificate rootX509Certificate) throws Exception {
File keyStoreFile = File.createTempFile(KEY_STORE_FILE_PREFIX, KEY_STORE_FILE_SUFFIX);
try (FileOutputStream fos = new FileOutputStream(keyStoreFile.getPath())) {
KeyStore ks = KeyStore.getInstance(KEY_STORE_TYPE, KEY_STORE_PROVIDER);
ks.load(null);
ks.setCertificateEntry("rootCaCertificate", rootX509Certificate);
ks.store(fos, DEFAULT_KEY_STORE_PASSWORD.toCharArray());
}
return keyStoreFile;
}
/**
* This method clears the SSL properties.
* @throws Exception
*/
private static void clearSslProperties() throws Exception {
System.clearProperty("javax.net.ssl.trustStore");
System.clearProperty("javax.net.ssl.trustStoreType");
System.clearProperty("javax.net.ssl.trustStorePassword");
}
}
```
Se desideri connetterti a un cluster di database tramite un proxy, consulta [Connessione a un database tramite l'autenticazione IAM](rds-proxy-connecting.md#rds-proxy-connecting-iam).
# Connessione al cluster di DB utilizzando l'autenticazione IAM e il AWS SDK per Python (Boto3)
È possibile connettersi a un cluster come descritto di seguito. AWS SDK per Python (Boto3)
**Prerequisiti**
Di seguito sono riportati i prerequisiti per la connessione alcluster di DB utilizzando l’autenticazione IAM:
+ [Abilitazione e disabilitazione dell’autenticazione database IAM](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [Creazione e utilizzo di una policy IAM per l'accesso al database IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [Creazione di un account database tramite l’autenticazione IAM](UsingWithRDS.IAMDBAuth.DBAccounts.md)
Inoltre, assicurarsi che le librerie importate nel codice di esempio esistano nel sistema.
**Esempi**
Gli esempi di codice utilizzano i profili per le credenziali condivise. [Per informazioni sulla specificazione delle credenziali, AWS SDK per Python (Boto3) consulta Credenziali nella documentazione.](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/credentials.html)
Il seguente esempio di codice mostra come generare un token di autenticazione e utilizzarlo per eseguire la connessione a un cluster del database.
Per eseguire questo esempio di codice, è necessario il file [AWS SDK per Python (Boto3)](https://aws.amazon.com/sdk-for-python/), trovato sul sito. AWS
Modifica i valori delle variabili seguenti in base alle esigenze.
+ `ENDPOINT`: l'endpoint del cluster di database cui vuoi accedere
+ `PORT` – Numero di porta usato per la connessione al dell'istanza database
+ `USER` – L'account database cui vuoi accedere.
+ `REGION`— La AWS regione in cui è in esecuzione il cluster di DB
+ `DBNAME` – Database a cui accedere.
+ `SSLCERTIFICATE` - Percorso completo del certificato SSL per Amazon Aurora
Per `ssl_ca`, specificare un certificato SSL. Per scaricare un certificato SSL consulta [Utilizzo SSL/TLS per crittografare una connessione a un'](UsingWithRDS.SSL.md)
**Nota**
Non è possibile utilizzare un record DNS Route 53 personalizzato anziché l'endpoint del cluster di databaseper generare il token di autenticazione.
Questo codice si connette a un cluster di database Aurora MySQL.
Prima di eseguire questo codice, installa il driver PyMy SQL seguendo le istruzioni nel [Python Package](https://pypi.org/project/PyMySQL/) Index.
```
import pymysql
import sys
import boto3
import os
ENDPOINT="mysqlcluster.cluster-123456789012.us-east-1.rds.amazonaws.com"
PORT="3306"
USER="jane_doe"
REGION="us-east-1"
DBNAME="mydb"
os.environ['LIBMYSQL_ENABLE_CLEARTEXT_PLUGIN'] = '1'
#gets the credentials from .aws/credentials
session = boto3.Session(profile_name='default')
client = session.client('rds')
token = client.generate_db_auth_token(DBHostname=ENDPOINT, Port=PORT, DBUsername=USER, Region=REGION)
try:
conn = pymysql.connect(auth_plugin_map={'mysql_clear_password':None},host=ENDPOINT, user=USER, password=token, port=PORT, database=DBNAME, ssl_ca='SSLCERTIFICATE', ssl_verify_identity=True, ssl_verify_cert=True)
cur = conn.cursor()
cur.execute("""SELECT now()""")
query_results = cur.fetchall()
print(query_results)
except Exception as e:
print("Database connection failed due to {}".format(e))
```
Questo codice si connette a un cluster di database Aurora PostgreSQL.
Prima di eseguire questo codice, installa`psycopg2`seguendo le istruzioni in [Documentazione di Psycopg](https://pypi.org/project/psycopg2/).
```
import psycopg2
import sys
import boto3
import os
ENDPOINT="postgresmycluster.cluster-123456789012.us-east-1.rds.amazonaws.com"
PORT="5432"
USER="jane_doe"
REGION="us-east-1"
DBNAME="mydb"
#gets the credentials from .aws/credentials
session = boto3.Session(profile_name='RDSCreds')
client = session.client('rds')
token = client.generate_db_auth_token(DBHostname=ENDPOINT, Port=PORT, DBUsername=USER, Region=REGION)
try:
conn = psycopg2.connect(host=ENDPOINT, port=PORT, database=DBNAME, user=USER, password=token, sslrootcert="SSLCERTIFICATE")
cur = conn.cursor()
cur.execute("""SELECT now()""")
query_results = cur.fetchall()
print(query_results)
except Exception as e:
print("Database connection failed due to {}".format(e))
```
Se desideri connetterti a un cluster di database tramite un proxy, consulta [Connessione a un database tramite l'autenticazione IAM](rds-proxy-connecting.md#rds-proxy-connecting-iam).
# Risoluzione dei problemi relativi all’autenticazione database IAM
Di seguito, è possibile trovare idee per la risoluzione dei problemi comuni relativi all’autenticazione database IAM e informazioni sui log e sulle metriche di CloudWatch relativi all’autenticazione database IAM.
## Esportazione di log degli errori di autenticazione database IAM su CloudWatch Logs
I log degli errori di autenticazione database IAM sono archiviati sull’host del database e li puoi esportare nel tuo account CloudWatch Logs. Utilizza i log e i metodi di correzione in questa pagina per risolvere i problemi relativi all’autenticazione database IAM.
È possibile abilitare le esportazioni dei log verso CloudWatch Logs dalla console, dalla AWS CLI e dall’API RDS. Per istruzioni relative alla console, consulta [Pubblicazione di log di database su Amazon CloudWatch Logs](USER_LogAccess.Procedural.UploadtoCloudWatch.md).
Per esportare i log degli errori di autenticazione database IAM in CloudWatch Logs durante la modifica di un cluster di database dalla AWS CLI, usa il seguente comando:
```
aws rds create-db-cluster --db-cluster-identifier mydbinstance \
--region us-east-1 \
--engine postgres \
--engine-version 16 \
--master-username master \
--master-user-password password \
--publicly-accessible \
--enable-iam-database-authentication \
--enable-cloudwatch-logs-exports=iam-db-auth-error
```
Per esportare i log degli errori di autenticazione database IAM in CloudWatch Logs durante la modifica di un cluster di database dalla AWS CLI, usa il seguente comando:
```
aws rds modify-db-cluster --db-cluster-identifier mydbcluster \
--region us-east-1 \
--cloudwatch-logs-export-configuration '{"EnableLogTypes":["iam-db-auth-error"]}'
```
Per verificare se il cluster di database sta esportando i log di autenticazione database IAM su CloudWatch Logs, controlla se il parametro `EnabledCloudwatchLogsExports` è impostato a `iam-db-auth-error` nell’output del comando `describe-db-instances`.
```
aws rds describe-db-cluster --region us-east-1 --db-cluster-identifier mydbcluster
...
"EnabledCloudwatchLogsExports": [
"iam-db-auth-error"
],
...
```
## Metriche CloudWatch relative all’autenticazione database IAM
Amazon Aurora fornisce metriche quasi in tempo reale sull’autenticazione database IAM al tuo account Amazon CloudWatch. Nella tabella seguente sono elencati le metriche di autenticazione database IAM e le dimensioni disponibili con CloudWatch:
| Parametro | Descrizione |
| --- | --- |
| `IamDbAuthConnectionRequests` | Numero totale di richieste di connessione effettuate con l’autenticazione database IAM. |
| `IamDbAuthConnectionSuccess` | Numero totale di richieste di autenticazione database IAM riuscite. |
| `IamDbAuthConnectionFailure` | Numero totale di richieste di autenticazione database IAM non riuscite. |
| `IamDbAuthConnectionFailureInvalidToken` | Numero totale di richieste di autenticazione database IAM non riuscite a causa di un token non valido. |
| `IamDbAuthConnectionFailureInsufficientPermissions` | Numero totale di richieste di autenticazione database IAM non riuscite a causa di policy o autorizzazioni errate. |
| `IamDbAuthConnectionFailureThrottling` | Numero totale di richieste di autenticazione database IAM non riuscite a causa della limitazione (della larghezza di banda della rete) per l’autenticazione database IAM. |
| `IamDbAuthConnectionFailureServerError` | Numero totale di richieste di autenticazione database IAM non riuscite a causa di un errore interno del server nella funzionalità di autenticazione database IAM. |
## Problemi e soluzioni comuni
È possibile che si verifichino i seguenti problemi durante l’utilizzo dell’autenticazione database IAM. Utilizza i passaggi di correzione indicati nella tabella per risolvere i problemi:
| Errore | Metrica/metriche | Causa | Soluzione |
| --- | --- | --- | --- |
| `[ERROR] Failed to authenticate the connection request for user db_user because the provided token is malformed or otherwise invalid. (Status Code: 400, Error Code: InvalidToken)` | `IamDbAuthConnectionFailure` `IamDbAuthConnectionFailureInvalidToken` | Il token di autenticazione database IAM nella richiesta di connessione non è un token SigV4a valido o non è formattato correttamente. | Controlla la tua strategia di generazione di token nella tua applicazione. In alcuni casi, assicurati di passare il token con una formattazione valida. La troncatura del token (o la formattazione errata della stringa) renderà il token non valido. |
| `[ERROR] Failed to authenticate the connection request for user db_user because the token age is longer than 15 minutes. (Status Code: 400, Error Code:ExpiredToken)` | `IamDbAuthConnectionFailure` `IamDbAuthConnectionFailureInvalidToken` | Il token di autenticazione database IAM è scaduto. I token sono validi solo per 15 minuti. | Controlla la logica di memorizzazione nella cache dei token e/o di riutilizzo dei token nell’applicazione. Non riutilizzare token più vecchi di 15 minuti. |
| `[ERROR] Failed to authorize the connection request for user db_user because the IAM policy assumed by the caller 'arn:aws:sts::123456789012:assumed-role/ / ' is not authorized to perform `rds-db:connect` on the DB instance. (Status Code: 403, Error Code:NotAuthorized)` | `IamDbAuthConnectionFailure` `IamDbAuthConnectionFailureInsufficientPermissions` | Questo errore potrebbe essere dovuto ai seguenti fattori: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.Troubleshooting.html) | Verifica il ruolo e/o la policy IAM che stai assumendo nella tua applicazione. Assicurati di assumere la stessa policy per generare il token utilizzata per la connessione al database. |
| `[ERROR] Failed to authorize the connection request for user db_user due to IAM DB authentication throttling. (Status Code: 429, Error Code: ThrottlingException)` | `IamDbAuthConnectionFailure` `IamDbAuthConnectionFailureThrottling` | Stai effettuando troppe richieste di connessione al tuo database in un breve lasso di tempo. La limitazione (della larghezza di banda della rete) per l’autenticazione database IAM è di 200 connessioni al secondo. | Riduci la velocità di creazione di nuove connessioni con l’autenticazione IAM. Prendi in considerazione l’implementazione del pool di connessioni utilizzando Server proxy per RDS per riutilizzare le connessioni stabilite nell’applicazione. |
| `[ERROR] Failed to authorize the connection request for user db_user due to an internal IAM DB authentication error. (Status Code: 500, Error Code: InternalError)` | `IamDbAuthConnectionFailure` `IamDbAuthConnectionFailureThrottling` | Si è verificato un errore interno durante l’autorizzazione della connessione database con l’autenticazione database IAM. | Contatta https://aws.amazon.com/premiumsupport/ per indagare sul problema. |
# Risoluzione dei problemi di identità e accesso in Amazon Aurora
Utilizza le informazioni seguenti per diagnosticare e risolvere i problemi comuni che possono verificarsi durante l'utilizzo di Aurora e IAM.
**Topics**
+ [Non sono autorizzato a eseguire un'operazione in Aurora](#security_iam_troubleshoot-no-permissions)
+ [Non sono autorizzato a eseguire iam: PassRole](#security_iam_troubleshoot-passrole)
+ [Desidero consentire a persone esterne al mio AWS account di accedere alle mie risorse Aurora](#security_iam_troubleshoot-cross-account-access)
## Non sono autorizzato a eseguire un'operazione in Aurora
Se ti Console di gestione AWS dice che non sei autorizzato a eseguire un'azione, devi contattare l'amministratore per ricevere assistenza. L’amministratore è colui che ti ha fornito le credenziali di accesso.
L'errore di esempio seguente si verifica quando l'`mateojackson`utente tenta di utilizzare la console per visualizzare i dettagli su un *widget* ma non dispone `rds:GetWidget` delle autorizzazioni.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: rds:GetWidget on resource: my-example-widget
```
In questo caso, Mateo chiede al suo amministratore di aggiornare le policy per poter accedere alla risorsa `my-example-widget` mediante l'operazione `rds:GetWidget`.
## Non sono autorizzato a eseguire iam: PassRole
Se ricevi un errore che indica che non sei autorizzato a eseguire l'operazione `iam:PassRole`, devi contattare il tuo amministratore per ricevere assistenza. L’amministratore è colui che ti ha fornito le credenziali di accesso. Richiedi a tale persona di aggiornare le tue policy per poter passare un ruolo a Aurora.
Alcuni AWS servizi consentono di trasferire un ruolo esistente a quel servizio, anziché creare un nuovo ruolo di servizio o un ruolo collegato al servizio. Per eseguire questa operazione, è necessario disporre delle autorizzazioni per trasmettere il ruolo al servizio.
L'errore di esempio seguente si verifica quando un utente denominato `marymajor` cerca di utilizzare la console per eseguire un'operazione in Aurora. Tuttavia, l'operazione richiede che il servizio disponga delle autorizzazioni concesse da un ruolo di servizio. Mary non dispone di autorizzazioni per passare il ruolo al servizio.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
In questo caso, Mary chiede all'amministratore di aggiornare la sue policy per poter eseguire l'operazione `iam:PassRole`.
## Desidero consentire a persone esterne al mio AWS account di accedere alle mie risorse Aurora
È possibile creare un ruolo con il quale utenti in altri account o persone esterne all’organizzazione possono accedere alle tue risorse. È possibile specificare chi è attendibile per l’assunzione del ruolo. Per i servizi che supportano politiche basate sulle risorse o liste di controllo degli accessi (ACLs), puoi utilizzare tali policy per consentire alle persone di accedere alle tue risorse.
Per maggiori informazioni, consulta gli argomenti seguenti:
+ Per capire se Aurora supporta queste funzionalità, consulta [Funzionamento di Amazon Aurora con IAM](security_iam_service-with-iam.md).
+ Per scoprire come fornire l'accesso alle tue risorse su più AWS account di tua proprietà, consulta [Fornire l'accesso a un utente IAM in un altro AWS account di tua proprietà nella Guida](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) per l'utente *IAM*.
+ Per scoprire come fornire l'accesso alle tue risorse ad AWS account di terze parti, consulta [Fornire l'accesso agli AWS account di proprietà di terze parti](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) nella *Guida per l'utente IAM*.
+ Per informazioni su come fornire l’accesso tramite la federazione delle identità, consulta [Fornire l’accesso a utenti autenticati esternamente (Federazione delle identità)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) nella *Guida per l’utente IAM*.
+ Per informazioni sulle differenze tra l'utilizzo di ruoli e policy basate su risorse per l'accesso multi-account, consultare [Differenza tra i ruoli IAM e le policy basate su risorse](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html) nella *Guida per l'utente di IAM*.
# Registrazione e monitoraggio in
Il monitoraggio è una parte importante per mantenere l'affidabilità, la disponibilità e le prestazioni di Amazon Aurora e AWS delle tue soluzioni. È necessario raccogliere i dati di monitoraggio da tutte le parti della AWS soluzione in modo da poter eseguire più facilmente il debug di un errore multipunto, se si verifica. AWS offre diversi strumenti per monitorare le risorse Amazon Aurora e rispondere a potenziali incidenti:
** CloudWatch Allarmi Amazon**
Utilizzando Amazon CloudWatch alarms, controlli una singola metrica per un periodo di tempo specificato. Se la metrica supera una determinata soglia, viene inviata una notifica a un argomento o una policy di Amazon SNS. AWS Auto Scaling CloudWatch gli allarmi non richiamano azioni perché si trovano in uno stato particolare. È necessario invece cambiare lo stato e mantenerlo per un numero di periodi specificato.
**AWS CloudTrail Registri**
CloudTrail fornisce un registro delle azioni intraprese da un utente, un ruolo o un AWS servizio in . CloudTrail acquisisce tutte le chiamate API per Amazon Aurora come eventi, incluse le chiamate dalla console e le chiamate di codice alle operazioni dell'API Amazon RDS. Utilizzando le informazioni raccolte da CloudTrail, puoi determinare la richiesta effettuata ad Aurora, l'indirizzo IP da cui è stata effettuata la richiesta, chi ha effettuato la richiesta, quando è stata effettuata e dettagli aggiuntivi. Per ulteriori informazioni, consulta [Monitoraggio delle chamate API di Amazon Aurora in AWS CloudTrail](logging-using-cloudtrail.md).
**Monitoraggio avanzato**
Amazon Aurora fornisce le metriche in tempo reale per il sistema operativo sul quale è in esecuzione il cluster di database. Puoi visualizzare i parametri per il tuo cluster di DB utilizzando la console o utilizzare l'output JSON di Enhanced Monitoring di Amazon CloudWatch Logs in un sistema di monitoraggio a tua scelta. Per ulteriori informazioni, consulta [Monitoraggio dei parametri del sistema operativo con il monitoraggio avanzato](USER_Monitoring.OS.md).
**Performance Insights di Amazon RDS**
Approfondimenti sulle prestazioni amplia le funzionalità di monitoraggio esistenti di Amazon Aurora per illustrare le prestazioni del database e consentire l’analisi di eventuali problemi che lo riguardano. Con il pannello di controllo di Performance Insights, è possibile visualizzare il carico del database e filtrare il carico in base alle attese, alle istruzioni SQL, agli host o agli utenti. Per ulteriori informazioni, consulta [Monitoraggio del carico DB con Performance Insights su Amazon Aurora](USER_PerfInsights.md).
**Log di database**
Puoi visualizzare, scaricare e guardare i log del database utilizzando l'API o Console di gestione AWS RDS AWS CLI. Per ulteriori informazioni, consulta [Monitoraggio dei file di log di Amazon Aurora](USER_LogAccess.md).
** Raccomandazioni di Amazon Aurora**
Amazon Aurora offre raccomandazioni automatiche per le risorse di database. Queste raccomandazioni forniscono consigli sulle best practice analizzando la configurazione, l’utilizzo e i dati sulle prestazioni del cluster di database. Per ulteriori informazioni, consulta [Suggerimenti di Amazon Aurora](monitoring-recommendations.md).
** Notifiche di eventi Amazon Aurora**
Amazon Aurora utilizza Amazon Simple Notification Service (Amazon SNS) per fornire una notifica quando si verifica un evento Amazon Aurora. Queste notifiche possono essere in qualsiasi modulo di notifica supportato da Amazon SNS per una AWS regione, ad esempio un'e-mail, un messaggio di testo o una chiamata a un endpoint HTTP. Per ulteriori informazioni, consulta [Utilizzo della notifica degli eventi di Amazon RDS](USER_Events.md).
**AWS Trusted Advisor**
Trusted Advisor si basa sulle best practice apprese servendo centinaia di migliaia di AWS clienti. Trusted Advisor ispeziona l' AWS ambiente e quindi formula raccomandazioni quando esistono opportunità per risparmiare denaro, migliorare la disponibilità e le prestazioni del sistema o contribuire a colmare le lacune di sicurezza. Tutti i AWS clienti hanno accesso a cinque Trusted Advisor controlli. I clienti con un piano di supporto Business o Enterprise possono visualizzare tutti i Trusted Advisor controlli.
Trusted Advisor dispone dei seguenti controlli Amazon Aurora:
+ Istanze database Amazon Aurora inattive
+ Rischio accesso gruppo di sicurezza Amazon Aurora
+ Backup Amazon Aurora
+ Multi-AZ Amazon Aurora
+ Accessibilità dell’istanza database Aurora
Per ulteriori informazioni su questi controlli, consulta [best practice Trusted Advisor (Controlli)](https://aws.amazon.com/premiumsupport/trustedadvisor/best-practices/).
**Flussi di attività di database**
I flussi di attività di database proteggono i database da minacce interne controllando l'accesso DBA ai flussi di attività di database. Pertanto, la raccolta, la trasmissione, l'archiviazione e la successiva elaborazione del flusso di attività del database esulano dall'accesso di chi gestisce DBAs il database. Gli stream dell'attività di database consentono di fornire protezioni per il database e soddisfare requisiti normativi e di conformità. Per ulteriori informazioni, consulta [Monitoraggio di Amazon Aurora tramite i flussi di attività del database](DBActivityStreams.md).
Per ulteriori informazioni sul monitoraggio di Aurora, consulta [Monitoraggio dei parametri in un cluster di database Amazon Aurora](MonitoringAurora.md).
# Convalida della conformità per Amazon Aurora
Revisori di terze parti valutano la sicurezza e la conformità di Amazon Aurora come parte di più programmi di conformità di AWS. Questi includono SOC, PCI, FedRAMP, HIPAA e altri.
Per un elenco dei AWS servizi che rientrano nell'ambito di specifici programmi di conformità, consulta la sezione [AWSServizi rientranti nell'ambito di un programma di conformità](https://aws.amazon.com/compliance/services-in-scope/). Per informazioni generali, consultare [Programmi per la conformità di AWS](https://aws.amazon.com/compliance/programs/).
È possibile scaricare report di audit di terze parti utilizzandoAWS Artifact. Per ulteriori informazioni, consulta [Scaricamento dei report in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html).
La tua responsabilità di conformità quando usi Amazon Aurora è determinata dalla sensibilità dei tuoi dati, dagli obiettivi di conformità dell'organizzazione e dalle leggi e dai regolamenti applicabili. AWSfornisce le seguenti risorse per contribuire alla conformità:
+ [Guide introduttive su sicurezza e conformità](https://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance): queste guide all'implementazione illustrano considerazioni sull'architettura e forniscono passaggi per implementare ambienti di base incentrati sulla sicurezza e la conformità. AWS
+ [Progettazione per la sicurezza e la conformità HIPAA su Amazon Web Services](https://docs.aws.amazon.com/pdfs/whitepapers/latest/architecting-hipaa-security-and-compliance-on-aws/architecting-hipaa-security-and-compliance-on-aws.pdf): questo white paper descrive come le aziende possono utilizzare AWS per creare applicazioni conformi allo standard HIPAA.
+ [AWSrisorse per la conformità](https://aws.amazon.com/compliance/resources/): questa raccolta di cartelle di lavoro e guide che potrebbero riguardare il tuo settore e la tua area geografica.
+ [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)— Questo AWS servizio valuta la conformità delle configurazioni delle risorse alle pratiche interne, alle linee guida del settore e alle normative.
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)— Ciò Servizio AWS fornisce una visione completa dello stato di sicurezza dell'utente all'interno. AWS Security Hub CSPM utilizza i controlli di sicurezza per valutare le AWS risorse e verificare la conformità rispetto agli standard e alle migliori pratiche del settore della sicurezza. Per un elenco dei servizi e dei controlli supportati, consulta il riferimento ai controlli [CSPM di Security Hub](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-controls-reference.html).
# Resilienza in Amazon Aurora
L'infrastruttura globale di AWS è basata su regioni AWS e zone di disponibilità. AWS forniscono più zone di disponibilità fisicamente separate e isolate che sono connesse tramite reti altamente ridondanti, a bassa latenza e con throughput elevato. Con le zone di disponibilità, è possibile progettare e gestire applicazioni e database che eseguono il failover automatico tra zone di disponibilità senza interruzioni. Le zone di disponibilità sono più disponibili, tolleranti ai guasti e scalabili rispetto alle infrastrutture tradizionali a data center singolo o multiplo.
Per ulteriori informazioni sulle regioni e le zone di disponibilità AWS, consulta [Infrastruttura globale di AWS](https://aws.amazon.com/about-aws/global-infrastructure/).
Oltre all'infrastruttura globale AWS, Aurora offre numerose funzionalità per supportare la resilienza dei dati e le esigenze di backup.
## Backup e ripristino
Aurora esegue automaticamente il backup del volume del cluster e conserva i dati per la durata del *tempo di conservazione del backup*. I backup Aurora sono continui e incrementali, in modo da poter eseguire rapidamente un ripristino da qualsiasi punto del tempo di conservazione del backup. Durante la scrittura dei dati di backup, non si verifica alcun impatto sulle prestazioni o interruzione del funzionamento del servizio del database. Puoi specificare un tempo di conservazione del backup, da 1 a 35 giorni, durante la creazione o la modifica di un cluster di database.
Se desideri conservare un backup oltre il tempo di conservazione del backup, puoi anche eseguire uno snapshot dei dati del volume del cluster. Aurora mantiene i dati di ripristino incrementali per l'intero tempo di conservazione del backup. Quindi, è sufficiente creare uno snapshot per i dati che desideri conservare oltre il tempo di conservazione del backup. Puoi creare un nuovo cluster di database dalla snapshot.
Puoi recuperare i dati creando un nuovo cluster di database Aurora dai dati di backup conservati da Aurora o da uno snapshot del cluster di database salvata. Puoi ripristinare rapidamente una nuova copia di un cluster di database creato dai dati di backup a un momento qualsiasi del tempo di conservazione del backup. Data la natura continua e incrementale dei backup di Aurora a durante il tempo di conservazione del backup, non dovrai effettuare snapshot frequenti dei dati per migliorare i tempi di ripristino.
Per ulteriori informazioni, consulta [Backup e ripristino di un cluster DB Amazon Aurora](BackupRestoreAurora.md).
## Replica
Le repliche Aurora sono endpoint indipendenti in un cluster di database Aurora, utilizzati al meglio per operazioni di dimensionamento della lettura e maggiore disponibilità. È possibile distribuire fino a 15 repliche di Aurora nelle zone di disponibilità sulle quali si estende un cluster di database in una regione AWS. Il volume del cluster di database si compone di più copie dei dati per il cluster di database. Tuttavia, i dati nel volume del cluster sono rappresentati come singolo volume logico all'istanza database primaria e alle repliche di Aurora nel cluster di database. Se l'istanza database primaria non va a buon fine, una replica di Aurora viene promossa a istanza primaria.
Aurora supporta inoltre opzioni di replica specifiche per Aurora MySQL e Aurora PostgreSQL.
Per ulteriori informazioni, consulta [Replica con Amazon Aurora](Aurora.Replication.md).
## Failover
Aurora memorizza copie di dati in un cluster di database in più zone di disponibilità in una singola regione AWS. Lo storage avviene indipendentemente dal fatto che le istanze database nel cluster di database comprendano più zone di disponibilità. Quando si creano repliche di Aurora tra le zone di disponibilità, Aurora effettua automaticamente il provisioning e le mantiene in modo sincrono. L'istanza database primaria viene replicata in modo sincrono nelle zone di disponibilità sulle repliche di Aurora per fornire ridondanza dati, eliminare blocchi I/O e ridurre al minimo i picchi di latenza durante i backup di sistema. Eseguendo un cluster di database con disponibilità elevata, è possibile migliorare la disponibilità durante la manutenzione pianificata del sistema e consentire di proteggere i database da errori e interruzioni relative alle zone di disponibilità.
Per ulteriori informazioni, consulta [Elevata disponibilità di Amazon Aurora](Concepts.AuroraHighAvailability.md).
# Sicurezza dell'infrastruttura in Amazon Aurora
In quanto servizio gestito, Amazon Relational Database Service è protetto AWS dalla sicurezza di rete globale. Per informazioni sui servizi di AWS sicurezza e su come AWS protegge l'infrastruttura, consulta [AWS Cloud Security](https://aws.amazon.com/security/). Per progettare il tuo AWS ambiente utilizzando le migliori pratiche per la sicurezza dell'infrastruttura, vedi [Infrastructure Protection](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) in *Security Pillar AWS Well‐Architected* Framework.
Utilizzi chiamate API AWS pubblicate per accedere ad Amazon RDS attraverso la rete. I client devono supportare quanto segue:
+ Transport Layer Security (TLS). È richiesto TLS 1.2 ed è consigliato TLS 1.3.
+ Suite di cifratura con Perfect Forward Secrecy (PFS), ad esempio Ephemeral Diffie-Hellman (DHE) o Elliptic Curve Ephemeral Diffie-Hellman (ECDHE). La maggior parte dei sistemi moderni, come Java 7 e versioni successive, supporta tali modalità.
Inoltre, Aurora offre funzionalità che contribuiscono a supportare la sicurezza dell'infrastruttura.
## Gruppi di sicurezza
I gruppi di sicurezza controllano l'accesso del traffico in entrata e in uscita di un cluster database. Per impostazione predefinita, l'accesso alla rete è disattivato per un cluster database. Puoi specificare delle norme in un gruppo di sicurezza che consente l'accesso da un intervallo di indirizzi IP, dalla porta o da un gruppo di sicurezza. Una volta configurate le regole in ingresso, si applicano le stesse regole a tutti i cluster database con associazione a tale gruppo di sicurezza.
Per ulteriori informazioni, consulta [Controllo dell'accesso con i gruppi di sicurezza](Overview.RDSSecurityGroups.md).
## Public accessibility (Accesso pubblico)
Quando si avvia un'istanza database all'interno di un cloud privato virtuale (VPC) in base al servizio Amazon VPC, è possibile attivare o disattivare l'accessibilità pubblica per tale istanza database. Per stabilire se l'istanza database creata ha un nome DNS che si risolve in un indirizzo IP pubblico, utilizza il parametro *Public accessibility (Accessibilità pubblica)*. Questo parametro consente di stabilire se esiste un accesso pubblico all'istanza database. È possibile modificare un'istanza database per attivare o disattivare l'accessibilità pubblica modificando il parametro *Public accessibility (Accessibilità pubblica)*.
Per ulteriori informazioni, consulta [Nascondere cluster database in un VPC da Internet](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.Hiding).
**Nota**
Se la tua istanza DB si trova in un VPC ma non è accessibile pubblicamente, puoi anche utilizzare una connessione AWS Site-to-Site VPN o una Direct Connect connessione per accedervi da una rete privata. Per ulteriori informazioni, consulta [Riservatezza del traffico Internet](inter-network-traffic-privacy.md).
# API Amazon RDS ed endpoint VPC dell'interfaccia (AWS PrivateLink)
È possibile stabilire una connessione privata tra gli endpoint VPC e l'API Amazon RDS creando un *endpoint VPC di interfaccia*. Endpoint di interfaccia con tecnologia [AWS PrivateLink](https://aws.amazon.com/privatelink).
AWS PrivateLink consente di accedere in modo privato alle operazioni API di Amazon RDS senza un gateway Internet, un dispositivo NAT, una connessione VPN o una connessione. Direct Connect Le istanze database nel VPC non necessitano di indirizzi IP pubblici per comunicare con gli endpoint dell'API Amazon RDS per avviare, modificare o terminare le istanze database e i cluster DB. Inoltre, le istanze database non richiedono indirizzi IP pubblici per utilizzare le operazioni dell'API RDS disponibili. Il traffico di rete tra il VPC e Amazon RDS non esce dalla rete Amazon.
Ogni endpoint dell'interfaccia è rappresentato da una o più interfacce di rete elastiche nelle sottoreti. Per maggiori informazioni sulle interfacce di rete elastiche, consulta le [interfacce di rete elastiche](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) nella *Guida dell'utente di Amazon EC2.*
Per ulteriori informazioni sugli endpoint dei VPC, consulta [Endpoint VPC di interfaccia (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html) nella *Guida per l'utente di Amazon VPC*. Per informazioni sulle operazioni API RDS, consulta [Documentazione di riferimento delle API di Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/).
Non è necessaria un'interfaccia endpoint VPC per connettersi a un cluster database. Per ulteriori informazioni, consulta [Scenari per accedere a un cluster database in un VPC](USER_VPC.Scenarios.md).
## Considerazioni sugli endpoint VPC
Prima di impostare un endpoint VPC di interfaccia per endpoint Amazon RDS API, verificare di esaminare le [proprietà e le limitazioni degli endpoint di interfaccia](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#vpce-interface-limitations) in *Guida per l'utente di Amazon VPC*.
Tutte le operazioni API RDS rilevanti per la gestione delle risorse Amazon Aurora sono disponibili dal VPC utilizzando AWS PrivateLink.
Le policy degli endpoint VPC sono supportate per gli endpoint dell'API RDS. Per impostazione predefinita, l'accesso completo alle operazioni API RDS è consentito attraverso l'endpoint. Per ulteriori informazioni, consulta [Controllo degli accessi ai servizi con endpoint VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html) in *Guida per l'utente di Amazon VPC*.
## Disponibilità
L'API Amazon RDS attualmente supporta gli endpoint VPC nelle seguenti regioni: AWS
+ Stati Uniti orientali (Ohio)
+ Stati Uniti orientali (Virginia settentrionale)
+ Stati Uniti occidentali (California settentrionale)
+ Stati Uniti occidentali (Oregon)
+ Africa (Città del Capo)
+ Asia Pacific (Hong Kong)
+ Asia Pacifico (Mumbai)
+ Asia Pacifico (Nuova Zelanda)
+ Asia Pacifico (Osaka)
+ Asia Pacifico (Seoul)
+ Asia Pacifico (Singapore)
+ Asia Pacifico (Sydney)
+ Asia Pacifico (Taipei)
+ Asia Pacifico (Thailandia)
+ Asia Pacifico (Tokyo)
+ Canada (Centrale)
+ Canada occidentale (Calgary)
+ Cina (Pechino)
+ Cina (Ningxia)
+ Europa (Francoforte)
+ Europa (Zurigo)
+ Europa (Irlanda)
+ Europa (Londra)
+ Europe (Paris)
+ Europe (Stockholm)
+ Europa (Milano)
+ Israele (Tel Aviv)
+ Messico (centrale)
+ Medio Oriente (Bahrein)
+ Sud America (San Paolo)
+ AWS GovCloud (Stati Uniti orientali)
+ AWS GovCloud (Stati Uniti occidentali)
## Creazione di un endpoint VPC di interfaccia per l'API Amazon RDS
Puoi creare un endpoint VPC per l'API Amazon RDS utilizzando la console Amazon VPC o (). AWS Command Line Interface AWS CLI Per ulteriori informazioni, consultare [Creazione di un endpoint di interfaccia](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#create-interface-endpoint) nella *Guida per l’utente di Amazon VPC*.
Crea un endpoint VPC per l'API Amazon RDS utilizzando il nome del servizio `com.amazonaws.region.rds`.
Escludendo AWS le regioni in Cina, se abiliti il DNS privato per l'endpoint, puoi effettuare richieste API ad Amazon RDS con l'endpoint VPC utilizzando ad esempio il nome DNS predefinito per la regione. AWS `rds.us-east-1.amazonaws.com` Per le AWS regioni Cina (Pechino) e Cina (Ningxia), puoi effettuare richieste API con l'endpoint VPC utilizzando e, rispettivamente. `rds-api---cn-north-1.amazonaws.com.rproxy.goskope.com.cn` `rds-api---cn-northwest-1.amazonaws.com.rproxy.goskope.com.cn`
Per ulteriori informazioni, consultare [Accesso a un servizio tramite un endpoint di interfaccia](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#access-service-though-endpoint) in *Guida per l'utente di Amazon VPC*.
## Creazione di una policy di endpoint VPC per l'API Amazon RDS
Puoi allegare una policy di endpoint all'endpoint VPC che controlla l'accesso all'API Amazon RDS. Questo codice specifica le informazioni riportate di seguito:
+ Il principale che può eseguire operazioni.
+ Le azioni che possono essere eseguite.
+ Le risorse sui cui si possono eseguire operazioni.
Per ulteriori informazioni, consulta [Controllo degli accessi ai servizi con endpoint VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html) in *Guida per l'utente di Amazon VPC*.
**Ad esempio, policy di endpoint VPC per le operazioni API Amazon RDS**
Di seguito è riportato un esempio di una policy endpoint per l'API Amazon RDS. Se collegato a un endpoint, questa policy concede l'accesso alle operazioni API Amazon RDS riportate per tutte le entità su tutte le risorse.
```
{
"Statement":[
{
"Principal":"*",
"Effect":"Allow",
"Action":[
"rds:CreateDBInstance",
"rds:ModifyDBInstance",
"rds:CreateDBSnapshot"
],
"Resource":"*"
}
]
}
```
**Esempio: policy degli endpoint VPC che nega tutti gli accessi da un account specificato AWS**
La seguente politica degli endpoint VPC nega all' AWS account `123456789012` tutti gli accessi alle risorse che utilizzano l'endpoint. La policy consente tutte le operazioni da altri account.
```
{
"Statement": [
{
"Action": "*",
"Effect": "Allow",
"Resource": "*",
"Principal": "*"
},
{
"Action": "*",
"Effect": "Deny",
"Resource": "*",
"Principal": { "AWS": [ "123456789012" ] }
}
]
}
```
# Best practice di sicurezza per
Usa gli account AWS Identity and Access Management (IAM) per controllare l'accesso alle operazioni dell'API Amazon RDS, in particolare le operazioni che creano, modificano o eliminano risorse Amazon Aurora. Tali risorse includono i cluster di database, i gruppi di sicurezza e i gruppi di parametri. Utilizza anche IAM per controllare le azioni che eseguono azioni amministrative comuni come il backup e il ripristino di cluster di database.
+ Crea un singolo utente per ogni persona, te compresa, che gestisce le risorse Amazon Aurora. Non utilizzare credenziali AWS root per gestire le risorse Amazon Aurora.
+ Assegna a ciascun utente un set minimo di autorizzazioni richieste per eseguire le proprie mansioni.
+ Utilizza gruppi IAM per gestire in modo efficace le autorizzazioni per più utenti.
+ Ruota periodicamente le credenziali IAM.
+ Configura Gestione dei segreti AWS per ruotare automaticamente i segreti per Aurora. Per ulteriori informazioni, consulta [Rotazione dei segreti Gestione dei segreti AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html) nella *Guida per l'utente di Gestione dei segreti AWS *. Puoi anche recuperare le credenziali da programmaticamente. Gestione dei segreti AWS Per ulteriori informazioni, consulta [Recupero del valore segreto](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_retrieve-secret.html) nella *Guida per l'utente di Gestione dei segreti AWS *.
Per ulteriori informazioni sulla sicurezza di Amazon Aurora, consulta [Sicurezza in ](UsingWithRDS.md). Per ulteriori informazioni su IAM, consulta [AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/Welcome.html). Per informazioni sulle best practice di IAM, consulta [Best practice di IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAMBestPractices.html).
AWS Security Hub CSPM utilizza controlli di sicurezza per valutare le configurazioni delle risorse e gli standard di sicurezza per aiutarvi a rispettare vari quadri di conformità. Per ulteriori informazioni sull'utilizzo di Security Hub CSPM per valutare le risorse RDS, consulta i controlli di [Amazon Relational Database Service nella Guida](https://docs.aws.amazon.com/securityhub/latest/userguide/rds-controls.html) per l'utente. AWS Security Hub
È possibile monitorare l'utilizzo di RDS in relazione alle migliori pratiche di sicurezza utilizzando Security Hub CSPM. [Per ulteriori informazioni, vedi Cos'è? AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) .
Usa l'API Console di gestione AWS AWS CLI, the o RDS per modificare la password per il tuo utente principale. Se usi uno strumento diverso, ad esempio un client SQL, per modificare la password dell'utente master, i privilegi per l'utente potrebbero venire revocati involontariamente.
Amazon GuardDuty è un servizio di monitoraggio continuo della sicurezza che analizza ed elabora varie fonti di dati, inclusa l'attività di accesso ad Amazon RDS. Utilizza i feed di intelligence sulle minacce e il machine learning per identificare attività inattese, potenzialmente non autorizzate, comportamenti di accesso sospetti e operazioni dannose nell’ambiente AWS .
Quando Amazon GuardDuty RDS Protection rileva un tentativo di accesso potenzialmente sospetto o anomalo che indica una minaccia per il database, GuardDuty genera una nuova scoperta con dettagli sul database potenzialmente compromesso. Per ulteriori informazioni, consulta [Monitoraggio delle minacce con Amazon GuardDuty RDS Protection per Amazon Aurora](guard-duty-rds-protection.md).
# Controllo dell'accesso con i gruppi di sicurezza
I gruppi di sicurezza VPC controllano l’accesso che il traffico ha in entrata e in uscita su un cluster di database. Per impostazione predefinita, l’accesso alla rete è disattivato per un cluster di database. Puoi specificare delle norme in un gruppo di sicurezza che consente l'accesso da un intervallo di indirizzi IP, dalla porta o da un gruppo di sicurezza. Una volta configurate le regole in ingresso, si applicano le stesse regole a tutti i cluster di database con associazione a tale gruppo di sicurezza. Puoi specificare fino a 20 norme in un gruppo di sicurezza.
## Panoramica dei gruppi di sicurezza VPC
Ogni regola del gruppo di sicurezza VPC consente a un’origine specifica di accedere a un cluster di database in un VPC con associazione al gruppo di sicurezza VPC specifico. L'origine può essere una serie di indirizzi (ad esempio, 203.0.113.0/24) oppure un altro gruppo di sicurezza VPC. Specificando un gruppo di sicurezza VPC come origine, consenti il traffico in entrata da tutte le istanze (in genere i server dell'applicazione) che usano il gruppo di sicurezza VPC. I gruppi di sicurezza VPC possono avere regole che gestiscono sia il traffico in entrata che in uscita. Tuttavia, le regole del traffico in uscita in genere non si applicano ai cluster di database. Le regole del traffico in uscita si applicano solo se il cluster di database funge da client. Per creare gruppi di sicurezza VPC, è necessario utilizzare l'[API Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Welcome.html) o l'opzione **Security Group** (Gruppo di sicurezza) nella console VPC.
Quando si creano regole per il gruppo di sicurezza VPC che consentono l’accesso ai cluster nel VPC, è necessario specificare una porta per ciascun intervallo di indirizzi per i quali la regola consente l’accesso. Ad esempio, se si desidera abilitare l'accesso SSH (Secure Shell) alle istanze nel VPC, devi creare una regola che consenta l'accesso alla porta TCP 22 per l'intervallo di indirizzi specificato.
È possibile configurare più gruppi di sicurezza VPC che consentono l'accesso a porte diverse per istanze diverse nel VPC. Ad esempio, è possibile creare un gruppo di sicurezza VPC che consenta l'accesso alla porta TCP 80 per i server web nel VPC. Quindi è possibile creare un altro gruppo di sicurezza VPC che consenta l’accesso alla porta TCP 3306 per le istanze database Aurora MySQL nel VPC.
**Nota**
In un cluster database Aurora, il gruppo di sicurezza VPC associato al cluster database è anche associato a tutte le istanze database nel cluster database. Se modifichi il gruppo di sicurezza VPC per il cluster database o per un'istanza database, la modifica viene applicata automaticamente a tutte le istanze database nel cluster database.
Per ulteriori informazioni sui gruppi di sicurezza VPC, consulta la pagina [Gruppi di sicurezza](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) nella *Guida per l'utente di Amazon Virtual Private Cloud*.
**Nota**
Se il cluster di DB si trova in un VPC ma non è accessibile pubblicamente, puoi anche utilizzare una connessione AWS Site-to-Site VPN o una Direct Connect connessione per accedervi da una rete privata. Per ulteriori informazioni, consulta [Riservatezza del traffico Internet](inter-network-traffic-privacy.md).
## Scenario del gruppo di sicurezza
Un uso comune di un cluster di database in un VPC è quello di condividere dati con un server di applicazione in esecuzione in un’istanza Amazon EC2 nello stesso VPC, al quale si accede tramite un’applicazione client esterna al VPC. In questo scenario, si utilizzano le pagine RDS e VPC sulle Console di gestione AWS operazioni API RDS ed EC2 per creare le istanze e i gruppi di sicurezza necessari:
1. Creare un gruppo di sicurezza VPC (ad esempio, `sg-0123ec2example`) e definire le regole in entrata che utilizzano l'indirizzo IP dell'applicazione client usato nell'indirizzo IP dell'applicazione del client come origine. Questo gruppo di sicurezza consente all'applicazione del client di collegarsi alle istanze EC2 in una VPC che utilizza questo gruppo di sicurezza.
1. Creare un'istanza EC2 per l'applicazione e aggiungere l'istanza EC2 al gruppo di sicurezza VPC (`sg-0123ec2example`) creato nel passaggio precedente.
1. Creare un secondo gruppo di sicurezza VPC (ad esempio, `sg-6789rdsexample`) e creare una nuova regola specificando il gruppo di sicurezza VPC creato nel passaggio 1 (`sg-0123ec2example`) come l'origine.
1. Creare un nuovo cluster di database e aggiungere il cluster di database al gruppo di sicurezza VPC (`sg-6789rdsexample`) creato nel passaggio precedente. Quando si crea il cluster di database, utilizzare lo stesso numero di porta di quello specificato per la regola del gruppo di sicurezza VPC (`sg-6789rdsexample`) creato nel passaggio 3.
Il seguente diagramma mostra questo scenario.
![\[Cluster di database e istanza EC2 in un VPC\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/con-VPC-sec-grp-aurora.png)
Per istruzioni dettagliate sulla configurazione di un VPC per questo scenario, consulta [Tutorial: crea un VPC da utilizzare con un cluster di DB (solo) IPv4](CHAP_Tutorials.WebServerDB.CreateVPC.md). Per ulteriori informazioni sull’utilizzo di un VPC, consulta [VPC Amazon e Amazon Aurora](USER_VPC.md).
## Creazione di un gruppo di sicurezza VPC
Puoi creare un gruppo di sicurezza VPC per un'istanza database tramite la console VPC. Per informazioni sulla creazione di un gruppo di sicurezza, consulta le pagine [Fornitura dell'accesso al cluster di database nel VPC creando un gruppo di sicurezza](CHAP_SettingUp_Aurora.md#CHAP_SettingUp_Aurora.SecurityGroup) e [Gruppi di sicurezza](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) nella *Guida per l'utente di Amazon Virtual Private Cloud*.
## Associazione di un gruppo di sicurezza a un cluster database
Puoi associare un gruppo di sicurezza a un cluster DB utilizzando **Modify cluster** sulla console RDS, l'API `ModifyDBCluster` Amazon RDS o il `modify-db-cluster` AWS CLI comando.
L’esempio della CLI seguente associa un gruppo VPC specifico e rimuove i gruppi di sicurezza database dal cluster di database
```
aws rds modify-db-cluster --db-cluster-identifier dbName --vpc-security-group-ids sg-ID
```
Per informazioni sulla modifica di un cluster di database, consulta [Modifica di un cluster database Amazon Aurora](Aurora.Modifying.md).
# Privilegi dell'account utente master
Quando si crea un nuovo cluster di database, l’utente master predefinito utilizzato ottiene determinati privilegi per tale cluster di database. Non è possibile modificare il nome utente master dopo aver creato il cluster di database.
**Importante**
Si consiglia di non utilizzare l'utente master direttamente nelle applicazioni. Rispetta piuttosto la best practice di utilizzare un utente del database creato con i privilegi minimi richiesti per l'applicazione.
**Nota**
Se si cancellano per errore le autorizzazioni per l’utente master è possibile ripristinarle modificando il cluster di database e impostando una nuova password per l’utente master. Per ulteriori informazioni sulla modifica di un cluster di database, consulta [Modifica di un cluster database Amazon Aurora](Aurora.Modifying.md) .
La tabella seguente mostra i privilegi e i ruoli di database ottenuti dall'utente master per ciascuno dei motori di database.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.MasterAccounts.html)
# Utilizzo di ruoli collegati ai servizi per Amazon Aurora
Amazon Aurora AWS Identity and Access Management utilizza ruoli collegati ai servizi (IAM[).](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) Un ruolo collegato ai servizi è un tipo univoco di ruolo IAM collegato direttamente a Amazon Aurora. I ruoli collegati ai servizi sono predefiniti da Aurora e includono tutte le autorizzazioni richieste dal servizio per chiamare altri servizi per tuo conto. AWS
Un ruolo collegato ai servizi semplifica l’uso di Amazon Aurora perché non sarà più necessario aggiungere manualmente le autorizzazioni. Amazon Aurora definisce le autorizzazioni dei ruoli collegati ai servizi e, salvo diversamente definito, solo Amazon Aurora può assumere il ruolo. Le autorizzazioni definite includono la policy di trust e la policy delle autorizzazioni. Una policy delle autorizzazioni specifica non può essere collegata a un’altra entità IAM.
È possibile eliminare i ruoli solo dopo aver eliminato le risorse correlate. Questa procedura protegge le risorse di Amazon Aurora perché impedisce la rimozione involontaria delle autorizzazioni di accesso alle risorse.
Per informazioni sugli altri servizi che supportano i ruoli collegati ai servizi, consultare i [servizi AWS che funzionano con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) e cercare i servizi che riportano **Yes (Sì)** nella colonna **Service-Linked Role (Ruolo associato ai servizi)**. Scegli **Sì** in corrispondenza di un link per visualizzare la documentazione relativa al ruolo collegato ai servizi per tale servizio.
## Autorizzazioni del ruolo collegato ai servizi per Amazon Aurora
Il ruolo collegato al servizio AWSService RoleFor RDS prevede che i seguenti servizi assumano il ruolo:
+ `rds.amazonaws.com`
A questo ruolo collegato ai servizi è collegata un policy di autorizzazione denominata `AmazonRDSServiceRolePolicy` che concede le autorizzazioni per operare nell’account.
Per ulteriori informazioni su questa politica, incluso il documento sulla politica JSON, consulta [Amazon RDSService RolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSServiceRolePolicy.html) nella *AWS Managed Policy Reference Guide*.
**Nota**
Per consentire a un’entità IAM (ad esempio un utente, un gruppo o un ruolo) di creare, modificare o eliminare un ruolo collegato ai servizi, devi configurare le autorizzazioni. Se viene visualizzato il messaggio di errore seguente:
**Unable to create the resource. (Impossibile creare la risorsa. Verify that you have permission to create service linked role. (Verifica di possedere le autorizzazioni necessarie per creare un ruolo collegato ai servizi.) Otherwise wait and try again later. (In caso contrario, attendi e riprova più tardi.**
Accertati che le seguenti autorizzazioni siano abilitate:
```
{
"Action": "iam:CreateServiceLinkedRole",
"Effect": "Allow",
"Resource": "arn:aws:iam::*:role/aws-service-role/rds.amazonaws.com/AWSServiceRoleForRDS",
"Condition": {
"StringLike": {
"iam:AWSServiceName":"rds.amazonaws.com"
}
}
}
```
Per ulteriori informazioni, consulta [Autorizzazioni del ruolo collegato ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) nella *Guida per l’utente di IAM*.
### Creazione di un ruolo collegato ai servizi per Amazon Aurora
Non devi creare manualmente un ruolo collegato ai servizi. Quando si crea un cluster di database, Amazon Aurora crea nuovamente il ruolo collegato al servizio per conto dell’utente.
**Importante**
Se utilizzavi il servizio Amazon Aurora prima del 1° dicembre 2017, quando ha iniziato a supportare ruoli collegati al servizio, Amazon nel tuo account. AWSService RoleFor Per ulteriori informazioni, vedi [Un](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared) nuovo ruolo è apparso nel mio account. AWS
Se elimini questo ruolo collegato ai servizi e quindi devi ricrearlo di nuovo, puoi utilizzare lo stesso processo per ricreare il ruolo nel tuo account. Quando si crea un cluster di database, Amazon Aurora crea nuovamente il ruolo collegato al servizio per tuo conto.
### Modifica di un ruolo collegato ai servizi per Amazon Aurora
Amazon Aurora non consente di modificare AWSService RoleFor il ruolo collegato al servizio RDS. Dopo avere creato un ruolo collegato al servizio, non sarà possibile modificarne il nome perché varie entità potrebbero farvi riferimento. È possibile tuttavia modificarne la descrizione utilizzando IAM. Per ulteriori informazioni, consulta [Modifica di un ruolo collegato ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) nella *Guida per l’utente di IAM*.
### Eliminazione di un ruolo collegato ai servizi per Amazon Aurora
Se non è più necessario utilizzare una caratteristica o un servizio che richiede un ruolo collegato ai servizi, ti consigliamo di eliminare quel ruolo. In questo modo non sarà più presente un’entità non utilizzata che non viene monitorata e gestita attivamente. Tuttavia, prima di poter eliminare il ruolo collegato al servizio, devi eliminare tutti i cluster database.
#### Pulizia di un ruolo collegato ai servizi
Prima di utilizzare IAM per eliminare un ruolo collegato ai servizi, devi innanzitutto verificare che il ruolo non abbia sessioni attive ed eliminare tutte le risorse utilizzate dal ruolo.
**Per verificare se il ruolo collegato ai servizi dispone di una sessione attiva nella console IAM**
1. Accedi Console di gestione AWS e apri la console IAM all'indirizzo. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)
1. Nel pannello di navigazione della console IAM seleziona **Ruoli**. Quindi scegli il nome (non la casella di controllo) del ruolo AWSService RoleFor RDS.
1. Nella pagina **Riepilogo** per il ruolo selezionato, scegli la scheda **Ultimo accesso**.
1. Nella scheda **Ultimo accesso**, esamina l’attività recente per il ruolo collegato ai servizi.
**Nota**
Se non sei sicuro che Amazon Aurora stia utilizzando AWSService RoleFor il ruolo RDS, puoi provare a eliminarlo. Se il servizio sta utilizzando il ruolo, l’eliminazione non andrà a buon fine e potrai visualizzare le regioni AWS in cui il ruolo viene utilizzato. Se il ruolo è in uso, prima di poterlo eliminare dovrai attendere il termine della sessione. Non puoi revocare la sessione per un ruolo collegato al servizio.
##### Eliminazione di tutti i cluster
Utilizza una delle procedure seguenti per eliminare un singolo cluster. Ripeti la procedura per ogni cluster.
**Per eliminare un cluster (console)**
1. Aprire la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Nell’elenco **Databases (Database)**, scegliere il cluster da eliminare.
1. Per **Cluster Actions (Operazioni cluster)**, scegliere **Delete (Elimina)**.
1. Scegliere **Delete (Elimina)**.
**Per eliminare un cluster (CLI)**
Consulta `[delete-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-cluster.html)` in *Riferimento ai comandi AWS CLI *.
**Per eliminare un cluster (API)**
Consulta `[DeleteDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteDBCluster.html)` nella *Amazon RDS API Reference*.
Puoi utilizzare la console IAM, l'IAM CLI o l'API IAM per eliminare il ruolo collegato al servizio AWSService RoleFor RDS. Per ulteriori dettagli, consulta [Eliminazione di un ruolo collegato al servizio](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) nella *Guida per l’utente di IAM*.
## Autorizzazioni del ruolo collegato ai servizi per Amazon RDS Beta
Amazon Aurora utilizza il ruolo collegato al servizio denominato `AWSServiceRoleForRDSBeta` per consentire ad Amazon Aurora di AWS chiamare i servizi per conto delle tue risorse DB RDS.
Il ruolo AWSService RoleFor RDSBeta collegato al servizio prevede che i seguenti servizi assumano il ruolo:
+ `rds.amazonaws.com`
A questo ruolo collegato ai servizi è collegata un policy di autorizzazione denominata `AmazonRDSBetaServiceRolePolicy` che concede le autorizzazioni per operare nell’account. Per ulteriori informazioni, consulta [AWS politica gestita: Amazon RDSBeta ServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSBetaServiceRolePolicy).
**Nota**
Per consentire a un’entità IAM (ad esempio un utente, un gruppo o un ruolo) di creare, modificare o eliminare un ruolo collegato ai servizi, devi configurare le autorizzazioni. Se viene visualizzato il messaggio di errore seguente:
**Unable to create the resource. (Impossibile creare la risorsa. Verify that you have permission to create service linked role. (Verifica di possedere le autorizzazioni necessarie per creare un ruolo collegato ai servizi.) Otherwise wait and try again later. (In caso contrario, attendi e riprova più tardi.**
Accertati che le seguenti autorizzazioni siano abilitate:
```
{
"Action": "iam:CreateServiceLinkedRole",
"Effect": "Allow",
"Resource": "arn:aws:iam::*:role/aws-service-role/custom.rds.amazonaws.com/AmazonRDSBetaServiceRolePolicy",
"Condition": {
"StringLike": {
"iam:AWSServiceName":"custom.rds.amazonaws.com"
}
}
}
```
Per ulteriori informazioni, consulta [Autorizzazioni del ruolo collegato ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) nella *Guida per l’utente di IAM*.
## Ruolo collegato ai servizi per Amazon RDS Preview
Amazon Aurora utilizza il ruolo collegato al servizio denominato `AWSServiceRoleForRDSPreview` per consentire ad Amazon Aurora di AWS chiamare i servizi per conto delle tue risorse DB RDS.
Il ruolo AWSService RoleFor RDSPreview collegato al servizio prevede che i seguenti servizi assumano il ruolo:
+ `rds.amazonaws.com`
A questo ruolo collegato ai servizi è collegata un policy di autorizzazione denominata `AmazonRDSPreviewServiceRolePolicy` che concede le autorizzazioni per operare nell’account. Per ulteriori informazioni, consulta [AWS politica gestita: Amazon RDSPreview ServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSPreviewServiceRolePolicy).
**Nota**
Per consentire a un’entità IAM (ad esempio un utente, un gruppo o un ruolo) di creare, modificare o eliminare un ruolo collegato ai servizi, devi configurare le autorizzazioni. Se viene visualizzato il messaggio di errore seguente:
**Unable to create the resource. (Impossibile creare la risorsa. Verify that you have permission to create service linked role. (Verifica di possedere le autorizzazioni necessarie per creare un ruolo collegato ai servizi.) Otherwise wait and try again later. (In caso contrario, attendi e riprova più tardi.**
Accertati che le seguenti autorizzazioni siano abilitate:
```
{
"Action": "iam:CreateServiceLinkedRole",
"Effect": "Allow",
"Resource": "arn:aws:iam::*:role/aws-service-role/custom.rds.amazonaws.com/AmazonRDSPreviewServiceRolePolicy",
"Condition": {
"StringLike": {
"iam:AWSServiceName":"custom.rds.amazonaws.com"
}
}
}
```
Per ulteriori informazioni, consulta [Autorizzazioni del ruolo collegato ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) nella *Guida per l’utente di IAM*.
# VPC Amazon e Amazon Aurora
Amazon Virtual Private Cloud (Amazon VPC) consente di avviare le risorse AWS, come i cluster database Aurora, in un cloud privato virtuale (VPC).
Quando utilizzi un VPC, hai il controllo completo sull'ambiente virtuale di rete. Puoi scegliere il tuo intervallo di indirizzi IP, creare sottoreti e configurare liste di routing e di controllo accessi. Non è previsto alcun costo aggiuntivo per eseguire il cluster database in Amazon VPC.
Gli account hanno un VPC predefinito. Tutti i nuovi cluster database vengono creati nel VPC predefinito, salvo diversamente specificato.
**Topics**
+ [Uso di un cluster database in un VPC](USER_VPC.WorkingWithRDSInstanceinaVPC.md)
+ [Scenari per accedere a un cluster database in un VPC](USER_VPC.Scenarios.md)
+ [Tutorial: crea un VPC da utilizzare con un cluster di DB (solo) IPv4](CHAP_Tutorials.WebServerDB.CreateVPC.md)
+ [Tutorial: Creazione di un VPC per l'utilizzo con un cluster database (modalità dual-stack)](CHAP_Tutorials.CreateVPCDualStack.md)
Di seguito vengono descritte le funzionalità VPC relative ai cluster database Amazon Aurora. Per ulteriori informazioni su Amazon VPC, consulta [Guida alle operazioni di base di Amazon VPC](https://docs.aws.amazon.com/AmazonVPC/latest/GettingStartedGuide/) e [Guida per l'utente di Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/).
# Uso di un cluster database in un VPC
Il cluster database deve essere all'interno di un cloud privato virtuale (VPC). Un VPC è una rete virtuale logicamente isolata dalle altre reti virtuali nel cloud. AWS Amazon VPC ti consente di avviare AWS risorse, come un cluster di istanze Amazon DB un'istanza Amazon EC2, in un VPC. Il VPC può essere un VPC predefinito fornito con l'account o uno creato da te. Tutti VPCs sono associati al tuo account. AWS
Il VPC predefinito ha tre sottoreti che è possibile usare per isolare le risorse all'interno del VPC. Il VPC predefinito ha anche un gateway Internet che può essere usato per fornire l'accesso alle risorse all'interno del VPC dall'esterno del VPC.
Per un elenco di scenari relativi ai cluster database Amazon Aurora in un VPC , consulta [Scenari per accedere a un cluster database in un VPC](USER_VPC.Scenarios.md).
**Topics**
+ [Uso di un cluster database in un VPC](#Overview.RDSVPC.Create)
+ [Controllo della crittografia VPC](#USER_VPC.EncryptionControl)
+ [Utilizzo di gruppi di sottoreti database](#USER_VPC.Subnets)
+ [Sottoreti condivise](#USER_VPC.Shared_subnets)
+ [Assegnazione di indirizzi IP in Amazon Aurora](#USER_VPC.IP_addressing)
+ [Nascondere cluster database in un VPC da Internet](#USER_VPC.Hiding)
+ [Creazione di un cluster database in un VPC](#USER_VPC.InstanceInVPC)
Nei seguenti tutorial puoi imparare a creare un VPC da usare per uno scenario Amazon Aurora comune:
+ [Tutorial: crea un VPC da utilizzare con un cluster di DB (solo) IPv4](CHAP_Tutorials.WebServerDB.CreateVPC.md)
+ [Tutorial: Creazione di un VPC per l'utilizzo con un cluster database (modalità dual-stack)](CHAP_Tutorials.CreateVPCDualStack.md)
## Uso di un cluster database in un VPC
Ecco alcuni consigli per l'uso di un cluster database in un VPC:
+ Il VPC deve avere almeno due sottoreti. Una *sottorete* è un segmento dell'intervallo di indirizzi IP di un VPC che è possibile specificare e utilizzare per raggruppare i cluster database in base alle esigenze operative e di sicurezza.
+ Se desideri che il cluster database nel VPC sia accessibile a livello pubblico, verifica di aver attivato gli attributi VPC *DNS hostnames* (Nomi host DNS) e *DNS resolution* (Risoluzione DNS).
+ Il VPC deve includere un gruppo di sottoreti database creato da te. Puoi creare un gruppo di sottoreti di database, specificando le sottoreti create. Amazon Aurora sceglie una sottorete e un indirizzo IP all'interno di quella stessa sottorete da associare all'istanza database primaria nel cluster DB. L'istanza database primaria utilizza la zona di disponibilità che contiene la sottorete.
+ Il VPC deve avere un gruppo di sicurezza VPC che consente l'accesso al cluster database.
Per ulteriori informazioni, consulta [Scenari per accedere a un cluster database in un VPC](USER_VPC.Scenarios.md).
+ I blocchi CIDR in ciascuna delle sottoreti devono essere sufficientemente grandi da contenere gli indirizzi IP di riserva per Amazon Aurora da utilizzare durante le attività di manutenzione, inclusi il failover e il dimensionamento delle risorse di calcolo. Ad esempio, un intervallo come 10.0.0.0/24 e 10.0.1.0/24 è in genere sufficientemente ampio.
+ Un VPC può avere un attributo di *tenancy di istanza* o *predefinito* o *dedicato*. Tutte le impostazioni predefinite VPCs hanno l'attributo di tenancy dell'istanza impostato su default e un VPC predefinito può supportare qualsiasi classe di istanza DB.
Se scegli di includere il cluster database in un VPC dedicato in cui l'attributo di locazione dell'istanza è impostato su dedicato, la classe dell'istanza database del cluster database deve essere uno dei tipi di istanza dedicata Amazon EC2. Ad esempio, l'istanza dedicata EC2 r5.large corrisponde alla classe di istanza database db.r5.large. Per informazioni sulla tenancy di istanza in un VPC, consulta [Istanze dedicate](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/dedicated-instance.html) nella *Guida per l'utente Amazon Elastic Compute Cloud*.
Per ulteriori informazioni sui tipi di istanze che possono essere in un’istanza dedicata, consulta [Istanze dedicate Amazon EC2](https://aws.amazon.com/ec2/purchasing-options/dedicated-instances/) nella pagina dei prezzi Amazon EC2.
**Nota**
Quando si imposta l'attributo di locazione dell'istanza su dedicato per un cluster database, non è garantita l'esecuzione del cluster database su un host dedicato.
## Controllo della crittografia VPC
I controlli di crittografia VPC ti consentono di applicare tutto il traffico di rete encryption-in-transit all'interno del tuo. VPCs Utilizzate il controllo della crittografia per soddisfare i requisiti di conformità normativa assicurando che solo l'hardware basato su Nitro con funzionalità di crittografia possa essere fornito nelle aree designate. VPCs Il controllo della crittografia rileva inoltre i problemi di compatibilità al momento della richiesta dell'API anziché durante il provisioning. I carichi di lavoro esistenti continuano a funzionare e vengono bloccate solo le nuove richieste incompatibili.
Imposta i controlli di crittografia VPC impostando la modalità di controllo VPC su:
+ *disabilitato (impostazione* predefinita)
+ *monitor*
+ *forzato*
Per verificare la modalità di controllo corrente per il tuo VPC, usa il comando Console di gestione AWS o [DescribeVpcs](https://docs.aws.amazon.com//AWSEC2/latest/APIReference/API_DescribeVpcs.html)CLI o API.
Se il tuo VPC applica la crittografia, puoi fornire solo basati su Nitro che supportano la crittografia in transito in quel VPC. Per ulteriori informazioni, consultare [Tipi di classi di istanza database](Concepts.DBInstanceClass.Types.md). *Per informazioni sulle istanze Nitro, consulta [Istanze costruite sul sistema AWS Nitro nella Guida](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-nitro-instances.html) per l'utente di Amazon EC2.*
**Nota**
`VpcEncryptionControlViolationException`
Aurora ServerlessPer MySQL e PostreSQL, il controllo della crittografia richiede la versione 3 o successiva della piattaforma.
## Utilizzo di gruppi di sottoreti database
Le sottoreti sono segmenti di un intervallo di indirizzi IP di un VPC che si designa per raggruppare le risorse in base alle esigenze operative e di sicurezza. Un *gruppo di sottoreti DB* è una raccolta di sottoreti (generalmente private) creata in un VPC e che è possibile indicare per i cluster database. Utilizzando un gruppo di sottoreti DB, è possibile specificare un particolare VPC durante la creazione di cluster di istanze utilizzando AWS CLI l'API o RDS. Se utilizzi la console, puoi scegliere il VPC e i gruppi di sottorete che desideri usare.
Ogni gruppo di sottoreti database deve avere almeno due zone di disponibilità in una determinata Regione AWS. Quando si crea un cluster database in un VPC, è necessario selezionare anche un gruppo di sottoreti DB. Dal gruppo di sottoreti DB, Amazon Aurora sceglie una sottorete e un indirizzo IP all'interno di essa da associare all'istanza database primaria nel cluster database. Il database utilizza la zona di disponibilità che contiene la sottorete. Aurora Amazon assegna sempre un indirizzo IP da una sottorete con spazio libero per gli indirizzi IP.
Le sottoreti di un gruppo di sottoreti DB sono pubbliche o private. Le sottoreti sono pubbliche o private, a seconda della configurazione impostata per le relative liste di controllo degli accessi alla rete (rete) e le tabelle di routing. ACLs Affinché un cluster database possa essere accessibile a livello pubblico, tutte le sottoreti nel gruppo di sottoreti database devono essere pubbliche. Se una sottorete associata a un cluster database accessibile pubblicamente cambia da pubblica a privata, ciò può avere ripercussioni sulla disponibilità del cluster database.
Per creare un gruppo di sottoreti DB che supporti la modalità dual-stack, assicuratevi che a ogni sottorete che aggiungete al gruppo di sottorete DB sia associato un blocco CIDR del protocollo Internet versione 6 (). IPv6 Per ulteriori informazioni, consulta [Assegnazione di indirizzi IP in Amazon Aurora](#USER_VPC.IP_addressing) la sezione «[Migrazione verso](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html)» IPv6 nella *Amazon VPC* User Guide.
Quando Amazon Aurora crea un cluster database in un VPC, assegna un'interfaccia di rete al cluster database usando un indirizzo IP dal gruppo di sottoreti del database. Tuttavia, consigliamo vivamente di usare il nome del sistema dei nomi di dominio (DNS) per collegare il cluster database, perché l'indirizzo IP sottostante varia durante un failover.
**Nota**
Per ogni cluster database in esecuzione in un VPC, assicurati di riservare almeno un indirizzo in ogni sottorete nel gruppo di sottoreti DB per l'utilizzo da parte di Amazon Aurora per le operazioni di ripristino.
## Sottoreti condivise
Puoi creare un cluster database in un VPC condiviso.
Alcune considerazioni da tenere a mente durante l'utilizzo di shared: VPCs
+ È possibile spostare un cluster database da una sottorete VPC condivisa a una sottorete VPC non condivisa e viceversa.
+ I membri di un VPC condiviso devono creare un gruppo di sicurezza nel VPC per consentire loro di creare un cluster database.
+ I proprietari e i membri di un VPC condiviso possono accedere al database utilizzando le query SQL. Tuttavia, solo il creatore di una risorsa può effettuare chiamate API sulla risorsa.
## Assegnazione di indirizzi IP in Amazon Aurora
Gli indirizzi IP permettono alle risorse nel VPC di comunicare tra loro e con le risorse su Internet. Amazon Aurora supporta IPv4 entrambi i protocolli di IPv6 indirizzamento. Per impostazione predefinita, Amazon Aurora e Amazon VPC utilizzano il protocollo di indirizzamento. IPv4 Non puoi disattivare questo comportamento. Quando crei un VPC, assicurati di specificare un blocco IPv4 CIDR (un intervallo di indirizzi privati IPv4 ).
Il supporto per il IPv6 protocollo amplia il numero di indirizzi IP supportati. Utilizzando il IPv6 protocollo, ti assicuri di disporre di indirizzi disponibili sufficienti per la crescita futura di Internet. Le risorse RDS nuove ed esistenti possono utilizzare IPv4 e IPv6 indirizzare all'interno del tuo VPC. La configurazione, la protezione e la traduzione del traffico di rete tra i due protocolli utilizzati in diverse parti di un’applicazione può causare sovraccarico operativo. Puoi standardizzare il IPv6 protocollo per le risorse Amazon RDS per semplificare la configurazione della rete.
**Topics**
+ [IPv4 indirizzi](#USER_VPC.IP_addressing.IPv4)
+ [IPv6 indirizzi](#USER_VPC.IP_addressing.IPv6)
+ [Modalità dual-stack](#USER_VPC.IP_addressing.dual-stack-mode)
### IPv4 indirizzi
Quando si crea un VPC, è necessario specificare un intervallo di IPv4 indirizzi per il VPC sotto forma di blocco CIDR, ad esempio. `10.0.0.0/16` Un *gruppo di sottoreti DB* definisce l'intervallo di indirizzi IP in questo blocco CIDR che può essere usato da cluster database. Questi indirizzi IP possono essere privati o pubblici.
Un IPv4 indirizzo privato è un indirizzo IP che non è raggiungibile su Internet. Puoi utilizzare IPv4 indirizzi privati per la comunicazione tra il tuo cluster di DB e altre risorse, come le istanze Amazon EC2, nello stesso VPC. Ogni cluster database dispone di un indirizzo IP privato per la comunicazione nel VPC.
Un indirizzo IP pubblico è un IPv4 indirizzo raggiungibile da Internet. Puoi utilizzare gli indirizzi pubblici per la comunicazione tra cluster database e risorse su Internet, ad esempio un client SQL. Puoi controllare se cluster database ricevono un indirizzo IP pubblico.
Amazon RDS utilizza indirizzi Public Elastic IPv4 dal pool di indirizzi pubblici di EC2 per istanze di IPv4 database accessibili al pubblico. Questi indirizzi IP sono visibili nel tuo AWS account quando usi la `describe-addresses` CLI, l'API o visualizzi la sezione Elastic IPs (EIP) nel. Console di gestione AWS Ogni indirizzo IP gestito da RDS è contrassegnato da un `service_managed` attributo impostato su. `"rds"`
Sebbene IPs siano visibili nel tuo account, rimangono completamente gestiti da Amazon RDS e non possono essere modificati o rilasciati. Amazon RDS viene rilasciato IPs nuovamente nel pool di IPv4 indirizzi pubblici quando non è più in uso.
CloudTrail registra le chiamate API relative all'EIP di RDS, ad esempio. `AllocateAddress` Queste chiamate API vengono richiamate dal Service Principal. `rds.amazonaws.com`
**Nota**
IPs le risorse allocate da Amazon RDS non vengono conteggiate ai fini dei limiti EIP del tuo account.
Per un tutorial che mostra come creare un VPC con solo IPv4 indirizzi privati da utilizzare per uno scenario Amazon comune, consulta. [Tutorial: crea un VPC da utilizzare con un cluster di DB (solo) IPv4](CHAP_Tutorials.WebServerDB.CreateVPC.md)
### IPv6 indirizzi
Facoltativamente, puoi associare un blocco IPv6 CIDR al tuo VPC e alle sottoreti e assegnare IPv6 gli indirizzi di quel blocco alle risorse del tuo VPC. Ogni indirizzo è unico a livello globale. IPv6
Il blocco IPv6 CIDR per il tuo VPC viene assegnato automaticamente dal pool IPv6 di indirizzi di Amazon. Non è possibile scegliere l'intervallo in modo autonomo.
Quando ti connetti a un IPv6 indirizzo, assicurati che siano soddisfatte le seguenti condizioni:
+ Il client è configurato in modo da consentire il trasferimento del traffico tra IPv6 client e database.
+ I gruppi di sicurezza RDS utilizzati dall'istanza DB sono configurati correttamente in modo da consentire il trasferimento del traffico tra client e database. IPv6
+ Lo stack del sistema operativo client consente il traffico sull' IPv6 indirizzo e i driver e le librerie del sistema operativo sono configurati per scegliere l'endpoint di istanza DB predefinito corretto (uno o due IPv4 ). IPv6
Per ulteriori informazioni IPv6, consulta la sezione [Indirizzamento IP](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html) nella *Amazon VPC User Guide*.
### Modalità dual-stack
Un cluster di DB viene eseguito in modalità dual-stack quando è in grado di comunicare sia IPv4 tramite protocolli di indirizzamento che tramite protocolli di indirizzamento. IPv6 Le risorse possono quindi comunicare con il cluster di DB utilizzando uno o entrambi IPv4 IPv6 i protocolli. Le istanze DB private in modalità dual-stack dispongono di IPv6 endpoint che RDS limita al solo accesso VPC, garantendo che gli endpoint rimangano privati. IPv6 Le istanze DB pubbliche in modalità dual-stack forniscono entrambi gli endpoint a cui puoi accedere da Internet. IPv4 IPv6
**Topics**
+ [Modalità dual-stack e gruppi di sottoreti database](#USER_VPC.IP_addressing.dual-stack-db-subnet-groups)
+ [Utilizzo di istanze database in modalità dual-stack](#USER_VPC.IP_addressing.dual-stack-working-with)
+ [Modifica dei cluster di IPv4 sole DB per utilizzare la modalità dual-stack](#USER_VPC.IP_addressing.dual-stack-modifying-ipv4)
+ [Disponibilità di cluster database di rete dual-stack](#USER_VPC.IP_addressing.dual-stack-availability)
+ [Limitazioni per cluster database di rete dual-stack](#USER_VPC.IP_addressing.dual-stack-limitations)
Per un tutorial che mostra come creare un VPC con entrambi IPv4 IPv6 gli indirizzi da utilizzare per uno scenario Amazon comune, consulta. [Tutorial: Creazione di un VPC per l'utilizzo con un cluster database (modalità dual-stack)](CHAP_Tutorials.CreateVPCDualStack.md)
#### Modalità dual-stack e gruppi di sottoreti database
Per utilizzare la modalità dual-stack, assicurati che a ogni sottorete del gruppo di sottoreti DB associato al cluster di DB sia associato un blocco CIDR. IPv6 Per soddisfare questo requisito, puoi creare un nuovo gruppo di sottoreti database o modificare un gruppo di sottoreti database esistente. Quando cluster database sono in modalità dual-stack, i client possono connettersi normalmente. Assicurati che i firewall di sicurezza dei client e i gruppi di sicurezza delle istanze RDS DB siano configurati accuratamente per consentire il trasferimento del traffico. IPv6 Per connettersi, i client utilizzano l'endpoint dell'istanza principale del cluster database. Le applicazioni client possono specificare il protocollo preferito per la connessione a un database. In modalità dual-stack, il cluster di DB rileva il protocollo di rete preferito del client IPv6, IPv4 o lo utilizza per la connessione.
Se un gruppo di sottoreti database smette di supportare la modalità dual-stack a causa dell'eliminazione della sottorete o dell'annullamento dell'associazione con il blocco CIDR, si può verificare una situazione di stato di rete incompatibile per le istanze database associate al gruppo di sottoreti database. Inoltre, non puoi utilizzare il gruppo di sottoreti database quando crei un nuovo cluster database in modalità dual-stack.
Per determinare se un gruppo di sottoreti DB supporta la modalità dual-stack utilizzando il Console di gestione AWS, visualizza il **Tipo di rete** nella pagina dei dettagli del gruppo di sottoreti DB. Per determinare se un gruppo di sottoreti DB supporta la modalità dual-stack utilizzando il AWS CLI, esegui il comando e visualizza nell'output. [describe-db-subnet-groups](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-subnet-groups.html)`SupportedNetworkTypes`
Le repliche di lettura vengono trattate come istanze database indipendenti e possono avere un tipo di rete diverso dall'istanza database principale. Se si modifica il tipo di rete dell'istanza database principale di una replica di lettura, tale modifica non interessa la replica di lettura. Quando si ripristina un'istanza database, è possibile ripristinarla su qualsiasi tipo di rete supportato.
#### Utilizzo di istanze database in modalità dual-stack
Quando si crea o si modifica un cluster di DB, è possibile specificare la modalità dual-stack per consentire alle risorse di comunicare con il cluster di o entrambi. IPv4 IPv6
**Quando si utilizza Console di gestione AWS per creare o modificare un'istanza DB, è possibile specificare la modalità dual-stack nella sezione Tipo di rete.** L'immagine seguente mostra la sezione **Network type** (Tipo di rete) nella console.
![\[Sezione Tipo di rete nella console con l’opzione Modalità dual-stack selezionata.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/dual-stack-mode.png)
Quando utilizzi il AWS CLI per creare o modificare un cluster di DB, imposta l'`--network-type`opzione per utilizzare la modalità `DUAL` dual-stack. Quando usi l'API RDS per creare o modificare un cluster database, per utilizzare la modalità dual-stack imposta il parametro `NetworkType` su `DUAL`. Quando modifichi il tipo di rete di un'istanza database, è possibile che si verifichi un periodo di inattività. Se la modalità dual-stack non è supportata dalla versione del motore del database o dal gruppo di sottoreti database in uso, viene restituito l'errore `NetworkTypeNotSupported`.
Ulteriori informazioni sulla creazione di un cluster di database sono disponibili in [Creazione di un cluster database Amazon Aurora](Aurora.CreateInstance.md). Per ulteriori informazioni sulla modifica di un cluster di database, consultare [Modifica di un cluster database Amazon Aurora](Aurora.Modifying.md).
Per determinare se un cluster database è in modalità dual-stack utilizzando la console, visualizza l'opzione **Network type** (Tipo di rete) nella scheda **Connectivity & security** (Connettività e sicurezza) per il cluster database in questione.
#### Modifica dei cluster di IPv4 sole DB per utilizzare la modalità dual-stack
A tale scopo, devi modificare il tipo di rete del cluster database. La modifica potrebbe comportare tempi di inattività.
Ti consigliamo di modificare il tipo di rete dei cluster Amazon Aurora durante una finestra di manutenzione. L'impostazione predefinita del tipo di rete delle nuove istanze sulla modalità dual stack non è al momento supportata. È possibile impostare il tipo di rete manualmente utilizzando il comando `modify-db-cluster`.
Prima di modificare un cluster database per utilizzare la modalità dual-stack, assicurati che il gruppo di sottoreti DB supporti la modalità dual-stack. Se il gruppo di sottoreti DB associato al cluster database non supporta la modalità dual-stack, specifica un gruppo di sottoreti database diverso che supporta tale modalità quando modifichi il cluster database. La modifica del gruppo di sottoreti di database di un cluster di database può causare tempi di inattività.
Se si modifica il gruppo di sottoreti di database di un cluster di database prima di modificare il cluster di database per l'utilizzo della modalità Dual stack, assicurati che il gruppo di sottoreti di database sia valido per il cluster di database prima e dopo la modifica.
Ti consigliamo di eseguire l'[modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)API solo con il `--network-type` parametro con valore `DUAL` per modificare la rete di un cluster Amazon Aurora in modalità dual-stack. L’aggiunta di altri parametri al parametro `--network-type` nella stessa chiamata API potrebbe causare tempi di inattività.
Se non riesci a connetterti al cluster di DB dopo la modifica, assicurati che i firewall di sicurezza del client e del database e le tabelle di routing siano configurati con precisione per consentire il traffico verso il database sulla rete selezionata ( IPv4 o IPv6). Potrebbe inoltre essere necessario modificare i parametri del sistema operativo, le librerie o i driver per connetterti utilizzando un IPv6 indirizzo.
**Per modificare un cluster IPv4 di sole DB per utilizzare la modalità dual-stack**
1. Modificare un gruppo di sottoreti database per supportare la modalità dual-stack o creare un gruppo di sottoreti database che supporti la modalità dual-stack:
1. Associa un blocco IPv6 CIDR al tuo VPC.
Per istruzioni, consulta [Aggiungere un blocco IPv6 CIDR al tuo VPC](https://docs.aws.amazon.com/vpc/latest/userguide/modify-vpcs.html#vpc-associate-ipv6-cidr) nella *Amazon VPC* User Guide.
1. Collega il blocco IPv6 CIDR a tutte le sottoreti del gruppo di sottoreti DB.
Per istruzioni, consulta [Aggiungere un blocco IPv6 CIDR alla sottorete](https://docs.aws.amazon.com/vpc/latest/userguide/modify-subnets.html#subnet-associate-ipv6-cidr) nella Amazon *VPC* User Guide.
1. Verificare che il gruppo di sottoreti database supporti la modalità dual-stack.
**Se utilizzi il Console di gestione AWS, seleziona il gruppo di sottoreti DB e assicurati che il valore **Supported network types** sia Dual,. IPv4**
Se utilizzi il AWS CLI, esegui il [describe-db-subnet-groups](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-subnet-groups.html)comando e assicurati che il `SupportedNetworkType` valore per l'istanza DB sia`Dual, IPv4`.
1. Modifica il gruppo di sicurezza associato al cluster di DB per consentire IPv6 le connessioni al database o crea un nuovo gruppo di sicurezza che consenta IPv6 le connessioni.
Per le istruzioni, vedere [Regole del gruppo di sicurezza](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html) nella *Guida per l'utente di Amazon VPC*.
1. Modifica il cluster database in modo che supporti la modalità dual-stack. A questo scopo, imposta l'opzione **Network type** (Tipo di rete) su **Dual-stack mode** (Modalità dual-stack).
In caso di utilizzo della console, accertati che le impostazioni seguenti siano corrette:
+ **Tipo di rete**–**Dual-stack mode (Modalità dual-stack)**
![\[Sezione Tipo di rete nella console con l’opzione Modalità dual-stack selezionata.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/dual-stack-mode.png)
+ **DB subnet group** (Gruppo di sottoreti DB): gruppo di sottoreti database configurato in un passaggio precedente
+ **Security group** (Gruppo di sicurezza): gruppo di sicurezza di default configurato in un passaggio precedente
Se utilizzi il AWS CLI, assicurati che le seguenti impostazioni siano corrette:
+ `--network-type` – `dual`
+ `--db-subnet-group-name`: gruppo di sottoreti database configurato in un passaggio precedente
+ `--vpc-security-group-ids`: gruppo di sicurezza VPC configurato in un passaggio precedente
Esempio:
```
aws rds modify-db-cluster --db-cluster-identifier my-cluster --network-type "DUAL"
```
1. Verifica che il cluster database supporti la modalità dual-stack.
Se utilizzi la console, scegli la scheda **Configuration** (Configurazione) per il cluster database. In quella scheda, assicurati che il valore dell'opzione **Network type** (Tipo di rete) sia **Dual-stack mode** (Modalità dual-stack).
Se utilizzi il AWS CLI, esegui il [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html)comando e assicurati che il `NetworkType` valore per il cluster DB sia`dual`.
Esegui il `dig` comando sull'endpoint dell'istanza Writer DB per identificare l' IPv6indirizzo ad esso associato.
```
dig db-instance-endpoint AAAA
```
Utilizza l'endpoint dell'istanza Writer DB, non l' IPv6 indirizzo, per connetterti al cluster di DB.
#### Disponibilità di cluster database di rete dual-stack
I cluster DB di rete dual-stack sono disponibili in tutti Regioni AWS gli ambienti ad eccezione dei seguenti:
+ Asia Pacifico (Hyderabad)
+ Asia Pacifico (Malesia)
+ Asia Pacifico (Melbourne)
+ Asia Pacifico (Thailandia)
+ Canada occidentale (Calgary)
+ Europa (Spagna)
+ Europa (Zurigo)
+ Israele (Tel Aviv)
+ Messico (centrale)
+ Medio Oriente (Emirati Arabi Uniti)
Le seguenti versioni del motore del database supportano i cluster di database di rete dual-stack:
+ Versioni Aurora MySQL:
+ 3.02 o versioni successive alla 3
+ 2.09.1 o versioni successive alla 2
Per ulteriori informazioni sulle versioni di Aurora MySQL, consulta la sezione [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/Welcome.html](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/Welcome.html).
+ Versioni di Aurora PostgreSQL:
+ 15.2 e tutte le versioni successive
+ 14.3 o versioni successive alla 14
+ 13.7 o versioni successive alla 13
Per ulteriori informazioni sulle versioni di Aurora PostgreSQL, consulta [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/Welcome.html](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/Welcome.html).
#### Limitazioni per cluster database di rete dual-stack
Le seguenti limitazioni si applicano ai cluster database di rete dual-stack:
+ I cluster di DB non possono utilizzare esclusivamente il protocollo. IPv6 Possono utilizzare IPv4 esclusivamente oppure possono utilizzare il IPv6 protocollo IPv4 and (modalità dual-stack).
+ Amazon RDS non supporta IPv6 sottoreti native.
+ Non è possibile utilizzare il proxy RDS con cluster database in modalità dual-stack.
## Nascondere cluster database in un VPC da Internet
Uno scenario Amazon Aurora comune è quello di avere un VPC in cui disponi di un’istanza Amazon EC2 con un’applicazione web pubblica e un cluster di database con un database che non è pubblicamente accessibile. Puoi ad esempio creare un VPC che ha una sottorete pubblica e una sottorete privata. Le istanze EC2 che fungono da server web possono essere implementate nella sottorete pubblica. L'implementazione di cluster database viene invece eseguita nella sottorete privata. In tale implementazione, solo i server Web hanno accesso ai cluster database. Per un'illustrazione di questo scenario, consulta [Un cluster di database in un VPC a cui accede un’istanza EC2 nello stesso VPC](USER_VPC.Scenarios.md#USER_VPC.Scenario1).
Quando si avvia un cluster database all'interno di un VPC, il cluster database dispone di un indirizzo IP privato per il traffico all'interno del VPC. Questo indirizzo IP privato non è accessibile pubblicamente. Puoi utilizzare l'opzione **Public access** (Accesso pubblico) per indicare se il cluster database dispone anche di un indirizzo IP pubblico oltre all'indirizzo IP privato. Se il cluster database è definito come accessibile pubblicamente, il relativo endpoint DNS utilizza l'indirizzo IP privato dall'interno del VPC. Utilizza invece l'indirizzo IP pubblico dall'esterno del VPC. L'accesso al cluster database è in ultima analisi controllato dal gruppo di sicurezza in uso. Questo accesso pubblico non è consentito se il gruppo di sicurezza assegnato al cluster database non include regole in entrata che lo consentono. Per un cluster database che deve essere accessibile pubblicamente, le sottoreti nel relativo gruppo di sottoreti DB devono disporre di un gateway Internet. Per ulteriori informazioni, consulta [Impossibile connettersi all'istanza database di Amazon RDS](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Connecting)
Puoi modificare un cluster database per attivare o disattivare l'accessibilità pubblica modificando l'opzione **Public access** (Accesso pubblico). Nella figura seguente viene illustrata l'opzione **Public access (Accesso pubblico)** nella sezione **Additional connectivity configuration (Configurazioni di connettività aggiuntiva)** . Per impostare l'opzione, apri la sezione **Additional connectivity configuration (Configurazioni di connettività aggiuntiva)** nella sezione **Connectivity (Connettività)** .
![\[Imposta l’opzione Accesso pubblico del database nella sezione Configurazione di connettività aggiuntiva su No.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/VPC-example4.png)
Per informazioni sulla modifica di un'istanza database per impostare l'opzione **Public access (Accesso pubblico)**, consulta [Modifica di un'istanza database in un cluster database](Aurora.Modifying.md#Aurora.Modifying.Instance).
## Creazione di un cluster database in un VPC
Le procedure seguenti aiutano a creare un cluster database in un VPC. Per utilizzare il VPC predefinito, puoi iniziare con il passaggio 2 e utilizzare il VPC e il gruppo di sottoreti DB creati automaticamente. Se desideri creare un VPC aggiuntivo, puoi creare un nuovo VPC.
**Nota**
Se desideri che il cluster database nel VPC sia pubblicamente accessibile, devi aggiornare le informazioni DNS per il VPC attivando gli attributi VPC *DNS hostnames* (Nomi host DNS) e *DNS resolution* (Risoluzione DNS). Per informazioni sull'aggiornamento delle informazioni DNS per un'istanza VPC, consulta [Aggiornamento del supporto DNS per il VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html).
Segui questa procedura per creare un'istanza database in un VPC:
+ [Fase 1. Creazione di un VPC](#USER_VPC.CreatingVPC)
+ [Fase 2: creazione di un gruppo di sottoreti database](#USER_VPC.CreateDBSubnetGroup)
+ [Fase 3: creazione di un gruppo di sicurezza VPC](#USER_VPC.CreateVPCSecurityGroup)
+ [Passaggio 4: creazione di un'istanza database nel VPC](#USER_VPC.CreateDBInstanceInVPC)
### Fase 1. Creazione di un VPC
Crea un VPC con sottoreti in almeno due zone di disponibilità. Usi queste sottoreti quando crei un gruppo di sottoreti database. Se disponi di un VPC di default, viene creata automaticamente una sottorete in ciascuna zona di disponibilità nella Regione AWS.
Per ulteriori informazioni, consulta [Creazione di un VPC con sottoreti pubbliche e private](CHAP_Tutorials.WebServerDB.CreateVPC.md#CHAP_Tutorials.WebServerDB.CreateVPC.VPCAndSubnets) oppure [Creazione di un VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#Create-VPC) nella *Guida per l'utente di Amazon VPC*..
### Fase 2: creazione di un gruppo di sottoreti database
Un gruppo di sottoreti DB è una raccolta di sottoreti (generalmente private) creata per un VPC e che è possibile definire per i cluster database. Un gruppo di sottoreti DB consente di specificare un particolare VPC quando si creano cluster di istanze utilizzando AWS CLI l'API o RDS. Se utilizzi la console, puoi scegliere il VPC e le sottoreti che desideri usare. Ogni gruppo di sottoreti database deve avere almeno una sottorete in almeno due zone di disponibilità nella Regione AWS. Come best practice, ogni gruppo di sottoreti database deve disporre di almeno una sottorete per ogni zona di disponibilità nella Regione AWS.
Per un cluster database che deve essere accessibile pubblicamente, le sottoreti nel gruppo di sottoreti database devono disporre di un gateway Internet. Per ulteriori informazioni sui gateway Internet, consulta [Eseguire la connessione a Internet utilizzando un gateway Internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html) nella *Guida per l'utente di Amazon VPC*.
Quando crei un cluster database in un VPC, puoi selezionare un gruppo di sottoreti DB. Amazon Aurora sceglie una sottorete e un indirizzo IP al suo interno da associare al cluster database. Se non esistono gruppi di sottoreti DB, Amazon Aurora crea un gruppo di sottoreti predefinito quando crei un cluster database. Amazon Aurora crea e associa un'interfaccia di rete elastica al cluster database con tale indirizzo IP. Il cluster database utilizza la zona di disponibilità contenente la sottorete.
In questo passaggio, si crea un gruppo di sottoreti database e si aggiungono le sottoreti create per il VPC.
**Creare un gruppo di sottoreti database**
1. Aprire la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Nel pannello di navigazione selezionare **Subnet groups (Gruppi di sottoreti)**.
1. Scegli **Create DB Subnet Group (Crea gruppo di sottoreti del database)**.
1. Per **Name (Nome)**, digita il nome del gruppo di sottoreti database.
1. Per **Description Descrizione)**, digita una descrizione per il gruppo di sottoreti database.
1. In **VPC**, scegli il VPC predefinito o il VPC creato in precedenza.
1. Nella sezione **Aggiungi sottoreti**, scegliere le zone di disponibilità che includono le sottoreti da **Zone di disponibilità**, quindi scegliere le sottoreti da **Sottoreti**.
![\[Creazione di un gruppo di sottoreti del database.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/RDSVPC101.png)
1. Scegliere **Create (Crea)**.
Il nuovo gruppo di sottoreti database viene visualizzato nell'elenco dei gruppi di sottoreti database sulla console RDS. Puoi scegliere il gruppo di sottoreti database per visualizzare i dettagli, comprese tutte le sottoreti associate al gruppo, nel riquadro dei dettagli nella parte inferiore della finestra.
### Fase 3: creazione di un gruppo di sicurezza VPC
Prima di creare un cluster database, devi creare un gruppo di sicurezza VPC da associare tale cluster database. Se non crei un gruppo di sicurezza VPC, puoi utilizzare il gruppo di sicurezza predefinito quando crei un cluster database. Per istruzioni su come creare un gruppo di sicurezza per il cluster database, consulta [Creazione di un gruppo di sicurezza VPC per un cluster database privato](CHAP_Tutorials.WebServerDB.CreateVPC.md#CHAP_Tutorials.WebServerDB.CreateVPC.SecurityGroupDB) oppure [Controlla il traffico verso le risorse utilizzando gruppi di sicurezza](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) nella *Guida per l'utente di Amazon VPC*.
### Passaggio 4: creazione di un'istanza database nel VPC
In questo passaggio, si crea un cluster database e si utilizza il nome VPC, il gruppo di sottoreti DB e il gruppo di sicurezza VPC creato nel passaggio precedente.
**Nota**
Se desideri che il cluster database nel VPC sia pubblicamente accessibile, devi abilitare gli attributi *VPC DNS hostnames* (Nomi host DNS) e *DNS resolution* (Risoluzione DNS). Per ulteriori informazioni, consulta [Attributi DNS per il VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html) nella *Guida per l'utente di Amazon VPC*.
Per informazioni dettagliate su come creare un cluster di database, consulta [Creazione di un cluster database Amazon Aurora](Aurora.CreateInstance.md).
Quando richiesto nella sezione **Connectivity** (Connettività), inserisci il nome VPC, il gruppo di sottoreti DB e il gruppo di sicurezza VPC.
**Nota**
L'aggiornamento VPCs non è attualmente supportato per i cluster Aurora DB.
# Scenari per accedere a un cluster database in un VPC
Amazon Aurora supporta i seguenti scenari per accedere a un cluster database in un VPC:
+ [Un’istanza Amazon EC2 nella stessa VPC](#USER_VPC.Scenario1)
+ [Un'istanza EC2 in un VPC diverso](#USER_VPC.Scenario3)
+ [Un'applicazione client tramite internet](#USER_VPC.Scenario4)
+ [Una rete privata](#USER_VPC.NotPublic)
## Un cluster di database in un VPC a cui accede un’istanza EC2 nello stesso VPC
Un uso comune di un cluster di database in un VPC è quello di condividere dati con un server di applicazione in esecuzione in un’istanza EC2 nello stesso VPC.
Il seguente diagramma mostra questo scenario.
![\[Scenario VPC con un server web pubblico e un database privato\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/con-VPC-sec-grp-aurora.png)
Il modo più semplice per gestire l'accesso tra istanze EC2 e cluster di database nello stesso VPC consiste nel fare quanto segue:
+ Creare un gruppo di sicurezza VPC in cui si troveranno i cluster database. Questo gruppo di sicurezza può essere usato per limitare l'accesso ai cluster database. Ad esempio, puoi creare una regola personalizzata per questo gruppo di sicurezza. Ciò potrebbe consentire l'accesso TCP usando la porta assegnata al cluster database al momento della creazione della stessa e un indirizzo IP utilizzato per accedere al cluster database per lo sviluppo o per altri scopi.
+ Crea un gruppo di sicurezza VPC in cui si troveranno le istanze EC2 (server Web e client). Questo gruppo di sicurezza può, se necessario, consentire l'accesso all'istanza EC2 da Internet tramite la tabella di routing del VPC. Ad esempio, può impostare regole in questo gruppo di sicurezza per consentire l'accesso TCP all'istanza EC2 sulla porta 22.
+ Creare regole personalizzate nel gruppo di sicurezza per i cluster database che consentono connessioni dal gruppo di sicurezza creato per le istanze EC2. Queste regole potrebbero consentire a qualsiasi membro del gruppo di sicurezza di accedere ai cluster database.
È disponibile una sottorete pubblica e privata aggiuntiva in una zona di disponibilità separata. Un gruppo di sottoreti DB RDS richiede una sottorete in almeno due zone di disponibilità. La sottorete aggiuntiva semplifica il passaggio a un'implementazione Multi-AZ di un'istanza DB in futuro.
Per una dimostrazione che mostri come creare un VPC con sottoreti pubbliche e private per questo scenario, consulta [Tutorial: crea un VPC da utilizzare con un cluster di DB (solo) IPv4](CHAP_Tutorials.WebServerDB.CreateVPC.md).
**Suggerimento**
Quando crei un cluster database, puoi configurare automaticamente la connettività di rete tra un'istanza Amazon EC2 e un cluster database. Per ulteriori informazioni, consulta [Configurazione della connettività di rete automatica con un'istanza EC2](Aurora.CreateInstance.md#Aurora.CreateInstance.Prerequisites.VPC.Automatic) .
**Per creare una regola in un gruppo di sicurezza VPC che consente delle connessioni da un altro gruppo di sicurezza, esegui la procedura seguente:**
1. [Accedi a Console di gestione AWS e apri la console Amazon VPC all'indirizzo https://console.aws.amazon.com /vpc.](https://console.aws.amazon.com/vpc)
1. Fai clic su **Security Groups** (Gruppi di sicurezza) nel pannello di navigazione.
1. Scegli o crea un gruppo di sicurezza per il quale desideri concedere l'accesso ai membri di un altro gruppo di sicurezza. Nello scenario precedente, questo è il gruppo di sicurezza utilizzato per i cluster database. Seleziona la scheda **Regole in entrata**, quindi scegli **Modifica regola**.
1. Nella scheda **Modifica regole in entrata**, seleziona **Aggiungi regola**.
1. Per **Tipo**, scegli la voce che corrisponde alla porta utilizzata durante la creazione del cluster database, ad esempio **MySQL/Aurora**.
1. Nella casella **Origine** iniziare a digitare l'ID del gruppo di sicurezza, che elenca i gruppi di sicurezza corrispondenti. Scegli il gruppo di sicurezza con i membri che desideri abbiano accesso alle risorse protette da questo gruppo di sicurezza. Nello scenario precedente, questo è il gruppo di sicurezza utilizzato per le istanze EC2.
1. Se necessario, ripeti i passaggi per il protocollo TCP creando una regola con **All TCP (Tutti i TCP)** come **Tipo** e il gruppo di sicurezza nella casella **Source (Origine)**. Se desideri usare il protocollo UDP, crea una regola con **All UDP** (Tutti i UDP) come **Type** (Tipo) e il gruppo di sicurezza nella casella **Source** (Origine).
1. Scegliere **Salva regole**.
Nella schermata seguente viene illustrata una regola in entrata con un gruppo di sicurezza per la relativa origine.
![\[Aggiunta di un gruppo di sicurezza alle regole di un altro gruppo di sicurezza\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/con-vpc-add-sg-rule.png)
Per ulteriori informazioni sulla connessione al cluster di database dall'istanza EC2, consulta [Connessione a un cluster database Amazon Aurora](Aurora.Connecting.md).
## Un cluster database in un VPC a cui accede un'istanza EC2 in un VPC diverso
Quando i cluster database si trova in un VPC diverso dall'istanza EC2 che si sta utilizzando per accedervi, puoi utilizzare il peering VPC per accedere al cluster database.
Il seguente diagramma mostra questo scenario.
![\[Istanza database in un VPC a cui accede un’istanza EC2 in un VPC diverso\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/RDSVPC2EC2VPC-aurora.png)
Una connessione peering VPC è una connessione di rete tra due VPCs che consente di instradare il traffico tra di loro utilizzando indirizzi IP privati. Le risorse in uno qualsiasi dei VPC possono comunicare tra loro come se fossero nella stessa rete. Puoi creare una connessione peering VPC tra i tuoi account VPCs, con un VPC in un altro AWS account o con un VPC in un altro. Regione AWS Per ulteriori informazioni su VPC in peering, consulta [Peering di VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html) nella *Guida per l'utente di Amazon Virtual Private Cloud*.
## Un cluster database in un VPC a cui accede un'applicazione client tramite Internet
Per accedere a cluster database in un VPC da un'applicazione client tramite Internet, configura un VPC con una sottorete pubblica singola e un gateway Internet per abilitare la comunicazione in Internet.
Il seguente diagramma mostra questo scenario.
![\[Un cluster di database in un VPC a cui accede un’applicazione client tramite Internet\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/GS-VPC-network-aurora.png)
È consigliabile utilizzare la seguente configurazione:
+ Un VPC di dimensione /16 (ad esempio, CIDR: 10.0.0.0/16). Questa dimensione fornisce indirizzi 65.536 indirizzi IP privati.
+ Una sottorete di dimensione /24 (ad esempio, CIDR: 10.0.0.0/24). Questa dimensione fornisce 256 indirizzi IP privati.
+ Un cluster di database Amazon Aurora che è in associazione al VPC e alla sottorete. Amazon RDS assegna un indirizzo IP nella sottorete al cluster database.
+ Un gateway Internet che collega il VPC a Internet e agli altri prodotti AWS .
+ Un gruppo di sicurezza associato al cluster database. Le regole in entrata del gruppo di sicurezza consentono all'applicazione client di accedere al cluster database.
Per informazioni su come creare un cluster database in un VPC, consulta [Creazione di un cluster database in un VPC](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.InstanceInVPC).
## Un cluster database in un VPC a cui si accede da una rete privata
Se il cluster database non è accessibile pubblicamente, sono disponibili le seguenti opzioni per consentire l'accesso da una rete privata:
+ Una connessione VPN. AWS Site-to-Site Per maggiori informazioni, consulta [Che cos’è AWS Site-to-Site VPN?](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html)
+ Una Direct Connect connessione. Per ulteriori informazioni, vedi [Cos'è Direct Connect?](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html)
+ Una AWS Client VPN connessione. Per maggiori informazioni, consulta [Che cos’è AWS Client VPN?](https://docs.aws.amazon.com//vpn/latest/clientvpn-admin/what-is.html)
Il diagramma seguente mostra uno scenario con una connessione AWS Site-to-Site VPN.
![\[cluster di database in un VPC a cui si accede da una rete privata.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/site-to-site-vpn-connection-aurora.png)
Per ulteriori informazioni, consulta [Riservatezza del traffico Internet](inter-network-traffic-privacy.md).
# Tutorial: crea un VPC da utilizzare con un cluster di DB (solo) IPv4
Uno scenario comune include un cluster database in un cloud privato virtuale (VPC) basato sul servizio Amazon VPC. Questo VPC condivide i dati con un server Web in esecuzione nello stesso VPC. In questo tutorial eseguirai la creazione del VPC in questo scenario.
Il seguente diagramma mostra questo scenario. Per informazioni su altri scenari, consulta [Scenari per accedere a un cluster database in un VPC](USER_VPC.Scenarios.md).
![\[Scenario VPC singolo\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/con-VPC-sec-grp-aurora.png)
Il cluster database deve essere disponibile solo per il server Web e non per la rete Internet pubblica. Pertanto, occorre creare un VPC con sottoreti pubbliche e private. Il server Web è ospitato nella sottorete pubblica, in modo da poter raggiungere l'Internet pubblico. Il cluster database è ospitato in una sottorete privata. Il server Web può connettersi al cluster database perché è ospitato nello stesso VPC. Tuttavia, il cluster database non è disponibile per la rete Internet pubblica e ciò garantisce una maggiore sicurezza.
Questo tutorial configura una sottorete pubblica e privata aggiuntiva in una zona di disponibilità separata. Queste sottoreti non vengono utilizzate dal tutorial. Un gruppo di sottoreti DB RDS richiede una sottorete in almeno due zone di disponibilità. La sottorete aggiuntiva semplifica la configurazione di più istanze database Aurora.
In questa esercitazione viene descritta la configurazione di un VPC per cluster di database Amazon Aurora. Per un'esercitazione che illustra come creare un server Web per questo scenario VPC, consulta [Tutorial: creazione di un server Web e un cluster database Amazon Aurora](TUT_WebAppWithRDS.md). Per ulteriori informazioni su Amazon VPC, consulta [Guida alle operazioni di base di Amazon VPC](https://docs.aws.amazon.com/AmazonVPC/latest/GettingStartedGuide/) e [Guida per l'utente di Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/).
**Suggerimento**
Quando crei un cluster database, puoi configurare automaticamente la connettività di rete tra un'istanza Amazon EC2 e un cluster database. La configurazione di rete è simile a quella descritta in questo tutorial. Per ulteriori informazioni, consulta [Configurazione della connettività di rete automatica con un'istanza EC2](Aurora.CreateInstance.md#Aurora.CreateInstance.Prerequisites.VPC.Automatic).
## Creazione di un VPC con sottoreti pubbliche e private
Utilizza la procedura seguente per creare un VPC con sottoreti pubbliche e private.
**Per creare un VPC e sottoreti**
1. Apri la console Amazon VPC all'indirizzo [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Nell'angolo in alto a destra di Console di gestione AWS, scegli la regione in cui creare il tuo VPC. In questo esempio viene utilizzata la regione Stati Uniti occidentali (Oregon).
1. Nell'angolo in alto a sinistra, scegli **VPC Dashboard** (Pannello di controllo VPC). Per iniziare a creare un VPC, scegli **Create VPC** (Crea VPC).
1. In **Resources to create** (Risorse da creare) nell'area **VPC settings** (Impostazioni VPC), scegli **VPC and more** (VPC e altro).
1. In **VPC settings** (Impostazioni VPC) restanti, imposta i seguenti valori:
+ **Name tag auto-generation** (Generazione automatica del tag del nome): **tutorial**
+ **IPv4 Blocco CIDR:** **10.0.0.0/16**
+ IPv6 Blocco **CIDR: **nessun IPv6 ** blocco** CIDR
+ **Tenancy** (Locazione): **Default**
+ **Numero di zone di disponibilità (AZs)** **— 2**
+ **Personalizza AZs**: mantiene i valori predefiniti.
+ **Number of public subnet** (Numero di sottoreti pubbliche): **2**
+ **Number of private subnets** (Numero di sottoreti private): **2**
+ **Customize subnets CIDR blocks** (Personalizza blocchi CIDR delle sottoreti): mantieni i valori predefiniti.
+ **NAT gateways (\$1)** (Gateway NAT): **nessuna**
+ **VPC endpoints** (Endpoint VPC): **nessuno**
+ **DNS options** (Opzioni DNS): mantieni i valori predefiniti.
1. Seleziona **Create VPC** (Crea VPC).
## Creazione di un gruppo di sicurezza VPC per un server Web pubblico
È possibile a questo punto aggiungere un gruppo di sicurezza per l'accesso pubblico. Per connetterti alle istanze EC2 nel VPC, aggiungi regole in entrata al gruppo di sicurezza VPC. Queste consentono al traffico di connettersi da Internet.
**Per creare un gruppo di sicurezza VPC**
1. Apri la console Amazon VPC all'indirizzo [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Scegliere **VPC Dashboard (Pannello di controllo VPC)**, **Security Groups (Gruppi di sicurezza)** e quindi **Create security group (Crea gruppo di sicurezza)**.
1. Nella pagina **Create security group (Crea gruppo di sicurezza)** impostare questi valori:
+ **Security group name: (Nome del gruppo di sicurezza:** **tutorial-securitygroup**
+ **Descrizione:** **Tutorial Security Group**
+ **VPC:** scegli il VPC che hai creato in precedenza, ad esempio: vpc- (**tutorial-vpc**) *identifier*
1. Aggiungere regole in entrata al gruppo di sicurezza
1. Determina l'indirizzo IP da utilizzare per connettersi alle istanze EC2 nel VPC utilizzando Secure Shell (SSH). Per determinare il tuo indirizzo IP pubblico, in un'altra finestra o scheda del browser, puoi utilizzare il servizio all'indirizzo. [https://checkip.amazonaws.com](https://checkip.amazonaws.com) Un esempio di indirizzo IP è `203.0.113.25/32`.
In molti casi, è possibile eseguire la connessione tramite un fornitore di servizi Internet (ISP) o con la protezione di un firewall senza un indirizzo IP statico. In tal caso, trova l'intervallo di indirizzi IP utilizzati dai computer client.
**avvertimento**
Se utilizzi `0.0.0.0/0` per l'accesso SSH, consenti a tutti gli indirizzi IP di accedere alle istanze pubbliche utilizzando SSH. Questo approccio è accettabile per un breve periodo di tempo in un ambiente di test, ma non è sicuro per gli ambienti di produzione. In produzione, autorizza solo un determinato indirizzo IP o un intervallo di indirizzi per accedere alle istanze utilizzando SSH.
1. Nella sezione **Regole in entrata**, scegliere **Aggiungi regola**.
1. Imposta i seguenti valori per la nuova regola in entrata per consentire l'accesso SSH all'istanza Amazon EC2. In tal caso, è possibile eseguire la connessione all'istanza Amazon EC2 per installare il server Web e altre utility. Puoi connetterti all'istanza EC2 anche per caricare contenuto per il server Web.
+ **Tipo:** **SSH**
+ **Origine**: indirizzo IP o intervallo ottenuto nella fase 1, ad esempio **203.0.113.25/32**.
1. Scegli **Aggiungi regola**.
1. Imposta i seguenti valori per la nuova regola in entrata per consentire l'accesso HTTP al server Web:
+ **Tipo:** **HTTP**
+ **Origine**: **0.0.0.0/0**
1. Per creare il gruppo di sicurezza, scegli **Create security group** (Crea gruppo di sicurezza).
Prendi nota dell'ID del gruppo di sicurezza perché sarà necessario in seguito in questo tutorial.
## Creazione di un gruppo di sicurezza VPC per un cluster database privato
Per mantenere il cluster database privato, crea un secondo gruppo di sicurezza per l'accesso privato. Per connetterti ai cluster di database privati nel VPC, aggiungi regole in entrata al gruppo di sicurezza VPC per consentire il traffico solo dal server web.
**Per creare un gruppo di sicurezza VPC**
1. Apri la console Amazon VPC all'indirizzo [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Scegliere **VPC Dashboard (Pannello di controllo VPC)**, **Security Groups (Gruppi di sicurezza)** e quindi **Create security group (Crea gruppo di sicurezza)**.
1. Nella pagina **Create security group (Crea gruppo di sicurezza)** impostare questi valori:
+ **Security group name: (Nome del gruppo di sicurezza:** **tutorial-db-securitygroup**
+ **Descrizione:** **Tutorial DB Instance Security Group**
+ **VPC:** scegli il VPC che hai creato in precedenza, ad esempio: vpc- (**tutorial-vpc**) *identifier*
1. Aggiungere regole in entrata al gruppo di sicurezza
1. Nella sezione **Regole in entrata**, scegliere **Aggiungi regola**.
1. Imposta i valori seguenti per la nuova regola in entrata per consentire il traffico MySQL sulla porta 3306 dall'istanza Amazon EC2. In tal caso, puoi connetterti dal server Web al cluster database ed eseguire l'archiviazione e il recupero dei dati dall'applicazione Web nel database.
+ **Tipo:** **MySQL/Aurora**
+ **Source** (Origine): l'identificatore del gruppo di sicurezza **tutorial-securitygroup** creato in precedenza in questo tutorial, ad esempio **sg-9edd5cfb**.
1. Per creare il gruppo di sicurezza, scegli **Create security group** (Crea gruppo di sicurezza).
## Per creare un gruppo di sottoreti del database
Un *gruppo di sottoreti DB* è una raccolta di sottoreti creata in un VPC e che è possibile indicare per i cluster database. Un gruppo di sottoreti DB consente di specificare un determinato VPC quando si creano cluster database.
**Come creare un gruppo di sottoreti database**
1. Identifica le sottoreti private per il database nel VPC.
1. Apri la console Amazon VPC all'indirizzo [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Scegli **VPC Dashboard** (Pannello di controllo VPC), quindi seleziona **Subnets** (Sottoreti).
1. ****Nota la sottorete delle sottoreti denominata IDs 1-us-west-2a e 2-us-west-2b. tutorial-subnet-private tutorial-subnet-private****
La sottorete è necessaria quando create il gruppo di sottoreti DB. IDs
1. Aprire la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
Assicurarsi di connettersi alla console Amazon RDS e non alla console Amazon VPC.
1. Nel pannello di navigazione selezionare **Subnet groups (Gruppi di sottoreti)**.
1. Scegli **Create DB Subnet Group** (Crea gruppo di sottoreti del database).
1. Nella pagina **Create DB subnet group (Crea gruppo di sottoreti del database)** impostare questi valori in **Subnet group details (Dettagli gruppi di sottoreti)**:
+ **Nome:** **tutorial-db-subnet-group**
+ **Descrizione:** **Tutorial DB Subnet Group**
+ **VPC: **tutorial-vpc**** (vpc-) *identifier*
1. Nella sezione **Aggiungi sottoreti**, scegliere **Zone di disponibilità** e **Sottoreti**.
Per questo tutorial, scegli **us-west-2a** e **us-west-2b** per l'opzione **Availability Zones** (Zone di disponibilità). In **Subnets** (Sottoreti), scegli le sottoreti private identificate nella fase precedente.
1. Scegli **Create** (Crea).
Il nuovo gruppo di sottoreti database viene visualizzato nell'elenco dei gruppi di sottoreti database sulla console RDS. Puoi scegliere il gruppo di sottoreti DB per visualizzare i dettagli nel riquadro dei dettagli nella parte inferiore della finestra. Questi dettagli includono tutte le sottoreti associate al gruppo.
**Nota**
Se questo VPC è stato creato per il completamento di [Tutorial: creazione di un server Web e un cluster database Amazon Aurora](TUT_WebAppWithRDS.md), creare il cluster di database seguendo le istruzioni riportate in [Creazione di un cluster di database Amazon Aurora](CHAP_Tutorials.WebServerDB.CreateDBCluster.md).
## Eliminazione del VPC
Dopo aver creato il VPC e altre risorse per questo tutorial, è possibile eliminarle se non sono più necessarie.
**Nota**
Se hai aggiunto risorse nel VPC creato per questo tutorial, potrebbe essere necessario eliminarle prima di poter eliminare il VPC. Ad esempio, queste risorse potrebbero includere istanze Amazon EC2 o cluster database Amazon RDS. Per ulteriori informazioni, consulta [Eliminazione del VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#VPC_Deleting) nella *Guida per l'utente di Amazon VPC*.
**Per eliminare un VPC e le risorse correlate**
1. Eliminare il gruppo di sottoreti di database.
1. Aprire la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Nel pannello di navigazione selezionare **Subnet groups (Gruppi di sottoreti)**.
1. Seleziona il gruppo di sottoreti DB che desideri eliminare, ad esempio. **tutorial-db-subnet-group**
1. Scegliere **Delete (Elimina)** e quindi scegliere **Delete (Elimina)** nella finestra di conferma.
1. Nota l'ID VPC.
1. Apri la console Amazon VPC all'indirizzo [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Scegli **VPC Dashboard**, quindi scegli. **VPCs**
1. Nell'elenco, identifica il VPC creato, ad esempio **tutorial-vpc**.
1. Prendi nota del valore **ID VPC** del VPC creato. L'ID VPC è richiesto nei passaggi successivi.
1. Eliminare i gruppi di sicurezza.
1. Apri la console Amazon VPC all'indirizzo [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Scegliere **VPC Dashboard (Pannello di controllo VPC)** e quindi scegliere **Security Groups (Gruppi di sicurezza)**.
1. Seleziona il gruppo di sicurezza per l'istanza database di Amazon RDS, ad esempio. **tutorial-db-securitygroup**
1. In **Actions** (Operazioni), scegli **Delete security groups** (Elimina gruppi di sicurezza) e quindi scegli **Delete** (Elimina) nella pagina di conferma.
1. Sulla pagina **Security Groups (Gruppi di sicurezza)**, selezionare il gruppo di sicurezza per l'istanza Amazon EC2, ad esempio **tutorial-securitygroup**.
1. In **Actions** (Operazioni), scegli **Delete security groups** (Elimina gruppi di sicurezza) e quindi scegli **Delete** (Elimina) nella pagina di conferma.
1. Elimina il VPC.
1. Apri la console Amazon VPC all'indirizzo [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Scegli **VPC Dashboard**, quindi scegli. **VPCs**
1. Selezionare il VPC che si desidera eliminare, ad esempio **tutorial-vpc**.
1. In **Operazioni**, scegli **Elimina VPC**.
Nella pagina di conferma vengono visualizzate altre risorse associate al VPC che verranno eliminate, incluse le subnet associate.
1. Nella pagina di conferma, immetti **delete** e scegliere **Delete (Elimina)**.
# Tutorial: Creazione di un VPC per l'utilizzo con un cluster database (modalità dual-stack)
Uno scenario comune include un cluster database in un cloud privato virtuale (VPC) basato sul servizio Amazon VPC. Questo VPC condivide i dati con un'istanza Amazon EC2 pubblica in esecuzione nello stesso VPC.
In questo tutorial, si crea il VPC per questo scenario che funziona con un database in esecuzione in modalità dual-stack. Modalità dual-stack per abilitare la connessione tramite il IPv6 protocollo di indirizzamento. Per ulteriori informazioni sull'indirizzamento IP, consulta [Assegnazione di indirizzi IP in Amazon Aurora](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.IP_addressing).
I cluster di rete dual-stack sono supportati nella maggior parte delle regioni. Per ulteriori informazioni, consulta [Disponibilità di cluster database di rete dual-stack](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.IP_addressing.dual-stack-availability). Per esaminare le limitazioni della modalità dual-stack, consulta [Limitazioni per cluster database di rete dual-stack](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.IP_addressing.dual-stack-limitations).
Il seguente diagramma mostra questo scenario.
![\[Scenario VPC per la modalità dual-stack\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/con-VPC-sec-grp-dual-stack-aurora.png)
Per informazioni su altri scenari, consulta [Scenari per accedere a un cluster database in un VPC](USER_VPC.Scenarios.md).
Il cluster database deve essere disponibile solo per l'istanza Amazon EC2 e non per la rete Internet pubblica. Pertanto, occorre creare un VPC con sottoreti pubbliche e private. Il server Web è ospitato nella sottorete pubblica, in modo da poter raggiungere l'Internet pubblico. Il cluster database è ospitato in una sottorete privata. L'istanza Amazon EC2 può connettersi al cluster database perché è ospitata nello stesso VPC. Tuttavia, il cluster database non è disponibile per la rete Internet pubblica, fornendo una maggiore sicurezza.
Questo tutorial configura una sottorete pubblica e privata aggiuntiva in una zona di disponibilità separata. Queste sottoreti non vengono utilizzate dal tutorial. Un gruppo di sottoreti DB RDS richiede una sottorete in almeno due zone di disponibilità. La sottorete aggiuntiva semplifica la configurazione di più istanze database Aurora.
Per creare un cluster database che utilizza la modalità dual-stack, specifica **Dual-stack mode** (Modalità dual-stack) per l'opzione **Network type** (Tipo di rete). Puoi, inoltre, modificare un cluster database usando la stessa impostazione. Ulteriori informazioni sulla creazione di un cluster di database sono disponibili in [Creazione di un cluster database Amazon Aurora](Aurora.CreateInstance.md). Per ulteriori informazioni sulla modifica di un cluster di database, consultare [Modifica di un cluster database Amazon Aurora](Aurora.Modifying.md).
In questa esercitazione viene descritta la configurazione di un VPC per cluster di database Amazon Aurora. Per ulteriori informazioni su Amazon VPC, consulta la [Guida per l'utente di Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/).
## Creazione di un VPC con sottoreti pubbliche e private
Utilizza la procedura seguente per creare un VPC con sottoreti pubbliche e private.
**Per creare un VPC e sottoreti**
1. Apri la console Amazon VPC all'indirizzo [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Nell'angolo in alto a destra di Console di gestione AWS, scegli la regione in cui creare il tuo VPC. Questo esempio utilizza la regione Stati Uniti orientali (Ohio).
1. Nell'angolo in alto a sinistra, scegli **VPC Dashboard** (Pannello di controllo VPC). Per iniziare a creare un VPC, scegli **Create VPC** (Crea VPC).
1. In **Resources to create** (Risorse da creare) nell'area **VPC settings** (Impostazioni VPC), scegli **VPC and more** (VPC e altro).
1. Nei campi **VPC settings** (Impostazioni VPC) restanti, imposta i seguenti valori:
+ **Name tag auto-generation** (Generazione automatica del tag del nome): **tutorial-dual-stack**
+ **IPv4 Blocco CIDR:** **10.0.0.0/16**
+ IPv6 Blocco **CIDR: blocco** CIDR fornito da **Amazon IPv6 **
+ **Tenancy** (Locazione): **Default**
+ **Numero di zone di disponibilità** **(): 2 AZs**
+ **Personalizza AZs**: mantiene i valori predefiniti.
+ **Number of public subnet** (Numero di sottoreti pubbliche): **2**
+ **Number of private subnets** (Numero di sottoreti private): **2**
+ **Customize subnets CIDR blocks** (Personalizza blocchi CIDR delle sottoreti): mantieni i valori predefiniti.
+ **NAT gateways (\$1)** (Gateway NAT): **nessuna**
+ **Egress only internet gateway** (Gateway Internet solo in uscita): **No**
+ **VPC endpoints** (Endpoint VPC): **nessuno**
+ **DNS options** (Opzioni DNS): mantieni i valori predefiniti.
**Nota**
Amazon RDS richiede almeno due sottoreti in due zone di disponibilità diverse per supportare le implementazioni Multi-AZ di un'istanza DB. In questo tutorial viene creata crea un'implementazione Single-AZ, ma il requisito semplifica la conversione in un'implementazione Multi-AZ di un'istanza DB in futuro.
1. Seleziona **Crea VPC**.
## Per creare un gruppo di sicurezza VPC per un'istanza Amazon EC2 pubblica
È possibile a questo punto aggiungere un gruppo di sicurezza per l'accesso pubblico. Per connettersi alle istanze EC2 nel VPC, aggiungi regole in entrata al gruppo di sicurezza VPC per consentire il traffico da Internet.
**Per creare un gruppo di sicurezza VPC**
1. Apri la console Amazon VPC all'indirizzo [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Scegliere **VPC Dashboard (Pannello di controllo VPC)**, **Security Groups (Gruppi di sicurezza)** e quindi **Create security group (Crea gruppo di sicurezza)**.
1. Nella pagina **Create security group (Crea gruppo di sicurezza)** impostare questi valori:
+ **Security group name: (Nome del gruppo di sicurezza:** **tutorial-dual-stack-securitygroup**
+ **Descrizione:** **Tutorial Dual-Stack Security Group**
+ **VPC:** **scegli il VPC che hai creato in precedenza, ad esempio: vpc- () *identifier* tutorial-dual-stack-vpc**
1. Aggiungere regole in entrata al gruppo di sicurezza
1. Determina l'indirizzo IP da utilizzare per connettersi alle istanze EC2 nel VPC utilizzando Secure Shell (SSH).
Un esempio di indirizzo Internet Protocol versione 4 (IPv4) è. `203.0.113.25/32` Un esempio di intervallo di indirizzi Internet Protocol versione 6 (IPv6) è`2001:db8:1234:1a00::/64`.
In molti casi, è possibile eseguire la connessione tramite un fornitore di servizi Internet (ISP) o con la protezione di un firewall senza un indirizzo IP statico. In tal caso, trova l'intervallo di indirizzi IP utilizzati dai computer client.
**avvertimento**
Se utilizzi `0.0.0.0/0` for IPv4 o `::0` for IPv6, consenti a tutti gli indirizzi IP di accedere alle tue istanze pubbliche tramite SSH. Questo approccio è accettabile per un breve periodo di tempo in un ambiente di test, ma non è sicuro per gli ambienti di produzione. In produzione, è preferibile autorizzare l'accesso alle istanze solo a indirizzo IP o a un intervallo di indirizzi specifico.
1. Nella sezione **Regole in entrata**, scegliere **Aggiungi regola**.
1. Imposta i seguenti valori per la nuova regola in entrata per consentire l'accesso Secure Shell (SSH) all'istanza Amazon EC2. In questo caso, è possibile connettersi all'istanza EC2 per installare client SQL e altre applicazioni. Specifica un indirizzo IP per poter accedere all'istanza EC2:
+ **Tipo:** **SSH**
+ **Origine:** indirizzo IP o intervallo ottenuto nel passaggio a. Un esempio di indirizzo IPv4 IP è. **203.0.113.25/32** Un esempio di indirizzo IPv6 IP è**2001:DB8::/32**.
1. Per creare il gruppo di sicurezza, scegli **Create security group** (Crea gruppo di sicurezza).
Prendi nota dell'ID del gruppo di sicurezza perché sarà necessario in seguito in questo tutorial.
## Creazione di un gruppo di sicurezza VPC per un cluster database privato
Per mantenere il cluster database privato, crea un secondo gruppo di sicurezza per l'accesso privato. Per connetterti ai cluster database privati nel VPC, aggiungi le regole in entrata al gruppo di sicurezza VPC. Queste consentono il traffico solo dall'istanza Amazon EC2.
**Per creare un gruppo di sicurezza VPC**
1. Apri la console Amazon VPC all'indirizzo [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Scegliere **VPC Dashboard (Pannello di controllo VPC)**, **Security Groups (Gruppi di sicurezza)** e quindi **Create security group (Crea gruppo di sicurezza)**.
1. Nella pagina **Create security group (Crea gruppo di sicurezza)** impostare questi valori:
+ **Security group name: (Nome del gruppo di sicurezza:** **tutorial-dual-stack-db-securitygroup**
+ **Descrizione:** **Tutorial Dual-Stack DB Instance Security Group**
+ **VPC:** **scegli il VPC che hai creato in precedenza, ad esempio: vpc- () *identifier* tutorial-dual-stack-vpc**
1. Aggiungere regole in entrata al gruppo di sicurezza
1. Nella sezione **Regole in entrata**, scegliere **Aggiungi regola**.
1. Imposta i valori seguenti per la nuova regola in entrata per consentire il traffico MySQL sulla porta 3306 dall'istanza Amazon EC2. In tal modo, puoi eseguire la connessione dall'istanza EC2 al cluster database ed Questa operazione consente di inviare dati dall'istanza EC2 al database.
+ **Tipo:** **MySQL/Aurora**
+ **Source** (Origine): l'identificatore del gruppo di sicurezza **tutorial-dual-stack-securitygroup** creato in precedenza durante il tutorial, ad esempio **sg-9edd5cfb**.
1. Per creare il gruppo di sicurezza, scegliere **Crea gruppo di sicurezza**.
## Per creare un gruppo di sottoreti del database
Un *gruppo di sottoreti DB* è una raccolta di sottoreti creata in un VPC e che è possibile indicare per i cluster database. L'utilizzo di un gruppo di sottoreti DB consente di specificare un determinato VPC durante la creazione di cluster database. Per creare un gruppo di sottoreti database compatibile con `DUAL`, tutte le sottoreti devono essere compatibili con `DUAL`. Per essere `DUAL` compatibile, una sottorete deve avere un IPv6 CIDR associato.
**Come creare un gruppo di sottoreti database**
1. Identifica le sottoreti private per il database nel VPC.
1. Apri la console Amazon VPC all'indirizzo [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Scegli **VPC Dashboard** (Pannello di controllo VPC), quindi seleziona **Subnets** (Sottoreti).
1. ****Nota la sottorete delle sottoreti denominate IDs -private1-us-west-2a e -private2-us-west-2b. tutorial-dual-stack-subnet tutorial-dual-stack-subnet****
Avrai bisogno della IDs sottorete quando creerai il tuo gruppo di sottoreti DB.
1. Aprire la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
Assicurarsi di connettersi alla console Amazon RDS e non alla console Amazon VPC.
1. Nel pannello di navigazione selezionare **Subnet groups (Gruppi di sottoreti)**.
1. Scegli **Create DB Subnet Group** (Crea gruppo di sottoreti del database).
1. Nella pagina **Create DB subnet group (Crea gruppo di sottoreti del database)** impostare questi valori in **Subnet group details (Dettagli gruppi di sottoreti)**:
+ **Nome:** **tutorial-dual-stack-db-subnet-group**
+ **Descrizione:** **Tutorial Dual-Stack DB Subnet Group**
+ **VPC: tutorial-dual-stack-vpc ** **(vpc** -) *identifier*
1. Nella sezione **Add subnets** (Aggiungi sottoreti), scegli i valori desiderati per le opzioni **Availability Zones** (Zone di disponibilità) e **Subnets** (Sottoreti).
Per questo tutorial, scegli **us-east-2b** e **us-east-2c** per l'opzione **Availability Zones** (Zone di disponibilità). In **Subnets** (Sottoreti), scegli le sottoreti private identificate nella fase precedente.
1. Scegli **Create** (Crea).
Il nuovo gruppo di sottoreti database viene visualizzato nell'elenco dei gruppi di sottoreti database sulla console RDS. È possibile scegliere il gruppo di sottoreti database per visualizzarne i dettagli. I dettagli includono i protocolli di indirizzamento supportati e tutte le sottoreti associate al gruppo e il tipo di rete supportato dal gruppo di sottoreti database.
## Creare un'istanza Amazon EC2 in modalità dual-stack
Per creare un’istanza Amazon EC2, segui le istruzioni riportate in [Launch an instance using the new launch instance wizard](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-instance-wizard.html) nella *Guida per l’utente di Amazon EC2*.
Nella pagina **Configure Instance Details** (Configura i dettagli dell'istanza), imposta questi valori e lascia gli altri valori come predefiniti:
+ **Rete**: scegli un VPC esistente con sottoreti pubbliche e private, ad esempio **tutorial-dual-stack-vpc**(vpc-) creato in. *identifier* [Creazione di un VPC con sottoreti pubbliche e private](#CHAP_Tutorials.CreateVPCDualStack.VPCAndSubnets)
+ **Subnet**: scegli una sottorete pubblica esistente, ad esempio **subnet- *identifier*** \$1 -public1-us-east-2a \$1 us-east-2a creata in. tutorial-dual-stack-subnet [Per creare un gruppo di sicurezza VPC per un'istanza Amazon EC2 pubblica](#CHAP_Tutorials.CreateVPCDualStack.SecurityGroupEC2)
+ **Auto-assign Public IP** (Assegna automaticamente IP pubblico): scegli **Enable** (Abilita).
+ ** IPv6 **Assegna**** automaticamente IP: scegli Abilita.
+ **Firewall (security groups)** (Firewall (gruppi di sicurezza)): scegli **Select an existing security group** (Seleziona un gruppo di sicurezza esistente).
+ **Gruppi di sicurezza comuni**: scegli un gruppo di sicurezza esistente, ad esempio il `tutorial-securitygroup` creato in [Per creare un gruppo di sicurezza VPC per un'istanza Amazon EC2 pubblica](#CHAP_Tutorials.CreateVPCDualStack.SecurityGroupEC2). Assicurarsi che il gruppo di sicurezza scelto includa regole in ingresso per Secure Shell (SSH) e l'accesso HTTP.
## Creazione di un cluster database in modalità dual-stack
In questo passaggio, viene creata un cluster database che viene eseguito in modalità dual-stack.
**Come creare un’istanza 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. Questo esempio utilizza la regione Stati Uniti orientali (Ohio).
1. Nel riquadro di navigazione, scegliere **Databases** (Database).
1. Scegliere **Create database** (Crea database).
1. Nella pagina **Create database** (Crea database), assicurati che l'opzione **Standard create** (Creazione standard) sia selezionata, quindi scegli il tipo di motore DB Aurora MySQL.
1. Nella sezione **Connettività**, imposta i seguenti valori:
+ **Network type** (Tipo di rete): scegli **Dual-stack mode** (Modalità dual-stack).
![\[Sezione Tipo di rete nella console con l'opzione Dual-stack mode (Modalità dual-stack) selezionata\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/dual-stack-mode.png)
+ **Cloud privato virtuale (VPC)**: scegli un VPC esistente con sottoreti pubbliche e private, ad esempio **tutorial-dual-stack-vpc**(vpc-) create in. *identifier* [Creazione di un VPC con sottoreti pubbliche e private](#CHAP_Tutorials.CreateVPCDualStack.VPCAndSubnets)
Il VPC deve avere sottoreti in diverse zone di disponibilità.
+ **Gruppo di **sottoreti DB: scegli un gruppo** di sottoreti DB per il VPC, ad esempio -subnet-group creato in. tutorial-dual-stack-db** [Per creare un gruppo di sottoreti del database](#CHAP_Tutorials.CreateVPCDualStack.DBSubnetGroup)
+ **Public access** (Accesso pubblico): scegli **No**.
+ **VPC security group (firewall)** (Gruppo di sicurezza VPC (firewall)): seleziona **Choose existing** (Sceglie esistente).
+ **Gruppi di sicurezza VPC esistenti****: scegli un gruppo di sicurezza VPC esistente configurato per l'accesso privato, ad esempio -securitygroup created in. tutorial-dual-stack-db** [Creazione di un gruppo di sicurezza VPC per un cluster database privato](#CHAP_Tutorials.CreateVPCDualStack.SecurityGroupDB)
Rimuovere gli altri gruppi di sicurezza, come quello predefinito, selezionando la **X** associata a esso.
+ **Availability Zone** (Zona di disponibilità): scegli **us-west-2a**.
Per evitare il traffico tra AZ, assicurati che l'istanza database e l'istanza EC2 si trovino nella stessa zona di disponibilità.
1. Per le restanti sezioni, specifica le impostazioni del cluster di database. Per informazioni su ciascuna impostazione, consulta [Impostazioni per cluster di database Aurora](Aurora.CreateInstance.md#Aurora.CreateInstance.Settings).
## Connessione all'istanza Amazon EC2 e al cluster database
Dopo aver creato l'istanza Amazon EC2 e il cluster database in modalità dual-stack, puoi eseguire la connessione utilizzando il protocollo IPv6. Per connetterti a un'istanza Amazon EC2 utilizzando il IPv6 protocollo, segui le istruzioni in [Connetti alla tua istanza Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html) nella *Amazon EC2* User Guide.
Per connetterti al cluster database Aurora MySQL dall'istanza Amazon EC2, segui le istruzioni in [Connessione a un cluster di database Aurora MySQL](CHAP_GettingStartedAurora.CreatingConnecting.Aurora.md#CHAP_GettingStartedAurora.Aurora.Connect).
## Eliminazione del VPC
Dopo aver creato il VPC e altre risorse per questo tutorial, è possibile eliminarle se non sono più necessarie.
Se hai aggiunto risorse nel VPC creato per questo tutorial, potrebbe essere necessario eliminarle prima di poter eliminare il VPC. Esempi di risorse sono le istanze Amazon EC2 o i cluster database. Per ulteriori informazioni, consulta [Eliminazione del VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#VPC_Deleting) nella *Guida per l'utente di Amazon VPC*.
**Per eliminare un VPC e le risorse correlate**
1. Eliminare il gruppo di sottoreti database:
1. Aprire la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Nel pannello di navigazione selezionare **Subnet groups (Gruppi di sottoreti)**.
1. Seleziona il gruppo di sottoreti DB da eliminare, ad esempio. **tutorial-db-subnet-group**
1. Scegliere **Delete (Elimina)** e quindi scegliere **Delete (Elimina)** nella finestra di conferma.
1. Annotare l'ID VPC:
1. Apri la console Amazon VPC all'indirizzo [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Scegli **VPC Dashboard**, quindi scegli. **VPCs**
1. Nell'elenco, identifica il VPC che hai creato, ad esempio. **tutorial-dual-stack-vpc**
1. Annotare il valore **ID VPC** del VPC creato. Sarà necessario usare questo ID VPC nei passaggi successivi.
1. Eliminare i gruppi di sicurezza:
1. Apri la console Amazon VPC all'indirizzo [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Scegliere **VPC Dashboard (Pannello di controllo VPC)** e quindi scegliere **Security Groups (Gruppi di sicurezza)**.
1. Seleziona il gruppo di sicurezza per l'istanza database di Amazon RDS, ad esempio **tutorial-dual-stack-db-securitygroup**.
1. In **Actions** (Operazioni), scegli **Delete security groups** (Elimina gruppi di sicurezza) e quindi scegli **Delete** (Elimina) nella pagina di conferma.
1. Nella pagina **Gruppi di sicurezza**, seleziona il gruppo di sicurezza per l'istanza Amazon EC2, ad esempio. **tutorial-dual-stack-securitygroup**
1. In **Actions** (Operazioni), scegli **Delete security groups** (Elimina gruppi di sicurezza) e quindi scegli **Delete** (Elimina) nella pagina di conferma.
1. Elliminare il gateway NAT:
1. Apri la console Amazon VPC all'indirizzo [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Scegliere **VPC Dashboard (Pannello di controllo VPC)** e quindi scegliere **NAT Gateways (Gateway NAT)**.
1. Seleziona il gateway NAT del VPC creato. Utilizzare l'ID VPC per identificare il gateway NAT corretto.
1. In **Actions** (Operazioni), scegli **Delete NAT gateway** (Elimina gateway NAT).
1. Nella pagina di conferma, immetti **delete** e scegliere **Delete (Elimina)**.
1. Eliminare il VPC
1. Apri la console Amazon VPC all'indirizzo [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Scegli **VPC Dashboard**, quindi scegli. **VPCs**
1. Seleziona il VPC che desideri eliminare, ad esempio. **tutorial-dual-stack-vpc**
1. In **Operazioni**, scegli **Elimina VPC**.
Nella pagina di conferma vengono visualizzate altre risorse associate al VPC che verranno eliminate, incluse le subnet associate.
1. Nella pagina di conferma, immetti **delete** e scegliere **Delete (Elimina)**.
1. Rilasciare gli indirizzi IP elastici:
1. Apri la console Amazon EC2 all'indirizzo [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. **Scegli **EC2 Dashboard**, quindi scegli Elastic. IPs**
1. Seleziona l'indirizzo IP elastico da rilasciare.
1. In **Actions** (Operazioni), scegli **Release Elastic IP addresses** (Rilascia indirizzi IP elastici).
1. Nella pagina di conferma scegli **Release (Rilasciare)**.