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 con Amazon Aurora MySQL La sicurezza di Amazon Aurora MySQL viene gestita su tre livelli: + Per controllare chi può eseguire azioni di gestione di Amazon RDS su cluster e istanze DB MySQL Aurora, usi (IAM). AWS Identity and Access Management Quando ti connetti AWS utilizzando le credenziali IAM, il tuo AWS account deve disporre di policy IAM che concedano le autorizzazioni necessarie per eseguire le operazioni di gestione di Amazon RDS. Per ulteriori informazioni, consulta [Gestione accessi e identità per Amazon Aurora](UsingWithRDS.IAM.md) Se utilizzi IAM per accedere alla console Amazon RDS, assicurati di accedere prima Console di gestione AWS con le tue credenziali utente IAM. Quindi vai alla console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). + I cluster di database Aurora MySQL devono essere creati in un cloud privato virtuale (VPC) utilizzando il servizio Amazon VPC. Per controllare i dispositivi e le istanze Amazon EC2 che possono aprire le connessioni all'endpoint e alla porta dell'istanza database per i cluster di database Aurora MySQL in un VPC, puoi utilizzare un gruppo di sicurezza VPC. È possibile creare queste connessioni di endpoint e porta mediante Transport Layer Security (TLS). Le regole del firewall aziendale possono inoltre determinare se i dispositivi in esecuzione nell'azienda possono aprire connessioni a un'istanza database. Per ulteriori informazioni su VPCs, consulta[VPC Amazon e Amazon Aurora](USER_VPC.md). La tenancy VPC supportata dipende dalla classe di istanze database usata dai cluster DB di Aurora MySQL. Con la tenancy VPC `default`, VPC viene eseguito nell'hardware condiviso. Con la tenancy VPC `dedicated`, il VPC viene eseguito in un'istanza hardware dedicata. Le classi di istanze database espandibili supportano solo la locazione VPC di default. Le classi di istanza database con prestazioni espandibili includono le classi di istanza db.t2, db.t3 e db.t4g DB. Tutte le altre classi di istanza database di Aurora MySQL DB supportano sia il tenancy VPC di default che dedicato. **Nota** Consigliamo di utilizzare le classi di istanza database T solo per i server di sviluppo e test o altri server non di produzione. Per ulteriori informazioni sulle classi di istanza T, consulta [Utilizzo delle classi di istanza T per lo sviluppo e i test](AuroraMySQL.BestPractices.Performance.md#AuroraMySQL.BestPractices.T2Medium). Per ulteriori informazioni sulle classi di istanza, consulta [Classi di istanze DB Amazon Aurora](Concepts.DBInstanceClass.md). Per ulteriori informazioni sulle tenancy VPC `default` e `dedicated`, consulta [Istanze dedicate](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/dedicated-instance.html) nella *Guida per l'utente di Amazon Elastic Compute Cloud*. + Per autenticare l'accesso e le autorizzazioni per un cluster DB Amazon Aurora MySQL puoi seguire uno degli approcci qui riportati oppure utilizzare una loro combinazione: + Puoi adottare lo stesso approccio utilizzato per un'istanza standalone di MySQL. I comandi come `CREATE USER`, `RENAME USER`, `GRANT`, `REVOKE` e `SET PASSWORD` funzionano esattamente come nei database in locale, modificando direttamente le tabelle dello schema del database. Per ulteriori informazioni, consulta [ Access Control and Account Management](https://dev.mysql.com/doc/refman/8.0/en/access-control.html) nella documentazione MySQL. + Puoi anche utilizzare l'autenticazione database IAM. Questo metodo prevede l'autenticazione del database IAM nel cluster DB tramite un utente IAM oppure con un ruolo IAM e un token di autenticazione. Il *token di autenticazione* è un valore univoco, generato tramite il processo di firma Signature Version 4. Utilizzando l'autenticazione del database IAM, puoi utilizzare le stesse credenziali per controllare l'accesso alle tue AWS risorse e ai tuoi database. Per ulteriori informazioni, consulta [Autenticazione del database IAM ](UsingWithRDS.IAMDBAuth.md). **Nota** Per ulteriori informazioni, consulta [Sicurezza in ](UsingWithRDS.md). Nelle sezioni seguenti, consulta le informazioni sulle autorizzazioni utente per le connessioni Aurora MySQL e TLS con i cluster di database Aurora MySQL. **Topics** + [Privilegi dell'utente master con Amazon Aurora MySQL.](#AuroraMySQL.Security.MasterUser) + [Connessioni TLS a cluster di database Aurora MySQL](#AuroraMySQL.Security.SSL) ## Privilegi dell'utente master con Amazon Aurora MySQL. Quando crei un'istanza database Amazon Aurora MySQL, l'utente master ha i seguenti privilegi predefiniti indicati in [Privilegi dell'account utente master](UsingWithRDS.MasterAccounts.md). Per fornire i servizi di gestione per ogni cluster di database, vengono creati gli utenti `admin` e `rdsadmin` al momento della creazione del cluster di database. I tentativi di rimuovere, rinominare, cambiare la password o modificare i privilegi dell'account `rdsadmin` produrranno errori. Nei cluster di database Aurora MySQL versione 2, gli utenti `admin` e `rdsadmin` vengono creati al momento della creazione del cluster di database. Nei cluster di database Aurora MySQL versione 3, vengono creati gli utenti `admin`, `rdsadmin` e `rds_superuser_role`. **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. Per la gestione del cluster di database di Aurora MySQL, i comandi standard `kill` e `kill_query` sono stati limitati. Al loro posto, utilizza i comandi di Amazon RDS `rds_kill` e `rds_kill_query` per terminare le sessioni utente e le query nelle istanze database di Aurora MySQL. **Nota** La crittografia di un'istanza database e delle snapshot non è supportata per la regione Cina (Ningxia). ## Connessioni TLS a cluster di database Aurora MySQL I cluster database Amazon Aurora MySQL supportano le connessioni Transport Layer Security (TLS) da applicazioni che utilizzano lo stesso processo e la stessa chiave pubblica delle istanze database RDS per MySQL. Amazon RDS crea un certificato TLS e installa il certificato nell'istanza database quando Amazon RDS effettua il provisioning dell'istanza. Questi certificati sono firmati da un'autorità di certificazione. Il certificato TLS include l'endpoint dell'istanza database come il nome comune (CN) per il certificato TLS per la protezione contro attacchi di spoofing. Di conseguenza, è possibile utilizzare l'endpoint del cluster DB per la connessione a un cluster DB tramite TLS solo se il client supporta i nomi alternativi dell'oggetto (Subject Alternative Names, SAN). In caso contrario, dovrai usare l'endpoint dell'istanza di un'istanza di scrittura. Per ulteriori informazioni sul download dei certificati, consultare [Utilizzo SSL/TLS per crittografare una connessione a un'](UsingWithRDS.SSL.md). Consigliamo il driver AWS JDBC come client che supporta SAN con TLS. Per ulteriori informazioni sul driver AWS JDBC e istruzioni complete per il suo utilizzo, consulta l'archivio dei driver [JDBC di Amazon Web Services (AWS)](https://github.com/aws/aws-advanced-jdbc-wrapper). GitHub **Topics** + [Richiesta di una connessione TLS a un cluster DB Aurora MySQL](#AuroraMySQL.Security.SSL.RequireSSL) + [Versioni TLS per Aurora MySQL](#AuroraMySQL.Security.SSL.TLS_Version) + [Configurazione di suite di cifratura per connessioni ai cluster di database Aurora MySQL](#AuroraMySQL.Security.SSL.ConfiguringCipherSuites) + [Crittografia delle connessioni a un cluster DB Aurora MySQL](#AuroraMySQL.Security.SSL.EncryptingConnections) ### Richiesta di una connessione TLS a un cluster DB Aurora MySQL È possibile richiedere che tutte le connessioni utente al cluster database Aurora MySQL utilizzino TLS utilizzando il parametro cluster database `require_secure_transport`. Per impostazione predefinita, il parametro `require_secure_transport` è impostato su `OFF`. È possibile impostare il parametro `require_secure_transport` su `ON` per richiedere la crittografia TLS per le connessioni al cluster database. Puoi impostare il valore del parametro `require_secure_transport` aggiornando il gruppo di parametri per il tuo cluster DB. Non è necessario riavviare il cluster DB affinché la modifica abbia effetto. Per ulteriori informazioni sui gruppi di parametri, consulta [Gruppi di parametri per Amazon Aurora](USER_WorkingWithParamGroups.md). **Nota** Il parametro `require_secure_transport` è disponibile per Aurora MySQL versione 2 e 3. È possibile impostare questo parametro in un gruppo di parametri del cluster database personalizzato. Il parametro non è disponibile nei gruppi di parametri di istanza database. Quando il parametro `require_secure_transport` è impostato su `ON` per un cluster DB, un client di database può connettersi ad esso se è in grado di stabilire una connessione crittografata. In caso contrario, viene restituito al client un messaggio di errore simile al seguente: ``` MySQL Error 3159 (HY000): Connections using insecure transport are prohibited while --require_secure_transport=ON. ``` ### Versioni TLS per Aurora MySQL Aurora MySQL supporta Transport Layer Security (TLS) versione 1.0, 1.1, 1.2 e 1.3. A partire da Aurora MySQL versione 3.04.0 e successive, è possibile utilizzare il protocollo TLS 1.3 per proteggere le connessioni. La tabella seguente mostra il supporto TLS per le versioni di Aurora MySQL. **** | Versione Aurora MySQL | TLS 1.0 | TLS 1.1 | TLS 1.2 | TLS 1.3 | Predefinita | | --- | --- | --- | --- | --- | --- | | Aurora MySQL versione 2 | Deprecated | Deprecated | Supportata | Non supportata | Tutte le versioni TLS supportate | | Aurora MySQL versione 3 (versioni precedenti a 3.04.0) | Deprecated | Deprecated | Supportata | Non supportata | Tutte le versioni TLS supportate | | Aurora MySQL versione 3 (3.04.0 e versioni successive) | Non supportata | Non supportato | Supportato | Supportata | Tutte le versioni TLS supportate | **Importante** Se si utilizzano gruppi di parametri personalizzati per i cluster Aurora MySQL con versione 2 e versioni precedenti alla 3.04.0, si consiglia di utilizzare TLS 1.2 perché TLS 1.0 e 1.1 sono meno sicuri. L'edizione community di MySQL 8.0.26 e Aurora MySQL 3.03 e le relative versioni minori hanno reso obsoleto il supporto per le versioni TLS 1.1 e 1.0. L'edizione community di MySQL 8.0.28 e le versioni compatibili di Aurora MySQL 3.04.0 e successive non supportano TLS 1.1 e TLS 1.0. Se si utilizza Aurora MySQL versione 3.04.0 o successive, non impostare il protocollo TLS su 1.0 e 1.1 nel gruppo di parametri personalizzati. Per Aurora MySQL versione 3.04.0 e successive, l'impostazione predefinita è TLS 1.3 e TLS 1.2. È possibile utilizzare il parametro del cluster database `tls_version` per indicare le versioni del protocollo consentite. Parametri client simili esistono per la maggior parte degli strumenti client o dei driver di database. Alcuni client meno recenti potrebbero non supportare versioni TLS più recenti. Per impostazione predefinita, il cluster DB tenta di utilizzare la versione del protocollo TLS più alta consentita dalla configurazione del server e del client. Impostare il parametro del cluster `tls_version` DB su uno dei seguenti valori: + `TLSv1.3` + `TLSv1.2` + `TLSv1.1` + `TLSv1` È anche possibile impostare il parametro `tls_version` come un stringa di elenco separato da virgole. Se desideri utilizzare entrambi i protocolli TLS 1.2 e TLS 1.3, il `tls_version` parametro deve includere tutti i protocolli dal protocollo più basso a quello più alto. In questo caso, `tls_version` è impostato come: ``` tls_version=TLSv1.2,TLSv1.3 ``` Per informazioni sulla modifica di parametri in un gruppo di parametri del cluster database, consulta [Modifica dei parametri in un gruppo di parametri del cluster DB in Amazon Aurora](USER_WorkingWithParamGroups.ModifyingCluster.md). Se si utilizza il AWS CLI per modificare il parametro del cluster `tls_version` DB, `ApplyMethod` deve essere impostato su. `pending-reboot` Quando il metodo di applicazione è `pending-reboot`, le modifiche ai parametri vengono applicate dopo l'arresto e il riavvio dei cluster database associati al gruppo di parametri. ### Configurazione di suite di cifratura per connessioni ai cluster di database Aurora MySQL Utilizzando suite di cifratura configurabili, è possibile avere maggiore controllo sulla sicurezza delle connessioni al database. È possibile specificare un elenco di suite di crittografia che si desidera abilitare per proteggere le connessioni TLS client al database. Con le suite di cifratura, è possibile controllare la crittografia di connessione accettata dal server di database. In tal modo si previene l'uso di crittografie obsolete o non sicure. Le suite di cifratura configurabili sono supportate in Aurora MySQL versione 3 e Aurora MySQL versione 2. Per specificare l'elenco di cifrature TLS 1.2, TLS 1.1, TLS 1.0 consentite per la crittografia delle connessioni, modifica il parametro del cluster `ssl_cipher`. Imposta il parametro `ssl_cipher` in un gruppo di parametri cluster utilizzando la Console di gestione AWS, la AWS CLI o l'API RDS. Imposta il parametro `ssl_cipher` su una stringa di valori di cifratura separati da virgole per la versione TLS. Per l'applicazione client, puoi specificare le cifrature da utilizzare per le connessioni crittografate utilizzando l'opzione `--ssl-cipher` durante la connessione al database. Per ulteriori informazioni sulla connessione al database, consulta [Connessione a un cluster di database Amazon Aurora MySQL](Aurora.Connecting.md#Aurora.Connecting.AuroraMySQL). A partire da Aurora MySQL versione 3.04.0 e successive, è possibile specificare le suite di crittografia TLS 1.3. Per specificare le suite di crittografia TLS 1.3 consentite, modifica il parametro `tls_ciphersuites` nel gruppo di parametri. TLS 1.3 ha ridotto il numero di suite di crittografia disponibili a causa delle modifiche alla convenzione di denominazione che rimuove il meccanismo di scambio delle chiavi e il certificato utilizzati. Imposta il parametro `tls_ciphersuites` su una stringa di valori di cifratura separati da virgole per TLS 1.3. La tabella seguente mostra le cifrature supportate insieme al protocollo di crittografia TLS e alle versioni valide del motore Aurora MySQL per ogni cifratura. | Crittografia | Protocollo di crittografia | Versioni di Aurora MySQL supportate | | --- | --- | --- | | `ECDHE-RSA-AES128-SHA` | TLS 1.0 | 3.04.0 e versioni successive, 2.11.0 e versioni successive | | `ECDHE-RSA-AES128-SHA256` | TLS 1.2 | 3.04.0 e versioni successive, 2.11.0 e versioni successive | | `ECDHE-RSA-AES128-GCM-SHA256` | TLS 1.2 | 3.04.0 e versioni successive, 2.11.0 e versioni successive | | `ECDHE-RSA-AES256-SHA` | TLS 1.0 | 3.04.0 e versioni successive, 2.11.0 e versioni successive | | `ECDHE-RSA-AES256-GCM-SHA384` | TLS 1.2 | 3.04.0 e versioni successive, 2.11.0 e versioni successive | | `ECDHE-RSA-CHACHA20-POLY1305` | TLS 1.2 | 3.04.0 e versioni successive, 2.11.0 e versioni successive | | `ECDHE-ECDSA-AES128-SHA` | TLS 1.0 | 3.04.0 e versioni successive, 2.11.0 e versioni successive | | `ECDHE-ECDSA-AES256-SHA` | TLS 1.0 | 3.04.0 e versioni successive, 2.11.0 e versioni successive | | `ECDHE-ECDSA-AES128-GCM-SHA256` | TLS 1.2 | 3.04.0 e versioni successive, 2.11.0 e versioni successive | | `ECDHE-ECDSA-AES256-GCM-SHA384` | TLS 1.2 | 3.04.0 e versioni successive, 2.11.0 e versioni successive | | `ECDHE-ECDSA-CHACHA20-POLY1305` | TLS 1.2 | 3.04.0 e versioni successive, 2.11.0 e versioni successive | | `TLS_AES_128_GCM_SHA256` | TLS 1.3 | 3.04.0 e versioni successive | | `TLS_AES_256_GCM_SHA384` | TLS 1.3 | 3.04.0 e versioni successive | | `TLS_CHACHA20_POLY1305_SHA256` | TLS 1.3 | 3.04.0 e versioni successive | Per informazioni sulla modifica di parametri in un gruppo di parametri del cluster database, consulta [Modifica dei parametri in un gruppo di parametri del cluster DB in Amazon Aurora](USER_WorkingWithParamGroups.ModifyingCluster.md). Se usi l'interfaccia a riga di comando per modificare il parametro cluster di database `ssl_cipher`, assicurati di impostare `ApplyMethod` su `pending-reboot`. Quando il metodo di applicazione è `pending-reboot`, le modifiche ai parametri vengono applicate dopo l'arresto e il riavvio dei cluster database associati al gruppo di parametri. È inoltre possibile utilizzare il comando CLI [describe-engine-default-cluster-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-engine-default-cluster-parameters.html) per determinare quali suite di crittografia sono attualmente supportate per una famiglia di gruppi di parametri specifica. L'esempio seguente mostra come ottenere i valori consentiti per il parametro del cluster `ssl_cipher` per Aurora MySQL versione 2. ``` aws rds describe-engine-default-cluster-parameters --db-parameter-group-family aurora-mysql5.7 ...some output truncated... { "ParameterName": "ssl_cipher", "ParameterValue": "ECDHE-RSA-AES128-SHA,ECDHE-RSA-AES128-SHA256,ECDHE-RSA-AES128-GCM-SHA256,ECDHE-RSA-AES256-SHA,ECDHE-RSA-AES256-GCM-SHA384,ECDHE-RSA-CHACHA20-POLY1305,ECDHE-ECDSA-AES256-SHA,ECDHE-ECDSA-CHACHA20-POLY1305,ECDHE-ECDSA-AES256-GCM-SHA384,ECDHE-ECDSA-AES128-GCM-SHA256,ECDHE-ECDSA-AES128-SHA", "Description": "The list of permissible ciphers for connection encryption.", "Source": "system", "ApplyType": "static", "DataType": "list", "AllowedValues": "ECDHE-RSA-AES128-SHA,ECDHE-RSA-AES128-SHA256,ECDHE-RSA-AES128-GCM-SHA256,ECDHE-RSA-AES256-SHA,ECDHE-RSA-AES256-GCM-SHA384,ECDHE-RSA-CHACHA20-POLY1305,ECDHE-ECDSA-AES256-SHA,ECDHE-ECDSA-CHACHA20-POLY1305,ECDHE-ECDSA-AES256-GCM-SHA384,ECDHE-ECDSA-AES128-GCM-SHA256,ECDHE-ECDSA-AES128-SHA", "IsModifiable": true, "SupportedEngineModes": [ "provisioned" ] }, ...some output truncated... ``` Per ulteriori informazioni sulle cifrature, consulta la variabile [ssl\$1ciphers](https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_ssl_cipher) nella documentazione di MySQL. Per ulteriori informazioni sui formati di suite di cifratura, consulta la documentazione per il [formato elenco openssl-ciphers](https://www.openssl.org/docs/manmaster/man1/openssl-ciphers.html#CIPHER-LIST-FORMAT) e il [formato stringa openssl-ciphers](https://www.openssl.org/docs/manmaster/man1/openssl-ciphers.html#CIPHER-STRINGS) sul sito Web OpenSSL. ### Crittografia delle connessioni a un cluster DB Aurora MySQL Per crittografare le connessioni con il client `mysql` di default, avvia il client mysql utilizzando il parametro `--ssl-ca` per fare riferimento alla chiave pubblica, ad esempio: Per MySQL 5.7 e 8.0: ``` mysql -h myinstance.123456789012.rds-us-east-1.amazonaws.com --ssl-ca=full_path_to_CA_certificate --ssl-mode=VERIFY_IDENTITY ``` Per MySQL 5.6: ``` mysql -h myinstance.123456789012.rds-us-east-1.amazonaws.com --ssl-ca=full_path_to_CA_certificate --ssl-verify-server-cert ``` *full\$1path\$1to\$1CA\$1certificate*Sostituiscilo con il percorso completo del certificato di Certificate Authority (CA). Per ulteriori informazioni sul download di un certificato, consultare [Utilizzo SSL/TLS per crittografare una connessione a un'](UsingWithRDS.SSL.md). È possibile richiedere connessioni TLS per account utente specifici. Ad esempio, in base alla versione di MySQL, è possibile utilizzare una delle seguenti istruzioni per richiedere connessioni TLS per l'account utente `encrypted_user`. Per MySQL 5.7 e 8.0: ``` ALTER USER 'encrypted_user'@'%' REQUIRE SSL; ``` Per MySQL 5.6: ``` GRANT USAGE ON *.* TO 'encrypted_user'@'%' REQUIRE SSL; ``` Quando utilizzi un proxy RDS, esegui la connessione all'endpoint del proxy anziché al normale endpoint del cluster. È possibile rendere SSL/TLS obbligatorie o facoltative le connessioni al proxy, allo stesso modo delle connessioni dirette al cluster Aurora DB. Per informazioni sull'utilizzo del proxy RDS, consulta [Proxy Amazon RDS per Aurora](rds-proxy.md). **Nota** Per ulteriori informazioni sulle connessioni TLS con MySQL, consulta la [documentazione di MySQL](https://dev.mysql.com/doc/refman/5.7/en/using-encrypted-connections.html).