Il gestionale non si è mai fermato. L’ultimo riavvio non programmato nessuno se lo ricorda. Il fornitore che l’ha installato è andato in pensione. E quando chiedi chi controlla i log di quel sistema, la risposta è un silenzio imbarazzato.
Se lavori in un’azienda che ha un IBM i — quello che quasi tutti continuano a chiamare AS/400 — questa scena ti è familiare. È la macchina su cui gira la produzione, la fatturazione, il magazzino. È anche l’unica in azienda di cui nessuno parla mai nelle riunioni sulla sicurezza.
Non è un caso. È esattamente il problema.
Il paradosso dell’affidabilità
L’IBM i si è guadagnato sul campo la fama di piattaforma solida: architettura a oggetti, integrazione fra sistema operativo e database, retrocompatibilità che attraversa i decenni. Un’applicazione scritta negli anni Novanta gira ancora oggi, spesso senza una riga modificata.
Questa affidabilità ha però prodotto un effetto collaterale: ha reso il sistema invisibile. Ciò che non si rompe non chiede attenzione, e ciò che non chiede attenzione esce dal radar. Nel frattempo, intorno a quella macchina, sono cambiati la rete, le modalità di accesso, il perimetro aziendale e il panorama delle minacce.
Il risultato è una piattaforma tecnicamente robusta, configurata secondo criteri di vent’anni fa, collegata a una rete del 2026.
I numeri, prima delle opinioni
L’IBM i Marketplace Survey 2026 di Fortra fotografa bene lo scarto fra percezione e pratica: il 64% dei responsabili IBM i indica la cybersecurity fra le principali preoccupazioni, ma solo il 42% ha effettivamente in campo protezioni antivirus e anti-ransomware sulla piattaforma. Nell’edizione precedente, su 250 rispondenti, la preoccupazione saliva al 77% a fronte di un 40% di adozione.
Due terzi del settore sa di avere un problema. Meno della metà lo ha affrontato.
Sul fronte opposto, l’IBM X-Force Threat Intelligence Index 2026 segnala che lo sfruttamento delle vulnerabilità è diventato la prima causa di attacco, con il 40% degli incidenti osservati nel 2025, e registra un aumento del 44% degli attacchi che partono da applicazioni esposte. Gli attaccanti non cercano più solo l’endpoint dell’utente: cercano il sistema che contiene i dati.
Sul tuo IBM i i dati ci sono tutti.
Dove si nascondono i rischi reali
Nella nostra esperienza sui sistemi IBM i in ambito PMI e PA, le criticità ricorrenti sono quasi sempre le stesse cinque. Nessuna richiede un attacco sofisticato per essere sfruttata.
- Profili con autorità eccessive. Utenze con *ALLOBJ accumulate nel tempo per risolvere un problema contingente e mai revocate. Spesso includono profili di servizio, ex dipendenti e account di fornitori esterni.
- Accessi che scavalcano i menu. La sicurezza di molte installazioni storiche è costruita sui menu applicativi. Ma ODBC, JDBC, FTP, DDM e i comandi remoti non passano dai menu: chi arriva da rete accede direttamente agli oggetti, se le autorizzazioni a livello di oggetto non sono state configurate.
- L’IFS come porta d’ingresso. L’Integrated File System viene spesso condiviso verso i client Windows. Un ransomware che cifra una condivisione mappata non ha bisogno di “capire” l’IBM i: gli basta scrivere sui file.
- Protocolli in chiaro. Telnet e FTP senza TLS restano attivi in un numero sorprendente di installazioni, con credenziali che transitano leggibili sulla rete interna.
- Il giornale di audit spento, o acceso e mai letto. Il QAUDJRN è lo strumento nativo che registra cosa succede sul sistema. Molte installazioni non lo hanno mai attivato. Fra quelle che lo hanno attivato, la maggior parte non lo legge: i dati esistono, nessuno li guarda.
Il punto cieco: log che restano sull’isola
Quest’ultimo punto merita un discorso a parte, perché è quello che distingue un sistema monitorato da uno soltanto acceso.
Quando un’azienda si dota di un Security Operation Center, in genere ci fa arrivare gli eventi di firewall, endpoint, Active Directory e cloud. L’IBM i resta fuori. Non per una scelta consapevole: semplicemente parla una lingua che gli strumenti standard non leggono, e nessuno si è preso il compito di tradurla.
La conseguenza pratica è che il sistema che custodisce gli ordini, i dati dei clienti e la contabilità è l’unico su cui, in caso di incidente, non si sa dire chi ha fatto cosa e quando. Un accesso anomalo alle tre di notte a un file di produzione non genera nessun allarme, perché non c’è nessuno — e nessuna macchina — dall’altra parte a riceverlo.
Portare gli eventi dell’IBM i dentro il monitoraggio centrale non è un vezzo tecnico: è la differenza fra accorgersi di un incidente mentre accade e ricostruirlo settimane dopo dai backup. È il ragionamento su cui abbiamo costruito CyberGuard SOC per IBM Power i.
«Ma il nostro AS/400 non è esposto su Internet»
È l’obiezione che sentiamo più spesso, ed è quasi sempre vera. Quasi.
Il punto è che da anni gli attacchi non arrivano più dalla porta principale. Arrivano da una casella di posta, da una credenziale riutilizzata, da un portatile di un fornitore collegato in VPN. L’attaccante entra nella rete interna come utente qualsiasi, e da lì si guarda intorno. A quel punto la domanda non è più se l’IBM i sia esposto verso l’esterno, ma quanto sia difficile raggiungerlo dall’interno.
Nella maggior parte delle reti che vediamo, la risposta è: pochissimo. Il sistema risponde su ODBC da qualunque postazione, le condivisioni IFS sono montate sui client, le credenziali di servizio sono le stesse da anni e non scadono. Un movimento laterale che altrove richiederebbe giorni, lì richiede minuti.
C’è poi un secondo equivoco, più sottile: l’idea che un sistema poco diffuso sia protetto dalla propria stessa nicchia. Ha funzionato finché gli attacchi erano opportunistici e scritti a mano. Con strumenti automatizzati capaci di riconoscere e interrogare servizi di rete non comuni, l’oscurità non è più una difesa — è solo un ritardo nella scoperta.
Cosa cambia con NIS2
Fino a ieri questa era una questione di buona gestione. Dal recepimento della direttiva NIS2 con il D.Lgs 138/2024 è diventata, per molte aziende, un obbligo.
L’articolo 24 richiede misure tecniche e organizzative adeguate alla gestione dei rischi, fra cui la sicurezza degli accessi, la gestione delle vulnerabilità e il rilevamento degli incidenti. L’articolo 25 impone tempi di notifica stretti: una segnalazione preliminare entro 24 ore dalla consapevolezza dell’incidente e una notifica entro 72 ore.
Qui il nodo diventa evidente. Non si può notificare in 24 ore un incidente che non si è in grado di rilevare. Se il sistema centrale dell’azienda non produce eventi leggibili e nessuno li osserva, la consapevolezza arriva quando il danno è già visibile — e a quel punto le finestre di legge sono ampiamente scadute.
Se non hai ancora chiaro se la tua azienda rientri nel perimetro, il punto di partenza è la guida NIS2 per le PMI.
Da dove partire, concretamente
Non serve un progetto da sei mesi per uscire dalla zona di rischio. Serve iniziare dalle cose che si misurano.
- Fai l’inventario delle utenze privilegiate. Quanti profili hanno *ALLOBJ? Chi sono? Quanti appartengono a persone che non lavorano più in azienda o a fornitori che non intervengono da anni?
- Verifica il livello di sicurezza del sistema. Il valore di sistema QSECURITY a livello 30 protegge molto meno del livello 40, che è lo standard atteso oggi.
- Chiudi le vie di accesso non presidiate. Censisci quali exit point sono attivi e chi li usa davvero.
- Attiva il giornale di audit — e portalo fuori. Attivare QAUDJRN è il primo passo; farne arrivare gli eventi a chi li guarda è quello che conta.
- Metti l’IBM i nel piano di risposta. Se hai una procedura di gestione degli incidenti che non nomina mai il sistema gestionale, quella procedura ha un buco.
Se vuoi una misura del punto di partenza, abbiamo raccolto i controlli essenziali nella checklist dei 15 controlli di sicurezza per IBM i, e un mini-audit in 5 domande per avere un’idea in pochi minuti di dove sei messo.
Il sistema più affidabile merita la stessa attenzione degli altri
L’IBM i non è un problema. È probabilmente la piattaforma più solida del tuo parco macchine, ed è per questo che ci gira sopra ciò che conta.
Il problema è averlo trattato per anni come un elettrodomestico: qualcosa che funziona e basta, e di cui non serve occuparsi. Quella logica, con NIS2 e con l’attuale panorama di minacce, non regge più.
La buona notizia è che l’IBM i ha già dentro di sé quasi tutto quello che serve: controlli granulari sugli oggetti, un giornale di audit nativo, meccanismi di autorizzazione che molte piattaforme più moderne si sognano. Quasi sempre non manca la tecnologia. Manca qualcuno che la accenda, la configuri e la guardi.
Vuoi sapere a che punto è davvero il tuo IBM i? Partiamo da un assessment del sistema e da una lettura onesta dei rischi, senza vendere nulla prima di aver capito. Parliamone.
Leggi anche
