Problematiche di sicurezza su database
PostgreSQL

I database mantengono i principali dati aziendali e debbono essere adeguatamente protetti.
Questa breve pagina riporta le problematiche piu' diffuse per quanto riguarda le basi dati ed i piu' comuni errori sulla sicurezza dei database ma sopratutto... indica come risolverle con il database PostgreSQL!

Nel seguito sono riportate le informazioni di interesse organizzate in paragrafi specifici: Introduzione, Matrice delle soluzioni, Controllo accessi, Controllo SQL, Protezione dati, Configurazione sicura, Varie ed eventuali.

Introduzione

Le piu' recenti normative per la sicurezza dei dati hanno posto l'attenzione di tutte le aziende sulla protezione dei dati: GDPR (General Data Protection Regulation, per la protezione dei dati personali), SOX (Sarbanes-Oxley Act of 2002, per la protezione dei dati finanziari), PCI-DSS (Payment Card Industry Data Security Standard, standard internazionale a protezione dei dati delle carte di credito), HIPAA (Health Insurance Portability and Accountability Act, legge USA a protezione dei dati personali e sanitari), ...

I database mantengono i principali dati aziendali e debbono essere adeguatamente protetti. Questo documento presenta quelli che sono le problematiche di sicurezza piu' comuni relativamente ai database e come possono essere risolte. A seconda dei casi verranno presentate soluzioni introducendo Best Practice di programmazione o di progettazione, utilizzando funzionalita' standard PostgreSQL o utilizzando strumenti e pacchetti esterni.

Tra i molti elenchi di problematiche da cui partire... ne abbiamo scelto uno italiano che ha anche il pregio di avere le virtu' Calviniane dell'esattezza e della rapidita'. L'elenco sulle problematiche di sicurezza piu' comuni per i database e' quello contenuto nel Rapporto 2016 preparato dal Clusit (Associazione Italiana per la Sicurezza Informatica) su aziende italiane ed e' quindi uno specchio reale della situazione presente nella maggioranza delle imprese.

Le problematiche emerse nella ricerca sono state suddivise nelle seguenti categorie:

• DB Access Control
  Definizione dell'accesso ai dati ai soli utenti autorizzati e controllo di quando, dove e come i dati sono acceduti.
• Monitoring / Blocking and Audit
  Analisi delle transazioni che avvengono sulla base dati ed visualizzazione le attivita' correnti e storiche
• Data Protection
  Processi e controlli sulla trasmissione, sull'accesso e la memorizzazione delle informazioni per tutto il ciclo di vita dei dati.
• Secure Configuration
  Processi e controlli per garantire la corretta configurazione dei Database

Nel resto del documento analizzeremo le tecnologie disponibili in PostgreSQL per risolvere le problematiche di sicurezza dei dati su ciascuna delle categorie citate.

Matrice delle soluzioni

