Cloud Intelligence™
Rilevamento delle anomalie nei costi cloud: lezioni da incidenti reali
Il team DoiT ha analizzato sei mesi di incidenti di sicurezza nella nostra base clienti. La causa alla radice era raramente qualcosa di inedito: quasi sempre una credenziale che qualcuno aveva dimenticato di proteggere.
Questa pagina è disponibile anche in English, Deutsch, Español, Français, 日本語 e Português.
A cura dei team DoiT Customer Success e Forward Deployed Engineering
About Kendall Wondergem
Senior Director of Customer and Partner Success at DoiT, leading teams that deliver continuous value and exceptional customer experience through our products and services. Over 20 years of experience in management consulting, SaaS, startups, and the cloud.
My personal pageTL;DR: Negli ultimi sei mesi, i team DoiT hanno gestito un numero crescente di incidenti di sicurezza nella nostra base clienti e sui principali cloud provider. La stragrande maggioranza è riconducibile a una sola cosa: una credenziale trapelata o senza restrizioni, di solito una API key o una access key IAM, lasciata dove non avrebbe dovuto essere. Alcuni incidenti sono stati individuati immediatamente, grazie a DoiT Cloud Intelligence™ Real-Time Anomaly Detection e a notifiche configurate correttamente verso lo stakeholder giusto lato cliente, al momento giusto. Dove le cose sono andate male, i clienti hanno registrato picchi di spesa fino a centinaia di migliaia di dollari prima che qualcuno se ne accorgesse. In questo articolo analizziamo cosa abbiamo osservato, quanto è costato e le azioni che Lei e il Suo team dovreste intraprendere oggi stesso per prevenire questi attacchi e individuare gli incidenti in pochi minuti anziché in giorni.
Se esegue workloads sul cloud pubblico, questo incubo lo conosce, per sentito dire o per esperienza diretta: una chiave incollata in un repository pubblico, integrata in un'app mobile o lasciata in una pipeline CI che nessuno controlla da un anno. Qualche giorno dopo, qualcuno del reparto finanziario chiede perché la bolletta cloud ha uno zero in più. Non è un'ipotesi: è di gran lunga l'incidente di sicurezza più comune a cui rispondiamo.
Abbiamo raccolto i dati sugli incidenti registrati dai nostri Forward Deployed Engineers negli ultimi sei mesi per capire quali pattern si ripetono su una base clienti ampia e variegata. Non è il classico report di un vendor che mette in guardia da attacchi teorici: è ciò che arriva davvero nella nostra coda, e vogliamo aiutarLa a evitare la stessa situazione nella Sua azienda.
Pattern degli incidenti di sicurezza cloud: GCP vs AWS
Gli incidenti su Google Cloud erano quasi tutti riconducibili a una cosa sola: l'esplosione dell'uso dell'API Gemini e di Vertex AI nell'ultimo anno, e quanto sia risultato facile lasciare una API key senza restrizioni mentre si sviluppa velocemente. Abbiamo pubblicato sul blog la soluzione per l'abuso delle API key di Gemini qui. Gli incidenti su AWS seguivano un pattern più tradizionale: chiavi IAM trapelate sfociate in abusi di risorse di calcolo, oltre a una manciata di veri e propri account takeover. Su entrambe le piattaforme, la causa alla radice non è quasi mai stata una vulnerabilità della piattaforma: quasi sempre qualcosa che un essere umano ha fatto, o non ha fatto, con una credenziale.
Incidenti di sicurezza su GCP: le API key trapelate sono la causa n. 1
| Causa principale | Quota |
|---|---|
| API key trapelate o senza restrizioni (Gemini, Vertex, AI Studio) | 77% |
| Chiave di service account trapelata usata per crypto mining o flotte Compute Engine non autorizzate | 19% |
| Hijack di sessione o account admin con manipolazione della fatturazione o lockout degli amministratori | 2% |
| Esfiltrazione di dati tramite un service account compromesso | 2% |
È la prima riga a fare la parte del leone. Il 77% degli incidenti GCP osservati negli ultimi sei mesi era riconducibile a una API key — di solito una browser key Firebase o una chiave Maps/Gemini incorporata nel codice client-side — priva di restrizioni sul referrer HTTP, sull'IP e sullo scoping delle API. Gli attaccanti scansionano repository pubblici e bundle frontend esposti proprio alla ricerca di questo pattern e, una volta trovata una chiave funzionante, lanciano script automatizzati contro la Generative Language API e li lasciano girare. Abbiamo visto incidenti di questo tipo che vanno da qualche centinaio di dollari a oltre 200.000 dollari di addebiti Gemini non autorizzati, generati nel giro di poche ore.
Il secondo cluster, le chiavi di service account trapelate, si sviluppa in modo diverso ma inizia allo stesso modo: una chiave a lunga durata dimenticata in un repository GitHub, in una configurazione CI/CD o sul laptop di uno sviluppatore. Una volta ottenuta, l'attaccante non fa lievitare le bollette API: avvia risorse di calcolo. In un caso su cui abbiamo lavorato, una chiave di service account GitLab CI trapelata ha permesso a un attaccante di lanciare più di 10.500 VM di crypto mining in un singolo progetto GCP nel corso di una notte. E le richieste di rimborso al cloud provider non vengono sempre approvate. È la parte su cui vale la pena soffermarsi: i cloud provider stanno diventando più rigidi con i crediti per "spese fuori controllo", soprattutto in caso di incidenti ripetuti o prevenibili. Contenimento e prevenzione contano più di prima, perché la rete di sicurezza di una contestazione della fattura non è garantita.
Incidenti di sicurezza su AWS: chiavi IAM trapelate e account takeover
| Causa principale | Quota |
|---|---|
| Access key IAM trapelata o senza restrizioni (macchine dev, CI/CD, codice) con uso non autorizzato di EC2, ECS, Fargate o Bedrock | 56% |
| Takeover dell'account root o di sessioni admin con manipolazione della fatturazione o lockout degli amministratori | 15% |
| Workload o applicazione compromessi (servizio esposto, trust policy mal configurata) con movimento laterale o esfiltrazione di secret | 15% |
| Abuso della piattaforma tramite account cliente compromessi, phishing o spam inviato tramite Amazon SES | 7% |
| Attacco DDoS o a livello di rete senza compromissione di credenziali | 7% |
Il quadro su AWS è simile a quello di GCP: le credenziali trapelate rappresentano oltre la metà del totale. Le access key IAM trapelate da macchine di sviluppo o pipeline CI si trasformano in flotte EC2 o Fargate non autorizzate che eseguono crypto miner o, sempre più spesso, in chiamate non autorizzate all'API Bedrock che accumulano costi di inferenza dei modelli.
I casi di takeover dell'account root sono quelli che dovrebbero preoccupare di più i responsabili della sicurezza, perché sono i più difficili da sanare. In un incidente, un attaccante ha reimpostato la password dell'account root AWS di un cliente, ha registrato il proprio dispositivo MFA e ha escluso completamente i veri amministratori. Da lì, ha eseguito chiamate su larga scala all'API Bedrock che hanno generato oltre 500.000 dollari di addebiti prima che l'account venisse recuperato. Il recupero ha richiesto un lavoro diretto con AWS per riverificare la proprietà e ricostruire gli accessi da zero. Nessun alert di rilevamento anomalie è abbastanza rapido se le persone che dovrebbero rispondere non riescono ad accedere all'account.
Abbiamo anche osservato un cluster più piccolo, ma reale, di compromissioni a livello di workload: un load balancer esposto su Internet che espone un pod, una trust policy OIDC mal configurata e un attaccante che si muove lateralmente per esfiltrare migliaia di secret da Secrets Manager. Qui non si tratta tanto di una singola chiave trapelata, quanto del debito accumulato da una configurazione di rete e IAM troppo permissiva.
Compromissione delle identità: phishing, abuso OAuth e account takeover
Gli incidenti rimanenti seguivano un pattern diverso ma correlato: campagne di phishing che raccoglievano credenziali, poi usate per dirottare account e inviare spam tramite un'identità mittente compromessa, o per spostarsi su strumenti di terze parti collegati via OAuth. L'account Workspace compromesso di un cliente è stato usato per aggiungere collegamenti manager non autorizzati al suo account Google Ads e accumulare quasi 50.000 dollari di spesa pubblicitaria fraudolenta. In un altro caso, il login di un dipendente è stato usato per concedere accesso OAuth a strumenti di terze parti, con conseguenti acquisti non autorizzati.
Il filo conduttore su tutte le piattaforme: il punto debole non era l'infrastruttura del cloud provider. Era l'identità.
La bolletta è il fumo, non l'incendio
È forte la tentazione di considerare il picco di costo come il problema. In realtà, il picco di costo è spesso il primo sintomo visibile di una compromissione delle credenziali. Sistemare la bolletta significa curare il sintomo. Sistemare l'igiene delle credenziali e prendere sul serio il rilevamento delle anomalie significa affrontare la causa alla radice.
Per questo la nostra raccomandazione ha due componenti che devono lavorare insieme: una revisione della postura di sicurezza che chiuda le falle prima che vengano sfruttate, e un monitoraggio che individui rapidamente lo sfruttamento se una falla dovesse comunque sfuggire.
Come prevenire gli incidenti di sicurezza cloud: colmare le falle
La raccomandazione in due parti di DoiT prevede quanto segue:
Fase 1: rivedere la postura di sicurezza cloud
La maggior parte degli incidenti descritti sopra era prevenibile con pratiche che rientrano in una revisione standard della postura di sicurezza cloud: limitare le API key a referrer o intervalli IP specifici, ruotare e dismettere le chiavi di service account a lunga durata, passare dalle credenziali statiche alla workload identity federation o a token a breve durata ovunque possibile, imporre MFA e limiti alla durata delle sessioni presso l'identity provider e limitare chi può creare o usare binding IAM a livello owner. Niente di esotico: è il lavoro noioso e poco glamour dell'igiene degli accessi, ed è esattamente il lavoro che continua a risultare mancante, incidente dopo incidente.
Fase 2: configurare il rilevamento delle anomalie nei costi cloud e le notifiche
DoiT Cloud Intelligence™ Real-Time Anomaly Detection (disponibile nei nostri tier Enhanced ed Enterprise) è pensato esattamente per il divario che emerge in quasi tutti gli incidenti di questo dataset: il ritardo tra il momento in cui qualcosa va storto e il momento in cui qualcuno se ne accorge. La maggior parte degli strumenti basati sulla fatturazione rileva un picco di spesa ore o giorni dopo che si è verificato, perché legge export che si aggiornano con ritardo. Real-Time Anomaly Detection legge direttamente i dati di utilizzo a runtime, combinandoli con i pattern di spesa storici, e può segnalare attività insolite in pochi minuti, non in giorni. Ogni alert include un punteggio di gravità e un'analisi generata dall'AI del servizio, dello SKU e della risorsa interessati, così il Suo team non parte da zero nell'indagine.
Per i clienti del tier Essentials, il nostro rilevamento anomalie cloud out-of-the-box può e deve comunque essere configurato, con notifiche appropriate per identificare e segnalare le anomalie. Per passare a Real-Time Anomaly Detection, contatti il Suo Account Manager DoiT o apra un ticket tramite Expert Inquiry nella console DoiT.
Per ottenere il massimo dal rilevamento delle anomalie:
- Verifichi che le notifiche di rilevamento anomalie siano configurate per le persone giuste, sui canali giusti e al momento giusto. Le notifiche di anomalie di costo richiedono l'autorizzazione Cloud Analytics e, per impostazione predefinita, vengono inviate ad Admin, Power User, Finance User e Standard User; vale però la pena controllare chi nel Suo team le ha effettivamente configurate e assicurarsi che tutti comprendano l'importanza di rispondere rapidamente alle notifiche.
- Non si fermi alla soglia di gravità predefinita. Se la Sua organizzazione esegue workloads ad alta velocità (CI/CD, inferenza GenAI, flotte con autoscaling), regoli la cadenza di revisione in modo che un'anomalia di gravità media alle 2 di notte venga comunque esaminata prima del mattino.
- Si affidi al Suo Customer Success Manager DoiT per configurare (o convalidare) rilevamento e notifiche. I CSM di DoiT sono a disposizione e possono essere gli occhi esperti necessari per assicurarsi che tutto sia impostato correttamente.
- Configuri notifiche per i picchi di spesa e per l'uso di nuovi SKU. Il rilevamento delle anomalie su nuovi SKU, con relativa notifica, è poco sfruttato ma fondamentale: La avvisa nel momento in cui la Sua organizzazione inizia a usare un servizio o uno SKU mai utilizzato prima, che è esattamente ciò che accade quando un attaccante con una chiave rubata inizia a colpire la Generative Language API o ad avviare per la prima volta inferenza su Bedrock. Un nuovo SKU legittimo compare di tanto in tanto, quando il Suo team rilascia qualcosa di nuovo. Uno inspiegabile, che compare in un momento inatteso, merita subito un controllo.
- Valuti la configurazione di notifiche sull'esaurimento delle quote o sull'uso dei crediti. Pur essendo pensata per un altro tipo di problema, questa configurazione completa il quadro dei comportamenti inattesi nella spesa.
- Valuti l'uso delle automazioni. Configuri DoiT Cloud Intelligence™ CloudFlow perché si attivi sui trigger di anomalie di costo. Può automatizzare attività di mitigazione degli incidenti come pubblicare su Slack, creare ticket o eseguire passaggi di remediation. Non sa da dove iniziare? Il Suo Customer Success Manager DoiT può coordinare una sessione di lavoro con un Forward Deployed Engineer di DoiT per creare i Suoi CloudFlow.
Per maggiori informazioni sulla configurazione del rilevamento anomalie e delle notifiche, consulti la documentazione DoiT sul rilevamento anomalie e sulle notifiche, oppure contatti il Suo Customer Success Manager DoiT.
Cloud bill shouldn't be a mystery
One platform for AI and Cloud optimization.
Supporto esperto per il rilevamento delle anomalie nei costi cloud
Per i clienti dei tier Enhanced ed Enterprise: contatti il Suo Customer Success Manager o Account Manager DoiT per pianificare una revisione della postura di sicurezza e/o configurare una solida strategia di rilevamento e risposta alle anomalie. Non sa chi è il Suo CSM/AM? Acceda a DoiT Cloud Intelligence™, clicchi sull'icona a forma di ingranaggio in alto a destra e selezioni "Account Managers".
Per i clienti del tier Essentials: apra un ticket tramite la console (vada al menu e selezioni "Get expert advice") e un Customer Success Manager potrà aiutarLa a configurare o rivedere la configurazione di anomalie e notifiche, oltre a fornirLe maggiori dettagli su una revisione della postura di sicurezza in autonomia o guidata da DoiT.
Checklist di risposta agli incidenti di sicurezza cloud
Se succede qualcosa nel Suo ambiente, ecco l'ordine delle operazioni che consigliamo, basato sulla nostra esperienza con incidenti contenuti rapidamente:
- Prima di tutto, tagli fuori la credenziale. Elimini o ruoti immediatamente l'API key o l'access key IAM compromessa. Non aspetti di aver compreso appieno la portata dell'impatto prima di farlo. Ogni ora in cui rimane attiva significa più spesa e più esposizione.
- Fermi l'emorragia a livello di risorse. Termini VM, istanze o flotte di calcolo avviate dall'attaccante. Se la spesa cresce più velocemente di quanto riesca a eliminare le risorse in sicurezza, scollegare l'account di fatturazione del progetto interessato è un freno d'emergenza del tutto legittimo.
- Preservi i log prima di ripulire tutto. Gli audit log e i VPC Flow Log sono ciò di cui il Suo cloud provider e il Suo team avranno bisogno in seguito, sia per l'analisi delle cause sia per un'eventuale contestazione della fattura. Ruotare ogni credenziale e cancellare ogni risorsa prima che qualcuno abbia estratto i log rende l'indagine molto più difficile.
- Apra un caso con il Suo cloud provider. Per le spese non autorizzate, la maggior parte dei provider ha un processo per contestare gli addebiti legati a una compromissione confermata. Sia realista sulle probabilità: i provider sono diventati più rigidi con questi crediti, soprattutto per incidenti ricorrenti o prevenibili, quindi non consideri garantita la richiesta di credito.
- Coinvolga DoiT. Apra un ticket tramite la console (vada al menu e selezioni "Get expert advice") o scriva al Suo Customer Success Manager. Quanto prima veniamo coinvolti, tanto più potremo aiutarLa con indicazioni sul contenimento, con l'escalation verso il provider e nell'assicurare che la stessa falla non si riapra.
- Chiuda la falla una volta contenuto l'incidente. Un incidente è un catalizzatore: lo usi per pianificare quella revisione della postura di sicurezza che rimanda da tempo.
FAQ
Che cos'è il rilevamento delle anomalie nei costi cloud?
Il rilevamento delle anomalie nei costi cloud è un monitoraggio che segnala pattern insoliti di spesa o di utilizzo — un nuovo SKU, un picco imprevisto, un servizio sconosciuto — nel momento in cui si verificano, invece di aspettare che sia la fattura mensile a rivelarli. DoiT Cloud Intelligence™ Real-Time Anomaly Detection legge direttamente i dati di utilizzo a runtime, quindi può segnalare l'attività in pochi minuti anziché nelle ore o nei giorni richiesti dagli strumenti basati sugli export di fatturazione.
Cosa succede in caso di leak di una API key?
Una volta che una API key senza restrizioni su referrer HTTP, IP o scope viene esposta — in un repository pubblico, in un'app mobile o in una configurazione CI — gli attaccanti in genere la trovano entro poche ore tramite scansioni automatizzate e lanciano immediatamente script contro API a pagamento come la Generative Language API o Bedrock. Negli incidenti che abbiamo monitorato, il danno andava da qualche centinaio di dollari a oltre 200.000 dollari di addebiti non autorizzati generati nel giro di poche ore.
Come avviene il takeover di un account cloud?
La maggior parte degli account takeover che osserviamo inizia con una credenziale sottratta tramite phishing o riutilizzata, non con una vulnerabilità della piattaforma. Un attaccante reimposta una password, registra il proprio dispositivo MFA ed esclude l'amministratore legittimo — poi usa quell'accesso per accumulare costi di calcolo o di inferenza dei modelli, o per manipolare la fatturazione. È il tipo di incidente più difficile da sanare, perché chi dovrebbe normalmente rispondere non riesce ad accedere all'account.
AWS o Google Cloud rimborsano gli addebiti non autorizzati derivanti da una credenziale trapelata?
Non automaticamente, e non sempre. Entrambi i provider hanno un processo di contestazione per gli addebiti legati a una compromissione confermata, ma sono diventati più rigidi nell'approvare i crediti, soprattutto per incidenti ricorrenti o prevenibili. Consideri il rimborso come possibile, non garantito: prevenzione e contenimento rapido contano più della rete di sicurezza di una contestazione della fattura.
Qual è la prima cosa da fare se si sospetta il leak di una credenziale?
Ruoti o elimini immediatamente la chiave compromessa, ancora prima di aver definito completamente la portata dell'impatto — ogni ora in cui rimane attiva è ulteriore esposizione. Poi fermi l'emorragia a livello di risorse (termini le risorse di calcolo non autorizzate o scolleghi la fatturazione come freno d'emergenza) e preservi gli audit log prima di ripulire qualsiasi cosa, perché serviranno per l'analisi delle cause e per un'eventuale contestazione della fattura.
Quanto rapidamente il rilevamento delle anomalie nei costi cloud può individuare una chiave compromessa?
Con un rilevamento in tempo reale configurato per avvisare sull'uso di nuovi SKU e su picchi di spesa con punteggio di gravità, i team possono individuare una chiave compromessa entro pochi minuti dal primo utilizzo. Il rilevamento anomalie standard basato sugli export di fatturazione ha in genere un ritardo da ore a giorni — esattamente la finestra che, nei nostri dati, ha trasformato incidenti minori in incidenti a sei cifre.
