Quando aggiornare è eresia: Warhammer 40K e il rischio dei sistemi legacy

Adeptus Mechanicus, debito tecnico e il prezzo di una tecnologia che nessuno osa cambiare.

Nel nome del Dio Macchina

Immagina un mondo forgia. La cattedrale non ospita un altare: ospita una macchina. È così grande che le passerelle scompaiono nel fumo, mentre tubazioni simili a nervature risalgono pareti di ferro. Le candele tremano sotto il rombo degli ingranaggi. L’incenso copre appena l’odore dell’olio. Da qualche parte, molto in alto, un indicatore continua a lampeggiare.

Un sacerdote tecnico avanza tra i cavi. Si ferma davanti a un pannello, esegue una sequenza tramandata e attende. La macchina risponde. Nessuno sa più chi abbia scritto le istruzioni originali. Nessuno vuole essere quello che scoprirà, davanti a un’intera fabbrica immobile, perché il settimo passaggio non andava saltato.

Questa scena è immaginata, non tratta da un racconto canonico. Ma il paradosso appartiene perfettamente all’atmosfera di Warhammer 40.000: una civiltà dipende da tecnologie tanto importanti quanto difficili da comprendere, modificare o sostituire.

Ecco perché parlare di Warhammer 40K e sistemi legacy è meno strano di quanto sembri. Basta togliere le vesti rosse, abbassare il volume dei cori e sostituire il pannello sacro con quel server che nessuno riavvia dal 2014.

Atto I — Il culto della macchina

Nella presentazione ufficiale dell’Adeptus Mechanicus, Warhammer Community descrive una confraternita di sacerdoti ingegneri che custodisce, riproduce e mantiene tecnologie antiche, alcune ormai comprese solo parzialmente. Conoscenza, devozione e manutenzione si intrecciano. Preservare una macchina significa preservare qualcosa da cui l’Imperium dipende.

Non sarebbe corretto ridurre tutto a «odiano il nuovo». Il Mechanicus cerca anche conoscenze perdute; e Belisarius Cawl rappresenta un evidente controesempio alla totale immobilità. La tensione interessante è un’altra: quanto spazio resta per cambiare quando il funzionamento di una tecnologia è avvolto dall’autorità della tradizione?

Torniamo nella nostra cattedrale immaginaria. Il giovane apprendista domanda perché una leva debba essere abbassata due volte. Il custode risponde che si è sempre fatto così. Potrebbe esserci una ragione eccellente. Potrebbe essere il residuo di un guasto risolto tre secoli prima. Il problema è che non sanno più distinguere le due cose.

Nel mondo IT, il rito assume forme meno solenni: un file chiamato DEFINITIVO_v7, una procedura custodita nella memoria di una sola persona, un’applicazione che funziona soltanto con una particolare versione di una libreria. Il sistema produce ancora risultati. La capacità di spiegare quei risultati, invece, si assottiglia.

Una tecnologia può continuare a funzionare anche quando l’organizzazione ha perso la capacità di governarla pienamente. Un inventario utile deve quindi andare oltre il nome del server: chi lo gestisce, quale processo sostiene, quali dati tratta, da cosa dipende e chi sa ripristinarlo?

È una domanda di governance, rischio e controllo. Se il custode lascia l’organizzazione e con lui scompare l’unica spiegazione della sequenza, non abbiamo perso soltanto una persona. Abbiamo perso una parte della nostra capacità operativa.

Atto II — Il prezzo dell’immobilità

La macchina continua a girare. Questo tranquillizza tutti, finché un ricambio non arriva più, un’interfaccia cambia o il fornitore smette di offrire assistenza. A quel punto il tempio scopre che la propria stabilità aveva una data di scadenza. Solo che nessuno l’aveva scritta sul calendario.

Il debito tecnico somiglia agli interessi di una decisione rimandata: una scorciatoia o una soluzione diventata inadeguata rende più costosi gli interventi successivi. Non coincide semplicemente con l’età del sistema. La paura di toccarlo, però, può alimentarlo: meno sappiamo, meno interveniamo; meno interveniamo, più difficile diventa recuperare conoscenza.

Consideriamo un esempio interamente ipotetico. Un’azienda usa un’applicazione per coordinare le spedizioni. È affidabile, ma gira su un sistema operativo fuori supporto e dipende da un componente che il nuovo ambiente non accetta. Migrare durante il picco stagionale potrebbe fermare il magazzino. Rimandare di qualche settimana può essere una decisione sensata.

