Secrets management: chiavi e password fuori dal codice

Il secrets management è l'insieme di strumenti e regole con cui un'azienda crea, conserva, distribuisce, ruota e revoca i segreti usati da applicazioni e sistemi: password dei database, chiavi API, token, chiavi SSH, certificati. L'obiettivo è semplice da dire: nessun segreto in chiaro nel codice o nelle configurazioni, ognuno letto solo da chi ne ha bisogno, ognuno con una scadenza.

Qui trovi dove finiscono davvero i segreti, come si gestiscono e cosa fare quando una chiave finisce dove non doveva.

Cos'è un segreto, e perché non è una password qualsiasi

L'OWASP, nel suo Secrets Management Cheat Sheet, elenca i segreti più comuni: chiavi API, credenziali dei database, permessi IAM, chiavi SSH, certificati, stringhe di connessione, token di sessione, chiavi private. Osserva anche che molte organizzazioni li tengono scritti in chiaro nel codice sorgente e sparsi nei file di configurazione.

La differenza con la password di una persona è che il segreto lo usa una macchina: nessuno lo digita, nessuno si accorge se lo usa qualcun altro, e spesso non scade.

Dove finiscono i segreti, in pratica

Di solito un segreto trapela perché è finito in un posto pensato per altro:

• Il codice e la sua storia. Una chiave scritta in un file e poi cancellata resta nei commit precedenti. Google lo dice nella guida alla gestione delle chiavi dei service account: toglierla dal repository non basta, perché la maggior parte dei sistemi di versione conserva per sempre la storia delle modifiche.
• I file di configurazione copiati da un ambiente all'altro, compresi quelli sul portatile dello sviluppatore. Anche il file di stato di Terraform può contenere segreti in chiaro, come spieghiamo nella scheda sull'IaC scanning.
• Le pipeline CI/CD, che usano credenziali con privilegi elevati e possono scriverle nei log. L'OWASP chiede di trattare gli strumenti di CI/CD come un ambiente di produzione. È uno dei punti del DevSecOps, dove la pipeline si tratta anche come un bersaglio.
• Le immagini dei container. Secondo la documentazione Docker, build argument e variabili d'ambiente non vanno usati per i segreti, perché restano nell'immagine finale.
• Le variabili d'ambiente. L'OWASP le sconsiglia quando esistono alternative: sono di norma accessibili a tutti i processi e possono finire nei log o nei dump di sistema.
• Le chiavi dei service account scaricate. Su Google Cloud una chiave creata e scaricata da IAM, per default, non ha scadenza e resta valida finché qualcuno non la cancella.

Perché conta: cosa dicono gli incidenti

Il Cloud Threat Horizons Report H1 2026 di Google mette in fila cosa è successo negli incidenti cloud più recenti. Nelle indagini di Mandiant del secondo semestre 2025, non limitate a Google Cloud, il 21% dei casi è partito da credenziali rubate, di persone o di servizi. Due esempi del rapporto spiegano il meccanismo meglio di qualsiasi percentuale:

• a fine 2025 un gruppo è entrato nell'ambiente di una vittima con chiavi di accesso AWS che, secondo Mandiant, erano state esposte per la prima volta in un incidente del 2022 presso un fornitore di gestione delle password. Chiavi ancora valide tre anni dopo;
• altri attaccanti hanno usato token di accesso personali di GitHub rubati per entrare nei repository, e lì hanno trovato token applicativi e di database non protetti, usati poi per andare oltre.

Nello stesso rapporto c'è il caso del gruppo UNC4899: dopo essere entrato in un cluster, ha trovato credenziali statiche del database nelle variabili d'ambiente di un pod e le ha usate per modificare account sul database di produzione. Tra le raccomandazioni, Google chiede di non tenere segreti come le credenziali dei database in variabili d'ambiente o nei repository.

Come si gestiscono i segreti: cinque regole

1. Dove puoi, elimina il segreto

Il segreto più sicuro è quello che non esiste. AWS, nelle best practice IAM, chiede che i workload accedano con credenziali temporanee tramite ruoli IAM: su EC2 o Lambda è AWS a consegnarle alla risorsa, senza distribuire credenziali di lunga durata. Per i workload fuori da AWS, comprese le piattaforme CI/CD, indica meccanismi come IAM Roles Anywhere o lo scambio di un token di un identity provider esterno. Google Cloud indica come alternative alle chiavi la workload identity federation e i service account collegati alle risorse, e per le organizzazioni create dal 3 maggio 2024 blocca di default la creazione di chiavi dei service account. Su Azure, Microsoft raccomanda le managed identity per collegare applicazioni e servizi a Key Vault senza credenziali scritte nel codice.

2. Un posto solo, con accessi minimi

Dove il segreto serve, va in un servizio dedicato, e l'applicazione lo chiede a runtime invece di averlo scritto nel codice. I provider hanno ciascuno il suo: AWS Secrets Manager, Azure Key Vault, Google Secret Manager; esistono anche prodotti indipendenti dal cloud. Con più cloud o più strumenti, l'OWASP chiede soprattutto di standardizzare: deve essere chiaro a cosa serve ogni segreto e dove si trova.

Centralizzare non vuol dire dare a tutti accesso a tutto. Ogni applicazione legge solo i propri segreti, e le persone ne leggono il meno possibile: secondo l'OWASP, ogni utente che può leggere un segreto è una strada in più per farlo uscire. Microsoft, per esempio, raccomanda un Key Vault per applicazione, regione e ambiente, così che sviluppo, preproduzione e produzione non condividano gli stessi segreti.

3. Una scadenza per ogni segreto

