Secret dinamici e leasing

Un segreto statico viene creato una volta e riutilizzato indefinitamente: per esempio, la stessa password del database condivisa per anni da dieci servizi. I segreti statici sono l'impostazione predefinita e rappresentano il problema: durano a lungo, sono ampiamente condivisi e sono difficili da ruotare.

Un segreto dinamico viene generato su richiesta, è unico per un consumer e scade automaticamente. Invece di archiviare una password, il vault crea una credenziale completamente nuova ogni volta che viene richiesta.

Questo semplice cambiamento risolve gli aspetti più complessi della gestione dei segreti: la rotazione diventa automatica e il raggio d'impatto di qualsiasi fuga di dati si riduce quasi a zero.

I segreti dinamici richiedono che il vault disponga di accesso privilegiato al sistema backend. Per un database, il flusso è il seguente:

• Un amministratore configura il vault con una credenziale DB root e un template di creazione.
• Un'app esegue l'autenticazione e richiede una credenziale.
• Il vault esegue CREATE USER sul database e restituisce un nome utente e una password nuovi.
• Quando il lease scade, il vault esegue automaticamente DROP USER.

L'app non vede mai una password di lunga durata: riceve una credenziale temporanea associata alla sua identità e al suo lease.

Quando un'applicazione ha bisogno di accedere al database, chiede una credenziale al vault. La risposta contiene un nome utente e una password unici e appena creati, oltre a un lease che indica per quanto tempo sono validi.

Ogni consumer riceve una credenziale propria. Se si avviano due pod dello stesso servizio, ricevono due nomi utente diversi, rendendo possibile l'audit per consumer a livello di database.

Un lease è un contratto che stabilisce per quanto tempo un segreto è valido. Ogni segreto dinamico ha un TTL (time to live) e un max TTL opzionale.

• default_ttl: per quanto tempo la credenziale rimane valida prima di scadere.
• max_ttl: il limite massimo assoluto, anche in presenza di rinnovi.

Quando il lease scade, il vault revoca la credenziale, eliminando attivamente l'utente del database. La scadenza non è solo un flag: attiva una vera procedura di pulizia. È questo che rende i segreti dinamici autoriparanti: una credenziale rubata diventa inutilizzabile entro la finestra del TTL.

Le app a esecuzione prolungata che restano attive oltre la durata di un lease devono rinnovarlo prima della scadenza. Il rinnovo estende il TTL fino al max TTL; dopodiché l'app deve richiedere una nuova credenziale.

Gli operatori possono anche revocare immediatamente un lease: è il kill switch da usare durante un incidente. La revoca di un lease elimina subito la credenziale sottostante, indipendentemente dal TTL rimanente.

È persino possibile revocare tutti i lease con un determinato prefisso, interrompendo istantaneamente l'accesso a un intero servizio o ambiente.

I segreti dinamici non sono limitati ai database. Vault e strumenti simili generano credenziali a breve durata per molti sistemi:

• Cloud IAM: chiavi di accesso AWS/GCP/Azure temporanee tramite assume-role in stile STS.
• SSH: certificati SSH firmati e a breve durata invece di chiavi statiche.
• PKI/TLS: certificati emessi su richiesta con validità breve.
• RabbitMQ, MongoDB, Consul: credenziali effimere per i servizi.

Il modello è identico ovunque: richiedere, utilizzare brevemente, far scadere automaticamente. Le chiavi cloud statiche e di lunga durata sono una causa frequente di violazioni; le credenziali IAM dinamiche le eliminano.

Consideri una credenziale divulgata nei due modelli:

• Statica: la password rimane valida finché un operatore non se ne accorge, la ruota e aggiorna ogni consumer. La finestra di esposizione dura giorni o mesi.
• Dinamica: la credenziale scade entro il suo TTL, spesso nell'arco da pochi minuti a un'ora, ed è limitata a un singolo consumer con autorizzazioni minime. La finestra di esposizione è minima e il danno è contenuto.

