Cloud Intelligence™Cloud Intelligence™

Cloud Intelligence™

La sua API key Google potrebbe finanziare l'AI di qualcun altro

By John D'EliaMay 11, 20265 min read

Questa pagina è disponibile anche in English, Deutsch, Español, Français, 日本語 e Português.

In sintesi

  • Generare contenuti con l'API di Gemini sfruttando API key mal configurate è diventato lo sport del momento. Continui a leggere prima che tocchi a lei.
  • Abbiamo rilasciato uno strumento di scansione open source e gratuito per individuare le API key problematiche: https://github.com/doitintl/gcp-apikey-check

Cosa sta succedendo

Noi di DoiT, quando si parla di cloud, ne vediamo davvero di tutti i colori. Negli ultimi tempi dalla community arrivano sempre più segnalazioni di brutte sorprese in fattura legate a Gemini. L'utente magari non usa nemmeno Gemini nelle proprie applicazioni, eppure si ritrova con conti salatissimi per la generazione di contenuti, spesso immagini o video, che fanno lievitare la spesa più velocemente di quanto gli avvisi di fatturazione possano allertarla. Se utilizza API key Google da qualche parte, continui a leggere: le sue chiavi potrebbero essere a rischio.


Come accade

Google Cloud, come tutti gli altri cloud provider, si basa su un modello di responsabilità condivisa: Google risponde dell'infrastruttura sottostante, mentre gli utenti sono responsabili della sicurezza nell'utilizzo di tale infrastruttura. Google adotta un unico formato di API key (AIza...) per due scopi molto diversi: identificatori pubblici di progetto e credenziali di autenticazione sensibili.

Le problematiche legate alle API key di Google Maps e Firebase si trascinano da tempo: in fase di creazione, l'impostazione predefinita era senza alcuna restrizione e spettava allo sviluppatore limitare l'ambito delle API e vincolarle a siti web, indirizzi IP o SDK specifici. Cosa che non sempre accadeva. Le API key di Google Maps e Firebase, peraltro, finiscono spesso nel codice frontend dei client, quindi non sono particolarmente private e fungono più che altro da identificatori per la fatturazione.

I guai sono cominciati quando l'API di Gemini è stata abilitata nello stesso progetto in cui erano già presenti chiavi Maps o Firebase senza restrizioni. Una volta scoperte queste chiavi, gli attori malevoli hanno imparato in fretta a sfruttarle.

Quando l'API di Gemini viene abilitata in un progetto Google Cloud, ogni API key esistente che non sia vincolata ad API specifiche all'interno di quel progetto può accedere silenziosamente agli endpoint di Gemini. Nessun avviso. Nessuna email. Nessuna conferma. Una chiave Maps che ha incorporato nel suo sito anni fa potrebbe oggi essere una credenziale Gemini perfettamente funzionante, esposta nel codice sorgente della pagina alla portata di chiunque.

Un altro vettore di esposizione delle chiavi è il commit accidentale di API key o di Service Account key statiche su repository GitHub pubblici. In passato venivano rapidamente intercettate da malintenzionati e usate per attività di cripto-mining; oggi Google è diventato più bravo a riconoscere frodi di questo tipo.


Cosa ne fa un aggressore

L'attacco è banale. Un attore malevolo apre il codice sorgente della sua pagina, copia la chiave AIza... e richiama l'API di generazione immagini di Gemini. Tutto qui. Nessun accesso alla sua infrastruttura, nessuna credenziale da rubare, nessun exploit sofisticato. Solo la sua chiave e una richiesta HTTP, ripetuta molte volte in rapida successione e interamente addebitata sul suo account.


È esposto?

Provi a rispondere a queste domande:

  1. Le API Generative Language o Gemini Agent Platform (in precedenza Vertex AI) sono abilitate in uno qualsiasi dei suoi progetti GCP?
  2. Esistono API key prive di restrizioni di API o di applicazione?
  3. Le chiavi Maps o Firebase condividono la stessa key con le API di AI?
  4. Possiede Service Account key vecchie, inutilizzate o con ruoli owner o editor?

