Logging ed Auditing per PostgreSQL RDS

Questa paginetta riporta i passi per la configurazione del logging nativo e dell'estensione PostgreSQL PGAudit in Amazon RDS.

La registrazione degli accessi e delle attivita' (AUDIT) e' importante sia per ragioni di sicurezza che per ottemperare alle leggi ed ai regolamenti sulla gestione delle basi dati.

PostgreSQL ha potenti funzionalita' di logging ed in questo documento vediamo come configurare l'audit per la registrazione delle attivita' occorse sulla base dati sulle basi dati PostgreSQL ospitate in Amazon RDS. Analizzeremo sia il normale logging nativo che l'estensione PGAudit.

Nel seguito sono riportate alcune informazioni di interesse organizzate in paragrafi specifici: Introduzione, Logging, PGAudit, Varie ed eventuali.

Introduzione

La rilevazione delle attivita' svolte su un database e' molto importante sia per necessita' di logging/tracing che per adempiere agli eventuali requisiti di legge. PostgreSQL permette di effettuare un auditing delle attivita' con diversi strumenti che rispondono alle crescenti esigenze di auditing.

Le tecniche che riportiamo in questo documento sono:

• Logging nativo
• PGAudit

Le versioni di riferimento sono tutte le versioni di PostgreSQL ed Aurora PostgreSQL supportate in Amazon RDS.
Anche se i concetti di base sono molto simili, la configurazione e l'utilizzo del logging di PostgreSQL con una base dati on premises sono differenti come descritto in dettaglio questo documento.

Logging

La modalita' di base con PostgreSQL per registrare gli accessi e le attivita' eseguite sul database e' quella di attivare il logging. Il log di PostgreSQL riporta gli eventi occorsi sulla base dati e le query eseguite con un dettaglio che dipende dalla configurazione.

Con RDS PostgreSQL ed Aurora PostgreSQL il logging di default e' limitato e riporta principalmente eventuali errori. Il logging si configura impostando gli opportuni parametri nel DB Parameter Group.
I log vengono mantenuti per il tempo indicato dal parametro rds.log_retention_period che e' espresso in minuti. Il valore massimo e' 10080, ovvero una settimana.

Le possibilita' di configurazione del logging sono molto ampie... vediamo i parametri piu' importanti!

Il parametro log_filename specifica il formato del nome del log; su RDS si puo' scegliere tra i due formati postgresql.log.%Y-%m-%d e postgresql.log.%Y-%m-%d-%H con le ovvie differenze [NdA c'e' un ulteriore formato ma meno utile a mio avviso...]. I parametri log_rotation_age e log_rotation_size controllano la creazione di nuovi file. Su RDS i log non vengono mai troncati ed il parametro log_truncate_on_rotation e' sempre impostato a false.

Il parametro log_destination su RDS ed Aurora viene utilizzato per indicare il formato: il default e' stderr e con csvlog il formato e' CSV. Il formato CSV e' utile sia quando si utilizzano tool esterni per analizzare i log, che utilizzando l'estensione log_fdw che permette di accedere al log da SQL.

Per attivare il logging sugli statement SQL i parametri sono:

• log_statement default: none; valori possibili: none, ddl, mod, all
• log_min_duration_statement default: -1 (non attivo); valore in millisecondi (eg. 0 tutti gli statement, 5000: statement che durano oltre 5 secondi)

Ovviamente le impostazioni rispettivamente ad all o a 0 possono essere molto pesanti...

Per monitorare le connessioni e le disconnessioni i parametri sono: log_connections e log_disconnections. Questi due parametri sono utili per la compliance sugli accessi al DB, ma per alcune tipologie di applicazioni possono essere molto pesanti...

Infine il parametro rds.force_admin_logging_level consente di tracciare anche le attivita' svolte da rdsadmin.

Se serve una retention maggiore i log vanno pubblicati su Amazon CloudWatch Logs. CloudWatch fornisce funzionalita' ulteriori come la possibilita' di attivare allarmi e fornire lo streaming dei dati di log. Per pubblicare i PostgreSQL logs su CloudWatch Logs dalla console scegliere Databases --> DB instance --> Modify e quindi impostare il flag:

Da questo momento i log sono disponibili su CloudWatch:

Come abbiamo visto con log_statement e' possibile variare il tipo di statement monitorati... tuttavia l'impostazione log_statement = all porta ad una verbosita' del logging ed un forte impatto sulle performance e viene quindi utilizzata solo per periodi limitati di tempo durante un debug.

Per controllare quali oggetti controllare in modo selettivo e' possibile utilizzare l'estensione PGAudit come vedremo nel prossimo capitolo.

PGAudit

L'estensione PGAudit e' stata implementata da una terza parte ed e' disponibile fin dalla versione 9.5 di PostgreSQL. Non fa parte delle extension core di PostgreSQL ed on-premises e' necessario installarla.

