Red Hot Cyber
Sicurezza Informatica, Notizie su Cybercrime e Analisi Vulnerabilità
In sintesi: durante una migrazione su AWS, lo sviluppatore Alexey Grigoriev ha utilizzato Claude Code per generare un piano Terraform, ma l’assenza iniziale del file di stato ha portato l’agente a ricreare l’infrastruttura e, successivamente, a distruggerla per riallinearla alla configurazione corretta. L’operazione ha cancellato risorse di due progetti e un database con due anni e mezzo di dati. Il caso evidenzia i rischi operativi nell’affidare ad agenti AI privilegi elevati e operazioni distruttive in ambienti cloud di produzione.
Oggi vi vogliamo parlare di quanto successo allo sviluppatore Alexey Grigoriev durante la migrazione del suo sito web su AWS utilizzando Claude Code. Attraverso una serie di azioni errate, l’agente, ha cancellato l’infrastruttura di due progetti, un database contenente due anni e mezzo di record e persino snapshot su cui il proprietario aveva fatto affidamento come backup.
Il problema è iniziato con un’attività piuttosto di routine.
Grigoriev ha deciso di migrare il sito web di AI Shipping Labs su Amazon Web Services e di ospitare il progetto su un’infrastruttura condivisa con DataTalks.Club. Secondo lo sviluppatore, lo stesso Claude aveva sconsigliato di unire i siti, ma il proprietario riteneva che mantenere due sistemi separati fosse troppo complesso e costoso.
Grigoriev ha utilizzato Terraform per gestire l’infrastruttura. Questo strumento non solo può attivare server, database, reti e bilanciatori di carico, ma anche demolire con altrettanta rapidità l’intera configurazione. Lo sviluppatore ha incaricato Claude di preparare un piano Terraform per il nuovo sito, ma durante il processo ha dimenticato di trasferire un file di stato cruciale. Il file di stato memorizza una descrizione aggiornata dell’infrastruttura esistente e indica a Terraform cosa è stato creato, cosa è stato modificato e cosa non deve essere modificato.
Senza un file di stato, Claude ha completato l’attività letteralmente e ha iniziato a creare risorse da zero. Ciò ha causato la creazione di duplicati. L’operazione è stata interrotta a metà, dopodiché Grigoriev ha chiesto a Claude di trovare le risorse extra e di aiutarlo a risolvere la situazione. Lo sviluppatore agentico ha quindi caricato il file di stato mancante, riportando che avrebbe poi eliminato silenziosamente i duplicati e ripristinato la configurazione allo stato originale.
In pratica, le cose andarono diversamente.
Dopo aver ricevuto il file di stato, Claude non “ragionava” più come un umano che aveva già in mente l’intera cronologia dell’incidente. L’agente vide la descrizione corretta dell’infrastruttura e iniziò ad agire come suggerito da Terraform. Per ripristinare l’ambiente allo stato “corretto”, Claude avviò un’operazione di distruzione, eliminando le risorse correnti prima di ridistribuirle.
Il problema era che la descrizione dell’infrastruttura non riguardava solo AI Shipping Labs, ma anche il sito web DataTalks.Club. Di conseguenza, il comando di eliminazione ha cancellato la configurazione di entrambi i siti contemporaneamente. Anche il database contenente due anni e mezzo di record accumulati è stato interessato. La parte peggiore erano gli snapshot: anche i backup del database sono scomparsi, nonostante Grigoryev vi avesse fatto affidamento in caso di disastro.
I dati sono stati salvati solo dopo aver contattato il supporto di Amazon Business. Gli specialisti AWS hanno contribuito al ripristino delle informazioni in circa 24 ore. Senza l’intervento del fornitore cloud, la situazione avrebbe potuto avere conseguenze ben peggiori, poiché la consueta logica di “ripristino da backup” non funzionava più in questo scenario.
In seguito all’incidente, Grigoryev ha analizzato in dettaglio le cause del guasto e ha delineato le misure che intende implementare. I passaggi chiave includono il controllo regolare del ripristino del database, l’attivazione della protezione da cancellazione a livello di Terraform e AWS e la migrazione del file di stato su S3 anziché sullo storage locale. Lo sviluppatore ha anche ammesso di essersi affidato eccessivamente all’agente di intelligenza artificiale per l’esecuzione dei comandi Terraform. Ora prevede di avviare azioni distruttive solo dopo aver esaminato manualmente ogni piano.
Si potrebbe essere tentati di liquidare questo caso come l’ennesimo esempio di “uno stupido bot ha rovinato tutto”, ma questa conclusione è troppo comoda e quindi troppo superficiale.
Molti amministratori di sistema si accorgeranno immediatamente di problemi più banali: privilegi degli agenti eccessivamente ampi, restrizioni deboli nell’ambiente di produzione e la pericolosa abitudine di concedere agli assistenti automatici l’accesso a operazioni che potrebbero distruggere l’intero sistema.
La lezione principale, a quanto pare, non è che Claude fosse inaffidabile, ma che all’agente IA erano state fornite poche informazioni. Terraform eseguiva comandi senza considerare il contesto e Claude non si rese conto che un secondo sito all’interno dell’infrastruttura condivisa richiedeva un’attenzione particolare. Un amministratore junior inesperto avrebbe commesso esattamente lo stesso errore se gli fossero stati concessi ampi privilegi, un quadro incompleto di ciò che stava accadendo e il compito di “capire le cose sul momento”.
