Sicurezza con Amazon Aurora PostgreSQL - Amazon Aurora

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 PostgreSQL

Per una panoramica generale della sicurezza in Aurora, consulta Sicurezza in Amazon Aurora. Puoi gestire la sicurezza per Amazon Aurora PostgreSQL a diversi livelli:

  • Per controllare chi è in grado di eseguire le operazioni di gestione di Amazon RDS nei cluster di database e nelle istanze database Aurora PostgreSQL, viene utilizzato AWS Identity and Access Management (IAM). IAM gestisce l'autenticazione dell'identità utente prima che questi possa accedere al servizio. Gestisce inoltre l'autorizzazione, ovvero se l'utente è autorizzato a fare ciò che sta cercando di fare. L'autenticazione del database IAM è un metodo di autenticazione aggiuntivo che è possibile scegliere quando si crea un cluster di database Aurora PostgreSQL. Per ulteriori informazioni, consulta Gestione accessi e identità per Amazon Aurora.

    Se utilizzi IAM con il cluster di database Aurora PostgreSQL, esegui l'accesso alla AWS Management Console con le tue credenziali IAM prima di aprire la console Amazon RDS all'indirizzo https://console.aws.amazon.com/rds/.

  • Assicurati che i cluster di database Aurora vengano 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 DB Aurora in un VPC, è necessario utilizzare un gruppo di sicurezza VPC. Le connessioni a endpoint e porte possono essere stabilite tramite Secure Sockets Layer (SSL). 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 sui VPC, consulta VPC di Amazon VPC e Amazon Aurora.

    La tenancy VPC supportata dipende dalla classe di istanze database usata dai cluster DB di Aurora PostgresSQL. Con la tenancy VPC default, il cluster di database viene eseguito nell'hardware condiviso. Con la tenancy VPC dedicated, il cluster di database viene eseguito in un'istanza hardware dedicata. Le classi di istanza database delle prestazioni in modalità burst supportano solo la tenancy VPC di default. Le classi di istanza database delle prestazioni in modalità burst includono le classi di istanza database db.t3 e db.t4g. Tutte le altre classi di istanza database di Aurora PostgreSQL DB supportano sia il tenancy VPC di default che dedicato.

    Per ulteriori informazioni sulle classi di istanza, consulta Aurora Classi di istanze database. Per ulteriori informazioni sulle tenancy VPC default e dedicated, consulta Istanze dedicate nella Guida per l'utente di Amazon Elastic Compute Cloud.

  • Per concedere autorizzazioni ai database PostgreSQL eseguiti sul cluster di database Amazon Aurora, puoi adottare lo stesso approccio generale utilizzato con le istanze standalone di PostgreSQL. I comandi come CREATE ROLE, ALTER ROLE, GRANT e REVOKE funzionano esattamente come nei database on-premise, ovvero in modo analogo alla modifica diretta delle tabelle dello schema del database.

    PostgreSQL gestisce i privilegi mediante i ruoli. Il ruolo rds_superuser è quello più privilegiato a livello di cluster di database Aurora PostgreSQL. Questo ruolo viene creato automaticamente e viene concesso all'utente che crea il cluster di database (l'account utente principale, postgres per impostazione predefinita). Per ulteriori informazioni, vedi Informazioni su ruoli e autorizzazioni di PostgreSQL.

Tutte le versioni disponibili di Aurora PostgreSQL, comprese le versioni 10, 11, 12, 13, 14, e successive, supportano il meccanismo SCRAM (Salted Challenge Response Authentication Mechanism) per le password come un'alternativa al digest del messaggio (MD5). Si consiglia di utilizzare SCRAM perché è più sicuro di MD5. Per ulteriori informazioni, inclusa la modalità di migrazione delle password utente del database da MD5 a SCRAM, consulta Utilizzo delle crittografia password SCRAM per PostgreSQL.

Sicurezza dei dati Aurora PostgreSQL con SSL/TLS

Amazon RDS supporta la crittografia SSecure Socket Layer (SSL) e Transport Layer Security (TLS) per i cluster DB Aurora PostgreSQL. Utilizzando SSL/TLS, puoi crittografare una connessione tra le tue applicazioni e i cluster DB Aurora PostgreSQL. Puoi inoltre imporre a tutte le connessioni per i cluster DB Aurora PostgreSQL di utilizzare SSL/TLS. Amazon Aurora PostgreSQL supporta Transport Layer Security (TLS) versioni 1.1 e 1.2. Si consiglia di utilizzare TLS 1.2 per connessioni crittografate. Abbiamo aggiunto il supporto per TLSv1.3 per le seguenti versioni di Aurora PostgreSQL:

  • 15.3 e tutte le versioni successive

  • 14.8 o versioni successive alla 14

  • 13.11 o versioni successive alla 13

  • 12.15 e versioni successive alla 12

  • 11.20 e versioni successive alla 11

