Oracle fuori supporto: il database funziona ancora, la sicurezza non è più coperta

Un database Oracle fuori supporto continua a funzionare: il gestionale si apre, gli ordini entrano, le fatture escono. Quello che si ferma sono le correzioni di sicurezza. Le vulnerabilità scoperte dopo la scadenza restano aperte su quel sistema e sono descritte in bollettini pubblici, che chiunque può leggere. Il rischio, quindi, non è un guasto improvviso. È un’esposizione che cresce a ogni bollettino, insieme alle domande di clienti, revisori e assicuratori a cui diventa difficile rispondere.

Scenario tipico. In una società di distribuzione il database del gestionale gira da anni sulla stessa versione. Nessuno lo tocca: funziona, e ogni intervento sembra un pericolo per la chiusura del mese. Poi un cliente importante manda il questionario di sicurezza per i fornitori: «I vostri sistemi ricevono gli aggiornamenti di sicurezza del produttore?». La risposta onesta è no, e il tema arriva sul tavolo della direzione.

Che cosa significa «fuori supporto» per un database Oracle?

Oracle accompagna ogni versione del database con un ciclo di assistenza in tre fasi, descritto nella sua politica di supporto (Lifetime Support Policy):

• Premier Support: correzioni degli errori e patch di sicurezza comprese nel contratto di assistenza;
• Extended Support: per alcune versioni, qualche anno in più di correzioni e patch, a pagamento;
• Sustaining Support: assistenza a tempo indeterminato, ma senza nuove patch.

«Fuori supporto», nel linguaggio comune, è una versione arrivata alla terza fase, oppure un’installazione su cui l’azienda ha smesso di applicare le patch. Il risultato pratico è lo stesso: le vulnerabilità scoperte da quel momento restano aperte.

Oracle lo scrive in ogni bollettino: le patch di sicurezza sono fornite solo per le versioni coperte da Premier Support o da Extended Support. E ricorda che alcuni attacchi sono riusciti perché i clienti colpiti non avevano applicato patch già disponibili.

Quali versioni ricevono ancora le patch?

La tabella riassume le date pubblicate da Oracle per le versioni più diffuse.

La 26ai, presentata nell’ottobre 2025, ha preso il posto della 23ai.

Le patch seguono un calendario pubblico. Le correzioni cumulative trimestrali (Critical Patch Update) escono il terzo martedì di gennaio, aprile, luglio e ottobre: l’ultima è del 21 luglio 2026, la prossima è annunciata per il 20 ottobre. Dal 28 maggio 2026 Oracle pubblica anche aggiornamenti di sicurezza mensili negli altri mesi (Critical Security Patch Update). Chi resta su una versione senza copertura non riceve né gli uni né gli altri.

Perché un database senza patch è più esposto a ogni bollettino?

Ogni bollettino di Oracle elenca le vulnerabilità corrette, con il loro codice CVE (il numero con cui una vulnerabilità viene registrata e resa pubblica), il prodotto coinvolto e la gravità. Per chi aggiorna è un promemoria. Per chi cerca sistemi da attaccare è una mappa: basta sapere quale versione risponde su un server per capire quali falle sono rimaste aperte.

• L’esposizione cresce anche se in azienda non cambia nulla. Ogni nuovo bollettino aggiunge vulnerabilità che su quella versione non verranno corrette.
• Le vulnerabilità note sono tra le più usate negli attacchi. L’agenzia statunitense per la sicurezza informatica (CISA) tiene un catalogo pubblico di quelle già sfruttate in attacchi reali, proprio perché la prima difesa è chiuderle.

Un database raramente è raggiungibile da internet, ma lo è da server applicativi, postazioni e account di servizio che possono essere compromessi. Chi entra nella rete cerca proprio i sistemi rimasti indietro con gli aggiornamenti.

Che cosa chiedono norme, clienti e assicurazioni?

