sicurezza informatica

Sicurezza informatica e IA: gli errori del cloud che stiamo ripetendo



Indirizzo copiato

Un’analisi approfondita sui crescenti rischi dell’intelligenza artificiale applicata alle aziende, tracciando un parallelismo storico tra la governance degli agenti autonomi e i vecchi errori sistemici commessi durante l’adozione di massa del cloud

Pubblicato il 30 lug 2026

Matteo Gargiulo

Editor e specialista in media digitali e comunicazione internazionale



Sicurezza informatica
Foto Shutterstock
AI Questions Icon
Chiedi all'AI
Riassumi questo articolo
Approfondisci con altre fonti

Punti chiave

  • Adozione massiva di intelligenza artificiale richiama gli errori del cloud: il IAM tradizionale è insufficiente, gli agenti sfruttano permessi; adottare default deny.
  • Imporre Zero Trust con autenticazione del dispositivo, controlli endpoint e certificati X.509 per bloccare accessi da macchine non autorizzate.
  • Usare l’IA per revisione codice e difesa, ma limitare il vibe coding e gli LLM fai-da-te: rischio errori sistemici e metriche fuorvianti.
Riassunto generato con AI


L’adozione di massa dell’intelligenza artificiale all’interno delle infrastrutture aziendali sta ricalcando fedelmente dinamiche già osservate nel recente passato tecnologico.

Nel corso di un approfondito dibattito rilasciato all’interno del podcast specializzato CISO Series, esperti e analisti del settore hanno evidenziato come l’attuale frenesia legata ai modelli linguistici stia riproponendo le medesime vulnerabilità strutturali che caratterizzarono la migrazione verso le architetture cloud.

Il nucleo della questione non risiede nella novità tecnologica in sé, bensì nella tendenza sistematica a sacrificare la sicurezza in nome della rapidità di implementazione e della facilità d’uso per il business, forzando i responsabili della difesa informatica a inseguire minacce ampiamente prevedibili.

Il grande inganno degli agenti autonomi e il collasso dell’IAM

I sistemi tradizionali di Identity and Access Management (IAM) mostrano vistosi limiti concettuali se applicati ai nuovi flussi di lavoro automatizzati.

I modelli di gestione dell’identità correnti sono strutturati per verificare se un determinato attore sia tecnicamente autorizzato ad accedere a una risorsa, ma non possiedono criteri logici per stabilire se quell’azione sia opportuna.

Una configurazione IAM standard può confermare la legittimità di un agente software che interroga un database aziendale contenente gli stipendi per unirlo alle valutazioni delle prestazioni del personale, ma non è in grado di rilevare se tale operazione debba effettivamente essere eseguita o se violi le logiche di riservatezza interna.

Questa criticità viene amplificata dalla natura stessa degli agenti artificiali, ai quali vengono concessi ampi permessi permanenti che non verrebbero mai assegnati a un dipendente umano. Andy Ellis, Principal presso Duha, fa notare come l’imprevedibilità umana differisca radicalmente dal comportamento degli algoritmi.

Gli agenti tecnologici sono estremamente prevedibili poiché tendono a utilizzare la totalità dei permessi di cui dispongono.

Nelle organizzazioni umane, la sicurezza viene spesso compromessa dall’abitudine di clonare i profili autorizzativi dei colleghi per i nuovi assunti, accumulando nel corso degli anni una serie di accessi ridondanti che il dipendente non utilizzerà mai.

Tuttavia, nel momento in cui lo stesso dipendente distribuisce un agente automatizzato per rispondere a specifiche interrogazioni, il software rileva tutti i privilegi latenti e inizia ad attingere indistintamente a qualunque dato disponibile.

L’applicazione del Default Deny

Danny Jenkins, CEO di ThreatLocker, suggerisce una soluzione netta. Bisogna applicare la filosofia del default deny. Questo approccio prevede il blocco impostato per impostazione predefinita.

Jenkins basa la gestione dei privilegi su un assioma lineare: «Penso che si tratti davvero di permettere ciò di cui si ha bisogno e nient’altro».

Diventa indispensabile analizzare i flussi ed eliminare le autorizzazioni obsolete. Bisogna ridurre preventivamente le prerogative concesse agli strumenti artificiali.

La velocità del caos e l’assenza di responsabilità

Il monitoraggio degli agenti artificiali impone tempi di reazione molto rapidi. Un operatore umano che sottrae dati agisce con una lentezza relativa. Questo comportamento offre una finestra temporale utile per il rilevamento.

Al contrario, gli agenti software operano a una velocità superiore. Essi generano danni sistemici o alterazioni dei database in frazioni di secondo. A volte agiscono in modo del tutto errato e imprevedibile.

