Gestione sicura dei segreti e variabili d'ambiente

I secret hardcoded — chiavi API, password di database, chiavi private TLS e token OAuth incorporati direttamente nel codice sorgente — sono tra le vulnerabilità di sicurezza più comuni e più facilmente prevenibili. I secret presenti nel codice sorgente rimangono esposti nella cronologia del controllo versione (anche dopo l'eliminazione), sono visibili a tutti gli sviluppatori con accesso al repository e vengono spesso divulgati quando i repository vengono accidentalmente resi pubblici. Strumenti come GitGuardian e truffleHog eseguono scansioni continue alla ricerca di secret divulgati su piattaforme come GitHub.

Le variabili d'ambiente rimuovono i secret dal codice sorgente inserendoli a runtime tramite il sistema operativo host o l'orchestratore dei container. L'applicazione legge os.environ['DB_PASSWORD'] invece di un valore hardcoded. È una soluzione migliore rispetto all'hardcoding, ma le variabili d'ambiente presentano dei punti deboli: compaiono negli elenchi dei processi, vengono ereditate dai processi figli, finiscono spesso nei crash dump e nei log di debug e richiedono una rotazione manuale. Sono appropriate per lo sviluppo, ma da sole non sono sufficienti per la gestione dei secret in produzione.

I gestori di secret sono sistemi progettati appositamente per archiviare, ruotare e sottoporre a audit l'accesso ai secret. Tra le soluzioni principali figurano HashiCorp Vault (open source ed enterprise), AWS Secrets Manager, Azure Key Vault e Google Cloud Secret Manager. Le applicazioni eseguono l'autenticazione presso il gestore di secret a runtime, recuperano il secret e lo utilizzano: nessun secret viene mai archiviato su disco o nelle variabili d'ambiente. Ogni accesso viene registrato, consentendo di verificare chi ha avuto accesso a quale secret e quando.

Un vantaggio fondamentale dei gestori di secret rispetto alle variabili d'ambiente è la rotazione automatica. AWS Secrets Manager può ruotare automaticamente le password dei database RDS secondo una pianificazione (ad esempio, ogni 30 giorni), senza richiedere il nuovo deployment dell'applicazione. Il gestore di secret aggiorna contemporaneamente la password nel database e il secret archiviato. Le applicazioni che recuperano i secret a ogni connessione ricevono automaticamente la nuova credenziale. In questo modo si elimina la pratica comune di utilizzare password «permanenti» per gli account di servizio, che non vengono mai ruotate.

La prima linea di difesa contro i segreti sottoposti a commit è un file .gitignore gestito correttamente che escluda tutti i file che potrebbero contenere segreti. Tuttavia, .gitignore impedisce solo i commit futuri: i segreti già sottoposti a commit rimangono nella cronologia di git. Se dei segreti vengono sottoposti accidentalmente a commit, devono essere considerati immediatamente compromessi: ruotate il segreto, quindi, facoltativamente, utilizzate strumenti come git filter-repo per riscrivere la cronologia (operazione richiesta ai fini della conformità, ma da sola insufficiente poiché il segreto potrebbe essere già stato estratto).

I file di Infrastructure as Code (IaC) (Terraform, CloudFormation, manifest Kubernetes) contengono spesso segreti: stringhe di connessione ai database, chiavi API nelle dichiarazioni delle variabili d'ambiente e certificati TLS. Questi file vengono spesso sottoposti a commit nei sistemi di controllo versione, creando un rischio di esposizione dei segreti. Tra le soluzioni vi sono i segreti dinamici di Vault (Vault genera una credenziale a breve durata specificamente per ogni esecuzione di Terraform), i Secrets di Kubernetes (archiviati in etcd, devono essere crittografati a riposo) e external-secrets-operator, che sincronizza i segreti da un secrets manager a Kubernetes durante l'esecuzione.

Ogni applicazione o servizio dovrebbe accedere solo ai segreti di cui ha effettivamente bisogno: è il principio del privilegio minimo applicato ai segreti. Un'applicazione web ha bisogno della password del database, ma non della chiave privata della CA. Un processo di generazione di report ha bisogno di credenziali di sola lettura per il database, non dell'accesso in scrittura. I secrets manager applicano questo principio tramite policy di accesso che specificano quali identità (ruoli IAM, account di servizio, AppRoles) possono leggere quali segreti, registrando ogni accesso ai fini dell'audit.

I segreti dinamici vengono generati su richiesta per uno specifico richiedente e scadono automaticamente. Vault può generare una credenziale temporanea per il database valida per 1 ora e associata al servizio specifico che l'ha richiesta. Alla scadenza, la credenziale viene revocata automaticamente dal database. In questo modo non esistono credenziali statiche di lunga durata che possano essere sottratte: anche se un attaccante intercetta una credenziale dinamica, questa scade rapidamente ed è associata all'identità richiedente nei log di audit.

Le pipeline CI/CD richiedono spesso dei segreti: credenziali dei provider cloud per la distribuzione, token dei registry Docker e chiavi di firma. Non archiviate mai i segreti negli script o nei file di configurazione della pipeline. Utilizzate invece il secrets store integrato nella piattaforma della pipeline (GitHub Actions Secrets, GitLab CI Variables, Jenkins Credentials Store) oppure recuperate i segreti da un vault centralizzato durante l'esecuzione, usando un'identità macchina. Contrassegnate le variabili contenenti segreti come mascherate nei log, per impedirne l'esposizione accidentale nell'output della build.

I secrets manager forniscono log di audit completi di ogni evento di accesso ai segreti: quale identità ha effettuato l'accesso a quale segreto, da quale IP, a quale ora e se l'accesso è riuscito o è stato negato. Questi log sono fondamentali per la conformità (SOC 2, PCI-DSS) e per la risposta agli incidenti. Quando si sospetta che una credenziale sia stata compromessa, i log di audit mostrano quali sistemi vi hanno avuto accesso e quando, consentendo di identificare rapidamente i sistemi potenzialmente interessati e di decidere come contenerli.

Gli hook pre-commit sono script eseguiti automaticamente prima del completamento di ogni commit git e consentono di rilevare i segreti prima che entrino nella cronologia del controllo versione. Strumenti come detect-secrets (Yelp), GitLeaks e git-secrets (AWS) si integrano come hook pre-commit ed esaminano i file nell'area di staging alla ricerca di pattern corrispondenti a chiavi API, stringhe di connessione, chiavi private e token JWT. Se viene rilevato un segreto, il commit viene rifiutato e al developer viene richiesto di rimuovere la credenziale. Il framework pre-commit facilita l'aggiunta e la condivisione delle configurazioni degli hook tra i team.

Verificate la vostra comprensione dei concetti di CompTIA Security+ (SY0-701) trattati in questa lezione.

In questa lezione avete imparato che: i segreti hardcoded nel codice sorgente devono essere eliminati e sostituiti con secrets manager come Vault o AWS Secrets Manager; la rotazione automatica elimina le credenziali di lunga durata che gli attaccanti potrebbero sfruttare anche dopo la compromissione iniziale; infine, i segreti dinamici e le policy di accesso basate sul privilegio minimo riducono al minimo il valore di ogni singolo segreto esposto. Nella prossima lezione esploreremo la sicurezza delle dipendenze e la software composition analysis.