CVE: come gestire le vulnerabilità dei database on-premise e cloud

In questo articolo vedremo come abbiamo affrontato la risoluzione della vulnerabilità per uno dei nostri clienti di cui gestiamo 70 installazioni di Postgres su cloud AWS e on-premise. 

Il Contesto

Facciamo un passo indietro per capire insieme a cosa ci riferiamo quando parliamo di CVE.

CVE è un termine appartenente al linguaggio della sicurezza informatica ed è un identificativo standard per documentare e tracciare i bug di sicurezza dei software. All'interno del sistema troviamo informazioni concise e precise per identificare la lista di vulnerabilità che interessano un software, il livello della loro gravità e le indicazioni per risolverle.

Il Problema

Nel nostro caso, ci siamo occupati della gestione della CVE-2024-10979 [1], una vulnerabilità relativa alle variabili d’ambiente in PostgreSQL PL/Perl. Questa falla interessa tutte le versioni di PostgreSQL precedenti alla 17.1 ovvero: 16.5, 15.9, 14.14, 13.17, 12.21. Per risolvere la vulnerabilità, è necessario aggiornare PostgreSQL a una delle versioni corrette che contengono la patch di sicurezza, a seconda della versione in uso. Il livello di gravità della CVE è di 8.8 in una scala che va da 1 a 10, per cui si tratta di un livello di gravità molto elevato.

L'Obiettivo

La gestione delle CVE, in generale, segue un percorso ben preciso e strutturato che inizia con l’analisi della problematica e dell’impatto sui sistemi dei nostri clienti, si articola mediante la stesura di un piano d’azione e culmina nell’implementazione della soluzione consigliata sui sistemi interessati. Il cliente viene sempre coinvolto, perché la sensibilizzare sui problemi relativi alla sicurezza informatica è una parte importante dei servizi che offriamo.

Dopo aver identificato i database interessati nei data center del cliente, sia on-premise che su cloud AWS, abbiamo dunque pianificato gli aggiornamenti in accordo con i fornitori degli applicativi. Per quanto concerne i database on-premise, la roadmap che abbiamo seguito partiva dall’aggiornamento dei sistemi di sviluppo e arrivava ai test, per poi passare in produzione. Questo approccio è stato pensato per permettere ai diversi fornitori di testare gli applicativi congiuntamente agli aggiornamenti dei database, garantendo così la prevenzione di eventuali problemi in ambienti di produzione.

L’aggiornamento dei database che abbiamo eseguito per risolvere la vulnerabilità è un aggiornamento di minor version [2]. Gli aggiornamenti di minor version solitamente contengono fix a basso rischio quali risoluzioni di bug, problemi di sicurezza e data corruption. Nella pratica, il downtime di questo tipo di aggiornamento è breve, nel nostro caso sono stati gestiti in media con un downtime di cinque minuti, dovuto anche alla preparazione delle attività e ai controlli preliminari che sono stati fatti. 

La Soluzione

Per i database del cliente in ambiente cloud AWS, invece, abbiamo riscontrato una problematica in fase di analisi. Negli RDS (Relational Database Service) è abilitata l’opzione Auto minor version upgrade, per cui i database si aggiornano in automatico alla nuova minor version, una volta che questa è stata testata e approvata da AWS [3]. Il problema deriva dal fatto che la minor version approvata non è l’ultima versioni disponibile, cioè quella in cui la CVE è stata risolta. Nel nostro caso, per risolvere la vulnerabilità avremmo dovuto aggiornare i nostri database RDS alle seguenti versioni di PostgreSQL 16.5, 15.9, 14.14, 13.17, 12.21, mentre l’aggiornamento automatico degli RDS si fermava alle versioni 16.3, 15.7, 14.12, 13.15, 12.19. 

Come si deve agire con i CVE e AWS Cloud? 

Essendo Advanced Consulting Partner AWS, con competenze specialistiche certificate, tra cui la AWS Certified Database, ed essendo tra i pochi partner ad avere una validazione Amazon RDS Delivery (visita questa pagina per tutte le nostre Competencies, Validations, Certifications and Programs), abbiamo aperto un case al supporto di AWS per avere un’indicazione ufficiale di come procedere, chiedendo indicazioni sugli eventuali rischi nell’aggiornare manualmente gli RDS ad una versione non inclusa nell’aggiornamento automatico. 

I Risultati

Il supporto ci ha dato parere favorevole nell’aggiornamento manuale alle versioni in cui la CVE è stata risolta. Abbiamo quindi avuto il via libera anche da parte di AWS per eseguire l’aggiornamento manuale alle minor version più recenti rispetto a quelle testate e approvate, dando priorità alla risoluzione della vulnerabilità.

Sebbene il supporto non abbia dichiarato rischi significativi nell'aggiornamento manuale, ci ha raccomandato di seguire sempre le best practice [4], per garantire un processo di aggiornamento regolare. È una raccomandazione che da sempre condividiamo e facciamo ai nostri clienti. Nel dettaglio, li invitiamo a:

• testare l’aggiornamento prima in un ambiente che non sia di produzione, per verificare la compatibilità e assicurarsi che non vi siano problemi imprevisti;
• pianificare l'aggiornamento durante un periodo di traffico ridotto per ridurre al minimo le interruzioni dei servizi.

Abbiamo quindi provveduto ad aggiornare i database alle minor version più attuali, in cui la vulnerabilità è stata risolta, seguendo le best practice suggerite. 

Conclusione

In conclusione, possiamo affermare che siamo riusciti a mettere in sicurezza tutti i database del cliente sia on-premise che in cloud AWS, con il minimo disservizio possibile e prima che la condizione di vulnerabilità potesse dare origine a conseguenze ben più gravi. È giusto ricordare che mantenere i database, e più in generale i sistemi, aggiornati, migliora il livello di sicurezza e pone al riparo da rischi che potrebbero portare a conseguenze gravi, come l’accesso ai sistemi e alle reti, da parte di utenti non legittimati, fino all'installazione di malware e al furto di dati.