Gestire i segreti in sicurezza e mantenere pulito l'ambiente

I segreti, come chiavi API, password e token, sono i dati più sensibili di qualsiasi sistema. Gestirli in modo errato negli script Bash è uno degli errori di sicurezza più comuni e dannosi.

• Elenco dei processi: gli argomenti passati ai comandi compaiono in ps aux, /proc/<pid>/cmdline e nei log di audit del sistema, risultando visibili a tutti gli utenti dell'host.
• Cronologia della shell: i comandi digitati interattivamente (e talvolta gli script) vengono registrati in ~/.bash_history.
• File di log: le tracce di set -x, i log delle applicazioni e l'output CI/CD possono acquisire i valori delle variabili.
• Fuga nell'ambiente: i processi figli ereditano l'intero ambiente del processo padre, inclusi gli eventuali segreti esportati.

Uno script adeguatamente protetto tratta i segreti come materiale radioattivo: riduce al minimo il tempo di esposizione, limita la superficie esposta e sanifica ogni elemento prima che esca.

Quando passate un segreto come argomento dalla riga di comando, ogni utente del sistema può leggerlo immediatamente tramite ps. Non è un rischio teorico: viene sfruttato regolarmente negli ambienti di hosting condiviso e nei container.

Il frammento qui sotto mostra il problema e la correzione affiancati.

Il modello interattivo più sicuro consiste nel leggere un segreto al momento dell'esecuzione usando read -rs. Il flag -s impedisce l'eco, così i caratteri non vengono mai visualizzati, mentre -r impedisce l'interpretazione delle barre rovesciate.

Punti chiave:

• La variabile non viene mai esportata, quindi i processi figli non possono vederla tramite /proc/<pid>/environ.
• Dopo l'uso, eliminate immediatamente la variabile con unset per ridurre la finestra di esposizione.
• Evitate echo "$SECRET": usate printf '%s' per impedire che una nuova riga finale alteri il valore e per mantenerlo invisibile nelle tracce.

Quando un segreto deve essere conservato su disco (ad esempio, la chiave di un account di servizio), i permessi del file sono la vostra prima linea di difesa.

