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 può eseguire azioni di gestione di Amazon RDS su cluster e istanze DB PostgreSQL Aurora, usa (IAM). AWS Identity and Access Management 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 delle identità e degli accessi per Amazon Aurora.

    Se utilizzi IAM con il tuo cluster Aurora PostgreSQL DB, accedi prima con le tue credenziali IAM, prima di aprire la AWS Management Console 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 quali dispositivi e EC2 istanze Amazon possono aprire connessioni all'endpoint e alla porta dell'istanza DB per i cluster Aurora DB in un VPC, utilizza 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 su, consulta. VPCs Amazon VPC e 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 Classi di istanze DB Amazon Aurora. 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, consulta Comprendere i SQL ruoli e le autorizzazioni di Postgree.

Tutte le versioni di Aurora PostgreSQL disponibili, incluse le versioni 10, 11, 12, 13, 14 e versioni successive, supportano il Salted Challenge Response Authentication Mechanism (SCRAM) per le password come alternativa a message digest (). MD5 Ti consigliamo di utilizzare SCRAM perché è più sicuro di. MD5 Per ulteriori informazioni, incluso come migrare le password degli utenti del database da SCRAM 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. Utilizzo dell'SSL/TLS, you can encrypt a connection between your applications and your Aurora PostgreSQL DB clusters. You can also force all connections to your Aurora PostgreSQL DB cluster to use 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 la versione TLSv1 2.3 delle 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 SSL/TLS è disponibile in tutte le regioni per AWS Aurora PostgreSQL. Amazon RDS crea un SSL/TLS certificate for your Aurora PostgreSQL DB cluster when the DB cluster is created. If you enable SSL/TLS certificate verification, then the SSL/TLS certificate includes the DB cluster endpoint as the Common Name (CN) for the SSL/TLS certificato per proteggersi dagli 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. SSL/TLS support, the client first tries to connect to the database with SSL/TLS by default. If the client can't connect with SSL/TLS, it reverts to connecting without 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

Per richiedere connessioni SSL/TLS al cluster Aurora PostgreSQL DB, usa il parametro. rds.force_ssl

  • Per richiedere connessioni SSL/TLS, imposta il valore del parametro su 1 (attivo). rds.force_ssl

  • Per disattivare le connessioni SSL/TLS richieste, imposta il valore del parametro su 0 (disattivato). rds.force_ssl

Il valore predefinito di questo parametro dipende dalla versione di Aurora PostgreSQL:

  • Per Aurora PostgreSQL versione 17 e successive: il valore predefinito è 1 (attivo).

  • Per le versioni 16 e precedenti di Aurora PostgreSQL: il valore predefinito è 0 (disattivato).

Nota

Quando si esegue un aggiornamento della versione principale da Aurora PostgreSQL versione 16 o precedente alla versione 17 o successiva, il valore predefinito del parametro cambia da 0 (disattivato) a 1 (attivo). Questa modifica può causare errori di connettività per le applicazioni non configurate per SSL. È possibile ripristinare il comportamento predefinito precedente impostando questo parametro su 0 (disattivato).

Per ulteriori informazioni sulla gestione dei parametri, vedere.

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.

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 ssl_ciphers parametro su una stringa di valori di cifratura separati da virgole in un gruppo di parametri del cluster utilizzando l'API RDS AWS Management Console AWS CLI, the o. Per impostare i parametri del cluster, consulta Modifica dei parametri in un gruppo di parametri del cluster DB in Amazon Aurora.

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

Versioni del motore Aurora PostgreSQL Cifrature supportate TLS 1.1 TLS 1.2 TLS 1.3
9.6, 10.20 e versioni precedenti, 11.15 e versioni precedenti, 12.10 e versioni precedenti, 13.6 e versioni precedenti

DHE-RSA- -SHA AES128

DHE-RSA- AES128 - SHA256

DHE-RSA- -GCM- AES128 SHA256

DHE-RSA- AES256 -SHA

DHE-RSA- AES256 - SHA256

DHE-RSA- -GCM- AES256 SHA384

ECDHE-ECDSA- AES256 -SHA

ECDHE-ECDSA- -GCM- AES256 SHA384

ECDH-RSA- - AES256 SHA384

ECDHE-RSA- AES128 -SHA

ECDHE-RSA- - AES128 SHA256

ECDHE-RSA- -GCM AES128 - SHA256

ECDHE-RSA- AES256 -SHA

ECDHE-RSA- AES256 -GCM- SHA384

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

10.21, 11.16, 12.11, 13.7, 14.3 e 14.4

ECDHE-RSA- AES128 -SHATLS_ECDHE_RSA_CON_AES_128_CBC_SHA

TLS_ECDHE_RSA_CON_AES_128_GCM_ SHA256

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

TLS_ECDHE_RSA_CON_AES_256_GCM_ SHA384

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

TLS_ECDHE_RSA_CON_AES_128_GCM_ SHA256

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

TLS_ECDHE_RSA_CON_AES_256_GCM_ SHA384

TLS_RSA_CON_AES_256_GCM_ SHA384

TLS_RSA_WITH_AES_256_CBC_SHA

TLS_RSA_CON_AES_128_GCM_ SHA256

TLS_RSA_WITH_AES_128_CBC_SHA

TLS_ECDHE_RSA_CON_ 0_ CHACHA2 05_ POLY13 SHA256

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

10.22, 11.17, 12.12, 13.8, 14.5 e 15.2

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

TLS_ECDHE_RSA_CON_AES_128_CBC_ SHA256

TLS_ECDHE_RSA_CON_AES_128_GCM_ SHA256

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

TLS_ECDHE_RSA_CON_AES_256_GCM_ SHA384

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

TLS_ECDHE_RSA_CON_AES_128_CBC_ SHA256

TLS_ECDHE_RSA_CON_AES_128_GCM_ SHA256

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

TLS_ECDHE_RSA_CON_AES_256_GCM_ SHA384

TLS_RSA_CON_AES_256_GCM_ SHA384

TLS_RSA_WITH_AES_256_CBC_SHA

TLS_RSA_CON_AES_128_GCM_ SHA256

TLS_RSA_CON_AES_128_CBC_ SHA256

TLS_RSA_WITH_AES_128_CBC_SHA

TLS_ECDHE_RSA_CON_ 0_ CHACHA2 05_ POLY13 SHA256

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

11.20, 12.15, 13.11, 14.8, 15.3, 16.1 e versioni successive

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

TLS_ECDHE_RSA_WITH_AES_128_CBC_ SHA256

TLS_ECDHE_RSA_CON_AES_128_GCM_ SHA256

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

TLS_ECDHE_RSA_CON_AES_256_GCM_ SHA384

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

TLS_ECDHE_RSA_CON_AES_128_CBC_ SHA256

TLS_ECDHE_RSA_CON_AES_128_GCM_ SHA256

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

TLS_ECDHE_RSA_CON_AES_256_GCM_ SHA384

TLS_RSA_CON_AES_256_GCM_ SHA384

TLS_RSA_WITH_AES_256_CBC_SHA

TLS_RSA_CON_AES_128_GCM_ SHA256

TLS_RSA_CON_AES_128_CBC_ SHA256

TLS_RSA_WITH_AES_128_CBC_SHA

TLS_ECDHE_RSA_CON_ 0_ CHACHA2 05_ POLY13 SHA256

TLS_AES_128_GCM_ SHA256

TLS_AES_256_GCM_ SHA384

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

È inoltre possibile utilizzare il comando CLI describe-engine-default-cluster-parameters 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 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.