I segreti dinamici trasformano la rotazione da un oneroso progetto manuale in una caratteristica automatica e continua del sistema.

I segreti dinamici sono potenti, ma richiedono che il vault conservi una credenziale root altamente privilegiata per ogni backend in cui può creare gli utenti associati alle credenziali che rilascia. Questo concentra il rischio nel vault.

Misure di mitigazione:

• Ruoti la credenziale root stessa, così neppure il vault conserva la password amministrativa originale.
• Limiti l'account root esattamente alle autorizzazioni necessarie per creare ed eliminare gli utenti, niente di più.
• Isoli e monitori con particolare attenzione l'host del vault, poiché è ora un obiettivo di grande valore.

Vault può ruotare la propria credenziale root, così dopo la configurazione nessuna persona la conosce.

Le app devono essere progettate per prevedere il cambiamento delle credenziali. Con i segreti statici, il codice legge una password una volta all'avvio. Con i segreti dinamici, il codice deve:

• Recuperare una credenziale e annotare il TTL del relativo lease.
• Rinnovare il lease oppure recuperare una nuova credenziale prima della scadenza.
• Riconnettersi senza errori quando una vecchia credenziale viene revocata.

Un modello comune prevede un sidecar agent che gestisce il ciclo di vita del lease e riscrive un file locale contenente il segreto, così l'app deve solo ricaricare la propria configurazione. Anche i connection pool devono essere aggiornati, per evitare che continuino a usare una credenziale scaduta.

Non tutti i segreti possono essere dinamici. Alcune API di terze parti forniscono un'unica chiave di lunga durata che non può essere generata su richiesta. Per questi segreti statici, applichi misure di sicurezza compensative:

• Li archivi nel vault, mai nel codice.
• Limiti il loro ambito al privilegio minimo.
• Li ruoti secondo una pianificazione (argomento della prossima lezione).
• Ne monitori l'utilizzo per rilevare anomalie.

Regola generale: preferisca i segreti dinamici; quando è costretto a usare quelli statici, li ruoti e sottoponga il loro utilizzo a audit continui.

Le pipeline CI/CD sono un caso d'uso ideale. Tradizionalmente, una pipeline conserva chiavi di deployment di lunga durata, diventando un bersaglio molto allettante. Con i segreti dinamici, la pipeline:

• Esegue l'autenticazione al vault utilizzando la propria identità OIDC (ad esempio, il token OIDC di GitHub Actions).
• Richiede credenziali cloud a breve durata, valide solo per la durata del job.
• Lascia che scadano automaticamente al termine del job.

Non esiste mai una chiave di deployment di lunga durata. Un log della pipeline compromessa divulga una credenziale già inutilizzabile quando qualcuno lo legge.

Verifichi la sua comprensione dei lease e dei segreti dinamici.

Ha imparato come le credenziali a breve durata e con scadenza automatica trasformano la gestione dei segreti.

• I segreti dinamici vengono generati su richiesta, sono unici per ogni consumer e scadono automaticamente, a differenza dei segreti statici riutilizzati.
• Un lease definisce un TTL e un max TTL; alla scadenza il vault revoca la credenziale eseguendo una vera procedura di pulizia.
• I lease possono essere rinnovati dalle app a esecuzione prolungata oppure revocati immediatamente come kill switch durante un incidente.
• I segreti dinamici funzionano con database, cloud IAM, SSH, PKI e altro ancora: riducono il raggio d'impatto e automatizzano la rotazione.
• Il compromesso consiste nel conservare una credenziale root nel vault: la ruoti e ne limiti rigorosamente l'ambito.
• Le app e le pipeline CI/CD devono essere progettate per gestire le scadenze; preferisca i segreti dinamici e ruoti quelli statici quando sono inevitabili.

Nella prossima lezione parleremo della rotazione delle chiavi e del rilevamento delle fughe di dati quando riescono comunque a verificarsi.