• Modalità 0600 — leggibile e modificabile solo dal proprietario. Nessun accesso per il gruppo o per gli altri utenti.
• Modalità 0400 — di sola lettura per il proprietario. Preferitela per le chiavi che non dovreste mai sovrascrivere accidentalmente.
• Conservate i file dei segreti in una directory dedicata, ad esempio ~/.secrets/ o /run/secrets/ (quest'ultima è un tmpfs basato sulla RAM in molti sistemi Linux e sopravvive solo fino al riavvio).
• Non collocate mai i file dei segreti all'interno di una directory monitorata da git senza un file .gitignore assolutamente affidabile.

curl supporta un file ~/.netrc (o un percorso arbitrario tramite --netrc-file) che associa i nomi host alle credenziali. In questo modo i dati di autenticazione restano completamente fuori dalla riga di comando e dal corpo dello script.

Il formato del file è semplice:

machine api.example.com
  login admin
  password s3cr3t

Buone pratiche:

• Impostate sempre chmod 0600 ~/.netrc: su alcuni sistemi curl rifiuta il file se è leggibile da tutti.
• Usate --netrc-file /run/secrets/netrc per indicare un segreto basato su tmpfs o iniettato nel container.
• Eliminate i file netrc temporanei con un trap su EXIT.

Le variabili d'ambiente sono un metodo diffuso per inserire segreti negli script (applicazioni 12-factor, pipeline CI/CD). Tuttavia, vengono esposte a ogni processo figlio e compaiono in /proc/<pid>/environ per tutta la durata del processo.

Strategie difensive:

• Importate immediatamente il segreto in una variabile locale e annullate la variabile d'ambiente con unset, in modo che i processi figli non possano ereditarla.
• Passate i segreti ai comandi specifici usando env -i o un'assegnazione inline, invece di usare l'intero ambiente ereditato.
• Non eseguite mai export su una variabile contenente un segreto: quando possibile, usate soltanto l'assegnazione (senza export).

set -x (xtrace) è prezioso per il debug, ma stampa il valore di ogni variabile che espande, inclusi i segreti, sullo standard error. Queste tracce finiscono spesso nei log CI o in syslog.

Strategie per proteggere i segreti mantenendo utile il tracing:

• Disabilitate temporaneamente il tracing intorno alle operazioni sensibili con { set +x; } 2>/dev/null.
• Riattivatelo in seguito con set -x.
• Reindirizzate l'output di xtrace a un descrittore di file separato, diretto a un file di log protetto anziché al flusso di log pubblico.

Anche prestando attenzione, a volte i segreti finiscono nell'output dei log, soprattutto negli script dettagliati o legacy. Una funzione wrapper per il logging che oscura i pattern noti aggiunge una rete di sicurezza.

Questo pattern usa una sostituzione basata su regex su tutto l'output dei log. È un livello di ultima istanza, non un sostituto delle altre pratiche di gestione sicura già illustrate.

env -i avvia un comando con un ambiente completamente vuoto, impedendo a qualsiasi variabile ereditata, inclusi i segreti accidentali, di raggiungere il processo figlio. In seguito si passano esplicitamente solo gli elementi necessari.

È particolarmente utile quando si eseguono script non attendibili, strumenti di build o utilità di terze parti che potrebbero sottrarre dati dall'ambiente.

tmpfs è un filesystem basato sulla RAM. I file scritti al suo interno non vengono mai salvati su disco, eliminando il rischio che i segreti sopravvivano nella swap, nella cache del disco o negli snapshot.

• Su Linux, /dev/shm e /run/user/<uid> sono in genere mount tmpfs.
• Associate sempre l'uso di tmpfs a un trap EXIT per eliminare i file al termine dello script.
• Nei container (Docker, Kubernetes), i segreti possono essere montati direttamente come volumi tmpfs in /run/secrets.

Lo script seguente combina tutte le tecniche di questa lezione in un helper di deployment realistico. Osservate come ogni livello di difesa rafforzi gli altri:

• lettura da stdin con -s — nessuna visualizzazione nel terminale
• file dei segreti su tmpfs con pulizia tramite trap
• pulizia dell'ambiente — il segreto viene annullato prima di qualsiasi processo secondario
• protezione da xtrace — la traccia viene sospesa intorno al codice sensibile
• oscuramento dei log — una regex di sicurezza prima della scrittura nel log

Verificate la vostra comprensione di come i segreti possano trapelare attraverso gli elenchi dei processi e di come impedirlo.

Avete completato Gestione sicura dei segreti e delle variabili d'ambiente. Ecco un riferimento conciso a tutti gli argomenti trattati:

• Elenchi dei processi: non passate mai i segreti come argomenti della riga di comando: compaiono in ps aux e /proc/<pid>/cmdline. Usate invece il piping tramite stdin o --netrc-file.
• Lettura da stdin: usate read -rs per acquisire i segreti interattivamente senza visualizzarli nel terminale né esporli nella cronologia della shell.
• Permessi dei file: i file dei segreti devono avere chmod 0600 (o 0400). Usate install -m 0600 per una creazione atomica.
• File netrc: delegate le credenziali a un file temporaneo indicato da --netrc-file; eliminate il file con trap EXIT.
• Gestione dell'ambiente: eseguite immediatamente unset sulle variabili d'ambiente contenenti segreti dopo averle acquisite localmente; non eseguite mai export su di esse senza necessità; usate env -i per isolare i processi figli.
• Protezione da xtrace: racchiudete il codice sensibile in { set +x; } 2>/dev/null ... set -x per impedire che le tracce di debug rivelino i valori.
• Oscuramento dei log: usate un logger basato su sed come rete di sicurezza di ultima istanza.
• tmpfs: conservate i segreti usati a runtime in /run/user/$UID o /dev/shm, in modo che non tocchino mai il disco; distruggeteli all'uscita.

La difesa in profondità è il principio fondamentale: nessuna singola misura è sufficiente, ma combinarle rende estremamente difficile la fuga dei segreti.