L'OWASP descrive il ciclo di vita in quattro fasi: creazione, rotazione, revoca, scadenza. La rotazione serve a far funzionare per poco tempo una credenziale rubata, e la durata giusta va da pochi minuti ad anni a seconda di cosa apre. Per la rotazione l'OWASP suggerisce in genere la funzione offerta dal provider, perché è più semplice da adottare e lascia meno spazio a errori di configurazione. AWS Secrets Manager, per esempio, permette di programmarla, e siccome l'applicazione legge il segreto a runtime, cambiarlo non richiede di ridistribuirla.

Attenzione a non estendere la regola alle persone: per le password degli utenti il NIST SP 800-63B chiede di non imporre il cambio periodico e di imporlo quando c'è evidenza di compromissione.

4. Un registro di chi legge cosa

I servizi dei provider permettono di registrare letture e modifiche dei segreti: AWS Secrets Manager tramite CloudTrail, Google Secret Manager con lo storico delle modifiche, Azure Key Vault attivando i log, che Microsoft raccomanda. I log servono il giorno dell'incidente, quando la domanda è chi ha letto quella chiave e quando, e servono prima, per accorgersi di letture che non tornano.

5. Fermare i segreti prima del commit

L'OWASP suggerisce di portare il controllo dove nasce il problema: nell'IDE dello sviluppatore o con un hook che gira prima del commit. Le piattaforme di codice aiutano. Su GitHub la push protection blocca i push che contengono segreti prima che arrivino al repository: per gli account personali è attiva di default e ferma i segreti diretti ai repository pubblici, mentre a livello di repository e di organizzazione è disattivata di default e richiede GitHub Secret Protection. Per un'azienda conta la seconda.

Docker secrets e Kubernetes: due trappole frequenti

Docker

Il nome trae in inganno. I Docker secrets propriamente detti valgono solo per i servizi Docker Swarm, non per i container avviati da soli: nello swarm sono cifrati in transito e a riposo, e arrivano solo ai servizi autorizzati. Docker Compose ha un meccanismo con lo stesso nome che monta ogni segreto come file in /run/secrets, e la documentazione lo preferisce alle variabili d'ambiente, che possono finire nei log durante il debug.

In fase di build il punto è un altro: niente segreti in ARG o ENV nel Dockerfile. Docker indica i secret mount, che rendono il segreto disponibile solo durante l'istruzione che lo usa, senza lasciarlo nell'immagine.

Kubernetes

La documentazione di Kubernetes avverte che i Secret, per default, sono salvati non cifrati nel datastore del cluster (etcd). Chi ha accesso all'API o a etcd può leggerli, e chi può creare un Pod in un namespace può leggere ogni Secret di quel namespace. Un Secret di Kubernetes è quindi un modo di consegnare il segreto all'applicazione, non un posto sicuro dove conservarlo: servono cifratura a riposo e permessi stretti, oppure un secrets manager esterno.

Se un segreto è finito nel codice: cosa fare

L'OWASP mette l'ordine giusto, ed è un ordine che conta:

1. Revoca. La chiave esposta smette di funzionare subito. È il passo che chiude davvero la porta.
2. Sostituzione. Se ne crea una nuova e la si distribuisce, meglio con un processo ripetibile che a mano.
3. Rimozione. Si toglie il segreto dal codice e dai log. Riscrivere la storia del repository è possibile, ma l'OWASP avverte che rompe i riferimenti ai commit esistenti: va pianificato, e non sostituisce la revoca.
4. Verifica nei log. Chi aveva accesso, chi l'ha usata e quando, da quando era esposta. Una chiave pubblicata per un'ora e una pubblicata per due anni non sono lo stesso incidente.

Conviene scrivere la procedura prima che serva, con un nome accanto a ogni passaggio.

E la compliance?

Nella ISO/IEC 27001:2022 il tema tocca più controlli dell'Annex A: il 5.17 sulle informazioni di autenticazione, l'8.4 sull'accesso al codice sorgente e l'8.24 sull'uso della crittografia, che comprende la gestione delle chiavi. Con un secrets manager, dove stanno i segreti e chi li legge si dimostra dai suoi log e dalle sue policy.

Trovare i segreti già sparsi nel cloud

Le regole valgono da oggi in avanti, ma intanto esiste il pregresso: chiavi su dischi di macchine virtuali, token nelle immagini, service account con chiavi mai ruotate, magari in un account di test che nessuno ricorda. Per questo un censimento dei segreti parte dall'inventario di tutti gli account cloud, ed è lo stesso lavoro che serve per gli errori di configurazione cloud.

Un segreto non pesa da solo: una chiave che apre un ruolo amministrativo su una macchina esposta su internet è un problema diverso da una chiave scaduta in un repository interno. Collegare segreti, permessi ed esposizione è il lavoro di una CNAPP. Wiz, di cui AmagisTech è partner, si collega agli account cloud via API, senza agenti, analizza i dischi da snapshot temporanei e mette in relazione segreti, identità, errori di configurazione, vulnerabilità ed esposizione per individuare i percorsi di attacco reali; con Wiz Code cerca i segreti anche nel codice e nei template dell'infrastruttura (Wiz, How to Evaluate Wiz: Common FAQs). Cosa si riceve da una prima analisi lo raccontiamo nella fotografia del cloud, e se lavori in una realtà SaaS giovane trovi le priorità in sicurezza del cloud per startup e scaleup.

In sintesi

Il secrets management risponde a quattro domande su ogni chiave, token e password delle applicazioni: dove sta, chi la legge, quando scade, come si revoca. La strada è togliere i segreti dove si può con credenziali temporanee, mettere gli altri in un servizio dedicato con accessi minimi, rotazione e log, bloccarli prima del commit e avere pronta la procedura per quando uno trapela. Se vuoi sapere quali segreti sono già esposti nel tuo AWS, Azure o Google Cloud, e cosa aprono, partiamo da una fotografia del cloud con Wiz.