Proteggere le chiavi API: la lezione di LiteLLM e Railway

Le chiavi API sono il lasciapassare della tua infrastruttura digitale. Se finiscono in mano sbagliata, chi le possiede accede ai tuoi provider AI, svuota i crediti, ruba dati. Il 21 ottobre 2026 il mondo della automazioni AI ha visto due incidenti che ripetono la stessa lezione: LiteLLM (la libreria Python per orchestrare modelli AI) è stata compromessa con una versione malevola che spiava le variabili d'ambiente, e Railway (piattaforma di hosting popolare tra developer) ha subito un accesso ai dati ambientali degli utenti. In entrambi i casi, le chiavi API finivano in chiaro in log e processi accessibili.

Se usi LiteLLM, Railway, oppure semplicemente gestisci chiavi API in progetti di automazioni o agenti AI, questo articolo è per te. Non è una questione di "se", ma di "quando" e di "come prima".

In breve: le chiavi API non vanno mai committa su git, non vanno scritte in file di config in plain text, e non vanno lasciate nei log. Usa un vault per i segreti (Doppler, HashiCorp Vault, il secrets manager del tuo provider), ruota le chiavi periodicamente, monitora l'uso con rate limiting, e segmenta le autorizzazioni: una chiave per un servizio, non una master key per tutto.

Cosa è successo il 21 ottobre: LiteLLM 1.107.0 e Railway

Il 21 ottobre è stata rilasciata una versione corrotta di LiteLLM (la 1.107.0) che conteneva del codice malevolo. Questo codice non faceva niente di vistoso nel tuo Python script: non rubava i tuoi dati direttamente. Ma catturava le variabili d'ambiente (environment variables) e le spediva su un server esterno, non autorizzato. In un progetto che usa LiteLLM, le variabili d'ambiente contengono le chiavi API per OpenAI, Claude, Gemini, Stripe, e tutto il resto.

Nello stesso periodo, Railway (che ospita app e progetti) ha avuto un accesso non autorizzato al database interno che memorizza le variabili d'ambiente degli utenti. In altre parole, il suo vault dei segreti è stato esposto. Chi aveva un progetto su Railway con chiavi API dentro le env var (e praticamente tutti le mettono lì) ha rischiato di vederle copiate.

Sono due attacchi diversi sul piano tecnico, ma identici sul piano strategico: entrambi sfruttano il fatto che sviluppatori e aziende mettono le chiavi API dove le variabili d'ambiente finiscono, e poi non le proteggono abbastanza.

Dove finiscono le chiavi API (e perché è un problema)

Le chiavi API vanno memorizzate da qualche parte. Il posto più comodo è una variabile d'ambiente: la scrivi una volta, il tuo codice la legge, e sembra fatto. Ma le variabili d'ambiente:

• Finiscono nei log quando il tuo script fallisce e stampa gli errori.
• Rimangono in memoria se il processo non termina correttamente.
• Si vedono in chiaro in ps aux se qualcuno accede al server.
• Vengono incluse nei backup dei container se non le escluidi.
• Si copiano nei file di dump quando il sistema fa un crash.
• Sono leggibili da qualunque container o processo sullo stesso host se la sandboxing non è perfetta.

Un attacco come quello di LiteLLM sfrutta esattamente questo: il fatto che il codice che gira sul tuo server ha accesso alle variabili d'ambiente, e niente lo impedisce di leggerle e trasmetterle.

Come proteggere le chiavi API: il vault

La soluzione vera è non mettere mai le chiavi API nelle variabili d'ambiente come plain text, o almeno non lasciarle lì disponibili in chiaro a qualunque cosa gira sul tuo server.

Usi un vault: un servizio (separato dal tuo server di produzione, con accesso controllato e auditato) che memorizza i segreti in forma crittografata e li rilascia solo a chi ha prove di identità valide.

I servizi più comuni sono:

• Doppler: pensato per team e startup, dashboard web, sincronizzazione automatica nei tuoi ambienti, CLI comoda.
• HashiCorp Vault: il classico, più complesso, self-hosted o cloud, usato in aziende grandi.
• AWS Secrets Manager: se sei già su AWS, è integrato e basta.
• Google Cloud Secret Manager: analogo per Google Cloud.
• Azure Key Vault: per chi usa Microsoft.
• 1Password Business: non solo password, anche segreti e chiavi, con accesso controllato.

Il flusso è: il tuo codice si autentica verso il vault (con un token o una credenziale specifica per quel servizio), il vault controlla se quello script ha diritto di leggere quella chiave, e se sì la rilascia. Il vault traccia chi ha richiesto cosa e quando. La chiave non finisce mai in una variabile d'ambiente leggibile in chiaro nel tuo processo.

Rotazione: cambiate le chiavi regolarmente

