Autenticazione al database Aurora PostgreSQL con IAM

Hai mai passato una notte a ruotare manualmente le password del database perché erano in scadenza? O scoperto che le credenziali di accesso erano salvate in chiaro in un file di configurazione che girava su dieci server?

Queste situazioni sono più comuni di quanto si pensi, e rappresentano uno dei rischi di sicurezza più sottovalutati nelle infrastrutture cloud moderne.

Amazon Web Services offre una soluzione elegante a questo problema: l’autenticazione IAM per Aurora PostgreSQL e Amazon RDS. Invece di password statiche — che vanno gestite, ruotate e protette — si usano token temporanei generati al momento della connessione. Nessuna password da conservare, nessun segreto da far girare nei file di configurazione.

In questo articolo vediamo come funziona, come si configura e quando ha senso adottarla.

Come funziona l’autenticazione IAM

Il principio è semplice: invece di chiedere una password fissa, il database accetta un token temporaneo che viene generato al momento e ha una durata limitatissima — circa 15 minuti.

Il processo si articola in tre fasi:

L’applicazione (o l’utente) possiede un’identità IAM con i permessi corretti
Viene richiesto un token temporaneo firmato digitalmente ad AWS
Il token viene usato come password per la connessione al database

Il token viene generato con il comando AWS CLI:

aws rds generate-db-auth-token \
  --hostname mio-cluster.cluster-abc123.eu-west-1.rds.amazonaws.com \
  --port 5432 \
  --region eu-west-1 \
  --username mio-utente

Il risultato è una stringa lunga firmata digitalmente. Scade dopo 15 minuti, quindi anche se venisse intercettata sarebbe inutilizzabile quasi immediatamente.

Configurazione del cluster Aurora

Prima di tutto, bisogna abilitare l’autenticazione IAM sul cluster. Non è attiva di default: va spuntata esplicitamente nelle impostazioni del cluster Aurora, sia dalla console AWS che via Terraform o CLI.

Una volta abilitata, bisogna creare l’utente PostgreSQL e assegnargli il ruolo speciale rds_iam, che indica al sistema di accettare token IAM al posto di password:

-- Crea l'utente (il nome deve corrispondere a quello nella policy IAM)
CREATE USER "mario.rossi@example.com";

-- Assegna il ruolo IAM
GRANT rds_iam TO "mario.rossi@example.com";

Importante: il nome utente PostgreSQL deve corrispondere esattamente a quello presente nella policy IAM e usato nella generazione del token. Anche una maiuscola diversa causa errori di accesso.

Creare la policy IAM

L’accesso non funziona finché non autorizzi esplicitamente l’identità IAM a connettersi. La policy deve concedere l’azione rds-db:connect sulla risorsa specifica del cluster.

L’ARN della risorsa segue questo schema:

arn:aws:rds-db:REGIONE:ACCOUNT-ID:dbuser:RESOURCE-ID/NOME-UTENTE

Esempio di policy JSON completa:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "rds-db:connect",
    "Resource": "arn:aws:rds-db:eu-west-1:123456789012:dbuser:cluster-ABC123/mario.rossi@example.com"
  }]
}

Come trovare il resource-id? Non è il nome del cluster, ma un identificatore interno. Lo trovi nella console RDS sotto Configuration → Resource ID, oppure via CLI:

aws rds describe-db-clusters \
  --query 'DBClusters[*].[DBClusterIdentifier,DbClusterResourceId]'

Connettersi al database

Con policy e utente configurati, il flusso di connessione è questo:

Genera il token con aws rds generate-db-auth-token
Usa il token come valore del campo password nella stringa di connessione
Assicurati che SSL sia abilitato (è obbligatorio con IAM auth)

Esempio con psql:

TOKEN=$(aws rds generate-db-auth-token \
  --hostname mio-cluster.cluster-abc123.eu-west-1.rds.amazonaws.com \
  --port 5432 --region eu-west-1 --username mario.rossi@example.com)

psql "host=mio-cluster.cluster-abc123.eu-west-1.rds.amazonaws.com \
      port=5432 sslmode=require \
      dbname=mio_database \
      user=mario.rossi@example.com \
      password=$TOKEN"

Esempio con Python e psycopg2:

import boto3
import psycopg2

client = boto3.client('rds', region_name='eu-west-1')

token = client.generate_db_auth_token(
    DBHostname='mio-cluster.cluster-abc123.eu-west-1.rds.amazonaws.com',
    Port=5432,
    DBUsername='mario.rossi@example.com'
)

conn = psycopg2.connect(
    host='mio-cluster.cluster-abc123.eu-west-1.rds.amazonaws.com',
    port=5432,
    database='mio_database',
    user='mario.rossi@example.com',
    password=token,
    sslmode='require'
)

Perché vale la pena usarla

I benefici concreti rispetto alla gestione tradizionale delle password:

Nessuna password da gestire o ruotare: il token scade da solo dopo 15 minuti
Accesso centralizzato: chi ha il permesso IAM può connettersi, chi non ce l’ha viene bloccato automaticamente
Audit trail: ogni accesso è tracciabile in CloudTrail
Facile revoca: basta togliere la policy IAM per bloccare l’accesso istantaneamente
Funziona con i ruoli IAM: perfetto per EC2, Lambda e container ECS senza segreti hard-coded

Limiti da considerare

Token di breve durata: le applicazioni che mantengono connessioni persistenti devono gestire il rinnovo del token prima della scadenza
Dipendenza da AWS: il client deve poter raggiungere l’endpoint AWS per generare il token — non funziona offline o in ambienti isolati
Massimo 200 connessioni IAM per database: tieni presente questo limite in architetture ad alto numero di connessioni
SSL obbligatorio: se la tua infrastruttura ha vincoli su SSL, tienilo in considerazione

Quando ha senso adottarla

L’autenticazione IAM è la scelta giusta se:

Lavori in un ambiente cloud-native su AWS
Vuoi eliminare le password statiche dal tuo stack
Hai utenti o servizi con accessi temporanei (operatori, pipeline CI/CD, Lambda)
Stai costruendo architetture a microservizi dove ogni servizio ha il proprio ruolo IAM

È meno indicata se hai applicazioni legacy che non supportano la rigenerazione automatica del token, o se operi in ambienti ibridi con connettività limitata ad AWS.

Conclusione

La gestione delle password dei database è uno di quei problemi che si tende a rimandare finché non diventa urgente — di solito nel momento peggiore. L’autenticazione IAM non risolve tutto, ma elimina una categoria intera di rischi senza aggiungere complessità operativa significativa.

In un’architettura moderna su AWS, dove ogni componente ha già il suo ruolo IAM, abilitarla è spesso la soluzione più naturale: nessun secret manager da configurare, nessuna rotazione da schedulare, nessuna password da proteggere.

Se stai costruendo qualcosa di nuovo su Aurora o RDS, vale la pena partire già con IAM authentication. Aggiungerla in un secondo momento su sistemi esistenti richiede più lavoro di quanto sembri.