Nessuna norma elenca le versioni di database ammesse. Le regole chiedono di gestire il rischio e di saper dimostrare le scelte fatte, e un sistema senza patch lo rende più difficile.

• NIS2 in Italia. Il D.Lgs. 138/2024, che recepisce la direttiva NIS2, chiede ai soggetti essenziali e importanti misure di gestione dei rischi che riguardano anche la manutenzione dei sistemi, «ivi comprese la gestione e la divulgazione delle vulnerabilità» (art. 24, comma 2, lettera e). Un database senza patch non comporta in automatico una sanzione, ma la scelta va motivata con una valutazione del rischio e con misure che compensino l’assenza di aggiornamenti.
• Catena di fornitura. Lo stesso articolo chiede di curare la sicurezza dei rapporti con i fornitori (lettera d). Per questo le aziende soggette alla NIS2 mandano questionari ai propri fornitori, e tra le domande tipiche c’è quella sugli aggiornamenti di sicurezza.
• Dati personali. Il GDPR chiede misure di sicurezza adeguate al rischio, da scegliere «tenendo conto dello stato dell’arte» (art. 32). Un sistema con vulnerabilità note e non corrette fatica a rientrare in questa definizione.
• Assicurazioni. Se una polizza cyber si sottoscrive dopo un questionario sulla sicurezza, le risposte contano: in Italia le dichiarazioni inesatte del contraente possono ridurre l’indennizzo o, nei casi più gravi, rendere annullabile il contratto (articoli 1892 e 1893 del Codice civile). Alcune polizze possono anche prevedere condizioni sui sistemi non aggiornati.

Per le imprese sammarinesi il quadro è diverso: va valutato caso per caso.

Che cosa si può fare se l’aggiornamento non è possibile subito?

A volte l’aggiornamento non si può fare domani: il gestionale non è ancora certificato, c’è una chiusura di bilancio, manca una finestra di intervento. Allora si riduce l’esposizione, con misure temporanee che non sostituiscono le patch.

1. Restringere chi può raggiungere il database: solo i server applicativi e le postazioni di amministrazione, con regole di rete scritte e verificate.
2. Mettere ordine nelle utenze: via gli account inutilizzati e quelli condivisi, password predefinite cambiate, privilegi ridotti al necessario.
3. Registrare gli accessi: attivare il tracciamento (audit) delle operazioni sensibili e far leggere i registri a una persona incaricata, a scadenze fisse.
4. Provare il ripristino: una prova a calendario, con il tempo necessario a ripartire scritto in un verbale.
5. Isolare ciò che non si può aggiornare: se una vecchia applicazione vincola la versione, la si separa dal resto della rete.
6. Fissare una data: queste misure servono a guadagnare tempo, e quel tempo va speso per un piano di uscita con una scadenza scritta.

Per la 19c, dopo dicembre 2029, Oracle prevede l’Extended Support a pagamento fino a dicembre 2032. Sposta la scadenza, e va confrontato con un aggiornamento pianificato. Per 11g, 12c e 18c questa strada non c’è più.

Come si pianifica l’uscita senza fermare il gestionale?

Un aggiornamento ben preparato segue una sequenza che anche la direzione può controllare passo per passo.

1. Fotografia dell’esistente: versione e livello delle patch, edizione, opzioni installate, applicazioni collegate, elaborazioni notturne, volumi.
2. Verifica con il produttore del gestionale: su quali versioni di Oracle l’applicazione è certificata. È il vincolo che più spesso decide i tempi.
3. Scelta della destinazione: la 19c, con le patch comprese fino a dicembre 2029, oppure la 26ai, coperta fino a dicembre 2031. Alla 26ai si arriva direttamente solo dalla 19c o dalla 21c: da versioni più vecchie si passa da una versione intermedia, oppure si trasferiscono i dati in un database nuovo. Inoltre, dalla 21c Oracle supporta soltanto l’architettura multitenant, in cui ogni database è ospitato dentro un contenitore: chi arriva da una 19c organizzata in modo tradizionale deve prevedere la conversione.
4. Prove su una copia: aggiornamento, verifiche applicative, confronto dei tempi delle interrogazioni più importanti.
5. Finestra concordata e rientro previsto: il passaggio si fa in un orario deciso con chi usa il sistema, con una copia verificata alle spalle e un piano per tornare indietro se una verifica non torna.