Dopo l'incidente di LiteLLM e Railway, la prima cosa che hanno dovuto fare i developer è stata rigenerare tutte le chiavi API. Perché anche se la chiave è stata rubata il 21 ottobre, tu potrai scoprirlo il 31 ottobre. Nel frattempo, il malintenzionato la usa tutti i giorni.

La rotazione non è una cosa che fai una volta all'anno per compliance. È un'abitudine operativa:

• Ruota le chiavi che usi spesso (API di provider, database, provider di hosting) ogni 30-90 giorni.
• Ruota subito quelle che hanno accesso critico (admin token, chiavi root).
• Ruota tutte le chiavi non appena sospetti un leak o un accesso non autorizzato.

Molti developer non lo fanno perché è noioso: cambiare una chiave vuol dire andare nel dashboard del provider, generare una nuova, aggiornarla nel vault, rideploy dell'app, e verificare che nulla sia rotto. Automatizza il flusso se puoi.

Segmentazione: una chiave per un servizio, non una master key

Spesso accade di creare un'unica chiave API "generale" che dà accesso a tutto: OpenAI, Stripe, il database, il file storage. Così è facile da gestire. Ma è anche il peggior errore strategico: se quella chiave viene rubata, il malintenzionato ha il passpartout di tutto il tuo sistema.

Fai il contrario:

• Una chiave API per OpenAI, con limiti di rate e di spesa.
• Una chiave separata per Claude.
• Un token diverso per accedere a Stripe (e che non può creare transazioni, solo leggere).
• Credenziali separate per il database.

Se una chiave viene compromessa, il danno è circoscritto. Inoltre, il malintenzionato non sa quante altre chiavi ci sono o dove le usi.

Monitoring e alert: sapere quando qualcosa non va

Proteggi le chiavi, ma anche monitora il loro uso. Se una chiave API riceve 100 richieste al minuto mentre il tuo codice ne fa una al secondo, c'è un problema.

Imposta alert su:

• Spike di richieste a un'API (il tuo progetto fa 10 call/minuto, ma ne vede 1000: alert).
• Richieste da IP inaspettati.
• Errori di autenticazione in aumento.
• Variazioni anomale di costo su provider come OpenAI o Stripe.

Molti provider (OpenAI, Stripe, Anthropic) offrono questi alert nativamente nel loro dashboard. Leggili.

Vibe Coding e sicurezza

Se fai vibe coding (usi agenti AI e MCP per automatizzare compiti), il rischio di chiavi esposte è più alto perché l'agente AI ha accesso a molti servizi. Segui ancora più rigorosamente:

• L'agente legge le chiavi solo da un vault, non da variabili d'ambiente hardcodificate.
• Dai all'agente permessi minimi: non il token admin di OpenAI, ma una chiave con limite di spesa.
• Monitora il consumo di token dell'agente: se improvvisamente usa 10 volte la sua media, un'altra mano potrebbe aver preso il controllo.

Supply chain: non basta aggiornare

L'attacco a LiteLLM è stato un attacco alla supply chain: il codice malevolo non era nel tuo repo, era nel pacchetto npm/pip che importi. Non potevi vederlo nel tuo codice. Solo chi controllava LiteLLM sapeva che stava succedendo.

La lezione: aggiornare le dipendenze non basta. Quando aggiorni, sappi che stai aggiornando; non è automatico. Usa un servizio come Dependabot (Github) o Snyk che ti avvisa quando una dipendenza ha una vulnerabilità nota, e quando la tiri in una versione che non conosci ancora, la quarantena in uno stage environment prima di metterla in produzione.

Se usi un agente AI per gestire il tuo progetto (per esempio un MCP che deploya codice), assicurati che:

• L'agente aggiorna le dipendenze solo in un branch, non in main.
• Un umano rivede l'update prima che sia live.
• C'è un revert automatico se le metriche cambiano dopo il deploy.

Checklist operativa per proteggere le chiavi API

