Sicurezza RDS: crittografia e parameter group

RDS supporta la crittografia a riposo tramite AWS Key Management Service (KMS). Quando abilita la crittografia durante la creazione dell'istanza DB, tutti i dati nei volumi EBS sottostanti, nei backup automatici, nelle snapshot e nelle Read Replica vengono crittografati utilizzando la chiave KMS specificata.

La crittografia deve essere abilitata al momento della creazione: non è possibile crittografare direttamente un'istanza esistente non crittografata. La soluzione consiste nell'acquisire una snapshot non crittografata, copiarla abilitando la crittografia e ripristinare l'istanza dalla snapshot crittografata. La chiave KMS può essere una chiave gestita da AWS oppure una Customer-Managed Key (CMK), che offre maggiore controllo e possibilità di audit.

Poiché non è possibile abilitare la crittografia su un'istanza esistente, seguite questo percorso di migrazione:

1. Create uno snapshot manuale dell'istanza non crittografata
2. Copiate lo snapshot e abilitate la crittografia durante la copia, specificando una chiave KMS
3. Ripristinate una nuova istanza DB dallo snapshot crittografato
4. Aggiornate l'endpoint dell'applicazione in modo che punti alla nuova istanza
5. Eliminate la vecchia istanza non crittografata

Questo approccio comporta un certo downtime, a meno che non utilizziate DMS per mantenere sincronizzata la nuova istanza crittografata prima del cutover.

RDS crittografa i dati in transito utilizzando SSL/TLS. Ogni motore fornisce un certificato CA scaricabile che il driver client utilizza per verificare l'identità del server. Per imporre l'uso delle connessioni SSL, configurate il motore del database in modo che rifiuti le connessioni non crittografate.

Per MySQL, impostate il parametro require_secure_transport = ON nel gruppo di parametri. Per PostgreSQL, impostate ssl = 1 e, facoltativamente, rds.force_ssl = 1 per rifiutare completamente le connessioni non SSL. Molti driver di database Java e Python accettano inoltre il parametro sslmode=require nella stringa di connessione.

I gruppi di parametri sono raccolte denominate di impostazioni di configurazione del motore che vengono associate a un'istanza RDS. Sono l'equivalente RDS della modifica di my.cnf in MySQL o di postgresql.conf in PostgreSQL, ma sono gestiti da AWS e sottoposti a versionamento per famiglia di motori.

AWS fornisce un gruppo di parametri predefinito per ogni versione del motore, ma le relative impostazioni non possono essere modificate. Per personalizzare i parametri, create un gruppo di parametri personalizzato, modificate i parametri desiderati e associatelo all'istanza DB. Le modifiche ai parametri statici richiedono un riavvio; i parametri dinamici diventano effettivi immediatamente.

