Testo normale Rails variabili d'ambiente e sicurezza

3

Lavoro per un'azienda sanitaria che enfatizza la sicurezza, a causa della sensibilità dei dati con cui lavoriamo. Di recente, abbiamo effettuato molti controlli (interni ed esterni) del nostro attuale "stack" per garantire che siamo conformi ai vari requisiti del cliente.

Un argomento recente di discussione riguarda le variabili ambientali. Usiamo la gemma dotenv, quindi stiamo memorizzando molte di queste variabili in un file .env (ignorato in git) sul server web. Queste variabili includono le credenziali del nostro database, le credenziali SMTP e varie chiavi API.

Quando alcuni dirigenti hanno appreso che tali credenziali erano memorizzate sul server web in testo semplice, esprimevano preoccupazione. Questa preoccupazione ha scatenato la discussione sulla crittografia di quelle variabili. Vedo i meriti della crittografia e sarebbe certamente utile per proteggere le nostre chiavi API e simili. Tuttavia, dubito del valore che offre per proteggere i dati memorizzati sul nostro server DB (che è in definitiva la preoccupazione maggiore) ... di cosa stiamo parlando qui è un utente malintenzionato che ottiene l'accesso al nostro server web. A meno che manchi qualcosa, quell'utente potrebbe comunque aprire una console di rotaie, che caricherà l'applicazione, gestirà la decrittografia delle credenziali e permetterà loro di interrogare il DB usando i nostri modelli (Patient.all, per esempio). Mi sembra che se il nostro server web viene compromesso, veniamo protetti indipendentemente dal fatto che abbiamo crittografato quelle variabili. Ho ragione su questo?

Supponendo che io sia, come rispondo a questa domanda con qualcosa di più concreto di "beh, è così che funziona Rails" (per quanto riguarda la possibilità di aprire una connessione al DB tramite i binari c)?

    
posta RonMexico 12.01.2017 - 17:56
fonte

3 risposte

1

Ciò che conta qui è una questione di minacce e di linee di difesa. Le minacce che posso immaginare sono:

  • una vulnerabilità nel server Web consente a un utente malintenzionato di leggere i file dalle cartelle delle applicazioni Web
  • una vulnerabilità nel server Web consente a un utente malintenzionato di leggere le variabili di ambiente dell'applicazione
  • una vulnerabilità nel server Web consente a un utente malintenzionato di eseguire comandi arbitrari per conto dell'app legittima
  • una vulnerabilità nel server (indipendentemente dall'applicazione web) consente a un utente malintenzionato di accedere al server

Quindi hai 2 possibili linee di difesa (idealmente dovresti combinarle entrambe)

  1. ridurre il rischio di esposizione

    • assicurati che lo stack di applicazioni Web sia costantemente aggiornato
    • assicurati che l'applicazione web sia nascosta dietro un proxy inverso: questo può aiutare a garantire che solo le richieste HTTP per accettabili URL possano raggiungere il server - la riscrittura dell'URL del proxy può mappare gli URL in arrivo a un sottoprocesso per garantire che nessun URL alla radice possa essere ricevuto
    • assicurati che il datacenter sia protetto correttamente dietro un firewall e che tutti i server seguano le migliori regole pratiche (accesso amministrativo limitato, solo porte aperte richieste, ecc.)
  2. ridurre le possibili conseguenze di un attacco riuscito

    • setup log analisys per rilevare l'accesso illecito e ridurre la finestra temporale di un attacco
    • Se l'utente malintenzionato può leggere la variabile di ambiente, ma non può eseguire alcun comando, assicurarsi che il server di database non sia raggiungibile dall'esterno del centro dati
    • se i dati sono altamente sensibili, è possibile proteggere l'accesso al database anche se il server delle applicazioni Web è stato compromesso utilizzando un'API che richiede un'autenticazione client precedente e passa il token del client a un server di applicazione del servizio che può eseguire controlli di autorizzazione . La difesa completa diventa qui:

      external_firewall - reverse_proxy - web_server - internal_firewal- application_server
      

La crittografia sul server può essere solo offuscata, perché la chiave di decrittografia deve essere accessibile da qualche parte. Può solo indurire il compito per l'attaccante, ma non sarà in grado di bloccarlo.

    
risposta data 12.06.2017 - 10:09
fonte
1

Il problema che hai è che le variabili di ambiente possono perdere in alcune circostanze meno gravi di un utente malintenzionato che ottiene effettivamente l'accesso alla shell interattiva al tuo host (un buon articolo che descrive alcuni dei possibili rischi è " Variabili d'ambiente considerate dannose per i tuoi segreti ". Anche la memorizzazione di segreti in testo semplice può comportare il rischio che un utente malintenzionato possa accedere ai non montati disco, da backup o simili.

Come esempio, presumo che tu esegua il backup del file .env in qualche modo, quindi c'è il rischio di accesso non autorizzato a quel backup.

Una cosa che consideri guardando è una soluzione di "gestione dei segreti" per aiutare a gestire cose come questa. Cose come Hashicorp Vault o, se stai usando Docker, puoi usare Segreti Docker

    
risposta data 12.06.2017 - 10:34
fonte
0

Hai ragione a considerare quegli altri metodi di immissione nei dati non crittografati. Tuttavia, spesso gli attaccanti non ottengono pieno accesso a un server, ma solo parziali, e che è la cosa reale contro cui questo potrebbe proteggere. Ad esempio, potrebbe esserci una vulnerabilità nella tua app che consente a un utente malintenzionato di visualizzare una copia di tutte le variabili di ambiente disponibili per l'app (qualcosa di simile a un phpinfo() non protetto, ma a Rails); ciò consentirebbe loro l'accesso se le variabili di ambiente non sono crittografate, ma posizionare un roadblock se sono crittografate.

Pensare attraverso vari scenari per trovare esattamente ciò che stai effettivamente proteggendo è un ottimo modo per valutare qualsiasi funzione di sicurezza proposta. Questo tipo di "protezione contro un aggressore che può fare solo questo problema limitato, ma non quest'altro" i miglioramenti a volte possono essere utili, ma a volte forniscono molta complessità per essenzialmente nessun vantaggio nel mondo reale; scrivere le tue ipotesi rende un po 'più chiaro e più semplice valutare se ha senso per la tua organizzazione o meno.

    
risposta data 12.01.2017 - 19:33
fonte

Leggi altre domande sui tag