Per informazioni generali sul supporto SSL/TLS e sui database PostgreSQL, consulta Supporto SSL nella documentazione di PostgreSQL. Per informazioni sull'utilizzo della connessione SSL/TLS in JDBC, consulta Configurazione del client nella documentazione di PostgreSQL.

Il supporto per SSL/TLS è disponibile in tutte le Regioni AWS per Aurora PostgreSQL. Amazon RDS crea un certificato SSL/TLS per il cluster DB Aurora PostgreSQL al momento della creazione del cluster. Se abiliti la verifica del certificato SSL/TLS, il certificato SSL/TLS include l'endpoint del cluster DB come nome comune (CN) per il certificato SSL/TLS per la protezione contro attacchi di spoofing.

Per effettuare la connessione a un cluster DB Aurora PostgreSQL tramite SSL/TLS
  1. Scaricare il certificato.

    Per ulteriori informazioni sul download dei certificati, consultare .

  2. Importare il certificato nel proprio sistema operativo.

  3. Effettua la connessione al tuo cluster DB Aurora PostgreSQL su SSL/TLS.

    Quando ti connetti tramite SSL/TLS, il tuo client può scegliere di verificare o meno la catena di certificati. Se i parametri di connessione specificano sslmode=verify-ca o sslmode=verify-full, il client richiede che i certificati CA RDS siano nell'archivio attendibilità o facciano riferimento all'URL della connessione. Questo requisito è verificare la catena di certificati che firma il certificato del database.

    Quando un client, come psql o JDBC, è configurato con il supporto SSL/TLS, per impostazione predefinita tenta innanzitutto di connettersi al database con SSL/TLS. Se il client non riesce a connettersi con SSL/TLS, torna a connettersi senza SSL/TLS. Per impostazione predefinita, l'opzione sslmode per i client JDBC e basati su libpq è impostata su prefer.

    Utilizzare il parametro sslrootcert come riferimento per il certificato, ad esempio sslrootcert=rds-ssl-ca-cert.pem.

Di seguito è riportato un esempio di utilizzo di psql per la connessione a un cluster DB Aurora PostgreSQL.

$ psql -h testpg.cdhmuqifdpib.us-east-1.rds.amazonaws.com -p 5432 \ "dbname=testpg user=testuser sslrootcert=rds-ca-2015-root.pem sslmode=verify-full"

Richiesta di una connessione SSL/TLS a un cluster DB Aurora PostgreSQL

Puoi richiedere che le connessioni al tuo cluster DB Aurora PostgreSQL utilizzino SSL/TLS usando il parametro rds.force_ssl. Per impostazione predefinita, il parametro rds.force_ssl è impostato su 0 (off). Puoi impostare il parametro rds.force_ssl su 1 (attivato) per richiedere la crittografia SSL/TLS per le connessioni al tuo cluster DB. L'aggiornamento del parametro rds.force_ssl imposta inoltre il parametro PostgreSQL ssl su 1 (attivato) e modifica il file pg_hba.conf del cluster DB per supportare la nuova configurazione SSL/TLS.

Puoi impostare il valore del parametro rds.force_ssl aggiornando il gruppo di parametri per il tuo cluster DB. Se il gruppo di parametri per il cluster DB non è quello predefinito e il parametro ssl è già impostato su 1 quando imposti rds.force_ssl su 1, non dovrai riavviare il cluster DB. In caso contrario, per applicare la modifica dovrai riavviare il cluster DB. Per ulteriori informazioni sui gruppi di parametri, consulta Utilizzo di gruppi di parametri.

Quando il parametro rds.force_ssl è impostato su 1 per un cluster DB, vedrai un risultato simile al seguente quando effettui la connessione, per indicare che la crittografia SSL/TLS non è necessaria:

$ psql postgres -h SOMEHOST.amazonaws.com -p 8192 -U someuser psql (9.3.12, server 9.4.4) WARNING: psql major version 9.3, server major version 9.4. Some psql features might not work. SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256) Type "help" for help. postgres=>

