L’email è arrivata mesi fa. “End of Support per Oracle Database 11g/12c.” L’IT l’ha letta, ha alzato le spalle, e ha continuato a fare quello che fa ogni giorno: tenere in piedi un sistema che funziona. Nessun errore, nessun rallentamento, nessun ticket. Il ragionamento è sempre lo stesso: “se non è rotto, non lo tocco.” Ed è esattamente qui che si sbaglia.
Un database Oracle fuori supporto non smette di funzionare il giorno dopo la scadenza. Continua a girare, a rispondere alle query, a servire l’applicazione gestionale, l’ERP, il portale clienti. Il problema non è tecnico nell’immediato. È che da quel momento Oracle smette di rilasciare patch di sicurezza per quella versione. Le vulnerabilità che verranno scoperte dopo — e ne vengono scoperte, con regolarità, su ogni versione di ogni prodotto — resteranno aperte per sempre, su quel sistema.
Cosa cambia davvero il giorno dell’EOL
Non cambia niente nell’interfaccia. Cambia tutto nel rischio. Le Critical Patch Update trimestrali di Oracle non arriveranno più per la tua versione. I CVE pubblicati da quel momento in poi resteranno documentati, pubblici, consultabili da chiunque — compreso chi cerca sistemi da colpire. Non serve un attacco mirato: bastano scanner automatici che verificano quali porte rispondono e quale versione di database c’è dietro.
Chi gestisce infrastrutture critiche lo sa bene: un sistema fuori supporto è un sistema con vulnerabilità note e documentate, senza rimedio. Non è una minaccia teorica. È un dato di fatto che qualunque pen-test serio evidenzia nei primi cinque minuti.
Il mito del “funziona ancora”
“Funziona ancora” è il modo in cui un rischio si traveste da normalità. Un database Oracle non aggiornato può girare per anni senza incidenti — fino al giorno in cui non lo fa più, e a quel punto il problema non è più solo tecnico. È un data breach, un fermo produzione, un incidente da notificare. E in quel momento, la domanda che arriva prima da tutti — clienti, assicurazione, autorità — è sempre la stessa: “sapevate che il sistema era fuori supporto?” Sì, lo sapevate. C’era un’email.
Compliance: l’EOL non è più una scelta interna
Con NIS2 in vigore, per i soggetti essenziali e importanti la gestione del ciclo di vita dei sistemi non è più un’opzione da valutare a piacimento. Un database fuori supporto, senza patch di sicurezza, è una non conformità che un audit ISO 27001 individua senza fatica — e che un’ispezione NIS2 può trasformare in una sanzione o in una richiesta di rimedio immediato.
Chi ha certificazioni da mantenere, chi lavora con la PA, chi tratta dati sanitari o finanziari, sa che il tema non è più “vogliamo aggiornare?” ma “possiamo dimostrare di essere conformi?”. E su un Oracle EOL, la risposta è no.
Cosa succede in concreto se rimandi
- Nessuna patch di sicurezza per nuove vulnerabilità, per sempre.
- Superficie d’attacco che cresce ogni trimestre che passa, senza che nulla lo segnali dall’interno.
- RTO e RPO che diventano teorici: se il sistema va giù per un exploit noto, il piano di disaster recovery si scontra con una versione che nessuno sa più ripristinare in sicurezza.
- Audit di compliance falliti, con richieste di remediation a tempi stretti e costi non pianificati.
- Contratti assicurativi cyber a rischio: molte polizze escludono la copertura su sistemi fuori supporto al momento dell’incidente.
Perché nessuno se ne accorge finché non è tardi
I team interni sono bravi a tenere in piedi i sistemi. Sono meno abituati a pianificare la loro fine. La migrazione di un database Oracle in produzione — con dipendenze applicative, job schedulati, integrazioni con terzi — richiede competenze specifiche e tempo, due cose che spesso mancano proprio a chi deve occuparsi anche dell’ordinaria amministrazione. Il risultato è che la migrazione slitta, e slitta ancora, finché l’EOL non è più una data futura ma un fatto già accaduto.
Noi lo vediamo spesso: aziende che arrivano da noi non perché hanno subito un incidente, ma perché un audit — interno o di un cliente — ha acceso la spia. A quel punto il problema non è più “aggiorniamo quando abbiamo tempo”, ma “quanto ci mette Strategic a farlo senza fermare la produzione?”
Come si affronta seriamente
Un piano di migrazione Oracle serio parte da un assessment tecnico: versione attuale, dipendenze applicative, volumi, finestre di manutenzione disponibili. Poi si costruisce un percorso — verso una versione supportata on-premise o verso il cloud — con DBA certificati che gestiscono backup, tuning e cutover senza sorprese. Non è un progetto che si improvvisa in un weekend, ma non è nemmeno il progetto pluriennale che molti temono: con il team giusto, i tempi si comprimono drasticamente.
La domanda da farsi non è se l’EOL sia un problema reale. Lo è. La domanda è quanto tempo vuoi lasciare tra l’avviso e l’azione — e chi vuoi che scopra la risposta al posto tuo.
