Protezione dei dati in Amazon Aurora DSQL
Alla protezione dei dati si applica il modello di responsabilità condivisa
Per garantire la protezione dei dati, suggeriamo di proteggere le credenziali e di configurare i singoli utenti con AWS IAM Identity Center o 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:
-
Utilizzare l’autenticazione a più fattori (MFA) con ogni account.
-
Utilizzare SSL/TLS per comunicare con le risorse . È richiesto TLS 1.2 ed è consigliato TLS 1.3.
-
Configurare l’API e la registrazione dei log delle attività degli utenti con AWS CloudTrail. Per informazioni sull’utilizzo dei percorsi CloudTrail per acquisire le attività, consultare Utilizzo dei percorsi CloudTrail nella Guida per l’utente di CloudTrail.
-
Utilizzare le soluzioni di crittografia, insieme a tutti i controlli di sicurezza di default all’interno dei Servizi AWS.
-
Utilizzare 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. Questo vale quando si lavora con la CLI e altri strumenti utilizzando la console, le API, la AWS CLI o gli SDK AWS. 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 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 i client AWS CLI, SDK o API e gli endpoint di 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 attraverso un certificato X.509 o la chiave di accesso segreta AWS del cliente secondo il processo di firma Signature Version 4 (Sigv4). Per maggiori informazioni, consultare Processo di firma Signature Version 4 nella Riferimenti generali di AWS.
-
Utilizzare la AWS CLI o uno degli SDK AWS per effettuare richieste ad AWS. Questi strumenti firmano automaticamente le richieste con la chiave di accesso specificata al momento della configurazione.
Per la crittografia a riposo, consultare Crittografia dei dati a riposo in Aurora DSQL.
Riservatezza del traffico inter-rete
Le connessioni tra Aurora DSQL e le applicazioni on-premises locali e tra Aurora DSQL e altre risorse AWS nella stessa Regione AWS sono protette.
Sono disponibili due opzioni di connettività tra la rete privata e AWS:
-
Una connessione AWS VPN Site-to-Site VPN. Per maggiori informazioni, consultare Che cos’è AWS Site-to-Site VPN?
-
Una connessione AWS Direct Connect. Per maggiori informazioni, consultare Che cos’è AWS Direct Connect?
È 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, consultare Configurazione di cluster multi-Regione.