Ultimo aggiornamento: 22 maggio 2026
Questo documento identifica i potenziali vettori di attacco e le strategie di mitigazione per la riservatezza, l'integrità e la disponibilità dei dati per Cloud Storage. L'ambito di questo report è limitato alla tua prospettiva e si concentra sui rischi che puoi gestire nel tuo ambiente Cloud Storage.
Questi modelli di minaccia sono una valutazione probabilistica basata su vettori di attacco attualmente noti, ipotesi architetturali e ambito specificato del sistema al momento della pubblicazione. Questi modelli non sono esaustivi e hanno lo scopo di fungere da base per le valutazioni di sicurezza e dei rischi dei clienti Google Cloud e di guidare le decisioni di riduzione dei rischi.
Per questo servizio sono state identificate le seguenti minacce:
Dettagli minacce
Le seguenti sezioni forniscono informazioni su ogni minaccia, sulle sue
manifestazioni e sulle mitigazioni consigliate.
Divulgazione di informazioni tramite una configurazione di accesso non sicura
I dati sensibili archiviati negli oggetti Cloud Storage possono essere esposti a terze parti non autorizzate quando i controlli dell'accesso sono configurati in modo errato. La configurazione errata dei controlli di accesso è uno dei problemi di sicurezza del cloud più comuni e di maggiore impatto.
| Categoria STRIDE |
Divulgazione di informazioni |
| Tattica MITRE ATT&CK |
Raccolta |
| Manifestazioni |
Esposizione del bucket pubblico:un bucket Cloud Storage viene reso pubblico concedendo ruoli come Storage Object Viewer agli account allUsers o allAuthenticatedUsers nella relativa policy di autorizzazione IAM. Se la prevenzione dell'accesso pubblico non viene applicata, questi ruoli espongono tutti gli oggetti a internet. Perdita di URL firmati:un URL firmato, che funge da token di autenticazione temporaneo, viene inavvertitamente divulgato tramite codice lato client, log o trasmissione non sicura. Qualsiasi utente o applicazione esterno che ottiene l'URL può accedere all'oggetto Cloud Storage specificato con le autorizzazioni (ad esempio, lettura o scrittura) fino alla scadenza della firma dell'URL. Autorizzazioni IAM eccessivamente ampie:alle identità, come un account utente o un account di servizio, vengono concesse autorizzazioni ampie (ad esempio storage.objects.get o storage.objects.list) in molti bucket quando le identità richiedono l'accesso solo a un piccolo sottoinsieme di dati. Credenziali di identità compromesse:un malintenzionato ottiene le credenziali per un account utente o una chiave di account di servizio, consentendogli di autenticarsi all'API JSON di Cloud Storage e accedere a tutti i dati che l'identità compromessa è autorizzata a visualizzare. Configurazione errata del bilanciatore del carico:un'istanza di Cloud Load Balancing configurata con un bucket Cloud Storage come backend può essere configurata in modo errato per esporre pubblicamente gli oggetti, anche se il bucket stesso non è pubblico. Questa configurazione errata crea un percorso di accesso alternativo, potenzialmente meno sicuro, ai dati, bypassando i controlli IAM di Cloud Storage diretti. Memorizzazione nella cache CDN impropria: quando un bucket Cloud Storage viene utilizzato come backend per Cloud Load Balancing e Cloud CDN, una configurazione errata può causare la memorizzazione nella cache di dati sensibili nelle posizioni edge pubbliche di Google. Se il servizio di backend non emette le intestazioni Cache-Control corrette (ad esempio private o no-store), la CDN potrebbe pubblicare i contenuti memorizzati nella cache per utenti non autorizzati, ignorando i controlli IAM del bucket.
|
| Mitigazioni |
Applica la prevenzione dell'accesso pubblico a singoli bucket di archiviazione o a livello di progetto, cartella o organizzazione con il vincolo dei criteri dell'organizzazione storage.publicAccessPrevention. Utilizza l'accesso uniforme a livello di bucket per semplificare le autorizzazioni ed evitare gli ACL legacy. Configura le chiavi di crittografia gestite dal cliente (CMEK) per proteggere i dati con la crittografia at-rest. Mantieni i tempi di scadenza degli URL firmati il più brevi possibile. Esegui regolarmente audit per rilevare e rimuovere le chiavi dei account di servizio compromesse o inutilizzate. Implementa i Controlli di servizio VPC per creare un perimetro di servizio e impedire l'esfiltrazione di dati anche in caso di furto delle credenziali. Assicurati che le policy Cloud Armor vengano applicate ai bilanciatori del carico che pubblicano contenuti Cloud Storage per limitare l'accesso.
|
Elevazione dei privilegi utilizzando configurazioni errate di IAM
Un malintenzionato con autorizzazioni IAM specifiche e apparentemente innocue può aumentare i propri privilegi per ottenere un accesso più ampio, incluso il controllo amministrativo sui bucket Cloud Storage e sui dati che contengono. Questa minaccia aggira la postura di sicurezza prevista e viola il principio del privilegio minimo.
| Categoria STRIDE |
Elevazione dei privilegi |
| Tattica MITRE ATT&CK |
Escalation dei privilegi |
| Manifestazioni |
Modifica diretta della policy:un'identità, ad esempio un utente o un account di servizio, a cui è stata concessa l'autorizzazione storage.buckets.setIamPolicy su un bucket Cloud Storage può modificare direttamente la relativa policy di autorizzazione. Questa configurazione consente all'autore dell'attacco di concedersi ruoli con privilegi elevati, come Storage Admin, ottenendo il controllo completo della configurazione e dei dati del bucket. Simulazione dell'identità del service account:un'identità con un ruolo come roles/iam.serviceAccountUser che contiene l'autorizzazione iam.serviceAccounts.actAs su un account di servizio può collegare il account di servizio ad altre risorse, ad esempio un'istanza Compute Engine, per eseguire il codice con l'identità del account di servizio collegato. In alternativa, un'identità con un ruolo come roles/iam.serviceAccountTokenCreator che dispone di autorizzazioni tra cui iam.serviceAccounts.getAccessToken può generare token di accesso per quel account di servizio. Se il account di servizio di destinazione dispone di privilegi elevati sulle risorse Cloud Storage, l'attaccante eredita effettivamente questi privilegi. Generazione di URL firmati:un'identità con l'autorizzazione iam.serviceAccounts.signBlob su un account di servizio può generare URL firmati V4. Questi URL consentono all'autore dell'attacco di creare un accesso temporaneo con token di autenticazione agli oggetti che il account di servizio può leggere o scrivere, aggirando potenzialmente controlli di rete più restrittivi o la mancanza di autorizzazioni Cloud Storage dirette dell'autore dell'attacco.
|
| Mitigazioni |
Segui il principio del privilegio minimo. Evita di aggiungere autorizzazioni come storage.buckets.setIamPolicy, iam.serviceAccounts.actAs o iam.serviceAccounts.signBlob ai ruoli, a meno che non sia assolutamente necessario. Utilizza le condizioni IAM per limitare le autorizzazioni a risorse o periodi di tempo specifici. Verifica regolarmente i criteri di autorizzazione utilizzando strumenti come Cloud Asset Inventory per rilevare e rimuovere le autorizzazioni eccessive. Assicurati che le applicazioni che gestiscono gli URL firmati non li registrino o li espongano in modo che possano essere recuperati da terze parti. Ad esempio, se utilizzi Cloud CDN per memorizzare nella cache gli URL firmati, imposta intestazioni Cache-Control appropriate per evitare di memorizzare nella cache pubblicamente oggetti sensibili che devono essere privati e autenticati tramite un URL firmato.
|
Manomissione o distruzione dei dati mediante autorizzazioni eccessive
Un malintenzionato con autorizzazioni sufficienti può alterare, danneggiare o eliminare definitivamente dati e configurazioni all'interno del sistema Cloud Storage, causando una perdita di integrità e disponibilità dei dati.
| Categoria STRIDE |
Manomissione |
| Tattica MITRE ATT&CK |
Impatto |
| Manifestazioni |
Manipolazione diretta degli oggetti:un'identità con autorizzazioni storage.objects.create o storage.objects.delete può sovrascrivere o eliminare singoli oggetti Cloud Storage. Utilizzo improprio delle policy del ciclo di vita:un malintenzionato con l'autorizzazione storage.buckets.update può modificare la configurazione della gestione del ciclo di vita degli oggetti di un bucket per creare una regola che elimini tutti gli oggetti immediatamente o dopo un breve periodo, causando la distruzione di massa dei dati. Eliminazione del bucket:un utente malintenzionato con privilegi elevati e l'autorizzazione storage.buckets.delete può eliminare un intero bucket Cloud Storage, distruggendo immediatamente tutti gli oggetti, le configurazioni e i criteri associati. Hijacking delle notifiche:un malintenzionato con l'autorizzazione storage.buckets.update può alterare o eliminare in modo dannoso una configurazione delle notifiche Pub/Sub. Questo attacco può oscurare i sistemi downstream che si basano su questi eventi o reindirizzare le notifiche a un argomento controllato dall'autore dell'attacco.
|
| Mitigazioni |
Se hai bisogno di uno spazio di archiviazione immutabile o di un periodo di conservazione minimo, configura il blocco del bucket per l'intero bucket o il blocco dell'oggetto per i singoli oggetti. Configura il controllo delle versioni degli oggetti e una policy di eliminazione temporanea per pianificare il recupero da sovrascritture accidentali o dannose nei bucket che contengono dati critici. Implementa un periodo di eliminazione temporanea specificato che ti dia tempo sufficiente per rilevare e recuperare gli oggetti prima dell'eliminazione definitiva. Abilita gli audit log di accesso ai dati nei bucket che contengono dati critici per monitorare i pattern di accesso irregolari.
|
Esfiltrazione di dati utilizzando job Storage Transfer Service configurati in modo errato
Un malintenzionato con autorizzazioni storagetransfer.transferjobs.create o storagetransfer.transferjobs.update può creare o modificare un job Storage Transfer Service per copiare i dati da un bucket Cloud Storage sensibile a un bucket controllato dal malintenzionato in un altro progetto. Questo vettore di attacco può essere utilizzato per estrarre grandi volumi di dati in modo silenzioso e continuo, bypassando il tipico monitoraggio dell'accesso ai dati che potrebbe essere incentrato su chiamate API dirette come storage.objects.get.
| Categoria STRIDE |
Divulgazione di informazioni |
| Tattica MITRE ATT&CK |
Esfiltrazione |
| Manifestazioni |
Creazione di job di trasferimento dannosi: un malintenzionato con autorizzazioni storagetransfer.transferjobs.create o storagetransfer.transferjobs.update crea o modifica un job Storage Transfer Service per copiare i dati da un bucket Cloud Storage sensibile a un bucket controllato dal malintenzionato in un altro progetto.
|
| Mitigazioni |
Limita rigorosamente le autorizzazioni IAM per storagetransfer.transferjobs.create e storagetransfer.transferjobs.update. Assegna queste autorizzazioni solo ai ruoli utilizzati da account amministrativi attendibili. Implementa un perimetro dei Controlli di servizio VPC per limitare la comunicazione tra i servizi all'interno del perimetro e i servizi all'esterno del perimetro. Utilizza le condizioni IAM per i ruoli che concedono le autorizzazioni per i job di trasferimento per limitare i bucket di origine e destinazione a località note e autorizzate. Monitora regolarmente Cloud Audit Logs per la creazione e la modifica dei job Storage Transfer Service. Configura gli avvisi per i job che specificano una destinazione esterna o non attendibile.
|
Perdita dell'accesso ai dati a causa di una gestione errata delle dipendenze
Attacchi o gestione errata delle dipendenze dei servizi critici possono negare l'accesso legittimo ai dati in Cloud Storage, rendendo i dati inaccessibili anche senza compromettere direttamente il sistema di archiviazione stesso.
| Categoria STRIDE |
Manomissione |
| Tattica MITRE ATT&CK |
Impatto |
| Manifestazioni |
Indisponibilità di CMEK:se un bucket Cloud Storage è configurato per utilizzare una chiave CMEK, la disattivazione o l'eliminazione della chiave Cloud KMS di supporto rende tutti gli oggetti criptati con quella chiave inaccessibili a livello di crittografia. L'agente di servizio Cloud Storage non può eseguire la decrittografia, il che comporta un denial of service totale per questi dati. Blocco del bucket dannoso:un malintenzionato con autorizzazioni storage.buckets.update può applicare un blocco del bucket con un periodo di conservazione eccessivamente lungo. Questo blocco impedisce l'eliminazione legittima dei dati, il che può portare a un accumulo di costi significativo e non necessario, una forma di denial of service finanziario.
|
| Mitigazioni |
Implementa criteri di autorizzazione IAM rigorosi e la separazione dei compiti per l'amministrazione di Cloud KMS. Assicurati che le identità con l'autorizzazione per gestire i bucket Cloud Storage non dispongano anche dell'autorizzazione per gestire le chiavi Cloud KMS utilizzate dai bucket. Utilizza i meccanismi di prevenzione dell'eliminazione delle chiavi Cloud KMS. Per il blocco del bucket, controlla attentamente l'autorizzazione storage.buckets.update e utilizza il monitoraggio per ricevere avvisi in caso di modifiche impreviste alla configurazione.
|
Offuscamento dell'attività a causa di un'osservabilità insufficiente
Se l'audit e il monitoraggio non sono configurati correttamente, un malintenzionato può eseguire azioni dannose sulle risorse Cloud Storage senza essere rilevato. Un'osservabilità insufficiente consente a un aggressore di nascondere le proprie tracce e impedisce una risposta efficace agli incidenti e un'analisi forense.
| Categoria STRIDE |
Ripudio |
| Tattica MITRE ATT&CK |
Evasione della difesa |
| Manifestazioni |
Log di accesso ai dati disattivati:mentre i log delle attività di amministrazione sono sempre attivi, i log di accesso ai dati, che registrano le letture e le scritture degli oggetti, sono disattivati per impostazione predefinita. Se non è abilitato in modo esplicito, un malintenzionato può esfiltrare o manomettere tutti i dati in un bucket senza generare Cloud Audit Logs per queste azioni, rendendo difficile il rilevamento o l'indagine sulla violazione. Manipolazione del sink di log: un malintenzionato che ottiene autorizzazioni sufficienti può disattivare o riconfigurare i sink di log che instradano Cloud Audit Logs, interrompendo di fatto il flusso di dati pertinenti alla sicurezza verso i sistemi di monitoraggio. Negligenza nel monitoraggio delle metriche:un malintenzionato esegue attività lente e graduali, ad esempio esfiltra gradualmente piccole quantità di dati per un lungo periodo. Queste azioni potrebbero non attivare avvisi di gravità elevata in Cloud Audit Logs, ma creerebbero pattern anomali nelle metriche di Cloud Monitoring (ad esempio, traffico di uscita sostenuto). La mancata monitoraggio di queste metriche offre a un malintenzionato un altro modo per non essere rilevato.
|
| Mitigazioni |
Abilita gli audit log di accesso ai dati per tutti i bucket che contengono dati sensibili o critici. Assicurati che i log vengano indirizzati a un progetto di logging sicuro e centralizzato con autorizzazioni controllate rigorosamente per impedire la manomissione dei sink di log. Configura avvisi basati sui log in Cloud Monitoring o in un sistema SIEM per rilevare attivamente attività sospette, come pattern di accesso anomali o modifiche ai criteri di autorizzazione IAM. Crea avvisi basati sulle metriche chiave di Cloud Monitoring per rilevare deviazioni dal comportamento di base. Utilizza le dashboard e i dati degli approfondimenti di Storage Intelligence integrati di Data Security Posture Management per fornire un monitoraggio continuo dell'esposizione al rischio a livello di oggetto e valutazioni della security posture.
|
Avvelenamento della catena di fornitura utilizzando artefatti compromessi archiviati in Cloud Storage
Se un malintenzionato ottiene l'accesso in scrittura, ad esempio storage.objects.create o storage.objects.delete, a un bucket Cloud Storage utilizzato per archiviare artefatti software (ad esempio, file binari, immagini container o script di build), può sostituire gli artefatti legittimi con versioni dannose. Le pipeline CI/CD downstream, gli sviluppatori o gli utenti finali che si fidano degli artefatti di questo bucket eseguiranno inavvertitamente il codice compromesso, causando un attacco alla catena di fornitura su larga scala.
| Categoria STRIDE |
Manomissione |
| Tattica MITRE ATT&CK |
Accesso iniziale |
| Manifestazioni |
Sostituzione binaria:un malintenzionato sovrascrive un binario o una libreria di rilascio con una versione infetta da trojan. Quando questo artefatto viene inserito in una build o distribuito, il codice dell'autore dell'attacco viene eseguito nell'ambiente di destinazione. Avvelenamento dell'immagine container: un malintenzionato con accesso a un bucket utilizzato come backend per un registro container (ad esempio Artifact Registry) può potenzialmente manomettere i livelli dell'immagine, inserendo vulnerabilità o backdoor. Modifica dello script di build:un malintenzionato modifica gli script di build (ad esempio cloudbuild.yaml o Makefile) archiviati in Cloud Storage per alterare il processo di compilazione stesso. Un malintenzionato potrebbe modificare gli script di compilazione per estrarre segreti o incorporare una backdoor durante la compilazione. Avvelenamento del modello di AI:un malintenzionato potrebbe sostituire un checkpoint del modello valido in Cloud Storage con un checkpoint dannoso che esegue codice quando viene caricato da un sistema di produzione. In alternativa, un malintenzionato potrebbe modificare i dati in un bucket Cloud Storage utilizzato per l'addestramento del modello per inserire backdoor o comportamenti dannosi nel modello addestrato.
|
| Mitigazioni |
Utilizza un servizio di gestione degli artefatti dedicato come Artifact Registry, che fornisce l'analisi delle vulnerabilità e un migliore controllo dell'accesso dell'accesso. Evita di utilizzare i bucket Cloud Storage standard per archiviare artefatti software critici. Implementa la firma digitale per tutti gli artefatti della build. Configura le pipeline CI/CD per verificare la firma di un artefatto prima di eseguirne il deployment, garantendone l'integrità e la provenienza. Configura il controllo delle versioni degli oggetti in un bucket per conservare gli oggetti sovrascritti con dati dannosi.
|
Denial of service basata sui costi utilizzando l'inondazione di oggetti Cloud Storage o l'abuso del traffico in uscita
Un malintenzionato con autorizzazioni di creazione di oggetti su un bucket scrivibile pubblicamente o scarsamente protetto può caricare un numero elevato di piccoli oggetti, con conseguenti costi finanziari significativi derivanti da operazioni di classe A e tariffe di archiviazione. In alternativa, un malintenzionato con accesso in lettura a un bucket con l'opzione "Il richiedente paga" disattivata può scaricare ripetutamente oggetti di grandi dimensioni, generando addebiti eccessivi per l'uscita di rete e potenzialmente influendo sulla disponibilità del servizio per gli utenti legittimi a causa dei limiti di fatturazione.
| Categoria STRIDE |
Denial of Service |
| Tattica MITRE ATT&CK |
Impatto |
| Manifestazioni |
Inondazione di oggetti:un malintenzionato utilizza uno script per creare rapidamente milioni di piccoli oggetti in un bucket, aumentando i costi operativi e potenzialmente influendo sulle applicazioni che elencano o elaborano i contenuti del bucket. Abuso dell'uscita:per un bucket che ospita grandi set di dati pubblici, un malintenzionato scarica ripetutamente i file, causando un esaurimento finanziario a causa dei costi della larghezza di banda in uscita. Questo abuso può portare il progetto a raggiungere le quote di fatturazione, causando di fatto un denial of service.
|
| Mitigazioni |
Configura gli avvisi di fatturazione Cloud per informare gli amministratori quando i costi superano una soglia di budget predefinita, in modo da rilevare in anticipo le spese anomale. Per i bucket accessibili pubblicamente, abilita i pagamenti a carico del richiedente. Questa funzionalità sposta il costo dell'accesso e dell'uscita dei dati sull'utente che li scarica, mitigando gli attacchi basati sul costo dell'uscita contro il proprietario del bucket. Utilizza Storage Insights per monitorare l'attività a livello di oggetto. Storage Insights fornisce la visibilità necessaria per la previsione dei costi e l'identificazione degli oggetti con traffico elevato che potrebbero essere presi di mira per l'abuso dell'uscita.
|
Manipolazione dell'integrità dei dati mediante l'abuso del controllo delle versioni degli oggetti Cloud Storage
Sebbene il controllo delle versioni degli oggetti sia una difesa fondamentale, un utente malintenzionato con autorizzazioni sufficienti, ad esempio storage.objects.delete o storage.objects.create, può manipolare la cronologia degli oggetti per compromettere l'integrità dei dati. Possono eliminare la versione corrente di un oggetto, facendo in modo che una versione precedente, potenzialmente errata o vulnerabile, diventi la versione "live". Può essere utilizzato per ripristinare patch di sicurezza, reintrodurre bug o ripristinare informazioni obsolete senza che sia immediatamente ovvio, poiché l'oggetto esiste ancora.
| Categoria STRIDE |
Manomissione |
| Tattica MITRE ATT&CK |
Impatto |
| Manifestazioni |
Ripristino della patch di sicurezza:un malintenzionato elimina l'ultima versione di un file binario o di configurazione dell'applicazione che contiene una patch di sicurezza, causando il ripristino della versione precedente vulnerabile del sistema. Corruzione dei dati per ripristino: in un sistema che si basa su Cloud Storage per l'archiviazione dello stato o della configurazione, un malintenzionato ripristina un oggetto di configurazione critico a uno stato precedente, causando errori di configurazione del servizio o di elaborazione dei dati. Manipolazione dell'integrità del modello di AI: un malintenzionato potrebbe sovrascrivere o ripristinare un checkpoint del modello di AI archiviato in un bucket Cloud Storage.
|
| Mitigazioni |
Sviluppa applicazioni che si basano su versioni specifiche degli oggetti per recuperare l'oggetto in base al suo numero di generazione univoco, non solo al suo nome. In questo modo, viene sempre recuperata la versione corretta. Utilizza un blocco di bucket con una policy di conservazione definita per i dati che richiedono un'archiviazione immutabile. Configura un criterio di eliminazione temporanea come ulteriore livello di difesa dall'eliminazione dannosa. Il controllo delle versioni degli oggetti non fornisce protezione contro le eliminazioni dei bucket.
|
Esfiltrazione di dati utilizzando pipeline Dataflow attivate da Cloud Storage
Se una pipeline Dataflow è configurata per attivarsi automaticamente alla creazione di oggetti in un bucket Cloud Storage, un malintenzionato che può scrivere in quel bucket può potenzialmente esfiltrare i dati. Se il account di servizio del job Dataflow dispone delle autorizzazioni per accedere ad altri dati sensibili e scrivere in posizioni esterne (ad esempio un altro bucket Cloud Storage o BigQuery), l'autore dell'attacco può creare un file di input che fa sì che la pipeline legga i dati sensibili e li scriva in una posizione controllata dall'autore dell'attacco.
| Categoria STRIDE |
Divulgazione di informazioni |
| Tattica MITRE ATT&CK |
Esfiltrazione |
| Manifestazioni |
Esfiltrazione tra progetti:un malintenzionato carica un file in un bucket di trigger. La pipeline Dataflow, in esecuzione con un account di servizio privilegiato, legge i dati sensibili da un altro progetto e scrive l'output in un bucket Cloud Storage pubblico specificato dal file di input dell'autore dell'attacco.
|
| Mitigazioni |
Racchiudi la pipeline Dataflow e le relative dipendenze Cloud Storage all'interno di un perimetro Controlli di servizio VPC per impedire alla pipeline di inviare dati a destinazioni esterne non autorizzate. Applica il principio del privilegio minimo al account di servizio worker Dataflow. Deve disporre solo delle autorizzazioni specifiche necessarie per leggere dall'origine e scrivere nella destinazione prevista. Abilita gli audit log di accesso ai dati per gli eventi DATA_WRITE per facilitare il controllo delle attività sospette dalla pipeline Dataflow. Abilita l'accesso uniforme a livello di bucket nel bucket Cloud Storage per garantire controllo dell'accesso'accesso coerente basato su IAM.
|
Compromissione dell'integrità mediante la manipolazione dello stato di IaC in Cloud Storage
Quando utilizzi i bucket Cloud Storage per archiviare i file di stato dell'infrastruttura come codice (IaC) (ad esempio, il file terraform.tfstate in Terraform), un malintenzionato con accesso in scrittura al bucket di stato può manomettere il file di stato. Modificando lo stato, un malintenzionato può inserire risorse dannose, modificare configurazioni di sicurezza critiche o causare la distruzione delle risorse durante la successiva esecuzione di IaC. Questa manomissione aggira i processi di revisione del codice, poiché l'attacco ha come target lo stato, non il codice stesso.
| Categoria STRIDE |
Manomissione |
| Tattica MITRE ATT&CK |
Impatto |
| Manifestazioni |
Disattivazione del controllo di sicurezza:un malintenzionato altera il file di stato per mostrare uno stato impreciso per una regola firewall o una policy di autorizzazione IAM. Il successivo comando Terraform apply potrebbe non applicare correttamente la configurazione sicura prevista.
|
| Mitigazioni |
Attiva il controllo delle versioni degli oggetti nel bucket Cloud Storage che archivia il file di stato. Il controllo delle versioni degli oggetti consente di recuperare il file di stato in caso di modifica accidentale o dannosa. Implementa controlli IAM rigorosi sul bucket del file di stato. Assicurati che solo il account di servizio CI/CD abbia accesso in scrittura e che gli sviluppatori abbiano al massimo accesso di sola lettura.
|
Escalation dei privilegi per gli script di avvio o bootstrap archiviati in Cloud Storage
Se un'istanza Compute Engine o un nodo GKE estrae i propri script di avvio o bootstrap da un bucket Cloud Storage, un malintenzionato con accesso in scrittura a quel bucket può modificare questi script. Poiché questi script vengono spesso eseguiti con privilegi elevati (ad esempio come root sulla VM o con il account di servizio del nodo), l'autore dell'attacco può inserire comandi per creare utenti backdoor, esfiltrare metadati e token di accesso o installare software dannoso. Queste azioni consentono a un malintenzionato di aumentare i privilegi dalle autorizzazioni di scrittura degli oggetti Cloud Storage al controllo completo delle risorse di calcolo.
| Categoria STRIDE |
Elevazione dei privilegi |
| Tattica MITRE ATT&CK |
Escalation dei privilegi |
| Manifestazioni |
Esfiltrazione di metadati:l'aggressore aggiunge comandi come curl -H 'Metadata-Flavor: Google' http://metadata.google.internal/... allo script di avvio per rubare token dell'account di servizio o altri secret. Reverse shell:l'attaccante inserisce un comando per avviare una reverse shell dall'istanza di computing a un server controllato dall'attaccante, concedendogli l'accesso interattivo.
|
| Mitigazioni |
Archivia gli script di avvio in un bucket Cloud Storage dedicato e controllato rigorosamente. Applica criteri di autorizzazione IAM con privilegi minimi in modo che solo gli amministratori autorizzati o le pipeline CI/CD possano modificare gli script. Valuta una strategia di classificazione dei dati in cui configuri i tag delle risorse nei bucket utilizzati per gli script di avvio e utilizza l'accesso condizionale basato su tag IAM per limitare ulteriormente l'accesso. Invece di estrarre gli script da Cloud Storage, includili nelle immagini macchina personalizzate. Questa strategia crea un artefatto immutabile meno soggetto a modifiche in fase di runtime.
|
Backdoor della catena di fornitura che utilizza i dati di addestramento ML ospitati in Cloud Storage
Un malintenzionato con accesso in scrittura a un bucket Cloud Storage che contiene dati di addestramento per un modello di machine learning può compromettere il set di dati. Inserendo dati dannosi creati con cura, l'attaccante può creare una backdoor nel modello addestrato. Questa backdoor può indurre il modello a classificare erroneamente input specifici in modo da avvantaggiare l'aggressore, comportandosi normalmente sui dati generali per evitare il rilevamento. Ad esempio, il modello potrebbe approvare transazioni fraudolente o ignorare i controlli di sicurezza.
| Categoria STRIDE |
Manomissione |
| Tattica MITRE ATT&CK |
Impatto |
| Manifestazioni |
Classificazione errata mirata:un malintenzionato inserisce dati compromessi che inducono un modello di rilevamento delle frodi addestrato a classificare sempre come legittime le transazioni provenienti da un account controllato dal malintenzionato. Evasione del modello: un malintenzionato compromette i dati di addestramento di un modello di rilevamento di malware con esempi di malware etichettati come benigni, facendo sì che il modello finale ignori i suoi strumenti specifici.
|
| Mitigazioni |
Implementa controlli dell'accesso rigorosi sui bucket Cloud Storage che contengono dati di addestramento. Applica il principio del privilegio minimo per concedere l'accesso in scrittura a questi bucket ed esegui regolarmente audit con strumenti come Policy Analyzer. Valuta una strategia di classificazione dei dati in cui configuri i tag delle risorse sui bucket utilizzati per i dati di addestramento ML e aggiungi condizioni basate sui tag IAM per limitare ulteriormente l'accesso. Esegui un audit per rilevare modifiche non autorizzate agli oggetti utilizzati per i dati di addestramento. Configura il controllo delle versioni degli oggetti, mantieni i checksum e configura i log di controllo dell'accesso ai dati per l'evento DATA_WRITE per facilitare il controllo delle anomalie per gli eventi di creazione degli oggetti correlati ai dati di addestramento. Esegui regolarmente l'audit e la convalida dei modelli ML per rilevare comportamenti imprevisti. Utilizza tecniche di test contraddittorio per rilevare backdoor o vulnerabilità nascoste introdotte durante l'addestramento. Configura un perimetro dei Controlli di servizio VPC per limitare l'accesso a risorse sensibili, come dati di addestramento e altri servizi coinvolti nella creazione di modelli, dall'esterno del perimetro attendibile.
|
Attacco Denial of Service utilizzando flussi di lavoro fan-out attivati dalla creazione di oggetti in Cloud Storage
Se un flusso di lavoro (ad esempio Cloud Run Functions o Workflows) è configurato per attivare la creazione di oggetti in un bucket Cloud Storage ed eseguire un'attività che richiede molte risorse, un malintenzionato con l'autorizzazione storage.objects.create può avviare un attacco Denial of Service. Caricando un numero elevato di file in un breve periodo (noto come trigger di fan-out), l'autore dell'attacco può causare lo scaling rapido del servizio downstream, consumando risorse eccessive, raggiungendo i limiti di concorrenza o di scalabilità e comportando costi significativi, con conseguente indisponibilità del servizio per gli utenti legittimi.
| Categoria STRIDE |
Denial of Service |
| Tattica MITRE ATT&CK |
Impatto |
| Manifestazioni |
Esaurimento delle risorse:un malintenzionato carica 10.000 file di piccole dimensioni, attivando 10.000 chiamate parallele di funzioni Cloud Run che esauriscono la quota di CPU, la memoria o i limiti di frequenza delle API downstream del progetto. DoS basato sui costi:il fan-out attiva un numero elevatissimo di esecuzioni in un servizio a pagamento, generando una fattura enorme e la potenziale sospensione dell'account, negando di fatto il servizio.
|
| Mitigazioni |
Implementa rigidi controlli dell'accesso sui bucket Cloud Storage che attivano i workflow. Applica il principio del privilegio minimo per concedere l'accesso in scrittura a questi bucket ed esegui regolarmente audit con strumenti come Policy Analyzer. Imposta limiti di concorrenza per le funzioni Cloud Run basate su eventi per controllare il numero massimo di esecuzioni parallele, evitando l'esaurimento delle risorse. Implementa un meccanismo di debouncing, che poi richiama la logica di elaborazione principale. Un esempio di meccanismo di debounce consiste nell'aggiungere un'attività a una coda Cloud Tasks con limitazione di frequenza. Questo meccanismo aiuta a gestire gli aumenti improvvisi del volume di richieste distribuendole nel tempo. Configura un perimetro dei Controlli di servizio VPC per limitare l'accesso a risorse sensibili, ad esempio la scrittura in un bucket che attiva un flusso di lavoro, dall'esterno del perimetro attendibile.
|
Spostamento non autorizzato di dati utilizzando pipeline di backup basate su Cloud Storage
Gli strumenti di backup e ripristino di emergenza spesso utilizzano Cloud Storage come area di gestione temporanea o destinazione finale per i backup. Se un malintenzionato compromette la configurazione di questo strumento, può reindirizzare i backup a un bucket Cloud Storage controllato dall'attaccante. Il account di servizio di backup spesso dispone di ampie autorizzazioni di lettura su molte origini dati (ad esempio database o VM), consentendo all'attaccante di esfiltrare grandi volumi di dati sensibili manipolando il parametro di destinazione del job di backup.
| Categoria STRIDE |
Divulgazione di informazioni |
| Tattica MITRE ATT&CK |
Esfiltrazione |
| Manifestazioni |
Reindirizzamento del job di backup:un malintenzionato con autorizzazioni per modificare una configurazione del job di backup cambia il percorso del bucket Cloud Storage di destinazione in gs://attacker-public-bucket/. Backup tra progetti:l'autore dell'attacco configura un nuovo job di backup all'interno di un progetto compromesso per leggere i dati da un'origine sensibile ed eseguirne il backup in un bucket di un altro progetto Google Cloud controllato dall'autore dell'attacco.
|
| Mitigazioni |
Assicurati che i service account dello strumento di backup dispongano di autorizzazioni con ambito limitato. Configura gli strumenti di backup in modo che possano scrivere solo in bucket di backup specifici e designati e non leggere da posizioni arbitrarie. Utilizza i Controlli di servizio VPC per impedire ai servizi di backup di accedere a origini dati sensibili e di scrivere nei bucket Cloud Storage al di fuori di un perimetro sicuro.
|
Policy bypass using legacy Cloud Storage ACL usage in hybrid environments
Cloud Storage supporta due sistemi di controllo dell'accesso reciprocamente esclusivi: IAM e ACL legacy. Quando l'accesso uniforme a livello di bucket è disabilitato, vengono valutati entrambi i sistemi. Un malintenzionato può sfruttare questa configurazione aggiungendo un ACL legacy (ad esempio, concedendo l'accesso a un account Google personale o a un gruppo pubblico) a un oggetto, anche se la policy di autorizzazione a livello di bucket sembra restrittiva. Questo attacco crea un percorso di accesso ombra che spesso non viene rilevato dagli scanner di sicurezza incentrati su IAM, consentendo all'aggressore di aggirare le norme di sicurezza previste.
| Categoria STRIDE |
Elevazione dei privilegi |
| Tattica MITRE ATT&CK |
Evasione della difesa |
| Manifestazioni |
Accesso pubblico a livello di oggetto: un malintenzionato con l'autorizzazione storage.objects.update aggiunge un ACL di lettura pubblica a un oggetto sensibile, rendendolo accessibile a chiunque su internet, aggirando una policy di autorizzazione del bucket restrittiva. Accesso cross-account:un malintenzionato assegna al proprio account esterno l'autorizzazione OWNER su un oggetto di configurazione critico utilizzando un ACL, consentendogli di modificare l'oggetto senza essere rilevato dagli audit IAM.
|
| Mitigazioni |
Abilita l'accesso uniforme a livello di bucket su tutti i bucket Cloud Storage. L'accesso uniforme a livello di bucket disabilita tutti gli ACL e garantisce che IAM sia l'unico metodo coerente per gestire l'accesso, semplificando gli audit e impedendo questo bypass. Utilizza il vincolo dei criteri dell'organizzazione constraints/storage.uniformBucketLevelAccess per applicare un accesso uniforme a livello di bucket a tutti i nuovi bucket di un progetto, una cartella o un'organizzazione.
|
Distruzione dei dati utilizzando pipeline CI/CD compromesse che hanno come target Cloud Storage
Alle pipeline CI/CD vengono spesso concessi service account con privilegi elevati per gestire l'infrastruttura e distribuire gli artefatti. Se un malintenzionato compromette il sistema CI/CD, può utilizzare il account di servizio della pipeline per eseguire azioni distruttive su Cloud Storage. Un esempio di compromissione è un aggressore che inserisce codice dannoso in uno script di build o ottiene l'accesso all'orchestratore. Questo compromesso può comportare l'eliminazione di bucket o la sovrascrittura di oggetti critici.
| Categoria STRIDE |
Manomissione |
| Tattica MITRE ATT&CK |
Impatto |
| Manifestazioni |
Passaggio di build dannoso:un malintenzionato aggiunge un passaggio a una pipeline CI/CD che cancella tutti i dati. Ad esempio, l'autore dell'attacco aggiunge un passaggio in cloudbuild.yaml che esegue un comando come gcloud storage rm -r gs://critical-bucket/. Ereditarietà dei privilegi:l'attaccante utilizza il account di servizio della pipeline compromessa, che dispone di ampie autorizzazioni, per concedere al proprio account l'accesso amministrativo ai bucket Cloud Storage per un utilizzo successivo.
|
| Mitigazioni |
Applica il principio del privilegio minimo ai service account CI/CD. Ad esempio, non assegnare a una pipeline di build le autorizzazioni per eliminare i bucket di produzione. Utilizza identità separate per le diverse fasi della pipeline, ad esempio build, test o deployment. Proteggi i bucket Cloud Storage critici dall'eliminazione attivando il blocco del bucket o dell'oggetto oppure assicurandoti che il account di servizio CI/CD non disponga dell'autorizzazione storage.buckets.delete.
|
Eliminazione non autorizzata di bucket utilizzando account break-glass con privilegi eccessivi
Gli account di accesso di emergenza o break-glass sono identità con privilegi elevati utilizzate solo in caso di emergenza. Se questi account non sono protetti e gestiti correttamente (ad esempio, le credenziali vengono divulgate o l'accesso non è limitato nel tempo), un malintenzionato che compromette un account di emergenza può eseguire azioni altamente distruttive. Un rischio principale è l'eliminazione di interi bucket Cloud Storage, che può portare a una perdita di dati catastrofica e irreversibile, poiché l'eliminazione dei bucket è un'azione permanente.
| Categoria STRIDE |
Elevazione dei privilegi |
| Tattica MITRE ATT&CK |
Escalation dei privilegi |
| Manifestazioni |
Perdita catastrofica di dati: un malintenzionato compromette un account di emergenza gestito in modo inadeguato ed esegue uno script per eliminare tutti i bucket Cloud Storage in un progetto. Estorsione:un malintenzionato ottiene l'accesso e minaccia di eliminare i bucket critici a meno che non venga pagato un riscatto.
|
| Mitigazioni |
Implementa l'accesso just-in-time (JIT) per le procedure di emergenza anziché utilizzare account con privilegi permanenti. Concedi le autorizzazioni on demand per un periodo di tempo limitato e per uno scopo specifico. Applica un blocco bucket ai bucket che contengono oggetti critici o un blocco oggetto ai singoli oggetti. I blocchi impediscono l'eliminazione del bucket e dei relativi oggetti, anche da parte degli utenti con autorizzazioni di proprietario, per un periodo di conservazione specificato.
|
Esfiltrazione silenziosa di dati utilizzando sink di logging compromessi che scrivono in Cloud Storage
Cloud Logging può essere configurato per esportare i log in un bucket Cloud Storage. Se un malintenzionato ottiene le autorizzazioni per modificare un sink di logging, può riconfigurarlo per esportare i log sensibili in un bucket Cloud Storage controllato dal malintenzionato in un altro progetto. L'esportazione dei log sensibili consente a un malintenzionato di esfiltrare in modo silenzioso e continuo i dati sensibili acquisiti nei log.
| Categoria STRIDE |
Divulgazione di informazioni |
| Tattica MITRE ATT&CK |
Esfiltrazione |
| Manifestazioni |
Reindirizzamento del sink di log:un malintenzionato modifica la proprietà di destinazione di un sink di log esistente in modo che punti al proprio bucket Cloud Storage. Creazione di filtri dannosi: un malintenzionato crea un sink con un filtro che prende di mira in modo specifico i log che contengono informazioni sensibili (ad esempio PII o token) e li esporta.
|
| Mitigazioni |
Monitora Cloud Audit Logs per le chiamate API CreateSink e UpdateSink. Configura gli avvisi per comunicare ai team di sicurezza eventuali sink di log nuovi o modificati per assicurarti che siano autorizzati. Configura un perimetro dei Controlli di servizio VPC per mitigare l'esfiltrazione di dati.
|
Attivazione del ransomware tramite la revoca centralizzata di CMEK
Quando i bucket Cloud Storage vengono criptati con CMEK, la disponibilità dei dati è legata alla disponibilità della chiave. Un malintenzionato che ottiene autorizzazioni sufficienti su Cloud KMS può eliminare o disabilitare la chiave utilizzata per un bucket Cloud Storage critico. Questa azione rende tutti i dati nel bucket inaccessibili a livello crittografico, di fatto una forma di distruzione dei dati o ransomware, in quanto i dati rimangono ma non possono essere decriptati.
| Categoria STRIDE |
Manomissione |
| Tattica MITRE ATT&CK |
Impatto |
| Manifestazioni |
Eliminazione della chiave:un malintenzionato con l'autorizzazione cloudkms.cryptoKeyVersions.destroy elimina definitivamente una versione della chiave, rendendo impossibile il recupero dei dati. Disattivazione della chiave:un malintenzionato con l'autorizzazione cloudkms.cryptoKeyVersions.disable disattiva una chiave, rendendo i dati di Cloud Storage illeggibili finché la chiave non viene riattivata. Questa azione può causare un'interruzione prolungata.
|
| Mitigazioni |
Applica una durata minima per lo stato Pianificato per l'eliminazione prima che le chiavi Cloud KMS possano essere eliminate. Per impostazione predefinita, questo periodo è di 30 giorni, ma puoi configurare un periodo da 1 a 120 giorni al momento della creazione iniziale di una chiave. Non puoi modificare questo periodo dopo l'eliminazione di una chiave. Valuta la possibilità di applicare il vincolo del criterio dell'organizzazione constraints/cloudkms.minimumDestroyScheduledDuration per garantire che le chiavi non possano essere create con un periodo di eliminazione pianificata inferiore al minimo previsto. Limita rigorosamente l'accesso ai ruoli amministrativi di Cloud KMS. Separa i compiti di utilizzo delle chiavi da quelli di amministrazione delle chiavi per impedire a un singolo account compromesso di utilizzare e distruggere le chiavi. Ruota periodicamente le chiavi Cloud KMS, scegliendo un periodo di rotazione in base ai requisiti di sensibilità o conformità del tuo workload.
|
Esfiltrazione di dati utilizzando snapshot o esportazioni di backup in Cloud Storage
Molti servizi Google Cloud (ad esempio Compute Engine o Cloud SQL) consentono di creare snapshot o esportare backup in Cloud Storage. Un malintenzionato con le autorizzazioni per eseguire queste operazioni di esportazione può creare uno snapshot di una risorsa che contiene dati sensibili e salvarlo in un bucket Cloud Storage con autorizzazioni meno restrittive, ad esempio un bucket pubblico o un bucket condiviso con un account esterno. Questa azione ignora i controlli dell'accesso più rigorosi della risorsa principale (ad esempio, le credenziali del database), poiché ora i dati sono accessibili utilizzando Cloud Storage IAM.
| Categoria STRIDE |
Divulgazione di informazioni |
| Tattica MITRE ATT&CK |
Esfiltrazione |
| Manifestazioni |
Snapshot del disco nel bucket pubblico:uno sviluppatore interno con autorizzazioni compute.snapshots.create e storage.objectAdmin crea uno snapshot di un disco VM che contiene secret e lo esporta in un bucket Cloud Storage pubblico. Esportazione del database:un malintenzionato con l'autorizzazione cloudsql.instances.export esporta un database di produzione in un bucket Cloud Storage in un progetto controllato dal malintenzionato.
|
| Mitigazioni |
Assicurati che i progetti designati per i backup e gli snapshot abbiano policy IAM e Controlli di servizio VPC almeno altrettanto rigorose di quelle dei progetti di origine per mantenere una postura di sicurezza coerente. Valuta una strategia di classificazione dei dati in cui configuri i tag delle risorse sui bucket utilizzati per i backup e aggiungi condizioni di accesso basate su tag IAM per limitare ulteriormente l'accesso.
|
