top of page
Cerca

Il giorno in cui un software “normale” ha iniziato a fare paura: gestione remota, fiducia e indipendenza nella giustizia.

Negli ultimi giorni mi sono ritrovato a leggere, ascoltare, incrociare nei corridoi e nelle chat professionali sempre la stessa frase, detta con toni diversissimi: “Ma è vero che possono entrare nei computer dei magistrati?”


La domanda nasce da fatti di cronaca di queste settimane, da una ricostruzione giornalistica che ha rimesso sotto i riflettori la presenza, su decine di migliaia di postazioni informatiche di procure e tribunali, di un sistema di gestione centralizzata. E come succede spesso, appena una tecnologia smette di essere invisibile e diventa racconto pubblico, cambia consistenza. In un attimo non è più “infrastruttura”: è sospetto, è simbolo, è prova indiziaria di qualcos’altro.


Capisco la tentazione di scegliere subito una posizione comoda. Da una parte la narrativa del “software spia”, del grande occhio digitale, dell’accesso remoto come scorciatoia per controllare le toghe. Dall’altra la risposta istituzionale, che insiste sulla normalità dello strumento e sul suo impiego per finalità di sicurezza e manutenzione, respingendo l’idea stessa di sorveglianza. In mezzo, però, c’è un terreno che raramente viene raccontato bene: quello in cui la capacità tecnica, la governance e la percezione pubblica si intrecciano fino a diventare indistinguibili. Ed è lì che vale la pena stare, senza urlare e senza sdrammatizzare.

Nel racconto circolato in queste settimane, il software identificato come Endpoint Configuration Manager, noto storicamente come SCCM nell’ecosistema Microsoft, sarebbe presente dal 2019 per la gestione centralizzata di aggiornamenti, configurazioni e manutenzione dei sistemi informatici del Ministero della Giustizia.


È un dettaglio che, letto da chi fa IT, suona quasi ovvio. Letto da chi maneggia fascicoli, segreti investigativi e provvedimenti in bozza, suona invece diverso: perché il punto non è solo che cosa il software sia, ma che cosa possa fare se qualcuno, legittimamente o meno, ne detiene le chiavi.


Qui conviene mettere subito un paletto, semplice ma essenziale. Endpoint Configuration Manager non nasce come “trojan”. È una piattaforma enterprise progettata per amministrare grandi parchi macchina: distribuire applicazioni, applicare patch, verificare inventari hardware e software, far rispettare policy senza dover andare fisicamente PC per PC. E dentro questa logica di amministrazione, esistono anche funzioni di controllo remoto utili per assistenza e troubleshooting, con meccanismi di autorizzazione e con report pensati proprio per l’audit dell’uso del remote control. La documentazione Microsoft, per esempio, descrive report specifici per ricostruire quali computer siano stati oggetto di sessioni di controllo remoto e da parte di quali utenti amministrativi.


Detto così sembra tutto lineare. E invece non lo è, perché in un ambiente giudiziario l’endpoint non è una “postazione d’ufficio” come le altre. È un punto di contatto con atti coperti da riservatezza, con dati giudiziari e personali su larga scala, con comunicazioni interne, con dinamiche che hanno un peso costituzionale prima ancora che organizzativo. L’indipendenza del giudice, nella vita reale, non vive soltanto nelle norme: vive anche in una sensazione concreta di inviolabilità del lavoro quotidiano. E quando entra in scena un’infrastruttura che, in teoria, consente interventi amministrativi remoti, quella sensazione può incrinarsi anche se nessuno ha mai abusato di nulla.


C’è un passaggio mentale che, in questi casi, fa danni in entrambe le direzioni. Chi è allarmato tende a confondere “capacità tecnica” con “uso effettivo”, trasformando un possibile in un certo. Chi minimizza tende a fare l’errore opposto: finge che la capacità tecnica non esista o che sia irrilevante, come se l’etica bastasse a neutralizzare un privilegio. In realtà la capacità esiste, e non è un mistero: un sistema di endpoint management, se configurato con privilegi elevati, permette di distribuire software e script, di raccogliere informazioni sullo stato del sistema, di effettuare azioni amministrative e, se abilitato, di avviare sessioni di controllo remoto. Il punto vero, quello adulto, è un altro: quali barriere architetturali e procedurali impediscono che questa capacità diventi opaca, contestabile, o peggio abusabile?