Determinazione dello stato di connessione SSL/TLS

Lo stato crittografato della tua connessione è indicato nel banner di accesso quando ti connetti al cluster DB:

Password for user master: psql (9.3.12) SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256) Type "help" for help.   postgres=>

Puoi anche caricare l'estensione sslinfo e quindi richiamare la funzione ssl_is_used() per determinare se viene utilizzata la crittografia SSL/TLS. La funzione restituisce t se la connessione utilizza la crittografia SSL/TLS, altrimenti restituisce f.

postgres=> create extension sslinfo; CREATE EXTENSION postgres=> select ssl_is_used(); ssl_is_used --------- t (1 row)

Puoi utilizzare il comando select ssl_cipher() per determinare la crittografia SSL/TLS:

postgres=> select ssl_cipher(); ssl_cipher -------------------- DHE-RSA-AES256-SHA (1 row)

Se abiliti set rds.force_ssl e riavvi il tuo cluster DB, le connessioni non SSL vengono rifiutate con il seguente messaggio:

$ export PGSSLMODE=disable $ psql postgres -h SOMEHOST.amazonaws.com -p 8192 -U someuser psql: FATAL: no pg_hba.conf entry for host "host.ip", user "someuser", database "postgres", SSL off $

Per informazioni sull'opzione sslmode, consulta l'argomento relativo alle funzioni di controllo della connessione del database nella documentazione di PostgreSQL.

Configurazione di suite di cifratura per connessioni ai cluster di database Aurora PostgreSQL

Utilizzando suite di cifratura configurabili, è possibile avere maggiore controllo sulla sicurezza delle connessioni al database. È possibile specificare un elenco di suite di cifratura che si desidera consentire per proteggere le connessioni SSL/TLS client al database. Con le suite di cifratura, è possibile controllare la crittografia di connessione accettata dal server di database. Ciò aiuta a prevenire l'uso di crittografie obsolete o non sicure.

Le suite di cifratura configurabili sono supportate nelle versioni 11.8 e successive di Aurora PostgreSQL.

Per specificare l'elenco di cifrature consentite per la crittografia delle connessioni, modifica il parametro del cluster ssl_ciphers. Imposta il parametro ssl_ciphers su una stringa di valori di cifratura separata da virgole in un gruppo di parametri del cluster utilizzando la AWS Management Console, la AWS CLI o l'API RDS. Per impostare i parametri del cluster, consulta Modifica di parametri in un gruppo di parametri cluster database.

La tabella seguente mostra le cifrature supportate per le versioni valide del motore Aurora PostgreSQL.

Versioni del motore Aurora PostgreSQL Cifrature supportate

9.6, 10.20 e versioni precedenti, 11.15 e versioni precedenti, 12.10 e versioni precedenti, 13.6 e versioni precedenti

  • DHE-RSA-AES128-SHA

  • DHE-RSA-AES128-SHA256

  • DHE-RSA-AES128-GCM-SHA256

  • DHE-RSA-AES256-SHA

  • DHE-RSA-AES256-SHA256

  • DHE-RSA-AES256-GCM-SHA384

  • ECDHE-ECDSA-AES256-SHA

  • ECDHE-ECDSA-AES256-GCM-SHA384

  • ECDHE-RSA-AES256-SHA384

  • ECDHE-RSA-AES128-SHA

  • ECDHE-RSA-AES128-SHA256

  • ECDHE-RSA-AES128-GCM-SHA256

  • ECDHE-RSA-AES256-SHA

  • ECDHE-RSA-AES256-GCM-SHA384

10.21, 11.16, 12.11, 13.7, 14.3 e 14.4

  • DHE-RSA-AES128-SHA

  • DHE-RSA-AES128-SHA256

  • DHE-RSA-AES128-GCM-SHA256

  • DHE-RSA-AES256-SHA

  • DHE-RSA-AES256-SHA256

  • DHE-RSA-AES256-GCM-SHA384

  • ECDHE-ECDSA-AES256-SHA

  • ECDHE-ECDSA-AES256-GCM-SHA384

  • ECDHE-RSA-AES256-SHA384

  • ECDHE-RSA-AES128-SHA

  • ECDHE-RSA-AES128-GCM-SHA256

  • ECDHE-RSA-AES256-SHA

  • ECDHE-RSA-AES256-GCM-SHA384

  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

  • TLS_RSA_WITH_AES_256_GCM_SHA384

  • TLS_RSA_WITH_AES_256_CBC_SHA

  • TLS_RSA_WITH_AES_128_GCM_SHA256

  • TLS_RSA_WITH_AES_128_CBC_SHA

  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