Dopo aver creato un gruppo di parametri personalizzato, modificate i singoli parametri utilizzando il comando CLI modify-db-parameter-group o la console. I parametri hanno un metodo di applicazione: immediate (diventa effettivo senza riavvio) oppure pending-reboot (diventa effettivo solo dopo il riavvio successivo dell'istanza).

Parametri importanti da conoscere per l'esame: max_connections (limite delle connessioni simultanee), innodb_buffer_pool_size (dimensione della cache in memoria di MySQL), log_bin_trust_function_creators (consente le stored function che scrivono nel binary log) e rds.force_ssl (impone SSL per PostgreSQL).

I gruppi di opzioni sono simili ai gruppi di parametri, ma controllano funzionalità aggiuntive del motore del database invece della configurazione delle prestazioni. Vengono utilizzati principalmente con Oracle e SQL Server per abilitare funzionalità come Oracle Application Express (APEX), SQL Server Transparent Data Encryption (TDE) o l'autenticazione SQL Server Active Directory.

Ogni opzione di un gruppo di opzioni può avere impostazioni proprie. I gruppi di opzioni sono sottoposti a versionamento per famiglia di motori e devono essere associati all'istanza DB. La maggior parte dei motori open source (MySQL, PostgreSQL, MariaDB) raramente richiede gruppi di opzioni personalizzati.

RDS supporta l'autenticazione IAM del database per i motori MySQL e PostgreSQL. Invece di utilizzare una combinazione statica di nome utente e password, l'applicazione assume un ruolo IAM e genera un token di autenticazione temporaneo (valido per 15 minuti) utilizzando il comando AWS CLI o la chiamata SDK generate-db-auth-token.

Tra i vantaggi figurano l'assenza di password del database a lunga durata, la rotazione automatica delle credenziali tramite le policy IAM e il controllo centralizzato degli accessi. Per utilizzare questa funzionalità è necessario abilitare --enable-iam-database-authentication sull'istanza e creare un utente del database associato a un ruolo IAM.

AWS Secrets Manager può archiviare e ruotare automaticamente la password principale di RDS e le credenziali dell'applicazione. Quando la rotazione è abilitata, Secrets Manager richiama una funzione Lambda che aggiorna la password del database e memorizza il nuovo valore nel secret; l'applicazione recupera il valore più recente del secret tramite l'API di Secrets Manager, disponendo così sempre di credenziali valide.

Quando create un'istanza RDS nella console, potete scegliere di affidare a Secrets Manager la gestione delle credenziali principali. In questo modo si eliminano le password codificate nel codice o nelle variabili d'ambiente.

Le istanze RDS vengono eseguite all'interno di una VPC e utilizzano i gruppi di sottoreti DB per definire in quali sottoreti (distribuite su più AZ) è possibile collocare l'istanza. La best practice consiste nel collocare RDS in sottoreti private senza accesso diretto a Internet.

I gruppi di sicurezza controllano quali indirizzi IP e quali altri gruppi di sicurezza possono raggiungere la porta DB (ad esempio, TCP 3306 per MySQL). Il gruppo di sicurezza del livello applicativo dovrebbe essere l'unica origine consentita nel gruppo di sicurezza RDS, applicando il principio del privilegio minimo a livello di rete. Non configurate mai 0.0.0.0/0 (tutto il traffico) come regola in ingresso in un gruppo di sicurezza RDS.

Enhanced Monitoring pubblica le metriche a livello di sistema operativo (CPU, memoria, file system, I/O del disco) in CloudWatch Logs ogni 1–60 secondi, offrendo una granularità maggiore rispetto alle metriche CloudWatch predefinite a intervalli di 60 secondi. Utilizza un agent in esecuzione sull'host DB ed è disponibile per tutti i motori, ad eccezione della modalità di mirroring di SQL Server.

I log di audit del database (general query log e slow query log per MySQL; pgaudit per PostgreSQL) possono essere pubblicati in CloudWatch Logs per l'analisi di conformità. Abilitateli tramite i gruppi di parametri, quindi configurate le esportazioni dei log nella console RDS, alla voce Esportazioni dei log.

Principali best practice di sicurezza RDS per l'esame SAA-C03:

• Abilitate la crittografia a riposo con una CMK KMS durante la creazione dell'istanza
• Imponete l'uso di SSL/TLS in transito tramite le impostazioni dei gruppi di parametri
• Collocate le istanze in sottoreti private con gruppi di sicurezza restrittivi
• Utilizzate l'autenticazione IAM del database o Secrets Manager per evitare password statiche
• Abilitate CloudTrail per registrare le chiamate API RDS e CloudWatch Logs per i log di audit del database
• Utilizzate le regole AWS Config (ad esempio, rds-instance-public-access-check) per rilevare configurazioni errate

Verificate la vostra comprensione dei concetti di AWS Solutions Architect (SAA-C03) trattati in questa lezione.

In questa lezione avete imparato che la crittografia RDS a riposo utilizza KMS e deve essere abilitata durante la creazione, che i gruppi di parametri controllano la configurazione del motore, incluso l'uso di SSL/TLS per i dati in transito, e che l'autenticazione IAM del database e Secrets Manager eliminano le password statiche del database. Ora esamineremo le tabelle e gli elementi di DynamoDB, oltre alla progettazione delle chiavi primarie.