- La disavventura di un consulente AI australiano
- Come è successo: una chiave API lasciata in chiaro
- Sessantamila richieste e un conto che lievita
- Limiti di spesa superati: il meccanismo che ha tradito
- Il lieto fine parziale e le lezioni da trarre
- Sicurezza cloud: un problema strutturale
- Domande frequenti
La disavventura di un consulente AI australiano
Quando Jesse Davies, consulente specializzato in intelligenza artificiale con base in Australia, ha aperto la dashboard di fatturazione del proprio account Google Cloud, ha pensato a un errore di sistema. Oltre 25.000 dollari australiani, equivalenti a circa 18.000 dollari statunitensi, addebitati in un arco di tempo brevissimo. Non era un errore. Era il risultato di una svista apparentemente banale: una chiave API lasciata esposta in un progetto pubblicato su Google Cloud Run.
La vicenda, emersa nelle scorse settimane e divenuta rapidamente virale nella comunità degli sviluppatori, racconta qualcosa di più di una semplice disattenzione individuale. Mette a nudo le fragilità strutturali con cui professionisti e aziende si confrontano quotidianamente nell'ecosistema del cloud computing, dove un dettaglio trascurato può trasformarsi in un salasso economico.
Come è successo: una chiave API lasciata in chiaro
La dinamica è tanto semplice quanto istruttiva. Davies stava lavorando a un servizio ospitato su Cloud Run, la piattaforma serverless di Google che consente di eseguire container in modo scalabile. All'interno del progetto, reso pubblico probabilmente per finalità di test o dimostrazione, era rimasta una chiave API attiva, una credenziale che consente di autenticarsi e utilizzare servizi a pagamento.
Una chiave API esposta in un repository o in un servizio pubblico è, per un malintenzionato, come trovare le chiavi di casa sotto lo zerbino. E qualcuno, infatti, le ha trovate. Un attaccante, quasi certamente attraverso strumenti automatizzati di scansione, ha individuato la credenziale e ha iniziato a sfruttarla sistematicamente.
Stando a quanto ricostruito dallo stesso Davies, non si è trattato di un attacco sofisticato. La chiave era lì, in chiaro, accessibile a chiunque sapesse dove cercare. Il problema non è stato l'abilità dell'attaccante, ma la facilità con cui la porta era rimasta aperta.
Sessantamila richieste e un conto che lievita
Una volta ottenuto l'accesso, il soggetto malevolo ha generato circa 60.000 richieste automatiche verso i servizi Google Cloud collegati alla chiave compromessa. Ogni singola richiesta comportava un costo. Moltiplicate per decine di migliaia, quelle frazioni di centesimo si sono trasformate in una fattura esorbitante.
È il meccanismo perverso dei costi imprevisti nel cloud computing: i servizi scalano automaticamente in base alla domanda, e se la domanda è generata da un attacco, il contatore gira comunque. L'utente paga, a meno che non intervenga un blocco.
La questione dei costi nascosti legati all'intelligenza artificiale e ai servizi cloud è del resto sempre più centrale nel dibattito tecnologico. Modelli di pricing basati sul consumo offrono flessibilità, ma espongono anche a rischi che molti professionisti, soprattutto quelli che operano come freelance o in piccole realtà, faticano a gestire.
Limiti di spesa superati: il meccanismo che ha tradito
Davies aveva impostato dei limiti di spesa sul proprio account. Avrebbe dovuto essere una rete di sicurezza. Non lo è stata. Come sottolineato dal consulente stesso, il sistema di Google Cloud prevede un meccanismo di aumento automatico del livello dell'account (automatic tier upgrade) che, in determinate condizioni, consente di superare le soglie di spesa precedentemente configurate.
In altre parole, il sistema ha interpretato l'impennata di utilizzo come una crescita legittima, adeguando automaticamente i parametri dell'account. Un comportamento by design, pensato per evitare interruzioni di servizio a clienti in espansione, che in questo caso ha funzionato esattamente al contrario delle aspettative dell'utente.
È un aspetto che solleva interrogativi rilevanti sulla protezione delle chiavi API e, più in generale, sulla trasparenza dei meccanismi di billing delle grandi piattaforme cloud. Se un limite di spesa può essere aggirato automaticamente, fino a che punto può dirsi davvero un limite?
Il lieto fine parziale e le lezioni da trarre
La storia ha avuto un epilogo meno drammatico di quanto si potesse temere. Dopo aver segnalato l'accaduto a Google, i costi sono stati annullati e parte del denaro già addebitato è stato recuperato. Un esito positivo, certo, ma che non cancella lo stress e il rischio concreto a cui Davies è stato esposto.
Non tutti gli utenti, va detto, possono contare sulla stessa visibilità mediatica per ottenere un rimborso. E non tutte le piattaforme reagiscono con la stessa disponibilità. La vicenda è dunque anche un promemoria sulle best practice che chiunque lavori con servizi cloud dovrebbe adottare:
- Mai includere chiavi API nel codice sorgente di progetti pubblici, nemmeno temporaneamente
- Utilizzare secret manager e strumenti di gestione sicura delle credenziali
- Configurare alert di spesa multipli e su soglie progressive
- Effettuare audit periodici dei servizi esposti e delle credenziali attive
- Revocare immediatamente le chiavi non più necessarie
Per chi opera nel campo dell'intelligenza artificiale, dove le chiamate API a modelli linguistici e servizi di inferenza possono essere particolarmente costose, queste precauzioni non sono opzionali. Sono una necessità.
Sicurezza cloud: un problema strutturale
Il caso Davies non è isolato. Le cronache della cybersecurity applicata ai servizi cloud sono piene di episodi analoghi: credenziali esposte su GitHub, chiavi AWS finite in repository pubblici, token di accesso dimenticati in container Docker. È un problema che riguarda singoli sviluppatori tanto quanto grandi organizzazioni.
Google, dal canto suo, sta investendo massicciamente nella sicurezza della propria infrastruttura. Lo dimostra, tra l'altro, il possibile accordo da 30 miliardi di dollari con Wiz, azienda leader nella sicurezza cloud, che segnala quanto il colosso di Mountain View consideri la questione strategica. Parallelamente, l'azienda ha introdotto strumenti per la rilevazione delle truffe digitali, segno di un'attenzione crescente alla protezione degli utenti su più fronti.
Ma la tecnologia, da sola, non basta. Come dimostra questa vicenda, il fattore umano resta il punto debole più frequente. Una chiave dimenticata, un momento di fretta, un progetto di test che diventa pubblico per errore. Basta poco perché la scalabilità del cloud, solitamente un vantaggio, si trasformi in un moltiplicatore di danni.
La lezione è chiara, anche se scomoda: nel mondo del cloud computing, la sicurezza non è mai un dettaglio. E il costo della disattenzione può essere, letteralmente, molto salato.