10.22 e versioni successive, 11.17 e versioni successive, 12.12 e versioni successive, 13.8 e versioni successive, 14.5 e versioni successive, 15.2 e versioni successive

  • DHE-RSA-AES128-SHA

  • DHE-RSA-AES128-SHA256

  • DHE-RSA-AES128-GCM-SHA256

  • DHE-RSA-AES256-SHA

  • DHE-RSA-AES256-SHA256

  • DHE-RSA-AES256-GCM-SHA384

  • ECDHE-ECDSA-AES256-SHA

  • ECDHE-ECDSA-AES256-GCM-SHA384

  • ECDHE-RSA-AES256-SHA384

  • ECDHE-RSA-AES128-SHA

  • ECDHE-RSA-AES128-SHA256

  • ECDHE-RSA-AES128-GCM-SHA256

  • ECDHE-RSA-AES256-SHA

  • ECDHE-RSA-AES256-GCM-SHA384

  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

  • TLS_RSA_WITH_AES_256_GCM_SHA384

  • TLS_RSA_WITH_AES_256_CBC_SHA

  • TLS_RSA_WITH_AES_128_GCM_SHA256

  • TLS_RSA_WITH_AES_128_CBC_SHA256

  • TLS_RSA_WITH_AES_128_CBC_SHA

  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

15.3, 14.8, 13.11, 12.15 e 11.20

  • DHE-RSA-AES128-SHA

  • DHE-RSA-AES128-SHA256

  • DHE-RSA-AES128-GCM-SHA256

  • DHE-RSA-AES256-SHA

  • DHE-RSA-AES256-SHA256

  • DHE-RSA-AES256-GCM-SHA384

  • ECDHE-ECDSA-AES256-SHA

  • ECDHE-ECDSA-AES256-GCM-SHA384

  • ECDHE-RSA-AES256-SHA384

  • ECDHE-RSA-AES128-SHA

  • ECDHE-RSA-AES128-SHA256

  • ECDHE-RSA-AES128-GCM-SHA256

  • ECDHE-RSA-AES256-SHA

  • ECDHE-RSA-AES256-GCM-SHA384

  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

  • TLS_RSA_WITH_AES_256_GCM_SHA384

  • TLS_RSA_WITH_AES_256_CBC_SHA

  • TLS_RSA_WITH_AES_128_GCM_SHA256

  • TLS_RSA_WITH_AES_128_CBC_SHA256

  • TLS_RSA_WITH_AES_128_CBC_SHA

  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

  • TLS_AES_128_GCM_SHA256

  • TLS_AES_256_GCM_SHA384

È possibile utilizzare anche il comando della CLI describe-engine-default-cluster-parameters per determinare quali suite di cifratura sono attualmente supportate per una famiglia del gruppo di parametri specifici. L'esempio seguente mostra come ottenere i valori consentiti per il parametro del cluster ssl_cipher per Aurora PostgreSQL 11.

aws rds describe-engine-default-cluster-parameters --db-parameter-group-family aurora-postgresql11 ...some output truncated... { "ParameterName": "ssl_ciphers", "Description": "Sets the list of allowed TLS ciphers to be used on secure connections.", "Source": "engine-default", "ApplyType": "dynamic", "DataType": "list", "AllowedValues": "DHE-RSA-AES128-SHA,DHE-RSA-AES128-SHA256,DHE-RSA-AES128-GCM-SHA256,DHE-RSA-AES256-SHA,DHE-RSA-AES256-SHA256,DHE-RSA-AES256-GCM-SHA384, ECDHE-RSA-AES128-SHA,ECDHE-RSA-AES128-SHA256,ECDHE-RSA-AES128-GCM-SHA256,ECDHE-RSA-AES256-SHA,ECDHE-RSA-AES256-SHA384,ECDHE-RSA-AES256-GCM-SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA", "IsModifiable": true, "MinimumEngineVersion": "11.8", "SupportedEngineModes": [ "provisioned" ] }, ...some output truncated...

Il parametro ssl_ciphers è impostato per tutte le suite di cifrature consentite. Per ulteriori informazioni sulla crittografia, consulta la variabile ssl_ciphers nella documentazione di PostgreSQL.