Qui entra in gioco la parola che in Italia usiamo troppo poco quando parliamo di tecnologia pubblica: governance. In un contesto come quello giudiziario non basta dire “è per la sicurezza informatica”. La sicurezza non è uno slogan, è un sistema di vincoli. Se il controllo remoto è possibile, deve essere incardinato in una procedura che non viva di fiducia personale ma di regole verificabili: autorizzazioni, tracciabilità, segregazione dei ruoli, log protetti, audit credibili. Perché la fiducia istituzionale non si costruisce chiedendo di credere. Si costruisce offrendo la possibilità concreta di verificare.


Il tema dei log, in questi dibattiti, viene spesso trattato con superficialità. Da un lato c’è l’idea suggestiva del “senza lasciare traccia”, dall’altro una fiducia un po’ ingenua nel fatto che “tanto tutto logga”. La realtà è meno cinematografica e più spietata. I log esistono davvero soltanto se sono gestiti come un programma organizzativo: raccolta coerente, retention, protezione dall’alterazione, monitoraggio, revisione periodica. NIST, con la guida storica SP 800-92 sulla log management, insiste proprio su questo punto: non basta generare log, serve un approccio enterprise alla loro gestione, perché i log diventano utili (anche in chiave forense) solo se sono completi, affidabili, protetti e consultabili.


E poi c’è l’aspetto che, per chi lavora nel processo, è quasi inevitabile: la contestazione. Se una postazione può essere raggiunta da remoto da un soggetto amministrativo, come si protegge la catena di responsabilità? Come si difende l’attribuzione di un’azione digitale quando più mani, con privilegi elevati, possono intervenire sullo stesso sistema? Non serve immaginare complotti: basta una modifica accidentale, una configurazione toccata “per aiutare”, un intervento di assistenza fatto in fretta, e la domanda in udienza diventa improvvisamente più difficile del previsto. Ed è lì che la governance smette di essere un tema tecnico e diventa tenuta processuale.


Fin qui, però, qualcuno potrebbe obiettare: “Va bene, ma senza strumenti centralizzati come fai a tenere sicuro un parco macchine così grande?”. È un’obiezione seria. E anzi: proprio la cronaca internazionale degli ultimi anni suggerisce che il problema non è l’eccesso di strumenti, ma spesso il contrario, cioè infrastrutture fragili, frammentate, difficili da aggiornare e da proteggere. Non stiamo parlando di teoria. Nel luglio 2024 il Los Angeles Superior Court è arrivato a chiudere tutte le sedi dopo un attacco ransomware che ha colpito sistemi di rete e servizi essenziali, con impatti su portali e operatività. In Australia, nello Stato di Victoria, un attacco ha colpito il database delle registrazioni giudiziarie e la rete audio-video in aula, con il rischio di esposizione di contenuti sensibili di udienze. In Pennsylvania, nel febbraio 2024, un attacco di tipo denial-of-service ha interrotto servizi online delle corti, ricordando quanto sia sottile la linea tra “disruption” e danno istituzionale. E più di recente, nell’agosto 2025, la stessa U.S. federal judiciary ha confermato che la propria infrastruttura IT è stata oggetto di cyberattacchi persistenti e sofisticati, con conseguenze e timori legati anche a dati giudiziari sensibili.


Questi esempi non servono per fare terrorismo psicologico. Servono per mettere a fuoco una verità semplice: la giustizia è un bersaglio, e lo sarà sempre di più. Chi gestisce infrastrutture giudiziarie ha quindi un dovere doppio. Deve ridurre la superficie d’attacco e garantire continuità operativa, certo. Ma deve farlo senza creare “zone d’ombra” che, anche solo in potenza, alimentino sospetti di controllo improprio o interferenze. È un equilibrio delicatissimo. E quando è delicato, non lo reggi con comunicati o con rassicurazioni generiche: lo reggi con architetture che separano, con privilegi minimizzati, con accessi temporanei e tracciati, con audit indipendenti che non siano autoreferenziali.

In questo discorso, sorprendentemente, torna utile anche il lessico delle garanzie istituzionali. La raccomandazione CM/Rec(2010)12 del Consiglio d’Europa, parlando di indipendenza, efficienza e responsabilità dei giudici, richiama il bisogno di condizioni che proteggano la funzione da pressioni indebite e interferenze. È un testo nato per l’ordinamento, non per i server. Ma il salto concettuale è immediato: se vogliamo proteggere davvero l’indipendenza, dobbiamo trattare l’infrastruttura digitale come parte delle condizioni materiali che la rendono possibile. In altre parole, l’indipendenza oggi passa anche da chi può amministrare cosa, e con quali controlli.


