Quali sono i vantaggi di mettere i valori segreti di un sito Web come variabili d'ambiente?

Le linee guida devops su https://12factor.net/config suggeriscono di inserire i segreti del sito Web (password del database, chiavi API, ecc.) In variabili d'ambiente. Quali vantaggi presenta invece di utilizzare file di testo (JSON, XML, YAML, INI o simili) ignorati dal controllo versione?

Trovo molto più semplice copiare un file di configurazione con segreti piuttosto che gestire le variabili di ambiente in .bash_profile e nella configurazione del server web. Mi manca qualcosa?

L'autore elenca il loro ragionamento, sebbene sia un po 'disgiunto. Il loro argomento principale è che è facile controllare accidentalmente un file di configurazione e che i file di configurazione hanno formati diversi e possono essere sparsi nel sistema (tutti e tre sono argomenti mediocri per la configurazione relativa alla sicurezza come token di autenticazione e credenziali).

Data la mia esperienza, hai essenzialmente le seguenti tre opzioni, con vantaggi e svantaggi associati:

Archivia i dati in file di configurazione.

Quando si adotta questo approccio, è consigliabile isolarli idealmente dal repository stesso e assicurarsi che siano al di fuori dell'area in cui l'app memorizza il contenuto.

vantaggi:

• Molto facile da isolare e controllare l'accesso, soprattutto se si utilizzano cose come SELinux o AppArmor per migliorare la sicurezza generale del sistema.
• Generalmente facile da modificare per utenti non tecnici (questo è un vantaggio per i software pubblicati, ma non necessariamente per i software specifici della propria organizzazione).
• Facile da gestire su grandi gruppi di server. Esistono tutti i tipi di strumenti per la distribuzione della configurazione.
• Ragionevolmente facile da verificare quale sia la configurazione esatta utilizzata.
• Per un'app ben scritta, di solito è possibile modificare la configurazione senza interrompere il servizio aggiornando il file di configurazione e quindi inviando un segnale particolare all'app (di solito SIGHUP).

svantaggi:

• È necessaria una pianificazione adeguata per proteggere i dati.
• Potrebbe essere necessario imparare formati diversi (anche se in questi giorni c'è solo una manciata di cui preoccuparsi e generalmente hanno una sintassi simile).
• Le posizioni esatte di archiviazione possono essere codificate nell'app, il che rende la distribuzione potenzialmente problematica.
• L'analisi dei file di configurazione può essere problematica.

Archivia i dati in variabili d'ambiente.

Di solito questo viene fatto acquistando un elenco di variabili e valori di ambiente dallo script di avvio, ma in alcuni casi potrebbe semplicemente dichiararli sulla riga di comando prima del nome del programma.

vantaggi:

• Rispetto all'analisi di un file di configurazione, estrarre un valore da una variabile d'ambiente è banale in quasi tutti i linguaggi di programmazione.
• Non devi preoccuparti troppo della pubblicazione accidentale della configurazione.
• Ottieni un certo grado di sicurezza dall'oscurità perché questa pratica è rara e la maggior parte delle persone che hackerano la tua app non penserà di guardare subito le variabili di ambiente.
• L'accesso può essere controllato dall'applicazione stessa (quando genera processi figlio, può facilmente pulire l'ambiente per rimuovere le informazioni sensibili).

svantaggi

• Sulla maggior parte dei sistemi UNIX, è abbastanza facile accedere alle variabili di ambiente di un processo. Alcuni sistemi forniscono modi per mitigarlo (ad esempio l' hidepidopzione di mount /procsu LInux), ma non sono abilitati per impostazione predefinita e non proteggono dagli attacchi dell'utente proprietario del processo.
• Non è banale vedere le impostazioni esatte che qualcosa sta usando se gestisci correttamente il problema di sicurezza sopra menzionato.
• Devi fidarti dell'app per cancellare l'ambiente quando genera processi figlio, altrimenti perderanno informazioni.
• Non è possibile modificare facilmente la configurazione senza un riavvio completo dell'app.

Utilizzare gli argomenti della riga di comando per passare i dati.

Scherzi a parte, evitatelo a tutti i costi, non è sicuro ed è un dolore nel culo da mantenere.

vantaggi:

• Ancora più semplice da analizzare rispetto alle variabili d'ambiente nella maggior parte delle lingue.
• I processi figlio non ereditano automaticamente i dati.
• Fornisce un modo semplice per testare rapidamente configurazioni particolari durante lo sviluppo dell'applicazione.

svantaggi:

• Proprio come le variabili di ambiente, è facile leggere la riga di comando di un altro processo sulla maggior parte dei sistemi.
• Estremamente noioso per aggiornare la configurazione.
• Pone un limite per quanto tempo può essere la configurazione (a volte fino a 1024 caratteri).

Le variabili di ambiente saranno ereditate da ogni processo figlio del web server. Sono tutte le sessioni che si collegano al server e ogni programma generato da loro. I segreti verranno automaticamente rivelati a tutti questi processi.

Se si mantengono segreti nei file di testo, devono essere leggibili dal processo del server e potenzialmente anche da ogni processo figlio. Ma almeno i programmi devono andare a trovarli; non vengono forniti automaticamente. Potresti anche essere in grado di far funzionare alcuni processi figlio con account diversi e rendere i segreti leggibili solo da quegli account. Ad esempio, suEXEC lo fa in Apache.

Anche se ci sono alcuni compromessi relativi alla sicurezza da fare quando si tratta di variabili o file di ambiente, non credo che la sicurezza sia stata la principale forza trainante per questa raccomandazione. Ricorda che gli autori di 12factor.net sono anche (o erano anche?) Sviluppatori di Heroku PaaS. Far sì che tutti utilizzino le variabili di ambiente probabilmente ha semplificato un po 'il loro sviluppo. C'è così tanta varietà nei diversi formati e posizioni dei file di configurazione e sarebbe stato difficile per loro supportarli tutti. Le variabili d'ambiente sono facili in confronto.

Non ci vuole molta immaginazione per indovinare alcune delle conversazioni che si sono svolte.

Sviluppatore A: "Ah, questa IU del file di configurazione segreta è troppo ingombra! Dobbiamo davvero avere un menu a discesa che passi da json, xml e csv?"

Sviluppatore B: "Oh, la vita sarebbe così grandiosa se solo tutti usassero le variabili d'ambiente per la configurazione dell'app".

Sviluppatore A: "In realtà ci sono alcuni plausibili motivi di sicurezza per farlo. Probabilmente le variabili di ambiente non verranno controllate accidentalmente nel controllo del codice sorgente."

Sviluppatore B: "Non impostare le variabili di ambiente con uno script che avvia il daemon o un file di configurazione?"

Sviluppatore A: "Non in Heroku! Li faremo digitare nella UI."

Sviluppatore B: "Oh, guarda, il mio avviso sul nome di dominio per 12factor.net è appena andato via." ¹

¹ : fonte: inventato.

TL; DR

Esistono diversi motivi per utilizzare le variabili di ambiente anziché i file di configurazione, ma due dei più comuni da trascurare sono il valore di utilità della configurazione fuori banda e la separazione avanzata tra server, applicazioni o ruoli organizzativi. Piuttosto che presentare un elenco esaustivo di tutte le possibili ragioni, affronterò solo questi due argomenti nella mia risposta e toccerò leggermente le loro implicazioni sulla sicurezza.

Configurazione fuori banda: separazione dei segreti dal codice sorgente

Se memorizzi tutti i tuoi segreti in un file di configurazione, devi distribuirli su ciascun server. Ciò significa che è necessario controllare i segreti nel controllo di revisione insieme al codice o disporre di un repository o di un meccanismo di distribuzione completamente separati per i segreti.

Crittografare i tuoi segreti non aiuta davvero a risolverlo. Tutto ciò che fa è spingere il problema ad una rimozione, perché ora devi preoccuparti anche della gestione e della distribuzione delle chiavi!

In breve, le variabili di ambiente sono un approccio per spostare i dati per server o per applicazione fuori dal codice sorgente quando si desidera separare lo sviluppo dalle operazioni. Ciò è particolarmente importante se hai pubblicato il codice sorgente!

Migliora la separazione: server, applicazioni e ruoli

Mentre potresti sicuramente avere un file di configurazione per contenere i tuoi segreti, se li memorizzi nel codice sorgente hai un problema di specificità. Hai un ramo o un repository separato per ogni set di segreti? Come assicurate che il giusto set di segreti arrivi ai server giusti? O riduci la sicurezza avendo "segreti" che sono gli stessi ovunque (o leggibili ovunque, se li hai tutti in un unico file), e quindi costituiscono un rischio maggiore se i controlli di sicurezza di un sistema falliscono?

Se si desidera avere segreti univoci su ciascun server o per ogni applicazione, le variabili di ambiente eliminano il problema di dover gestire una moltitudine di file. Se aggiungi un nuovo server, applicazione o ruolo, non devi creare nuovi file o aggiornare quelli vecchi: aggiorni semplicemente l'ambiente del sistema in questione.

Pensieri di separazione sulla sicurezza

Mentre una completa esplorazione della sicurezza di kernel / memoria / file non rientra nell'ambito di questa risposta, vale la pena sottolineare che le variabili di ambiente per sistema correttamente implementate non sono meno sicure dei segreti "crittografati". In entrambi i casi, il sistema di destinazione deve ancora conservare il segreto decifrato in memoria ad un certo punto per poterlo utilizzare.

Vale anche la pena sottolineare che quando i valori sono memorizzati nella memoria volatile su un determinato nodo, non esiste alcun file su disco che può essere copiato e attaccato offline. Questo è generalmente considerato un vantaggio per i segreti in memoria, ma certamente non è conclusivo.

La questione delle variabili d'ambiente rispetto ad altre tecniche di gestione dei segreti è in realtà più sui compromessi di sicurezza e usabilità che non sugli assoluti. Il tuo chilometraggio può variare.

Personalmente, non consiglierei di impostare le variabili ambientali in .bashrcquanto diventano visibili a tutti i processi avviati dalla shell ma di impostarle a livello di demone / supervisore (script init / rc, configurazione del sistema) in modo che il loro ambito sia limitato a dove necessario .

Laddove team separati gestiscono le operazioni, le variabili di ambiente forniscono un'interfaccia semplice per le operazioni per impostare l'ambiente per l'applicazione senza dover conoscere i file / formati di configurazione e / o ricorrere alla manipolazione del loro contenuto. Ciò è particolarmente vero nelle impostazioni multi-lingua / multi-framework in cui i team operativi possono scegliere il sistema di distribuzione (sistema operativo, processi di supervisione) in base alle esigenze operative (facilità di distribuzione, scalabilità, sicurezza, ecc.).

Un'altra considerazione sono le pipeline CI / CD, poiché il codice attraversa ambienti diversi(ad esempio sviluppo, test / qa, gestione temporanea, produzione) i dettagli ambientali (zone di distribuzione, dettagli di connessione al database, credenziali, indirizzi IP, nomi di dominio, ecc. ecc.) sono meglio impostati da strumenti / framework di gestione della configurazione dedicati e consumati dall'applicazione processi dall'ambiente (in un ambiente secco, scrivere una volta, eseguire ovunque moda). Tradizionalmente, dove gli sviluppatori tendono a gestire questi problemi operativi, tendono a archiviare file o modelli di configurazione oltre al codice, per poi aggiungere soluzioni alternative e altre complessità quando cambiano i requisiti operativi (ad es. Nuovi ambienti / distribuzione / siti, scalabilità / sicurezza peso in,

• Env-vars semplifica la configurazione / complessità su larga scala.
• Env-vars colloca la configurazione operativa esattamente con il team responsabile degli aspetti non correlati al codice dell'applicazione in modo uniforme (se non standard) non vincolante.
• Env-vars supporta lo scambio dei processi master / supervisore (ad esempio god, monit, supervisord, sysvinit, systemd, ecc.) Che supportano l'applicazione - e certamente anche il sistema di distribuzione (sistemi operativi, immagini del contenitore, ecc.) O altro come requisiti operativi Evolve / cambio. Mentre ogni framework linguistico al giorno d'oggi ha una sorta di runtime di processo, questi tendono ad essere operativamente inferiori, adatti più agli ambienti di sviluppo e / o aumentano la complessità in ambienti di produzione multi-lingua / multi-framework.

Per la produzione, preferisco impostare l'applicazione env-vars in un EnvironmentFile come /etc/default/myapplication.confquello distribuito dalla gestione della configurazione e impostato leggibile solo in modo roottale che systemd(o qualsiasi altra cosa) possa generare l'applicazione sotto un utente del sistema Privato Privato in un Privato gruppo . Supportato con gruppi di utenti dedicati per opse sudo- questi file sono illeggibili dal mondo per impostazione predefinita. Questo è conforme a 12factor che supporta tutta la bontà di Dev + Ops plus ha tutti i vantaggi di una sicurezza decente, consentendo allo stesso tempo agli sviluppatori / tester di abbandonare i propri file Environment negli ambienti dev / qa / test.

Dal punto di vista di uno sviluppatore, l'archiviazione dei dati di configurazione nelle variabili di ambiente semplifica le distribuzioni tra diversi ambienti (sviluppo, QA e produzione) e libera gli sviluppatori dal doversi preoccupare di distribuire il file di configurazione errato.

Le app Web di Azure offrono la possibilità di usare questo modello e funziona molto bene.

Inoltre, mantiene i dati potenzialmente sensibili fuori dal controllo del codice sorgente. Ignorare quei file dal controllo del codice sorgente non è realmente fattibile (almeno in .NET) perché in questi file è presente anche la necessaria configurazione di plateplate.