La salvaguardia della sicurezza affronta anche il problema della responsabilità legale. Un dipendente rischia il licenziamento o il perseguimento penale. Gli agenti software sono invece privi di sanzioni applicabili. Essi agiscono senza alcuna conseguenza diretta. David Spark ricorda che la macchina non possiede una coscienza. Essa non è in grado di autoregolarsi.

Jenkins conferma questa totale assenza di freni: «L’agente stesso non ha una coscienza. Non può essere fermato, non si può ragionare con lui e farà qualunque cosa ritenga appropriata, che sia cancellare un database o criptare file». Risulta quindi vitale inserire vincoli strutturali e controlli periodici.

L’ombra del cloud sullo sviluppo dell’intelligenza artificiale

I parallelismi tra l’evoluzione dei modelli LLM e i passati errori strategici commessi durante la transizione al cloud trovano d’accordo numerosi analisti.

Caleb Sima di White Rabbit ha sintetizzato l’attuale scenario evidenziando un dato allarmante: «Abbiamo appena distribuito più superficie di attacco in 12 mesi di quanta ne abbiamo costruita nel decennio precedente».

La proliferazione incontrollata di server basati su Model Context Protocol (MCP) privi di qualsiasi forma di autenticazione, unita alla comparsa di funzionalità malevole all’interno dei marketplace dedicati ai modelli linguistici, ricalca gli stessi difetti di gioventù delle prime infrastrutture cloud.

Rispetto a questa diagnosi, Ellis esprime una parziale divergenza di vedute, ritenendo che non si tratti di un errore grossolano, bensì del normale processo di adozione delle tecnologie dirompenti da parte del business.

Le aziende tendono ad appropriarsi immediatamente degli strumenti innovativi per massimizzare la produttività. Di conseguenza, l’atteggiamento dei professionisti della sicurezza che pretendono di arrestare i processi aziendali in attesa di lunghe consultazioni interne si rivela storicamente fallimentare.

L’unica strategia sostenibile consiste nell’implementare controlli fondamentali e flessibili che precedano lo spiegamento tecnologico.

Il parallelo con gli open relay

Jenkins individua un’analogia storica nei servizi di posta elettronica dei primi anni Duemila. In quel periodo i server venivano configurati come open relay. Lo scopo era semplificare al massimo le comunicazioni.

Dopo una serie di abusi informatici, il settore ha introdotto le credenziali obbligatorie. Sono nate così le black-list e l’autenticazione a più fattori (MFA).

L’errore ripetuto consiste nel fare affidamento solo su strumenti di risposta alle minacce. Bisogna invece consentire unicamente le operazioni necessarie, isolando il resto.

L’IA come alleato della difesa

L’intelligenza artificiale rappresenta anche un prezioso alleato per la sicurezza. ThreatLocker utilizza algoritmi avanzati nei propri flussi operativi.

Questi strumenti analizzano centinaia di migliaia di righe di codice. Essi individuano falle invisibili all’occhio umano.

L’integrazione tra analisi classica e intelligenza artificiale offre ottimi risultati. Permette di convalidare la categorizzazione dei siti web con una precisione superiore al 99%.

Oltre l’identità umana: l’autenticazione del dispositivo nello Zero Trust

Il concetto tradizionale di autenticazione focalizzato esclusivamente sul fattore umano mostra segni di obsolescenza strutturale.

Ellis sottolinea l’urgenza di superare questa impostazione, precisando che l’utente logico non deve essere inteso come una persona isolata, bensì come un set integrato composto da “umano più dispositivo”. Risulta tecnicamente impossibile verificare l’identità dell’individuo sulla rete senza autenticare in via preliminare lo stato e l’integrità del terminale utilizzato.

La fragilità del solo fattore umano viene confermata da un esperimento di simulazione condotto da ThreatLocker sul proprio personale tecnico.

Un attacco controllato di phishing è riuscito a trarre in inganno otto ingegneri dell’azienda, i quali hanno inserito le proprie credenziali per l’accesso a Office 365 e hanno successivamente approvato la notifica push del secondo fattore di autenticazione (2FA) sui propri telefoni.

Questo episodio dimostra che le tecniche di ingegneria sociale possono eludere la vigilanza dei profili più tecnici.

L’identità hardware del dispositivo, al contrario, costituisce una variabile non cedibile tramite inganno telefonico o interfacce web contraffatte.

Il controllo degli endpoint e il blocco dei dispositivi sconosciuti

Un’efficace architettura di sicurezza deve basarsi su rigidi controlli degli endpoint aziendali. Ellis ricorda l’esperienza maturata in Akamai, dove l’infrastruttura prevedeva l’installazione di un certificato X.509 su ciascun computer aziendale.