E la privacy? Anche qui, niente moralismi. In ambienti che trattano dati giudiziari su larga scala, le valutazioni d’impatto non sono un rito. Le linee guida europee sulle DPIA, nella tradizione WP29 poi endorse dall’EDPB, insistono su quando il trattamento è “likely to result in a high risk” e su come strutturare una valutazione che non sia cosmetica. Un sistema centralizzato che gestisce endpoint dove transitano informazioni delicate è, per definizione, un oggetto che merita una DPIA rigorosa e soprattutto comunicata internamente con chiarezza: chi ha accesso, in quali casi, con quali limiti, con quale logging, con quali controlli terzi. Perché la riservatezza non è soltanto “non guardare”: è anche dimostrare che non si può guardare senza lasciare una scia verificabile.


Arrivo, volutamente, a una considerazione che spesso viene trattata come dettaglio finale, quando invece è l’inizio di tutto: le persone. La cronaca di queste settimane ci mostra che una parte significativa del problema nasce anche dall’asimmetria informativa. Chi amministra conosce strumenti e logiche. Chi usa le postazioni, spesso, vede solo l’effetto: finestre che compaiono, richieste di conferma, interventi tecnici che arrivano senza contesto, oppure non arrivano affatto ma “potrebbero arrivare”. In quel vuoto, qualsiasi narrazione attecchisce.


E allora, sì: il problema è anche addestramento, formazione, cultura operativa. Non formazione generica, non la lezione una tantum su Teams con trenta slide e zero pratica. Parlo di addestramento continuo e concreto all’uso dei software e delle procedure: riconoscere una richiesta legittima di assistenza, capire cosa significa autorizzare una sessione di remote control, sapere quali canali ufficiali vengono usati e quali no, distinguere un intervento amministrativo tracciato da un’anomalia da segnalare, comprendere che cosa viene loggato e perché. Perché un’infrastruttura può essere impeccabile sulla carta e diventare fragile nella pratica se chi la vive ogni giorno non è messo nelle condizioni di interpretarla. E quando non si interpreta, si teme. Quando si teme, si sospetta. Quando si sospetta, la fiducia si consuma anche senza un abuso reale.


La vicenda italiana di queste settimane, quindi, la leggo così: non come prova automatica di sorveglianza, e nemmeno come “malinteso tecnologico” da liquidare con sufficienza. La leggo come segnale di un bisogno più profondo: progettare e governare le infrastrutture della giustizia con la stessa cura con cui si progettano le garanzie processuali. E accettare che, accanto agli investimenti in tecnologia, serva un investimento altrettanto serio in competenze, in procedure e in addestramento delle persone che quella tecnologia la usano, la subiscono, la autorizzano, la contestano.


Se vogliamo che un software resti “normale”, dobbiamo renderlo normale anche per chi non è tecnico. Non a parole. Nei fatti.


Questa storia ci mette davanti a un paradosso contemporaneo: per difendere la giustizia servono strumenti di gestione e sicurezza sempre più potenti, ma più sono potenti più diventano politicamente e istituzionalmente sensibili. La soluzione non è demonizzare la gestione centralizzata, né fingere che il tema sia solo percezione. La soluzione sta in governance verificabile, logging robusto, audit indipendenti e, soprattutto, addestramento reale del personale, perché senza cultura operativa la tecnologia resta un corpo estraneo e ogni corpo estraneo, in un sistema delicato, diventa sospetto.


Spunti di discussione: Mi interessa capire come la vedete voi, senza posizioni “di bandiera”. Qual è, oggi, un livello accettabile di controllo tecnico centralizzato in un ambiente giudiziario, sapendo che gli attacchi alle corti nel mondo sono ormai cronaca e non eccezione? Pretendiamo meccanismi di audit esterni e davvero indipendenti come condizione minima di legittimazione, o ci accontentiamo di rassicurazioni interne purché tecnicamente plausibili? E soprattutto, quanto siamo disposti a investire in formazione continua di magistrati, cancellieri e personale amministrativo, perché la sicurezza non resti una materia per pochi specialisti ma diventi una competenza diffusa, capace di ridurre non solo il rischio tecnico, ma anche la zona grigia della sfiducia?


Yuri Lucarini Informatico Forense - Criminologo



Fonti e Link per approfondire:


 
 
 

Commenti

bottom of page