È sicuro archiviare le password critiche nelle variabili di ambiente del server?

Ho un cluster di server, ognuno con file di configurazione che attualmente contengono password di testo semplice per sistemi sensibili e di importanza critica (code di messaggi, archivi di dati e altri servizi).

Alcune persone spostano le password critiche dai file di configurazione in una variabile di ambiente degli account utente in cui vengono eseguiti i processi del server. In questo modo, è possibile eseguire il commit dei file di configurazione nel controllo versione e l'amministratore di sistema deve creare una variabile di ambiente appropriata solo quando il sistema server è impostato. Naturalmente, l'accesso agli account che eseguono questi servizi è molto limitato.

È davvero il modo migliore per evitare le password nei file di configurazione in testo normale o esiste un modo migliore?

Se usi un sistema Linux, guarda / proc / * / environment e decidi se le variabili di ambiente sono un buon posto per archiviare informazioni sensibili o meno. / proc / self è il processo corrente:

$ tr '\0' '\n' < /proc/self/environ
USER=me
LOGNAME=me
HOME=/home/me
PATH=/usr/bin:/bin:/usr/sbin:/sbin
MAIL=/var/mail/me
SHELL=/usr/bin/sh
SSH_CLIENT=1.2.3.4 58195 22
SSH_CONNECTION=1.2.3.4 58195 7.8.9.0 22
SSH_TTY=/dev/pts/1
TERM=xterm

Non importa che l'impostazione della variabile d'ambiente stia probabilmente leggendo un file da qualche parte.

La cosa da ricordare è che l'uso di una password significa che la password è disponibile per il programma. Se questa password non viene fornita da un utente digitandola ogni volta che un programma ne ha bisogno, tale password deve essere accessibile solo in base all'accesso del programma. È possibile crittografare la password localmente e far decrittografare il programma utilizzando una chiave, ma tutto ciò che fa è oscurare la password contro la divulgazione accidentale; qualcuno che ha lo stesso accesso al programma può fare le stesse cose che può fare il programma, inclusa la lettura della chiave di crittografia.

Il modo giusto per farlo è far funzionare l'applicazione come account limitato e archiviare la password in un file protetto con autorizzazioni a livello di filesystem. Speriamo che possiate "includere" un file o simile per mantenere la password fuori da un sistema di controllo della versione (supponendo che il VCS non abbia controlli di sicurezza). Per proteggerti dalla divulgazione involontaria, oscura la password come preferisci: base64 la codifica, usa pgp per crittografare, qualunque cosa abbia senso nel set di opzioni del tuo programma server. Se stai scrivendo un programma per farlo, la cosa migliore che puoi fare è chiedere a un utente la password solo quando è necessario, quindi eliminare quella password dalla memoria non appena viene utilizzata.

Alla fine, se hai dei dati che devono essere letti e scritti , finirai per proteggere qualcosa con una password (o se sei davvero paranoico, con una smart card hardware fisica e un PIN), no importa quanti livelli di crittografia hai.

Questo si riduce alla questione di base della sicurezza del sistema rispetto alla convenienza. Puoi aggiungere "difesa in profondità" disponendo di un sacco di livelli di controlli di sicurezza che un attore malintenzionato dovrebbe violare per raggiungere i "beni", ma poi quando un attore legittimo vuole leggere o modificare alcuni dati, devono passare attraverso un mucchio di cerchi. L'alternativa sono le password in chiaro nei file di testo.

Cosa farei se volessi davvero proteggere alcune informazioni in un sistema mission-critical:

1. Utilizzare la crittografia completa del disco, in modo che il contenuto dell'intero archivio permanente sia crittografato.

2. Limitare l'accesso fisico alle macchine. Bloccare il telaio della macchina con un meccanismo di blocco sicuro e controllare l'accesso fisico alle chiavi. Assumi i muscoli (guardie armate) per essere guardiani per l'accesso.

3. Applicare il controllo di accesso obbligatorio (MAC) a grana fine nel sistema operativo del dispositivo. Puoi iniziare con qualcosa come SELinux su GNU / Linux e impostarlo su Enforcing, quindi adattare la politica alle esatte esigenze del software di produzione, consentendo a quegli account esattamente (e solo) le autorizzazioni di cui hanno bisogno per i file di cui hanno bisogno.

4. Se hai password specifiche del sistema e controllo della versione per i file di configurazione, vuoi davvero evitare il possibile errore di avere una password in testo normale erroneamente impegnata nel controllo della versione, poiché può essere difficile rimuovere una password trapelata da un Cache di VCS. Le variabili d'ambiente sono una delle diverse opzioni praticabili per questo. L'altro è una richiesta di password all'avvio del programma, ma poi riavviare la macchina e ripristinare lo stato operativo è uno sforzo manuale e non può essere fatto autonomamente, quindi c'è di nuovo quella comodità rispetto alla sicurezza.

5. Assicurati di avere a portata di mano specialisti della rete che si occupino delle autorizzazioni del firewall, per ridurre al minimo la tua esposizione a un attacco sulla rete. Audit (penetration test e whitebox test the code) qualsiasi software che si interfaccia con sistemi esterni, in particolare Internet pubblico. Le "interfacce" comprendono non solo connessioni di rete dirette, ma anche la lettura o la scrittura di dati "non attendibili" (dati i cui byte sono originati dall'esterno della RAM / disco / CPU del server sicuro).

Questo non è un elenco completo, ma in particolare il punto 4 è probabilmente rilevante per te, anche se se non esegui almeno i passaggi da 1 a 3, la considerazione del punto 4 e del punto 5 non ti aiuterà molto, perché il tuo il sistema non è sicuro a un livello abbastanza fondamentale.

Passare una password in una variabile d'ambiente è sicuro come far leggere il programma da un file. Solo i processi in esecuzione come lo stesso utente possono leggere l'ambiente di un processo e questi processi possono comunque leggere gli stessi file.

Si noti che questo è diverso dal passare una password sulla riga di comando. Gli argomenti della riga di comando sono leggibili da tutti i processi in esecuzione sullo stesso computer (salvo misure di protezione avanzata), non solo dai processi in esecuzione nello stesso utente.

Se si passa una variabile nell'ambiente, fare attenzione se il programma avvia altri programmi. Questi altri programmi erediteranno l'ambiente dei loro genitori. Quindi non farlo se temi che gli altri programmi possano accidentalmente perdere il contenuto del loro ambiente.

Il difetto nel tuo scenario è "creare una variabile d'ambiente appropriata quando il sistema server è impostato". Una variabile d'ambiente è una proprietà dinamica di un processo. Non è possibile crearlo durante l'installazione di un sistema, non se per impostazione si intende qualcosa che sopravvive al riavvio. Ciò che intendi è presumibilmente che l'amministratore ha predisposto la presenza di questa variabile nell'ambiente quando un determinato utente accede. Questo avviene tramite un file di configurazione (in genere ~/.pam_environmento ~/.profileo da un file letto ~/.profile). Pertanto, questa soluzione non sposta la password dai file di configurazione.

Configurare le cose in modo tale che le password si trovino nell'ambiente di accesso al momento dell'utente non è una buona idea. Significa che ogni processo in esecuzione come quell'utente avrà il segreto, quindi è vulnerabile a una perdita ovunque.

È necessario inserire una password in un file a parte i file di configurazione che sono sotto il controllo della versione e dai normali meccanismi di distribuzione. Va bene mettere la password nell'ambiente a un certo punto, se è conveniente, ma dovrebbe essere fatto per un piccolo set di programmi possibile.