Il problema della proliferazione dei secret

La proliferazione dei segreti è la diffusione incontrollata di credenziali sensibili all'interno di un'organizzazione. Un segreto è qualsiasi elemento che consenta di ottenere l'accesso: chiavi API, password dei database, token OAuth, chiavi private TLS, chiavi SSH e chiavi di cifratura.

La proliferazione si verifica quando questi segreti finiscono sparsi in luoghi in cui non dovrebbero mai trovarsi:

• Codice sorgente e file di configurazione
• Pipeline CI/CD e variabili d'ambiente
• Immagini dei container e infrastruttura come codice
• Messaggi di chat, wiki e sistemi di ticketing

Quando un segreto esiste in molti luoghi, si perde la capacità di tracciarlo, ruotarlo o revocarlo in modo affidabile.

La causa principale più comune è il segreto hardcoded, ovvero una credenziale scritta direttamente nel codice sorgente. Durante lo sviluppo sembra una soluzione comoda, ma diventa una responsabilità permanente.

Ecco come appare una password di database hardcoded nel codice dell'applicazione:

Chiunque disponga dell'accesso in lettura a questo file ora ha la password di produzione. Questo include ogni sviluppatore, ogni runner CI e chiunque cloni in seguito il repository.

Un pericolo critico dei segreti hardcoded è la cronologia del controllo versione. Anche se elimina un segreto in un commit successivo, questo rimane permanentemente nella cronologia Git di ogni clone.

È possibile recuperare in qualsiasi momento un segreto esposto dalla cronologia:

Per questo motivo, eliminare un segreto dall'ultimo commit non risolve l'esposizione. Il segreto deve essere considerato compromesso e ruotato immediatamente.

Quando un repository con segreti hardcoded viene inviato a un host pubblico come GitHub, bot automatizzati lo analizzano nel giro di pochi secondi o minuti.

Le conseguenze nel mondo reale includono:

• Bollette cloud esplosive: chiavi AWS trapelate usate per avviare flotte di sistemi per il mining di criptovalute, generando decine di migliaia di dollari di costi in una sola notte.
• Violazioni dei dati: credenziali di database esposte che hanno portato all'esfiltrazione completa dei dati.
• Movimento laterale: un token trapelato usato per spostarsi più in profondità nell'infrastruttura.

I provider cloud e GitHub eseguono ora il secret scanning, che rileva automaticamente e talvolta revoca automaticamente le chiavi trapelate, ma non è possibile considerarlo una rete di sicurezza affidabile.

I container introducono un vettore di proliferazione più difficile da individuare. I segreti incorporati in un'immagine durante la build vengono archiviati nei layer dell'immagine e distribuiti a ogni registry e host che scarica l'immagine.

Un errore comune consiste nel copiare un file segreto e poi eliminarlo in un layer successivo: il segreto esiste ancora nel layer precedente.

Chiunque scarichi l'immagine può estrarre quel layer e leggere la chiave. Utilizzi invece i build secrets o l'iniezione a runtime.

Spostare i segreti fuori dal codice e inserirli nelle variabili d'ambiente è un miglioramento, ma non è una soluzione completa. Le variabili d'ambiente risolvono l'hardcoding, ma introducono nuovi percorsi di esposizione:

• possono finire nei dump degli arresti anomali e nelle tracce dello stack degli errori
• sono visibili ad altri processi tramite /proc/<pid>/environ su Linux
• possono essere registrate dagli strumenti di debug che stampano l'intero ambiente
• possono essere archiviate in file .env in chiaro, che vengono sottoposti accidentalmente al commit

Le variabili d'ambiente sono accettabili per la configurazione a bassa sensibilità, ma i segreti di alto valore devono essere conservati in un gestore dei segreti dedicato, con controllo degli accessi e audit.

La proliferazione dei segreti rende quasi impossibile la risposta agli incidenti. Quando un segreto si trova ovunque, due domande non hanno risposta:

• Dove si trova? Non è possibile ruotare ciò che non si riesce a trovare.
• Chi lo ha usato? Senza log centralizzati degli accessi, non è possibile determinare l'ambito di una violazione.

