Rotazione chiave API: revoca la vecchia dopo la migrazione

Per cambiare una chiave API senza interrompere applicazioni e automazioni, crea una nuova credenziale con vincoli equivalenti, distribuiscila a tutti i sistemi che usano la precedente e revoca la vecchia solo dopo aver verificato la migrazione. La procedura di Google Cloud segue questo ordine: nuova chiave con le stesse restrizioni, aggiornamento di tutte le applicazioni e cancellazione della precedente alla fine.

La sovrapposizione temporanea consente ai sistemi già aggiornati e a quelli ancora in attesa di continuare a operare, se il servizio ammette due credenziali valide. Una prova riuscita con la nuova chiave, però, riguarda soltanto il sistema provato: per decidere quando eliminare la vecchia occorre censire anche integrazioni esterne e processi che si avviano di rado, poi osservarne l’esito.

Censisci chi usa la credenziale

Parti dai sistemi che inviano richieste, non soltanto dai segreti conservati nel gestore delle credenziali. Registra applicazioni, ambienti, integrazioni presso fornitori, pipeline e attività pianificate che potrebbero usare la chiave. Per ciascuno indica chi può modificarne la configurazione, dove si trova il riferimento alla credenziale, come si applica l’aggiornamento e quale operazione permette di provarlo.

Cerca le copie nelle variabili d’ambiente, nelle configurazioni di distribuzione e nei segreti salvati presso servizi esterni. Un processo può leggere la chiave soltanto all’avvio: aggiornare il valore nel gestore dei segreti non dimostra che un’istanza già attiva abbia caricato quello nuovo. Allo stesso modo, il successo dell’applicazione principale non dice nulla su una pipeline notturna che deve ancora partire.

Assegna a ogni sistema uno stato distinto: da aggiornare, aggiornato ma non provato, oppure provato con la nuova chiave. Le buone pratiche di Google Cloud raccomandano di monitorare l’uso delle API e di isolare le chiavi per applicazione; quest’ultima scelta può rendere più facile attribuire le richieste nelle rotazioni successive. Per la rotazione in corso, conserva anche l’elenco dei sistemi che condividono ancora la stessa credenziale.

Prepara la sostituta e il ritorno alla configurazione precedente

Genera la nuova chiave mentre la vecchia è valida, se il servizio permette la coesistenza. Prima della distribuzione confronta le restrizioni applicabili: API autorizzate, origini o applicazioni ammesse e altri limiti associati alla credenziale. Una restrizione mancante amplia l’accesso durante la sovrapposizione; una restrizione diversa può invece bloccare soltanto alcune richieste, lasciando riuscire una prova troppo semplice.

Conserva il nuovo valore nel sistema previsto per i segreti e usa un identificatore per distinguere le versioni senza riportare la chiave in chiaro nei log operativi. Prepara anche il rollback: finché la precedente è attiva, un sistema che fallisce con la sostituta può tornare temporaneamente alla configurazione già funzionante. Annota come effettuare questo ritorno per ciascun sistema, perché cambiare un segreto centralizzato può richiedere anche il riavvio o una nuova distribuzione.

Se il servizio non consente due chiavi valide contemporaneamente, manca il margine operativo su cui si basa questa sequenza. In quel caso occorre coordinare il cambio dei sistemi dipendenti e stabilire prima se sia necessaria una finestra di manutenzione. Anche quando la coesistenza è possibile, verifica eventuali limiti alla creazione di credenziali prima di avviare il passaggio.

Distribuisci per gruppi e osserva le richieste

Aggiorna per primo un sistema di cui puoi osservare sia la richiesta sia il risultato dell’operazione. Procedi poi per gruppi, registrando quali istanze e integrazioni hanno ricevuto il nuovo valore. Per ogni gruppo prova una richiesta rappresentativa dei permessi effettivamente usati: una risposta positiva a un controllo generico può non esercitare l’API o l’origine che conta in produzione.

Se il provider espone l’uso per singola credenziale, controlla che la nuova venga impiegata dai sistemi aggiornati e cerca richieste residue con la vecchia. Affianca a questi dati gli errori di autenticazione e l’esito delle operazioni importanti. L’assenza di errori può dipendere semplicemente dal fatto che un processo periodico non è ancora partito; l’assenza di richieste con la vecchia chiave va quindi letta insieme all’inventario.

La finestra di osservazione deve comprendere l’esecuzione dei sistemi meno frequenti, oppure una loro attivazione controllata. Se è disponibile solo l’ora dell’ultimo utilizzo della chiave, trattala come un indizio: non identifica da sola tutte le applicazioni ancora configurate con quel valore. Confronta il dato con lo stato delle distribuzioni, le prove delle integrazioni esterne e l’esecuzione delle attività pianificate.

Disattiva dove possibile, poi revoca

Quando tutti i sistemi censiti risultano aggiornati e provati, usa uno stato inattivo reversibile se il provider lo offre. La procedura AWS per le chiavi di accesso IAM prevede di controllare l’ultimo utilizzo della vecchia chiave, disattivarla, verificare le applicazioni con la nuova e cancellarla dopo un ulteriore periodo di osservazione. AWS descrive qui credenziali IAM: per un’altra API bisogna verificare che la disattivazione e la riattivazione siano effettivamente disponibili.

Durante la prova con la vecchia chiave inattiva, ripeti le operazioni rappresentative di applicazioni, integrazioni e automazioni. Se un sistema fallisce perché usa ancora la credenziale precedente, correggilo; riattiva la vecchia solo se il rischio associato lo consente, quindi ripeti migrazione e verifica. La cancellazione definitiva arriva quando i sistemi continuano a funzionare con la nuova chiave e la finestra di osservazione copre anche le esecuzioni meno frequenti.

Se sospetti che la vecchia credenziale sia stata compromessa, mantenerla valida durante la migrazione prolunga anche la possibilità di usarla impropriamente. Riduci la sovrapposizione e, se l’abuso è in corso, valuta la revoca immediata anche quando comporta un’interruzione: contenere l’accesso può avere priorità sulla continuità. Dopo la revoca, rimuovi i riferimenti attivi al vecchio segreto e verifica che le operazioni necessarie riescano ancora con la nuova credenziale.