Quando il fermo deve essere minimo, una replica tiene allineato il nuovo database mentre il vecchio lavora, e il passaggio si riduce a una finestra breve. Date e versioni aggiornate sono nel riquadro Versioni e scadenze.

In sintesi

• Un database Oracle fuori supporto funziona, ma le vulnerabilità scoperte dopo la scadenza restano aperte.
• Ricevono patch la 19c (fino a dicembre 2029, poi a pagamento fino al 2032), la 21c (fino a luglio 2027) e la 26ai (fino a dicembre 2031); 11g, 12c e 18c non più.
• NIS2, GDPR, clienti e assicuratori non vietano una versione, ma chiedono di gestire il rischio e di saperlo dimostrare.
• Se non si può aggiornare subito, si riduce l’esposizione e si fissa una data di uscita.
• L’aggiornamento parte dalla certificazione del gestionale e si prova su una copia.

Domande frequenti

Un database Oracle fuori supporto smette di funzionare?

No. Il software lavora come prima e Oracle offre ancora assistenza tecnica, ma senza nuove patch: vulnerabilità ed errori scoperti dopo la scadenza non vengono più corretti per quella versione.

La 19c è ancora una scelta sicura?

Sì, se le patch vengono applicate con regolarità. La 19c è una versione a lungo termine, con Premier Support fino a dicembre 2029 ed Extended Support a pagamento fino a dicembre 2032. Conviene comunque preparare per tempo il passaggio alla 26ai, a partire dalla verifica della certificazione del gestionale.

Conviene passare direttamente alla 26ai?

Dipende dal punto di partenza e dal gestionale. La 26ai ha la copertura più lunga, ma si raggiunge direttamente solo dalla 19c o dalla 21c e richiede l’architettura multitenant e la certificazione delle applicazioni. Il percorso si decide dopo una prova su una copia.

Si può restare su una versione vecchia pagando un supporto esteso?

Solo finché la politica di Oracle lo prevede. Per la 19c l’Extended Support a pagamento arriva fino a dicembre 2032. Per 11g, 12c e 18c il periodo di Extended Support è terminato: su quelle versioni non arrivano più le patch di sicurezza di Oracle.

Aggiornare un database senza fermare l’azienda è il lavoro della nostra divisione Oracle & Database Engineering: fotografia di versioni e licenze, piano di aggiornamento, prove su una copia e passaggio nella finestra concordata. Quando il database rientra in una verifica di sicurezza più ampia, lavoriamo insieme alla divisione Cybersecurity.

Fonti

• Oracle, Lifetime Support Policy: Oracle Technology Products, date di supporto di Oracle Database
• Oracle, Critical Patch Update Advisory, July 2026, pubblicato il 21 luglio 2026
• Oracle, Critical Security Patch Update Advisory, May 2026, pubblicato il 28 maggio 2026
• Oracle, Oracle AI Database 26ai Powers the AI for Data Revolution, 14 ottobre 2025
• Oracle, Database Upgrade Guide 23ai, versioni che consentono l’aggiornamento diretto
• Oracle, Database Upgrade Guide 21c, aggiornamento dei database non-CDB all’architettura multitenant
• CISA, Known Exploited Vulnerabilities Catalog
• D.Lgs. 4 settembre 2024, n. 138, art. 24, Normattiva
• Regolamento (UE) 2016/679 (GDPR), art. 32, EUR-Lex
• Codice civile, art. 1892, Normattiva