Sicurezza
Come tenere i segreti fuori dal codice sorgente
I nomi delle variabili di ambiente possono stare nel manifest. Le credenziali no. I riferimenti ai segreti mantengono questo confine dal lavoro locale alla produzione.
Un segreto salvato anche una sola volta in un commit può sopravvivere in cloni, cache, log e vecchi commit molto dopo la cancellazione della riga visibile.
Salva nei commit il riferimento, non il valore
Il codice applicativo richiede nomi stabili per le variabili di ambiente, non la credenziale di produzione associata a ciascun nome. In un manifest Adios, un riferimento a un segreto registra la dipendenza senza inserire il valore nel repository.
Così il contratto di distribuzione rimane esaminabile. Un collega può vedere che l'app richiede DATABASE_URL o STRIPE_SECRET_KEY, mentre l'accesso al valore sottostante resta controllato separatamente.
env:
DATABASE_URL: secret://DATABASE_URL
API_SIGNING_KEY: secret://API_SIGNING_KEYTratta compilazione e ambiente di esecuzione come destinatari diversi
Alcune credenziali servono solo durante l'installazione delle dipendenze o il recupero del sorgente privato. Altre servono al processo in esecuzione. Fornire ogni segreto a entrambe le fasi crea un'esposizione più ampia di quella necessaria all'applicazione.
Limita ogni valore al percorso che lo usa e non stampare i valori risolti nell'output della compilazione, nei log dell'ambiente di esecuzione o nei messaggi di errore. Un archivio di segreti non può proteggere una credenziale che l'applicazione scrive in un log pubblico.
- —Solo compilazione: token per pacchetti privati e deploy key Git.
- —Solo ambiente di esecuzione: password del database, chiavi di firma e credenziali API dei provider.
- —Entrambe le fasi, solo se lo stesso valore è davvero necessario in tutte e due.
Rendi ordinaria la rotazione
Prima o poi una credenziale dovrà cambiare. Usa nomi e comportamenti applicativi che permettano di sostituirne il valore senza modificare il sorgente. Per le credenziali ad alto impatto, prevedi un periodo di sovrapposizione in cui vecchi e nuovi valori siano entrambi accettati mentre i carichi di lavoro si riavviano.
Se un segreto finisce in Git, ruotalo prima e ripulisci il repository dopo. Rimuovere la riga è una pulizia utile, ma non rende di nuovo sicuro il valore esposto.
- —Crea la credenziale sostitutiva senza disabilitare quella precedente.
- —Aggiorna il valore salvato e passa i carichi di lavoro alla credenziale sostitutiva.
- —Verifica nei log e nell'attività del provider che venga usata la nuova credenziale.
- —Revoca la credenziale precedente e registra l'ora della rotazione.
Gestisci una credenziale finita in un commit
Supponi che uno sviluppatore salvi in un commit un URL del database, lo rimuova nel commit successivo ed esegua un force push del branch. Considera comunque esposta la password: un clone, un recupero della CI, l'indice dell'editor o una cache della pull request potrebbero già contenerla.
Disabilita o ruota la credenziale, esamina la traccia di audit del provider, cerca nei log eventuali stampe accidentali e solo dopo ripulisci la cronologia del repository. Riscrivere la cronologia riduce la possibilità di ritrovarla in futuro; la rotazione elimina il percorso di accesso attuale.