La tabella seguente riporta come approcciare le diverse problematiche di sicurezza con PostgreSQL. Nella tabella si fa riferimento alle funzionalita' presenti nell'ultima versione 10.x [NdA il documento e' stato aggiornato alla versione 15.x] ma quando significativo si citeranno anche le versioni precedenti ed edizioni commerciali.
La matrice e' volutamente sintetica e riassuntiva. E' importante sottolineare che molte problematiche non possono essere solo risolte a livello di tecnologia ma richiedono un preciso processo aziendale. La tabella riporta se il DB fornisce un supporto per gestire la problematica, quanto il supporto e' completo e se sono necessari componenti esterni o opzionali.

Dalla tabella e' chiaro che molti dei punti sono da gestire con processi o con strumenti esterni al Database. Quando la problematica riguarda il database il supporto fornito da PostgreSQL e' sempre adeguato.
Nei prossimi capitoli vengono riportati maggiori dettagli su ciascuna delle soluzioni tecniche disponibili in PostgreSQL.

DB Access Control

Per il principio del minimo privilegio (least privilege) vanno utilizzate le utenze con i diritti minori possibili per svolgere le diverse attivita'. Questo e' particolarmente importante per le utenze applicative che debbono svolgere tipicamente solo operazioni CRUD, a cui non servono i privilegi per operazioni di DDL e sono tipicamente maggiormente soggette ad attacchi e meno protette. E' quindi necessario che le utenze utilizzate dagli Application Server o dai Web Server non siano proprietarie dello schema dati.

Sono molteplici le soluzioni tecnologiche fornite da PostgreSQL per quanto riguarda il controllo degli accessi:

• No distinction between Application User and Schema Owner (AC1)

  E' importante separare le utenze che sono proprietarie degli oggetti rispetto alle utenze con cui si connettono gli Application Server. Su PostgreSQL vi sono due livelli per abilitare gli accessi: il file pg_hba.conf (HBA: host-based authentication) ed i GRANT SQL. Combinando correttamente le abilitazioni si possono impostare verifiche approppriate per ogni rete di provenienza.
  La definizione dei GRANT spesso si fa a livello dell'intero database semplificando la gestione, come in questo esempio:

  GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA dbApp TO ApplicationUser;
  GRANT SELECT ON dbApp.emp TO EndUser;
  

  Per evitare di dover premettere il nome dello schema alle tabelle viene tipicamente impostato il search path con
  SET search_path TO dbApp;

  A questo punto l'accesso ai dati e' trasparente e l'utente vede gli oggetti con i diritti che gli sono stati autorizzati con i normali comandi SQL:

  psql --username EndUser SELECT * from emp;

  PostgreSQL dispone dei ruoli [NdA dalla versione 8.1 ROLES e USERS sono sinonimi] ed ha una completa gestione dei grant basata su una logica objet oriented: possono essere definite politiche di accesso molto sofisticate.

  Oltre ai GRANT standard dell'SQL, Postgres, dalla versione 9.5, consente di definire delle policy per impostare la row-level security. Le policy sono definite a livello di tabella e permettono di definire regole in lettura e/o in scrittura sulle tabelle.

• No lifecycle management for DB users (AC7)

  PostgreSQL permette la gestione delle abilitazioni delle utenze con la creazione di utenti e ruoli:

  CREATE ROLE scott WITH LOGIN
    PASSWORD 'xxx'
    CONNECTION LIMIT 5
    VALID UNTIL '2018-05-25';
  
  SET LOCAL configuration_parameter = 'value';
  

  Non e' possibile indicare l'expiration della password ma si puo' solo definire una scadenza [NdA alcuni fork come EDB Postgres Advanced Server e Postgres Pro forniscono una gestione piu' completa delle scadenze delle password con PROFILE simili a quelli Oracle].
  PostgreSQL ha una completa gestione della proprieta' degli oggetti con utenti e ruoli. E' generalmente semplice impostare una corretta politica del minimo privilegio. Le impostazioni iniziali dell'utente sono riportate in pg_user.useconfig.

