Sicurezza con Amazon Aurora Postgre SQL - 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 Postgre SQL

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

  • Per controllare chi può eseguire azioni di RDS gestione Amazon sui cluster SQL DB Aurora Postgre e sulle istanze DB, usa (). AWS Identity and Access Management IAM IAMgestisce l'autenticazione dell'identità dell'utente prima che l'utente possa accedere al servizio. Gestisce inoltre l'autorizzazione, ovvero se l'utente è autorizzato a fare ciò che sta cercando di fare. IAMl'autenticazione del database è un metodo di autenticazione aggiuntivo che puoi scegliere quando crei il tuo cluster Aurora SQL Postgre DB. Per ulteriori informazioni, consulta Gestione delle identità e degli accessi per Amazon Aurora.

    Se lo utilizzi IAM con il tuo cluster Aurora Postgre SQL DB, accedi prima AWS Management Console con IAM le tue credenziali, prima di aprire la console Amazon all'indirizzo. RDS https://console.aws.amazon.com/rds/

  • Assicurati di creare cluster Aurora DB in un cloud privato virtuale (VPC) basato sul 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 unVPC, utilizza un gruppo di sicurezza. VPC Puoi effettuare queste connessioni tra endpoint e porte utilizzando 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 suVPCs, vedere. Amazon VPC e Aurora

    La VPC tenancy supportata dipende dalla classe di istanza DB utilizzata dai cluster DB Aurora SQL Postgre. Con la default VPC tenancy, il cluster DB viene eseguito su hardware condiviso. Con la dedicated VPC tenancy, il cluster DB viene eseguito su un'istanza hardware dedicata. Le classi di istanze DB con prestazioni espandibili supportano solo la VPC tenancy predefinita. 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 istanze Aurora Postgre SQL DB supportano sia la tenancy predefinita che quella dedicata. VPC

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

  • Per concedere le autorizzazioni ai SQL database Postgre in esecuzione sul tuo cluster Amazon Aurora DB, puoi adottare lo stesso approccio generale delle istanze autonome di Postgre. SQL 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.

    Postgre gestisce i privilegi utilizzando i ruoli. SQL Il rds_superuser ruolo è il ruolo più privilegiato su un cluster Aurora SQL Postgre DB. 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 SQL versioni di Aurora Postgre disponibili, incluse le versioni 10, 11, 12, 13, 14 e versioni successive, supportano il meccanismo di autenticazione Salted Challenge Response (SCRAM) per le password come alternativa a message digest (). MD5 Ti consigliamo di utilizzarlo SCRAM perché è più sicuro di. MD5 Per ulteriori informazioni, incluso come migrare le password degli utenti del database da MD5 aSCRAM, consulta. Utilizzo delle crittografia password SCRAM per PostgreSQL

Protezione dei dati di Aurora SQL Postgree con/SSLTLS

Amazon RDS supporta la crittografia Secure Socket Layer (SSL) e Transport Layer Security (TLS) per i cluster Aurora SQL Postgre DB. UtilizzandoSSL/TLS, è possibile crittografare una connessione tra le applicazioni e i cluster Aurora SQL Postgre DB. Puoi anche forzare tutte le connessioni al tuo cluster Aurora Postgre SQL DB a utilizzare/. SSL TLS Amazon Aurora Postgre SQL supporta le versioni 1.1 e 1.2 di Transport Layer Security (TLS). Consigliamo di utilizzare TLS 1.2 per connessioni crittografate. Abbiamo aggiunto il supporto per la versione TLSv1 2.3 delle seguenti versioni di SQL Aurora Postgres:

  • 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 suSSL/TLSsupport e sui SQL database Postgre, consulta SSL il supporto nella documentazione di Postgre. SQL Per informazioni sull'utilizzo di una TLS connessioneSSL/JDBC, consulta Configurazione del client nella documentazione di Postgre. SQL

