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à. # Protezione dei dati in Amazon Aurora DSQL Alla protezione dei dati si applica il [modello di responsabilità condivisa](https://aws.amazon.com/compliance/shared-responsibility-model/). Come descritto in questo modello, AWS è responsabile della protezione dell’infrastruttura globale che esegue tutto il Cloud AWS. L’utente è responsabile del controllo dei contenuti ospitati su questa infrastruttura. Il cliente è inoltre responsabile della configurazione della protezione e delle attività di gestione per i servizi utilizzati. Per maggiori informazioni sulla privacy dei dati, consulta 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 e GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) nel *Blog sulla sicurezza*. Ai fini della protezione dei dati, ti consigliamo di proteggere le credenziali e configurare i singoli utenti con o. AWS IAM Identity Center AWS Identity and Access Management In tal modo, a ogni utente verranno assegnate solo le autorizzazioni necessarie per svolgere i suoi compiti. Suggeriamo, inoltre, di proteggere i dati nei seguenti modi: + Utilizza l’autenticazione a più fattori (MFA) con ogni account. + SSL/TLS Da utilizzare per comunicare con le risorse. È 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 trail per acquisire le attività, consulta [Utilizzo dei percorsi CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) nella *Guida per l’utente di CloudTrail*. + Utilizza le soluzioni di crittografia, 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. 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**. Ciò include quando lavori o utilizzi la console, l'API o AWS SDKs. AWS CLI 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 si fornisce un URL a un server esterno, suggeriamo vivamente di non includere informazioni sulle credenziali nell’URL per convalidare la richiesta al server. ## Crittografia dei dati Amazon Aurora DSQL offre un’infrastruttura di storage estremamente durevole, concepita per lo archiviazione di dati mission-critical e primari. I dati sono archiviati in modo ridondante su più dispositivi, in più strutture di una Regione Aurora DSQL. ### Crittografia dei dati in transito Per impostazione predefinita, è configurata la crittografia in transito. Aurora DSQL utilizza TLS per crittografare tutto il traffico tra il client SQL e Aurora DSQL. Crittografia e firma dei dati in transito tra AWS CLI client SDK o API e endpoint Aurora DSQL: + Aurora DSQL fornisce endpoint HTTPS per la crittografia dei dati in transito. + Per proteggere l’integrità delle richieste API ad Aurora DSQL, le chiamate API devono essere firmate dal chiamante. Le chiamate sono firmate da un certificato X.509 o dalla chiave di accesso AWS segreta del cliente in base al processo di firma della versione 4 di firma (Sigv4). Per maggiori informazioni, consulta [Processo di firma Signature Version 4](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) nella *Riferimenti generali di AWS*. + Usa il AWS CLI o uno dei due per effettuare richieste AWS SDKs a. AWS Questi strumenti firmano automaticamente le richieste con la chiave di accesso specificata al momento della configurazione. #### Conformità a FIPS Gli endpoint del piano dati Aurora DSQL (endpoint del cluster utilizzati per le connessioni al database) utilizzano moduli crittografici convalidati FIPS 140-2 per impostazione predefinita. Non sono necessari endpoint FIPS separati per le connessioni al cluster. Per le operazioni sul piano di controllo, Aurora DSQL fornisce endpoint FIPS dedicati nelle regioni supportate. Per ulteriori informazioni sugli endpoint FIPS del piano di controllo, vedere Endpoint e [quote Aurora DSQL](https://docs.aws.amazon.com/general/latest/gr/dsql.html) in. *Riferimenti generali di AWS* Per la crittografia a riposo, consulta [Crittografia dei dati a riposo in Aurora DSQL](data-encryption.md#encryption-at-rest). ### Riservatezza del traffico inter-rete Le connessioni sono protette sia tra Aurora DSQL e le applicazioni locali sia tra Aurora DSQL e altre risorse all'interno delle stesse. AWS Regione AWS 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 Aurora DSQL 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à. ## Protezione dei dati nelle Regioni testimone Quando si crea un cluster multi-Regione, una Regione testimone consente il ripristino automatico degli errori partecipando alla replica sincrona delle transazioni crittografate. Se un cluster in peering diventa non disponibile, la Regione testimone rimane disponibile per convalidare ed elaborare le scritture sul database, garantendo l’assenza di perdita di disponibilità. Le Regioni testimone proteggono e mantengono al sicuro i dati tramite queste funzionalità imposte come requisito di progettazione: + La Regione testimone riceve e archivia i registri dei log delle sole transazioni crittografate. Non ospita, archivia o trasmette mai le chiavi di crittografia. + La Regione testimone si concentra esclusivamente sulla registrazione delle transazioni di scrittura e sulle funzioni di quorum. Per requisito di progettazione non è in grado di leggere i dati. + La Regione testimone funziona senza endpoint di connessione al cluster o elaboratori di query. Ciò impedisce l’accesso al database da parte degli utenti. Per maggiori informazioni sulle Regioni testimoni, consulta [Configurazione di cluster multi-Regione](configuring-multi-region-clusters.md). # Configurazione dei SSL/TLS certificati per le connessioni Aurora DSQL Aurora DSQL richiede che tutte le connessioni utilizzino la crittografia Transport Layer Security (TLS). Per stabilire connessioni sicure, il sistema client deve affidarsi all’Amazon Root Certificate Authority (Amazon Root CA 1). Questo certificato è preinstallato su molti sistemi operativi. Questa sezione fornisce istruzioni per verificare il certificato Amazon Root CA 1 preinstallato su vari sistemi operativi e guida l’utente attraverso il processo di installazione manuale del certificato, qualora non fosse già presente. Si consiglia di utilizzare PostgreSQL versione 17. **Importante** Per gli ambienti di produzione, si consiglia di utilizzare la modalità SSL `verify-full` per garantire il massimo livello di sicurezza della connessione. Questa modalità verifica che il certificato del server sia firmato da un’autorità di certificazione affidabile e che il nome host del server corrisponda al certificato. ## Verifica dei certificati preinstallati Nella maggior parte dei sistemi operativi, **Amazon Root CA 1** è già preinstallato. Per convalidarlo, è possibile completare la procedura seguente. ### Linux () RedHat/CentOS/Fedora Esegui il comando seguente nel terminale: ``` trust list | grep "Amazon Root CA 1" ``` Se il certificato è installato, verrà visualizzato il seguente output: ``` label: Amazon Root CA 1 ``` ### macOS 1. Apri Spotlight Search (**Command** \$1 **Spazio**) 1. Cerca **Keychain Access** 1. Seleziona **System Roots** in **System Keychains** 1. Cerca **Amazon Root CA 1** nell’elenco dei certificati ### Windows **Nota** A causa di un problema noto con il client psql per Windows, l’utilizzo dei certificati root di sistema (`sslrootcert=system`) può restituire il seguente errore: `SSL error: unregistered scheme`. È possibile seguire [Connessione da Windows](#connect-windows) come metodo alternativo per connettersi al cluster tramite SSL. Se **Amazon Root CA 1** non è installato nel sistema operativo, procedi nel seguente modo. ## Installazione dei certificati Se il certificato `Amazon Root CA 1` non è preinstallato sul sistema operativo, sarà necessario installarlo manualmente per stabilire connessioni sicure al cluster Aurora DSQL. ### Installazione del certificato su Linux Attieniti alla seguente procedura per installare il certificato Amazon Root CA sui sistemi Linux. 1. Scarica il certificato root: ``` wget https://www.amazontrust.com/repository/AmazonRootCA1.pem ``` 1. Aggiungi il certificato all’archivio di fiducia: ``` sudo cp ./AmazonRootCA1.pem /etc/pki/ca-trust/source/anchors/ ``` 1. Aggiorna il CA Trust Store: ``` sudo update-ca-trust ``` 1. Verifica l’installazione: ``` trust list | grep "Amazon Root CA 1" ``` ### Installazione del certificato su macOS Questi passaggi di installazione dei certificati sono facoltativi. [Installazione del certificato su Linux](#install-linux) funziona anche per macOS. 1. Scarica il certificato root: ``` wget https://www.amazontrust.com/repository/AmazonRootCA1.pem ``` 1. Aggiungi il certificato al keychain di sistema: ``` sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain AmazonRootCA1.pem ``` 1. Verifica l’installazione: ``` security find-certificate -a -c "Amazon Root CA 1" -p /Library/Keychains/System.keychain ``` ## Connessione con SSL/TLS verifica Prima di configurare SSL/TLS i certificati per connessioni sicure al cluster Aurora DSQL, assicurati di avere i seguenti prerequisiti. + PostgreSQL versione 17 installata + AWS CLI configurato con le credenziali appropriate + Informazioni sugli endpoint del cluster Aurora DSQL ### Connessione da Linux 1. Genera e imposta il token di autenticazione: ``` export PGPASSWORD=$(aws dsql generate-db-connect-admin-auth-token --region=your-cluster-region --hostname your-cluster-endpoint) ``` 1. Connettiti utilizzando certificati di sistema (se preinstallati): ``` PGSSLROOTCERT=system \ PGSSLMODE=verify-full \ psql --dbname postgres \ --username admin \ --host your-cluster-endpoint ``` 1. Oppure, connettiti utilizzando un certificato scaricato: ``` PGSSLROOTCERT=/full/path/to/root.pem \ PGSSLMODE=verify-full \ psql --dbname postgres \ --username admin \ --host your-cluster-endpoint ``` **Nota** Per maggiori informazioni sulle impostazioni PGSSLMODE, consulta [sslmode](https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNECT-SSLMODE) nella documentazione sulle [Funzioni di controllo della connessione del database](https://www.postgresql.org/docs/current/libpq-connect.html) di PostgreSQL 17. ### Connessione da macOS 1. Genera e imposta il token di autenticazione: ``` export PGPASSWORD=$(aws dsql generate-db-connect-admin-auth-token --region=your-cluster-region --hostname your-cluster-endpoint) ``` 1. Connettiti utilizzando certificati di sistema (se preinstallati): ``` PGSSLROOTCERT=system \ PGSSLMODE=verify-full \ psql --dbname postgres \ --username admin \ --host your-cluster-endpoint ``` 1. Oppure, scarica il certificato root e salvalo con il nome `root.pem` (se il certificato non è preinstallato) ``` PGSSLROOTCERT=/full/path/to/root.pem \ PGSSLMODE=verify-full \ psql —dbname postgres \ --username admin \ --host your_cluster_endpoint ``` 1. Connessione tramite psql: ``` PGSSLROOTCERT=/full/path/to/root.pem \ PGSSLMODE=verify-full \ psql —dbname postgres \ --username admin \ --host your_cluster_endpoint ``` ### Connessione da Windows #### Utilizzo del prompt dei comandi 1. Genera il token di autenticazione: ``` aws dsql generate-db-connect-admin-auth-token ^ --region=your-cluster-region ^ --expires-in=3600 ^ --hostname=your-cluster-endpoint ``` 1. Imposta la variabile di ambiente della password: ``` set "PGPASSWORD=token-from-above" ``` 1. Imposta la configurazione SSL: ``` set PGSSLROOTCERT=C:\full\path\to\root.pem set PGSSLMODE=verify-full ``` 1. Connettiti al database: ``` "C:\Program Files\PostgreSQL\17\bin\psql.exe" --dbname postgres ^ --username admin ^ --host your-cluster-endpoint ``` #### Usando PowerShell 1. Genera e imposta il token di autenticazione: ``` $env:PGPASSWORD = (aws dsql generate-db-connect-admin-auth-token --region=your-cluster-region --expires-in=3600 --hostname=your-cluster-endpoint) ``` 1. Imposta la configurazione SSL: ``` $env:PGSSLROOTCERT='C:\full\path\to\root.pem' $env:PGSSLMODE='verify-full' ``` 1. Connettiti al database: ``` "C:\Program Files\PostgreSQL\17\bin\psql.exe" --dbname postgres ` --username admin ` --host your-cluster-endpoint ``` ## Risorse aggiuntive + [Documentazione di PostgreSQL SSL](https://www.postgresql.org/docs/current/libpq-ssl.html) + [Servizi Amazon Trust](https://www.amazontrust.com/repository/)