• OS administrators can escalate their privileges to DBA (AC8)

  Le utenze del sistema operativo e quelle della base dati sono separate in PostgreSQL. Per default l'utenza postgres ha privilegi amministrativi ed e' autorizzata con peer o trust nel file pg_hba.conf. E' fortemente consigliato impostare una password per l'utente postgres e richiederla esplicitamente impostando il metodo md5 [NdA dalla versione 10 e' disponibile lo SCRAM-SHA-256 che e' molto piu' sicuro]. Tuttavia, per un amministratore di sistema esperto, e' tecnicamente possibile modificare la configurazione di PostgreSQL e disabilitarne i controlli...
  Vanno considerati utenti privilegiati sul DB anche gli amministratori del sistema operativo. E' necessario utilizzare utenze personali anche per gli utenti amministratori del sistema e non solo per i DBA; deve essere presente un preciso auditing delle attivita' anche a livello di sistema operativo. Non e' mai necessario che un DBA PostgreSQL diventi root di SO.

• DBAs have full access to users' data (AC9)

  Le utenze amministrative in PostgreSQL hanno accesso a tutti i dati e non e' possibile escludere tale diritto. La crittografia applicativa e l'auditing sono le uniche soluzioni.

Le altre problematiche riportate in questa categoria vengono risolte definendo ed applicando opportune policy di sicurezza.
Ad esempio non ci sono ragioni tecniche su PostgreSQL per far utilizzare l'utenza applicativa agli sviluppatori negli ambienti di produzione. Una corretta definizione degli ambienti (eg. sviluppo, collaudo, produzione) e delle procedure per la messa in esercizio delle applicazioni e' necessaria per disporre di sistema sicuro nel suo complesso.

Monitoring / Blocking and Audit

Sono molteplici le soluzioni tecnologiche fornite da PostgreSQL per quanto riguarda il monitoraggio delle attivita' correnti sulla base dati (eg. pg_stat_activity).
E' inoltre consigliabile installare l'estensione pg_stat_statements poiche' fornisce utili dettagli sia per l'analisi delle prestazioni che per il controllo degli statement SQL.

• No preventive SQL controls (LG1)

  Un problema comune nelle applicazioni web e' l'SQL injection, una forma di attacco che arriva direttamente al database.

  Per quanto riguarda il controllo preventivo dell'SQL questo puo' essere realizzato con proxy esterni all'RDBMS. Tali soluzioni con diversi livelli di sofisticazione e specializzazione sono esterne al DB (eg. i WAF: Web Application Firewall, gli IDS: Intrusion Detection System). E' molto semplice creare dati civetta o honeypot in un database PostgreSQL.

• No or partial and inconsistent logs (LG2)

  Il logging di PostgreSQL e' molto completo e flessibile. Il log sono disponibili come file a livello di sistema operativo oppure rediretti su syslog. Una descrizione completa e' contenuta in questo documento.

  La raccolta e la securizzazione dei log e' tipicamente realizzata dal SIEM (Security Information and Event Management) aziendale.

• Logs are not managed (LG4)

  Processo esterno al DB. E' tipicamente compito di un SIEM...
  In ogni caso se si utilizza il logging su file e' possibile definire politiche di ritenzione e/o rotazione dei log.

• No DB user accountability (LG5)

  Oltre all'auditing e' possibile utilizzare i trigger per monitorare selettivamente le modifiche occorse su tabelle con dati critici. Un semplice esempio e' riportato in questa pagina. Dalla versione 9.5 e' disponibile l'estensione pgAudit [NdA descritto con maggior dettaglio in questa pagina].

• No end user accountability (LG6)

  Va utilizzato lo strumento di auditing pgAudit gia' riportato nel punto precedente. E' inoltre importante aver definito precise politiche di gestione delle utenze personali.

Data protection

Sono molteplici le soluzioni tecnologiche fornite da PostgreSQL per quanto riguarda la protezione dei dati:

• Applications do not encrypt (DP1)

  Anche se si tratta di un processo esterno alla base dati PostgreSQL fornisce un ampio insieme di funzioni di crittografia nell'extension pgcrypto. E' un'estensione standard, disponibile su tutte le piattaforme, su tutte le versioni PostgreSQL e con la stessa licenza (sempre gratuita). Abilitarla da SQL su un database e' molto semplice:

  create extension pgcrypto;

  Quali dati e con quali algoritmi crittografare va analizzato in modo adeguato. Per iniziare e' possibile adattare alcuni semplici script SQL per estrarre dal DB le tabelle e le colonne da verificare: andranno crittografate tutte le colonne che contengono dati critici. Da questo punto di vista e' molto importante la conoscenza del dato.

  Una panoramica sulle funzioni di crittografia disponibili a livello di database ed a quale livello sono applicabili e' contenuto in questo documento.

• No datafile encryption (DP2)

  Postgres non fornisce la data encryption at-rest; e' possibile utilizzare la crittografia a livello di storage (eg. LUKS).

  Sono disponibili alcune distribuzioni Enterprise di Postgres in cui il TDE e' disponibile. Inoltre la maggioranza dei fornitori di servizi Cloud che offre servizi su Postgres implementa la crittografia sui datafile.

• No network encryption (DP4)

  La crittografazione delle comunicazioni tra client e DB server e' molto importante. PostgreSQL supporta da sempre l'SSL per la crittografazione dei dati trasmessi con i client.

  La configurazione e' relativamente semplice poiche' richiede la creazione o l'installazione di un certificato server sul DB server e di un singolo parametro (ssl=on) nel file postgres.conf. Ulteriori parametri sono disponibili nel file openssl.cnf, ma generamente i default sono sufficienti. Una volta configurato e' necessario indicare sul server e sul client se la crittografazione della trasmissione dei dati e' opzionale, obbligatoria, ... scegliendo tra i possibili valori: disable, allow, prefer, require, verify-ca, verify-full. Lato DB Server l'obbligatorieta' della crittografazione si imposta sul file pg_hba.conf sostituendo la direttiva host con hostssl.

  Per effettuare una connessione utilizzando la crittografia:

  $ psql "service=myservice sslmode=require"

  Maggiori dettagli sulla configurazione e sui controlli effettuabili si trovano in questo documento.

• No backup / export encryption (DP5)

  Con PostgreSQL e' semplice effettuare la crittografazione dell'output dei comamandi di backup logico da linea di comando. In un ambiente di produzione si consiglia l'utilizzo di una chiave asimmetrica; in questo modo sul DB server viene utilizzata la sola chiave pubblica ed il contenuto in chiaro potra' essere ottenuto solo da chi possiede la chiave privata.
  La crittografazione puo' essere aggiunta facilmente:

  # Generazione della chiave (NB su un ambiente sicuro)
  openssl req -x509 -nodes -newkey rsa:2048 -keyout key.priv.pem -out key.pub.pem
  
  # Effettuazione del backup
  pg_dump mydb | openssl smime -encrypt -binary -text -aes256 -out db.sql.enc -outform DER key.pub.pem
  

• Production data copied to development environments (DP6)

  Una possibile soluzione e' quella di creare uno schema di appoggio contenenti i soli dati non personali/sensibili oppure modificare "al volo" i dati. Per farlo e' possibile utilizzare strumenti di ETL (eg. Pentaho Kettle), tool, proxy che effettuino SQL injection o script SQL standard.

• Unnecessary data are not hidden/masked (DP7)

  Con viste, sinonimi ed opportuni GRANT da PostgreSQL e' possibile mascherare i dati non necessari:

  create view emp_rest as
  select EMPNO, ENAME, JOB,
         MGR, HIREDATE, 0 SAL, 0 COMM, DEPTNO
    from emp;
  

  Dalla versione 15 e' possibile indicare nelle viste la modalita' di verifica dei privilegi (security_invoker).
  La maggior difficolta' pero' e' nell'analisi che richiede competenze sui dati/applicazioni e spesso non viene eseguita.

  Alcuni fork forniscono da tempo la funzionalita' di data redaction (eg. EDB). Piu' recente e' la disponibilita' dell'estension PostgreSQL Anonymizer (anon). Oltre che sui repository ufficiali Postgres viene fornita anche da diversi DBaaS in Cloud.

Secure Configuration

PostgreSQL da sempre ha tenuto in forte considerazione gli aspetti di sicurezza e tutte le versioni hanno configurazioni di default sicure.

• Obsolete DB / OS releases (SC1)

  Le procedure di upgrade di PostgreSQL sono ben definite ed il calendario delle release supportate e' ben noto. Le prime due cifre della versione indicano una major version (eg. 9.6) con nuove funzionalita', la terza cifra indica l'ultimo update che occorre con cadenza tipicamente trimestrale. In realta' con la versione 10 questa politica e' cambiata e la major version e' indicata solo dalla prima cifra (eg. 10) mentre la seconda cifra indica una minor release (eg. 10.4).
  Tipicamente si ha una major version ogni anno mentre le minor releases vengono emesse il secondo giovedi di febbraio, maggio, agosto e novembre. In caso di bug o gravi problemi di sicurezza vengono emesse ulteriori minor release.
  Le differenze, dal punto di vista applicativo, tra versioni PostgreSQL sono molto limitate. L'upgrade di PostgreSQL non richiede generalmente un effort significativo. E' comunque opportuno che venga definito un processo aziendale di aggiornamento delle releases e che siano previste finestre periodiche di manutenzione.

  Sono supportate le release 17, 16, 15, 14, 13, 12. Le release precedenti non vanno utilizzate.

  L'aggiornamento del sistema operativo e' esterno al DB, ma ugualmente importante.

• No DB / OS hardening (SC2)

  Le impostazioni di default di PostgreSQL sono sicure ma vanno comunque verificate con attenzione.

  E' importante raccogliere periodicamente le configurazioni ed i dati sull'utilizzo degli ambienti. La raccolta di tali informazioni non e' solo utile per le attivita' sistemistiche, ma anche per la sicurezza degli ambienti: senza una baseline e' impossibile qualsiasi analisi.

  Agli utenti va applicato il principio del minimo privilegio e vanno verificati tutti i grant di privilegi amministrativi. Come applicazione del principio del minimo privilegio e' sicuramente opportuno eseguire il seguente comando:

  REVOKE CREATE ON SCHEMA public FROM PUBLIC;
  

  L'accesso a public e la possibilita' di creare oggetti sono spesso sfruttati come privilege escalation [NdA il comando indicato non funziona su alcune configurazioni in cloud perche' l'owner dello schema e' differente (eg. Amazon RDS per l'utente rdsadmin), in questo caso e' comunque possibile revocare il privilegio dopo aver eseguito ALTER SCHEMA public OWNER TO userX;]...
  Dalla versione 15 non e' piu' necessario il revoke indicato perche' il grant non e' piu' presente e solo l'utente proprietario del database o i superadmin possono creare oggetti nello schema PUBLIC.
  Su PostgreSQL la profilazione degli accessi dalla rete e' molto semplice (si effettua nel file pg_hba.conf) ed e' buona norma sia eseguita con le opportune restrizioni.
  Utili sono i controlli riportati nelle STIG (Security Technical Implementation Guides) dello IASE (Information Assurance Support Environment) che e' un ente del DoD (Department of Defense degli USA). E' significativo riportare che EnterpriseDB Postgres Advanced Server ha uno STIG differente e pubblicato molto prima anche perche' ha diverse importanti funzionalita' di sicurezza aggiuntive rispetto alla versione community. Molto completi sono i controlli riportati nei CIS Benchmark [NdA sono disponibili solo dal 2018-2019 ma molto precisi come per gli altri RDBMS].
  Non va dimenticato infine il controllo delle password!

  Nella documentazione ufficiale PostgreSQL si trovano le Security Information che riportano i riferimenti delle vulnerabilita' scoperte ed i dettagli delle versioni che ne sono colpite. Poiche' lo sviluppo e' separato e' importante anche verificare i Security Advisories dei driver JDBC.

  L'hardening dell'OS e' esterno al DB, ma ugualmente importante, tra i molti strumenti utili sono fondamentali la verifica delle permission, il logging ed i filtri iptables. Fondamentale e' anche la protezione degli accessi da rete con un Firewall; negli ambienti enterprise si adottano tipicamente anche IDS/IPS (Intrusion Detection Systems/Intrusion Prevention Systems) e WAF (Web Application Firewall). La configurazione di tali strumenti per proteggere i DB PostgreSQL e' generalmente semplice ma dipende dalla configurazione presente.

• No patching (SC3)

  PostgreSQL emette patch (minor release) con cadenza trimestrale a meno di fixing piu' urgenti. L'applicazione delle minor releases, oltre ad essere fortemente consigliata, non presenta tipicamente difficolta': e' rapida e non richiede adeguamenti nelle applicazioni; e' solo necessario il riavvio della base dati.
  Le attivita' di patching di PostgreSQL vanno inserite nel processo aziendale di aggiornamento e manutenzione degli ambienti.

  E' sempre consigliabile l'applicazione dell'ultima minor release disponibile per la versione in uso. E' fortemente consigliabile l'utilizzo delle versioni 12.18, 13.14, 14.11, 15.6, 16.2 o successive poiche' le versioni precedenti presentano vulnerabilita' con CVSS score elevato (eg. Details CVE-2024-1597, Details CVE-2024-0985, Mitre CVE-2022-2625, Postgres CVE-2022-1552, Mitre CVE-2022-1552, Mitre CVE-2020-25695, Mitre CVE-2019-10164, Mitre CVE-2018-1058, CVE Details).
  E' invece fortemente sconsigliato l'utilizzo di versioni precedenti alla 12 compresa poiche' non sono piu' supportate e quindi non ricevono aggiornamenti sulla sicurezza [NdA per le precedenti versioni utilizzare almeno: 11.22, 10.21, 9.6.20, 9.5.12, 9.4.17, 9.3.22, 9.2.24, 9.1.9, 9.0.14, 8.4.17].

Varie ed eventuali

Va sottolineato che, delle attivita' di messa in sicurezza evidenziate, solo alcune sono legate all’acquisto di nuovi prodotti. Spesso per risolvere la maggioranza delle problematiche e' sufficiente un buon uso di PostgreSQL e l'applicazione di adeguati processi aziendali, il tutto dopo una corretta e completa analisi di sicurezza.

Va riportato che l'importanza e la complessita' della materia sono notevoli gli interventi di messa in sicurezza di PostgreSQL vanno quindi approcciati con la necessaria competenza ed esperienza.

Tra gli strumenti utili per la raccolta delle configurazioni di sistema e dei dati prestazionali: ux2html (raccolta configurazione sistemi Unix/Linux), pg2html (raccolta configurazione PostgreSQL), dashboard con Grafana.

Sono disponibili documenti relativi agli aspetti pratici di sicurezza sui database anche per Oracle e MySQL.

Titolo: Risolvere gli errori di sicurezza sui database PostgreSQL
Livello: Medio (2/5)
Data: 31 Ottobre 2017 🎃 Halloween
Versione: 1.0.7 - 14 Febbraio 2024 ❤️
Autori: mail [AT] meo.bogliolo.name