Su RDS l'estensione PGAudit invece e' disponibile per tutte le versioni di PostgreSQL ed Aurora PostgreSQL ed e' quindi sufficiente configurarla.

PGAudit produce l'output sul log nativo di PostgreSQL ma fornisce alcune importanti funzioni in piu':

• E' possibile effettuare l'auditing su database, utenti ed oggetti specifici
• Una volta configurato l'auditing si imposta con semplici comandi in linea
• Il risultato del log e' piu' completo, piu' facilmente intepretabile da strumenti automatici ed eventuali informazioni sensibili vengono nascoste

L'auditing di PGAudit opera a due differenti livelli:

• SESSION che consente il controllo di:
  • READ: select, copy from
  • WRITE: insert, update, delete, truncate, copy to
  • FUNCTION: function calls, DO blocks
  • ROLE: grant, revoke, create/alter/drop role
  • DDL: all DDL (eccetto ROLE)
  • MISC: discard, fetch, checkpoint, vacuum
  • MISC_SET: comandi SET
  • ALL: tutti i precedenti
• OBJECT che consente il controllo di:
  • SELECT
  • INSERT
  • UPDATE
  • DELETE
  • ALL: tutti i precedenti

L'auditing a livello di sessione si imposta con la variabile pgaudit.log mentre quello a livello di oggetto si imposta con un GRANT.
Come? Lo vediamo tra poco: prima dobbiamo configurare l'extension!

Configurazione

Per la configurazione di PGAudit su AWS i passi sono i seguenti:

• Creare un ruolo per l'audit (su RDS ovviamente non si usa il superuser):

  CREATE ROLE rds_pgaudit;
  

• Creare/configurare il DB Parameter Group impostando il parametro pgaudit.role con il ruolo appena definito ed inserendo nelle shared_preload_libraries la libreria pgaudit:
• Riavviare il DB (e' sempre necessario quando si modifica l'elenco delle librerie dinamiche)
• Creare l'extension [NdA e' necessario eseguirla su ogni database dell'istanza PostgreSQL]:

  CREATE EXTENSION pgaudit;
  

La configurazione e' terminata!

Utilizzo

L'utilizzo di PGAudit e' molto semplice. In pratica l'auditing a livello di sessione si imposta con pgaudit.log mentre quello a livello di oggetto si imposta con un GRANT...

Vediamo qualche esempio pratico di utilizzo:

Con il primo comando si imposta l'auditing a livello di sessione su tutti gli statement eseguiti su uno specifico database.
Con il secondo gruppo di comandi si imposta l'auditing a livello di sessione su due utenti [NdA non puo' essere impostato su un ruolo ma direttamente sull'utente che esegue la connessione]. E' importante notare che e' possibile indicare piu' impostazioni e che che un "-" indica un esclusione.
Il terzo esempio e' su una tabella specifica e vengono estratti tutti gli accessi con comandi SELECT e DELETE.
L'ultimo esempio attiva l'auditing di ogni statement per la sessione corrente.

Una volta configurato PGAudit e' davvero molto semplice da utilizzare e molto flessibile.

Per verificare la configurazione di audit attiva sugli utenti e' possibile utilizzare la query:

SELECT rolname, rolconfig
  FROM pg_roles
 ORDER BY rolname;

SELECT table_schema, table_name, privilege_type 
  FROM information_schema.role_table_grants 
 WHERE grantee in ('rds_pgaudit', 'auditor')
 ORDER BY table_schema, table_name;

Varie ed eventuali

Ci sono diverse leggi e regolamenti che richiedono l'auditing sull'accesso ai dati: alcune emesse dalle amministrazioni nazionali, altre da organizzazioni finanziarie, altre ancora per ottenere certificazioni ISO. Seguite i link per avere maggiori riferimenti sugli obblighi di legge e sul GDPR.

E' importante sottolineare che i requisiti minimi richiesti dalle normative non si limitano all'audit... I risultati dell'audit vanno anche salvati immediatamente, mantenuti in modo corretto e resi consultabili. Fondamentali sono anche una corretta definizione dei privilegi [NdE basata sul principio del minimo privilegio] e la crittografia [NdE sia sui dati che sulla loro trasmissione].
E' necessario procedere prima ad un assessment tecnico e funzionale della base dati e quindi a provvedere alla messa in sicurezza del database con tutti gli strumenti necessari, tra cui l'audit.
Maggiori informazioni come implementare soluzioni sulle problema di sicurezza in PostgreSQL si trovano in questo documento.

Titolo: Logging ed Auditing per PostgreSQL su RDS
Livello: Medio (2/5)
Data: 14 Febbraio 2021
Versione: 1.0.3 - 31 Ottobre 2022 🎃
Autore: mail [AT] meo.bogliolo.name