Abuso delle API Key di Gemini: la soluzione c'è, ma ha una scadenza

In sintesi

• Google dismetterà progressivamente le API key standard per la Gemini API in due fasi: le key standard senza restrizioni smetteranno di funzionare il 19 giugno 2026; tutte le key standard smetteranno di funzionare a settembre 2026
• Se ha key senza restrizioni, il tempo per limitarle o migrare al nuovo tipo di auth key è ormai poco
• Le nuove "authorization key" sono legate a un service account, una misura che chiude il vettore di abuso che avevo trattato in un articolo precedente
• Usi il nostro scanner gratuito per individuare le key esposte: github.com/doitintl/gcp-apikey-check

Un po' di storia

Qualche settimana fa ho raccontato come alcuni malintenzionati riuscissero a recuperare API key di Google prive di scope e di restrizioni da pagine web o pubblicate per errore. Una volta ottenute le key, questi soggetti generavano in fretta contenuti con Gemini per poi sparire, lasciando ai proprietari ignari bollette Gemini salate, in genere di decine di migliaia di dollari, a volte anche di più. Ne abbiamo visti parecchi casi e il sub-reddit googlecloud è pieno di storie da incubo.

Di recente Google ha modificato il comportamento delle API key di Gemini di nuova creazione. Sembra che finalmente stia intervenendo per chiudere la falla anche sulle key esistenti, e la cosa riguarderà chi usa la Gemini API. Le novità sono positive, ma le scadenze sono molto strette!

Cosa cambia

Google sta facendo passare la Gemini API dalle key standard alle authorization (auth) key.

Le key standard associano le richieste a un progetto Google Cloud per fatturazione e quota, ma non identificano chi effettua la chiamata. Non c'è alcuna identità del chiamante, e questo limita i controlli di accesso applicabili.

Le auth key, invece, sono legate a uno specifico service account di Google Cloud. Le richieste effettuate con un'auth key vengono elaborate sotto l'identità di quel service account, abilitando un controllo degli accessi basato su IAM. Google segnala inoltre che le auth key beneficeranno di controlli antifrode più reattivi.

Le scadenze della migrazione:

• 19 giugno 2026: la Gemini API rifiuterà le richieste provenienti da key standard senza restrizioni. Le key standard con restrizioni API esplicite continueranno a funzionare.
• Settembre 2026: la Gemini API rifiuterà le richieste provenienti da tutte le key standard. Entro quella data dovrà essere passato alle auth key.

Tutte le key nuove e create di recente in Google AI Studio sono già auth key per impostazione predefinita.

In che modo aiutano le Auth Key?

Con una key standard priva di scoping delle API, qualsiasi malintenzionato che la trovava poteva provarla sulla Gemini API e iniziare a generare contenuti addebitati sul suo account. È esattamente l'attacco descritto nel mio articolo precedente.

Le auth key chiudono questa falla in diversi modi. Per impostazione predefinita sono limitate alla Gemini API, quindi un'auth key trapelata non può essere usata con altre API di Google. Soprattutto, sono legate a un service account: questo consente di applicare i controlli di accesso IAM, cosa che con le key standard non era possibile. Le richieste effettuate con un'auth key compaiono inoltre negli audit log, e i sistemi di rilevamento dei secret esposti di Google possono reagire più rapidamente, perché c'è un'identità da revocare.

Detto questo, le auth key non sono una soluzione perfetta. Auth key trapelate o esfiltrate potrebbero comunque essere usate per generare contenuti e far lievitare la bolletta. Quanto siano efficaci i sistemi antifrode di Google in questi casi, ancora non lo sappiamo.

La soluzione migliore è non usare affatto le API key. Se utilizza Gemini sul backend, valuti la migrazione alla Gemini Enterprise Agent Platform, che si basa su credenziali IAM a breve durata anziché su key statiche: niente da esporre, niente da ruotare.

Cosa fare

Entro il 19 giugno 2026: metta in sicurezza le key standard senza restrizioni

Usi lo scanner per individuare le key senza restrizioni nella sua organizzazione GCP:

git clone https://github.com/doitintl/gcp-apikey-check
cd gcp-apikey-check
uv sync

# Scan an entire organization (**recommended**)
uv run gcpkeyscan.py --org-id YOUR_ORG_ID

# Or a single project
uv run gcpkeyscan.py --project-id YOUR_PROJECT_ID

Per ogni key senza restrizioni individuata, ha due possibilità:

Opzione 1 — Limitare la key (guadagna tempo fino a settembre): In Google AI Studio, apra la pagina API Keys, individui le key contrassegnate come "Unrestricted", passi il cursore sull'etichetta, faccia clic su "Add restrictions" e selezioni "Restrict to Gemini API only."

Opzione 2 — Migrare subito a un'auth key (consigliata):

1. Vada su AI Studio API Keys
2. Faccia clic su "Create API key" — ora le nuove key sono auth key per impostazione predefinita
3. Aggiorni il codice dell'applicazione, le variabili d'ambiente e le configurazioni di deploy con la nuova key
4. Testi, testi e poi testi ancora
5. Elimini o revochi la vecchia key standard

In caso di problemi, faccia riferimento alla documentazione di migrazione di Google per ulteriori dettagli.

Entro settembre 2026: migri tutte le key standard rimanenti

Le key standard che ha limitato nel primo passaggio smetteranno di funzionare a settembre. Segua gli stessi passaggi di migrazione descritti sopra per creare auth key sostitutive e aggiornare le sue applicazioni.

Il quadro d'insieme

Passare alle auth key è un passo avanti, ma la best practice di fondo non cambia.

Per la maggior parte dei workloads su Google Cloud, Workload Identity Federation e Application Default Credentials con ruoli IAM restano le opzioni preferibili: nessuna key da esporre, nessuna rotazione da gestire, audit trail adeguati per impostazione predefinita. Se utilizza la Gemini API in produzione, le consigliamo di passare alla Gemini Enterprise Agent Platform, che si basa su credenziali a breve durata anziché su API key statiche e offre altre funzionalità utili in produzione, come il supporto del vendor.

Per le applicazioni Maps e Firebase, invece, queste key restano API key standard; tuttavia, è bene seguire le best practice: limiti ciascuna key alle specifiche API necessarie, aggiunga restrizioni a livello applicativo e non metta mai le key di Maps o Firebase sulla stessa key di Gemini o di altre API di AI. Se possibile, tenga le key di Gemini in un progetto separato, per maggiore sicurezza.

Prossimi passi

La scadenza del 19 giugno è ormai alle porte. Se non ha ancora fatto l'audit delle sue key, lo faccia subito:

• Faccia lo scan dell'organizzazione: github.com/doitintl/gcp-apikey-check
• Approfondimento sul vettore di abuso: Your Google API Key Might Be Paying for Someone Else's AI
• Guida alla migrazione di Google: ai.google.dev/gemini-api/docs/api-key#migrate-to-auth-key
• Guida alla migrazione alla Google Enterprise Agent Platform: docs.cloud.google.com/gemini-enterprise-agent-platform/models/migrate/migrate-google-ai.