1. Crea un vault per i segreti: se sei una piccola azienda e usi AWS, inizia con Secrets Manager. Se preferisci qualcosa di agnostico cloud, Doppler è più semplice. Se vuoi self-hosted e controllo totale, HashiCorp Vault.
2. Sposta tutte le chiavi API dal codice al vault: cerca nel tuo repo .env, config.js, secrets.py e tutto quello che contiene una chiave. Muovi in vault, aggiorna il codice per leggerle dal vault.
3. Abilita il logging e l'audit: il vault deve tracciare chi ha letto quale segreto, quando, da dove. Leggi quei log una volta a settimana.
4. Imposta l'accesso al vault su ruoli: solo il tuo servizio di produzione può leggere la chiave di OpenAI. Il tuo ambiente di staging legge una chiave diversa (una test key, con limite di spesa).
5. Rigenera tutte le chiavi critiche oggi: LiteLLM e Railway sono stati incidenti pubblici. Se eri affetto, rigenerare subito è il minimo. Se non eri affetto, rigenerare ogni 90 giorni.
6. Imposta rate limiting e limiti di spesa: in OpenAI, Stripe, Anthropic, puoi creare una chiave che spende massimo 10 $ al giorno. Usala, non la master key.
7. Monitora il consumo API: metti un alert se il costo giornaliero di OpenAI sale oltre una soglia normale. Se un malintenzionato ha la tua chiave, lo scopri il giorno stesso.
8. Revedi le dipendenze Python e Node: se usi LiteLLM, aggiorna alla versione successiva a 1.107.0. Usa pip list o npm list e controlla che nessuno dei tuoi pacchetti sia in una versione nota come compromessa. Snyk.io offre un servizio gratuito di scansione.
9. Automatizza la rotazione delle chiavi: se puoi, scrivi uno script che rigenera la chiave ogni 90 giorni e la aggiorna nel vault. Niente di manuale.
10. Documenta dove sono le chiavi e chi può accedervi: scrivi una riga in un documento interno: "La chiave OpenAI è in Doppler, nel vault production. Solo il servizio api-server la legge. La rotoliamo il primo lunedì di ogni trimestre."

Gli errori da evitare

• Committare le chiavi su Git: anche se il repo è privato. Se il repo viene reso pubblico per sbaglio, le chiavi sono pubbliche. Usa .gitignore per escludere .env e file simili.
• Usare la stessa chiave in locale e in produzione: in locale, usa una chiave test con limite di spesa. In produzione, usa una chiave separata con monitoring. Se smarrisce il laptop di uno sviluppatore, la chiave locale è esposta, non quella di produzione.
• Mettere le chiavi dentro i commenti del codice: capita quando un developer scrive // API_KEY=sk-12345 come nota. Ripulisci il git history con git filter-branch se è successo.
• Lasciare le chiavi nei log: configura i tuoi logger per escludere campi sensibili. Se usi Node, usa pino o winston con un redactor. In Python, scrivi un logger custom che maschera i token.
• Non testare il vault: prima di mettere il vault in produzione, fai un test: il tuo codice legge davvero da lì? Cosa succede se il vault è down? Hai un fallback?
• Dimenticare i segreti nei template del container: se usi Docker, non buildare l'immagine con una chiave dentro il Dockerfile. Passa le chiavi via variabili d'ambiente a runtime, dal vault.
• Non monitorare l'uso delle chiavi: se non hai alert, scopri il leak quando arriva la fattura di 50.000 $ da OpenAI. Accendi gli alert.

Domande frequenti su proteggere le chiavi API

Quanto costa un vault come Doppler o HashiCorp?

Doppler parte da gratuito (fino a 50 segreti per un team piccolo), poi 7 $/utente/mese. HashiCorp Vault self-hosted è gratis, ma devi hostarla tu (costo del server). HashiCorp Cloud Platform costa 0.20 $/mille richieste.

Se uso già AWS, servire AWS Secrets Manager basta?

Sì, se il tuo progetto è tutto su AWS. Se hai servizi su AWS, Heroku e Vercel, AWS Secrets Manager non reach tutti. Doppler raggiunge ovunque. Valuta in base alla tua architettura.

Posso rotare una chiave mentre il servizio è in produzione?

Sì, se il vault supporta la lettura della versione più recente di una chiave. Aggiorna la chiave nel vault, il tuo codice legge la nuova versione, nessun downtime. Verifica prima in staging.

Che succede se il vault va down?

Se il vault non raggiunge per 30 secondi, il tuo servizio di produzione non può leggere le chiavi e fallisce. Per questo molti usano un cache locale (il vault fornisce la chiave, la app la cachea per 5-10 minuti) oppure un fallback a una chiave backup (meno ideale, ma migliore di un crash).

Come faccio a scoprire se una mia chiave è stata rubata?

Se è pubblicata online, servizi come GitGuardian o TruffleHog la trovano e ti avvisano. Se è stata rubata privatamente (come in LiteLLM), lo scopri dal monitoring: spike di richieste, costi anomali. Per questo gli alert sono critici.

Un agente AI può accedere al vault?

Sì, un agente AI (MCP o un custom tool) può autentica al vault e leggere le chiavi che gli servono. L'importante è usare le stesse best practice: segmentazione (chiave limitata per quell'agente), monitoring, audit.

Il punto centrale

Le chiavi API sono il perimetro di sicurezza della tua infrastruttura. Se sono rubate, il malintenzionato entro in casa tua. Gli incidenti di LiteLLM e Railway il 21 ottobre insegnano una cosa sola: metti un vault fra le chiavi e il mondo, segmenta i permessi, ruota regolarmente, monitora sempre.

Inizia da qui: oggi rigenera le chiavi critiche (OpenAI, Stripe, database). Domani, metti un vault. La settimana prossima, imposta gli alert. Non è una cosa che fai una volta. È un'abitudine che protegge il tuo business ogni giorno.