SSL/TLSil supporto è disponibile in tutte le AWS regioni per Aurora Postgre. SQL Amazon RDS crea un TLS certificatoSSL/per il tuo cluster DB Aurora Postgre al momento della creazione del cluster SQL DB. Se abiliti la verificaSSL/TLScertificate, il TLS certificatoSSL/include l'endpoint del cluster DB come nome comune (CN) del TLS certificatoSSL/per proteggerlo dagli attacchi di spoofing.

Per connettersi a un cluster Aurora Postgre SQL DB tramite/SSLTLS
  1. Scaricare il certificato.

    Per ulteriori informazioni sul download dei certificati, consultare .

  2. Importare il certificato nel proprio sistema operativo.

  3. Connect al cluster Aurora Postgre SQL DB tramite/. SSL TLS

    Quando ti connetti usandoSSL/TLS, il tuo client può scegliere di verificare o meno la catena di certificati. Se i parametri di connessione specificano sslmode=verify-ca osslmode=verify-full, allora il client richiede che i certificati RDS CA siano presenti nel proprio trust store o che vi sia un riferimento nella connessioneURL. Questo requisito è verificare la catena di certificati che firma il certificato del database.

    Quando un client, come psql oJDBC, è configurato conSSL/TLSsupport, il client tenta innanzitutto di connettersi al database conSSL/per impostazione TLS predefinita. Se il client non riesce a connettersi conSSL/TLS, torna alla connessione senzaSSL/. TLS Per impostazione predefinita, l'sslmodeopzione per JDBC i client 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 connettersi a un cluster Aurora SQL Postgre DB.

$ 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 TLS connessioneSSL/a un cluster Aurora SQL Postgre DB

È possibile richiedere che le connessioni al cluster Aurora Postgre SQL DB utilizzinoSSL/TLSutilizzando il parametro. rds.force_ssl Per impostazione predefinita, il parametro rds.force_ssl è impostato su 0 (off). È possibile impostare il rds.force_ssl parametro su 1 (attivo) per richiedereSSL/TLSper le connessioni al cluster DB. L'aggiornamento del rds.force_ssl parametro imposta anche il SQL ssl parametro Postgre su 1 (on) e modifica il pg_hba.conf file del cluster DB per supportare la nuova SSL configurazione/. 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 .

Quando il rds.force_ssl parametro è impostato su 1 per un cluster DB, al momento della connessione viene visualizzato un output simile al seguente, a indicare che ora TLS è richiestoSSL/:

$ 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 della TLS connessioneSSL/

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=>

È inoltre possibile caricare l'sslinfoestensione e quindi chiamare la ssl_is_used() funzione per determinare seSSL/TLSè in uso. La funzione restituisce t se la connessione utilizzaSSL/TLS, altrimenti restituiscef.

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

È possibile utilizzare il select ssl_cipher() comando per determinare il TLS codiceSSL/:

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

Se si abilita set rds.force_ssl e si riavvia il cluster DB, le mancate SSL connessioni 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'sslmodeopzione, consulta Funzioni di controllo della connessione al database nella documentazione di Postgre. SQL

Configurazione delle suite di crittografia per le connessioni ai cluster Aurora Postgre DB SQL

Utilizzando suite di cifratura configurabili, è possibile avere maggiore controllo sulla sicurezza delle connessioni al database. Puoi specificare un elenco di suite di crittografia a cui desideri consentire di proteggere le connessioni client/i al tuo database. SSL TLS 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 crittografia configurabili sono supportate nelle versioni 11.8 e successive di Aurora SQL Postgre.

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 il, il o. AWS Management Console AWS CLI RDS API 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 i codici supportati per le versioni valide del motore Aurora Postgre. SQL

Versioni del motore Aurora SQL Postgre Cifrature supportate TLS1.1 TLS1.2 TLS1.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-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

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 _ WITH AES CBC _128_ _ SHA

TLS_ _ _ ECDHE _ RSA _128_ WITH _ AES GCM SHA256

TLS_ _ _ ECDHE _ RSA _256_ WITH _ AES CBC SHA