Il raggio d'impatto di una singola credenziale esposta aumenta con la proliferazione. Una password condivisa e riutilizzata su dieci servizi significa che una sola esposizione li compromette tutti. La centralizzazione e l'uso di credenziali univoche e di breve durata riducono drasticamente questo raggio.

Il momento meno costoso per bloccare una fuga di dati è prima che il segreto entri nel controllo versione. Gli scanner di segreti pre-commit esaminano le modifiche in staging e bloccano i commit che contengono schemi di credenziali.

Tra gli strumenti open source più diffusi figurano gitleaks, trufflehog e detect-secrets. Un tipico hook pre-commit viene eseguito localmente:

Abbini questa soluzione a una scansione lato server in CI, così anche uno sviluppatore che aggira l'hook locale viene comunque rilevato.

Se un segreto raggiunge un luogo in cui non dovrebbe trovarsi, proceda nel seguente ordine. La rotazione viene prima; la pulizia della cronologia è secondaria, perché potrebbero già esistere delle copie.

• 1. Ruotare: revochi il segreto esposto e ne emetta immediatamente uno nuovo.
• 2. Verificare: esamini i log degli accessi per individuare eventuali utilizzi non autorizzati durante il periodo di esposizione.
• 3. Eliminare: rimuova il segreto dalla cronologia, ad esempio con git filter-repo, ed esegua un force-push.
• 4. Prevenire: aggiunga la scansione e sposti il segreto in un gestore, così che il problema non possa ripetersi.

Non salti mai il passaggio 1. Un segreto che è stato esposto pubblicamente è compromesso, senza eccezioni.

La proliferazione peggiora quando i segreti dispongono di privilegi eccessivi e sono condivisi eccessivamente. Applicare il principio del privilegio minimo limita i danni in caso di esposizione:

• Assegni a ogni servizio una credenziale propria, mai una condivisa.
• Limiti ogni segreto alle autorizzazioni minime necessarie, ad esempio sola lettura anziché amministrazione.
• Preferisca credenziali di breve durata che scadono automaticamente.
• Separi i segreti per ambiente: le chiavi di dev non devono mai concedere l'accesso a prod.

Queste abitudini trasformano una violazione catastrofica in un incidente circoscritto e recuperabile.

Gli strumenti da soli non risolvono la proliferazione: serve una cultura adeguata. Un'organizzazione matura considera la gestione dei segreti una disciplina continua:

• Posizione predefinita: nessun segreto deve mai trovarsi nel codice sorgente.
• Centralizzi l'archiviazione in un vault gestito, con controllo degli accessi e log di audit.
• Automatizzi la scansione in ogni fase: pre-commit, CI e registry.
• Renda la rotazione una procedura ordinaria, non un'attività riservata alle emergenze.
• Formi ogni sviluppatore affinché riconosca e segnali le esposizioni senza colpevolizzazioni.

L'obiettivo è un sistema in cui sia difficile esporre un segreto e facile rimediare all'esposizione.

Verifichi di aver compreso perché eliminare un segreto esposto non è sufficiente.

Ha appreso perché i segreti hardcoded e dispersi sono una delle vulnerabilità di sicurezza più comuni e dannose.

• La proliferazione dei segreti è la diffusione incontrollata delle credenziali tra codice, pipeline, immagini e chat.
• I segreti hardcoded persistono per sempre nella cronologia Git: eliminarli non risolve un'esposizione.
• I repository pubblici vengono analizzati nel giro di pochi minuti, causando bollette cloud esplosive e violazioni dei dati.
• Le variabili d'ambiente e i layer delle immagini sono canali che possono esporre i segreti, non sistemi di archiviazione sicuri.
• La proliferazione aumenta il raggio d'impatto e rende impossibili la rotazione e la risposta agli incidenti.
• La soluzione consiste nell'eseguire la scansione prima del commit, ruotare prima di tutto in caso di esposizione, centralizzare i segreti in un vault e applicare il principio del privilegio minimo.

Nel prossimo capitolo centralizzeremo correttamente i segreti usando vault e secret store.