Quando un attacco informatico mette a rischio la fiducia: possiamo proteggere l’identità anche se i sistemi si fermano?
Un attacco informatico può interrompere servizi essenziali in pochi istanti. Ma il danno più duraturo non riguarda soltanto l’indisponibilità dei sistemi. Che cosa accade se un aggressore compromette anche l’identità digitale di una persona, i privilegi di un amministratore o l’autorizzazione a compiere operazioni sensibili? Un’architettura diversa potrebbe limitarne le conseguenze?
Il 15 ottobre 2026 il portale sloveno 24ur.com, presentando un dibattito specialistico sulla resilienza informatica delle istituzioni finanziarie, ha richiamato l’attenzione sulla preparazione agli incidenti, sulla continuità operativa e sulla fiducia degli utenti. L’articolo non documenta una nuova violazione accertata di una specifica banca, ma offre un punto di partenza per una riflessione più ampia.
L’Istituto 1 Aprile estende la domanda all’identità, alle autorizzazioni e alla responsabilità delle azioni digitali. Il fatto che un servizio funzioni non garantisce che ogni accesso sia legittimo; un accesso autenticato non dimostra che l’azione sia stata approvata dalla persona autorizzata.
Tre conseguenze diverse dello stesso incidente
La prima è l’indisponibilità del servizio: un utente non riesce a effettuare un pagamento, consultare una polizza o accedere a un portale. In questi casi sono essenziali ridondanza, copie di sicurezza, piani di ripristino e continuità operativa.
La seconda è la compromissione dei dati. Un aggressore può copiarli, modificarli o cancellarli. Riavviare un’applicazione non prova che i dati siano rimasti corretti. Servono controlli degli accessi, registri verificabili, protezioni dell’integrità e verifiche indipendenti.
La terza è la compromissione dell’identità e dei privilegi. Un attaccante può abusare di una sessione autenticata, delle credenziali di un dipendente o di un account amministrativo. Il sistema può considerare valide le operazioni semplicemente perché provengono da quell’account. Tuttavia identità, diritto di accesso e approvazione di una specifica azione sono elementi distinti.
La fiducia fa parte della sicurezza informatica
Non sempre è necessario violare direttamente un database protetto. Talvolta bastano un messaggio fraudolento convincente, una sessione sottratta o un’autorizzazione falsamente attribuita.
L’Agenzia dell’Unione europea per la cybersicurezza, ENISA, analizza rischi quali ransomware, vulnerabilità sfruttate, attacchi alla catena di fornitura e ingegneria sociale. L’intelligenza artificiale può rendere le comunicazioni fraudolente ancora più credibili. La domanda fondamentale quindi non è soltanto chi ha effettuato l’accesso, ma chi può fare cosa, per quale finalità e con quale approvazione verificabile in modo indipendente.
DORA, NIS2 e resilienza operativa
Il regolamento europeo DORA si applica dal 17 gennaio 2025 e definisce un quadro per la resilienza operativa digitale del settore finanziario: gestione dei rischi ICT, segnalazione degli incidenti rilevanti, test di resilienza e rischi legati ai fornitori esterni.
La direttiva NIS2 rafforza i requisiti di cybersicurezza per un insieme più ampio di soggetti importanti ed essenziali. Entrambi gli strumenti contribuiscono a prepararsi agli incidenti e a ridurne l’impatto, ma la conformità normativa da sola non può impedire ogni abuso di account o privilegi.
Essere resilienti significa anche individuare l’incidente, contenerlo, ripristinare i servizi e valutare se dati, identità e autorizzazioni restano affidabili dopo l’attacco.
Che cosa studia il concetto QEI?
L’Istituto 1 Aprile sviluppa la ricerca QEI – Quantized Encrypted Identity. Una delle direzioni consiste nel verificare se alcuni confini di fiducia legati all’identità possano rimanere indipendenti dai normali account utente e amministrativi. L’obiettivo non è sostituire la sicurezza delle reti, ma studiare uno strato aggiuntivo di protezione.
Verifica indipendente dell’identità
Per operazioni sensibili si potrebbero richiedere prove crittografiche verificabili, legate alla singola azione, senza affidarsi esclusivamente a password o sessioni attive. Il principio è rivelare soltanto le informazioni strettamente necessarie.
Separazione dei privilegi amministrativi
Chi gestisce l’infrastruttura ha bisogno di strumenti di manutenzione, non necessariamente dell’accesso a ogni identità personale o del potere di approvare operazioni a nome degli utenti. Chiavi distinte, privilegi minimi e approvazioni indipendenti rappresentano quindi ipotesi da esaminare.
Autorizzazione verificabile dell’azione
«L’account è autenticato» non equivale a «la persona avente diritto ha approvato esattamente questa operazione». Una prova potrebbe essere limitata a una finalità, a determinati dati e a un intervallo di tempo, con verifica separata dall’account dell’amministratore.
Revoca e recupero controllato
In caso di sospetto abuso dovrebbe essere possibile revocare credenziali o autorizzazioni compromesse e ripristinarle con un procedimento controllato. Anche il recupero, però, non deve diventare un nuovo punto unico di attacco.
Esempio: un amministratore compromesso
Immaginiamo che un attaccante ottenga il controllo di un account amministrativo di un istituto finanziario. Il danno dipende dall’ampiezza dei privilegi e dalle misure di protezione. Autorizzazioni eccessive possono consentire di modificare configurazioni, leggere dati riservati o tentare di assumere il controllo di altri account.
Un’architettura che separi la gestione dell’infrastruttura dalle chiavi necessarie alle operazioni sensibili sull’identità potrebbe impedire che un singolo accesso compromesso basti per ogni abuso successivo. Compromettere un account non dovrebbe significare compromettere automaticamente l’intera identità digitale. L’efficacia di tale separazione deve però essere dimostrata con test reali.
Abbiamo affrontato questo aspetto anche nell’articolo Quando un amministratore compromesso non significa un’identità compromessa.
Che cosa QEI non può risolvere da solo
QEI è un concetto di ricerca, non un prodotto di sicurezza operativo o certificato. Non può impedire da solo tutti gli attacchi ransomware, le vulnerabilità delle applicazioni, i guasti dei data center o gli attacchi contro la disponibilità dei servizi.
Una buona architettura dell’identità non sostituisce la sicurezza dei dispositivi, i backup, la segmentazione delle reti, la risposta agli incidenti, la formazione e i controlli organizzativi. I meccanismi ipotizzati potrebbero anche introdurre costi, dipendenze e nuovi punti di malfunzionamento; richiederebbero quindi valutazioni tecniche, legali e di sicurezza indipendenti.
Come verificare la proposta in un progetto pilota
Un progetto di ricerca circoscritto dovrebbe misurare, tra l’altro:
- se un amministratore compromesso può aggirare la protezione dei dati d’identità;
- se è possibile distinguere con certezza l’accesso dall’approvazione di una determinata transazione;
- quanto rapidamente si possono revocare e recuperare le autorizzazioni;
- che cosa accade quando un servizio centrale non è temporaneamente raggiungibile;
- quanti dati personali devono essere effettivamente comunicati;
- quali nuovi rischi operativi e di sicurezza introduce il sistema proposto.
Una ricerca credibile deve accettare anche risultati negativi: una soluzione può rivelarsi inadeguata in determinati contesti.
Conclusione: la fiducia deve poggiare su garanzie indipendenti
Ripristinare rapidamente un servizio è importante, ma la fiducia nel lungo periodo richiede dati affidabili, privilegi limitati, approvazioni verificabili e possibilità di recupero sicuro dopo un incidente.
Il prossimo passo della sicurezza digitale potrebbe non essere soltanto un accesso più robusto, ma una separazione più chiara tra identità, autorità e fiducia. È una delle direzioni di ricerca di QEI, con la tutela della privacy al centro della progettazione.
Per approfondire: QEI – Ricerca e sviluppo.
Fonti e approfondimenti
- 24ur.com – Kibernetski napad lahko v sekundah zamaje leta zaupanja (15 ottobre 2026, in sloveno).
- ENISA – Panorama delle minacce informatiche.
- Autorità bancaria europea – Digital Operational Resilience Act (DORA).
- Commissione europea – Direttiva NIS2.
Questo articolo è un contributo di ricerca indipendente dell’Istituto 1 Aprile. Le funzionalità QEI descritte sono ipotesi di sviluppo, non capacità verificate di un sistema già operativo. La citazione di istituzioni esterne non implica alcuna collaborazione.