TLS_ _ _ ECDHE _ RSA _256_ WITH _ AES GCM SHA384

TLS_ _ _ ECDHE _ RSA _128_ WITH _ AES CBC SHA

TLS_ _ _ ECDHE _ RSA _128_ WITH _ AES GCM SHA256

TLS_ _ _ ECDHE _ RSA _256_ WITH _ AES CBC SHA

TLS_ _ _ ECDHE _ RSA _256_ WITH _ AES GCM SHA384

TLS_ _ _ RSA _256_ WITH _ AES GCM SHA384

TLS_ _ _ RSA _256_ WITH _ AES CBC SHA

TLS_ _ _ RSA _128_ WITH _ AES GCM SHA256

TLS_ _ _ RSA _128_ WITH _ AES CBC SHA

TLS_ _ _ ECDHE _ RSA 0_ WITH 05_ CHACHA2 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_ _ _ _ _128_ _ ECDHE RSA WITH AES CBC SHA

TLS_ _ _ ECDHE _ RSA _128_ WITH _ AES CBC SHA256

TLS_ _ _ ECDHE _ RSA _128_ WITH _ AES GCM SHA256

TLS_ _ _ ECDHE _ RSA _256_ WITH _ AES CBC SHA

TLS_ _ _ ECDHE _ RSA _256_ WITH _ AES GCM SHA384

TLS_ _ _ ECDHE _ RSA _128_ WITH _ AES CBC SHA

TLS_ _ _ ECDHE _ RSA _128_ WITH _ AES CBC SHA256

TLS_ _ _ ECDHE _ RSA _128_ WITH _ AES GCM SHA256

TLS_ _ _ ECDHE _ RSA _256_ WITH _ AES CBC SHA

TLS_ _ _ ECDHE _ RSA _256_ WITH _ AES GCM SHA384

TLS_ _ _ RSA _256_ WITH _ AES GCM SHA384

TLS_ _ _ RSA _256_ WITH _ AES CBC SHA

TLS_ _ _ RSA _128_ WITH _ AES GCM SHA256

TLS_ _ _ RSA _128_ WITH _ AES CBC SHA256

TLS_ _ _ RSA _128_ WITH _ AES CBC SHA

TLS_ _ _ ECDHE _ RSA 0_ WITH 05_ CHACHA2 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_ _ _ _ _128_ _ ECDHE RSA WITH AES CBC SHA

TLS_ _ _ ECDHE _ RSA _128_ WITH _ AES CBC SHA256

TLS_ _ _ ECDHE _ RSA _128_ WITH _ AES GCM SHA256

TLS_ _ _ ECDHE _ RSA _256_ WITH _ AES CBC SHA

TLS_ _ _ ECDHE _ RSA _256_ WITH _ AES GCM SHA384

TLS_ _ _ ECDHE _ RSA _128_ WITH _ AES CBC SHA

TLS_ _ _ ECDHE _ RSA _128_ WITH _ AES CBC SHA256

TLS_ _ _ ECDHE _ RSA _128_ WITH _ AES GCM SHA256

TLS_ _ _ ECDHE _ RSA _256_ WITH _ AES CBC SHA

TLS_ _ _ ECDHE _ RSA _256_ WITH _ AES GCM SHA384

TLS_ _ _ RSA _256_ WITH _ AES GCM SHA384

TLS_ _ _ RSA _256_ WITH _ AES CBC SHA

TLS_ _ _ RSA _128_ WITH _ AES GCM SHA256

TLS_ _ _ RSA _128_ WITH _ AES CBC SHA256

TLS_ _ _ RSA _128_ WITH _ AES CBC SHA

TLS_ _ _ ECDHE _ RSA 0_ WITH 05_ CHACHA2 POLY13 SHA256

TLS_ _128_ _ AES GCM SHA256

TLS_ _256_ _ AES 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 CLI comando 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 ssl_cipher cluster per Aurora SQL Postgre 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 sui codici, consulta la variabile ssl_ciphers nella documentazione di Postgre. SQL