Chiavi API dimenticate: come revocarle senza fermare il servizio

Una verifica interna di OpenRouter ha rilevato più di 1.000 chiavi API attive per 85 dipendenti; secondo l’azienda, 168 chiavi non venivano utilizzate da mesi. Sono cifre di un’autoverifica di OpenRouter, non di uno studio indipendente sul settore. Ma anche come esempio specifico mostrano una trappola ingegneristica ben nota: è facile dimenticare una chiave, ma non l’applicazione che dipende da essa. L’azienda ha datato al 28 settembre 2026 l’annuncio del Security Center.

Il problema non consiste semplicemente nel trovare la credenziale più vecchia ed eliminarla. Il team deve individuare il responsabile, capire dove viene usata la chiave e come sostituirla senza interrompere un’attività rara o un servizio dimenticato. Senza queste informazioni, revocare l’accesso trasforma un’operazione di pulizia in un esperimento rischioso.

Cosa mostra il Security Center e cosa non dimostra

Secondo la descrizione di OpenRouter, il Security Center riunisce le chiavi dell’account e ne mostra il responsabile, l’ultimo utilizzo, il limite di spesa e la scadenza; gli amministratori dell’organizzazione vedono tutte le chiavi, mentre i membri vedono quelle che hanno creato. Per le operazioni in blocco è possibile selezionare fino a 500 chiavi e disattivarle, archiviarle o impostare un limite di spesa. La disattivazione è reversibile, l’archiviazione no. Sono caratteristiche dello strumento descritte dal fornitore stesso, non una valutazione indipendente della sua efficacia.

È particolarmente importante considerare lo stato «eliminabile» come un invito a verificare, non come prova dell’assenza di dipendenze. La metrica di utilizzo mostra le richieste passate, ma non necessariamente spiega a quale processo cron, scenario di emergenza o attività stagionale appartenga una chiave. OpenRouter stesso consiglia di confermare l’eliminazione con il responsabile; anche la documentazione sulle impostazioni di sicurezza avverte di verificare le dipendenze prima di disattivare o archiviare una chiave.

Le restrizioni di rete prevedono una precisazione distinta: l’IP allowlist è disponibile agli amministratori del piano Enterprise e si applica a tutte le chiavi dell’organizzazione. Le richieste provenienti da indirizzi non inclusi nell’elenco vengono rifiutate con un errore 403 e le modifiche hanno effetto immediato. Prima di attivare la restrizione, occorre quindi considerare gli indirizzi dei server di produzione, della rete dell’ufficio e dei runner CI; altrimenti la misura di sicurezza stessa potrebbe interrompere chiamate legittime.

Procedura di pulizia: prima il responsabile, poi la revoca

1. Fate un inventario. Per ogni chiave registrate il responsabile, lo scopo, l’ambiente, i sistemi che la utilizzano, il limite di spesa e la scadenza. Se il sistema indica come responsabile soltanto una persona, assegnate anche la responsabilità a un team o a un servizio, che se ne occuperà in caso di uscita della persona dall’azienda.
2. Verificate l’utilizzo e le dipendenze. Confrontate l’orario dell’ultima richiesta con le pianificazioni delle attività in background, gli scenari di ripristino, le pipeline di rilascio e le integrazioni esterne. L’assenza di attività recente è un motivo per chiedere al responsabile, non una ragione sufficiente per eliminare subito la chiave.
3. Riducete il rischio prima della migrazione. Dove è supportato, impostate un limite di spesa ragionevole e una scadenza. Seguite il principio del privilegio minimo e le regole per la conservazione dei segreti: la guida OWASP alla gestione dei segreti considera inventario, accesso e ciclo di vita delle credenziali come fasi distinte del processo.
4. Create una chiave sostitutiva e migrate i sistemi che la usano. Aggiornate il segreto nell’archivio o nella configurazione di distribuzione, quindi trasferite le applicazioni gradualmente. Non inserite il valore della chiave nei ticket, nei log o nel codice sorgente.
5. Verificate la produzione prima della revoca. Assicuratevi che la nuova chiave funzioni in tutti i sistemi noti che la utilizzano, inclusi CI e le attività meno frequenti. Poi disattivate prima la vecchia chiave, se è disponibile un’operazione reversibile; archiviatela o eliminatela dopo aver confermato la migrazione e aver completato il periodo di osservazione concordato.

La sequenza «creare una nuova chiave → trasferire le applicazioni → verificare il funzionamento → eliminare la vecchia» coincide con le istruzioni di OpenRouter per la rotazione. È una procedura consigliata, non una garanzia di assenza di interruzioni: il risultato dipende dall’aver individuato tutti i sistemi che utilizzano la credenziale.

Le chiavi di un servizio non sono tutti i segreti dell’organizzazione

La dashboard di un singolo fornitore aiuta a gestire le chiavi di quel servizio, ma da sola non centralizza i segreti di cloud, database, CI/CD e altre API. Le raccomandazioni generali di OWASP sul ciclo di vita dei segreti comprendono archiviazione centralizzata, controllo degli accessi, audit, rotazione e revoca. Anche le raccomandazioni di Google Cloud consigliano di limitare l’ambito di utilizzo delle chiavi, eliminare le credenziali non necessarie e monitorarne l’utilizzo.

OpenRouter afferma inoltre che il Security Center utilizza metadati delle chiavi, spese e scadenze, senza leggere prompt e risposte. È una dichiarazione del fornitore stesso; tra le fonti esaminate non è stata trovata alcuna verifica tecnica indipendente. E, più in generale, la disponibilità di una dashboard non dimostra che il team abbia già ridotto il numero di incidenti o i costi: nei materiali esaminati non sono stati trovati risultati pubblici successivi al lancio.