Il dispositivo eseguiva una prima autenticazione automatica con la rete e, solo dopo il buon esito di questo passaggio, veniva richiesta l’autenticazione dell’operatore umano.

Questo approccio neutralizza i tentativi di phishing, poiché il possesso fraudolento delle credenziali utente diventa del tutto inutile se il computer dell’attaccante non risulta censito e autorizzato a monte.

La validità di questo paradigma trova riscontro nelle odierne soluzioni di Zero Trust Cloud Access, progettate per inibire l’accesso ad applicativi in cloud come Salesforce o Office qualora la richiesta provenga da un computer non esplicitamente approvato dall’amministrazione centrale.

I dati statistici rilevano che i tentativi di accesso da dispositivi non associati da parte dei dipendenti legittimi sono eventi estremamente rari nel panorama aziendale.

Di conseguenza, qualunque richiesta di login originata da una macchina sconosciuta deve essere catalogata immediatamente come un segnale d’allarme e bloccata in via preventiva.

L’illusione del “Vibe-Coding” e i limiti del software fai-da-te

L’intelligenza artificiale tocca anche lo sviluppo di software per la protezione aziendale. Gli LLM permettono di generare codice funzionale descrivendo l’intento in inglese durante la pausa pranzo.

Questa tendenza viene definita vibe coding. Alcuni CISO stanno valutando la dismissione di determinati vendor. Vogliono sostituirli con applicativi sviluppati internamente tramite intelligenza artificiale.

I limiti delle soluzioni su scala ridotta

Ellis ridimensiona la portata di questo fenomeno. L’eliminazione dei fornitori riguarda solo problemi di nicchia o prodotti incentrati su semplici dashboard grafiche. Una funzionalità di base sviluppata in un fine settimana non equivale a una soluzione industriale. Essa non può operare su larga scala.

Gli agenti di intelligenza artificiale vanno considerati come collaboratori junior. Bisogna sottoporli a guide rigide di onboarding aziendale. Gli output devono includere logiche di codifica difensiva e integrazione Zero Trust.

Il rischio dell’errore sistemico

La fragilità del software generato dagli LLM risiede nei limiti della conoscenza pubblica. Jenkins paragona l’affidabilità attuale dell’IA a un GPS preciso al 98%. Questa accuratezza è sufficiente per brevi spostamenti locali. Tuttavia, il restante 2% di errore farà sbagliare strada durante un viaggio da New York a San Francisco. I software professionali si basano sul feedback di thousands di clienti.

Un algoritmo può scrivere uno script per bloccare lo schermo dopo quindici minuti. Esso non possiede però la visione d’insieme per governare una complessa architettura di sicurezza.

La tecnologia offre, invece, ottimi risultati nella revisione del codice. In questo campo l’automazione dimostra grandi capacità di analisi.

La gestione delle metriche e l’efficacia reale dei controlli

L’efficacia delle strategie di difesa si scontra con l’interpretazione dei dati. Spesso le metriche indicano un miglioramento senza mostrare una causa statistica.

Altre volte i dati non mostrano progressi a fronte di reali benefici apportati. Ellis definisce perverse la maggior parte delle metriche di sicurezza. L’esperto ritiene peggiore la prima circostanza. Essa culla l’organizzazione in un falso senso di protezione. Lo strumento di analisi potrebbe non essere più aggiornato.

Risultati reali contro grafici di marketing

Jenkins esprime una preferenza opposta. Il manager ritiene prioritario il possesso di controlli tangibili rispetto alle rappresentazioni grafiche. Con un sistema di autenticazione del dispositivo, la protezione aumenta concretamente. Questo avviene anche se i dati sui tentativi di phishing rimangono stabili. L’attenzione deve focalizzarsi sul risultato reale e non sulle metriche di marketing.

Ellis ironizza sul fatto che l’unico dato credibile sia il denaro in banca monitorato dal Chief Revenue Officer. Gli altri parametri sono narrazioni che hanno bisogno della solidità dei controlli applicati.

La gestione delle nuove tecnologie richiede un ritorno ai fondamentali della protezione informatica. Jenkins riassume questa visione con una considerazione diretta: «La sicurezza è difficile, ma non deve esserlo per forza».

L’obiettivo risiede nell’adozione di controlli preventivi semplici, capaci di rendere sicuro l’ambiente senza ostacolare la produttività.

Partecipa alla community

guest

0 Commenti
Più recenti
Più votati
Inline Feedback
Vedi tutti i commenti

Articoli correlati

0
Lascia un commento, la tua opinione conta.x