Rimandare per cinque anni senza riesaminare nulla è un’altra storia. Nel frattempo cambiano le minacce, gli accessi e le persone. La dipendenza dal vecchio fornitore si concentra su un tecnico prossimo alla pensione. La macchina non è diventata sacra: è diventata difficile da sostituire.

La guida congiunta CISA e NSA sulle configurazioni rischiose richiama il problema di software e hardware non più supportati: le vulnerabilità possono restare senza correzioni del produttore. Questo aumenta il rischio, ma «legacy» non significa automaticamente vulnerabile o non conforme. Contano supporto, esposizione, dati, minacce e controlli effettivi.

Nel magazzino immaginario, il rinvio dovrebbe avere un responsabile e una scadenza. Nel frattempo si possono limitare le comunicazioni necessarie, separare il sistema dalle reti meno fidate, sorvegliare comportamenti anomali e ridurre gli account autorizzati. Il minimo privilegio aiuta anche quando la macchina non può essere sostituita domani.

Sono misure compensative da valutare e verificare, non una benedizione che cancella ogni vulnerabilità. La porta sorvegliata non ripara il muro. Può però ridurre l’esposizione mentre prepariamo l’intervento.

Rinviare un aggiornamento può essere necessario; ignorare sistematicamente il rischio che ne deriva è un’altra cosa. L’incenso, purtroppo, non compare tra i controlli compensativi.

Atto III — L’eresia necessaria

Adesso arriva l’innovatore. Guarda il pannello, scuote la testa e propone di sostituire tutto venerdì pomeriggio. È convinto di salvare il mondo forgia. Due ore dopo, la macchina principale riparte perfettamente. Le tre linee collegate, invece, aspettano un segnale che il nuovo sistema non invia più.

Nella nostra scena inventata, i sacerdoti avevano paura del cambiamento. Il nuovo arrivato aveva paura solo della lentezza. Entrambi hanno ignorato la stessa cosa: le dipendenze. Una patch applicata senza comprenderle può compromettere la disponibilità proprio mentre tenta di migliorare la sicurezza.

Il NIST SP 800-40 Rev. 4 tratta il patch management come manutenzione preventiva e processo organizzativo: identificare, prioritizzare, acquisire, installare e verificare gli aggiornamenti. Non basta premere un pulsante. Serve collegare le esigenze di sicurezza a quelle di chi deve continuare a lavorare.

Nel nostro magazzino, il cambiamento comincia prima della finestra di manutenzione. Si ricostruiscono le integrazioni, si concorda un fermo sostenibile e si prova il nuovo ambiente. I test devono verificare il processo completo: l’ordine entra, la spedizione parte, i dati tornano correttamente. Un’applicazione che si apre non dimostra che il servizio funzioni.

Poi si prepara il ritorno: backup verificati, istruzioni praticabili, persone disponibili e criteri per decidere quando interrompere l’intervento. Il rollback non è la frase «nel caso torniamo indietro» scritta in fondo al documento. Alcune modifiche ai dati possono renderlo complesso; va capito prima, non mentre il telefono del magazzino squilla.

Anche il rinvio si governa. Qual è il rischio residuo? Chi accetta la decisione? Quando la rivediamo? Quale evento rende indispensabile intervenire prima? Sono domande concrete, capaci di trasformare una superstizione operativa in una scelta motivata.

Il sacerdote prudente e l’innovatore possono finalmente sedersi allo stesso tavolo. Uno conosce le cicatrici della macchina, l’altro vede una strada diversa. Nessuno dei due deve vincere per principio. Devono costruire una transizione che l’organizzazione possa sostenere.

Il problema non è scegliere tra conservazione e innovazione, ma governare il rischio di entrambe.

Non basta pregare il Dio Macchina

Nella cattedrale, l’indicatore lampeggia ancora. Questa volta qualcuno ne conosce il significato. Sa quali sistemi avvisare, dove trovare le istruzioni e quando fermarsi. La macchina non è meno importante perché abbiamo smesso di trattarla come un mistero.

Non ogni tecnologia vecchia va rottamata. Non ogni novità merita fiducia. Un sistema ben compreso e mantenuto può valere più di una sostituzione brillante di cui nessuno ha analizzato gli effetti. Ma la continuità non può dipendere eternamente dalla fortuna o dall’unico custode rimasto.

Forse la vera eresia non è aggiornare. È continuare a chiamare prudenza ciò che non sappiamo più spiegare.

Il Dio Macchina può anche ascoltare le preghiere. Il piano di ripristino dovrebbe funzionare senza aspettare una risposta.