Se gestisce più di una manciata di progetti, verificarlo manualmente sull'intera organizzazione non è realistico.


Scansioni la sua organizzazione in pochi minuti

In DoiT lavoriamo ogni giorno al fianco dei clienti Google Cloud. Abbiamo creato gcp-apikey-check per offrire all'intera community la stessa visibilità di cui dispongono i nostri clienti: gratis e open source.

Terminal window
git clone https://github.com/doitintl/gcp-apikey-check
cd gcp-apikey-check
uv sync
# Scan an entire organization
uv run gcpkeyscan.py --org-id YOUR_ORG_ID
# Or scan a single project
uv run gcpkeyscan.py --project-id YOUR_PROJECT_ID

Lo strumento analizza le API key alla ricerca delle configurazioni errate che generano questi picchi di spesa: chiavi senza restrizioni, API Maps e AI sulla stessa key, chiavi Firebase prive di restrizioni applicative e regole di referrer con wildcard troppo permissive. Inoltre, segnala le Service Account key vecchie, inutilizzate o con permessi eccessivi e verifica se le policy della sua organizzazione consentono la creazione di SA key. I risultati sono classificati per gravità (CRITICAL / HIGH / MED) ed esportati in JSON e CSV, così può intervenire subito.


Metta in sicurezza tutto e si chieda se le servono davvero delle chiavi

La cosa più importante da capire è questa: la migliore API key è non avere alcuna API key.

Le stesse best practice di Google parlano chiaro: eviti le API key e le Service Account key ovunque sia possibile. Le API key non hanno un'identità, per impostazione predefinita non hanno scadenza e non offrono un audit trail granulare. Per i servizi di backend e i workloads su GCP esiste quasi sempre un'alternativa migliore:

  • Utilizzi Workload Identity Federation al posto delle Service Account key per l'autenticazione server-to-server
  • Sfrutti le Application Default Credentials con ruoli IAM per i workloads in esecuzione su GCP
  • Richiami Gemini lato server con un IAM configurato correttamente: non esponga mai una chiave nel codice client-side

Se deve per forza usare API key, ad esempio per gli embed di Maps, gli SDK client di Firebase o altri casi d'uso client-side legittimi, le limiti come si deve:

  • Restringa ogni chiave alle sole API di cui ha effettivamente bisogno
  • Aggiunga restrizioni applicative: referrer HTTP per il web, bundle ID per il mobile, intervalli IP per i server
  • Non condivida mai le chiavi Maps o Firebase con Gemini o con qualsiasi altra API di AI
  • Disabiliti le API che non sta utilizzando attivamente
  • Imposti avvisi di fatturazione, in modo che un picco non passi inosservato per giorni

Per le Service Account key che non riesce ancora a eliminare: ruoti tutte quelle più vecchie di 90 giorni, rimuova i ruoli owner ed editor ed elimini le chiavi che non sono state utilizzate di recente.

Per fortuna Google ha reso più restrittive le impostazioni predefinite delle nuove API key: non è più possibile crearne una completamente priva di restrizioni. Anche Google AI Studio genera nuove API key vincolate alla sola API di Gemini. Non risolve tutti i problemi, ma default più ragionevoli sono comunque un aiuto.


Non aspetti la fattura

Google si sta muovendo per introdurre impostazioni predefinite più solide, ma resta da capire quando arriveranno questi cambiamenti e se serviranno davvero a proteggere le chiavi già distribuite nei suoi progetti. Gli sviluppatori che raccontano di addebiti inattesi non sapevano di essere esposti finché non era ormai troppo tardi.

Esegua oggi stesso la scansione. Scopra cosa ha in casa. Sistemi i casi più gravi e si muova poi verso l'eliminazione totale delle chiavi, ovunque sia possibile.

https://github.com/doitintl/gcp-apikey-check